Subject: Re: [mpls] MPLS-RT review of draft-jin-jounay-mpls-mldp-hsmp

From: Thomas Morin <[email-masked]>
Date: Fri, 20 Jul 2012 16:27:53 +0200

Hi,

I've reviewed this draft and here is my attempt at commenting on the
different aspects as expected for this review.

What the specs aim to achieve and the procedures described seem to me
as technically sound.

I am however, not convinced by all the use cases put forward in section
2. 

The first one is time synchronisation, but there is no detailed
explanation of why having a leaf-to-root path is needed ("PTP slave
might have to send also messages") nor why having this path be
co-routed is a benefit. 

The second one is IPTV ; one thing that bothers me is that with only
one router as the root, it seems that it will be very hard to implement
redundancy of the IGMP Querier function and source-side router and. 

The third application case is L2VPN, with a key claim being a reduced
operational cost due to having less LDP state in the network. For VPLS,
I don't understand where the gain is supposed to come from, compared to
the solution used in draft-ietf-l2vpn-vpls-mcast and
draft-ietf-l2vpn-evpn.

-Thomas

2012-07-12, Ross Callon:
> Thomas, Ravi, Mach;
>  
> You have been selected as an MPLS Review team reviewers for
> draft-jin-jounay-mpls-mldp-hsmp
>  
> 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: Thomas Morin <[email-masked]>
Date: Fri, 20 Jul 2012 16:37:06 +0200

Hi,

[please ignore my previous mail, sent before it was ready; my apologies]

So, I would say that the draft is in a good shape for being considered
for adoption. In my own view, the use cases would need to be more
strongly backed and/or more detailed (and if necessary, the claims of
applicability reduced) but discussing this is a natural part of a
debate on adoption.

Thanks,

-Thomas

---

From: Lizhong Jin<[email-masked]>
Date: Sat, 21 Jul 2012 22:48:19 +0800

Hi Thomas,
Thank you for this review. Please see inline below.

Regards
Lizhong

> might have to send also messages") nor why having this path be
[Lizhong] time synchronization [IEEE1588] requires the sync packet from 
master to slave to be co-routed with the delay request packet from slave 
to master. We will add these detail according IEEE1588 in the next 
version.

> redundancy of the IGMP Querier function and source-side router and. 
[Lizhong] If redundancy root node is required, two HSMP LSP could be 
provided. Section 6 has some considerations about redundancy.

> the solution used in draft-ietf-l2vpn-vpls-mcast and
[Lizhong] In this application, the PSN tunnel operational cost is reduced 
by HSMP LSP, you do not need to setup P2MP LSP + P2P LSP on each PE, but 
use HSMP LSP instead. VPLS-MCAST and EVPN does not talk about PSN tunnel 
operational cost. Actually HSMP LSP could be also applied in VPLS-MCAST 
and EVPN. We will make this part to be more clear to avoid 
misunderstanding.

---

From: Mach Chen <[email-masked]>
Date: Tue, 24 Jul 2012 08:31:51 +0000

Hi,

I have reviewed the draft and here are my comments:

1.       First, I am not fully convinced by the use cases

a)       For the PTP case, since the requirements is to have co-routed bidirectional path, and LDP-based solution may not be the best choose, it cannot guarantee that the upstream and downstream LSP are fully co-routed, because it’s path follow IP routing, two directions may choose different interfaces(links) or tunnels as the nexthop. RSVP-TE-based solution maybe a better choice. In addition, if the purpose is to save the bandwidth (compare to use unicast bidirectional LSP), seems the benefit is limited.

b)       For VPLS and E-VPN scenarios, seems MP2MP LSP  is a better choice.

2.       The draft introduces a new terminology: HSMP LSP, if my understanding is correct, the HSMP LSP is actually a co-routed bidirectional P2MP LSP,  and  IMHO, the name of co-routed bidirectional P2MP LSP is more common and easy to understand.

3.       The solution and extensions defined in the draft works, one comments on Section 4.2

