Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04

From: Lizhong Jin<[email-masked]>
Date: Tue, 7 Aug 2012 22:55:21 +0800

Hi Eric,
I believe there is some misunderstanding about the use case. Please see 
inline below.

Thanks
Lizhong

> Date: Mon, 06 Aug 2012 14:48:09 -0400
> From: Eric Rosen <[email-masked]>
> To: Loa Andersson <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>,   "[email-masked]"
>    <[email-masked]>
> Subject: Re: [mpls] wg doc poll on
>    draft-jin-mpls-mldp-leaf-discovery-04
> Message-ID: <8845.1344278889@erosen-linux>
> 
> 
> > this is to start a two week poll on adopting
> > draft-jin-mpls-mldp-leaf-discovery-04 as an MPLS working group 
document.
> 
> No, do not support.
> 
> Applications that use BGP-based auto-discovery and/or signaling, e.g., 
MVPN,
> already seem to have adequate mechanisms for discovering leaf nodes. 
E.g.,
> MVPN has the "Leaf Info Required" bit in PMSI Tunnel Attribute to 
indicate
> when the tunnel root wants to know who all the leafs are, and the Leaf 
A-D
> route  is used by the leafs to reply to the root.  A Leaf A-D route also
> carries an RT to constrain distribution of the route to the root node. 
The
> draft defines a new AFI/SAFI, whose NLRI consists of an mLDP FEC element 
and
> a leaf node address.  There is certainly no need for this in MVPN, as it
> just duplicates existing functionality, in a less general way, and with 
no
> comparable method of constraining distribution.
> 
> The MVPN BGP signaling allows a root node to determine which leaf nodes 
need
> to receive which customer data streams.  In theory, this information 
could
> be used to assign two different data streams to the same tunnel, if, 
e.g.,
> the same set of leaf nodes need to receive both streams.  (Whether this 
is
> actually useful in practice is arguable.)  However, the signaling 
proposed
> in this draft only allows the root node to determine the leaf nodes who 
have
> joined a particular mLDP LSP.  It doesn't convey any information about 
why a
> particular leaf node has joined a particular LSP, so it's not really 
useful
> if one is trying to decide whether two data streams should be sent on 
the
> same tunnel.
> 
> I just don't see the use case for the draft's BGP mechanism.
[Lizhong] The leaf discovery mechanism is not to complement MVPN. MVPN has 
Leaf A-D route to find the VPN membership, and MVPN is a root initiated 
application. The leaf discovery mechanism is useful for root initiated 
application to aggregate tunnels from leaf initiated application. For 
example, how to let MVPN to aggregate the mLDP tunnel generated by in-band 
signaling? Leaf A-D could not find the membership of other application. 
The leaf discovery mechamisn is trying to solve this issue. Section 2 
paragraph 2 gives out a more detail example.

> 
> I think the T-LDP mechanism is similarly problematic.  If an application 
is
> not already using T-LDP for signaling, I don't think it makes much sense 
to
> require that each leaf node initiate a new T-LDP session to each root 
node.
> For security reasons, one usually doesn't accept T-LDP sessions from 
just
> anyone; the set of possible T-LDP peers is either configured, or is
> auto-discovered (via some BGP-based mechanism).  If BGP auto-discovery 
is
> already being used, the T-LDP mechanism would not be needed, but if BGP
> auto-discovery is not being used, we wouldn't want to require that each
> potential root node be configured with the addresses of all the 
potential
> leaf nodes.
[Lizhong] in section 4, we say: the root initiated application with LDP as 
the
   main signaling mechanism, e.g, P2MP PW [I-D.ietf-pwe3-p2mp-pw], would
   use leaf discovery mechanism based on T-LDP, while application with
   MP-BGP as main signaling mechanism, e.g, VPLS
   Multicast[I-D.ietf-l2vpn-vpls-mcast], L3VPN Multicast [RFC6513] may
   use leaf discovery mechanism based on MP-BGP.
That means we did not require to configure much additional T-LDP session 
for leaf discovery, but mostly rely on the already existing T-LDP session 
provided by the application. 

