Ron, > On Jul 6, 2019, at 2:05 PM, Ron Bonica <[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://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > Juniper Business Use Only > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
