[rbridge] TTL only - was RE: New fields in shim header?

[Silvano Gai]

Joe,

Are you advocating a model in which TRILL add an Ethernet shim header
containing the TTL only? No RBridge addresses/nicknames?

IMO, without a level of addressing at the RBridge level the forwarding
is not flexible and scalable.

-- Silvano

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Joe Touch
Sent: Wednesday, October 11, 2006 9:46 PM
To: Radia Perlman
Cc: rbridge at postel.org
Subject: Re: [rbridge] New fields in shim header?



Radia Perlman wrote:
> 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

Of these, only the TTL seems absolutely required; that includes the ones
below. Keeping the shim minimal seems important (to reduce MTU impact,
in particular). If further IP functionality is required - e.g., diffserv
code point-like f-tags, or source-routes-like LIDs - then perhaps we
shouldn't be doing this at the link layer, IMO.

Joe

> ****************
> 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
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge