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

[Ole Troan <[e-mail]>]

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 <[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