Subject: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid

From: Alvaro Retana <[email-masked]>
Date: Thu, 15 Feb 2018 08:37:23 -0500

Dear idr WG:

This draft has been through the WG and IESG process and it is waiting final
approval for publication.

During the process some changes have been made, some of them significant
enough that I want to call out for your attention.  Please take a look at
the latest version, specifically the updated text related to multiple
prefixes/paths in sections 4.1 and 4.2.  For your convenience, I think that
the diff between -14 and -16 provides the clearest view:

https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-bgp-prefix-sid-14&url2=draft-ietf-idr-bgp-prefix-sid-16

I think the changes are fine and that they don’t require the document
returning to the WG.  But I just want to give you the opportunity to look
at them just in case.  If anyone has concerns, please reply to this
message.  I plan on approving the document for publication by the end of
next week (Feb/23).

Thanks!

Alvaro.

On February 13, 2018 at 10:31:47 PM, [email-masked] (
[email-masked]) wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

Title : Segment Routing Prefix SID extensions for BGP
Authors : Stefano Previdi
Clarence Filsfils
Acee Lindem
Arjun Sreekantiah
Hannes Gredler
Filename : draft-ietf-idr-bgp-prefix-sid-16.txt
Pages : 19
Date : 2018-02-13

Abstract:
The Segment Routing (SR) architecture allows a node to steer a packet
flow through any topological path and service chain by leveraging
source routing. The ingress node prepends an SR header to a packet
containing a set of segment identifiers (SID). Each SID represents a
topological or a service-based instruction. Per-flow state is
maintained only on the ingress node of the SR domain.

This document defines an optional, transitive BGP attribute for
announcing BGP Prefix Segment Identifiers (BGP Prefix-SID)
information.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-16
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-prefix-sid-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-prefix-sid-16

Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 15 Feb 2018 10:07:11 -0500

I note that the document still has the following text:

"a BGP speaker receiving a prefix with a BGP Prefix-SID attribute and a 
label NLRI field of Implicit NULL"

Am I the only one who doesn't know what the numeric value of "a label 
NLRI field of Implicit NULL" is?  There does not appear to be a 
definition of the numeric value of  "Implicit NULL" in RFC 8277, which 
is the only relevant item in the normative references.  Is a reference 
to RFC 3032 Section 2.1 required?

On 2/15/2018 8:37 AM, Alvaro Retana wrote:
> Dear idr WG:
>
> This draft has been through the WG and IESG process and it is waiting 
> final approval for publication.
>
> During the process some changes have been made, some of them 
> significant enough that I want to call out for your attention. Please 
> take a look at the latest version, specifically the updated text 
> related to multiple prefixes/paths in sections 4.1 and 4.2.  For your 
> convenience, I think that the diff between -14 and -16 provides the 
> clearest view:
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl1-3Ddraft-2Dietf-2Didr-2Dbgp-2Dprefix-2Dsid-2D14-26url2-3Ddraft-2Dietf-2Didr-2Dbgp-2Dprefix-2Dsid-2D16&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=o2an32VlUxyFhi7bKueRpn-9Nnv_ixMZmg44gSvPndA&e=> 
>
>
> returning to the WG.  But I just want to give you the opportunity to 
> look at them just in case.  If anyone has concerns, please reply to 
> this message.  I plan on approving the document for publication by the 
> end of next week (Feb/23).
>
> Thanks!
>
> Alvaro.
>
> On February 13, 2018 at 10:31:47 PM, [email-masked] 
> <mailto:[email-masked]> ([email-masked] 
> <mailto:[email-masked]>) wrote:
>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Dbgp-2Dprefix-2Dsid_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=N0tgIIQyJcbiz8sY8xJGqoiz9XY0NgyZ4b2MCWOxPHU&e=> 
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Didr-2Dbgp-2Dprefix-2Dsid-2D16&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=wwl2a9XgSSGYQmBMLUyjioJyIjaResJU63tV8Lh0oPw&e=> 
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Didr-2Dbgp-2Dprefix-2Dsid-2D16&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=_PKFP2HU-RTOgNjv3cQOhwYyuwh5P5aOJa6mVSQzeCo&e=> 
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Didr-2Dbgp-2Dprefix-2Dsid-2D16&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=7Ss6_8lzJDl0U3F8b4M9edpF1XG9JtyoZsQT_UModj0&e=> 
>>
>>
>>
>> until the htmlized version and diff are available at tools.ietf.org 
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=IsdTJ6aSeBNSSLkVINQYQNQkfE9P-u1y5XX5UWwn_Mc&e=>. 
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=nTLjy0PEOtD6YPTrGm-XSaWEAWSxs_Tt4Wy7Bj2QzUo&e=> 
>>
>>
>> [email-masked] <mailto:[email-masked]>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i-2Dd-2Dannounce&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=ov1NLTv8StMXZBSroef794vxZBfq-prK4hAHyagtjEA&e=> 
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_shadow.html&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=d7rR32qUs_sytae8S7msinAcVI7aDCB9yocrL2B8YkU&e=> 
>>
>> <https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_ietf_1shadow-2Dsites.txt&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=MRB2kIaIcnJ0jVfRmVl4puiURIx9GFD_qwYk4i48Pow&e=> 
>>
>
>
> Idr mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=BzTPrKQqOu71SaROHiK_7IeUpNHd2pDnQ11o3H5_ChE&e=

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 15 Feb 2018 20:10:15 +0100

