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

[Lizhong Jin<[e-mail]>]

Hi Sri,
See inline below.

Thanks
Lizhong
 

[e-mail] wrote 2012/07/20 02:24:25:

> Lizhong, see inline

> On Thu, Jul 19, 2012 at 1:14 AM, Lizhong Jin <[e-mail]> 
wrote:
> 
> 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. 
> 
> My point was that the TE multicast service from PE-y to PE-x may 
> require path PE-y -> P1 -> PE-x but the TE unicast service from PE-x
> to PE-y may require a path PE-x -> P2 -> PE-y. This may be due to 
> the current resource availability in the network and the TE 
> requirements of the multicast and unicast services. In this case co-
> routing is not possible. Also the unicast service from PE-z to PE-y 
> may require a path PE-z -> P3 -> PE-y. In this cast merging or 
> sharing resources for the unicast services is not possible. 
[Lizhong] I see your point now. If co-routing is not possible, the HSMP 
LSP setup will be failed and should use other kind of LSP. HSMP LSP is 
used when the primary requirement is co-routed for the application. If 
co-routing is not required, HSMP LSP is an optional way. I will try to 
make this more clear in the draft.

> 
> I interpreted Eric's point about TE as a need to do a common 
> solution with/without label-merging. Not a different use-case.
> 
>  
> > 
> > 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. 
> 
> I admit I don't understand all the intricacies of time sync. There 
> is a stmt in the draft - "... the PTP slave might have to send also 
> messages (not carrying timestamps) back to the PTP master ..." but 
> no mention about what are the TE constraints on such messages. Is 
> the PTP master always the root of the HSMP ?
[Lizhong] you are right, the TE constraints is missing, we will add this 
in next version. The root of HSMP could be PTP master, or connect PTP 
master directly or indirectly, as long as the root receives PTP master 
message.

> 
> Also I don't believe this draft is modifying how PTP messages from 
> master to slave are sent using P2MP. The TE requirements of messages
> from slaves to master along the reverse path that mandate co-routing
> and label-merging is not explained.
[Lizhong] Time synchronization is only one use case. But you are right, 
the time synchronization use case described in the draft is not clear 
about co-routing requirement and TE constraints. We will make this clear 
in the next version.

> 
>  
> 
> > 
> > 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)
> > 
> > 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls

> 

> 
> -- 
> - Sri