Subject: Re: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

From: Shraddha Hegde <[email-masked]>
Date: Wed, 3 Jun 2020 06:02:29 +0000

Hi Dhruv,

Thanks for the review and comments. Pls see inline

Juniper Business Use Only

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: Tuesday, May 12, 2020 1:31 PM
To: Loa Andersson <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

[External Email. Be cautious of content]

Hi Loa, WG,

I support the adoption of this work, it provides a useful functionality that has been described well enough to be adopted by the WG.

I do have a few suggestions and nits that the authors could take up later -

--

- I suggest adding a few more lines to build some context in your Introduction section, the current text works for someone in the know-how of MPLS-OAM/SR but fails to provide context for a general reader.
<shraddha> Sure. -07 will address this

- I suggest to expand the text in section 4, to clearly state that this I-D is further specifying 3 more new sub-TLVs and also which TLVs would carry these sub-TLVs etc.
<Shraddha> yes. -07 will address this

- Some of the references mentioned as Informative are more suitable as Normative, namely - [I-D.ietf-spring-segment-routing-central-epe], RFC 2119, RFC 8174, RFC 8690 (?)
<shraddha> I have moved RFC 2119, RFC 8174, RFC 8690 To normative but I-D.ietf-spring-segment-routing-central-epe Doesn't seem to be normative. The IDR protocol extension for BGP-EPE is already a normative document.

Nits
- Abstract, you expand Segment Identifiers (SID) NOT on first use but much later.
- Introduction, s/mpls/MPLS (multiple places)
- Section 2, s/e-BGP/EBGP (as per RFC Editor abbreviation preference)
- Section 4.1, Change ipv4/ipv6 to IPv4/IPv6 (multiple places)
- Section 4.1, Expand FFS!
- Section 5, s/SHOuLD/SHOULD
- Section 5, fix the over-running lines (exceeding 80 chars)

--
<shraddha> Thanks for catching these. Will address all of them in -07
Regards,
Dhruv

On Thu, Apr 30, 2020 at 8:27 AM Loa Andersson <[email-masked]> wrote:
>
> Working Group,
>
> This is to start a two week poll on adopting 
> draft-hegde-mpls-spring-epe-oam as a MPLS working group document.
>
> Please send your comments (support/not support) to the mpls working 
> group mailing list ([email-masked]). Please give a technical motivation 
> for your support/not support, especially if you think that the 
> document should not be adopted as a working group document.
>
> There is one IPR disclosure against this document.
>
> The authors have stated on the MPLS wg mailing list that they are 
> unaware of any IPRs that relates to this document.
>
> The working group adoption poll ends May 15, 2020.
>
> /Loa
> --
>
> My mail server it under a DOS attack, we are working to fix it but it 
> may take some time.
>
>
> Loa Andersson                        email: [email-masked]
> Senior MPLS Expert
> Bronze Dragon Consulting             phone: +46 739 81 21 64
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls
> __;!!NEt6yMaO-gk!QuF1vXKGokb2IcgR-VF6pRxK2p1Cd9bR5yomBlNiRpKzR75-DFco5
> 20tuchQkvLp$

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 3 Jun 2020 06:18:59 +0000

Hi ketan,

Thanks for the detailed review and comments. Pls see inline for response.

-----Original Message-----
From: Ketan Talaulikar (ketant) <[email-masked]> 
Sent: Wednesday, May 13, 2020 9:38 AM
To: Loa Andersson <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

Hi  Loa,

There is no doubt about the need for LSP ping and traceroute operations to cover BGP EPE SIDs. So the requirement is real and something that the WG should be taking up.

My concerns is that the proposal in the draft is diverging from the control plane protocol semantics for what constitutes the FEC (or context) and how it is to be validated. These are some core aspects that IMHO need to be addressed before adoption while the rest may be taken up during its life as a WG document. I would suggest to wait for the authors response.

Thanks,
Ketan

-----Original Message-----
From: Loa Andersson <[email-masked]>
Sent: 13 May 2020 09:22
To: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

Ketan,

Anything of this that need to addressed before wg adoption?

Authors

I leave the wgap opeb a few extra days to llow you to respond to this.

/Loa