Hi Eric,

Isn't the fact that a value is defined in IANA registry sufficient ?

https://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml

Do we have to quote all RFCs which define label values at each subsequent
work ?

Thx,
R.

On Thu, Feb 15, 2018 at 4:07 PM, Eric C Rosen <[email-masked]> wrote:

> Am I the only one who doesn't know what the numeric value of "a label NLRI
> field of Implicit NULL" is?  There does not appear to be a definition of
> the numeric value of  "Implicit NULL" in RFC 8277, which is the only
> relevant item in the normative references.  Is a reference to RFC 3032
> Section 2.1 required?
>
>
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-bgp-
> prefix-sid-14&url2=draft-ietf-idr-bgp-prefix-sid-16
> Idr mailing [email-masked]://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=BzTPrKQqOu71SaROHiK_7IeUpNHd2pDnQ11o3H5_ChE&e=
>
>
>
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 15 Feb 2018 19:23:19 +0000

As the late-inning “closer” on this draft, I’m fine either way.
Thanks,
Acee

From: <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Thursday, February 15, 2018 at 2:10 PM
To: Eric C Rosen <[email-masked]>
Cc: Alvaro Retana <[email-masked]>, IDR List <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>
Subject: Re: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid
Resent-From: <[email-masked]>
Resent-To: Stefano Previdi <[email-masked]>, <[email-masked]>, Acee Lindem <[email-masked]>, Arjun Sreekantiah <[email-masked]>, <[email-masked]>
Resent-Date: Thursday, February 15, 2018 at 2:10 PM

Hi Eric,

Do we have to quote all RFCs which define label values at each subsequent work ?

Thx,
R.

On Thu, Feb 15, 2018 at 4:07 PM, Eric C Rosen <[email-masked]<mailto:[email-masked]>> wrote:
I note that the document still has the following text:

"a BGP speaker receiving a prefix with a BGP Prefix-SID attribute and a label NLRI field of Implicit NULL"

Am I the only one who doesn't know what the numeric value of "a label NLRI field of Implicit NULL" is?  There does not appear to be a definition of the numeric value of  "Implicit NULL" in RFC 8277, which is the only relevant item in the normative references.  Is a reference to RFC 3032 Section 2.1 required?

This draft has been through the WG and IESG process and it is waiting final approval for publication.

During the process some changes have been made, some of them significant enough that I want to call out for your attention.  Please take a look at the latest version, specifically the updated text related to multiple prefixes/paths in sections 4.1 and 4.2.  For your convenience, I think that the diff between -14 and -16 provides the clearest view:

https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-bgp-prefix-sid-14&url2=draft-ietf-idr-bgp-prefix-sid-16<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl1-3Ddraft-2Dietf-2Didr-2Dbgp-2Dprefix-2Dsid-2D14-26url2-3Ddraft-2Dietf-2Didr-2Dbgp-2Dprefix-2Dsid-2D16&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=o2an32VlUxyFhi7bKueRpn-9Nnv_ixMZmg44gSvPndA&e=>

I think the changes are fine and that they don’t require the document returning to the WG.  But I just want to give you the opportunity to look at them just in case.  If anyone has concerns, please reply to this message.  I plan on approving the document for publication by the end of next week (Feb/23).

Thanks!

Alvaro.

On February 13, 2018 at 10:31:47 PM, [email-masked]<mailto:[email-masked]> ([email-masked]<mailto:[email-masked]>) wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Dbgp-2Dprefix-2Dsid_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=N0tgIIQyJcbiz8sY8xJGqoiz9XY0NgyZ4b2MCWOxPHU&e=>

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-16<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Didr-2Dbgp-2Dprefix-2Dsid-2D16&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=wwl2a9XgSSGYQmBMLUyjioJyIjaResJU63tV8Lh0oPw&e=>
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-prefix-sid-16<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Didr-2Dbgp-2Dprefix-2Dsid-2D16&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=_PKFP2HU-RTOgNjv3cQOhwYyuwh5P5aOJa6mVSQzeCo&e=>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-prefix-sid-16<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Didr-2Dbgp-2Dprefix-2Dsid-2D16&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=7Ss6_8lzJDl0U3F8b4M9edpF1XG9JtyoZsQT_UModj0&e=>

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=IsdTJ6aSeBNSSLkVINQYQNQkfE9P-u1y5XX5UWwn_Mc&e=>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=nTLjy0PEOtD6YPTrGm-XSaWEAWSxs_Tt4Wy7Bj2QzUo&e=>