“Both elements will be used as FEC Elements in the FEC TLV.” More accurate should be “If a FEC TLV contains an HSMP FEC Element, the HSMP FEC Element MUST be the only FEC Element in the FEC TLV.

4.       In summary, the solution and extensions are OK, but the use cases need more work and clarification.

Best regards,
Mach

发件人: Ross Callon [mailto:[email-masked]]
发送时间: 2012年7月13日 0:50
收件人: [email-masked]; Raveendra Torvi; Mach Chen
抄送: Loa Andersson; George Swallow (swallow); Martin Vigoureux; Ross Callon; [email-masked]; Fred Jounay; [email-masked]; Nic Leymann
主题: MPLS-RT review of draft-jin-jounay-mpls-mldp-hsmp

Thomas, Ravi, Mach;

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: Wed, 25 Jul 2012 00:39:16 +0800

Hi Mach,
Thank you for the review. See inline below.

Regards
Lizhong

Mach Chen <[email-masked]> wrote 2012/07/24 16:31:51:

> a)       For the PTP case, since the requirements is to have co-
> routed bidirectional path, and LDP-based solution may not be the 
> best choose, it cannot guarantee that the upstream and downstream 
> LSP are fully co-routed, because it’s path follow IP routing, two 
> directions may choose different interfaces(links) or tunnels as the 
> nexthop. 
[Lizhong] Do you mean ECMP link (e.g, LAG) between two LDP neighbors? If 
the logical link is ECMP, although physical interface is different from 
upstream to downstream and vice versa, we still consider it co-routed. One 
possible case for not co-routing is using static routing between LDP 
neighbors, if that happens, the LSR could generate an indication to 
operator. Another possible case to choose different interfaces will happen 
when physical link cost is assymmetric, which is a corner case in field 
deployment. When TE-Tunnels are used between LDP neighbors, yes, it is 
possible to be not co-routed for HSMP LSP. We will add these exceptions in 
the next version. The LSR/LER in HSMP LSP could detect if the path is 
co-routed or not, if not co-routed, an indication could be generated.

> RSVP-TE-based solution maybe a better choice. In addition, 
> if the purpose is to save the bandwidth (compare to use unicast 
> bidirectional LSP), seems the benefit is limited. 
[Lizhong] The purpose is not saving the bandwidth, mLDP based HSMP would 
be used in the network where bandwidth is not an issue. And time 
synchronization is only one of the use case for HSMP LSP, the benefit 
would be more in other use case, e.g, IPTV scenario in section 2.2.

> b)       For VPLS and E-VPN scenarios, seems MP2MP LSP  is a better 
choice. 
[Lizhong] MP2MP does not provide unicast path from leaf to root. HSMP LSP 
provide both multicast from root to leaf, and unicast from leaf to root. 
The two kind of LSP provide different purpose. You could also refer to 
MPLS list discussion as 
http://www.ietf.org/mail-archive/web/mpls/current/msg05557.html.

> 2.       The draft introduces a new terminology: HSMP LSP, if my 
> understanding is correct, the HSMP LSP is actually a co-routed 
> bidirectional P2MP LSP,  and  IMHO, the name of co-routed 
> bidirectional P2MP LSP is more common and easy to understand.
[Lizhong] bidirectional P2MP LSP is our initial name of this draft. 
Bidirectional in mLDP and PIM means there is full connectivity between all 
the nodes of the LSP, which is not the case for HSMP. Authors suggested 
HSMP LSP, Hub & Spoke multipoint LSP, to reflect the topology. Hope to see 
more comments from the WG about the name.

> “Both elements will be used as FEC Elements in the FEC TLV.” More 
> accurate should be “If a FEC TLV contains an HSMP FEC Element, the 
> HSMP FEC Element MUST be the only FEC Element in the FEC TLV.
[Lizhong] correct, will update this. Thank you.

> cases need more work and clarification.
[Lizhong] Hope above clarification helps.