On 12/05/2020 23:32, Ketan Talaulikar (ketant) wrote:
> Hello Authors,
>
> I have the following comments on this draft and would be good if you could clarify/respond.
>
> 1)The FEC description should match the "context" that is advertised in 
> the control plane for Peer Adj SID. E.g. the local/remote Interface 
> IDs are not being included from 
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-idr
> -bgpls-segment-routing-epe-1__;!!NEt6yMaO-gk!W0-Gp88WKnqRfX4kdfeWV8aIH
> qrXTj0Pzz9Vl-B2ZVn78SFO60XGBDi2Y-5xIny8$
> 9#section-4.2

<Shraddha> The EPE draft mandates interface-ids and allows remote interface-id to be zero.
Remote interface ID being zero does not help in validating the incoming interface which is very
Useful OAM functionality. For this reason, this draft recommends sending interface addresses in the PeerADJ SID
Link descriptors which is optional. 

I have updated the PeerAdj SID section with this information and also updated with the possibility of sending zero
In which case incoming interface validation should be skipped. This is to accommodate cases when the advertising node does not send the interface addresses
>
> 2) For the Peer Node SID, the control plane definition is https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-19*section-4.1__;Iw!!NEt6yMaO-gk!W0-Gp88WKnqRfX4kdfeWV8aIHqrXTj0Pzz9Vl-B2ZVn78SFO60XGBDi2Y6sXdlcY$  and the FEC description in this draft is not aligned with the corresponding control plane. The Peer Node SID is meant for the packet to be delivered to a specific BGP peer and it does not matter over which interface it is received. So why have those interface addresses as mandatory in the FEC. The only thing the control plane indicates is the peering session itself.
>
> 3) Same as (2) above, for the Peer Set SID, the interfaces are don't care.
<Shraddha> The reason for need to have interface addresses specified is for incoming interface validation as explained above. For Peer Node SID interfaces are advertised with draft I-D.hegde-idr-bgp-ls-epe-inter-as.I have added this to the reference and updated text as to why it is needed. Also the ingress can send 0 pair of addresses in which case
Incoming interface validation will be skipped and success will be sent based on other validations.
Pls check -07 version and let me know if you are OK with it.
>
> 4) The draft just says that the procedures are borrowed from RFC8287 but I don't think this is so straightforward or trivial. E.g. https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8287*section-7.2__;Iw!!NEt6yMaO-gk!W0-Gp88WKnqRfX4kdfeWV8aIHqrXTj0Pzz9Vl-B2ZVn78SFO60XGBDi2Y3Z0DrZ_$  has the following:
>
>     The network node that is immediately downstream of the node that
>     advertised the Adjacency Segment ID is responsible for generating the
>     FEC Stack Change sub-TLV for POP operation for the Adjacency Segment
>     ID.
>

<shraddha> A new section for EPE FEC validation has been added in -06 version. This section specifies the details when return code 3 
Has to be sent. As per  RFC 8029 sec 3.4.1.3 FEC stack change and IS_EGRESS code are treated identically.
" A Downstream Detailed Mapping TLV containing only one FEC stack
       change sub-TLV with pop operation is equivalent to IS_EGRESS
       (Return Code 3, Section 3.1) for the outermost FEC in the FEC
       stack.  The ingress router performing the LSP traceroute MUST
       treat such a case as an IS_EGRESS for the outermost FEC."

I don't see the need to re-iterate RFC 8029 sections in this draft. If it is still not clear let me know.

> In the case of IGPs, the downstream node does have the label and context for adjacency SID (which is functionally closest to BGP EPE SIDs). In the BGP-EPE SIDs case, this is not always the case. So I believe, it would be better if the entire operation were described.
<Shraddha> EPE SID validation section is added. Pls take a look and let me know if it looks good.
>
> 5) The ping or traceroute done to any of the BGP EPE SID corresponding to an eBGP session may result in the packet being sent to another entity. The security consideration talk about it, but the problem is not addressed by the remote AS dropping the packets. The security issue is that the OAM packet could expose the FECs and information of the local AS to a remote AS. So it is more as an caveat for the operators performing the OAM operation to be mindful of this fact.
>
<Shraddha> Yes. This was raised in RT review and security section has been updated with this info in -06 version.
   