_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i-d-announce<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i-2Dd-2Dannounce&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=ov1NLTv8StMXZBSroef794vxZBfq-prK4hAHyagtjEA&e=>
Internet-Draft directories: http://www.ietf.org/shadow.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_shadow.html&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=d7rR32qUs_sytae8S7msinAcVI7aDCB9yocrL2B8YkU&e=>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_ietf_1shadow-2Dsites.txt&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=MRB2kIaIcnJ0jVfRmVl4puiURIx9GFD_qwYk4i48Pow&e=>

Idr mailing list

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

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 15 Feb 2018 14:41:17 -0500

A reference to the IANA "Special Purpose MPLS Label Values" registry 
would be more appropriate than my suggestion of a reference to RFC 3032.

On 2/15/2018 2:23 PM, Acee Lindem (acee) wrote:
> *From: *<[email-masked]> on behalf of Robert Raszuk <[email-masked]>
> *Date: *Thursday, February 15, 2018 at 2:10 PM
> *To: *Eric C Rosen <[email-masked]>
> *Cc: *Alvaro Retana <[email-masked]>, IDR List <[email-masked]>, 
> "[email-masked]" <[email-masked]>, 
> "[email-masked]" 
> <[email-masked]>, Susan Hares <[email-masked]>
> *Subject: *Re: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid
> *Resent-From: *<[email-masked]>
> *Resent-To: *Stefano Previdi <[email-masked]>, <[email-masked]>, 
> Acee Lindem <[email-masked]>, Arjun Sreekantiah <[email-masked]>, 
> <[email-masked]>
> *Resent-Date: *Thursday, February 15, 2018 at 2:10 PM
>
> Hi Eric,
>
> https://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_mpls-2Dlabel-2Dvalues_mpls-2Dlabel-2Dvalues.xhtml&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=vtBIsDLv8jXDv1Fhpw5RUW4tFl3JG34pHtmL1Q6byW8&s=hEnyhlX4MtRvi4X7iZXuIpq647X-KvZjmH8ZuJXcxa0&e=>
>
> On Thu, Feb 15, 2018 at 4:07 PM, Eric C Rosen 
> <[email-masked]<mailto:[email-masked]>> wrote:
>
>     Am I the only one who doesn't know what the numeric value of "a
>     label NLRI field of Implicit NULL" is?  There does not appear to
>     be a definition of the numeric value of "Implicit NULL" in RFC
>     8277, which is the only relevant item in the normative
>     references.  Is a reference to RFC 3032 Section 2.1 required?
>
>
>
>         significant enough that I want to call out for your
>         attention.  Please take a look at the latest version,
>         specifically the updated text related to multiple
>         prefixes/paths in sections 4.1 and 4.2. For your convenience,
>         I think that the diff between -14 and -16 provides the
>         clearest view:
>
>         I think the changes are fine and that they don’t require the
>         document returning to the WG.  But I just want to give you the
>         opportunity to look at them just in case. If anyone has
>         concerns, please reply to this message.  I plan on approving
>         the document for publication by the end of next week (Feb/23).
>
>         Thanks!
>
>         Alvaro.
>
>         On February 13, 2018 at 10:31:47 PM,
>         [email-masked]<mailto:[email-masked]>([email-masked]<mailto:[email-masked]>)
>         wrote:
>
>
>             until the htmlized version and diff are available at
>             tools.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=IsdTJ6aSeBNSSLkVINQYQNQkfE9P-u1y5XX5UWwn_Mc&e=>.
>
>
>             Internet-Draft directories:
>             http://www.ietf.org/shadow.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_shadow.html&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=d7rR32qUs_sytae8S7msinAcVI7aDCB9yocrL2B8YkU&e=>
>             or
>             ftp://ftp.ietf.org/ietf/1shadow-sites.txt<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_ietf_1shadow-2Dsites.txt&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=yF0495B-NVp5DIlASsUbsM45SPzz8uoC8OecJguM3vA&s=MRB2kIaIcnJ0jVfRmVl4puiURIx9GFD_qwYk4i48Pow&e=>
>
>
>
>     https://www.ietf.org/mailman/listinfo/idr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=vtBIsDLv8jXDv1Fhpw5RUW4tFl3JG34pHtmL1Q6byW8&s=2bFiXHF10MVSqXz3IIn5ssSFJoPZDE14djm4jBzL-6o&e=>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 15 Feb 2018 20:00:34 +0000

I’ll add that.
Thanks,
Acee

