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

From: Italo Busi <[email-masked]>
Date: Mon, 4 May 2020 07:19:22 +0000

Support

Italo

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: giovedì 30 aprile 2020 04:56
> 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.
> 
> 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
>

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 4 May 2020 10:20:14 +0000

Support the WG adoption

-----Original Message-----
From: Loa Andersson <[email-masked]>
Sent: Thursday, April 30, 2020 8:26 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

[External Email. Be cautious of content]

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.

/Loa
--

My mail server it under a DOS attack, we are working to fix it but it may take some time.

Juniper Business Use Only

---

From: Kapil Arora <[email-masked]>
Date: Mon, 4 May 2020 11:05:30 +0000

I support the working group adoption for this draft

-----Original Message-----
From: Loa Andersson <[email-masked]>
Sent: Thursday, April 30, 2020 8:26 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

Working Group,

/Loa
--

---

From: Samson <[email-masked]>
Date: Mon, 4 May 2020 07:48:06 -0400

I support the working group adoption of this draft.
thanks,
Samson

On Mon, May 4, 2020 at 7:05 AM Kapil Arora <[email-masked]> wrote:

> This is to start a two week poll on adopting
> draft-hegde-mpls-spring-epe-oam as a MPLS working group document.
>
> 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.
>

---

From: Yimin Shen <[email-masked]>
Date: Mon, 4 May 2020 13:08:57 +0000

Support

Thanks,
-- Yimin Shen

On 4/29/20, 10:57 PM, "mpls on behalf of Loa Andersson" <[email-masked] on behalf of [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.

    The authors have stated on the MPLS wg mailing list that they are
    unaware of any IPRs that relates to this document.

    /Loa
    --

    My mail server it under a DOS attack, we are working to fix it but it
    may take some time.

    _______________________________________________
    mpls mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!VsYF-0B-xjf56EerY9ut7MC56YkQZN-8dNn8fEV8sCQp72jzeVE3l9IZgteZ4R8$

---

From: Julian Lucek <[email-masked]>
Date: Mon, 4 May 2020 13:12:28 +0000

Support – being able to do OAM on these SIDs is very useful

From: mpls <[email-masked]> on behalf of Loa Andersson <[email-masked]>
Date: Thursday, 30 April 2020 at 03:56
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

Working Group,

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.

/Loa
--

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

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!WXZ2Bn_JMkHPudV8bw92DybvgmJQ3MwaRY_C7oLOdH_n7TVpleTITqM9r-dxLrAG$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!WXZ2Bn_JMkHPudV8bw92DybvgmJQ3MwaRY_C7oLOdH_n7TVpleTITqM9r-dxLrAG$>

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Mon, 4 May 2020 15:29:38 +0200

Support.

//Krzysztof

> On 2020 -Apr-30, at 04:56, Loa Andersson <[email-masked]> wrote:
> 
> Working Group,
> 
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Lizhenbin <[email-masked]>
Date: Mon, 4 May 2020 14:45:21 +0000

Support the adoption.

Best Regards,
Zhenbin (Robin)

-----Original Message-----
From: Loa Andersson <[email-masked]>
Sent: Thursday, April 30, 2020 8:26 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

Working Group,

/Loa
--

---

From: Mukul Srivastava <[email-masked]>
Date: Mon, 4 May 2020 15:58:47 +0000

I support the adoption.

Thanks
Mukul

On 4/29/20, 10:56 PM, "Loa Andersson" <[email-masked]> wrote:

    Working Group,

    /Loa
    --

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 05 May 2020 10:48:14 +0800

I support the WG adoption.

Xiaohu

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

Working Group,

/Loa
--

---

From: <[email-masked]>
Date: Wed, 6 May 2020 10:51:32 +0800 (CST)

Hi Loa,

I've read this draft and I support working group adoption.

This draft describes a useful extension to RFC 8029/8287, which makes LSP Ping to EPE SIDs available.

Best Regards,

Xiao Min

原始邮件

发件人：LoaAndersson <[email-masked]>
收件人：[email-masked] <[email-masked]>;
抄送人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2020年04月30日 10:57
主 题 ：[mpls] working group adaption poll (wgap) fordraft-hegde-mpls-spring-epe-oam

Working Group,

/Loa
--

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 8 May 2020 09:04:15 +0000

Hi MPLS,

Yes, support. This extension is useful, and I think it is ready for adoption.

Thanks,
Cheng

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, April 30, 2020 10:56 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

Working Group,

/Loa
--

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 12 May 2020 13:30:38 +0530

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.

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

- 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 (?)

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)

--

Regards,
Dhruv

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 12 May 2020 15:32:55 +0000

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://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-19#section-4.2

2) For the Peer Node SID, the control plane definition is https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-19#section-4.1 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.

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://tools.ietf.org/html/rfc8287#section-7.2 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.

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. 

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.

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

Thanks,
Ketan

-----Original Message-----
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,

/Loa
--

---

From: Loa Andersson <[email-masked]>
Date: Wed, 13 May 2020 11:51:54 +0800

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

-- 

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, 13 May 2020 04:08:14 +0000

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,

Authors

/Loa

On 12/05/2020 23:32, Ketan Talaulikar (ketant) wrote:
> 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://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-1
> 9#section-4.2
> 

-- 

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: Loa Andersson <[email-masked]>
Date: Wed, 13 May 2020 17:29:00 +0800

Folks,

I don't tink this came through properly

/Loa

On 13/05/2020 15:12, Loa Andersson wrote:
> Ketan,
> 
> For me there is a bit of procedural issue in this, changing the draft at
> this stage would require a new wgap.
> 
> Would it be sufficient that the working group chairs and the authors 
> acknowledge that the issues you pointed out, including "diverging from
> the control plane protocol semantics for what constitutes the FEC"
> exists, and that all the issues you point out will be addressed as part 
> of the working group process?
> 
> Authors,
> 
> You obviously need to chime in on this.
> 
> /Loa
> 
> On 13/05/2020 12:08, Ketan Talaulikar (ketant) wrote:
>> 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
>>
>>> 2) For the Peer Node SID, the control plane definition is 
>>> https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-19#section-4.1 
>>> 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.
>>>
>>> 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://tools.ietf.org/html/rfc8287#section-7.2 has the following:
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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).
>>>
>>> Thanks,
>>> Ketan
>>>

--

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 13 May 2020 10:42:04 +0000

Hi Loa,

As mentioned in my email, I would like to hear from the authors if they acknowledge the problem and so we can discuss/conclude on the solutions.

Once we converge, I think we should be able to work around the procedural issue?

Thanks,
Ketan

-----Original Message-----
From: Loa Andersson <[email-masked]> 
Sent: 13 May 2020 14:59
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

Folks,

/Loa

On 13/05/2020 15:12, Loa Andersson wrote:
> Ketan,
> 
> For me there is a bit of procedural issue in this, changing the draft 
> at this stage would require a new wgap.
> 
> exists, and that all the issues you point out will be addressed as 
> part of the working group process?
> 
> Authors,
> 
>> taken up during its life as a WG document. I would suggest to wait 
>> for the authors response.
>>
>> Thanks,
>> Ketan
>>
>>> 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://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe
>>> -19#section-4.1 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.
>>>
>>> motivation for your support/not support, especially if you think 
>>> that the document should not be adopted as a working group document.
>>>

--