Re: [spring] SRv6 Network Programming: ENH = 59

[Ron Bonica <[e-mail]>]

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 <[e-mail]>
> Sent: Wednesday, May 8, 2019 2:14 PM
> To: Ron Bonica <[e-mail]>
> Cc: Bob Hinden <[e-mail]>; Tom Herbert
> <[e-mail]>; SPRING WG <[e-mail]>; 6man WG
> <[e-mail]>
> 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