Subject: Re: [mpls] Comments on draft-jjb-mpls-rsvp-te-hsmp-lsp

From: Manav Bhatia <[email-masked]>
Date: Mon, 14 Jan 2013 14:39:08 +0530

Hi,

We have posted an updated version of draft-jjb-mpls-rsvp-te-hsmp-lsp which
we hope addresses some of the questions raised by the MPLS-RT reviewers
team earlier.

http://www.ietf.org/id/draft-jjb-mpls-rsvp-te-hsmp-lsp-02.txt

Cheers, Manav

On Mon, Jul 16, 2012 at 9:19 PM, Eric Osborne (eosborne) <[email-masked]
> wrote:

> Overall, I think this is a solid draft.  It presents a pair of problems
> and the solution to those problems.  I'd like to see some input from the
> larger community as to whether the two problems the draft presents as
> prevalent in operational networks.  I'm also curious whether there are any
> other uses cases that may take advantage of HSMP.  Is there an analog in
> non-TE mcast that could be addressed with HSMP?
>
> Assuming the use cases are valid, I can see it eventually being adopted as
> a WG document.
>
> I have a few comments:
>
> - Section 1.1 talks about time synchronization.  I'm not a timing expert,
> so I'm just going off of what I can infer from the document.  The text
>
> "This is possible because of the link delay calculation performed locally
> by each node, which enables it to calculate the propagation delay over the
> path.  This scenario permits that the same PTP Sync messages would be sent
> by the PTP master to all the PTP slaves"
>
> implies that each hop in an LSP used for timing distribution would need to
> examine the packet, modify it, and send it on.  Strictly speaking this is
> outside the scope of this draft, but it seems a heck of a thing to just
> assume, since it is an important prerequisite for this particular use case.
>
> Manav, you're on draft-davari-tictoc-1588overmpls as well as this draft.
>  Do you anticipate that a HSMP LSP would use methods from that draft to
> distribute timing?  If the methods in draft-davari-tictoc-1588overmpls were
> not standardized, would the HSMP draft still be able to solve the timing
> distribution use case?
>
>
> -  The draft's approach merges the return traffic from the leaves.  Using
> Figure 1 (p. 5) as an example, node B will assign the same UPSTREAM_LABEL
> for all flows from all leaves.  This means we can't use this approach for
> MPLS-TP.  It seems that the problems identified in this draft would be
> relevant to those who want to use a TP-style approach for their LSPs.  I
> know this is not an MPLS-TP draft, but it would be nice to solve the
> p2mp+return problem once for both traditional TE and for TP.  It would be
> nice to have a way for an upstream node to give out different upstream
> labels per downstream hop.  I realize this increases the ILM requirements
> on the HSMP headend, but I fear that without this ability we'll have to
> solve the problem twice.
>
>
> - The example on p. 11 is hard to follow.  At step 2, it looks like PE1
> builds a p2p LSP to PE3 which is then converted to a p2mp LSP?  If the
> intent is to build a p2mp LSP to PE3, it should probably say something like
> "PE1 signals a P2MP LSP with PE3 as the only leaf" or something.
>
>
>
>
> eric
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>