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

[Silvano Gai]

Joe,

Let me focus on the need of RBridge addresses.

I didn't propose them; they are in the current WG draft:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
.txt
to achieve scalability at the ISIS level.

The outer MAC addresses are present only if the frame is sent over 802
link (section 2.9), but it may not be present on other media; therefore
TRILL cannot rely on them.

If you disagree with these two points, I think you disagree with the
work that has been done in TRILL till now.

What my draft adds is that addresses always come in pairs and there is a
value to have the source and destination RBridge addresses in the shim
header.

Let see if we are in synch up to here, then we can discuss the other
fields.

Cheers

-- Silvano

-----Original Message-----
From: Joe Touch [mailto:touch at ISI.EDU] 
Sent: Thursday, October 12, 2006 6:31 AM
To: Silvano Gai
Cc: Radia Perlman; rbridge at postel.org
Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?



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
>