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)
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
