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

From: Ron Bonica <[email-masked]>
Date: Tue, 2 Jul 2019 02:33:00 +0000

Folks,

Please review this draft and comment.

                                   Ron

Juniper Business Use Only

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Monday, July 1, 2019 10:27 PM
To: Ron Bonica <[email-masked]>; Andrew Alston <[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-00.txt

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

Name:		draft-bonica-spring-srv6-plus
Revision:	00
Title:		IPv6 Support for Segment Routing: SRv6+
Document date:	2019-07-01
Group:		Individual Submission
Pages:		23
URL:            https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D00.txt&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=nl07p8dP3iQ-0u6rwI1U6jjp_wqSYhsPge2Y6i5Fo5I&s=f9eRsPzrKToGvL0_wpMx9GAiF85cBkn2my6nyMx5_3c&e= 
Status:         https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus_&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=nl07p8dP3iQ-0u6rwI1U6jjp_wqSYhsPge2Y6i5Fo5I&s=i5EeePVTP8VTbcR4Tpnv_hZo97c6qRVc8ZNPyfEDugA&e= 
Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D00&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=nl07p8dP3iQ-0u6rwI1U6jjp_wqSYhsPge2Y6i5Fo5I&s=CK39cv9JYjduX8ZtyCxs49VG31Ijs5p6Dmz6ka7JDQ4&e= 
Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=nl07p8dP3iQ-0u6rwI1U6jjp_wqSYhsPge2Y6i5Fo5I&s=2Ya6wV9Pug7Yh-vebYFvEsuuY9vpaA9dKNmD6egK8yM&e= 

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 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: "Andrew G. Malis" <[email-masked]>
Date: Tue, 2 Jul 2019 07:14:30 -0400

Ron,

Just curious - since draft-ietf-6man-segment-routing-header is in 6man,
shouldn't this be aimed at 6man as well?

Cheers,
Andy

On Mon, Jul 1, 2019 at 10:33 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> To: Ron Bonica <[email-masked]>; Andrew Alston <
> [email-masked]>; Joel Halpern <[email-masked]>;
> Andrew Alston <[email-masked]>; Daniam Henriques <
> [email-masked]>; Jen Linkova <[email-masked]>; Yuji
> Kamite <[email-masked]>
> URL:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D00.txt&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=nl07p8dP3iQ-0u6rwI1U6jjp_wqSYhsPge2Y6i5Fo5I&s=f9eRsPzrKToGvL0_wpMx9GAiF85cBkn2my6nyMx5_3c&e=
> Status:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus_&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=nl07p8dP3iQ-0u6rwI1U6jjp_wqSYhsPge2Y6i5Fo5I&s=i5EeePVTP8VTbcR4Tpnv_hZo97c6qRVc8ZNPyfEDugA&e=
> Htmlized:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D00&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=nl07p8dP3iQ-0u6rwI1U6jjp_wqSYhsPge2Y6i5Fo5I&s=CK39cv9JYjduX8ZtyCxs49VG31Ijs5p6Dmz6ka7JDQ4&e=
> Htmlized:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=nl07p8dP3iQ-0u6rwI1U6jjp_wqSYhsPge2Y6i5Fo5I&s=2Ya6wV9Pug7Yh-vebYFvEsuuY9vpaA9dKNmD6egK8yM&e=
>
>
> 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.
>
> The IETF Secretariat
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Bob Hinden <[email-masked]>
Date: Tue, 2 Jul 2019 08:55:21 -0700

Andy,

> On Jul 2, 2019, at 4:14 AM, Andrew G. Malis <[email-masked]> wrote:
> 
> Ron,
> 
> Just curious - since draft-ietf-6man-segment-routing-header is in 6man, shouldn't this be aimed at 6man as well?

I wondered about this as well, but reading this briefly, this draft doesn’t define any new IPv6 bits, there are two other drafts that do.  See:

bonica-6man-comp-rtg-hdr, and
bonica-6man-seg-end-opt

Bob

> 
> Cheers,
> Andy
> 
> 
> On Mon, Jul 1, 2019 at 10:33 PM Ron Bonica <rbonica=[email-masked]> wrote:
> Folks,
> 
> URL:            https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf..org_internet-2Ddrafts_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D00.txt&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=nl07p8dP3iQ-0u6rwI1U6jjp_wqSYhsPge2Y6i5Fo5I&s=f9eRsPzrKToGvL0_wpMx9GAiF85cBkn2my6nyMx5_3c&e=
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 2 Jul 2019 13:44:05 -0400

Bob,

Thanks, that explains it.

Cheers,
Andy

On Tue, Jul 2, 2019 at 11:55 AM Bob Hinden <[email-masked]> wrote:

> I wondered about this as well, but reading this briefly, this draft
> doesn’t define any new IPv6 bits, there are two other drafts that do.  See:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf..org_internet-2Ddrafts_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D00.txt&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=nl07p8dP3iQ-0u6rwI1U6jjp_wqSYhsPge2Y6i5Fo5I&s=f9eRsPzrKToGvL0_wpMx9GAiF85cBkn2my6nyMx5_3c&e=
> > Status:

---

From: Ron Bonica <[email-masked]>
Date: Wed, 3 Jul 2019 17:32:14 +0000

Hi Andy,

The draft is relevant to both working groups. So I announced it to both WGs and will let the chairs decide where it belongs.

                                                          Ron

From: Andrew G. Malis <[email-masked]>
Sent: Tuesday, July 2, 2019 7:15 AM
To: Ron Bonica <[email-masked]>
Cc: SPRING WG <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: [spring] FW: New Version Notification for draft-bonica-spring-srv6-plus-00.txt

Ron,

Cheers,
Andy

On Mon, Jul 1, 2019 at 10:33 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Folks,

                                   Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Monday, July 1, 2019 10:27 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Joel Halpern <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Daniam Henriques <[email-masked]<mailto:[email-masked]>>; Jen Linkova <[email-masked]<mailto:[email-masked]>>; Yuji Kamite <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-bonica-spring-srv6-plus-00.txt

URL:            https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf..org_internet-2Ddrafts_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D00.txt&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=nl07p8dP3iQ-0u6rwI1U6jjp_wqSYhsPge2Y6i5Fo5I&s=f9eRsPzrKToGvL0_wpMx9GAiF85cBkn2my6nyMx5_3c&e=<https://urldefense..proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D00.txt&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=nl07p8dP3iQ-0u6rwI1U6jjp_wqSYhsPge2Y6i5Fo5I&s=f9eRsPzrKToGvL0_wpMx9GAiF85cBkn2my6nyMx5_3c&e=>

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<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=CWk0cNP1awx3ax13K9hMwuOdfEJwZNQvIbmbtXJ8EXk&s=I6_hAtV4ceZxaDhXiKHvJEGLKy_RROG_SE8CeB0_nlo&e=>.

The IETF Secretariat
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=CWk0cNP1awx3ax13K9hMwuOdfEJwZNQvIbmbtXJ8EXk&s=1EfiBF4sRUCINCa1hb-JdPRQD6Qe8hILack0ZnkXEvU&e=>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 3 Jul 2019 11:48:29 -0700

Hi Ron,

Thanks for the draft.

I think the name SRV6+ might be a little misleading in that it could
be misinterpreted as SRV6+ being a superset of SRV6. Specifically,
SRV6+ doesn't allow 128 bit SIDs which seems inherent in SRV6 and so
the primary function (and implementation) of SRV6 isn't compatible. It
doesn't seem like it would be that much effort to allow a 128 bit SID
size to be compatible.

I don't understand the rationale for needing a MSV to be explictly
configured throughout the domain. Couldn't the appropriate SID size be
chosen by the sender at run time. For instance, if all the SIDs in a
list are less than 65,536 then 16 bit SIDs can be used, else 32 bit
SIDs are used (I assume 16 and 32 bit SIDs are in same number space).
Since CRH has the bits stating the SID length there is no ambiguity at
the receiver. SID compression is opportunistic and it's always good
practice to avoid situations that require wide scale renumbering.

Please add a section on mutability requirements of protocol fields so
that there is no ambiguity.

Tom

---

From: Ron Bonica <[email-masked]>
Date: Wed, 3 Jul 2019 19:44:16 +0000

Hi Tom,

Thanks for the review.

On Friday, I will update draft-bonica-6man-comp-rtg-hdr. It will contain a section on mutability. It will say:

- the Segments Left field is mutable
- every other field in the CRH is immutable

I will also update draft-bonica-6man-vpn-dest-opt and draft-bonica-6man-seg-end-opt. Both of those request an IANA option type with the CHG bit equal to 0. So they are both immutable.

SID encoding isn't entirely opportunistic. Since the last IETF, we realized that it would be burdensome for every vendor  to support all three SID lengths. So, we said that implementations MUST support 32-bit encoding and MAY support 16 bit encoding. (We dropped 8-bit encoding entirely).

A side effect of this decision is that a node should only send CRH's with 16-bit encoding every other node in the domain supports 16-bit encoding. So, network operators will need to configure the SID length on each node, with the default being 32.

                                                                             Ron

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Wednesday, July 3, 2019 2:48 PM
To: Ron Bonica <[email-masked]>
Cc: SPRING WG <[email-masked]>; 6man WG <[email-masked]>
Subject: Comments on draft-bonica-spring-srv6-plus

Hi Ron,

Thanks for the draft.

I think the name SRV6+ might be a little misleading in that it could be misinterpreted as SRV6+ being a superset of SRV6. Specifically,
SRV6+ doesn't allow 128 bit SIDs which seems inherent in SRV6 and so
the primary function (and implementation) of SRV6 isn't compatible. It doesn't seem like it would be that much effort to allow a 128 bit SID size to be compatible.

I don't understand the rationale for needing a MSV to be explictly configured throughout the domain. Couldn't the appropriate SID size be chosen by the sender at run time. For instance, if all the SIDs in a list are less than 65,536 then 16 bit SIDs can be used, else 32 bit SIDs are used (I assume 16 and 32 bit SIDs are in same number space).
Since CRH has the bits stating the SID length there is no ambiguity at the receiver. SID compression is opportunistic and it's always good practice to avoid situations that require wide scale renumbering.

Please add a section on mutability requirements of protocol fields so that there is no ambiguity.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Wed, 3 Jul 2019 13:06:10 -0700

> SID encoding isn't entirely opportunistic. Since the last IETF, we realized that it would be burdensome for every vendor  to support all three SID lengths. So, we said that implementations MUST sup…

This sounds dicey from an interoperability and flexibility point of
view. Supposed I've deployed a network where everyone is using 16 bits
SIDs. But, then for some reason I need to switch vendors for a small
part of the network and their implementation doesn't support 16 bits.
Do I need to up the MSV and make all SIDs to be 32 bits just on the
off chance that one of the new nodes might be in some SID list?

> A side effect of this decision is that a node should only send CRH's with 16-bit encoding every other node in the domain supports 16-bit encoding. So, network operators will need to configure the S…

Well, in light the above problem, I have to wonder if it's better to
only support 32 bits. The leap from 128 bits to 32 bits is much more
consequential than going from 32 to 16 bits. Other than that, it
simplifies the protocol, reduces support and test matrix, ensures
interoperability, etc.

Tom

---

From: Mark Smith <[email-masked]>
Date: Thu, 4 Jul 2019 11:07:30 +1000

On Thu., 4 Jul. 2019, 06:06 Tom Herbert, <[email-masked]> wrote:

> > I will also update draft-bonica-6man-vpn-dest-opt and
> draft-bonica-6man-seg-end-opt. Both of those request an IANA option type
> with the CHG bit equal to 0. So they are both immutable.
> >
> > SID encoding isn't entirely opportunistic. Since the last IETF, we
> realized that it would be burdensome for every vendor  to support all three
> SID lengths. So, we said that implementations MUST support 32-bit encoding
> and MAY support 16 bit encoding. (We dropped 8-bit encoding entirely).
>
> > A side effect of this decision is that a node should only send CRH's
> with 16-bit encoding every other node in the domain supports 16-bit
> encoding. So, network operators will need to configure the SID length on
> each node, with the default being 32.
>

One single size is much better.

I think most people will pick the larger size, regardless of their
functional SID space need, to avoid the possibility of getting it wrong and
then having to do a lot of after hours and possibly service impacting work
in the future to expand from the smaller to larger size.

Implementations would also be simpler, so less opportunities for
implementation bugs.

It also means no possibility of configuration errors because the size is a
constant rather than a settable parameter.

A lot of the principles in RFC 5505 - "Principles of Internet Host
Configuration" - seem to me to be equally applicable to network interior
protocols.

For example, I think the whole of "2.1. Minimize Configuration" fully
applies here.

Regards,
Mark.

> > I think the name SRV6+ might be a little misleading in that it could be
> misinterpreted as SRV6+ being a superset of SRV6. Specifically,
> doesn't seem like it would be that much effort to allow a 128 bit SID size
> to be compatible.
> >
> chosen by the sender at run time. For instance, if all the SIDs in a list
> are less than 65,536 then 16 bit SIDs can be used, else 32 bit SIDs are
> used (I assume 16 and 32 bit SIDs are in same number space).

---

From: Ron Bonica <[email-masked]>
Date: Sat, 6 Jul 2019 21:05:35 +0000

Hi Mark,

In my experience, operators object when SR overhead consumes more than 80 bytes. Also, I have encountered two classes of operator:

  *   Those who avoid strictly-routed segments
  *   Those who rely heavily on strictly-routed segments

Those who avoid strictly-routed segments rarely generate SID Lists that contain more than 8 entries. So, they are generally OK with 32-bit encoding. This is because with 32-bit encoding, the total SR overhead is exactly 80 bytes (i.e., 40 bytes for the IPv6 header and 40 bytes for the CRH).

By contrast, those who rely on strictly-routed segments regularly generate SID Lists that contain more than 8 entries. So, they are generally required 16-bit encoding.

IMHO, the operator understands its needs better than we do. We should support both. Let the operator decide at run time.

                                                                                                                 Ron

From: Mark Smith <[email-masked]>
Sent: Wednesday, July 3, 2019 9:08 PM
To: Tom Herbert <[email-masked]>
Cc: Ron Bonica <[email-masked]>; SPRING WG <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: Comments on draft-bonica-spring-srv6-plus

On Thu., 4 Jul. 2019, 06:06 Tom Herbert, <[email-masked]<mailto:[email-masked]>> wrote:

I think most people will pick the larger size, regardless of their functional SID space need, to avoid the possibility of getting it wrong and then having to do a lot of after hours and possibly service impacting work in the future to expand from the smaller to larger size.

Implementations would also be simpler, so less opportunities for implementation bugs.

It also means no possibility of configuration errors because the size is a constant rather than a settable parameter.

A lot of the principles in RFC 5505 - "Principles of Internet Host Configuration" - seem to me to be equally applicable to network interior protocols.

For example, I think the whole of "2.1. Minimize Configuration" fully applies here.

Regards,
Mark.

Tom

> From: Tom Herbert <[email-masked]<mailto:[email-masked]>>
> To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
> Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=h1HPGtWvJGktKCJMcb_UIbDF0WrfdBRAeoLqQwBlgsY&s=ulAeVo3sBVzIwVGNNlvIUtUN4ctFNBLaPQKpAbrIpl8&e=>
--------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Sat, 6 Jul 2019 14:41:44 -0700

Ron,

> On Jul 6, 2019, at 2:05 PM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Hi Mark,
> 

What is special about 80?   Why not 64, 128, 256?

Bob

> 
> 	• Those who avoid strictly-routed segments
> 	• Those who rely heavily on strictly-routed segments
> 
> > A side effect of this decision is that a node should only send CRH's with 16-bit encoding every other node in the domain supports 16-bit encoding.. So, network operators will need to configure the SID length on each node, with the default being 32.
>

---

From: Tom Herbert <[email-masked]>
Date: Sat, 6 Jul 2019 16:23:25 -0700

On Sat, Jul 6, 2019, 2:05 PM Ron Bonica <[email-masked]> wrote:

> Hi Mark,
>
>
>
> In my experience, operators object when SR overhead consumes more than 80
> bytes. Also, I have encountered two classes of operator:
>
>
>
>    - Those who avoid strictly-routed segments
>    - Those who rely heavily on strictly-routed segments
>
>
>
> Those who avoid strictly-routed segments rarely generate SID Lists that
> contain more than 8 entries. So, they are generally OK with 32-bit
> encoding. This is because with 32-bit encoding, the total SR overhead is
> exactly 80 bytes (i.e., 40 bytes for the IPv6 header and 40 bytes for the
> CRH).
>
>
>
> By contrast, those who rely on strictly-routed segments regularly generate
> SID Lists that contain more than 8 entries. So, they are generally required
> 16-bit encoding.
>
> IMHO, the operator understands its needs better than we do. We should
> support both. Let the operator decide at run time.
>

If devices the operator has deployed don't support all the modes, then it's
not really a decision the operator can make, especially if they are bound
by the least common denominator of support. This is the predicament of the
largest operators that have a variety of different vendor devices in
deployment.

Ron, I'm a little surprised that there is pushback on being to support two
SID sizes in an implementation. This doesn't seem all that complex to me,
especially in light of the complex functionality being defined in other low
level protocols such as SR. Can you, or someone who sees this as an issue,
provide a little more context on this problem?

Thanks,
Tom

>
>
> Ron
>
>
>
>
>
> *From:* Mark Smith <[email-masked]>
> *Sent:* Wednesday, July 3, 2019 9:08 PM
> *To:* Tom Herbert <[email-masked]>
> *Cc:* Ron Bonica <[email-masked]>; SPRING WG <[email-masked]>; 6man
> WG <[email-masked]>
> *Subject:* Re: Comments on draft-bonica-spring-srv6-plus
>
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=h1HPGtWvJGktKCJMcb_UIbDF0WrfdBRAeoLqQwBlgsY&s=ulAeVo3sBVzIwVGNNlvIUtUN4ctFNBLaPQKpAbrIpl8&e=>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 8 Jul 2019 22:28:58 +0000

Bob,

SR encodings that require 128-bytes of overhead consume excessive bandwidth:

- on network links
- in ASICS

While the former is interesting, the later is probably more significant.  In order to process at high speeds, ASICs need to access the entire IPv6 header chain. So, they copy the header chain, including all extension headers,  from buffer memory to on-chip memory. As the number of bytes in the header chain increases, so does the cost of that copy. And the longer the header chain, the less accessible the technology becomes to low-cost ASICs.

So, the most significant benefit may be  in keeping that copy under 128 bytes.

                                                                                                       Ron

-----Original Message-----
From: Bob Hinden <[email-masked]>
Sent: Saturday, July 6, 2019 5:42 PM
To: Ron Bonica <[email-masked]>
Cc: Bob Hinden <[email-masked]>; Mark Smith <[email-masked]>; Tom Herbert <[email-masked]>; SPRING WG <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Comments on draft-bonica-spring-srv6-plus

Ron,

Bob

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 8 Jul 2019 18:47:31 -0400

While one can argue forever abotu where the critical points are, I think 
we all know that all other things being equal (yeah, I know, they never 
are) smaller is better.
It thus seems clear to me that we should simply mandate support for both 
16 and 32 bit SIDs in the CRH.

Yours,
Joel

---

From: Bob Hinden <[email-masked]>
Date: Mon, 8 Jul 2019 22:28:31 -0700

Ron,

> On Jul 8, 2019, at 3:28 PM, Ron Bonica <[email-masked]> wrote:
> 
> Bob,
> 

So there is nothing special about 80 when you said "operators object when SR overhead consumes more than 80 bytes” other than it is less than 128 (or some other implementation specific number).

Bob

---

From: Ron Bonica <[email-masked]>
Date: Tue, 9 Jul 2019 13:01:20 +0000

Mark, Tom,

Would mandating both satisfy your objections?

                                      Ron

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Monday, July 8, 2019 6:48 PM
Cc: SPRING WG <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: [spring] Comments on draft-bonica-spring-srv6-plus

While one can argue forever abotu where the critical points are, I think we all know that all other things being equal (yeah, I know, they never
are) smaller is better.
It thus seems clear to me that we should simply mandate support for both
16 and 32 bit SIDs in the CRH.

Yours,
Joel

On 7/8/19 6:28 PM, Ron Bonica wrote:
> Cc: Bob Hinden <[email-masked]>; Mark Smith 
> <[email-masked]>; Tom Herbert <[email-masked]>; SPRING WG 
> <[email-masked]>; IPv6 List <[email-masked]>
>> view. Supposed I've deployed a network where everyone is using 16 
>> bits SIDs. But, then for some reason I need to switch vendors for a 
>> small part of the network and their implementation doesn't support 16 bits.
>> Administrative Requests: 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>> lman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcW
>> zoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=6hBGzSjd8gWZ8Tbm
>> IE9-axKqsGSOS_eDBvbSVJQVZBo&s=5jHV8xT7UgFmm8UBSu3mgTeHSTvWUiRWm9da3g4
>> 8o5Y&e=
>> Administrative Requests: 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>> lman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcW
>> zoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=6hBGzSjd8gWZ8Tbm
>> IE9-axKqsGSOS_eDBvbSVJQVZBo&s=5jHV8xT7UgFmm8UBSu3mgTeHSTvWUiRWm9da3g4
>> 8o5Y&e=
> Administrative Requests: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzo
> CI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=6hBGzSjd8gWZ8TbmIE9
> -axKqsGSOS_eDBvbSVJQVZBo&s=5jHV8xT7UgFmm8UBSu3mgTeHSTvWUiRWm9da3g48o5Y
> &e=

_______________________________________________
spring mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=6hBGzSjd8gWZ8TbmIE9-axKqsGSOS_eDBvbSVJQVZBo&s=YYXoZxBfdVxmcXiO-tFkzBWknA5RrEzAz_IQTP1vy_0&e=

---

From: Mark Smith <[email-masked]>
Date: Tue, 9 Jul 2019 23:36:52 +1000

Hi Ron,

> Would mandating both satisfy your objections?

Well enough.

I still prefer the idea of a single size, however at least requiring
support for both sizes would avoid the trap of unintentionally buying a
device that can only do 16 bit SIDs when you're using 32 bit SIDs. That can
happen because that detail might be in small print on a spec sheet or
missed in an RFI/RFP response.

I think 32 bits should be the default SID size, so that people have to make
a conscious decision to use 16 bits, and therefore if 16 bits ends up being
too small in the future, they hopefully already know they'll be incurring
the operational costs and possible customer service impacts of having to
change from 16 to 32 SIDs.

Regards,
Mark.

> > While the former is interesting, the later is probably more
> significant.  In order to process at high speeds, ASICs need to access the
> entire IPv6 header chain. So, they copy the header chain, including all
> extension headers,  from buffer memory to on-chip memory. As the number of
> bytes in the header chain increases, so does the cost of that copy. And the
> longer the header chain, the less accessible the technology becomes to
> low-cost ASICs.
> >
> >> In my experience, operators object when SR overhead consumes more than
> 80 bytes. Also, I have encountered two classes of operator:
> >
> >> By contrast, those who rely on strictly-routed segments regularly
> generate SID Lists that contain more than 8 entries. So, they are generally
> required 16-bit encoding.
> >>
> >>> On Friday, I will update draft-bonica-6man-comp-rtg-hdr. It will
> contain a section on mutability. It will say:
> >>>
> encoding.. So, network operators will need to configure the SID length on
> >> It also means no possibility of configuration errors because the size
> is a constant rather than a settable parameter.
> >>

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Mon, 15 Jul 2019 01:42:35 +0000

Hi Ron:

According to following part of section#5 in srv6+ draft, 

+++
SIDs have node-local significance.  This means that a segment ingress
   node MUST identify each segment that it originates with a unique SID.
   However, a SID that is used by one segment ingress node to identify a
   segment that it originates can be used by another segment ingress
   node to identify another segment.
+++
Does it mean All type of SID have node-local significance in this draft? If I am correct, I think it is conflict with the content about SID type in your another draft "CRH", the loosely routed SID must have domain-wide significance.
The following sentences is from draft section 5 of CRH.
++++
Loosely routed SIDs have domain-wide significance.  This means that
   within a CRH domain, a loosely routed SID MUST map to exactly one
   IPv6 address.  By contrast, strictly routed SIDs have node-local
   significance.  This means that within a CRH domain, one node can map
   a strictly routed SID to one address while another node maps the same
   strictly routed SID to a different address.  See Appendix A for an
   example.
+++++++

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

WANG Weibin

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Ron Bonica
Sent: 2019年7月9日 6:29
To: Bob Hinden <[email-masked]>
Cc: Tom Herbert <[email-masked]>; SPRING WG <[email-masked]>; IPv6 List <[email-masked]>; Mark Smith <[email-masked]>
Subject: Re: [spring] Comments on draft-bonica-spring-srv6-plus

Bob,

- on network links
- in ASICS

                                                                                                       Ron

-----Original Message-----
From: Bob Hinden <[email-masked]>
Sent: Saturday, July 6, 2019 5:42 PM
To: Ron Bonica <[email-masked]>
Cc: Bob Hinden <[email-masked]>; Mark Smith <[email-masked]>; Tom Herbert <[email-masked]>; SPRING WG <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Comments on draft-bonica-spring-srv6-plus

Ron,

Bob

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Jul 2019 16:04:38 +0000

Weibin,

Thanks for your careful review and for this very insightful question. It does require some explanation.

Yes, all SIDs have node-local significance. This includes SIDs that represent strictly-routed segments as well as SIDs that represent loosely-routed segments. 

The text that you quote below, about loosely-routed SIDs having domain-wide significance, has been deleted from the currently posted version of draft-bonica-6man-comp-rtg-hdr.

And now for the explanation......

A SID is examined and processed by exactly one node (i.e., the ingress node of the segment that the SID represents). Therefore, even if an operator were to assign SIDs as if they had more global significance, they would still have node-local significance. That's all they need, because each SID is examined and processed by exactly one node.

Pursuing your question further, draft-bonica-lsr-isis-crh-extensions describes a mechanism that causes all loosely-routed segments terminating at a particular node to have the same SID. While this facilitates configuration and debugging, it is not strictly required. A controller could assign SIDs some other way and routing would still work.

An analogy might make this argument more palatable. Imagine a network operator that makes heavy use of IPv6 link-local addresses. In order to facilitate debugging, the operator configures IPv6 link-local addresses as if they had domain-wide significance. While this discipline may be significant and even useful to the network operator, it is coldly unnoticed by network devices.

                                                             Ron

-----Original Message-----
From: Wang, Weibin (NSB - CN/Shanghai) <[email-masked]> 
Sent: Sunday, July 14, 2019 9:43 PM
To: Ron Bonica <[email-masked]>; Bob Hinden <[email-masked]>
Cc: Tom Herbert <[email-masked]>; SPRING WG <[email-masked]>; IPv6 List <[email-masked]>; Mark Smith <[email-masked]>
Subject: RE: Comments on draft-bonica-spring-srv6-plus

Hi Ron:

+++

WANG Weibin

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Ron Bonica
Sent: 2019年7月9日 6:29
To: Bob Hinden <[email-masked]>
Cc: Tom Herbert <[email-masked]>; SPRING WG <[email-masked]>; IPv6 List <[email-masked]>; Mark Smith <[email-masked]>
Subject: Re: [spring] Comments on draft-bonica-spring-srv6-plus

Bob,

- on network links
- in ASICS

                                                                                                       Ron

-----Original Message-----
From: Bob Hinden <[email-masked]>
Sent: Saturday, July 6, 2019 5:42 PM
To: Ron Bonica <[email-masked]>
Cc: Bob Hinden <[email-masked]>; Mark Smith <[email-masked]>; Tom Herbert <[email-masked]>; SPRING WG <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Comments on draft-bonica-spring-srv6-plus

Ron,

Bob

> CI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=XHBhblXqRPQ3B3MXrgW
> aaG5S1rpL19W91khadzRJuQ8&s=MGMGhXEDBq7Aavhxrondm1PNtstBKgZ3_TaRPtXUvEc
> &e=
> CI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=XHBhblXqRPQ3B3MXrgW
> aaG5S1rpL19W91khadzRJuQ8&s=MGMGhXEDBq7Aavhxrondm1PNtstBKgZ3_TaRPtXUvEc
> &e=
_______________________________________________
spring mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=XHBhblXqRPQ3B3MXrgWaaG5S1rpL19W91khadzRJuQ8&s=aH7JIfGqjIdUmQdymQ0duOdskRuPtn7VDHCMAY6EJFs&e=