> 
> We do have to remember that, in receiver-driven multicast, the fact that 
the
> root node doesn't know all the leaf nodes is considered to be a 
scalability
> advantage.
[Lizhong] leaf discovery did not introduce much additional new T-LDP 
session, but mostly rely on the existing T-LDP session provided by the 
application. See section 5 for the scalability discussion.

> 
> Also, I'm not at all sure what the root node would do with the 
information
> that two P2MP LSPs have the same set of leaf nodes.  This fact by itself
> does not mean that the two tunnels could be replaced by a single tunnel.
> Even if it did, LDP has no mechanism for replacing one tunnel with 
another.
> I don't think it's worthwhile setting up a whole bunch of new TCP
> connections (and T-Hello adjacencies) just to convey a small amount of
> not-very-useful information.
[Lizhong] this is not to replace two tunnels into one, but when creating 
new service, the root node has the capability to aggregate existing tunnel 
instead of creating an additional one.

> 
> In summary:
> 
> - I don't really see what the use case is;
> 
> - Existing BGP A-D mechanisms for MVPN are better at providing the
>   information an application really needs, and are better at 
constraining
>   the distribution of the information;
> 
> - The T-LDP mechanism raises security issues and overhead issues, and
>   it is not clear what to do with the information it conveys.
> 
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 
> 
> End of mpls Digest, Vol 100, Issue 9
> ************************************
>

---

From: Eric Rosen <[email-masked]>
Date: Tue, 07 Aug 2012 11:42:13 -0400

> The leaf discovery mechanism is not to complement MVPN

> The leaf discovery mechanism is useful for root initiated application to
> aggregate tunnels from leaf initiated application. For example, how to let
> MVPN to aggregate the mLDP tunnel generated by in-band signaling?

I'm confused by these two sentences, as the second mentions the use of mldp
leaf discovery by MVPN, but the first says that you dont' intend the two
mechanisms to be used together.  However, let's assume for now that there is
no MVPN here, just some mLDP in-band signaling.

So suppose PE2, PE3, and PE4 join an mLDP tunnel rooted at PE1.  Say the
tunnel is identified by the mLDP FEC element <root=PE1, opaque
value=<S1,G1>> (this is a case of in-band signaling)..

Now PE2, PE3, and PE4 join another mLDP tunnel rooted at PE1, say
<root=PE1,opaque value=<S2,G2>> (another case of in-band signaling).

PE1 sees that the two tunnels have exactly the same set of leaf nodes.  So
what is PE1 supposed to do?

> the root node has the capability to aggregate existing tunnel instead of
> creating an additional one.

A few questions:

- How does it do this?  There doesn't seem to be any mechanism to do this.

  * What will cause PE2,PE3,PE4 to expect (S2,G2) traffic on the <root=PE1,
    opaque value=<S1,G1>> tunnel?

  * What will cause the teardown of the partially set up tunnel <PE1,S2,G2>
    at the P routers and PE routers?

- How does the root node's aggregation strategy respond to dynamically
  changing sets of leaf nodes?  (Remember the leaf nodes join and leave the
  LSP one at a time.)

- How does the root node even know that the leaf nodes can correctly handle
  traffic from an aggregated tunnel?

I don't think any of this can be done without some application-layer
signaling between the root and leaf nodes.  But if there is
application-layer signaling between the root and leaf nodes, why doesn't
that provide all the necessary auto-discovery?

> leaf discovery did not introduce much additional new T-LDP session, but
> mostly rely on the existing T-LDP session provided by the application.

If you want to focus on a use case where there is already T-LDP signaling
for some application, you have to show that some requirement is not met by
the existing T-LDP signaling for that application.

-

---

From: Lizhong Jin<[email-masked]>
Date: Wed, 8 Aug 2012 09:36:04 +0800

Hi Eric,
See inline below. Hope the clarification helps.

Thanks
Lizhong

