Subject: [mpls] MPLS-RT review of draft-chen-mpls-source-label

From: Yimin Shen <[email-masked]>
Date: Mon, 12 May 2014 13:52:32 +0000

WG chairs, authors,

I have finished my review for this draft. Overall, I think the document is easy to understand, and useful from the perspective that the mechanism may support egress routers to identify source of traffic for measurement purposes.

>From technical perspetive, I do have the following comments, and hope the authors can address them before WG adoption.

1.      Granularity of SL

   The document currently views "sources" as ingress nodes, hence assumes the granularity of SL as per-node. From a generic point of view, I'd like to see some discussion on per-flow SL (multiple flows ingress on a given node), or why this mode may not be useful.

2.      SL  allocation and disbritubtion.

   I think this is a big missing piece. The draft currently pushes this out of scope. However, the procedures of how a router may allocate an SL for itself without colliding with other routers, and how a source-to-SL mapping may be disctributed to egress routers are both relavant and important to the proposal. Therefore, they should be specified in this draft for completeness.

3.      Transit router use cases.

   The draft has improved its clarity from previous rev by removing transit router use cases. However, transit router is still mentioned in a few places. So a cleanup may still be need to achieve consistency.

Regards,

/Yimin Shen

---

From: Lizhong Jin <[email-masked]>
Date: Wed, 14 May 2014 23:22:12 +0800

Hi authors,
I finished the review, and the text is easy to understandable. I have some
technical comments and concerns before adoption. Hope the authors could
help to clarify.

Section 1, line 159
Suggest to remove the Segment Routing case, otherwise, we have to co-work
with SPRING WG for this draft.

Section 3, line 188
MPLS label is originally designed to be a locally unique label. But this
draft propose the label to be globally unique. That will bring many new
things, e.g., label management complexity, label space limitation, etc.
Could we achieve the purpose of Performance Measurement by other way, e.g.,
by using psuedowire between two endpoints.

Section 4.1, line 236
My concern here is, is it valuable to get the measurement of a P2P path
within a MP2P path (in section 1, you said, MP2P is a problem). The
performance you get at one time for this P2P path is surely influenced by
other P2P path of the same MP2P path. Keep in mind that the LSP label
tested is also shared by other P2P LSP within same MP2P LSP.
If you really want the MPLS path performance between two endpoints in LDP
environment, suggest to use PW instead.

Section 6.1.1, line 361
I have concern with the signaling mechanism. In a large network, if only
one LSR does not support SLC, then the whole network could not support SLC.
If one LSR changes its SLC status, it will flood to every node. That may
bring some instability to the network, and make the signaling unscalable.
And it maybe possible to optimize the signaling. The SLC status from the
next hop could be used to send upstream, right?

Section 6.1.2, 6.1.2.3
Since RSVP-TE LSP does not have the measurement problem listed in this
draft, why we need to do RSVP-TE extension? MP-BGP is not used to setup
MP2P / MP2MP LSP, then why we need the extension? Did I miss something?

Regards
Lizhong

On Friday, May 2, 2014, Ross Callon <[email-masked]> wrote:

>  Eric, Yimin, Lizhong;
>
> You have been selected as MPLS Review team reviewers for
> draft-chen-mpls-source-label-03.
>
> 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?  Also, is the text and grammar
> understandable (it doesn't need to be perfect at this point, but should be
> reasonably clear). 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 WG
> 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 May 16, 2014?
>
> Thanks, Ross
> (as MPLS WG chair)
>
>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 14 May 2014 17:56:19 +0000

Hi Lizhong,
many thanks for you kind consideration of our work and thoughtful comments. Please find my notes in-line and tagged GIM>>.

                Regards,
                                Greg

From: mpls [mailto:[email-masked]] On Behalf Of Lizhong Jin
Sent: Wednesday, May 14, 2014 8:22 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Ross Callon
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label

Hi authors,
I finished the review, and the text is easy to understandable. I have some technical comments and concerns before adoption. Hope the authors could help to clarify.

Section 1, line 159
Suggest to remove the Segment Routing case, otherwise, we have to co-work with SPRING WG for this draft.
GIM>> As MPLS data plane is in scope of SPRING WG we certainly will ask it to review this document and welcome their comments.