> In general, some more description that set the stage for the introduction of the new extensions and elaborate more on the operations (some considerations above on what is mandatory to evaluate and what is optional).
<Shraddha> Sure. Pls check the -07 version which I'll be posting soon and let me know if you have further comments.
> Thanks,
> Ketan
> From: mpls <[email-masked]> On Behalf Of Loa Andersson
> Sent: 30 April 2020 08:26
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [mpls] working group adaption poll (wgap) for 
> draft-hegde-mpls-spring-epe-oam
>
> Working Group,
>
> This is to start a two week poll on adopting draft-hegde-mpls-spring-epe-oam as a MPLS working group document.
>
> Please send your comments (support/not support) to the mpls working group mailing list ([email-masked]). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document.
>
> The authors have stated on the MPLS wg mailing list that they are unaware of any IPRs that relates to this document.
>

--

My mail server from time to time has come under DOS attacks, we are working to fix it but it may take some time. If you get denial of service sending to me plz try to use loa.pi.nu@gmail

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 3 Jun 2020 09:17:33 +0000

Hi Shraddha,

Thanks for your response and update. Please check inline below.

-----Original Message-----
From: Shraddha Hegde <[email-masked]>
Sent: 03 June 2020 11:49
To: Ketan Talaulikar (ketant) <[email-masked]>; Loa Andersson <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

Hi ketan,

-----Original Message-----

From: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>

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

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi  Loa,

Thanks,

Ketan

-----Original Message-----

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

Sent: 13 May 2020 09:22

To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Ketan,

Authors

/Loa

> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-idr<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-idr>

Remote interface ID being zero does not help in validating the incoming interface which is very Useful OAM functionality. For this reason, this draft recommends sending interface addresses in the PeerADJ SID Link descriptors which is optional.

I have updated the PeerAdj SID section with this information and also updated with the possibility of sending zero In which case incoming interface validation should be skipped. This is to accommodate cases when the advertising node does not send the interface addresses

[KT] Ack – this sounds good to me. Thanks.

> 2) For the Peer Node SID, the control plane definition is https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-19*section-4.1__;Iw!!NEt6yMaO-gk!W0-Gp88WKnqRfX4kdfeWV8aIHqrXTj0Pzz9Vl-B2ZVn78SFO60XGBDi2Y6sXdlcY$<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-19*section-4.1__;Iw!!NEt6yMaO-gk!W0-Gp88WKnqRfX4kdfeWV8aIHqrXTj0Pzz9Vl-B2ZVn78SFO60XGBDi2Y6sXdlcY$>  and the FEC description in this draft is not aligned with the corresponding control plane. The Peer Node SID is meant for the packet to be delivered to a specific BGP peer and it does not matter over which interface it is received. So why have those interface addresses as mandatory in the FEC. The only thing the control plane indicates is the peering session itself.

> 3) Same as (2) above, for the Peer Set SID, the interfaces are don't care.

<Shraddha> The reason for need to have interface addresses specified is for incoming interface validation as explained above. For Peer Node SID interfaces are advertised with draft I-D.hegde-idr-bgp-ls-epe-inter-as.I have added this to the reference and updated text as to why it is needed. Also the ingress can send 0 pair of addresses in which case Incoming interface validation will be skipped and success will be sent based on other validations.

[KT] I have a concern here. The semantics of the FEC for Peer Node and Set SIDs does not include (i.e. does not care about the interface over which the packet was received). So the link information is in any case part of the response that is sent back to the requester which can perform this validation. I don’t see how it can be included in the FEC definition.

> 4) The draft just says that the procedures are borrowed from RFC8287 but I don't think this is so straightforward or trivial. E.g. https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8287*section-7.2__;Iw!!NEt6yMaO-gk!W0-Gp88WKnqRfX4kdfeWV8aIHqrXTj0Pzz9Vl-B2ZVn78SFO60XGBDi2Y3Z0DrZ_$<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8287*section-7.2__;Iw!!NEt6yMaO-gk!W0-Gp88WKnqRfX4kdfeWV8aIHqrXTj0Pzz9Vl-B2ZVn78SFO60XGBDi2Y3Z0DrZ_$>  has the following:

<shraddha> A new section for EPE FEC validation has been added in -06 version. This section specifies the details when return code 3 Has to be sent. As per  RFC 8029 sec 3.4.1.3 FEC stack change and IS_EGRESS code are treated identically.

