I would much rather see support for only 32-bit SIDs, with no other optional sizes. Optional sizes tend to become requirements, and lead to configuration hassles. Also, I see 80 bytes as much too small a goal to fit into. 128 bytes seems a more reasonable lower bound.
Regards, John On Tue, 09 July 2019 13:37 UTC Mark Smith <[email protected]> wrote: Hi Ron, On Tue., 9 Jul. 2019, 23:01 Ron Bonica, <rbonica= [email protected]>; wrote: > Mark, Tom, > > 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. > Ron > > > > Juniper Business Use Only > > -----Original Message----- > From: spring <[email protected]>; On Behalf Of Joel M. Halpern > Sent: Monday, July 8, 2019 6:48 PM > Cc: SPRING WG <[email protected]>;; IPv6 List <[email protected]>; > 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: > > 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 <[email protected]>; > > Sent: Saturday, July 6, 2019 5:42 PM > > To: Ron Bonica <[email protected]>; > > Cc: Bob Hinden <[email protected]>;; Mark Smith > > <[email protected]>;; Tom Herbert <[email protected]>;; SPRING WG > > <[email protected]>;; IPv6 List <[email protected]>; > > Subject: Re: Comments on draft-bonica-spring-srv6-plus > > > > Ron, > > > >> On Jul 6, 2019, at 2:05 PM, Ron Bonica <rbonica= > [email protected]>; 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 <[email protected]>; > >> Sent: Wednesday, July 3, 2019 9:08 PM > >> To: Tom Herbert <[email protected]>; > >> Cc: Ron Bonica <[email protected]>;; SPRING WG <[email protected]>;; > >> 6man WG <[email protected]>; > >> Subject: Re: Comments on draft-bonica-spring-srv6-plus > >> > >> > >> > >> On Thu., 4 Jul. 2019, 06:06 Tom Herbert, <[email protected]>; wrote: > >> On Wed, Jul 3, 2019 at 12:44 PM Ron Bonica <[email protected]>; 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 <[email protected]>; > >>> Sent: Wednesday, July 3, 2019 2:48 PM > >>> To: Ron Bonica <[email protected]>; > >>> Cc: SPRING WG <[email protected]>;; 6man WG <[email protected]>; > >>> 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 > >> [email protected] > >> 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= > >> -------------------------------------------------------------------- > >> > >> Juniper Business Use Only > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> [email protected] > >> 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= > >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] > > 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 protected] > > 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= > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
