[rbridge] New fields in shim header?

[Radia Perlman]

Silvano Gai has posted an interest draft suggesting new fields for the 
shim header.
The draft is at:
http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-00.txt

If new fields are added, we'll have to give up on the MPLS-like 
encoding, and the shim header
would be slightly larger, so we should consider each of these fields and 
see whether people think
the functionality they give warrants the extra space in the shim header.

I think it might be best to start a thread about each field separately. 
But I'll summarize here.

The current shim header contains:
a) RBridge nickname, which is either egress or ingress RBridge depending 
on whether it is
directed unicast or not. This fits in MPLS's 20-bit Label field with one 
bit indicating whether
the RBridge nickname is the ingress (multicast) or egress (directed 
unicast).

b) TTL

c) priority

****************
The proposed extra fields for the shim header are:
a) have BOTH ingress and egress RBridge nicknames, and shrink the 
nicknames down to 16 bits.
The reason for this is that in the case of directed unicast policy (such 
as source address filtering)
can be applied to ingress as well as egress RBridge).

b) F-Tag: I think of this as a metric identifier, proposed length 
10-bits. This enables setting multiple
costs for each link, and calculating paths and trees differently for 
different types of traffic

c) egress LID ("local identifier"). This is for the convenience of the 
egress RBridge---for example, it could
be the port onto which the (decapsulated) frame should be forwarded. It 
saves the egress RBridge
from looking up the destination address in the original frame (since the 
ingress RBridge already
had to do that work). The ingress RBridge knew the LID to put in because 
the egress RBridge had
announced (my nickname, LID) for that destination. The ingress RBridge 
does not interpret the LID---just
sticks it into the shim header.

d) ingress LID  The only reason I think to have an ingress
LID is in case at some point in the future learning of (destination MAC 
address corresponds to
egress RBridge, LID) is done based on looking at data packets. 
Otherwise, this would be learned
from link state advertisements, and only one LID (egress LID) would be 
in the shim.

Anyway---the format of the shim is something we really should decide on 
and attempt to never change
in the future. I don't have strong opinions. What do other people think?

If you care about any of these fields (pro or con) start a thread with 
subject line, e.g., "F-tag in shim header".
Or maybe I'll do it. Or for now, reply to this note with opinions about 
any of the fields.

Thanks,

Radia