Subject: [rbridge] multicast pruning in TRILL

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 6 Jun 2007 14:34:38 -0700

Per Section 3.5 of the Rbridge Base Protocol
Specification, it looks like the trees computed
by the ISIS base instance need to be pruned 
based on VLAN/IGMP membership information.

Also, in order to actually make use of the 
pruning information when forwarding frames 
in a TRILL device, it looks like one would 
have to consult the inner L2 header of the 
frame to extract the inner VLAN and inner
MAC DA (the latter is needed for multicast).

In some sense TRILL is creating a tunnel,
and yet we need to dig deeper than the tunnel
headers in order to accomplish forwarding.
It also lacks consistency in that unicasts
are forwarded based on the RBridge destination
address and multicasts are forwarded based
on the inner MAC DA and VLAN.

If pruning was not a requirement we would
not have this issue.

Is the pruning functionality a requirement
(MUST) or a recommendation (MAY)?

Thanks,
Anoop

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 6 Jun 2007 23:58:22 -0400

Hi Anoop,

See below at @@@

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Anoop Ghanwani
Sent: Wednesday, June 06, 2007 5:35 PM
To: rbridge at postel.org
Subject: [rbridge] multicast pruning in TRILL

@@@ Certainly, the encapsulated ingress to egress Rbridge transport is a
tunnel.

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

@@@ There really isn't any inconsistency. The egress Rbridge for a
known-unicast frame is determined by using the destination MAC address
and the VLAN ID. It is just that for unicast, this can all be factored
into the selection of one relevant egress Rbridge and no in transit
pruning is needed. On the other hand, for multicast/broadcast, you could
theoretically have the ingress Rbridge determine and unicast to all the
relevant egress Rbridges, but that doesn't scale very well :-) So you
flood the frame but need to consult the destination address and VLAN for
pruning along the way so it only gets to relevant egress RBridges. For
both known-unicast and multi-destination frames, the frame passes
through transit Rbridges based on IS-IS adjacency and optimization
regardless of VLAN.

@@@ On the question of VLAN pruning and IP multicast pruning
implementation requirements, they can be considered separate questions
and there has been substantial discussion of them. I believe that VLAN
pruning should have an equal or higher level of implementation
requirement as IP multicast pruning and it is my impression that
"SHOULD" would be a reasonable implementation requirement for both of
these. 

@@@ Rbridges would, in some sense, operate "correctly" if there were no
pruning of multi-destination frames but you could be talking about
several orders of magnitude of inefficiency. If you were going to do
that, maybe you should consider being ultra consistent and just flooding
all frames, including unicast; after all, destination Rbridges that
don't need the frames can always throw them away. :-)

Thanks,
Anoop

@@@ Thanks,
@@@ Donald

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 07 Jun 2007 10:33:29 -0700

Re: Is multicast pruning a MAY or MUST:

I'm not sure there's been enough opinion voiced to have a consensus on this.
I'd be happy with MAY or SHOULD, since it really it just an optimization.

On the other part of what you said -- namely that you have to dig deeper 
into
the frame for multicast and VLAN pruning --- it was suggested, but
not extensively discussed, to move the inner VLAN into the TRILL header
so that VLAN pruning would not need to be done by finding the inner frame.

This would still require an RBridge in the core to look inside to find the
inner frame in order to look at the multicast address.

There are two ways I can think of to avoid this:
a) move the multicast address into the inner frame, perhaps as an option in
the TRILL header
b) use the multicast address in the inner frame as the destination 
address in the outer
header.

I rather like the notion of moving stuff that RBridges need to look at 
into the
outer header or TRILL header.

But this would need to be discussed, and hopefully soon.

Radia

Anoop Ghanwani wrote:
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Thu, 7 Jun 2007 11:00:27 -0700