[KT] Sure. I think we can work through this once we converge on the FEC definition.

[KT] Same as previous comment.

[KT] Thanks again for the update. I believe we can work through the remaining/open points over course of time.

Thanks,

Ketan

> From: mpls <[email-masked]<mailto:[email-masked]>> On Behalf Of Loa Andersson

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

> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> Please send your comments (support/not support) to the mpls working group mailing list ([email-masked]<mailto:[email-masked]>). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document.

--

My mail server from time to time has come under DOS attacks, we are working to fix it but it may take some time. If you get denial of service sending to me plz try to use loa.pi.nu@gmail<mailto:loa.pi.nu@gmail>

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

Senior MPLS Expert

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 4 Jun 2020 04:48:29 +0000

Hi Ketan,

Snipping open comments..

[KT] I have a concern here. The semantics of the FEC for Peer Node and Set SIDs does not include (i.e. does not care about the interface over which the packet was received). So the link information is in any case part of the response that is sent back to the requester which can perform this validation. I don't see how it can be included in the FEC definition.

<Shraddha>Lets say you have ASBR A connecting two different ASBRs in different ASes B and C. Lets assume there are multiple links between A->B and A->C.

                     Lets say there is a multi-hop eBGP session between A->B  between A->C.

                     Lets say peerNode SID has been advertised for A->B and A->C.  The Link descriptors for the PeerNode Sid include the BGP session local addresses and for a multi-hop BGP

                      BGP session its going to be loopback addresses so from available information, it is not possible to derive which interface the traffic will be flowing.

                      Now lets say  there is a requirement that certain application should use a guaranteed 10G bandwidth on these

                     Inter-as links. If the EPE controller does not know which interfaces the traffic will be flowing, it cannot figure out which peerNodeSID to pick to build the path.

                    Draft-hegde-idr-bgp-ls-epe-inter-as talks about the usecases and required protocol extensions.

                  For any reasonable traffic engineering using peerNodeSID I think that this information is required.

                 It is also useful to know if the control plane and dataplane are in sync with OAM. If the control plane is advertising peerNodeSID to be

                Going over some link but the actual traffic flow is on a different link, it will screw-up the traffic engineering. MPLS WG has built OAM has tools/techniques

                For years to find these kind of problems.We are trying to  apply these to EPE SIDs.

       Rgds
Shraddha

Juniper Business Use Only
From: Ketan Talaulikar (ketant) <[email-masked]>
Sent: Wednesday, June 3, 2020 2:48 PM
To: Shraddha Hegde <[email-masked]>; Loa Andersson <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

Hi Shraddha,

-----Original Message-----
From: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Sent: 03 June 2020 11:49
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Loa Andersson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

Hi ketan,

-----Original Message-----

Hi  Loa,

Thanks,

Ketan

-----Original Message-----

Sent: 13 May 2020 09:22

Ketan,

Authors

/Loa

[KT] Ack - this sounds good to me. Thanks.

[KT] I have a concern here. The semantics of the FEC for Peer Node and Set SIDs does not include (i.e. does not care about the interface over which the packet was received). So the link information is in any case part of the response that is sent back to the requester which can perform this validation. I don't see how it can be included in the FEC definition.

Thanks,

Ketan

--

Senior MPLS Expert

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 4 Jun 2020 06:34:34 +0000

Hi Shraddha,

Trimming further

[KT] This is correct and it is inline with the definition of BGP Peer Node SID per https://tools.ietf.org/html/rfc8402#section-4.2

[KT] For such use-cases (where steering needs to happen over a specific link/adjacency), the EPE controller needs to use the BGP Peer Adjacency SID that does this kind of steering over specific interfaces - again per definition in https://tools.ietf.org/html/rfc8402#section-4.2

[KT] We have been discussing this draft in the past and indeed it tries to enable signalling of additional underlying link information for a multi-hop eBGP neighborship.

[KT] However, for steering over links, we cannot change the semantics of Peer NodeSID which clearly does not put any constraint on the link over which packet is delivered to the BGP peer.

