Ron, > If you want to conserve space in the registry, you can do one of the > following:
I don't think I said I wanted to conserve space outright. But it is an 8-bit number space, so clearly if anyone wants more bits than that, they cannot rely on the protocol field. Note I'm arguing this purely on principle, I don't know the network programming use case. It is also a name space shared by both IPv4 and IPv6, and would this mean we were going to define next headers that were only valid after an SRH header? Ole > > - Update RFC 8200, redefining value 59 to mean "VPN Payload - type > unspecified" > - Update RFC 8200, redefining value 59 to mean "IP Processing Stops Here" > - Allocate a new type called "VPN Payload - type unspecified" > - Allocate a new type called "IP Processing Stops here" > > Ron > > > > Non-Juniper > >> -----Original Message----- >> From: Ole Troan <[email protected]> >> Sent: Wednesday, May 8, 2019 2:14 PM >> To: Ron Bonica <[email protected]> >> Cc: Bob Hinden <[email protected]>; Tom Herbert >> <[email protected]>; SPRING WG <[email protected]>; 6man WG >> <[email protected]> >> Subject: Re: SRv6 Network Programming: ENH = 59 >> >> Ron, >> >>> <adding the SPRING mailing list, because this is a SPRING draft> >>> >>> Folks, >>> >>> Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming- >> 00 define a set of SIDs that have the following things in common: >>> >>> - they are consumed by the egress node (SL == 0) >>> - they tell the egress node how to forward the payload into a VPN >>> >>> If the payload is IPv4, the next-header value in the SRH must be IP4 (value >> 4). >>> If the payload is IPv6, the next-header value in the SRH must be IPv6 (value >> 41). >>> If the payload is Ethernet, the next-header value in the SRH must be No Next >> Header (value 59). >>> >>> In the interest of consistency, we should probably allocate a new next- >> header value for Ethernet and use it. >> >> It's a fairly precious name space though. >> What would a general IP stack do with an Ethernet frame? It's kind of a neat >> feature that "IP processing terminates here". >> Or are we going to specify Ethernet over IP? >> >> Cheers, >> Ole _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
