Re: [mpls] MPLS-RT review of draft-jin-jounay-mpls-mldp-hsmp

[Lizhong Jin<[e-mail]>]

Hi Mach,
Thank you for the review. See inline below.

Regards
Lizhong


Mach Chen <[e-mail]> wrote 2012/07/24 16:31:51:

> Hi,
> 
> I have reviewed the draft and here are my comments:
> 
> 1.       First, I am not fully convinced by the use cases
> a)       For the PTP case, since the requirements is to have co-
> routed bidirectional path, and LDP-based solution may not be the 
> best choose, it cannot guarantee that the upstream and downstream 
> LSP are fully co-routed, because it’s path follow IP routing, two 
> directions may choose different interfaces(links) or tunnels as the 
> nexthop. 
[Lizhong] Do you mean ECMP link (e.g, LAG) between two LDP neighbors? If 
the logical link is ECMP, although physical interface is different from 
upstream to downstream and vice versa, we still consider it co-routed. One 
possible case for not co-routing is using static routing between LDP 
neighbors, if that happens, the LSR could generate an indication to 
operator. Another possible case to choose different interfaces will happen 
when physical link cost is assymmetric, which is a corner case in field 
deployment. When TE-Tunnels are used between LDP neighbors, yes, it is 
possible to be not co-routed for HSMP LSP. We will add these exceptions in 
the next version. The LSR/LER in HSMP LSP could detect if the path is 
co-routed or not, if not co-routed, an indication could be generated.

> RSVP-TE-based solution maybe a better choice. In addition, 
> if the purpose is to save the bandwidth (compare to use unicast 
> bidirectional LSP), seems the benefit is limited. 
[Lizhong] The purpose is not saving the bandwidth, mLDP based HSMP would 
be used in the network where bandwidth is not an issue. And time 
synchronization is only one of the use case for HSMP LSP, the benefit 
would be more in other use case, e.g, IPTV scenario in section 2.2.

> b)       For VPLS and E-VPN scenarios, seems MP2MP LSP  is a better 
choice. 
[Lizhong] MP2MP does not provide unicast path from leaf to root. HSMP LSP 
provide both multicast from root to leaf, and unicast from leaf to root. 
The two kind of LSP provide different purpose. You could also refer to 
MPLS list discussion as 
http://www.ietf.org/mail-archive/web/mpls/current/msg05557.html.

> 2.       The draft introduces a new terminology: HSMP LSP, if my 
> understanding is correct, the HSMP LSP is actually a co-routed 
> bidirectional P2MP LSP,  and  IMHO, the name of co-routed 
> bidirectional P2MP LSP is more common and easy to understand.
[Lizhong] bidirectional P2MP LSP is our initial name of this draft. 
Bidirectional in mLDP and PIM means there is full connectivity between all 
the nodes of the LSP, which is not the case for HSMP. Authors suggested 
HSMP LSP, Hub & Spoke multipoint LSP, to reflect the topology. Hope to see 
more comments from the WG about the name.

> 3.       The solution and extensions defined in the draft works, one
> comments on Section 4.2 
> “Both elements will be used as FEC Elements in the FEC TLV.” More 
> accurate should be “If a FEC TLV contains an HSMP FEC Element, the 
> HSMP FEC Element MUST be the only FEC Element in the FEC TLV.
[Lizhong] correct, will update this. Thank you.

> 4.       In summary, the solution and extensions are OK, but the use
> cases need more work and clarification.
[Lizhong] Hope above clarification helps.

> 
> 
> Best regards,
> Mach
> 
> 发件人: Ross Callon [mailto:[e-mail]] 
> 发送时间: 2012年7月13日 0:50
> 收件人: [e-mail]; Raveendra Torvi; Mach Chen
> 抄送: Loa Andersson; George Swallow (swallow); Martin Vigoureux; 
> Ross Callon; [e-mail]; Fred Jounay; [e-mail]; Nic 
Leymann
> 主题: MPLS-RT review of draft-jin-jounay-mpls-mldp-hsmp
> 
> Thomas, Ravi, Mach;
> 
> You have been selected as an MPLS Review team reviewers for
> draft-jin-jounay-mpls-mldp-hsmp
> 
> Note to authors: You have been CC’d on this email so that you can know 
that 
> this review is going on. However, please do not review your own 
document. 
> 
> Reviews should comment on whether the document is coherent, is it useful
> (ie, is it likely to be actually useful in operational networks), and is
> the document technically sound?  We are interested in knowing whether 
the 
> document is ready to be considered for WG adoption (ie, it doesn’t have 
to
> be perfect at this point, but should be a good start). 
> 
> Reviews should be sent to the document authors, WG co-chairs and 
secretary,
> and CC’d to the MPLS WG email list. If necessary, comments may be sent 
> privately to only the WG chairs. 
> 
> Are you able to review this draft by July 27, 2012 (ie, prior to the 
IETF 
> meeting in Vancouver)? 
> 
> Thanks, Ross
> (as MPLS WG chair)
>