> what is PE1 supposed to do?
[Lizhong] PE1 have the tunnel <root=PE1, opaque value=<S1,G1>>. Then when 
PE1 initiates new MVPN service, and has leaf member PE2, PE3, PE4, then 
PE1 is not necessary to initiate new mLDP tunnel, but directly aggreate to 
tunnel <root=PE1, opaque value=<S1,G1>> for MVPN service. If PE1 does not 
have the leaf information of tunnel <root=PE1, opaque value=<S1,G1>>, then 
PE1 could not aggregate MVPN service to that tunnel. And Leaf A-D route in 
MVPN could not help PE1 to find the leaf information of tunnel <root=PE1, 
opaque value=<S1,G1>>. That means two different kind of applications could 
share one tunnel which is this draft trying to solve. 

> that provide all the necessary auto-discovery?
[Lizhong] as stated above, this draft did not try to help aggregate tunnel 
<root=PE1, opaque value=<S1,G1>> and <root=PE1, opaque value=<S2,G2>>, but 
help to aggregate tunnels from different kinds of applications, or to let 
leaf initiated application and root initiated application to share one 
tunnel. E.g, enable MVPN to use tunnel <root=PE1, opaque value=<S1,G1>>.

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Thu, 9 Aug 2012 05:21:03 +0530

Hi Lizhong,
                           I am a bit confused on the text below.

[Lizhong] PE1 have the tunnel <root=PE1, opaque value=<S1,G1>>. Then when PE1 initiates new MVPN service, and has leaf member PE2, PE3, PE4, then PE1 is not necessary to initiate new mLDP tunnel, but directly aggreate to tunnel <root=PE1, opaque value=<S1,G1>> for MVPN service. If PE1 does not have the leaf information of tunnel <root=PE1, opaque value=<S1,G1>>, then PE1 could not aggregate MVPN service to that tunnel. And Leaf A-D route in MVPN could not help PE1 to find the leaf information of tunnel <root=PE1, opaque value=<S1,G1>>. That means two different kind of applications could share one tunnel which is this draft trying to solve.

Could you please clarify how would we aggregate multiple applications like MVPN over "in-band" S, G Tunnel?  I believe you meant multiplexing multiple applications over generic opaque tunnel, is that correct?

Irrespective of that, if the motivation of the solution is efficient mLdp resource management/aggregation then had you considered the option of using existing OAM mechanisms  (e.g on-demand p2mp lsp ping  or same with periodic refreshes after some larger intervals) to gather leaf info?

Having learnt about leaves thru T-LDP does not mean that leaves are reachable in data path. It is possible that a leaf join is stuck midway and couldn't really join the tree.
For example, thru T-LDP you have learnt about leaves L1, L2, L3, L4 but L4 couldn't join and is stuck in some transit node (e.g no session/hello adjacency to upstream etc). Then choosing the tree for an application that wants to talk to L1,L2,L3 and L4 may impact the application delivery.

Cheers,
Pranjal

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lizhong Jin
Sent: Tuesday, August 07, 2012 6:36 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04

Hi Eric,

Thanks
Lizhong

> what is PE1 supposed to do?
[Lizhong] PE1 have the tunnel <root=PE1, opaque value=<S1,G1>>. Then when PE1 initiates new MVPN service, and has leaf member PE2, PE3, PE4, then PE1 is not necessary to initiate new mLDP tunnel, but directly aggreate to tunnel <root=PE1, opaque value=<S1,G1>> for MVPN service. If PE1 does not have the leaf information of tunnel <root=PE1, opaque value=<S1,G1>>, then PE1 could not aggregate MVPN service to that tunnel. And Leaf A-D route in MVPN could not help PE1 to find the leaf information of tunnel <root=PE1, opaque value=<S1,G1>>. That means two different kind of applications could share one tunnel which is this draft trying to solve.

> that provide all the necessary auto-discovery?
[Lizhong] as stated above, this draft did not try to help aggregate tunnel <root=PE1, opaque value=<S1,G1>> and <root=PE1, opaque value=<S2,G2>>, but help to aggregate tunnels from different kinds of applications, or to let leaf initiated application and root initiated application to share one tunnel. E.g, enable MVPN to use tunnel <root=PE1, opaque value=<S1,G1>>.

---

From: [email-masked]
Date: Thu, 9 Aug 2012 12:39:58 +0800

