Subject: [spring] FW: New Version Notification for draft-bonica-spring-srv6-plus-05.txt

From: Ron Bonica <[email-masked]>
Date: Wed, 28 Aug 2019 15:38:18 +0000

FYI

Juniper Public

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Wednesday, August 28, 2019 11:31 AM
To: Ron Bonica <[email-masked]>; Shraddha Hegde <[email-masked]>; Andrew Alston <[email-masked]>; Gang Chen <[email-masked]>; Joel Halpern <[email-masked]>; Andrew Alston <[email-masked]>; Daniam Henriques <[email-masked]>; Jen Linkova <[email-masked]>; Yuji Kamite <[email-masked]>
Subject: New Version Notification for draft-bonica-spring-srv6-plus-05.txt

A new version of I-D, draft-bonica-spring-srv6-plus-05.txt
has been successfully submitted by Ron Bonica and posted to the IETF repository.

Name:		draft-bonica-spring-srv6-plus
Revision:	05
Title:		IPv6 Support for Segment Routing: SRv6+
Document date:	2019-08-28
Group:		Individual Submission
Pages:		23

Abstract:
   This document describes SRv6+. SRv6+ is a Segment Routing (SR)
   solution that leverages IPv6.  It supports a wide variety of use-
   cases while remaining in strict compliance with IPv6 specifications.
   SRv6+ is optimized for ASIC-based forwarding devices that operate at
   high data rates.

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.

The IETF Secretariat

---

From: Mark Smith <[email-masked]>
Date: Thu, 29 Aug 2019 09:39:54 +1000

Hi Ron,

In an email a while back I think you mentioned that the SID space is
unique in the context of an address, where as this draft is saying
that SIDs have node-local significance, which I think means the same
single SID space across all the addresses of the node.

The reason I'm wondering is that if the SID space is per-address, then
I'd think it could be possible to have a single 16 bit SID space,
rather than two sizes and needing an operator to make a choice (with
the risk of making an incorrect choice, and the consequences of having
to migrate a network from one size to another).

If 16 bits is enough for TCP/UDP etc. ports in most cases then I'd
guess it would probably be enough for SIDs. Of course, as with running
out of TCP/UDP port numbers, an operator could give a node or
interface another IPv6 address to create another 16 bit SID space if
necessary.

I also remember from that email you mentioning the idea of unique
link-local addresses. If IPv6 implementations follow RFC 8064,
"Recommendation on Stable IPv6 Interface Identifiers", which
recommends RFC 7217, "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Autoconfiguration
(SLAAC)", then nodes' link-local addresses (specifically the IID part)
should not only be network wide unique, but also globally unique.

Regards,
Mark.

