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

[Sriganesh Kini <[e-mail]>]

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.

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 ?

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.



>
> >
> > 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