RE: Comments on draft-bonica-spring-srv6-plus

[Ron Bonica <[e-mail]>]

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





Juniper Business Use Only

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

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 <[e-mail]> On Behalf Of Ron Bonica
Sent: 2019年7月9日 6:29
To: Bob Hinden <[e-mail]>
Cc: Tom Herbert <[e-mail]>; SPRING WG <[e-mail]>; IPv6 List <[e-mail]>; Mark Smith <[e-mail]>
Subject: Re: [spring] Comments on draft-bonica-spring-srv6-plus

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





Juniper Business Use Only

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

Ron,

> On Jul 6, 2019, at 2:05 PM, Ron Bonica <rbonica=[e-mail]> wrote:
> 
> Hi Mark,
> 
> In my experience, operators object when SR overhead consumes more than 80 bytes. Also, I have encountered two classes of operator:

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
> 
> 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 <[e-mail]>
> Sent: Wednesday, July 3, 2019 9:08 PM
> To: Tom Herbert <[e-mail]>
> Cc: Ron Bonica <[e-mail]>; SPRING WG <[e-mail]>; 
> 6man WG <[e-mail]>
> Subject: Re: Comments on draft-bonica-spring-srv6-plus
> 
> 
> 
> On Thu., 4 Jul. 2019, 06:06 Tom Herbert, <[e-mail]> wrote:
> On Wed, Jul 3, 2019 at 12:44 PM Ron Bonica <[e-mail]> wrote:
> >
> > 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).
> 
> 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 SID length on each node, with the default being 32.
> 
> 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.
> 
> 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.
> 
> 
> 
> 
> Tom
> 
> >
> >                                                                              
> > Ron
> >
> >
> >
> > Juniper Business Use Only
> >
> > -----Original Message-----
> > From: Tom Herbert <[e-mail]>
> > Sent: Wednesday, July 3, 2019 2:48 PM
> > To: Ron Bonica <[e-mail]>
> > Cc: SPRING WG <[e-mail]>; 6man WG <[e-mail]>
> > 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
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> 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=XHBhblXqRPQ3B3MXrgW
> aaG5S1rpL19W91khadzRJuQ8&s=MGMGhXEDBq7Aavhxrondm1PNtstBKgZ3_TaRPtXUvEc
> &e=
> --------------------------------------------------------------------
> 
> Juniper Business Use Only
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> 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=XHBhblXqRPQ3B3MXrgW
> aaG5S1rpL19W91khadzRJuQ8&s=MGMGhXEDBq7Aavhxrondm1PNtstBKgZ3_TaRPtXUvEc
> &e=
> --------------------------------------------------------------------
_______________________________________________
spring mailing list
[e-mail]
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=