Hi Ron, > Whatever we decide, I will use the same value in > draft-bonica-6man-vpn-dest-opt.
Ah, right. Because in your proposal the VPN Context Information contains the forwarding instructions? Seems a little underspecified in the draft, or am I missing something? And that is information signalled separately? Cheers, Ole > > 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
