[rbridge] TRILL header format, understanding the pros and cons (was "multicastpruning")

Thu Jun 14 22:30:42 PDT 2007

Sorry, Silvano,

I do believe it is worthwhile to calmly list all points for and against 
something even if the
issue has been decided. I understand the problem of a committee being 
like the
proverbial donkey starving because it is equidistant between two bales 
of hay and
can't decide which one to go to. And I understand also how at some 
point, unless
something is really broken, it's better to just go off in the original 
direction rather than
never converging.

However, I believe it is also always a useful exercise to summarize all 
the arguments
in one place. And sometimes when doing so, it might make sense to change 
the decision.

So...the way the TRILL header is now, intermediate RBridges have to find the
inner frame and look for:
a) VLAN tag (to do VLAN pruning)
b) the original destination address (in case it's an IP multicast, in 
order to do
IP multicast pruning)
c) the IP protocol type (for IGMP), and parsing enough of the IGMP 
message to
know that this is an IGMP reply (in order for it to get sent only to 
links with IP multicast
routers)

Moving the VLAN tag into the TRILL header (as a fixed field
rather than an option) makes the packet 2 bytes longer when there is no 
inner VLAN,
but makes the packet 2 bytes shorter when there was an inner VLAN 
(because the
VLAN can be deleted from the inner frame).

Signalling that the packet is an IGMP reply (so should be pruned to only 
send to
links with IP multicast routers) can be done with a single bit in the 
TRILL header.

Moving the original destination address into the TRILL header could 
theoretically
be done without adding to the length of the packet, by merely 
considering the
first 6 bytes of the packet to be the final 6 bytes of the TRILL header.

So the cost of moving these into the TRILL header are 2 bytes +1 bit, and
actually the 2 byte cost is only a cost when there was no VLAN tag in 
the inner header.

I'd think the advantages of doing so would be
a) easier for transit RBridges to make a forwarding decision
b) in a sense more "architecturally pure" since the transit RBridges 
would not
need to look at anything more than the TRILL header
c) if 802 invented a new kind of tag, since tags are not TLV encoded, 
transit RBridges
would not need to be upgraded to understand the new tag in order to find the
fields in the inner packet.

I'm not saying we have to change the TRILL format...I just want to 
carefully understand
the pros and cons. What arguments have I missed? (either more arguments 
for moving
everything necessary for forwarding into the TRILL header, or against it).

Thanks,

Radia

Silvano Gai wrote:
> Folks,
>
> We had a detailed discussion on the header format which included all the
> points that Radia list below. We had a strong consensus on one solution.
> The WG chairs confirmed this consensus on the mailing list.
>
> There is no new piece of information. We have not discovered anything
> that was not known at the time of the consensus. I propose we stick with
> the current header format.
>
> If we continue to change things we will never converge and the frame
> format needs to be stable ASAP.
>
> If we reopen the frame format discussion, then I want to reopen nickname
> vs address ;-) :-) :-) ;-)
>
> -- Silvano
>
>   
>> -----Original Message-----
>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
>>     
> On
>   
>> Behalf Of Radia Perlman
>> Sent: Thursday, June 07, 2007 1:29 PM
>> To: Eastlake III Donald-LDE008
>> Cc: rbridge at postel.org
>> Subject: Re: [rbridge] multicast pruning in TRILL
>>
>> (revisiting the issue of moving whatever is necessary for transit
>> bridges to look at
>> for pruning of multicasts (VLAN tag and destination multicast address)
>> to the portion of the frame outside the tunnel, i.e., either the TRILL
>> header or
>> the outer header)
>>
>> The mailing list archives are daunting, even though I've been trying
>>     
> to
>   
>> follow it all along.
>> I'd like to see the arguments both sides of this issue summarized
>>     
> rather
>   
>> than
>> pointing people at the mailing list -- just now I tried to review the
>> mailing list
>> on this issue and got discouraged. It never hurts to summarize the
>> issues again.
>>
>> I'll start by writing down concisely what I do remember, and perhaps
>> people can
>> concisely add other arguments:
>>
>> a) moving VLAN tag to TRILL header always: Pluses: it takes up fewer
>> bits total (since you
>> don't need the Ethertype) to include it as a tag in the inner header),
>> it's easier to find since
>> transit RBridges don't need to find the inner header,
>> the TRILL header is still fixed length.  Minuses: It takes up room
>>     
> even
>   
>> when there is
>> no VLAN tag in the inner header
>>
>> b) moving VLAN tag to TRILL header as an option: Pluses: it only takes
>> up room
>> when there is a VLAN tag in the inner frame. Minus: it makes the TRILL
>> header
>> variable length
>>
>> c) moving the inner multicast address (for IP multicast pruning) into
>> the TRILL header: I don't think this was discussed. But it would
>>     
> clearly
>   
>> have to be done as an option in the TRILL
>> header since we wouldn't want to make space for it in the TRILL header
>> on unicast
>> packets, so it would make the TRILL header variable length
>>
>> d) copying the inner multicast address (for IP multicast pruning) into
>> the *outer* Ethernet
>> header. I don't think this was discussed at all on the mailing list. I
>> assume that it wouldn't
>> confuse non-RBridge devices listening to that multicast address that
>> might hear the
>> packet because the Ethertype would be TRILL, so they'd (hopefully)
>>     
> drop
>   
>> it without
>> getting confused.
>>
>> Whatever I've missed, can someone add to this?
>>
>> Thanks,
>>
>> Radia
>>
>>
>> Eastlake III Donald-LDE008 wrote:
>>     
>>> @@@ Indeed, for precisely the reason you give, it was and remains my
>>> strong personal opinion that the VLAN-tag information should be part
>>>       
> of
>   
>>> the TRILL Header where it would be at least 14 bytes earlier and you
>>> would also save the 2 bytes of tag Ethertype. It contains priority
>>>       
> as
>   
>>> well as the VLAN ID info.
>>>
>>> @@@ However, the working group appears to be of the opinion that the
>>> VLAN-tag should be inserted inside the inner frame with an
>>>       
> Ethertype.
>   
>>> See the May mail here which includes arguments on the other side of
>>>       
> the
>   
>>> issue:
>>> http://www.postel.org/pipermail/rbridge/2007-May/thread.html.
>>>
>>>
>>>       
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>     