Ole,
If you want to conserve space in the registry, you can do one of the following:
- 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
