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

[Stewart Bryant <[e-mail]>]

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.

- Stewart


> 
> Cheers,
> Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>