Subject: [Idr] Adam Roach's Discuss on draft-ietf-idr-bgp-prefix-sid-25: (with DISCUSS)

From: Adam Roach <[email-masked]>
Date: Tue, 19 Jun 2018 23:37:39 -0700

Adam Roach has entered the following ballot position for
draft-ietf-idr-bgp-prefix-sid-25: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The removal of IPv6 support from this document without it having a normative
dependency on a document that describes use with IPv6 addresses causes me
quite a bit of concern, on two fronts. I'm willing to be convinced that I'm
off in the weeds, but right now I don't think we can publish the document.

First: while I understand that the working group's intentions are genuine,
this sets us up for a "fail unsafe" situation; if the working group, for
whatever reason, does not progress the IPv6 counterpart of this protocol to an
RFC, then the publication of this document will (retroactively) be in
contravention of the architectural advice issued by the IAB:

https://www.iab.org/documents/correspondence-reports-documents/2016-2/iab-statement-on-ipv6/

The second issue is the precedent of publishing an IPv4-only document in 2018,
at a time that we're aggressively trying to ensure that everyone is designing
their protocols in a way that supports IPv6 addresses. Even with a plan to fix
the lack of IPv6 support, the publication of the document itself sets a bad
example.

I think the first issue could be solved by holding this document until at least
a skeletal IPv6 approach is documented, and then creating a normative dependency
from this document to that one. The second issue could be addressed by
indicating that IPv6 is out of scope of this document only because it is
addressed in [RFC xxxx] (the aforementioned IPv6 document).

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 20 Jun 2018 09:37:08 +0200

Hi Adam,

I think there is slight confusion here :) Most likely due to document title
not its content ...

SR can be used in MPLS networks as well as native IPv6 networks. While SR
architecture talks about both paradigms they are quite disjointed.

MPLS forwarding can be build with IPv4 or (at least in theory :) with IPv6
MPLS enabled control planes.

The proposed herein attribute defines how to propagate indexes for
constructing SIDs in the former ie. SR-MPLS networks. And *is* applicable
to both IPv4 & IPv6 based MPLS networks.

What is outside of scope is the SID propagation for pure IPv6 networks, but
for that we may in the future define completely new attribute - hence I see
no reason to block or slow this work - as the way I see it it is completely
orthogonal.

See SID for MPLS networks is completely different then SID for native IPv6
networks so while preserving attribute space may sound attractive to some
folks I personally think that we are much better off to separate it - if
for nothing else then for filtering flexibility at the attribute level.

So if anything - I would just recommend to adjust the title of the document
at the RFC editor or current IETF review to better reflect the content. For
example to just replace it with: Segment Routing MPLS SID extensions for
BGP.

Hope this helps,
Robert.

On Wed, Jun 20, 2018 at 8:37 AM, Adam Roach <[email-masked]> wrote:

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 20 Jun 2018 11:23:36 +0000

Hi Adam,
 
Deferral of support for the SRv6 data plane should not be confused with support for IPv6 itself. Note that IPv6 unicast labeled prefixes are fully supported by the document. If you have further concerns, I suggest you discuss (in lowercase ;^) with the Routing ADs. For your edification, here are some references to SRv6: 

https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-network-programming/
https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/

While Segment Routing over the MPLS data plane is quite mature, there is still work to complete Segment Routing over the IPv6 data plane. 

Thanks,
Acee 

On 6/20/18, 2:37 AM, "Adam Roach" <[email-masked]> wrote:

---

From: Adam Roach <[email-masked]>
Date: Thu, 21 Jun 2018 15:59:43 -0500

Thanks to you and Acee for clarifying (and doing so quickly!), and sorry 
for the confusion. I've cleared my discuss in the tracker.

/a

On 6/20/18 2:37 AM, Robert Raszuk wrote:
> Hi Adam,
>
> I think there is slight confusion here :) Most likely due to document 
> title not its content ...
>
> SR can be used in MPLS networks as well as native IPv6 networks. While 
> SR architecture talks about both paradigms they are quite disjointed.
>
> MPLS forwarding can be build with IPv4 or (at least in theory :) with 
> IPv6 MPLS enabled control planes.
>
> constructing SIDs in the former ie. SR-MPLS networks. And *is* 
> applicable to both IPv4 & IPv6 based MPLS networks.
>
> What is outside of scope is the SID propagation for pure IPv6 
> networks, but for that we may in the future define completely new 
> attribute - hence I see no reason to block or slow this work - as the 
> way I see it it is completely orthogonal.
>
> See SID for MPLS networks is completely different then SID for native 
> IPv6 networks so while preserving attribute space may sound attractive 
> to some folks I personally think that we are much better off to 
> separate it - if for nothing else then for filtering flexibility at 
> the attribute level.
>
> So if anything - I would just recommend to adjust the title of the 
> document at the RFC editor or current IETF review to better reflect 
> the content. For example to just replace it with: Segment Routing MPLS 
> SID extensions for BGP.
>
> Hope this helps,
> Robert.
>
>
>
> On Wed, Jun 20, 2018 at 8:37 AM, Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Please refer to
>     https://www.ietf.org/iesg/statement/discuss-criteria.html
>     <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>     <https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/>
>
>
>
>     <https://www.iab.org/documents/correspondence-reports-documents/2016-2/iab-statement-on-ipv6/>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/idr>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 21 Jun 2018 21:21:13 +0000

Hi Adam,
Yes – I saw that.
Thanks,
Acee

From: Adam Roach <[email-masked]>
Date: Thursday, June 21, 2018 at 5:00 PM
To: Robert Raszuk <[email-masked]>
Cc: IDR List <[email-masked]>, Susan Hares <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] Adam Roach's Discuss on draft-ietf-idr-bgp-prefix-sid-25: (with DISCUSS)
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, June 21, 2018 at 4:59 PM

Thanks to you and Acee for clarifying (and doing so quickly!), and sorry for the confusion. I've cleared my discuss in the tracker.

/a

I think there is slight confusion here :) Most likely due to document title not its content ...

SR can be used in MPLS networks as well as native IPv6 networks. While SR architecture talks about both paradigms they are quite disjointed.

MPLS forwarding can be build with IPv4 or (at least in theory :) with IPv6 MPLS enabled control planes.

The proposed herein attribute defines how to propagate indexes for constructing SIDs in the former ie. SR-MPLS networks. And *is* applicable to both IPv4 & IPv6 based MPLS networks.

What is outside of scope is the SID propagation for pure IPv6 networks, but for that we may in the future define completely new attribute - hence I see no reason to block or slow this work - as the way I see it it is completely orthogonal.

See SID for MPLS networks is completely different then SID for native IPv6 networks so while preserving attribute space may sound attractive to some folks I personally think that we are much better off to separate it - if for nothing else then for filtering flexibility at the attribute level.

So if anything - I would just recommend to adjust the title of the document at the RFC editor or current IETF review to better reflect the content. For example to just replace it with: Segment Routing MPLS SID extensions for BGP.

Hope this helps,
Robert.

On Wed, Jun 20, 2018 at 8:37 AM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:
Adam Roach has entered the following ballot position for
draft-ietf-idr-bgp-prefix-sid-25: Discuss

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