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

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 16 Jul 2012 15:49:50 +0000

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

---

From: Manav Bhatia <[email-masked]>
Date: Mon, 16 Jul 2012 21:47:06 +0530

Hi Eric,

Yes i am the co-author of draft-ietf-tictoc-1588overmpls. I believe we
can use the HSMP LSP described in this draft for timing distribution
irrespective of whether we accept the solution described in the tictoc
draft or not.

[clipped]

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

Well, this is precisely what happens when you try to ship timing
packets over MPLS. Each LSR updates the residence time in the 1588
packet before forwarding it downstream.

The following blog post describes the HSMP LSP in detail and should
address most of your questions:
http://routingfreak.wordpress.com/2011/02/27/hub-and-spoke-multi-point-lsps-for-scalable-vpls-architecture/

Cheers, Manav

---

From: Lizhong Jin<[email-masked]>
Date: Thu, 19 Jul 2012 15:44:13 +0800

Hi Eric,
Thank you for this review. See inline below for my comments.

Regards
Lizhong

"Eric Osborne (eosborne)" <[email-masked]> wrote 2012/07/16 23:49:50:

> 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?
[Lizhong] hope draft-jin-jounay-mpls-mldp-hsmp-05 (
http://tools.ietf.org/html/draft-jin-jounay-mpls-mldp-hsmp-05) helps.
> - 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?
[Lizhong] See Manav's reply.

> 
> 
> -  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.
[Lizhong] if WG agree, we could add above option. Hope to see more 
comments about this.

> 
> 
> - 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. 
[Lizhong] the intention is to compute a P2P path to PE3 which is a CSPF 
behavior, and use this path information to build P2MP LSP (same as 
RFC4875). We will make this more clear. Thank you.