Re: [mpls] MPLS-RT review of draft-jjb-mpls-rsvp-te-hsmp-lsp

[Lizhong Jin<[e-mail]>]

Hi Sri,
Thank you for the review. Please see inline below.

Regards
Lizhong
 

Sriganesh Kini <[e-mail]> wrote 2012/07/19 08:25:54:

> Hi Manav and other authors,
> 
> Thanks for the additional pointers that you sent to help understand 
> the draft. It certainly helped.
> 
> However before I make a detailed review, I wanted to better 
> understand the motivation of this draft. If I understood correctly, 
> the HSMP LSP is co-routing unicast traffic from PE-x to PE-y with 
> multicast traffic in the reverse direction i.e, PE-y to PE-x. 
> However these are independent services and will have different TE 
> characteristics. I don't see how co-routing that traffic helps to 
> solve the TE problem, when that is the primary requirement of the 
> network design. In fact it may make it even harder.
> 
> I agree that some labels entries may be saved by having a MP2P 
> construct for the unicast traffic. However note that even for 
> unicast traffic the TE characteristics for traffic from PE-x to PE-y
> can be different than traffic from PE-z to PE-y. An MP2P LSP is less
> likely to provide a solution for that problem and when it 
> additionally gets constrained to be co-routed with another P2MP LSP 
> that is satisfying TE requirements of another service then it is 
> even less likely to do so.
[Lizhong] In that case, co-routed P2P return path from PE-x to PE-y, or 
PE-z to PE-y is required, and Eric pointed out the similar for TP case. 
That means upstream label should be allocated for every leaf node. If the 
WG think above case is useful, we could add that option of P2MP + 
co-routed P2P return path. In the current version, we only cover the TE 
case as described in section 3.3 and 3.4.

> 
> Another possible advantage of HSMP seems to be that there is some 
> saving in signaling since forward and reverse direction labels are 
> signaled at the same time. However IMO these savings are not big 
> enough. At least not big enough that independent services must be 
> constrained to be co-routed.
[Lizhong] the primary requirement for HSMP is co-routed. Another advantage 
is operational task reduction compared with P2MP + independent P2P return 
path. In many cases, the return path for P2MP is required, and it is not 
necessary to configure each P2P return path on each leaf node for HSMP 
LSP.

> 
> Note that I am not saying that VPLS does not have problems, nor am I
> saying that P2MP LSPs should not be used in VPLS. My primary 
> question is about the motivation for the co-routing when TE is a 
> requirement and the associated problems I described above for HSMP.
[Lizhong] one of the motivation for co-routed is time synchronization as 
described in section 1.1.

> 
> Let me know if I have understood anything incorrectly.
[Lizhong] hope the above helps.

> 
> Thanks
> - Sri
> ________________________________
> From: Ross Callon [[e-mail]]
> Sent: Thursday, July 12, 2012 9:59 AM
> To: Sriganesh Kini; [e-mail]; Nic Leymann
> Cc: Loa Andersson; George Swallow (swallow); Ross Callon; Martin 
> Vigoureux; [e-mail]; [e-mail]; 
> Bhatia, Manav (Manav)
> Subject: MPLS-RT review of draft-jjb-mpls-rsvp-te-hsmp-lsp
> 
> Sriganesh, Eric, Nic;
> 
> You have been selected as an MPLS Review team reviewers for
> draft-jjb-mpls-rsvp-te-hsmp-lsp
> 
> 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)
> 
>