> 抄送: Loa Andersson; George Swallow (swallow); Martin Vigoureux; 
> Ross Callon; [email-masked]; Fred Jounay; [email-masked]; Nic 
Leymann
> Reviews should be sent to the document authors, WG co-chairs and 
secretary,
> Are you able to review this draft by July 27, 2012 (ie, prior to the 
IETF

---

From: <[email-masked]>
Date: Sun, 29 Jul 2012 04:22:03 +0000

Hi Lizhong,

> redundancy of the IGMP Querier function and source-side router and.
[Lizhong] If redundancy root node is required, two HSMP LSP could be provided. Section 6 has some considerations about redundancy.

Note that it still does not allow proper IGMP fallback in case of Querier failure, because the two Queriers won't see each other; it's also unclear to me how you would ensure both that the two queriers have proper IGMP state and that you don't have packet duplication.

> the solution used in draft-ietf-l2vpn-vpls-mcast and
[Lizhong] In this application, the PSN tunnel operational cost is reduced by HSMP LSP, you do not need to setup P2MP LSP + P2P LSP on each PE, but use HSMP LSP instead.
VPLS-MCAST and EVPN does not talk about PSN tunnel operational cost. Actually HSMP LSP could be also applied in VPLS-MCAST and EVPN. We will make this part to be more clear to avoid misunderstanding.

Basically, for *each* P2MP LSP (eg. one per-PE per VPN) your proposal adds a (co-routed) path back to each PE, but this offer no gain of state on P-routers, since in a typical scenario unicast LDP is already here, and even assuming it is not, the cost of adding it is minimal and (contrary to HSMP LSP) independent of the number of VPNs.

I still don't see where the gain is...

-Thomas

> > IETF meeting in Vancouver)?

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 30 Jul 2012 13:39:50 +0200

Hi Thomas,

> I still don't see where the gain is…

A nice property of the HSMP-LSP is that the path to the root follows the the nodes in the path of the HSMP-LSP up to the root. That can't be guaranteed in case you use a P2P LSP to the root. Also, if you use a P2P LSP, you need an additional label to identify P2MP LSP it has to be associated with.

So in general I think the HSMP-LSP is useful technology that we should standardize. I'm pretty sure other use-cases will be developed over time.

Thx,

Ice.

---

From: Lizhong Jin<[email-masked]>
Date: Mon, 30 Jul 2012 20:36:27 +0800

Hi Thomas,
Thank you for the review. See inline below for the clarification.

Regards
Lizhong

<[email-masked]> wrote 2012/07/29 12:22:03:

> Note that it still does not allow proper IGMP fallback in case of 
> Querier failure, because the two Queriers won't see each other; it's
> also unclear to me how you would ensure both that the two queriers 
> have proper IGMP state and that you don't have packet duplication.
[Lizhong] Sorry, I did not describe this clear. If the root is the IGMP 
Querier and source-side router, you are right, it is hard to provide 
redundancy. The two HSMP LSP redundancy scenario would be valid when the 
IGMP Querier router acts as a client for both HSMP LSP, and multi-home to 
the two root nodes of HSMP LSP. This is still not IGMP Querier router node 
redundancy, but HSMP LSP redundancy. In that case, the IGMP Querier router 
node redundancy could be implemented by other mechanism, and independent 
of HSMP LSP redundancy. Note that the root node of HSMP LSP is not 
necessary to be IGMP Querier router in IPTV scenario.

> [Lizhong] In this application, the PSN tunnel operational cost is 
> reduced by HSMP LSP, you do not need to setup P2MP LSP + P2P LSP on 
> each PE, but use HSMP LSP instead. 
> VPLS-MCAST and EVPN does not talk about PSN tunnel operational cost.
> Actually HSMP LSP could be also applied in VPLS-MCAST and EVPN. We 
> will make this part to be more clear to avoid misunderstanding.
> 
> Basically, for *each* P2MP LSP (eg. one per-PE per VPN) your 
> proposal adds a (co-routed) path back to each PE, but this offer no 
> gain of state on P-routers, since in a typical scenario unicast LDP 
> is already here, and even assuming it is not, the cost of adding it 
> is minimal and (contrary to HSMP LSP) independent of the number of VPNs.
[Lizhong] yes, the state on P-routers is not reduced. This use case is to 
reflect the discussion on the list: 
http://www.ietf.org/mail-archive/web/mpls/current/msg05557.html. From the 
operational point of view, the number of LSP maintained on each PE is 
reduced (by combining the P2MP and P2P LSP into one LSP). But yes, the 
state maintained on P and PE is almost the same. We could add some note in 
the draft about this.

> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous 
> avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> If you have received this email in error, please notify the sender 
> and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for 
> messages that have been modified, changed or falsified.
> Thank you.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 30 Jul 2012 12:27:53 -0400

Ice,

I want to confirm my understanding:

- Use cases 2.1 (time sync) and 2.2 (igmp) are really use cases for vpms and could/should be removed from this spec

- hsmp is mostly useful for vpms and not really needed for vpls as Thomas said

About your comments in the below email:

- why is it important for the return path to be the same?
- Associating a separate p2p with a p2mp (if not using hsmp) is more (if not only) useful to vpms than vpls?

Thanks.
Jeffrey

> -----Original Message-----
> From: IJsbrand Wijnands [mailto:[email-masked]]
> Sent: Monday, July 30, 2012 7:40 AM
> To: <[email-masked]>
> Cc: [email-masked]; Lizhong Jin; Ross Callon
> Subject: Re: [mpls] draft-jin-jounay-mpls-mldp-hsmp
> 
> Hi Thomas,
> 
> > Basically, for *each* P2MP LSP (eg. one per-PE per VPN) your proposal
> adds a (co-routed) path back to each PE, but this offer no gain of
> state on P-routers, since in a typical scenario unicast LDP is already
> here, and even assuming it is not, the cost of adding it is minimal and
> (contrary to HSMP LSP) independent of the number of VPNs.
> >
> A nice property of the HSMP-LSP is that the path to the root follows
> the the nodes in the path of the HSMP-LSP up to the root. That can't be
> guaranteed in case you use a P2P LSP to the root. Also, if you use a
> P2P LSP, you need an additional label to identify P2MP LSP it has to be
> associated with.
> 
> So in general I think the HSMP-LSP is useful technology that we should
> standardize. I'm pretty sure other use-cases will be developed over
> time.
> 
> Thx,
> 
> Ice.
> 
> 
> >
> > -Thomas
> >
> >
> >
> >
> >>
> >>> Note to authors: You have been CC'd on this email so that you can
> >>> adoption (ie, it doesn't have to be perfect at this point, but
> should
> >>> be a good start).
> >>> secretary, and CC'd to the MPLS WG email list. If necessary,
> comments
> _______________________________________________________________________
> __________________________________________________
> >

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 30 Jul 2012 19:03:47 +0200

Hi Jeffrey,

> - why is it important for the return path to be the same?

Besides what is documented in the draft, I think it has nice properties that will be useful going forward. I have idea's, but I'm not ready to disclose these at this time.

> - Associating a separate p2p with a p2mp (if not using hsmp) is more (if not only) useful to vpms than vpls?

I think so yes.

Thx,

Ice.

---

From: Lizhong Jin<[email-masked]>
Date: Tue, 31 Jul 2012 09:58:29 +0800

"Jeffrey (Zhaohui) Zhang" <[email-masked]> wrote 2012/07/31 00:27:53:

> - Use cases 2.1 (time sync) and 2.2 (igmp) are really use cases for 
> vpms and could/should be removed from this spec
[Lizhong] VPMS is a service multiplexed to PSN tunnel. The time sync could 
be directly over PSN tunnel (HSMP LSP), see section 6.1 of 
draft-ietf-tictoc-1588overmpls-02. For the IGMP case, if the root node is 
IGMP querier, HSMP LSP instead of VPMS could be used. But as Thomas 
pointed, it is hard to provide redundancy.

> (if not only) useful to vpms than vpls?
[Lizhong] I partly agree. And if we all agree, we could remove the VPLS 
use case.

Thanks
Lizhong

> > > Basically, for *each* P2MP LSP (eg. one per-PE per VPN) your 
proposal