[KT] When multiple underlying links are there between A and B, there are implementation specific or other aspects that may influence whether the traffic goes over a 10G or a 100G link between the nodes. We do have capability in LSP Ping so that C and indicate in it's response the specific link over which it has received the packet from A. This way the actual querier can do verification to check whether the desired local implementation mechanism on A for choosing say the 100G link is working even if the Peer Node SID is being used. However, from a standard's perspective the semantics of Peer Node SID has no notion of interface binding associated with it and hence it cannot be put into its FEC and therefore this verification cannot be expected of C.

Thanks,

Ketan

       Rgds
Shraddha

To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Loa Andersson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Shraddha,

-----Original Message-----
From: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Sent: 03 June 2020 11:49
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Loa Andersson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

Hi ketan,

-----Original Message-----

Hi  Loa,

Thanks,

Ketan

-----Original Message-----

Sent: 13 May 2020 09:22

Ketan,

Authors

/Loa

Thanks,

Ketan

--

Senior MPLS Expert

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 5 Jun 2020 10:13:16 +0000

Ketan,

[KT] For such use-cases (where steering needs to happen over a specific link/adjacency), the EPE controller needs to use the BGP Peer Adjacency SID that does this kind of steering over specific interfaces - again per definition in https://tools.ietf.org/html/rfc8402#section-4.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8402*section-4.2__;Iw!!NEt6yMaO-gk!WwrozmNrEvsg2dRdGFYBwXFu4zD9twHRaNpGhfiP50SYMEoxhG5qiaUA7JOvjsdd$>

The above RFC section you are referring mentions what are PeerAdj SID, PeerNode SID and PeerSet SID. These definitions are matching with what you are saying that if steering on a link is required use PeerAdjSID and if steering on Peer is required use PeerNodeSID. This is good enough description of what is available.

Think about how an EPE controller decides whether it should steer on the link using PeerAdjSID or it should use PeerNodeSID. To make this decision EPE controller needs to have information about link characteristics and which link the traffic is going to take if a path is built using PeerAdjSID/PeerNodeSID and what is the bandwidth availability on those links. This is a fundamental requirement for any kind of traffic-engineering.

This usecase is very much in the scope of Egress Peer Engineering.
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-10 specifies that the problem statement
comes from 7855

"1.1<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-10#section-1.1>.  Problem Statement

