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

["Joel M. Halpern" <[e-mail]>]

I think it is equally important to note that given an existing way of 
encapsulating Ethernet in IP, one ought to have a good reason for 
creating a different one.  There is no indication that this use case 
needs anything different than next-header 97.

And Ole, no next-header does not, as far as I can tell from 8200 and its 
predecessors mean "the end of IP processing."

Yours,
Joel

On 5/9/19 7:17 AM, Stewart Bryant wrote:
> 
> 
> On 09/05/2019 10:12, Ole Troan wrote:
>>
>>
>>> On 9 May 2019, at 11:05, Stewart Bryant <[e-mail]> 
>>> wrote:
>>>
>>>
>>>
>>>> On 08/05/2019 19:13, Ole Troan wrote:
>>>> 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.
>>>
>>> Agreed, it has to last for the entire lifetime of the Internet.
>>>
>>> Indeed, I wonder if we should do what we did with MPLS 
>>> reserved/special purpose labels and create an extension mechanism now 
>>> rather than when
>>> we actually run out of space. That way less critical applications
>>> can use the less convenient longer identifier.
>>>
>>>> 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?
>>>
>>> Looking at NH=97 there seems to be an existing solution in place that 
>>> exactly addresses the need for carrying Ethernet over IP, so I don't 
>>> see why that is not used. It is only 16 bits and a single check to 
>>> confirm the version, and if implementers and operators are convinced 
>>> that the IP address is sufficiently safe as a check, then it is only 
>>> two extra bytes to write on transmit and two bytes to skip receive.
>>>
>>> The extra bits that NH=97 has reserved may also be useful in the long 
>>> term. For example it seems likely that an OAM/ACH mechanism will 
>>> eventually be needed at this encapsulation layer (just as it was 
>>> eventually needed with the Ethernet over MPLS pseudowire). It would 
>>> be hard to retrofit an OAM indicator with NH=59, but trivial with NH=97.
>>> So trivial in fact, I suspect that it ought be considered as part of 
>>> the initial specification.
>>>
>>> I suspect that we will be far more likely regret this use of 59 in 
>>> the long term than we will regret changing to 97 at this early stage.
>>
>> But it’s not that nh=59 can be used to imply that Ethernet follows. 
>> That would be very bad.
>>
>> It’s that ip processing stops here.
>>
>> Then if the two ends have agreed the meaning of the remaining payload 
>> and how to process it, that’s fine. If that signaling is in-band e.g 
>> in a particular SID or out-of-band, the principle is the same.
> 
> Yes, but experience suggests that having no control word and no ability 
> to retrofit one is a long term problem waiting to happen.
> 
> Stewart
> 
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring