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

[Ron Bonica <[e-mail]>]

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 <[e-mail]>
> Sent: Wednesday, May 8, 2019 3:33 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,
> 
> > 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 <[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