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

[Ron Bonica <[e-mail]>]

Ole,

Inline....

                Ron


Juniper Internal

> -----Original Message-----
> From: Ole Troan <[e-mail]>
> Sent: Wednesday, May 8, 2019 3:48 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
> 
> 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 <[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