The BGP-EPE problem statement is defined in [RFC7855<https://tools.ietf.org/html/rfc7855>]."

7855 lists traffic engineering as one of the main usecase for EPE.

https://tools.ietf.org/html/rfc7855#section-3.3.1

of RFC 7855  clearly describes Traffic Engineering usecases that need to be supported for EPE.

Rgds

Shraddha

Sent: Thursday, June 4, 2020 12:05 PM

Hi Shraddha,

Trimming further

[KT] This is correct and it is inline with the definition of BGP Peer Node SID per https://tools.ietf.org/html/rfc8402#section-4.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8402*section-4.2__;Iw!!NEt6yMaO-gk!WwrozmNrEvsg2dRdGFYBwXFu4zD9twHRaNpGhfiP50SYMEoxhG5qiaUA7JOvjsdd$>

[KT] For such use-cases (where steering needs to happen over a specific link/adjacency), the EPE controller needs to use the BGP Peer Adjacency SID that does this kind of steering over specific interfaces - again per definition in https://tools.ietf.org/html/rfc8402#section-4.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8402*section-4.2__;Iw!!NEt6yMaO-gk!WwrozmNrEvsg2dRdGFYBwXFu4zD9twHRaNpGhfiP50SYMEoxhG5qiaUA7JOvjsdd$>

Thanks,

Ketan

       Rgds
Shraddha

Hi Shraddha,

-----Original Message-----
From: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Sent: 03 June 2020 11:49
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Loa Andersson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

Hi ketan,

-----Original Message-----

Hi  Loa,

Thanks,

Ketan

-----Original Message-----

Sent: 13 May 2020 09:22

Ketan,

Authors

/Loa

Thanks,

Ketan

--

Senior MPLS Expert

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 5 Jun 2020 14:57:39 +0000

Hi Shraddha,

Please check inline below.

Sent: 05 June 2020 15:43

Ketan,

The above RFC section you are referring mentions what are PeerAdj SID, PeerNode SID and PeerSet SID. These definitions are matching with what you are saying that if steering on a link is required use PeerAdjSID and if steering on Peer is required use PeerNodeSID. This is good enough description of what is available.
[KT] Thanks. So as specified, those are the semantics of the three types of SIDs and hence I would request you to please align the FEC definitions and procedures in draft-hegde-mpls-spring-epe-oam with those definitions.

Think about how an EPE controller decides whether it should steer on the link using PeerAdjSID or it should use PeerNodeSID. To make this decision EPE controller needs to have information about link characteristics and which link the traffic is going to take if a path is built using PeerAdjSID/PeerNodeSID and what is the bandwidth availability on those links. This is a fundamental requirement for any kind of traffic-engineering.
[KT] Sure and those specific link attributes can be signaled as part of the Link NLRI that carries the BGP Peer Adj SID since that is the one associated with a specific link (please check https://tools.ietf.org/html/draft-ketant-idr-bgp-ls-bgp-only-fabric-04#section-4.2). Therefore, the PeerAdjSID can be used for steering over a specific link and PeerNodeSID can be used for steering over any link to the peer. This is very similar to AdjSID and PrefixSID in IGPs.

[KT] I believe the use-cases are covered and I would be glad to connect offline to better understand the problem/challenge that you see. If there is something more that needs to be done, I would be happy to collaborate with you. However, since the draft under discussion is about OAM support for BGP EPE SIDs, I do think that we need to follow the semantics and definitions as they are specified in RFC8402 and draft-ietf-idr-bgpls-segment-routing-epe.

Thanks,

Ketan

Rgds

Shraddha

Hi Shraddha,

Trimming further

Thanks,

Ketan

       Rgds
Shraddha

Hi Shraddha,

-----Original Message-----
From: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Sent: 03 June 2020 11:49
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Loa Andersson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

Hi ketan,

-----Original Message-----

Hi  Loa,

Thanks,

Ketan

-----Original Message-----

Sent: 13 May 2020 09:22

Ketan,

Authors

/Loa

Thanks,

Ketan

--

Senior MPLS Expert

---

From: Loa Andersson <[email-masked]>
Date: Sat, 6 Jun 2020 15:13:07 +0800

Working Group,

This wgap is closed and we have a new working group document.

Note: We had quite a bit of discussion on the version (-06) of this 
document that ww polled. The discussion lead to a new version being
posted (-07). We normally don't do this, but in this case we don't think
it is a problem, basically it is transparency and traceability that is
the concern if and when we post a new version during wgap or wglc.

So we are closing the wgap on -06, and working groups chairs are
accepting version -07 as the new working group document.

Can the authors please post:

draft-ietf-mpls-sr-epe-oam-01

With only the administrative changes as compared to version -07 of
draft-hegde-mpls-spring-epe-oam.

/Loa

On 30/04/2020 10:56, Loa Andersson wrote:
> as a MPLS working group document.
> 
> group mailing list ([email-masked]). Please give a technical
> motivation for your support/not support, especially if you think that
> the document should not be adopted as a working group document.
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          loa.pi.nu@gmail
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 11 Jun 2020 09:02:01 +0000

Ketan,

[KT] Sure and those specific link attributes can be signaled as part of the Link NLRI that carries the BGP Peer Adj SID since that is the one associated with a specific link (please check https://tools.ietf.org/html/draft-ketant-idr-bgp-ls-bgp-only-fabric-04#section-4.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ketant-idr-bgp-ls-bgp-only-fabric-04*section-4.2__;Iw!!NEt6yMaO-gk!TOOFlQK3bX88vsDwQmUzJcPDFmE-e4NXDTGUJsLf7iyeO2WKO6JXo2DyCDrcIyma$>). Therefore, the PeerAdjSID can be used for steering over a specific link and PeerNodeSID can be used for steering over any link to the peer. This is very similar to AdjSID and PrefixSID in IGPs

The FEC validation section clearly defines , the incoming interface can be any interface listed in the FEC.

"               o  Validate the incoming interface on which the OAM packet
                  was receieved, matches with the any of the
                  remote interfaces specified in the PeerNode SID FEC sub-TLV
"

Do you still have concerns?

Rgds
Shraddha

Sent: Friday, June 5, 2020 8:28 PM

Hi Shraddha,

Ketan,

Think about how an EPE controller decides whether it should steer on the link using PeerAdjSID or it should use PeerNodeSID. To make this decision EPE controller needs to have information about link characteristics and which link the traffic is going to take if a path is built using PeerAdjSID/PeerNodeSID and what is the bandwidth availability on those links. This is a fundamental requirement for any kind of traffic-engineering.
[KT] Sure and those specific link attributes can be signaled as part of the Link NLRI that carries the BGP Peer Adj SID since that is the one associated with a specific link (please check https://tools.ietf.org/html/draft-ketant-idr-bgp-ls-bgp-only-fabric-04#section-4.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ketant-idr-bgp-ls-bgp-only-fabric-04*section-4.2__;Iw!!NEt6yMaO-gk!TOOFlQK3bX88vsDwQmUzJcPDFmE-e4NXDTGUJsLf7iyeO2WKO6JXo2DyCDrcIyma$>). Therefore, the PeerAdjSID can be used for steering over a specific link and PeerNodeSID can be used for steering over any link to the peer. This is very similar to AdjSID and PrefixSID in IGPs.

This usecase is very much in the scope of Egress Peer Engineering.
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-10<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-10__;!!NEt6yMaO-gk!TOOFlQK3bX88vsDwQmUzJcPDFmE-e4NXDTGUJsLf7iyeO2WKO6JXo2DyCOHzhNFs$> specifies that the problem statement
comes from 7855

"1.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-10*section-1.1__;Iw!!NEt6yMaO-gk!TOOFlQK3bX88vsDwQmUzJcPDFmE-e4NXDTGUJsLf7iyeO2WKO6JXo2DyCKMQrXHR$>.  Problem Statement

The BGP-EPE problem statement is defined in [RFC7855<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7855__;!!NEt6yMaO-gk!TOOFlQK3bX88vsDwQmUzJcPDFmE-e4NXDTGUJsLf7iyeO2WKO6JXo2DyCPHgHv8O$>]."

https://tools.ietf.org/html/rfc7855#section-3.3.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7855*section-3.3.1__;Iw!!NEt6yMaO-gk!TOOFlQK3bX88vsDwQmUzJcPDFmE-e4NXDTGUJsLf7iyeO2WKO6JXo2DyCN0acXrO$>

Thanks,

Ketan

Rgds

Shraddha

Hi Shraddha,

Trimming further

Thanks,

Ketan

       Rgds
Shraddha

Hi Shraddha,

-----Original Message-----
From: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Sent: 03 June 2020 11:49
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Loa Andersson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

Hi ketan,

-----Original Message-----

Hi  Loa,

Thanks,

Ketan

-----Original Message-----

Sent: 13 May 2020 09:22

Ketan,

Authors

/Loa

Thanks,

Ketan

--

Senior MPLS Expert

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 12 Jun 2020 06:10:35 +0000

Hi Shraddha,

Perhaps we might be going in circles here so let me summarize.

The FEC definition for LSP ping/trace has to be in sync with the definition of the SID in the architecture (RFC8402) and the control plane protocol (draft-ietf-idr-bgpls-segment-routing-epe). I don't see how it can be defined to be something else - even if those additional parameters are marked as optional.

I've already explained how an implementation on the sender can use the echo response that includes the incoming interface on it to do additional checks for its further verification. This would be an implementation/use-case specific aspect that seems beyond the scope of the draft but we can discuss in the WG if there is a need to include it's description in the draft it in a non-normative manner.

So we have a way of staying consistent with the architecture and the control plane protocol while at the same time supporting your implementation specific use-case.

Thanks,
Ketan

Sent: 11 June 2020 14:32

Ketan,

Rgds
Shraddha

Hi Shraddha,

Ketan,

Thanks,

Ketan

Rgds

Shraddha

Hi Shraddha,

Trimming further

Thanks,

Ketan

       Rgds
Shraddha

Hi Shraddha,

-----Original Message-----
From: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Sent: 03 June 2020 11:49
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Loa Andersson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

Hi ketan,

-----Original Message-----

Hi  Loa,

Thanks,

Ketan

-----Original Message-----

Sent: 13 May 2020 09:22

Ketan,

Authors

/Loa

Thanks,

Ketan

--

Senior MPLS Expert