7 Aug 2012 16:55
Re: wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04
Lizhong Jin <lizhong.jin <at> zte.com.cn>
2012-08-07 14:55:21 GMT
2012-08-07 14:55:21 GMT
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 <erosen <at> cisco.com>
> To: Loa Andersson <loa <at> pi.nu>
> Cc: "mpls <at> ietf.org" <mpls <at> ietf.org>, "mpls-chairs <at> tools.ietf.org"
> <mpls-chairs <at> tools.ietf.org>
> Subject: Re: [mpls] wg doc poll on
> draft-jin-mpls-mldp-leaf-discovery-04
> Message-ID: <8845.1344278889 <at> 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
> mpls <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>
> End of mpls Digest, Vol 100, Issue 9
> ************************************
>
_______________________________________________ mpls mailing list mpls <at> ietf.org https://www.ietf.org/mailman/listinfo/mpls
RSS Feed