Ole,
Inline....
Ron
Juniper Internal
> -----Original Message-----
> From: Ole Troan <otr...@employees.org>
> Sent: Wednesday, May 8, 2019 3:48 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
>
> 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?
Yes.
> Seems a little underspecified in the draft, or am I missing something?
Standby for an update on the draft....
> And that is information signalled separately?
Yes. Standby for that draft, too.
Ron
>
> 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