rbridge-bounces at postel.org wrote:
> I'm not sure there's been enough opinion voiced to have a consensus
> on this. I'd be happy with MAY or SHOULD, since it really it just an
> optimization. 
> 
> On the other part of what you said -- namely that you have to
> dig deeper into the frame for multicast and VLAN pruning ---
> it was suggested, but not extensively discussed, to move the
> inner VLAN into the TRILL header so that VLAN pruning would
> not need to be done by finding the inner frame.
> 
> This would still require an RBridge in the core to look
> inside to find the inner frame in order to look at the multicast
> address. 
> 
> a) move the multicast address into the inner frame, perhaps
> as an option in the TRILL header
> b) use the multicast address in the inner frame as the
> destination address in the outer header.
> 
> I rather like the notion of moving stuff that RBridges need
> to look at into the outer header or TRILL header.
> 

I can see some value in moving RBridge-relevant fields earlier
in the overall packet, but I would want to avoid any and all
risks of doing so in a way where the semantics of those fields
did not remain fully under the IEEE and/or that would require
product to implement the same logic twice. Leaving them where
they are totally avoids such risks.

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Thu, 7 Jun 2007 11:15:28 -0700

Radia,

> I'd be happy with MAY or SHOULD, since it really it just an 

Actually, I think I agree with Donald's response.  Even
if it were a MAY/SHOULD, no one would ever want to build
a system that didn't do pruning.  It would be way too
inefficient.

> dig deeper 
> inside to find the

Moving the multicast address to the outer
header doesn't really help in terms of 
implementation since the look ups required
stay the same.  It might help from an 
architecture standpoint, but even that
I don't really see.

Essentially, we need both the inner VLAN and the
MAC DA to make their way into the TRILL header
so that they can be consulted for forwarding.
But doing so would unnecessarily add to the 
frame overhead.

Perhaps what is defined is as good as it
gets.  :-)

Somewhat off topic -
I now recall why the statement about "problems 
with learning when doing multipathing" was put
into the TRILL routing requirements document.
In the early days of TRILL, IIRC RBridges 
were going to just forward unicast frames without
an encapsulation header.  In that case, if
one had RBridges and regular bridges intermixed
in a network and had ECMP running in the RBridges,
we'd run into problems with address learning.

Anoop

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 07 Jun 2007 13:28:59 -0700