From: Eric C Rosen <[email-masked]>
Date: Thursday, February 15, 2018 at 2:41 PM
To: Acee Lindem <[email-masked]>, Robert Raszuk <[email-masked]>
Cc: Alvaro Retana <[email-masked]>, IDR List <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>
Subject: Re: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid

A reference to the IANA "Special Purpose MPLS Label Values" registry would be more appropriate than my suggestion of a reference to RFC 3032.

From: <[email-masked]><mailto:[email-masked]> on behalf of Robert Raszuk <[email-masked]><mailto:[email-masked]>
Date: Thursday, February 15, 2018 at 2:10 PM
To: Eric C Rosen <[email-masked]><mailto:[email-masked]>
Cc: Alvaro Retana <[email-masked]><mailto:[email-masked]>, IDR List <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, Susan Hares <[email-masked]><mailto:[email-masked]>
Subject: Re: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid
Resent-From: <[email-masked]><mailto:[email-masked]>
Resent-To: Stefano Previdi <[email-masked]><mailto:[email-masked]>, <[email-masked]><mailto:[email-masked]>, Acee Lindem <[email-masked]><mailto:[email-masked]>, Arjun Sreekantiah <[email-masked]><mailto:[email-masked]>, <[email-masked]><mailto:[email-masked]>
Resent-Date: Thursday, February 15, 2018 at 2:10 PM

Hi Eric,

Thx,
R.

Thanks!

Alvaro.

Abstract:

Idr mailing list

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 17 Feb 2018 20:40:59 +0000

Dear Alvaro and IDR WG:

     There is one more change we’d like to make to the draft that requires WG approval. One revelation during the review process for this draft is that the SRv6 use case as currently documented isn’t really that compelling and there are some details that are unspecified. Other than validation, the IPv6 SID TLV hasn’t been implemented. Consequently, we’d like to remove the IPv6 SID TLV and SRv6 dataplane specification from the draft. Are there any objections (other than the obvious one that it is very late to be making this change)?

Here are a list of implementations and none have implemented the IPv6 SID:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-prefix-sid%20implementations

Note that the code point for the IPv6 SID would be deprecated since validation has been implemented in several implementations.

If there are no objections, I could make this change next week and we could allow for an additional week for review.

Thanks,
Acee

From: Alvaro Retana <[email-masked]>
Date: Thursday, February 15, 2018 at 8:37 AM
To: IDR List <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>
Subject: Review Updates to draft-ietf-idr-bgp-prefix-sid
Resent-From: <[email-masked]>
Resent-To: Stefano Previdi <[email-masked]>, <[email-masked]>, Acee Lindem <[email-masked]>, Arjun Sreekantiah <[email-masked]>, <[email-masked]>
Resent-Date: Thursday, February 15, 2018 at 8:37 AM

Dear idr WG:

Thanks!

Alvaro.

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 17 Feb 2018 13:23:35 -0800

strong +1 from having reviewed the draft in SG if it's really not
implemented by anyone ... This will

1. simplify the draft significantly and improve its readability
2. remove bunch of weird corner cases I commented on that would need
specification if v6 is in it

Otherwise only serious comments pending was the clarity/correctness of the
forwarding section (but I admit I did NOT read the newest version published
so maybe they have been taken up) AFAIR ..

On Sat, Feb 17, 2018 at 12:40 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Dear Alvaro and IDR WG:
>
>
>
>      There is one more change we’d like to make to the draft that requires
> WG approval. One revelation during the review process for this draft is
> that the SRv6 use case as currently documented isn’t really that compelling
> and there are some details that are unspecified. Other than validation, the
> IPv6 SID TLV hasn’t been implemented. Consequently, we’d like to remove the
> IPv6 SID TLV and SRv6 dataplane specification from the draft. Are there any
> objections (other than the obvious one that it is very late to be making
> this change)?
>
>
>
> Note that the code point for the IPv6 SID would be deprecated since
> validation has been implemented in several implementations.
>
>
>
> If there are no objections, I could make this change next week and we
> could allow for an additional week for review.
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
>
>
>
>
> *From: *Alvaro Retana <[email-masked]>
> *Date: *Thursday, February 15, 2018 at 8:37 AM
> *To: *IDR List <[email-masked]>
> *Cc: *"[email-masked]" <draft-ietf-idr-bgp-prefix-
> [email-masked]>, "[email-masked]" <[email-masked]>, Susan Hares <
> [email-masked]>
> *Subject: *Review Updates to draft-ietf-idr-bgp-prefix-sid
> *Resent-To: *Stefano Previdi <[email-masked]>, <[email-masked]>, Acee
> Lindem <[email-masked]>, Arjun Sreekantiah <[email-masked]>, <
> [email-masked]>
> *Resent-Date: *Thursday, February 15, 2018 at 8:37 AM
>
>
>
> Dear idr WG:
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 17 Feb 2018 21:36:55 +0000