Hi Pranjal,
Thank you for the comments. See inline below.

Lizhong

"Dutta, Pranjal K (Pranjal)" <[email-masked]> wrote 
2012/08/09 07:51:03:

> [Lizhong] PE1 have the tunnel <root=PE1, opaque value=<S1,G1>>. Then
> when PE1 initiates new MVPN service, and has leaf member PE2, PE3, 
> PE4, then PE1 is not necessary to initiate new mLDP tunnel, but 
> directly aggreate to tunnel <root=PE1, opaque value=<S1,G1>> for 
> MVPN service. If PE1 does not have the leaf information of tunnel 
> <root=PE1, opaque value=<S1,G1>>, then PE1 could not aggregate MVPN 
> service to that tunnel. And Leaf A-D route in MVPN could not help 
> PE1 to find the leaf information of tunnel <root=PE1, opaque 
> value=<S1,G1>>. That means two different kind of applications could 

> Could you please clarify how would we aggregate multiple 
> applications like MVPN over “in-band” S, G Tunnel?  I believe you 
> meant multiplexing multiple applications over generic opaque tunnel,
> is that correct?
[Lizhong] right, and I think we are nearly aligned. And actually, whether 
the mLDP tunnel opaque value is generic or <S,G>, tunnel aggregation will 
care more about the tunnel root and leaf members.

> 
> Irrespective of that, if the motivation of the solution is efficient
> mLdp resource management/aggregation then had you considered the 
> option of using existing OAM mechanisms  (e.g on-demand p2mp lsp 
> ping  or same with periodic refreshes after some larger intervals) 
> to gather leaf info?
[Lizhong] We have considered this option before, please refer to 
http://www.ietf.org/proceedings/77/slides/mpls-4/mpls-4_files/frame.htm. 
By using OAM tools, additional overload will be added to the network, and 
leaf discovery is more of a signaling requirement. That's why we choose 
signaling to do leaf discovery.

> 
> Having learnt about leaves thru T-LDP does not mean that leaves are 
> reachable in data path. It is possible that a leaf join is stuck 
> midway and couldn’t really join the tree.
> For example, thru T-LDP you have learnt about leaves L1, L2, L3, L4 
> but L4 couldn’t join and is stuck in some transit node (e.g no 
> session/hello adjacency to upstream etc). Then choosing the tree for
> an application that wants to talk to L1,L2,L3 and L4 may impact the 
> application delivery.
[Lizhong] I understand you concern, but I think reachability is the 
reponsability of OAM tools.

> [Lizhong] PE1 have the tunnel <root=PE1, opaque value=<S1,G1>>. Then
> when PE1 initiates new MVPN service, and has leaf member PE2, PE3, 
> PE4, then PE1 is not necessary to initiate new mLDP tunnel, but 
> directly aggreate to tunnel <root=PE1, opaque value=<S1,G1>> for 
> MVPN service. If PE1 does not have the leaf information of tunnel 
> <root=PE1, opaque value=<S1,G1>>, then PE1 could not aggregate MVPN 
> service to that tunnel. And Leaf A-D route in MVPN could not help 
> PE1 to find the leaf information of tunnel <root=PE1, opaque 
> value=<S1,G1>>. That means two different kind of applications could 
> [Lizhong] as stated above, this draft did not try to help aggregate 
> tunnel <root=PE1, opaque value=<S1,G1>> and <root=PE1, opaque 
> value=<S2,G2>>, but help to aggregate tunnels from different kinds 
> of applications, or to let leaf initiated application and root 
> initiated application to share one tunnel. E.g, enable MVPN to use 
> tunnel <root=PE1, opaque value=<S1,G1>>. 
> 
> >

---

From: Eric Rosen <[email-masked]>
Date: Thu, 09 Aug 2012 10:43:44 -0400

Lizhong> PE1 has the tunnel <root=PE1, opaque value=<S1,G1>>. Then when PE1
Lizhong> initiates new MVPN service, and has leaf members PE2, PE3, PE4, PE1
Lizhong> does not need to initiate a new mLDP tunnel,

