Subject: Re: [mpls] MPLS-RT review of draft-hegde-mpls-spring-epe-oam

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Mon, 2 Mar 2020 10:17:46 +0000

Hello

I have been selected as an MPLS Review Team reviewer for this draft.

I found the document to be clear, well-written and coherent. It does address a problem that needs to be solved.

One technical comment that I have is that the document relies on the ingress LER launching the LSP Ping/Trace knowing the type of every SID along the path of the LSP in order to use the correct TLV in the target FEC stack. This presents a challenge for SR Policy because the path is just a list of SID labels with no type explicitly provided in the definition of the policy. 

This is slightly less of a problem in the case of RFC8287 because the head end node at least knows the details of the top SID.  In the case of EPE SIDs, a controller may learn these downstream SIDs though BGP-LS, but they are not learned directly by the head end node. The controller may or may not provide SID types to the node, but it is not clear what mechanism is available to do this. The draft rather side steps this issue and only provides the following guidance in section 2: "The node initiating the data plane monitoring may acquire the details of EPE-SIDs through BGP-LS advertisements...".  This statement should contain more detail about how this works (given that it is the controller that learns though BGP-LS), and what alternatives exist if the controller does not provide the SID types to the initiating node e.g. use of a NIL FEC type. An alternative would be to be more explicit that this is a gap which is out of scope of this draft and explicitly state that the mechanism that the initiating node learns the details of the EPE SIDs is out of scope. 

Best regards

Matthew

[email-masked] <[email-masked]>

On 14/02/2020, 04:52, "Loa Andersson" <[email-masked]> wrote:

    Mathew, Sam, Sasha and Italo,
    
    You have be selected as MPLS-RT reviewers for
    draft-hegde-mpls-spring-epe-oam.
    
    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
    WG secretary, and CC'd to the MPLS WG email list. If necessary, comments
    may be sent privately to only the WG chairs.
    
    If you have technical comments you should try to be explicit about what
    *really* need to be resolved before adopting it as a working group
    document, and what can wait until the document is a working group
    document and the working group has the revision control.
    
    Are you able to review this draft by Feb 28, 2020? Please respond in a
    timely fashion.

    Thanks, Loa
    (as MPLS WG chair)
    -- 
    -- 

    Loa Andersson                        email: [email-masked]
    Senior MPLS Expert
    Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 6 Mar 2020 10:04:18 +0000

Sasha,

Pls see inline..

From: Alexander Vainshtein <[email-masked]>
Sent: Tuesday, February 25, 2020 4:52 PM
To: Shraddha Hegde <[email-masked]>
Cc: [email-masked]; Mach Chen <[email-masked]>; [email-masked]
Subject: RE: MPLS-RT review of draft-hegde-mpls-spring-epe-oam

Shraddha,
Lots of thanks for a detailed response to my comments and a new version of the draft that addresses most of them.

Please see also some responses inline below. Hopefully they will be useful.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

From: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Sent: Monday, February 24, 2020 6:56 PM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Mach Chen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: MPLS-RT review of draft-hegde-mpls-spring-epe-oam

Hi Sasha,

Thanks for the review. Pls see inline for replies

Rgds
Shraddha

From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 18, 2020 5:34 PM
To: [email-masked]<mailto:[email-masked]>; Mach Chen <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: MPLS-RT review of draft-hegde-mpls-spring-epe-oam

Hello,

I have been selected as one of the  MPLS-RT reviewers of draft-hegde-mpls-spring-epe-oam.

This review presumably is part of the process of adoption of this draft as an MPLS WG document, and should answer the following questions:

  1.  Does this draft address a real problem?
  2.  Is the current version a reasonably good start for solving this problem?
  3.  Are there any issues that must be fixed prior to adoption of the draft as a WG document?

After reading the draft I think that the answers to questions (1) and (2) above are positive.

I have a couple of technical issues with the draft listed below.

  1.  All sub-TLVs defined in the draft include lists of pair of local and remote IPv4 or IPv6 addresses describing links between the advertising node and the eBGP neighbor for which the EPE SID is advertised.
     *   I wonder if link-local IPv6 addresses are acceptable in these lists

              <shraddha> draft-ietf-idr-bgpls-segment-routing-epe does not explicitly specify whether link local addresses are included.

From BGP protocol perspective I do not see any problem with including link local addresses. I have updated this draft to include link-local ipv6 addresses.

[[Sasha]] What the updated draft says is that link-local IPv6 addresses are allowed. But these addresses do not identify the interfaces on which they appear, so I doubt such a clarification is enough.  I think that if link-local IPv6 addresses are used, it should be possible to include some form of identifying the underlying interfaces following RFC 4007. Alternatively, you can say that link-local addresses are left FFS.

<Shraddha> ok will update next version for link-local addresses being FFS.

     *   I also wonder how unnumbered P2P IPv4 interfaces could be specified in these lists.

             <Shraddha> unnumbered p2p interfaces are out of scope. I have updated the document with this information[[Sasha]] OK with me.

  1.  All sub-TLVs defined in the draft include, as one of their files the field “Local AS” that is always defined as ”4 octet unsigned integer representing the Member ASN inside the Confederation”. I wonder if this definition equally applies to the case when the so-called “Local AS” mechanism defined in RFC 7705<https://urldefense.com/v3/__https:/clicktime.symantec.com/3KS3q9GHjbBnYp1G2Rk8Z3w6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fhtml*2Frfc7705__*3B*21*21NEt6yMaO-gk*21VXfhq4-7vne-Eba0WNolAQzJH-fEDF07GOqv-Q6SasdjBzZEdG6DQXAcVwjnSv1I*24__;JSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!Qi-KLen-84_SrjwPfEwqcbJ-dasxKJtTTT3cvlBG7t7mQitOuEF4j8xZJRlVLjrr$> is used vs. a specific eBGP peer. In these scenarios the number of the AS to which the node that advertises an EPE SID differs from the AS number that this node uses in its OPEN message to the specific neighbor.

           <Shraddha> This is a good point draft draft-ietf-idr-bgpls-segment-routing-epe does not talk about RFC 7705 and does not include MUST statements to indicate what should be sent if migration with RFC 7705 is in force. Although I personally think that it should be possible to support OAM when RFC 7705 is in force by including the AS numbers from “local AS”, it should be specified clearly in draft

draft-ietf-idr-bgpls-segment-routing-epe and this document should just inherit from draft-ietf-idr-bgpls-segment-routing-epe. It may be too late to update draft-ietf-idr-bgpls-segment-routing-epe as its already in RFC editor queue. For now I have updated OAM draft and mentioned that if RFC 7705 is in force and if global AS number is sent, remote node may fail the validation [[Sasha]] OK with me.

Looking for feedback if there is a better way to handle this.

  1.  The document states in Section 1 that “Other procedures for mpls ping and traceroute as defined in [RFC8287<https://urldefense.com/v3/__https:/clicktime.symantec.com/365NBZRjaAtFck4LPHPDaZb6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fhtml*2Frfc8287__*3B*21*21NEt6yMaO-gk*21VXfhq4-7vne-Eba0WNolAQzJH-fEDF07GOqv-Q6SasdjBzZEdG6DQXAcVx_5oIeQ*24__;JSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!Qi-KLen-84_SrjwPfEwqcbJ-dasxKJtTTT3cvlBG7t7mQitOuEF4j8xZJcPy_Qdi$>] are applicable for EPE-SIDs as well”.
     *   Such a blank statement requires some clarification IMHO

<shraddha> referred section 7 of RFC 8287

     *   Specifically, RFC 8287 states in Section that the Traceroute initiator, upon receiving an MPLS Echo Reply message that includes the FEC Stack Change TLV with one or more of the original segments being popped “MAY remove a corresponding FEC(s) from the Target FEC          Stack TLV in the next (TTL+1) traceroute request”. I wonder if, in the case of EPE SIDs, MAY requirement should not be upgraded to SHOULD or even MUST for security reasons

<shraddha> This is up for discussion.If the FEC stack is not removed, it exposes the details of the previous AS and hence the security risk.

This usecase is applicable when the involved ASes belong to same operator so keeping MAY  might be ok. I am looking for input from WG.

[[Sasha]] Waiting for the WG input is, of course, OK with me. However:

  *    We seem to agree that this may be a security risk, but I have not found anything in the Security Considerations section about this risk
  *   FWIW, I prefer to be prepared and not to wait for DISCUSS be raised by the Security ADs:-). Adding some text that describes this risk and the way to mitigate it could help to avoid this IMHO.

<Shraddha> For now, updated security consideration section with this information. We can add normative language

Based on WG input later.

Neither of the issues mentioned above looks to be as blocking WG adoption of the draft. They can safely be resolved after adoption.

Hopefully this review will be useful.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: Loa Andersson <[email-masked]<mailto:[email-masked]>>
Sent: Friday, February 14, 2020 6:53 AM
To: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Sam Aldrin <[email-masked]<mailto:[email-masked]>>; Italo Busi <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: MPLS-RT review of draft-hegde-mpls-spring-epe-oam

You have be selected as MPLS-RT reviewers for draft-hegde-mpls-spring-epe-oam.

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 WG secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs.

*really* need to be resolved before adopting it as a working group document, and what can wait until the document is a working group document and the working group has the revision control.