Hi Tony,
Thanks for the support. I’ve attached the changes I’m proposing – it is actually a pretty straight forward extraction.
Thanks,
Acee

From: Tony Przygienda <[email-masked]>
Date: Saturday, February 17, 2018 at 4:24 PM
To: Acee Lindem <[email-masked]>
Cc: Alvaro Retana <[email-masked]>, IDR List <[email-masked]>, "[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid

strong +1 from having reviewed the draft in SG if it's really not implemented by anyone ... This will
1. simplify the draft significantly and improve its readability
2. remove bunch of weird corner cases I commented on that would need specification if v6 is in it
Otherwise only serious comments pending was the clarity/correctness of the forwarding section (but I admit I did NOT read the newest version published so maybe they have been taken up) AFAIR ..

On Sat, Feb 17, 2018 at 12:40 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Dear Alvaro and IDR WG:

Thanks,
Acee

From: Alvaro Retana <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 15, 2018 at 8:37 AM
To: IDR List <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Review Updates to draft-ietf-idr-bgp-prefix-sid
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Stefano Previdi <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>, Arjun Sreekantiah <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent-Date: Thursday, February 15, 2018 at 8:37 AM

Dear idr WG:

Thanks!

Alvaro.

Abstract:

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 17 Feb 2018 22:45:18 +0100

Hi Acee,

Changes look good in general.

I would however keep reference to RFC4760 as  RFC3107 / RFC8277 are
actively using it :-).

Also since you removed the reference to SAFI 2/1 I would think the
paragraph describing it needs to be changes to say:

