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

[Stewart Bryant <[e-mail]>]

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