Are you able to review this draft by Feb 28, 2020? Please respond in a timely fashion.

Thanks, Loa

(as MPLS WG chair)

--

--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>

Senior MPLS Expert

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 6 Mar 2020 10:42:27 +0000

Hi Italo,

Thanks for review and comments. Pls see inline…

From: Italo Busi <[email-masked]>
Sent: Wednesday, February 26, 2020 10:30 PM
To: [email-masked]; [email-masked]; Mach Chen <[email-masked]>
Cc: [email-masked]; Bocci, Matthew (Nokia - GB) <[email-masked]>; Alexander Vainshtein <[email-masked]>; Sam Aldrin <[email-masked]>
Subject: RE: MPLS-RT review of draft-hegde-mpls-spring-epe-oam

Hi all,

I have reviewed the latest version of the draft which has been published two days ago (draft-hegde-mpls-spring-epe-oam-05).

I think that the document is coherent, is it useful (i.e., it addresses a real need for operational networks), and it is technically sound.

Therefore, I think that the draft is ready to be adopted as a WG document.

I have few comments that can be addressed either before or after WG adoption.

1.       The Introduction mentions the procedures defined in section 7 of RFC8287 and clarified by RFC8690.

My understanding is that RFC8690 clarifies how to use the length field with the sub-TLVs defined in section 5 of RFC8287 and therefore it is not strictly applicable to this draft.
<shraddha> yes. You are right. I updated this sentence and referred 8690 based on comment that 8287
Has an important clarification in RFC 8690 so it should be reference.

However, it would be worthwhile clarifying in section 4 of this draft how the length field should be set for the EPE SID sub-TLVs. An example would also be useful.
<shraddha> yes updated the draft.

2.       I guess that all the information elements used in the sub-TLVs defined in section 4 of this draft are those defined in draft-ietf-idr-bgpls-segment-routing-epe.
<Shraddha> Yes.

It would be worthwhile to reference draft-ietf-idr-bgpls-segment-routing-epe for these definitions.
<Shraddha> yes, normative reference added.

I guess this would also help resolving comment #1 from Sasha on link-local IPv6 addresses and unnumbered interfaces: whatever is supported by draft-ietf-idr-bgpls-segment-routing-epe should be also supported by this draft (and vice versa)
<shraddha> updated with link-local addresses FFS.

3.       In Figure 2, the “No.of IPv6 interface pairs” field seems a bit redundant since the information can be inferred from the “Length” and “No.of IPv4 interface pairs ” fields
<shraddha> Since IPv4 and ipv6 address pair may be present simultaneously, we need this field.

This is ok for me but please add some text to clarify whether the receiver should/shall perform some validation check
 <shraddha> sure will add new section in next revision.
4.       Figure 3 is not fully clear

If I understand well, the “Remote As Number”, “Remote BGP Router ID”, “No.of IPv4 interface pairs”, … fields are repeated for each element in the set.
<Shraddha> yes, these elements are repeated for each set.

It may be worthwhile to split the figure into two: one describing the TLV containing one or more “elements” and one describing the fields used in each element.
<Shraddha> Yes. updated

5.       In Figure 6, the “No.of elements in set” field as well as the “No.of IPv6 interface pairs” field of the last element in the set seem a bit redundant since the information can be inferred from the “Length” and “No.of IPv4 interface pairs ” of the last element in the set fields
<Shraddha>Since both IPv4 and IPv6 addresses pairs may be present simultaneously, number of pairs field is required.

As for comment #3 above, this is ok for me but please add some text to clarify whether the receiver should/shall perform some validation check
 <shraddha> sure will add new section in next revision.
Italo

> From: Loa Andersson [mailto:[email-masked]]
> Sent: venerdì 14 febbraio 2020 05:53
> To: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>; Alexander
> Vainshtein <[email-masked]<mailto:[email-masked]>>; Sam Aldrin
> <[email-masked]<mailto:[email-masked]>>; Italo Busi <[email-masked]<mailto:[email-masked]>>
> 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 WG
> secretary, and CC'd to the MPLS WG email list. If necessary, comments may be
> sent privately to only the WG chairs.
>
> *really* need to be resolved before adopting it as a working group document,
> and what can wait until the document is a working group document and the
> working group has the revision control.
>

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 6 Mar 2020 10:50:19 +0000

Hi Bocci,

Thanks for the review and comments.

-----Original Message-----
From: Bocci, Matthew (Nokia - GB) <[email-masked]> 
Sent: Monday, March 2, 2020 3:48 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: MPLS-RT review of draft-hegde-mpls-spring-epe-oam

Hello