In the MVPN procedures, PE1 generally advertises a tunnel before it knows
which other PEs need to join the tunnel.  

Lizhong> but directly aggrgeate to tunnel <root=PE1, opaque value=<S1,G1>>
Lizhong> for MVPN service ... That means two different kinds of application
Lizhong> could share one tunnel, which is what this draft is trying to
Lizhong> solve.

If PE1 sends the MVPN traffic into a tunnel that is being used by another
application, how will the leaf nodes know which traffic belongs to which
application?

I think this would require a demultiplexor field which is understood by both
applications.

Also, if the (S1,G1) flow stops while the MVPN application continues, it
will be necessary to leave the <root=PE1, opaque value=<S1,G1>> tunnel in
place.  This may cause a problem if the (S1,G1) flow later resumes, but with
a different set of receivers.

---

From: Chandrasekar R <[email-masked]>
Date: Thu, 9 Aug 2012 22:51:41 +0530

HI Lizhong,

[Chandra] How does the leaf PE differentiate between the mLDP traffic (S1, G1) and the MVPN traffic whose source/group addresses could be on a different address space?

If aggregating mLDP tunnels across different applications is the primary goal of the draft, then we should first establish whether the traffic of those applications can be actually aggregated.

Regards,
Chandra.

---

From: [email-masked]
Date: Fri, 10 Aug 2012 09:24:30 +0800

Hi Eric,
I think we are on the road to get aligned. See inline below.

Thanks
Lizhong

> which other PEs need to join the tunnel. 
[Lizhong] Right, but in MVPN, if want to aggregate I/S-PMSI onto same 
P-Multicast tree, PE would re-advertise I/S-PMSI A-D route. It is the same 
here, re-advertise I/S-PMSI A-D route.

> I think this would require a demultiplexor field which is understood by 
both
[Lizhong] right, tunnel aggregation require upstream label. But tunnel 
<root=PE1, opaque value=<S1,G1>> is not necessary to have demultiplexor 
field for mLDP in-band service, and PHP should be disabled for this 
tunnel.

> a different set of receivers.
[Lizhong] right, but this is not special for this draft, and I don't think 
this is a problem, this is general pain of multicast tunnel aggregation. 
The problem you referred is also existed for S-MPSI aggregation in MVPN. 
The deployment should balance between the pain and gain of multicast 
tunnel aggregation.

---

From: [email-masked]
Date: Fri, 10 Aug 2012 09:24:38 +0800

Chandra,
Thanks for the comments. See reply below.

Lizhong

> [Chandra] How does the leaf PE differentiate between the mLDP 
> traffic (S1, G1) and the MVPN traffic whose source/group addresses 
> could be on a different address space?
[Lizhong] If MVPN would aggregate I/S-PMSI onto one tunnel, it should 
certainly advertise upstream label which is specified in RFC6514. The 
upstream label would be used to demultiplex the MVPN traffic. Only the 
mLDP traffic (S1, G1) will not have upstream label, and could be 
differentiated by leaf PE. Note that PHP would be disabled for this mLDP 
tunnel.

> 
> If aggregating mLDP tunnels across different applications is the 
> primary goal of the draft, then we should first establish whether 
> the traffic of those applications can be actually aggregated.
[Lizhong] right, and as I know, the applications listed in the draft 
already has upstream label advertisement in their respective RFC/Draft.

---

From: Chandrasekar R <[email-masked]>
Date: Fri, 10 Aug 2012 20:47:07 +0530

Hi Lizhong,
Yes, it was clear that UHP should be used on the mLDP LSP.  If the same mLDP LSP is to be shared for MVPN also, then leaf PE cannot know from control plane signaling alone whether mLDP LSP label should be used for forwarding in-band multicast traffic or not. In any case if my understanding is correct it is not possible to aggregate two different mLDP in-band multicast flows. So aggregating an in-band multicast flow with flows of different application also increasing complexity is not a convincing motivation.

Regards,
Chandra.

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 10, 2012 6:55 AM
To: Chandrasekar R
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: DISCUSS///RE: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04

Chandra,

Lizhong

