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

[Sriganesh Kini <[e-mail]>]

Hello authors,

Some comments on the updated draft -

I would re-word the abstract as follows -
"There are applications that require bi-directional, co-routed and
guaranteed communication from a root node to several leaf nodes in a
hub-and-spoke fashion. This draft defines such a Hub and Spoke
Multipoint LSP (HSMP LSP) and defines protocol extensions to P2MP
RSVP-TE to setup such LSPs. "

section 1. Instead of "... require reverse one-to-one traffic flow
..." change to "...require reverse co-routed one-to-one traffic flow
... "

section 1.1 replace "bandwidth insurance" by "guaranteed bandwidth"

section 1.2 Replace "reverse path," with "reverse direction of the
VPMS PW i.e., from leaf to root".

section 2. Before doing a comparison it would be useful to first
define a HSMP LSP in terms of data plane and control plane operations.

section 3 replace "fullfill" by "fulfill"

How is the reservation style determined ? It may be useful for the
root to specify the style even for leaf to root traffic.

Otherwise the draft looks useful. It could considered for acceptance as WG doc.


On Mon, Jan 14, 2013 at 1:09 AM, Manav Bhatia <[e-mail]> wrote:
> 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)
> <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>



--
- Sri