Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

[Thomas Narten <[e-mail]>]

(repost with proper subject)

I have read the document, and want to raise some basic questions about
this document.

An original premise for this document was that it would use the same
Ethertype=0x8100 encoding for the inner header as the the base
protocol. This was done for backwards-compatability with base RBs and
to allow non-FGL aware RBs to forward FGL frames. Under this
assumption, having the labels split into two different parts using
separate fields made sense.

However, with the -01 revision, the above assumption has been thrown
out. FGLs now use a different ethertype encoding, and various parts of
the document make it clear that an RB operates in either FGL or VL
mode, with no overlap or backwards compatability. RBs implementing VL
are not supposed to receive or process FGL formatted TRILL data
frames.

Given that, I do not see a compelling justification for retaining the
"double tagging" encoding format the current document
supports. Specifically, I'd suggest:

1) not having separate high-order and low-order FGL fields; just
define one field that is 24 bits long.

2) Remove the second ethertype=0x893B field completely. We are just
wasting 2 bytes. (the field serves no useful purpose and must always
hold the value of 0x893B.)

3) While I don't have a strong opinion either way, I would also like
to see a justification for having an "Alternate Priority" field. The
base TRILL protocol doesn't have one. Why is it needed for FGLs?

Under the previous encapsulation format, we got the extra priority
"for free" since it was part of the TAG, but I'd like to see the
rational/use case for having this extra field stand on its own
merits. Is this just a "what the heck, why not" field? Or is there a
compelling use case for it?

I am also uncomfortable with some of the wording in the document
regarding "silicon".

>    2. Silicon Considerations
> 
>       Fine-grained labeling (FGL) should, to the extent practical, use
>       existing features, processing, and fields that are already
>       supported in at least some fast path silicon implementations that
>       currently support the TRILL base protocol.

This makes sense. We do not want to pick encodings that will be
problematatic for silicon (generally).  However, we also need to
balance such a desire against not restricting our design solely to
favor, say, one particular implementation. (I am not suggesting that
is being done here, just pointing out that if the current encoding
does favor certain implementations, we need to be upfront about that,
and discuss the implications openly.)

>    2. Silicon Considerations: Existing TRILL fast path silicon chips can
>       perform base TRILL Header insertion and removal to support ingress
>       and egress. In addition, it is believed that most such silicon
>       chips can also perform the native frame to FGL mapping and the
>       encoding of the FGL as specified herein, as well as the inverse
>       decoding and mapping. Some existing silicon can perform only one
>       of these operations on a frame in the fast path and is thus not
>       suitable to implement fast path TRILL FGL processing; however,
>       other existing chips are believed to be able to perform both
>       operations on the same frame in the fast path and are suitable for
>       FGL implementation.

My impression in talking to folk familiar with silicon implementations
is that silicon has gotten pretty good at being able to extract fields
from fixed arbitrary offsets into a packet. Thus, while they may be
able to extract the two separate labels and combine them (as the
current proposal calls for), they can just as easily extract a single
label of 24 bits.

If we are going to stick with the current encoding, I'd like to hear
directly from the silicon implementors why that is *necessary* and why
they cannot support the more natural/obvious format for 24-bit labels.

I have additional comments on the draft, but they may not be relevant
depending on how the above points are resolved.

Thomas