The BGP Prefix-SID attribute defined in this document can be attached
to prefixes from BGP labeled IPv4/IPv6 Unicast ([RFC8277
<https://tools.ietf.org/html/rfc8277>]).

instead of:

The BGP Prefix-SID attribute defined in this document can be attached
to prefixes from Address Family Identifier (AFI)/ Subsequent Address
Family Identifier (SAFI) combinations:

   Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277
<https://tools.ietf.org/html/rfc8277>]).

Thx,

Robert.

On Sat, Feb 17, 2018 at 10:36 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Tony,
>
> Thanks for the support. I’ve attached the changes I’m proposing – it is
> actually a pretty straight forward extraction.
>
> Thanks,
> Acee
>
>
>
> *From: *Tony Przygienda <[email-masked]>
> *Date: *Saturday, February 17, 2018 at 4:24 PM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *Alvaro Retana <[email-masked]>, IDR List <[email-masked]>, "
> [email-masked]" <[email-masked]>, Susan Hares <[email-masked]>,
> "[email-masked]" <draft-ietf-idr-bgp-prefix-
> [email-masked]>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 17 Feb 2018 22:00:38 +0000

Hi Robert,

From: <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Saturday, February 17, 2018 at 4:45 PM
To: Acee Lindem <[email-masked]>
Cc: Tony Przygienda <[email-masked]>, IDR List <[email-masked]>, "[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid
Resent-From: <[email-masked]>
Resent-To: Stefano Previdi <[email-masked]>, <[email-masked]>, Acee Lindem <[email-masked]>, Arjun Sreekantiah <[email-masked]>, <[email-masked]>
Resent-Date: Saturday, February 17, 2018 at 4:45 PM

Hi Acee,

I would however keep reference to RFC4760 as  RFC3107 / RFC8277 are actively using it :-).

Normally, we don’t need to retain indirect references. However, since it is so fundamental, I could add it to the first reference to RFC 8277, i.e., use ([RFC4760], [RFC8277]).

Also since you removed the reference to SAFI 2/1 I would think the paragraph describing it needs to be changes to say:

to prefixes from BGP labeled IPv4/IPv6 Unicast ([RFC8277<https://tools.ietf.org/html/rfc8277>]).

instead of:

   Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277<https://tools.ietf.org/html/rfc8277>]).

Good point, this reads a lot better.

Thanks,

Acee

Thx,
Robert.

On Sat, Feb 17, 2018 at 10:36 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tony,
Thanks for the support. I’ve attached the changes I’m proposing – it is actually a pretty straight forward extraction.
Thanks,
Acee

From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Date: Saturday, February 17, 2018 at 4:24 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>, IDR List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid

Thanks,
Acee

Dear idr WG:

Thanks!

Alvaro.

Abstract:

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 17 Feb 2018 23:05:56 +0000

Acee,

Changes look good to me!
Jeff

On Sat, Feb 17, 2018 at 13:37 Acee Lindem (acee) <[email-masked]> wrote:

> "[email-masked]" <
> [email-masked]>
>
>
> *Cc: *"[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, Susan Hares <[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 18 Feb 2018 11:57:14 +0100

Hi Acee,

Since we are at the open surgery of this draft there is one more point
which did not got resolved during our offline discussion. Feedback from WG
is welcome here.

The draft RECOMMENDS the following procedure in case of a conflict:

... it is RECOMMENDED that the first prefix using the label index is selected.

In BGP there is no guarantee about ordered delivery of BGP prefixes.  It
may work such in some specific topologies but not in any arbitrary one. So
if we recommend to pick one prefix on R1 and different prefix on R2 and
install in forwarding the same SID for those I am afraid the data plane
will get quite severely messed up and even finding it during
troubleshooting will be quite hard.

Also as pointed out already MPLS anycast SID may on purpose use the same
label across nodes according to draft-ietf-spring-mpls-anycast-segments-02.
Now if we want to accomplish the same in BGP we would need to advertise
different prefixes with the same SID (in MPLS-SR index). the above
paragraph does prevents that. Note that adding and advertising the _same_
prefix from different nodes will not work as BGP speakers may pick only one
(best path) and use it for forwarding. IBGP or EBGP multipath may not
always be enabled/use same set.

The crux of the issue when advertising SIDs in BGP is not so much about
prefixes, but their next hops which unfortunately the draft does not even
mention once.

Kind regards,
Robert.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sun, 18 Feb 2018 12:16:18 +0000

Hi Robert,

I do hope this is not an open surgery of the draft ☺

Regarding Anycast prefixes, my understanding was that this, by definition, means the same prefix being multi-home and originated by more than one routers. I did not follow anycast with different prefixes.

Also, the handling of anycast involves either of the following:

1)     Pointing to the “closest” (best on whatever the decision process of the protocol involved) originator of the prefix, OR

2)     Doing load-balancing between the multiple originators (when this is possibled/desired).

So I am not sure I understood the relationship of anycast to the conflict.

Thanks,
Ketan

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: 18 February 2018 16:27
To: Acee Lindem (acee) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid

Hi Acee,

Since we are at the open surgery of this draft there is one more point which did not got resolved during our offline discussion. Feedback from WG is welcome here.

In BGP there is no guarantee about ordered delivery of BGP prefixes.  It may work such in some specific topologies but not in any arbitrary one. So if we recommend to pick one prefix on R1 and different prefix on R2 and install in forwarding the same SID for those I am afraid the data plane will get quite severely messed up and even finding it during troubleshooting will be quite hard.

Also as pointed out already MPLS anycast SID may on purpose use the same label across nodes according to draft-ietf-spring-mpls-anycast-segments-02. Now if we want to accomplish the same in BGP we would need to advertise different prefixes with the same SID (in MPLS-SR index). the above paragraph does prevents that. Note that adding and advertising the _same_ prefix from different nodes will not work as BGP speakers may pick only one (best path) and use it for forwarding. IBGP or EBGP multipath may not always be enabled/use same set.

The crux of the issue when advertising SIDs in BGP is not so much about prefixes, but their next hops which unfortunately the draft does not even mention once.

Kind regards,
Robert.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 18 Feb 2018 12:38:00 +0000

Hi Robert,

From: <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Sunday, February 18, 2018 at 5:57 AM
To: Acee Lindem <[email-masked]>
Cc: IDR List <[email-masked]>
Subject: Re: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid

Hi Acee,

I don’t understand this concern either. The text applies to difference prefixes, not an anycast where multiple BGP speakers with advertise the same <prefix, SID> tuple.

Thanks,
Acee

Kind regards,
Robert.

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 18 Feb 2018 10:54:02 -0500

Robert and Acee:

If we do “open surgery”, this document will need to go back through the process (WG LC, IETF LC, and IESG Review). 

Sue Hares

IDR co-chiar

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Sunday, February 18, 2018 5:57 AM
To: Acee Lindem (acee)
Cc: [email-masked]
Subject: Re: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid

Hi Acee,

Kind regards,

Robert.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 18 Feb 2018 16:54:39 +0100

Hi Acee,

We are talking about 3107 here. That is to construct MPLS forwarding data
plane.

What goes into data plane is label and next hop - NLRI prefix really does
not matter here. The switching path is MPLS2MPLS not IP2MPLS in my point.

So what is going to happen if someone verbatim follows what is written in
this paragraph is that two prefixes P1 & P2 with different next hops NH1 &
NH2 and the same SID index S are present in BGP. This is the "conflict"
paragraph is trying to address.

Now some router R1 will receive P1 first and some other router R2 will
receive P2 first.

So what get's programmed into data plane is this:

R1 - lookup label: S index +base with next hop: NH1

R2 - lookup label: S index + base with next hop NH2

As you can see creating a rule based on the order in which different
prefixes are received will result in rather messy data plane.

Cheers,
R.

On Sun, Feb 18, 2018 at 1:38 PM, Acee Lindem (acee) <[email-masked]> wrote:

> *Date: *Sunday, February 18, 2018 at 5:57 AM
> *Cc: *IDR List <[email-masked]>
> I don’t understand this concern either. The text applies to difference
> prefixes, not an anycast where multiple BGP speakers with advertise the
> same <prefix, SID> tuple.
>
>
>
> Thanks,
>
> Acee
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 18 Feb 2018 16:56:59 +0100

Hi Sue,

Well Acee said himself few email back:

"Dear Alvaro and IDR WG:

WG approval."

I maybe just don't 'know what formally this "WG approval" is :)