One technical comment that I have is that the document relies on the ingress LER launching the LSP Ping/Trace knowing the type of every SID along the path of the LSP in order to use the correct TLV in the target FEC stack. This presents a challenge for SR Policy because the path is just a list of SID labels with no type explicitly provided in the definition of the policy. 
<Shraddha> head-end node can also use BGP-LS with ASBR to learn the EPE-SIDs and the FEC can be built .
"Theory of operation" section talks about this.
I will add absence of the SID details in PCEP and BGP-SR-TE extensions and that being out of scope of this draft. 

This is slightly less of a problem in the case of RFC8287 because the head end node at least knows the details of the top SID.  In the case of EPE SIDs, a controller may learn these downstream SIDs though BGP-LS, 

but they are not learned directly by the head end node. 

<shraddha> head-end can also learn via BGP-LS sessions to ASBRs.

The controller may or may not provide SID types to the node, but it is not clear what mechanism is available to do this. The draft rather side steps this issue and only provides the following guidance in section 2: "The node initiating the data plane monitoring may acquire the details of EPE-SIDs through BGP-LS advertisements...".  This statement should contain more detail about how this works (given that it is the controller that learns though BGP-LS), and what alternatives exist if the controller does not provide the SID types to the initiating node e.g. use of a NIL FEC type. An alternative would be to be more explicit that this is a gap which is out of scope of this draft and explicitly state that the mechanism that the initiating node learns the details of the EPE SIDs is out of scope. 
<shraddha> I'll add text that other mechanisms of learning SID details from controller may be used and it is out of scope for this draft.

Best regards

Matthew

    

    

    Thanks, Loa
    (as MPLS WG chair)
    -- 
    --

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 6 Mar 2020 12:04:24 +0000

Shraddha,
Looks OK.
Lots of thanks for handling these issues.

Regards,
Sasha

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Shraddha Hegde <[email-masked]>
Sent: Friday, March 6, 2020, 12:04
To: Alexander Vainshtein
Cc: [email-masked]; Mach Chen; [email-masked]
Subject: RE: MPLS-RT review of draft-hegde-mpls-spring-epe-oam

Sasha,

Pls see inline..

Shraddha,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Rgds
Shraddha

Hello,

  1.  All sub-TLVs defined in the draft include, as one of their files the field “Local AS” that is always defined as ”4 octet unsigned integer representing the Member ASN inside the Confederation”. I wonder if this definition equally applies to the case when the so-called “Local AS” mechanism defined in RFC 7705<https://clicktime.symantec.com/3UrmDD9qH6VKjx5W1DD8WRi6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3KS3q9GHjbBnYp1G2Rk8Z3w6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Ftools.ietf.org%2A2Fhtml%2A2Frfc7705__%2A3B%2A21%2A21NEt6yMaO-gk%2A21VXfhq4-7vne-Eba0WNolAQzJH-fEDF07GOqv-Q6SasdjBzZEdG6DQXAcVwjnSv1I%2A24__%3BJSUlJSUlJSUlJSUlJSU%21%21NEt6yMaO-gk%21Qi-KLen-84_SrjwPfEwqcbJ-dasxKJtTTT3cvlBG7t7mQitOuEF4j8xZJRlVLjrr%24> is used vs. a specific eBGP peer. In these scenarios the number of the AS to which the node that advertises an EPE SID differs from the AS number that this node uses in its OPEN message to the specific neighbor.

  1.  The document states in Section 1 that “Other procedures for mpls ping and traceroute as defined in [RFC8287<https://clicktime.symantec.com/3PrDpjCNUzzQR6HJ44VNcG6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F365NBZRjaAtFck4LPHPDaZb6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Ftools.ietf.org%2A2Fhtml%2A2Frfc8287__%2A3B%2A21%2A21NEt6yMaO-gk%2A21VXfhq4-7vne-Eba0WNolAQzJH-fEDF07GOqv-Q6SasdjBzZEdG6DQXAcVx_5oIeQ%2A24__%3BJSUlJSUlJSUlJSUlJSU%21%21NEt6yMaO-gk%21Qi-KLen-84_SrjwPfEwqcbJ-dasxKJtTTT3cvlBG7t7mQitOuEF4j8xZJcPy_Qdi%24>] are applicable for EPE-SIDs as well”.
     *   Such a blank statement requires some clarification IMHO

Based on WG input later.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Loa Andersson <[email-masked]<mailto:[email-masked]>>
Sent: Friday, February 14, 2020 6:53 AM
To: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Sam Aldrin <[email-masked]<mailto:[email-masked]>>; Italo Busi <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: MPLS-RT review of draft-hegde-mpls-spring-epe-oam

Thanks, Loa

(as MPLS WG chair)

--

--

Senior MPLS Expert