On Jan 8, 2017, at 10:18 AM, Francesco Fondelli <francesco.fondelli@xxxxxxxxx> wrote:
> point 3 and probably point 4, are too risky. If we go against the best
> current practice (RFC 4928, BCP 128) we need a very-very strong
> indication that the following data is not IP. I agree on everything
> else.
We need to fix bug 13301 somehow. BCP nonwithstanding, RFC 4448 says:
The features that the control word provides may not be needed for a
given Ethernet PW. For example, ECMP may not be present or active on
a given MPLS network, strict frame sequencing may not be required,
etc. If this is the case, the control word provides little value and
is therefore optional. Early Ethernet PW implementations have been
deployed that do not include a control word or the ability to process
one if present. To aid in backwards compatibility, future
implementations MUST be able to send and receive frames without the
control word present.
and the captures in that bug may be real rather than synthesized (some obscure companies named "Cisco" and "Huawei" has OUIs that have 4 as the first nibble and some obscure companies named "Hewlett-Packard" and "Juniper" has OUIs that have 6 as the first nibble).
As I said:
>> We might also want to have a preference to deal with the "first nibble of the MAC address is 4 or 6" issue.
So perhaps what we should do is either
1) have the "does this look like Ethernet" check *also* check whether the packet looks sufficiently like an IPv4 or IPv6 packet;
2) have a preference to indicate whether to use the "heuristically check whether this looks like Ethernet" first for all MPLS payload not explicitly processed by specific label bindings (manually using Decode As might not scale if there are a significant number of labels carrying that traffic);
3) both of them, in case the heuristics aren't sufficient for safety.