Section 3, line 188
MPLS label is originally designed to be a locally unique label. But this draft propose the label to be globally unique. That will bring many new things, e.g., label management complexity, label space limitation, etc. Could we achieve the purpose of Performance Measurement by other way, e.g., by using psuedowire between two endpoints.
GIM>> Yes, Source Label changes uniqueness scope from local to something else. As Yakov suggests to make explicit statement that Source Label must be unique only within given IGP domain and not globally. I see the point in such definition but would like to discuss it more, get more opinions from the group.

Section 4.1, line 236
My concern here is, is it valuable to get the measurement of a P2P path within a MP2P path (in section 1, you said, MP2P is a problem). The performance you get at one time for this P2P path is surely influenced by other P2P path of the same MP2P path. Keep in mind that the LSP label tested is also shared by other P2P LSP within same MP2P LSP.
If you really want the MPLS path performance between two endpoints in LDP environment, suggest to use PW instead.
GIM>> All performance metrics and performance measurement methods I know been defined for p2p. If we look at MEF’s model for Ethernet S-OAM PM, then for E-LAN it is still p2p measurement.

Section 6.1.1, line 361
I have concern with the signaling mechanism. In a large network, if only one LSR does not support SLC, then the whole network could not support SLC. If one LSR changes its SLC status, it will flood to every node. That may bring some instability to the network, and make the signaling unscalable. And it maybe possible to optimize the signaling. The SLC status from the next hop could be used to send upstream, right?
GIM>> I think that not all LSRs in an IGP domain are required to be SLC but only end-points of an LSP. Thus, if an LSR is not SLC, then SL cannot be used on LSPs it originates/terminates. Change in SLC, I imagine, may come as result of SW upgrade. Though it would trigged flood of updates that, IMO, would be one-time event.

Section 6.1.2, 6.1.2.3
Since RSVP-TE LSP does not have the measurement problem listed in this draft, why we need to do RSVP-TE extension? MP-BGP is not used to setup MP2P / MP2MP LSP, then why we need the extension? Did I miss something?
GIM>> I think that RSVP-TE LSP with label merge and PHP still have issues described in the document. Perhaps only MPLS-TP constructs have determinism of transport network and may not have this problem.

Regards
Lizhong

On Friday, May 2, 2014, Ross Callon <[email-masked]<mailto:[email-masked]>> wrote:
Eric, Yimin, Lizhong;