(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

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Thu, 7 Jun 2007 16:28:58 -0400

Hi,

See below at @@@ 

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Caitlin Bestler
Sent: Thursday, June 07, 2007 2:00 PM
To: Radia Perlman; Anoop Ghanwani
Cc: rbridge at postel.org
Subject: Re: [rbridge] multicast pruning in TRILL

Caitlin Bestler <caitlinb at broadcom.com> wrote:

@@@ The proposal would be to put a two byte field into the TRILL Header
that would be specified by reference to the IEEE standard. The 16 bits
would be used to control distribution tree pruning, priority queuing,
etc., inside an Rbridge in exactly the same way, regardless of whether
those 2 bytes are a field in the TRILL Header or are inserted inside the
encapsulated frame after an Ethertype. 

@@@ more below

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Anoop Ghanwani
Sent: Thursday, June 07, 2007 2:15 PM
To: Radia Perlman
Cc: rbridge at postel.org
Subject: Re: [rbridge] multicast pruning in TRILL

Radia,

@@@ Seems to me that moving an inner multicast or broadcast MAC address
to the outer Ethernet header could, on shared links, cause additional
interrupts to end stations from frames they would ultimately have to
discard (and probably shouldn't be handling anyway) because they don't
understand the TRILL Ethertype... 

@@@ As far as I can see, moving the VLAN tag info to the TRILL Header
reduces frame overhead. There would no longer be a need to insert an
Ethertype and the VLAN tag info into the encapsulated frame. Thus you
would save two bytes.

@@@ On the other hand, since the inner MAC DA is right after the TRILL
Header, whether it is part of the TRILL Header or not just depends on
where you draw the boundaries of that header :-)

@@@ Thanks,
@@@ Donald

Somewhat off topic -

Anoop

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sat, 9 Jun 2007 08:03:38 -0700

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

> Behalf Of Radia Perlman
> Sent: Thursday, June 07, 2007 1:29 PM
> To: Eastlake III Donald-LDE008

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sat, 9 Jun 2007 20:21:58 -0400

The consensus determination referred to is here:
http://www.postel.org/pipermail/rbridge/2007-May/002226.html
which refers to the option 1 here:
http://www.postel.org/pipermail/rbridge/2007-May/002078.html

Donald

-----Original Message-----
From: Silvano Gai [mailto:sgai at nuovasystems.com] 
Sent: Saturday, June 09, 2007 11:04 AM
To: Radia Perlman; Eastlake III Donald-LDE008
Cc: rbridge at postel.org
Subject: RE: [rbridge] multicast pruning in TRILL

Folks,

-- Silvano

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 11 Jun 2007 08:48:23 -0700

> I'd be happy with MAY or SHOULD, since it really it just an optimization.

IMO, optimizations should be expressed as MAY.

To say "SHOULD" is to say that implementations that do not implement the
optimization should have a good reason for not doing so. I don't think
the presumption should be tilted that way.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

-------------- 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/20070611/64269fe9/signature.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Mon, 11 Jun 2007 09:32:10 -0700

I agree with Joe.
In general we should use only MAY or MUST, not SHOULD

-- Silvano

> Behalf Of Joe Touch
> Sent: Monday, June 11, 2007 8:48 AM
> To: Radia Perlman
on
> this.

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 14 Jun 2007 22:30:42 -0700

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:
>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
>>     
> On
>   
>> Behalf Of Radia Perlman
>> 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
>> the TRILL header is still fixed length.  Minuses: It takes up room
>>     
> even
>   
>> when there is
>> the TRILL header: I don't think this was discussed. But it would
>>     
> clearly
>   
>> packet because the Ethertype would be TRILL, so they'd (hopefully)
>>     
> drop
>   
>> it without
>> getting confused.
>>
>>> strong personal opinion that the VLAN-tag information should be part
>>>       
> of
>   
>>> would also save the 2 bytes of tag Ethertype. It contains priority
>>>       
> as
>   
>>> 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:

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 15 Jun 2007 04:43:57 -0700

I'll add some info in the spirit of summarizing the reasons for a
decision already made.

Radia Perlman wrote:
...
> VLAN can be deleted from the inner frame).

I disagree that TRILL operations should ever modify their payload. Even
when done only at the ingress/egress, and only as an optimization, this
means that separate code is needed to parse headers inside vs. outside,
rather than just adding code to parse TRILL headers. Such code would be
used by trace debuggers, as well as by TRILL devices supporting other
fields that "should have been copied" into the TRILL header had we known
about them.

Any existing ethernet header that can be parsed now (or in the future)
in its original place can be parsed by TRILL using a fixed offset.
There's zero utility in copying or moving data - it presents
opportunities for more bugs and complexity.

> links with IP multicast routers) can be done with a single bit in the 

The same issue applies here.

...
> I'd think the advantages of doing so would be

I disagree that the following are agreed...

> a) easier for transit RBridges to make a forwarding decision

It is irrelevant where a header value is so long as it is in a fixed
location. There could be minor efficiencies in grabbing data in large
chunks, but such chunks are just as likely to grab both TRILL and the
inner ethernet headers in their entirety.

> need to look at anything more than the TRILL header

This is a fallacy. It is not architecturally "pure" to move a header;
it's still a field of the inner header, and moving it - if anything -
adds pollutes the architecture because it gives the misimpression that
TRILL is making decisions on only _its_ information.

> fields in the inner packet.

If 802 invented a new kind of tag, it's possible it wouldn't fit in the
current TRILL header, which means everything in TRILL would need to be
updated anyway.

Also, I don't believe there will be devices that support only transit or
only ingress/egress; ethernet plug-and-play compatibility means that
every device ought to support both functions (albeit with different
efficiency or scale in different devices).

> everything necessary for forwarding into the TRILL header, or against it).

I think you missed the pros, and omitted the cons (most of which you
posed as pros anyway).

Joe

-------------- 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/20070615/ae8196ab/signature.bin