Thx,
R.

On Sun, Feb 18, 2018 at 4:54 PM, Susan Hares <[email-masked]> wrote:

> Robert and Acee:
>
>
>
> If we do “open surgery”, this document will need to go back through the
> process (WG LC, IETF LC, and IESG Review).
>
>
>
> Sue Hares
>
> IDR co-chiar
>
>
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> *Sent:* Sunday, February 18, 2018 5:57 AM
> *To:* Acee Lindem (acee)
> *Cc:* [email-masked]
> *Subject:* Re: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid
>
>
>
> Hi Acee,
>
>
>

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 18 Feb 2018 11:13:32 -0500

Robert: 

<process moment on> 

As an AD, Alvaro may change to the document (see the history and his comments).  Due to the substantial nature of his comments during the AD evaluation and IESG review, the WG must approve the changes.   Alvaro’s checking to see if the WG agrees with his changes.   If the IDR WG agrees with it, then document does go forward to the RFC editor.   If WG objects,  then document will be return to the IDR for “surgery”, and then go through the process again (IDR WG LC, IETF LC, IESG evaluation.  

Such is the power of the AD review and changes suggest to the authors.   

<process moment off> 

I hope this process moment provides a cheerily chuckle in your day.   

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Sunday, February 18, 2018 10:57 AM
To: Susan Hares
Cc: idr wg
Subject: Re: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid

Hi Sue,

"Dear Alvaro and IDR WG:

     There is one more change we’d like to make to the draft that requires WG approval."

Thx,
R.

 

Robert and Acee:

Sue Hares

IDR co-chiar

Hi Acee,

Kind regards,

Robert.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 18 Feb 2018 17:27:48 +0000

Hi Robert,

Date: Sunday, February 18, 2018 at 10:54 AM

Hi Acee,

We are talking about 3107 here. That is to construct MPLS forwarding data plane.

What goes into data plane is label and next hop - NLRI prefix really does not matter here. The switching path is MPLS2MPLS not IP2MPLS in my point.

So what is going to happen if someone verbatim follows what is written in this paragraph is that two prefixes P1 & P2 with different next hops NH1 & NH2 and the same SID index S are present in BGP. This is the "conflict" paragraph is trying to address.

Now some router R1 will receive P1 first and some other router R2 will receive P2 first.

As you can see creating a rule based on the order in which different prefixes are received will result in rather messy data plane.

There are two reasons that different prefixes would be advertised with the same label index, misconfiguration or transition. This rule was posited to decrease the number of changes necessary in the case of a transition. In any case, while the data plane is messy, it is not broken since MPLS switching is stll hop-by-hop using the RFC 8277 label.

Thanks,
Acee

Cheers,
R.

On Sun, Feb 18, 2018 at 1:38 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

From: <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Sunday, February 18, 2018 at 5:57 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: IDR List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid

Hi Acee,

Thanks,
Acee

Kind regards,
Robert.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 18 Feb 2018 18:34:48 +0100

Acee,

>  it is not broken since MPLS switching is stll hop-by-hop

If NH1 and NH2 point in opposite directions you have permanent forwarding
loop between hops when packet arrives with label S+base. Is it really not a
prove of it being slightly broken ?

Thx,
R.

On Sun, Feb 18, 2018 at 6:27 PM, Acee Lindem (acee) <[email-masked]> wrote:

> *Date: *Sunday, February 18, 2018 at 10:54 AM
> There are two reasons that different prefixes would be advertised with the
> same label index, misconfiguration or transition. This rule was posited to
> decrease the number of changes necessary in the case of a transition. In
> any case, while the data plane is messy, it is not broken since MPLS
> switching is stll hop-by-hop using the RFC 8277 label.
>
>
>
> Thanks,
>
> Acee
>
>
>
> Cheers,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 18 Feb 2018 18:34:54 +0100

Hi Ketan,

Sorry for mixing two different and independent comments together in my msg
to Acee. One is about "first prefix selection" and let's keep it separate.

As far as anycast point I was talking about anycast SID/index not anycast
prefix. Yes for IP anycast prefix must be the same across nodes. But for SR
data plane I don't see this as such strong requirement.

Imagine R1 and R2 advertsing P1 and P2 with SID S. If you force that P1 &
P2 must be the same you must enable multipath on all the nodes to install S
with both next hops into dataplane.

Contrary if you allow same SID to be installed with different next hops
when it comes with different prefixes you don't have to worry about
multipath being enabled anywhere :). After all it should be up to operator
to decide how he wants to advertise his MPLS indexes.

