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

[Joe Touch]

Silvano Gai wrote:
> Joe,
> 
> Are you advocating a model in which TRILL add an Ethernet shim header
> containing the TTL only? No RBridge addresses/nicknames?

Not necessarily, but it's clear that only TTL is *required*, and
everything else ought to have a very strong reason for inclusion.

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

It would be useful to explain. In particular:

- how do rbridge addresses/nicknames enable flexibility vs. either VLAN
tags or the outer ethernet addresses?

- how does the lack of such tags affect scalability, *especially* given
that the solution is not intended to scale beyond that of current
ethernet deployments (we've discussed this before, and that was the WG
consensus).

- which nodes would this affect?

- why is it important to carry decapsulation forwarding information in
the packet? (e.g., for the new proposal)

Joe

> -- 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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061012/ac192c7d/signature.bin