On Thu, 29 Aug 2019 at 01:38, Ron Bonica
<rbonica=[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 28 Aug 2019 21:50:33 -0400

Mark, I had missed the earlier email suggesting that the SIDs could be 
address specific rather than just node specific.  That is an interesting 
idea.  At first glance, it appears to work, and warrants further thought.

As far as I know, routers tend not to use SLAAC for interface address 
generation, and tend not to be worried about the privacy properties of 
their interface addresses, so at least for most use cases I am having 
trouble following your last paragraph.

Thank you,
Joel

---

From: Mark Smith <[email-masked]>
Date: Thu, 29 Aug 2019 12:54:56 +1000

Hi Joel,

> idea.  At first glance, it appears to work, and warrants further thought.

I like the idea of having one-size-fits-most or one-size-fits-all
parameters or rather constants if possible, as it means one less
decision, and one less decision that could be wrong and then costly to
fix.

With per-address SID space, you could then use aggregate prefixes to
give a range of addresses and their SIDs some sort of significance
that may be operationally or business useful.

For example, I think ULAs should be used for the outer SR packet
addressing to help mitigate SR traffic leaking or its effects, and
since you can generate multiple of your own unique ULA /48s, you could
do something like have a SR ULA /48 per country, region etc., or
perhaps a ULA /48 per SR service type or type group.

> trouble following your last paragraph.

They might not be using the SLAAC "protocol" i.e. RA PIOs, however
they are supposed to be using the SLAAC method to generate their
Link-Local addresses.

RFC 4862, "IPv6 Stateless Address Autoconfiguration":

"The autoconfiguration process specified in this document applies only
   to hosts and not routers.  Since host autoconfiguration uses
   information advertised by routers, routers will need to be configured
   by some other means.  However, it is expected that routers will
   generate link-local addresses using the mechanism described in this
   document.  In addition, routers are expected to successfully pass the
   Duplicate Address Detection procedure described in this document on
   all addresses prior to assigning them to an interface."

RFC 7217 naturally applies to routers too due to their use of SLAAC
above, including their link-local addresses. The specific idea was to
be able to couple a router's interface addresses to something else
independent of interface MAC address, such as module slot, so that
swapping a router interface module didn't cause the IPv6 interface
addresses to change.

Of course you can avoid that problem by configuring static IPv6
addresses on router interfaces, although it's work a computer could do
instead, and I wonder how often people have typed in fe80::1 when they
really meant to type in fe80::2? DAD would catch it, however it's
better to avoid a problem.

I'm pretty sure globally unique Link-Local IIDs weren't a goal of RFC
7217, however I think they're useful because within your network they
can be come a network wide IPv6 interface identifier independent of
GUA/ULA addresses.

Their local network uniqueness also means they could be put in a local
instance of authoritative reverse DNS for fe80::/10 e.g. PTR
<intfname>.<routername>. That could be useful during troubleshooting
e.g. have an end-user read out their default gateway's interface
address name rather than fe80::<blah>. (fe80::1 is good for end-users
to read or type, but tells you nothing link or router specific. )

Regards,
Mark.

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Fri, 30 Aug 2019 14:22:34 +0000

Ron:

I still feel that all SID (including adj SID as well as Node SID) is node-local significance in your SRv6+ draft May be a problem, even if you has explained it previously.

From my understanding, the Node SID (for loopback@) must be global significance in SR-enabled domain, so that every Node within SRv6 domain can find the least cost path to the other Node which advertising its Node segment in IGP extension, every Node has its Node-segment and adj-segments for itself, these SIDs must be assigned by Node itself, not by other Nodes within SR-enabled domain.

From example described in section "5.1 Range" in your draft, I deduced, within SR domain, each node must assign independently a unique SID or more for other every Node from its perspective, for example, for Node 100, Node 1 can assign Node SID#11 to the Node 100, and Node 3 can assign Node SID#13 to Node 100, it means that Node 1 is segment ingress node for SID 11 whose instruction correspond to going to Node 100 via least cost path, Node 3 is segment ingress node for SID 13 to Node 100, following this way, How the ingress PE node calculate the E2E SR path within domain, because the ingress PE must know all different Segment SIDs assigned by every Node from its perspective, that is to say, in your case, one Node must receive 4999*4999 Node SIDs, 4999 for each Node, in order to achieve this goal, every Node must advertise all other Nodes' Node segments assigned by itself from its perspective, but it may be not possible, because each node has to advertise lots of SIDs in IGP extension, it is complex.

Although a good SIDs assigning way described in section "5.3 Assigning SIDs to Node segments", but meaning of this way in fact is not same as your essential meaning of your section 5.1.  in fact you have used the global significance of SID, and each Node assign SID to itself and in further advertising it in IGP extension. 

--------------------------------------
Thank you !

WANG Weibin  

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Ron Bonica
Sent: 2019年8月28日 23:38
To: SPRING WG <[email-masked]>; IPv6 List <[email-masked]>
Subject: [spring] FW: New Version Notification for draft-bonica-spring-srv6-plus-05.txt

FYI

Juniper Public

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Wednesday, August 28, 2019 11:31 AM
To: Ron Bonica <[email-masked]>; Shraddha Hegde <[email-masked]>; Andrew Alston <[email-masked]>; Gang Chen <[email-masked]>; Joel Halpern <[email-masked]>; Andrew Alston <[email-masked]>; Daniam Henriques <[email-masked]>; Jen Linkova <[email-masked]>; Yuji Kamite <[email-masked]>
Subject: New Version Notification for draft-bonica-spring-srv6-plus-05.txt

Abstract:

The IETF Secretariat
_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring

---

From: Ron Bonica <[email-masked]>
Date: Fri, 30 Aug 2019 15:23:05 +0000

Hi Wang,

I think that we are in agreement about how thing actually work. For example, assume the following:

- An SRv6+ domain contains Nodes A-Z
- On Node A, an network operator configures a node segment endpoint and associates the node segment endpoint with SID A
- IS-IS floods the node segment endpoint and SID throughout the IGP domain
- Node B builds Node Segment B-A and associates SID A with that segment 
- Node C builds Node Segment C-A and associates SID A with that segment 
- And so on until Node Z builds Node Segment Z-A and associates SID A with that segment 

I think that our disagreement is whether SID A, above, is a global SID or a node local SID. 

If you think that a SID identifies a segment, then it is node-local. This is because a single SID (i.e., A) identifies 25 different segments (i.e., Segments B-A through Z-A). 

If you think that a SID identifies an instruction that a) can be instantiated on multiple nodes and b) forwards a packet from the node upon which it is instantiated to Node A, then t is global.

Whether we call the SID local or global is really secondary, so long as we agree on how things work. If the text confuses the WG, I would be happy to change it.

                                                                                                                       Ron

Juniper Public

-----Original Message-----
From: Wang, Weibin (NSB - CN/Shanghai) <[email-masked]> 
Sent: Friday, August 30, 2019 10:23 AM
To: Ron Bonica <[email-masked]>; SPRING WG <[email-masked]>; IPv6 List <[email-masked]>
Subject: RE: New Version Notification for draft-bonica-spring-srv6-plus-05.txt

Ron:

WANG Weibin  

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Ron Bonica
Sent: 2019年8月28日 23:38
To: SPRING WG <[email-masked]>; IPv6 List <[email-masked]>
Subject: [spring] FW: New Version Notification for draft-bonica-spring-srv6-plus-05.txt

FYI

Juniper Public

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Wednesday, August 28, 2019 11:31 AM
To: Ron Bonica <[email-masked]>; Shraddha Hegde <[email-masked]>; Andrew Alston <[email-masked]>; Gang Chen <[email-masked]>; Joel Halpern <[email-masked]>; Andrew Alston <[email-masked]>; Daniam Henriques <[email-masked]>; Jen Linkova <[email-masked]>; Yuji Kamite <[email-masked]>
Subject: New Version Notification for draft-bonica-spring-srv6-plus-05.txt

Abstract:

The IETF Secretariat
_______________________________________________
spring mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwIGoQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=Y7tg_WdE6dDTbLTNP7fA4mmVNhGtWb9D_1Q0A228DOE&s=fDRQpSgY2T772Uheoj6CZ-n_K2TdcHCoa9_Mtz2GHGY&e=