Remember for mpls2mpls date plane what prefixes are advertised as part of
NLRI does not really matter ...

Anyhow I have a feeling that this discussion belongs to SPRING not to IDR
so let's move it there or take it offline.

Cheers,
R.

On Sun, Feb 18, 2018 at 1:16 PM, Ketan Talaulikar (ketant) <[email-masked]

> Hi Robert,
>
>
>
> I do hope this is not an open surgery of the draft J
>
>
>
> Regarding Anycast prefixes, my understanding was that this, by definition,
> means the same prefix being multi-home and originated by more than one
> routers. I did not follow anycast with different prefixes.
>
>
>
> 1)     Pointing to the “closest” (best on whatever the decision process
> of the protocol involved) originator of the prefix, OR
>
> *Sent:* 18 February 2018 16:27
> *To:* Acee Lindem (acee) <[email-masked]>
> *Cc:* [email-masked]

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 20 Feb 2018 13:52:47 -0500

On February 17, 2018 at 3:41:02 PM, Acee Lindem (acee) ([email-masked])
wrote:

Acee:

Hi!

There is one more change we’d like to make to the draft that requires WG
approval. One revelation during the review process for this draft is that
the SRv6 use case as currently documented isn’t really that compelling and
there are some details that are unspecified. Other than validation, the
IPv6 SID TLV hasn’t been implemented. Consequently, we’d like to remove the
IPv6 SID TLV and SRv6 dataplane specification from the draft. Are there any
objections (other than the obvious one that it is very late to be making
this change)?

If there are no objections, I could make this change next week and we could
allow for an additional week for review.

This is a significant change!  Thanks for specifically pointing out the
lack support in the implementations for the IPv6 SID.  Please consider
adding an rfc7942-style section to the document.

While I don’t have a specific objection to you simplifying the document, it
is a decision that shouldn’t be made *after* the IESG has approved the
publication of the document.  OTOH, better late than never!

idr-chairs:  I am returning the document to the WG for discussion and
update.  If the WG reaches consensus on the proposed changes, I want to
make sure that it is done with the understanding that the related IPv6 work
will be done later.  IOW, the result should not be that the IPv6 work is
abandoned — I am sure that is not the intent.  Note that we don’t need to
discuss or adopt a specific alternative before processing this document.

Thanks!

Alvaro.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 21 Feb 2018 19:20:12 +0000

Hi  Alvaro,

There are implementations of SRv6 today for various use cases (e.g. BGP VPNs, TE, NFV, Spray)
on multiple operating systems and multiple hardware platforms.

There have been demos and interop exercises between multiple vendors for SRv6 including
trials with operators.

The document change is related to one specific TLV which was not needed.

The SRv6 base specification describes the different control protocol usage and signalling in
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-03#section-8.4
via IGPs, BGP and BGP-LS.

- The IGP specifications for SRv6 are covered by draft-bashandy-isis-srv6-extensions and
  draft-li-ospf-ospfv3-srv6-extensions.
- The BGP VPN specifications is covered by draft-dawra-idr-srv6-vpn.
- The BGP-LS specification for SRv6 are covered by draft-dawra-idr-bgpls-srv6-ext.

With the above documents the SRv6 control plane is complete.

We propose to deprecate the IPv6 SID TLV defined in draft-ietf-idr-bgp-prefix-sid.
It is not required for any use-case.

Thanks Much,
Acee

From: Alvaro Retana <[email-masked]>
Date: Tuesday, February 20, 2018 at 1:52 PM
To: Acee Lindem <[email-masked]>, IDR List <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>
Subject: Re: Review Updates to draft-ietf-idr-bgp-prefix-sid

On February 17, 2018 at 3:41:02 PM, Acee Lindem (acee) ([email-masked]<mailto:[email-masked]>) wrote:

Acee:

Hi!

This is a significant change!  Thanks for specifically pointing out the lack support in the implementations for the IPv6 SID.  Please consider adding an rfc7942-style section to the document.

While I don’t have a specific objection to you simplifying the document, it is a decision that shouldn’t be made *after* the IESG has approved the publication of the document.  OTOH, better late than never!

idr-chairs:  I am returning the document to the WG for discussion and update.  If the WG reaches consensus on the proposed changes, I want to make sure that it is done with the understanding that the related IPv6 work will be done later.  IOW, the result should not be that the IPv6 work is abandoned — I am sure that is not the intent.  Note that we don’t need to discuss or adopt a specific alternative before processing this document.

Thanks!

Alvaro.