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

From: Sriganesh Kini <[email-masked]>
Date: Wed, 18 Jul 2012 20:25:54 -0400

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.

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.

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.

Let me know if I have understood anything incorrectly.

Thanks
- Sri
________________________________
From: Ross Callon [[email-masked]]
Sent: Thursday, July 12, 2012 9:59 AM
To: Sriganesh Kini; [email-masked]; Nic Leymann
Cc: Loa Andersson; George Swallow (swallow); Ross Callon; Martin Vigoureux; [email-masked]; [email-masked]; 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)

---

From: Lizhong Jin<[email-masked]>
Date: Thu, 19 Jul 2012 16:14:16 +0800

Hi Sri,
Thank you for the review. Please see inline below.

Regards
Lizhong

Sriganesh Kini <[email-masked]> wrote 2012/07/19 08:25:54:

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

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

> Let me know if I have understood anything incorrectly.
[Lizhong] hope the above helps.

> Cc: Loa Andersson; George Swallow (swallow); Ross Callon; Martin 
> Vigoureux; [email-masked]; [email-masked]; 
> Bhatia, Manav (Manav)

---

From: Sriganesh Kini <[email-masked]>
Date: Thu, 19 Jul 2012 11:24:25 -0700

Lizhong, see inline

On Thu, Jul 19, 2012 at 1:14 AM, Lizhong Jin <[email-masked]> wrote:

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

> necessary to configure each P2P return path on each leaf node for HSMP LSP.
>
> >

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.

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

-- 
- Sri

---

From: Lizhong Jin<[email-masked]>
Date: Fri, 20 Jul 2012 21:10:13 +0800

Hi Sri,
See inline below.

Thanks
Lizhong

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