You have been selected as MPLS Review team reviewers for draft-chen-mpls-source-label-03.

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?  Also, is the text and grammar understandable (it doesn't need to be perfect at this point, but should be reasonably clear). 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 WG secretary, and CC'd to the MPLS WG email list. If necessary, Comments may be sent privately to only the WG chairs.

Thanks, Ross
(as MPLS WG chair)

---

From: Lizhong Jin <[email-masked]>
Date: Thu, 15 May 2014 22:57:47 +0800

Hi Greg,

Thanks for the reply. See more inline below.

Regards

Lizhong

On Thursday, May 15, 2014, Gregory Mirsky <[email-masked]>
wrote:

>  Hi Lizhong,
>
> many thanks for you kind consideration of our work and thoughtful
> comments. Please find my notes in-line and tagged GIM>>.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* mpls [mailto:[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> *On Behalf Of *Lizhong Jin
> *Sent:* Wednesday, May 14, 2014 8:22 AM
> *To:* [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *Cc:* [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>;
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>; Ross Callon
> *Subject:* Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label
>
>
>
> Hi authors,
>
> GIM>> As MPLS data plane is in scope of SPRING WG we certainly will ask it
> to review this document and welcome their comments.
>
>
>
> Section 3, line 188
>
> GIM>> Yes, Source Label changes uniqueness scope from local to something
> else. As Yakov suggests to make explicit statement that Source Label must
> be unique only within given IGP domain and not globally. I see the point in
> such definition but would like to discuss it more, get more opinions from
> the group.
>
>
>
> Section 4.1, line 236
>
> GIM>> All performance metrics and performance measurement methods I know
> been defined for p2p. If we look at MEF’s model for Ethernet S-OAM PM, then
> for E-LAN it is still p2p measurement.
>
>
>
> Section 6.1.1, line 361
>
> GIM>> I think that not all LSRs in an IGP domain are required to be SLC
> but only end-points of an LSP. Thus, if an LSR is not SLC, then SL cannot
> be used on LSPs it originates/terminates. Change in SLC, I imagine, may
> come as result of SW upgrade. Though it would trigged flood of updates
> that, IMO, would be one-time event.
>
[Lizhong] in an LDP network, every node would be possibly to be egress of
an FEC. In the draft, it says:
An LSR X may receive multiple Label Mappings for a given

   FEC F from its neighbors.  In its turn, X may advertise a Label
   Mapping for F to its neighbors.  If X understands the SLC TLV, and if
   any of the advertisements it received for FEC F does not include the
   SLC TLV, X MUST NOT include the SLC TLV in its own advertisements of
   F.

In DU mode, the mapping advertisement will be influenced by other received
advertisement, which will bring more signaling. This is not one-time event,
any LDP session UP/DOWN will influence the whole signaling. But why don't
you limit the received advertisement only from the downstream node, not all
nodes? Only the received advertisement from downstream node does not SLC
TLV, X must not include SLC TLV.

 Section 6.1.2, 6.1.2.3
> GIM>> I think that RSVP-TE LSP with label merge and PHP still have issues
> described in the document. Perhaps only MPLS-TP constructs have determinism
> of transport network and may not have this problem.
>
[Lizhong] PHP could be disabled for RSVP-TE LSP. Which case has label merge
for RSVP-TE LSP? Anyway, if you think RSVP-TE also has issue, you should
say that in section 1. However, using source label to do LM for RSVP-TE LSP
may not be helpful, since the RSVP-TE label is more accurate to identify an
LSP, including source + destination + tunnel ID + LSP ID + PHB, etc.

>
>
> Regards
>
> Lizhong
>
>
>
>
> On Friday, May 2, 2014, Ross Callon <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> wrote:
>
> Eric, Yimin, Lizhong;
>
>
>

---

From: Ross Callon <[email-masked]>
Date: Thu, 15 May 2014 15:50:39 +0000

>> GIM>> As MPLS data plane is in scope of SPRING WG we certainly will ask it to review this document and welcome their comments.

The SPRING WG chairs are already aware of this document. I intend to notify them when we call this document for WG adoption, and again at WG last call.

Thanks, Ross

From: Lizhong Jin [mailto:[email-masked]]
Sent: Thursday, May 15, 2014 10:58 AM
To: Gregory Mirsky
Cc: [email-masked]; [email-masked]; [email-masked]; Ross Callon
Subject: Re: MPLS-RT review of draft-chen-mpls-source-label

Hi Greg,

Regards

Lizhong

On Thursday, May 15, 2014, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Lizhong,
many thanks for you kind consideration of our work and thoughtful comments. Please find my notes in-line and tagged GIM>>.

                Regards,
                                Greg

From: mpls [mailto:[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>] On Behalf Of Lizhong Jin
Sent: Wednesday, May 14, 2014 8:22 AM
To: [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
Cc: [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>; [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>; Ross Callon
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label

Hi authors,

Section 1, line 159

Section 3, line 188

Section 4.1, line 236

Section 6.1.1, line 361
I have concern with the signaling mechanism. In a large network, if only one LSR does not support SLC, then the whole network could not support SLC. If one LSR changes its SLC status, it will flood to every node. That may bring some instability to the network, and make the signaling unscalable. And it maybe possible to optimize the signaling. The SLC status from the next hop could be used to send upstream, right?
GIM>> I think that not all LSRs in an IGP domain are required to be SLC but only end-points of an LSP. Thus, if an LSR is not SLC, then SL cannot be used on LSPs it originates/terminates. Change in SLC, I imagine, may come as result of SW upgrade. Though it would trigged flood of updates that, IMO, would be one-time event.
[Lizhong] in an LDP network, every node would be possibly to be egress of an FEC. In the draft, it says:
An LSR X may receive multiple Label Mappings for a given

In DU mode, the mapping advertisement will be influenced by other received advertisement, which will bring more signaling. This is not one-time event, any LDP session UP/DOWN will influence the whole signaling. But why don't you limit the received advertisement only from the downstream node, not all nodes? Only the received advertisement from downstream node does not SLC TLV, X must not include SLC TLV.

Section 6.1.2, 6.1.2.3
Since RSVP-TE LSP does not have the measurement problem listed in this draft, why we need to do RSVP-TE extension? MP-BGP is not used to setup MP2P / MP2MP LSP, then why we need the extension? Did I miss something?
GIM>> I think that RSVP-TE LSP with label merge and PHP still have issues described in the document. Perhaps only MPLS-TP constructs have determinism of transport network and may not have this problem.
[Lizhong] PHP could be disabled for RSVP-TE LSP. Which case has label merge for RSVP-TE LSP? Anyway, if you think RSVP-TE also has issue, you should say that in section 1. However, using source label to do LM for RSVP-TE LSP may not be helpful, since the RSVP-TE label is more accurate to identify an LSP, including source + destination + tunnel ID + LSP ID + PHB, etc.

Regards
Lizhong

On Friday, May 2, 2014, Ross Callon <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
Eric, Yimin, Lizhong;

Thanks, Ross
(as MPLS WG chair)

---

From: Mach Chen <[email-masked]>
Date: Fri, 16 May 2014 09:10:04 +0000

Hi Lizhong,

Thanks for your comments!

See my reply inline...

Sniped.

> GIM>> I think that not all LSRs in an IGP domain are required to be 
> GIM>> SLC but only
> end-points of an LSP. Thus, if an LSR is not SLC, then SL cannot be 
> used on LSPs it originates/terminates. Change in SLC, I imagine, may 
> In DU mode, the mapping advertisement will be influenced by other 
> received advertisement, which will bring more signaling. This is not 
> one-time event, any LDP session UP/DOWN will influence the whole 
> signaling. But why don't you limit the received advertisement only 
> from the downstream node, not all nodes? Only the received 
> advertisement from downstream node does not SLC TLV, X must not include SLC TLV.

The above mechanism is originally defined for ELC, and IMHO, from the capability negotiation point of view, there is no different between ELC and SLC. As stated in the Acknowledgements section, the SLC negotiation is referred to ELC negotiation mechanism. 

If you have better suggestion, that will be appreciated. 
  
> draft, why we need to do RSVP-TE extension? MP-BGP is not used to 
> setup MP2P / MP2MP LSP, then why we need the extension? Did I miss something?
> GIM>> I think that RSVP-TE LSP with label merge and PHP still have 
> GIM>> issues
> described in the document. Perhaps only MPLS-TP constructs have 
> determinism of transport network and may not have this problem.
> [Lizhong] PHP could be disabled for RSVP-TE LSP. Which case has label 
> merge for RSVP-TE LSP? Anyway, if you think RSVP-TE also has issue, 
> you should say that in section 1. However, using source label to do LM 
> for RSVP-TE LSP may not be helpful, since the RSVP-TE label is more 
> accurate to identify an LSP, including source + destination + tunnel ID + LSP ID + PHB, etc.

If the PHP is disabled, then source label for RSPV-TE may not be needed. If people think RSVP-TE case is not a valid case, we could remove it.

BTW, please have a look at the last paragraph of section 3 of (http://tools.ietf.org/html/draft-zheng-l3vpn-pm-analysis-02#section-3 ) , it talks a case that even for RSVP-TE, the source label may also needed. 

Thanks,
Mach

> Lizhong

Sniped.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 16 May 2014 10:05:12 +0000

> -----邮件原件-----
> 发件人: Mach Chen [mailto:[email-masked]]
> 发送时间: 2014年5月16日 17:10
> 收件人: Lizhong Jin; Gregory Mirsky
> 抄送: [email-masked]; [email-masked];
> [email-masked]; Ross Callon
> 主题: RE: [mpls] MPLS-RT review of draft-chen-mpls-source-label
> 
> Hi Lizhong,
> 
> > [Lizhong] in an LDP network, every node would be possibly to be egress of an
> FEC.
> > In the draft, it says:
> The above mechanism is originally defined for ELC, and IMHO, from the
> capability negotiation point of view, there is no different between ELC and SLC.
> As stated in the Acknowledgements section, the SLC negotiation is referred to
> ELC negotiation mechanism.
> 

The downstream node could become an upstream node, and vice verse. Therefore, I believe the current description is no problem.

Best regards,
Xiaohu

> If the PHP is disabled, then source label for RSPV-TE may not be needed. If
> people think RSVP-TE case is not a valid case, we could remove it.
> 
> BTW, please have a look at the last paragraph of section 3 of
> (http://tools.ietf.org/html/draft-zheng-l3vpn-pm-analysis-02#section-3 ) , it
> talks a case that even for RSVP-TE, the source label may also needed.
> 
> Thanks,
> Mach
> 
> >
> > Regards
> > Lizhong
> 
> Sniped.

---

From: Lizhong Jin <[email-masked]>
Date: Fri, 16 May 2014 23:13:06 +0800

Hi Mach,
Inline below. Thanks.

Lizhong

On Friday, May 16, 2014, Mach Chen <[email-masked]> wrote:

> > [Lizhong] in an LDP network, every node would be possibly to be egress
> of an FEC.
> > In the draft, it says:
> capability negotiation point of view, there is no different between ELC and
> SLC. As stated in the Acknowledgements section, the SLC negotiation is
> referred to ELC negotiation mechanism.
>
[Lizhong] I know you borrow the text from RFC6790.  My suggestion is, only
when the received advertisement from downstream node (not any node) does
not include SLC TLV, X must not include SLC TLV. That will improve the
signaling, right? The LDP signaling flapping of non-downstream
advertisement will not influence the upstream advertisement.

> If the PHP is disabled, then source label for RSPV-TE may not be needed.
> If people think RSVP-TE case is not a valid case, we could remove it.
>
> BTW, please have a look at the last paragraph of section 3 of (
> http://tools.ietf.org/html/draft-zheng-l3vpn-pm-analysis-02#section-3 ) ,
> it talks a case that even for RSVP-TE, the source label may also needed.
>
[Lizhong] Thanks for the link. What I want to say is, if you believe
RSVP-TE has issue, then explicitly say that in section 1. In current text,
you said, RSVP-TE is OK in section 1, but you still extend RSVP-TE
protocol, that is confusing. And the same issue to MP-BGP extension.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 22 May 2014 10:12:52 +0000

发件人: Lizhong Jin [mailto:[email-masked]]
发送时间: 2014年5月16日 23:13
收件人: Mach Chen
抄送: Gregory Mirsky; [email-masked]; [email-masked]; [email-masked]; Ross Callon
主题: Re: MPLS-RT review of draft-chen-mpls-source-label

Hi Mach,
Inline below. Thanks.

Lizhong

On Friday, May 16, 2014, Mach Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Lizhong,

See my reply inline...

Sniped.

If you have better suggestion, that will be appreciated.
[Lizhong] I know you borrow the text from RFC6790.  My suggestion is, only when the received advertisement from downstream node (not any node) does not include SLC TLV, X must not include SLC TLV. That will improve the signaling, right? The LDP signaling flapping of non-downstream advertisement will not influence the upstream advertisement.

[Xiaohu] SLC TLV is used to indicate whether the egress has the capability of processing the SL. Hence it doesn’t matter whether the SLC TLV is received from a downstream node or a non-downstream node. Since there is a chance that one of the egresses originating that FEC doesn’t support the SLC, it’s safe for X to not include the SLC TLV in its advertisement. Otherwise, the packet with the SL on the fly may be dropped by the egress node w/o the SLC.

BTW, please have a look at the last paragraph of section 3 of (http://tools.ietf.org/html/draft-zheng-l3vpn-pm-analysis-02#section-3 ) , it talks a case that even for RSVP-TE, the source label may also needed.
[Lizhong] Thanks for the link. What I want to say is, if you believe RSVP-TE has issue, then explicitly say that in section 1. In current text, you said, RSVP-TE is OK in section 1, but you still extend RSVP-TE protocol, that is confusing. And the same issue to MP-BGP extension.

Thanks,
Mach

Sniped.