> could be on a different address space?
[Lizhong] If MVPN would aggregate I/S-PMSI onto one tunnel, it should certainly advertise upstream label which is specified in RFC6514. The upstream label would be used to demultiplex the MVPN traffic. Only the mLDP traffic (S1, G1) will not have upstream label, and could be differentiated by leaf PE. Note that PHP would be disabled for this mLDP tunnel.

> the traffic of those applications can be actually aggregated.
[Lizhong] right, and as I know, the applications listed in the draft already has upstream label advertisement in their respective RFC/Draft.

---

From: Lizhong Jin<[email-masked]>
Date: Sat, 11 Aug 2012 22:47:31 +0800

Chandrasekar R <[email-masked]> wrote 2012/08/10 23:17:07:

> Hi Lizhong,
> Yes, it was clear that UHP should be used on the mLDP LSP.  If the 
> same mLDP LSP is to be shared for MVPN also, then leaf PE cannot 
> know from control plane signaling alone whether mLDP LSP label 
> should be used for forwarding in-band multicast traffic or not. 
[Lizhong] if the traffic contains mLDP LSP label at the bottom of label 
stack, the leaf PE consider it as in-band multicast traffic, otherwise 
not. Note that there is only one in-band multicast flow carried by this 
mLDP LSP label, other traffic flow (not in-band multicast) will have 
upstream label for forwarding. Let me give an example, if leaf PE 
advertise label_A for <root=PE1, opaque value=<S1,G1>>, when MVPN 
aggregate flow to this mLDP LSP, root PE1 will advertise upstream label_B 
for this MVPN flow to leaf PE (RFC6514). The leaf PE will know that if 
bottom label stack is label_A, it is in-band multicast traffic, if label 
stack is labe_A and label_B, it is MVPN traffic.

> In 
> any case if my understanding is correct it is not possible to 
> aggregate two different mLDP in-band multicast flows. 
[Lizhong] yes, and aggregating two different mLDP in-band multicast flows 
is not the purpose of this draft. The purpose of this draft is to allow 
root initiated application (e.g, MVPN) to aggregate flow onto LSP setup by 
leaf initiated application (e.g, in-band mLDP). We will rephrase purpose 
content in the draft to make it more clear.

> So aggregating
> an in-band multicast flow with flows of different application also 
> increasing complexity is not a convincing motivation.
[Lizhong] Could you explicitly point out what kind of the complexity you 
have concern about?

Regards
Lizhong

> [Lizhong] If MVPN would aggregate I/S-PMSI onto one tunnel, it 
> should certainly advertise upstream label which is specified in 
> RFC6514. The upstream label would be used to demultiplex the MVPN 
> traffic. Only the mLDP traffic (S1, G1) will not have upstream 
> label, and could be differentiated by leaf PE. Note that PHP would 
> be disabled for this mLDP tunnel. 
> 
> >

---

From: Thomas Morin <[email-masked]>
Date: Tue, 21 Aug 2012 14:07:56 +0200

Hi WG, Chandra,

Chandrasekar R:
> [...]Aggregating an in-band multicast flow with flows of different 
> application also increasing complexity is not a convincing motivation.
>

Yes, you are putting the finger on precisely on a point I had discussed 
with the authors.

Due to the fact that you cannot aggregate together two in-band signalled 
P2MP LSPs, the only aggregation you can do involving in-band signalled 
LSPs will provide very limited gains, because it will not provide a 
significant gain (not an order of magnitude gain, at best a factor 2), 
and be much more constrained that the aggregation that can be done.  
Worse, trying to marginally optimize by aggregating single in-band 
signalled LSPs into service LSPs, will actually make the aggregation of 
these service LSPs more constrained and less efficient.

A patent looking for a problem ?

-Thomas

>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* Friday, August 10, 2012 6:55 AM
> *To:* Chandrasekar R
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* DISCUSS///RE: [mpls] wg doc poll on 
> Chandrasekar R <[email-masked] <mailto:[email-masked]>> wrote 
> 2012/08/10 01:21:41:
>
> > HI Lizhong,
> >
> differentiated by leaf PE. Note that PHP would be disabled for this 
> mLDP tunnel.
>
> >