Ole,
Whatever we decide, I will use the same value in draft-bonica-6man-vpn-dest-opt.
Ron
Juniper Internal
> -----Original Message-----
> From: Ole Troan <otr...@employees.org>
> Sent: Wednesday, May 8, 2019 3:33 PM
> To: Ron Bonica <rbon...@juniper.net>
> Cc: Bob Hinden <bob.hin...@gmail.com>; Tom Herbert
> <t...@herbertland.com>; SPRING WG <spring@ietf.org>; 6man WG
> <i...@ietf.org>
> Subject: Re: SRv6 Network Programming: ENH = 59
>
> 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 <otr...@employees.org>
> >> Sent: Wednesday, May 8, 2019 2:14 PM
> >> To: Ron Bonica <rbon...@juniper.net>
> >> Cc: Bob Hinden <bob.hin...@gmail.com>; Tom Herbert
> >> <t...@herbertland.com>; SPRING WG <spring@ietf.org>; 6man WG
> >> <i...@ietf.org>
> >> 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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
