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

[Stewart Bryant <[e-mail]>]

On 08/05/2019 19:34, Sander Steffann wrote:

> The whole point of these identifies is to tell the reader what the meaning is of what follows. Using value 59 like this looks like "when we say 'no-next-header' we actually mean 'ethernet' (probably)". That's just bad engineering, and reminds me of MPLS implementations that tried to guess what the payload was by looking at the first nibble (if it's 4 then it's probably an IPv4 packet, if it's a 6 then it's probably IPv6 and otherwise we treat it as ethernet). That kind of worked until MAC addresses starting with 4 and 6 started to be used... Let's not make such mistakes again and put proper labels on our payloads.

Exactly.

The exception that allowed Ethernet Pseudowires (PW) to run without the 
PW control word was introduced because some hardware could not process 
the control word at the time of initial roll-out. This led
to many complexities over the development life of PWs.

Eventually PALS had requests from both the operator community and the 
IEEE to address this problem which is why the latest RFC produced by the 
PALS WG is:

"Recommendation to Use the Ethernet Control Word"
https://datatracker.ietf.org/doc/rfc8469/

Referring back to the email I just sent earlier, a consequence of 
allowing Ethernet to run without the control word was significant 
complexity around PW OAM. OAM was also something that we did not 
originally think would be needed when we started the PW design around 
the year 2000, but we soon found out that it was an integral part of PW 
operations.

With NH=97 you have the bits that you need to introduce the essential 
characteristics of a control word - version and some bits for an 
associated channel identifier. The ACH identifier space available is 
much less in NH=97 than in the PW Control Word. However so far there 
have only been 24 channels (plus 8 Experimental Channels) allocated for 
use with Ethernet over MPLS PWs, so it ought to be possible to provide 
all of the support services needed in the 16 bits available in NH=97 
rather than requiring the 32 bits we used in PWs.

https://www.iana.org/assignments/g-ach-parameters/g-ach-parameters.xhtml

Of course if it turns out that 16 bits is not enough, then NH=97 has
a version field which allows the seamless introduction of new features
without needing a new NH type provided the version field check is
mandatory in the first version of the Standard.

- Stewart (PWE3 and then PALS chair)