[rbridge] Must/Should flooding optimization

[caitlinb at broadcom.com (Caitlin Bestler)]

I think it would be useful to look at four different 
categories on the flooding optimization:

egress to unknown ports:
	security-level MUST NOT send VLAN traffic to non-members.

	bandwidth-conservation MUST NOT send multicast traffic
	if there are no members.

rbridge-to-rbridge:
	bandwidth-conservation SHOULD/MUST NOT send traffic
	to another rbridge that the other rbridge will just
	drop. The arguments for MUST NOT mostly seem to fear
	widespread dumping of workload to other bridges based
	on market-driven benign neglect of overall network health.

	security-level MUST NOT might still apply if a given
	RBridge is simply not allowed to have members of
	a given VLAN.

	Possible exception when the rbridges have agreed
	(and/or been designed) to be assymetrical such that
	filtering is assigned to some but not all rbridges
	and the network is configured in an honest trade-off
	between wasted bandwidth versus table size.

egress to known ports (as part of an intergrated product):
	security-level MUST NOT on VLAN traffic still applies.

	bandwidth-conservation still applies on multicast
	traffic, but the benefit of pruning in the RBRidge
	as opposed to the end port is not at all a slam dunk
	in favor of RBRidge pruning.






Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2RLpmG22235 for <[e-mail]>; Mon, 27 Mar 2006 13:51:48 -0800 (PST)
Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 27 Mar 2006 13:51:31 -0800
X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 913692B0; Mon, 27 Mar 2006 13:51:31 -0800 (PST)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 6E2A22AF for <[e-mail]>; Mon, 27 Mar 2006 13:51:31 -0800 (PST)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id DEH58075; Mon, 27 Mar 2006 13:51:31 -0800 (PST)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 2713420502 for <[e-mail]>; Mon, 27 Mar 2006 13:51:31 -0800 ( PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 27 Mar 2006 13:51:30 -0800
Message-ID: <[e-mail]>
Thread-Topic: [rbridge] Must/Should flooding optimization
Thread-Index: AcZR5cyrAZYiWoXiSo2aj9N60UfUhAAAN7PA
From: "Caitlin Bestler" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006032708; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230372E34343238354441412E303035392D412D; ENG=IBF; TS=20060327215133; CAT=NONE; CON=NONE;
X-MMS-Spam-Filter-ID: A2006032708_4.00.0004_2.0.6,4.0-7
X-WSS-ID: 683681E90HW2269440-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k2RLpmG22235
Subject: Re: [rbridge] Must/Should flooding optimization
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2006 21:53:10 -0000
Status: RO
Content-Length: 1242

I think it would be useful to look at four different 
categories on the flooding optimization:

egress to unknown ports:
	security-level MUST NOT send VLAN traffic to non-members.

	bandwidth-conservation MUST NOT send multicast traffic
	if there are no members.

rbridge-to-rbridge:
	bandwidth-conservation SHOULD/MUST NOT send traffic
	to another rbridge that the other rbridge will just
	drop. The arguments for MUST NOT mostly seem to fear
	widespread dumping of workload to other bridges based
	on market-driven benign neglect of overall network health.

	security-level MUST NOT might still apply if a given
	RBridge is simply not allowed to have members of
	a given VLAN.

	Possible exception when the rbridges have agreed
	(and/or been designed) to be assymetrical such that
	filtering is assigned to some but not all rbridges
	and the network is configured in an honest trade-off
	between wasted bandwidth versus table size.

egress to known ports (as part of an intergrated product):
	security-level MUST NOT on VLAN traffic still applies.

	bandwidth-conservation still applies on multicast
	traffic, but the benefit of pruning in the RBRidge
	as opposed to the end port is not at all a slam dunk
	in favor of RBRidge pruning.






Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2RLBIG06235 for <[e-mail]>; Mon, 27 Mar 2006 13:11:18 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k2RLAbeG005079 for <[e-mail]>; Mon, 27 Mar 2006 16:11:03 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA26240 for <[e-mail]>; Mon, 27 Mar 2006 16:09:24 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <FG7S5G7Y>; Mon, 27 Mar 2006 16:09:23 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Date: Mon, 27 Mar 2006 16:09:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Must/Should flooding optimization
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2006 21:11:50 -0000
Status: RO
Content-Length: 3758

Dino,

	One more time (hopefully)... 

.. [SNIP] ..
--> >> 
--> >> A) Alternatively, are you arguing that VLAN filtering MUST occur
--> >>    on all RBridge interfaces in order to prevent mis-delivering
--> >>    VLAN-scoped multicast, or did I misunderstand your comments?
--> 
-->     First off, I never brought up VLAN pruning, you did. I 
-->     was focusing the discussion on multicast forwarding. So 
-->     if there is [no] IGMP report received for a group on an 
-->     egress rBridge interface, forwarding to that group does 
-->     not happen on that interface, period.
--> 
-->     So associating "VLAN pruning" with "multicast pruning" 
-->     brings no value to the discussion IMO. 
--> 

In an earlier exchange, I asked:
===============================

   As a clarification question, I am not sure whether this relates
   to VLAN support or multicast support.  Can you please clarify 
   the following points?

And you replied:
===============

   Multicast support which is scoped within a VLAN.

_________________________________________________________________

My understanding was that you wanted to make sure that we would
NOT (and could NOT) end up delivering a multicast frame to one 
VLAN because it was needed for another - unrelated - VLAN, unless
it is needed for both.

I completely agree that it is a very bad thing to confuse VLANs 
and MAC multicast delivery.  I could - for instance - have a
VLAN that is intended specifically to carry multicast traffic,
and I certainly do not want to push that traffic onto another 
(or all other) VLAN(s).

Separating this from VLANs, however, the assertion that an RBridge 
campus necessarily will NOT forward multicast on an egress interface 
unless there has been an IGMP report for that interface is not how 
802.1D bridging works now, and I cannot see in the WG charter where 
we have signed up to "fix" that (at least necessarily) in RBridges.

An RBridge campus is part of a single Ethernet LAN and should appear 
as such to routers (and other devices) on that LAN.  That means that 
routers (et al) expect to be exposed to all broadcast and multicast 
traffic within at least that one LAN.

For one thing, some routers may expect multicast messages - either
for the routing protocols themselves - or for related extensions to 
be propagated across the LAN without interference.  Likewise, some
devices may use multicast addresses for other reasons to communicate
among themselves within a single LAN.  That being the case, then we 
might find that we MUST qualify your statement above (minimally) with 
"except for configured (and potentially well known) MAC multicast 
destinations".

The well known case is something that can be reasonably abstracted
- except there will be new "well known" MAC multicast addresses at 
some point in the future that will also have to be included.  The
"configured" case is something we can work with - except that, in an
effort to minimize configuration, we should probably assume the 
default is to forward all MAC multicast traffic _except_ for those
configured addresses we want to treat differently.

I think there is a point of confusion here in that RBridges are not
intended to be routers, they are intended to be bridges that use a 
routing protocol to determine forwarding paths - instead of one of
a few variations of STP.  One of the goals in the charter is that we
do not break what works in an existing bridging environment.  Hence
we have to be careful - generally - in what we optimize and doubly
careful is what we require to be optimized.

.. [SNIP] ..

--> 
--> Dino
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2RJEVG21521 for <[e-mail]>; Mon, 27 Mar 2006 11:14:31 -0800 (PST)
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 27 Mar 2006 11:14:23 -0800
X-IronPort-AV: i="4.03,135,1141632000";  d="scan'208"; a="1788762291:sNHT30034020"
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2RJENYg027361 for <[e-mail]>; Mon, 27 Mar 2006 11:14:23 -0800 (PST)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k2RJENl7028424 for <[e-mail]>; Mon, 27 Mar 2006 11:14:23 -0800
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k2RJENdB028420; Mon, 27 Mar 2006 11:14:23 -0800
Date: Mon, 27 Mar 2006 11:14:23 -0800
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
References: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Must/Should flooding optimization
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2006 19:14:45 -0000
Status: RO
Content-Length: 93

>> Here, did you mean to say "... if there is no IGMP report ..."?

    Correct. Typo.

Dino


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2RJ0PG15674 for <[e-mail]>; Mon, 27 Mar 2006 11:00:25 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k2RIxmeG001109 for <[e-mail]>; Mon, 27 Mar 2006 13:59:48 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA06926 for <[e-mail]>; Mon, 27 Mar 2006 13:59:48 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <FG7S5BXP>; Mon, 27 Mar 2006 13:59:47 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Date: Mon, 27 Mar 2006 13:59:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Must/Should flooding optimization
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2006 19:00:50 -0000
Status: RO
Content-Length: 441

Dino, 

--> 
-->     First off, I never brought up VLAN pruning, you did. I 
-->     was focusing the discussion on multicast forwarding. So 
-->     if there is in IGMP report received for a group on an 
-->     egress rBridge interface, forwarding to that group does 
-->     not happen on that interface, period.
--> 

Here, did you mean to say "... if there is no IGMP report ..."?
                                           ^^

--
Eric


Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2RHROG13872 for <[e-mail]>; Mon, 27 Mar 2006 09:27:24 -0800 (PST)
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 27 Mar 2006 09:26:56 -0800
X-IronPort-AV: i="4.03,134,1141632000";  d="scan'208"; a="264384874:sNHT11592566212"
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2RHQuYg020539 for <[e-mail]>; Mon, 27 Mar 2006 09:26:56 -0800 (PST)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k2RHQuVB024505 for <[e-mail]>; Mon, 27 Mar 2006 09:26:56 -0800
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k2RHQutw024501; Mon, 27 Mar 2006 09:26:56 -0800
Date: Mon, 27 Mar 2006 09:26:56 -0800
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
References: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Must/Should flooding optimization
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2006 17:27:47 -0000
Status: RO
Content-Length: 1600

>> Questions:
>> 1) Given that VLAN filtering MUST occur at least at all RBridge 
>>    egress interfaces, how can VLAN-scoped Multicast be delivered
>>    on a VLAN-specific interface that does not support that VLAN?
>> 
>> 	(my answer: VLAN-scoped Multicast will not be delivered on
>> 	 VLAN-specific interfaces that do not support that VLAN)
>> 
>> 2) Assuming that you agree with my answer, then what justification 
>>    is there for saying VLAN filtering MUST occur on all RBridge 
>>    interfaces in order to prevent this form of mis-delivery?
>> 
>> 	(my answer: this requirement is not justified)
>> 
>> A) Alternatively, are you arguing that VLAN filtering MUST occur
>>    on all RBridge interfaces in order to prevent mis-delivering
>>    VLAN-scoped multicast, or did I misunderstand your comments?

    First off, I never brought up VLAN pruning, you did. I was focusing the
    discussion on multicast forwarding. So if there is in IGMP report received
    for a group on an egress rBridge interface, forwarding to that group does 
    not happen on that interface, period.

    So associating "VLAN pruning" with "multicast pruning" brings no value to
    the discussion IMO. 

    If an IGMP report for group G is received on an interface and the interface
    is in VLAN x, then there is a receiver for the group in VLAN x. Therefore,
    the MAC forwarding table for VLAN x has a MAC group entry to forward out
    this interface. And this would be the case for all switches where the
    "forwarding tree" is rooted by the switch directly connected to the 
    source(s).

Dino


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2RGjrG28883 for <[e-mail]>; Mon, 27 Mar 2006 08:45:53 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k2RGjkeG027537 for <[e-mail]>; Mon, 27 Mar 2006 11:45:46 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA20364 for <[e-mail]>; Mon, 27 Mar 2006 11:45:46 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <FG7SZ7WW>; Mon, 27 Mar 2006 11:45:45 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Date: Mon, 27 Mar 2006 11:45:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Must/Should flooding optimization
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2006 16:47:02 -0000
Status: RO
Content-Length: 4057

Dino,

	I'm not sure that there are any remaining points of dis-
agreement below, but please see in-line comments/questions... 

--> >> o	In every case (with or without VLAN optimization within
--> >> 	the RBridge campus), an egress RBridge MUST filter VLAN
--> >> 	traffic on egress (i.e. - when decapsulating RBridge to
--> >> 	RBridge traffic for forwarding on a Ethernet link).
--> >> o	There has never been any intention not to do this.
--> 
-->     And I'm telling you that it should when looking at a 
-->     network the size of 100 switches.

Possibly this is my bad for using "... never ... not ..."

I assume we would be in agreement if I rephrased this 

    "o   The implied intention has always been to do this."

I make this assertion because this is how Radia has presented 
this in earlier discussions on this topic (specifically in a
"How many trees" presentation given at IETF-63).

--> 
--> >> o	This is highly consistent with the minimal-configuration
--> >> 	goal of the TRILL WG because egress RBridges - at least
--> >> 	- will need to know (most likely from configuration) what
--> >> 	VLANs are associated with what RBridge interfaces.
--> 
-->     I don't see how it is related. Wanted to do [optimized] 
-->     forwarding doesn't require more configuration.

If RBridges are only REQUIRED to be VLAN aware at RBridge egress
interfaces, VLAN configuration is only REQUIRED at those interfaces.

Each RBridge advertises, via the RBridge Routing Protocol, the VLANs
to which it is connected.

Therefore only requiring VLAN awareness at RBridge egress interfaces
is highly consistent with the TRILL minimal-configuration goal - and
has no impact on the ability of RBridges to provide VLAN pruning.

--> 
--> >> o	So, given the above context, how do you expect that any
--> >> 	VLAN-scoped Multicast could end up being delivered on an
--> >> 	innappropriate VLAN interface? 
--> 
-->     You confused me. I don't see how your bullets follow to 
--> your question.

Given that it seems that you reversed the sense of the second
bullet above (the one with the offensive double-negative), it
may be that the flow to the question is clearer now.  However,
I will re-state as follows:

Background:
o  VLAN-based pruning/filtering MUST occur on RBridge egress.
o  VLAN-based pruning/filtering at RBridges that do not support
   directly VLAN-connected interfaces may require some non-zero 
   amount of "extra" configuration.

Additional factor:
o  Minimal configuration may be a more important consideration  
   in some deployment scenarios than VLAN pruning/filtering at
   interfaces that are not RBridge egresses

Questions:
1) Given that VLAN filtering MUST occur at least at all RBridge 
   egress interfaces, how can VLAN-scoped Multicast be delivered
   on a VLAN-specific interface that does not support that VLAN?

	(my answer: VLAN-scoped Multicast will not be delivered on
	 VLAN-specific interfaces that do not support that VLAN)

2) Assuming that you agree with my answer, then what justification 
   is there for saying VLAN filtering MUST occur on all RBridge 
   interfaces in order to prevent this form of mis-delivery?

	(my answer: this requirement is not justified)

A) Alternatively, are you arguing that VLAN filtering MUST occur
   on all RBridge interfaces in order to prevent mis-delivering
   VLAN-scoped multicast, or did I misunderstand your comments?

--> 
--> >> 	These are clearly isomorphic representations of a common
--> >> sub-setting operation.  This same observation applies to an 
--> >> RBridge campus as a whole.
--> 
-->     Whatever.
--> 
--> >> ->	Therefore, routers and hosts will not receive multicast 
--> >> 	frames that were not intended to be delivered to a VLAN
--> >> 	on which a router (or host) resides.
--> 
-->     Right.

I assume that these two responses mean either that you agree,
or that you don't care...

--> 
--> Dino
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2QMicG12331 for <[e-mail]>; Sun, 26 Mar 2006 14:44:39 -0800 (PST)
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 26 Mar 2006 14:44:34 -0800
X-IronPort-AV: i="4.03,130,1141632000";  d="scan'208"; a="1788446376:sNHT30016138"
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2QMiX1j019297 for <[e-mail]>; Sun, 26 Mar 2006 14:44:33 -0800 (PST)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k2QMiXvZ000554 for <[e-mail]>; Sun, 26 Mar 2006 14:44:33 -0800
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k2QMiXMk000550; Sun, 26 Mar 2006 14:44:33 -0800
Date: Sun, 26 Mar 2006 14:44:33 -0800
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
References: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Must/Should flooding optimization
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 26 Mar 2006 22:48:50 -0000
Status: RO
Content-Length: 1327

>> o	In every case (with or without VLAN optimization within
>> 	the RBridge campus), an egress RBridge MUST filter VLAN
>> 	traffic on egress (i.e. - when decapsulating RBridge to
>> 	RBridge traffic for forwarding on a Ethernet link).
>> o	There has never been any intention not to do this.

    And I'm telling you that it should when looking at a network the size
    of 100 switches.

>> o	This is highly consistent with the minimal-configuration
>> 	goal of the TRILL WG because egress RBridges - at least
>> 	- will need to know (most likely from configuration) what
>> 	VLANs are associated with what RBridge interfaces.

    I don't see how it is related. Wanted to do optmized forwarding doesn't
    require more configuration.

>> o	So, given the above context, how do you expect that any
>> 	VLAN-scoped Multicast could end up being delivered on an
>> 	innappropriate VLAN interface? 

    You confused me. I don't see how your bullets follow to your question.

>> 	These are clearly isomorphic representations of a common
>> sub-setting operation.  This same observation applies to an 
>> RBridge campus as a whole.

    Whatever.

>> ->	Therefore, routers and hosts will not receive multicast 
>> 	frames that were not intended to be delivered to a VLAN
>> 	on which a router (or host) resides.

    Right.

Dino


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2OHh2G20672 for <[e-mail]>; Fri, 24 Mar 2006 09:43:03 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k2OHgueG026077 for <[e-mail]>; Fri, 24 Mar 2006 12:42:57 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA24508 for <[e-mail]>; Fri, 24 Mar 2006 12:42:51 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <FG7SW90Q>; Fri, 24 Mar 2006 12:42:50 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Date: Fri, 24 Mar 2006 12:42:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Must/Should flooding optimization
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 24 Mar 2006 17:43:38 -0000
Status: RO
Content-Length: 4239

Dino,

	Thanks for the reply.

	So the issue you are concerned about is scoping multicast
by VLAN.  I see 3 remaining clarifications required in reponse
to the portion of your message that I've included below.

========================= 1 ====================================

	To clarify the question I asked specifically about your
concerns in this case, I was trying to ask the following:

o	In every case (with or without VLAN optimization within
	the RBridge campus), an egress RBridge MUST filter VLAN
	traffic on egress (i.e. - when decapsulating RBridge to
	RBridge traffic for forwarding on a Ethernet link).
o	There has never been any intention not to do this.
o	This is highly consistent with the minimal-configuration
	goal of the TRILL WG because egress RBridges - at least
	- will need to know (most likely from configuration) what
	VLANs are associated with what RBridge interfaces.

o	So, given the above context, how do you expect that any
	VLAN-scoped Multicast could end up being delivered on an
	innappropriate VLAN interface? 

========================== 2 ===================================

	On your further point, "pruning for a multicast group is 
always a subset of the pruning for a VLAN toplogy" - I agree
completely.  

	However I must add - strictly for "correctness" - that 
there is no ordering requirement in the sub-setting operation
by VLAN and Multicast group.  

	An implementation may do this using per-VLAN tables where 
multicast group is part of the look-up, a per-Multicast-Group 
table where VLAN is part of the look-up or a single table where 
VLAN and multicast group are both part of the lookup.

	These are clearly isomorphic representations of a common
sub-setting operation.  This same observation applies to an 
RBridge campus as a whole.

=========================== 3 ==================================

	On your last point, the fact that routers and hosts are
not included as part of an RBridge campus is relevant because:

o	Routers and hosts will only receive frames after they've
	been delivered by an egress RBrdge to the LAN segment on
	which the host or router is present.
o	The egress RBridge will necessarily have applied a VLAN
	specific filter prior to delivering any traffic to the
	LAN segment on which the RBridge is present.

->	Therefore, routers and hosts will not receive multicast 
	frames that were not intended to be delivered to a VLAN
	on which a router (or host) resides.

--
Eric

.. [SNIP] ..

--> 
--> >> As a clarification question, I am not sure whether this relates
--> >> to VLAN support or multicast support.  Can you please clarify 
--> >> the following points?
--> 
-->     Multicast support which is scoped within a VLAN.

.. [SNIP] ..

--> >> If your concern relates to VLANs in combination with multicast,
--> >> how is this a problem if VLAN pruning necessarily occurs when
--> >> frames egress from the RBridge campus?
--> 
-->     I really don't understand the question but let me respond by 
-->     saying the pruning for a multicast group is always a subset 
-->     of the pruning for a VLAN toplogy.
--> 
-->     The concern is that data packets and IGMP reports are send to 
-->     the same MAC address. So packets need to go to different 
-->     places then the IGMP reports go.
--> 
--> >> 
--> >> It has been a question from the very beginning of this effort 
--> >> as to whether or not there would be discrete Ingress RBridge
--> >> Trees per-VLAN (which corresponds to pruning VLAN traffic at
--> >> each RBridge), but there has never been a question about doing
--> >> this "VLAN pruning" at egress from the RBridge campus.
--> 
-->     Well the set of routers on one VLAN can be different (and 
-->     therefore at different topological locations) than another 
-->     one, so you have to have separate state to deal with each 
-->     VLAN.
--> 
--> >> Also, we do not include routers and hosts as part of a RBridge
--> >> campus.  Frames forwarded to routers and hosts MUST egress the
--> >> RBridge campus first.
--> 
-->     Right, how is this relevant?
--> 
--> Dino
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2NMuYG08475 for <[e-mail]>; Thu, 23 Mar 2006 14:56:34 -0800 (PST)
Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 23 Mar 2006 14:56:20 -0800
X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 59A7F2B0; Thu, 23 Mar 2006 14:56:20 -0800 (PST)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 2F4EE2AF for <[e-mail]>; Thu, 23 Mar 2006 14:56:20 -0800 (PST)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id DDR18334; Thu, 23 Mar 2006 14:46:56 -0800 (PST)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 3E7F220501 for <[e-mail]>; Thu, 23 Mar 2006 14:46:56 -0800 ( PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 23 Mar 2006 14:46:55 -0800
Message-ID: <[e-mail]>
Thread-Topic: [rbridge] Must/Should flooding optimization
Thread-Index: AcZOo02vftOYfqW4S6KH66GEoqR+2gAJqNOA
From: "Caitlin Bestler" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006032309; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230322E34343233323646422E303035442D412D; ENG=IBF; TS=20060323225622; CAT=NONE; CON=NONE;
X-MMS-Spam-Filter-ID: A2006032309_4.00.0004_2.0.6,4.0-7
X-WSS-ID: 683DF81E17461873-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k2NMuYG08475
Subject: Re: [rbridge] Must/Should flooding optimization
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2006 22:57:10 -0000
Status: RO
Content-Length: 1179

My observation is that those favoring a MUST here are essentially
assuming that if it is only a SHOULD that there will be some 
RBridge vendors who will evaluate the SHOULD language and decide
that their saving 10 cents per port is a valid reason to skip
flooding the rest of the campus.

That is they are not trusted to be proper stewards of the network
when making this design tradeoff. While cynical, it may not be
an innacurate assesment of inevitable market pressures.

But I believe the real intent of using SHOULD, instead of MUST,
is to protect implementations that have truly legitimate 
reasons to make this tradeoff.

For example, an RBridge that is integrated in a multi-blade
system may know that certain links only carry traffic to/from
the blades (i.e there are no internal RBridges that lead back
to the rest of the campus). As such that equipment designer
is in a position to make a fair and unbiased tradeoff between
the cost of filtering tables and the cost of wasting internal
bandwidth. That is exactly the sort of tradeoff that does not
impact interoperability, and we are supposed to avoid using
MUSTs or MUST NOTs to standardize engineering tradeoffs.





Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2NM7nG21292 for <[e-mail]>; Thu, 23 Mar 2006 14:07:49 -0800 (PST)
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 23 Mar 2006 14:07:46 -0800
X-IronPort-AV: i="4.03,123,1141632000";  d="scan'208"; a="1787770331:sNHT966488168"
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2NM7h1j001589 for <[e-mail]>; Thu, 23 Mar 2006 14:07:43 -0800 (PST)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k2NM7hIV002051 for <[e-mail]>; Thu, 23 Mar 2006 14:07:43 -0800
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k2NM7hSW002047; Thu, 23 Mar 2006 14:07:43 -0800
Date: Thu, 23 Mar 2006 14:07:43 -0800
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
References: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Must/Should flooding optimization
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2006 22:08:11 -0000
Status: RO
Content-Length: 1871

>> As a clarification question, I am not sure whether this relates
>> to VLAN support or multicast support.  Can you please clarify 
>> the following points?

    Multicast support which is scoped within a VLAN.

>> Point 1:
>> In the event that it relates exclusively to multicast support,
>> how is the RBridge case different from the 802.1D bridge case -
>> with respect to this issue?

    The rBridge case doesn't process reports for building an oif-list the
    same way as a an 802.1D bridge. That is the later, uses the interface
    the report is received on and the former uses the path to the originating
    edge rBridge.

>> Point 2:
>> If your concern relates to VLANs in combination with multicast,
>> how is this a problem if VLAN pruning necessarily occurs when
>> frames egress from the RBridge campus?

    I really don't understand the question but let me respond by saying
    the pruning for a multicast group is always a subset of the pruning
    for a VLAN toplogy.

    The concern is that data packets and IGMP reports are send to the
    same MAC address. So packets need to go to different places then the 
    IGMP reports go.

>> 
>> It has been a question from the very beginning of this effort 
>> as to whether or not there would be discrete Ingress RBridge
>> Trees per-VLAN (which corresponds to pruning VLAN traffic at
>> each RBridge), but there has never been a question about doing
>> this "VLAN pruning" at egress from the RBridge campus.

    Well the set of routers on one VLAN can be different (and therefore
    at different topological locations) than another one, so you have
    to have separate state to deal with each VLAN.

>> Also, we do not include routers and hosts as part of a RBridge
>> campus.  Frames forwarded to routers and hosts MUST egress the
>> RBridge campus first.

    Right, how is this relevant?

Dino


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2NHgiG13452 for <[e-mail]>; Thu, 23 Mar 2006 09:42:44 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k2NHgceG027996 for <[e-mail]>; Thu, 23 Mar 2006 12:42:38 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA08652 for <[e-mail]>; Thu, 23 Mar 2006 12:42:38 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <FG7SVY3W>; Thu, 23 Mar 2006 12:42:37 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Date: Thu, 23 Mar 2006 12:42:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Must/Should flooding optimization
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2006 17:43:12 -0000
Status: RO
Content-Length: 2984

Folks,

	When this first came out, I was inclined to let it go.
Since what I said is now being consistently misrepresented,
I think I need to clarify my position on this.

>> Eric Gray pointed out that doing this pruning is only an optimization.

There is nothing quite like having your position summarized
for you by someone who appears to disagree with you.  :-)

My position can be neatly and accurately summarized as follows:

"There are circumstances in which these optimizations can be
 safely omitted, therefore the term 'SHOULD' - as defined in 
 RFC 2119 - applies."

My justification follows (for those interested in the details).
=================================================================
Several people recognize VLAN and Multicast pruning as 
optimizations.

The question is whether or not we want to require it in all
implementations.

My position is that - contrary to some arguments made - I 
feel that requiring this behavior actually complicates both 
the specification and the implementation processes.  Doing
so is something I think we should undertake only if we have
to do so in order to produce useful, interoperable, specs.

However there are two aspects to consider here: requiring 
RBridge behaviors that _allow_ optimization support, and
requiring RBridges to implement those optimizations.

Everybody that I know of is in agreement that RBridges 
MUST not preclude support for implementations that will
include these optimizations.  This applies - for example
- to Radia's earlier observations about the need for all
RBridges to ensure VLAN and multicast group membership
information is appropriately propagated within an RBridge
campus.  Implementations that include these optimizations
need this information in order to work correctly.

What is in question is whether all RBridges MUST include
the optimizations - specifically for interoperability.

IMO, these optimizations are not necessarily supported in
802.1D bridges, and these bridges work.  Consequently, we
need to find specific cases where RBridges introduce some
behaviors that break the corresponding features in 802.1D 
bridges.

We have evaluated very many scenarios and each potential
RBridge capability as yet discussed and - as several of
the people at the meeting said (including Radia) - they
still work.  Yes, they work sub-optimally in scenarios
were VLAN/Multicast support is important, but they are 
no worse in those scenarios than a similar deployment of
802.1D bridges would be.

The meaning of "SHOULD" - as defined in RFC 2119 - is as
follows:

'This word, or the adjective "RECOMMENDED", mean that there
 may exist valid reasons in particular circumstances to ignore a
 particular item, but the full implications must be understood and
 carefully weighed before choosing a different course.'

Since - so far - it has been demonstrated that there are "valid
reasons in particular circumstances" which justify not including
these optimizations, this term fits.

--
Eric


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2NH5xG00301 for <[e-mail]>; Thu, 23 Mar 2006 09:05:59 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k2NH5reG027227 for <[e-mail]>; Thu, 23 Mar 2006 12:05:53 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA04645 for <[e-mail]>; Thu, 23 Mar 2006 12:05:52 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <FG7SVXHT>; Thu, 23 Mar 2006 12:05:52 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Date: Thu, 23 Mar 2006 12:05:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Must/Should flooding optimization
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2006 17:07:10 -0000
Status: RO
Content-Length: 1800

Dino,

	Please see below...

.. [SNIP] ..
--> 
-->     o IGMP reports which need to be forwarded through the 
-->       rBridge network are encapsualted in a new special MAC 
-->       group address when encapsulation occurs so core 
-->       rBridges can forward such packets on router ports. If
-->       this is not done and the inner group address is used 
-->       as the outer group address, then data packets to the 
-->       group and IGMP reports to the group would have to go 
-->       everywhere. We want data packets to go to receivers 
-->       only and IGMP reports to go to routers only (and 
-->       [nowhere] else).
--> 
-->     Comments?

As a clarification question, I am not sure whether this relates
to VLAN support or multicast support.  Can you please clarify 
the following points?

Point 1:
In the event that it relates exclusively to multicast support,
how is the RBridge case different from the 802.1D bridge case -
with respect to this issue?

Point 2:
If your concern relates to VLANs in combination with multicast,
how is this a problem if VLAN pruning necessarily occurs when
frames egress from the RBridge campus?

It has been a question from the very beginning of this effort 
as to whether or not there would be discrete Ingress RBridge
Trees per-VLAN (which corresponds to pruning VLAN traffic at
each RBridge), but there has never been a question about doing
this "VLAN pruning" at egress from the RBridge campus.

Also, we do not include routers and hosts as part of a RBridge
campus.  Frames forwarded to routers and hosts MUST egress the
RBridge campus first.

--> 
--> Dino
--> 
-->     
-->     
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2N150G16396 for <[e-mail]>; Wed, 22 Mar 2006 17:05:00 -0800 (PST)
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 22 Mar 2006 17:04:56 -0800
X-IronPort-AV: i="4.03,120,1141632000";  d="scan'208"; a="1787466075:sNHT89338204"
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2N14r1j000565 for <[e-mail]>; Wed, 22 Mar 2006 17:04:53 -0800 (PST)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k2N14rJs019717 for <[e-mail]>; Wed, 22 Mar 2006 17:04:53 -0800
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k2N14r3u019713; Wed, 22 Mar 2006 17:04:53 -0800
Date: Wed, 22 Mar 2006 17:04:53 -0800
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Radia Perlman on Tue, 21 Mar 2006 12:34:48 -0800)
References: <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Must/Should flooding optimization
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2006 01:06:02 -0000
Status: RO
Content-Length: 1496

>> Eric Gray pointed out that doing this pruning is only an optimization. 
>> Bandwidth would be wasted if some

    Wasting bandwidth is a non-starter. These boxes can go into enterprises
    who abandoned dense-mode PIM 8 years ago. And dense-mode PIM does "flood
    then prune". 

    We shouldn't repeat past sins.

    We need to prune by default, this has to be a part of the foundational
    design. Or else, we have a non-starter. I mentioned this in the working
    group hence my strong position on making this a MUST.

>> Radia

    I had a conversation with Radia, and these were points we wanted to post
    to make people think and comment about:

    o Router discovery is done by listening to 224.0.0.0/24 packets
      from routers which need to be flooded to all router ports (ports leading
      to routers on the edge of the rBridge network) versus flooding on
      the broadcast tree to all edge rBridges.

    o IGMP reports which need to be forwarded through the rBridge network
      are encapsualted in a new special MAC group address when encapsulation 
      occurs so core rBridges can forward such packets on router ports. If
      this is not done and the inner group address is used as the outer
      group address, then data packets to the group and IGMP reports to the 
      group would have to go everywhere. We want data packets to go to
      receivers only and IGMP reports to go to routers only (and no where
      else).

    Comments?

Dino

    
    


Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2MLsfG17188 for <[e-mail]>; Wed, 22 Mar 2006 13:54:41 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.106.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k2MLseuf005076 for <[e-mail]>; Wed, 22 Mar 2006 14:54:41 -0700 (MST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k2MLsYnc178944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Mar 2006 13:54:36 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 22 Mar 2006 13:53:04 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5 (X11/20060113)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Draft minutes posted
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 22 Mar 2006 21:54:54 -0000
Status: RO
Content-Length: 113

Let us know of any corrections.

<http://www3.ietf.org/proceedings/06mar/minutes/trill.txt>

   Erik and Donald


Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2MGhuG01532 for <[e-mail]>; Wed, 22 Mar 2006 08:43:56 -0800 (PST)
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 22 Mar 2006 08:43:51 -0800
X-IronPort-AV: i="4.03,119,1141632000";  d="scan'208"; a="263494808:sNHT29921240"
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2MGhoYg014137 for <[e-mail]>; Wed, 22 Mar 2006 08:43:51 -0800 (PST)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k2MGhokU027272 for <[e-mail]>; Wed, 22 Mar 2006 08:43:50 -0800
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k2MGho4U027268; Wed, 22 Mar 2006 08:43:50 -0800
Date: Wed, 22 Mar 2006 08:43:50 -0800
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Radia Perlman on Tue, 21 Mar 2006 12:54:04 -0800)
References: <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] IGMP learning
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 22 Mar 2006 16:45:04 -0000
Status: RO
Content-Length: 2172

>> links with IP endnodes, because some versions of IGMP have an endnode 
>> suppress an
>> announcement if they hear an announcement that some other endnode is 
>> also in that
>> group (since the IP endnode thinks the whole campus is one link).

    Not some but mostly all of them do.

>> This would seem like a contradiction, since the announcement MUST go 
>> onto a link if
>> there is an IP multicast router there, and MUST NOT go onto a link if 
>> there is
>> an IP endnode...so what would one do with a link that has both? But the 
>> answer is
>> that the announcement MUST go onto the link, which will suppress the 
>> announcement
>> of the endnode (for some versions of IGMP). But that's OK, because all 
>> IP multicast
>> traffic MUST be delivered to all links containing an IP multicast router 
>> (in that
>> VLAN).

    I hate to muddy the waters Radia, but when IGMPv3 is in use, there are
    some router implementations that do explicit tracking of receivers that
    join (S,G). There is no problem here but just wanted to raise attention
    that the IGMPv3 message on this segment would be sent by the end-node and 
    there is no suppression happening (in IGMPv3 only).

>> a) RBridges must do IP multicast router discovery
    
    Which means packets addressed to 224.0.0.13 (or 01005e.00000d) must be
    flooded on the broadcast tree (per VLAN) built by IS-IS.

>> g) A Designated RBridge that sees a multicast packet (with MAC address 
>> derived from
>> an IP multicast address) encapsulates the packet and sends it into the 
>> campus
>> on the ingress RBridge tree with itself as "ingress RBridge".

    So you didn't say where it forwards the packet. And it is implied from
    this text that it could be on the ports where you received IGMP reports.
    But I know from our conversation yesterday it is based on the group
    advertisements in LSPs.

>> Does this seem right to people?

    At a high-level yes. You could add to f):

    "The outgoing port list is made of the ports that lead to all egress-
    Rbridges which have announced the group MAC address within a VLAN."

    Then you can refer to this port list in h).

Dino


Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2LNbVG11339 for <[e-mail]>; Tue, 21 Mar 2006 15:37:31 -0800 (PST)
Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 21 Mar 2006 15:37:10 -0800
X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id ADBD02AF; Tue, 21 Mar 2006 15:37:10 -0800 (PST)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 7AA792AE for <[e-mail]>; Tue, 21 Mar 2006 15:37:10 -0800 (PST)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id DDH33355; Tue, 21 Mar 2006 15:37:10 -0800 (PST)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id E620B20501 for <[e-mail]>; Tue, 21 Mar 2006 15:37:09 -0800 ( PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 21 Mar 2006 15:37:08 -0800
Message-ID: <[e-mail]>
Thread-Topic: [rbridge] Must/Should flooding optimization
Thread-Index: AcZNKL1mgKWEXbjGR2uRtzNjc6U1HgAFynHg
From: "Caitlin Bestler" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006032109; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230322E34343230384439462E303032392D412D; ENG=IBF; TS=20060321233714; CAT=NONE; CON=NONE;
X-MMS-Spam-Filter-ID: A2006032109_4.00.0004_2.0.6,4.0-7
X-WSS-ID: 683E51AC3NG1928459-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k2LNbVG11339
Subject: Re: [rbridge] Must/Should flooding optimization
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2006 23:37:43 -0000
Status: RO
Content-Length: 2446

[e-mail] wrote:
> When a multicast or unknown destination packet is forwarded
> by RBridges, it is sent along the ingress RBridge rooted at
> the ingress RBridge. However, RBRidges along the way can
> prune the packet so that the packet only reaches links that
> have interested receivers. There are two pieces of pruning
> information: a) which egress RBridges are attached to which VLANs (so
> a 
> packet marked VLAN A need not be forwarded to RBridges that
> have no links attached to VLAN A)
> b) which egress RBridges have interested receivers for
> IP-derived multicast addresses (as learned through IGMP and multicast
> router discovery) 
> 
> Eric Gray pointed out that doing this pruning is only an optimization.
> Bandwidth would be wasted if some
> RBridge that was only in the "core" ignored IGMP and VLANs,
> and forwarded all non-unicasts (received on the expected
> ingress port for the specified ingress RBridge tree) to all
> potential outgoing ports in that ingress RBridge tree.
> 
> So, he argued that both forms of flooding optimization should
> be SHOULD, because
> a) a vendor can build a cheaper device if it doesn't have to
> bother filtering based on these things
> b) customers can buy the cheaper device it they'd like to
> save money, and don't care about saving bandwidth, especially
> because in their deployment they might not be using VLANs at
> all, and have very little multicast traffic, or there might
> be sections of their campus in which filtering won't matter
> for bandwidth
> c) even if a vendor were planning on eventually doing all
> features, this would make phased implementation possible.
> 
> Others argued that flooding optimization should be a MUST because:
> a) the spec is more complicated if things are options
> b) "your cheapo nonfiltering RBridge is putting more stress
> on my good-guy RBridge downstream"
> c) it's more options for customers to understand in the purchasing
> decision 
> 
> Anyway, what do people think?
> 

For a general purpose RBridge I would agree that it
should be a MUST. But I am concerned that other more
specialized devices may someday include RBridge functionality
within them. Such a device could concievably conclude that
the cost of certain ingress filters was simply not justified.
And in the larger context it would only be risking its own
internal bandwidth.

That's the sort of special deployment need that SHOULD
was designed for.




Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2LNSFG08086 for <[e-mail]>; Tue, 21 Mar 2006 15:28:15 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k2LNS9eG012338 for <[e-mail]>; Tue, 21 Mar 2006 18:28:09 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA14429 for <[e-mail]>; Tue, 21 Mar 2006 18:28:09 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <FG7STWLR>; Tue, 21 Mar 2006 18:28:08 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Date: Tue, 21 Mar 2006 18:28:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Must/Should flooding optimization
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2006 23:28:43 -0000
Status: RO
Content-Length: 7050

Radia, et al,

	Some clarifications...

	Just to be clear, "flooding optimization" as identified 
in the architecture applies only to flooding of frames with an
unkown MAC DA.

	VLAN Optimization as we have discussed on the list before
is the difference between:

(Optimized) forwarding multicast, broadcast or flooded traffic 
to only those downstream next-hop RBridges that are on the short
path toward an egress (DR) RBridge known to be part of a given 
VLAN.

(Unoptimized) forwarding all multicast, broadcast or flooded 
traffic to all downstream next-hop RBridges that are on the short
path toward an egress (DR) RBridge.

In both cases, an egress (DR) RBridge MUST filter all such frames 
and forward them only on the interfaces that are known to be part 
of the applicable VLAN.  Just to reiterate, this would be the case
even if all RBridges implement the VLAN Optimization.

	Multicast Optimization is the additional step of limiting 
frame forwarding to those downstream next-hop RBridges on the
shortest path toward egress (DR) RBridges known to be interested 
in frames addressed to a specific multicast MAC DA (this applies
only to Multicast frames).  This is an additional step because 
it makes sense to apply this optimization in addition to the VLAN
Optimization.

	Flooding Optimization - at least in the architecture is the
completely optional possibility of peeking at the inner MAC DA to
determine if it is _known_ locally (within a VLAN context, if that
applies).

	Also, see additional clarifications below...

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Radia Perlman
--> Sent: Tuesday, March 21, 2006 3:35 PM
--> To: Developing a hybrid router/bridge.
--> Subject: [rbridge] Must/Should flooding optimization
--> 
--> When a multicast or unknown destination packet is forwarded 
--> by RBridges, it is sent along the ingress RBridge rooted at 
--> the ingress RBridge. However, RBRidges along the way can prune
--> the packet so that the packet only reaches links that have 
--> interested receivers. There are two pieces of pruning information:
-->

This includes broadcast frames as well as multicast and unknown MAC
DA frames.

Also this is in reference to path pruning, generally, in RBridges.

--> 
--> a) which egress RBridges are attached to which VLANs (so a 
--> packet marked VLAN A need not be forwarded to RBridges that 
--> have no links attached to VLAN A)

Frames should also not be forwarded toward egress RBridges that are 
not DR for a shared media on which these frames might be forwarded.
One could argue that an RBridge that is not the DR for any shared
media is not an egress RBridge.

--> 
--> b) which egress RBridges have interested receivers for IP-derived 
--> multicast addresses (as learned through IGMP and multicast router 
--> discovery)
--> 
--> Eric Gray pointed out that doing this pruning is only an 
--> optimization. 

I pointed out that it is an optimization and that things will still
work - if potentially sub-optimally - if not all RBridges implement 
it.

-->
--> Bandwidth would be wasted if some RBridge that was only in the 
--> "core" ignored IGMP and VLANs, and forwarded all non-unicasts 
--> (received on the expected ingress port for the specified ingress 
--> RBridge tree) to all potential outgoing ports in that ingress 
--> RBridge tree.

There was more to the discussion than this.  Bandwidth is wasted in
an RBridge deployment where VLAN support or Multicast traffic is a
major consideration.

Given that one goal (perhaps the most important goal) of the TRILL
working group is minimal-to-zero configuration, and VLAN support - 
in particular - requires at least some degree of configuration, I
wonder if we are not working too hard at achieving opposing goals.

If we are trying to define a technology that does not require 
configuration to work in some subset of all possible deployment
scenarios, then I imagine we can assume that subset would not
involve VLANs.

I believe the usual way to deal with these concerns is through an 
Applicability RFC.

--> 
--> So, he argued that both forms of flooding optimization should be 
--> SHOULD, because
--> 
--> a) a vendor can build a cheaper device if it doesn't have to
--> bother filtering based on these things
--> 
--> b) customers can buy the cheaper device it they'd like to 
--> save money, and don't care about saving bandwidth,  especially 
--> because in their deployment they might not be using VLANs at 
--> all, and have very little multicast traffic, or there might be 
--> sections of their campus in which filtering won't matter for 
--> bandwidth

Making efficient use of bandwidth is one of the goals of the work
we are trying to do - as well as being a reason to deploy RBridges.  
Therefore, while VLAN and Multicast support may be non-issues in a
given RBridge deployment, it is unlikely that there will be sections
of an RBridge deployment where "filtering won't matter for bandwidth."

--> 
--> c) even if a vendor were planning on eventually doing all 
--> features, this would make phased implementation possible.

There was also the point that Bill Fenner made about opportunities 
for product differentiation stemming from this.

--> 
--> Others argued that flooding optimization should be a MUST 
--> because:
--> 
--> a) the spec is more complicated if things are options

No question about it.  For example, in the protocol specification,
you would have to say 

"If the XYZ optimization is implemented, the following section(s) 
specify how it MUST be done" 

as opposed to a much simpler introductory statement that says 

"The XYZ optimization is specified in the following section(s)."

I don't believe complexity - beyond this - is involved, because
we are not talking about configurable options.

--> 
--> b) "your cheapo nonfiltering RBridge is putting more stress on 
--> my good-guy RBridge downstream"

Assuming that a new "cheapo nonfiltering RBridge" is used to either
augment or replace existing bridges (note, not _RBridges_), impact
we can expect from this is not worse than if a "cheapo nonfiltering
bridge" was inserted instead of a "cheapo nonfiltering RBridge."

However, there is still a gain from the fact that this new RBridge
would use shortest path routing as opposed to spanning tree.

--> 
--> c) it's more options for customers to understand in the 
--> purchasing decision

Possibly I expect customers can be smarter.  For example, I
am pretty sure we can count on the "good-guy RBridge" vendor
to educate customers.  :-)

Also, this is another reason to provide an Applicability RFC.

--> 
--> Anyway, what do people think?
--> 
--> Should VLAN filtering be a MUST?
--> 
--> Should IP-multicast filtering be a MUST?

I am happy to accept any "informed" decision the working group
comes up with.

--> 
--> Radia
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

--
Eric


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2LN3ZG00422 for <[e-mail]>; Tue, 21 Mar 2006 15:03:35 -0800 (PST)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 21 Mar 2006 15:03:30 -0800 (PST)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 21 Mar 2006 15:03:29 -0800 (PST)
Received: from [152.70.2.164] (Forwarded-For: [130.129.131.251]) by mail-srv.sfvic.sunlabs.com (mshttpd); Tue, 21 Mar 2006 15:03:29 -0800
Date: Tue, 21 Mar 2006 15:03:29 -0800
From: [e-mail]
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] IGMP learning
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2006 23:03:42 -0000
Status: RO
Content-Length: 1135

Bill mentioned that document, which I have not yet read, but I wanted to first understand what the behavior
had to be. If this is indeed the behavior, then perhaps we can refer to that document rather than
specifying the details in the TRILL document. (I just found out about that document, and wanted to
quickly document the issues that came up at the meeting).

Radia



----- Original Message -----
From: Erik Nordmark <[e-mail]>
Date: Tuesday, March 21, 2006 2:21 pm
Subject: Re: [rbridge] IGMP learning

> 
> Shouldn't the rbridges behavior for IGMP just be identical to IGMP 
> snooping bridges?
> 
> My (perhaps incorrect) understanding is that this is specified in
> 	draft-ietf-magma-snoop-12.txt
> 	RFC 4286 Multicast Router Discovery
> 
> The only thing special for rbridges is how they handle the 
> "overlay 
> topology" (the topology between the rbridges) - presumably this 
> should 
> be viewed as a virtual switch port on each rbridge.
> 
>    Erik
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
> 



Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2LMMwG16217 for <[e-mail]>; Tue, 21 Mar 2006 14:22:58 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.68.36]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k2LMMvdK003781 for <[e-mail]>; Tue, 21 Mar 2006 14:22:57 -0800 (PST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with ESMTP id k2LMMsD6806053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 Mar 2006 14:22:57 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 21 Mar 2006 14:21:25 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5 (X11/20060113)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] IGMP learning
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2006 22:23:42 -0000
Status: RO
Content-Length: 429

Shouldn't the rbridges behavior for IGMP just be identical to IGMP 
snooping bridges?

My (perhaps incorrect) understanding is that this is specified in
	draft-ietf-magma-snoop-12.txt
	RFC 4286 Multicast Router Discovery

The only thing special for rbridges is how they handle the "overlay 
topology" (the topology between the rbridges) - presumably this should 
be viewed as a virtual switch port on each rbridge.

    Erik





Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2LKs8G15371 for <[e-mail]>; Tue, 21 Mar 2006 12:54:08 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 21 Mar 2006 12:54:03 -0800 (PST)
Received: from sun.com ([129.150.21.62]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 21 Mar 2006 12:54:03 -0800 (PST)
Date: Tue, 21 Mar 2006 12:54:04 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] IGMP learning
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2006 20:54:52 -0000
Status: RO
Content-Length: 3157

Another issue that we should discuss is how to do IGMP learning. After 
talking
to some multicast people, here is how I think it should work, and it is
different from what I'd specified in the protocol draft:

a) instead of flooding IGMP announcements to every link "in case there's 
an IP multicast
router there" (which is what the current draft says), there is a way for 
RBridges
to learn if there is a multicast router on their port. If so, then the 
RBridge must
announce "I have a link with an IP multicast router" in its 
core-instance of IS-IS.

b) IGMP announcements need not be flooded; they only need to go to links 
on which
there are IP multicast routers. And actually, IGMP announcements must 
not go onto
links with IP endnodes, because some versions of IGMP have an endnode 
suppress an
announcement if they hear an announcement that some other endnode is 
also in that
group (since the IP endnode thinks the whole campus is one link).

This would seem like a contradiction, since the announcement MUST go 
onto a link if
there is an IP multicast router there, and MUST NOT go onto a link if 
there is
an IP endnode...so what would one do with a link that has both? But the 
answer is
that the announcement MUST go onto the link, which will suppress the 
announcement
of the endnode (for some versions of IGMP). But that's OK, because all 
IP multicast
traffic MUST be delivered to all links containing an IP multicast router 
(in that
VLAN).

***********
So now the design:

a) RBridges must do IP multicast router discovery
b) The Designated RBridge must announce,
in the per-VLAN instance of IS-IS, "I have an attached IP
multicast router"
c) The Designated RBridge must listen to IGMP announcements, and learn which
IP multicast addresses have listeners on its attached link
d) The Designated RBridge must flood IGMP announcements, and internal 
RBridges
distribute this along the ingress RBridge tree (of the Designated 
RBridge that
injects the IGMP announcement), and filter whether there are any IP 
Multicast
Routers downstream on that ingress RBridge tree
e) Designated RBridges that see this forwarded IGMP announcement decapsulate
and forward the announcement on any attached links for which there are 
IP Multicast
Routers
f) The Desiganted RBridge announces, in its per-VLAN instance of IS-IS, 
which IP
multicast groups it has receivers for
g) A Designated RBridge that sees a multicast packet (with MAC address 
derived from
an IP multicast address) encapsulates the packet and sends it into the 
campus
on the ingress RBridge tree with itself as "ingress RBridge".
h) Other RBridges forward based on that tree, but filter based on VLAN 
as well as
multicast address. To be more specific, if ports p1, p2, and p3 are 
outgoing ports for that ingress RBridge tree, and if the packet is 
marked VLAN A, then if no VLAN A links
exist on p3, then don't forward onto p3. Now (given that VLAN A is 
reachable from
both ports p1 and p2), forward on p1 if there are multicast listeners 
for that group
reachable on that branch, OR if there are multicast IP routers reachable 
on that branch.

Does this seem right to people?

Radia



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2LKYxG07765 for <[e-mail]>; Tue, 21 Mar 2006 12:34:59 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 21 Mar 2006 12:34:51 -0800 (PST)
Received: from sun.com ([129.150.21.62]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 21 Mar 2006 12:34:51 -0800 (PST)
Date: Tue, 21 Mar 2006 12:34:48 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Must/Should flooding optimization
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2006 20:35:46 -0000
Status: RO
Content-Length: 1978

When a multicast or unknown destination packet is forwarded by RBridges, 
it is sent along the
ingress RBridge rooted at the ingress RBridge. However, RBRidges along 
the way can prune
the packet so that the packet only reaches links that have interested 
receivers. There are two
pieces of pruning information:
a) which egress RBridges are attached to which VLANs (so a packet marked 
VLAN A need not be forwarded
to RBridges that have no links attached to VLAN A)
b) which egress RBridges have interested receivers for IP-derived 
multicast addresses (as learned through IGMP
and multicast router discovery)

Eric Gray pointed out that doing this pruning is only an optimization. 
Bandwidth would be wasted if some
RBridge that was only in the "core" ignored IGMP and VLANs, and 
forwarded all non-unicasts (received
on the expected ingress port for the specified ingress RBridge tree) to 
all potential
outgoing ports in that ingress RBridge tree.

So, he argued that both forms of flooding optimization should be SHOULD, 
because
a) a vendor can build a cheaper device if it doesn't have to bother 
filtering based on these things
b) customers can buy the cheaper device it they'd like to save money, 
and don't care about saving bandwidth,
especially because in their deployment they might not be using VLANs at 
all, and have very little multicast
traffic, or there might be sections of their campus in which filtering 
won't matter for bandwidth
c) even if a vendor were planning on eventually doing all features, this 
would make phased implementation possible.

Others argued that flooding optimization should be a MUST because:
a) the spec is more complicated if things are options
b) "your cheapo nonfiltering RBridge is putting more stress on my 
good-guy RBridge downstream"
c) it's more options for customers to understand in the purchasing decision

Anyway, what do people think?

Should VLAN filtering be a MUST?
Should IP-multicast filtering be a MUST?

Radia



Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2LDZfG12583 for <[e-mail]>; Tue, 21 Mar 2006 05:35:42 -0800 (PST)
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 21 Mar 2006 08:35:36 -0500
X-IronPort-AV: i="4.03,114,1141621200";  d="scan'208"; a="84602581:sNHT30445224"
Received: from [204.96.115.72] (rtp-vpn2-424.cisco.com [10.82.241.168]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2LDZZWc000358;  Tue, 21 Mar 2006 08:35:35 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 21 Mar 2006 08:35:35 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] VLAN tag for the encapsulated packets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2006 13:36:37 -0000
Status: RO
Content-Length: 2784

I would say the simplest way to address this would be using the 
mutltitopology extensions proposed for IS-IS.... We might need to tweak 
them some, but, in principle, it's the same problem.

I have to poke at the IS-IS extensions draft:

http://www.ietf.org/internet-drafts/draft-ward-l2isis-01.txt

....anyway, I can look at making certain the extensions we're using 
includes the ability to use the multitopology stuff.

:-)

Russ

Gray, Eric wrote:
> Rute,
> 
> 	I had a brief dialog with Saikat off-line and I think I
> can explain the issue that relates to your question below.  In
> a sense, that portion of this discussion does relate to RBridges.
> 
> 	The problem is a result of a combination of confusion on
> how VLAN aware bridges are supposed to work when the physical 
> topology has bridges participating in multiple overlapping VLANs, 
> and some practical implementation issues in these cases.
> 
> 	Technically, each VLAN is supposed to be treated as if it
> is logically distinct from all other VLANs - even when multiple
> VLANs share the same facilities and devices.  Practically, this
> can lead to difficulty in correctly handling "virtualization" of 
> LAN resources - including VLAN aware bridges, links, etc.
> 
> 	If the virtualization is done correctly, than the "shortest
> path" across VLAN aware bridges and RBridges can never include a
> bridge or RBridge that is not part of the applicable VLAN. 
> 
> 	On the other hand, it is possible to produce a realistic
> scenario in which the topologically shortest path (in terms of
> the physical topology) between two devices that are part of a
> specific VLAN includes one or more VLAN aware devices that are 
> not part of that VLAN.  It is thus possible for implementations
> to (incorrectly) determine a topologically shortest path that 
> may take VLAN tagged frames across links/devices, where those
> devices would not know what to do with them.
> 
> 	This simply should not occur in implementations, because
> - if it does - the virtualization of VLAN resources is broken.
> For RBridges, the way to avoid this is simply not to consider
> links that are not part of a specific VLAN when computing the
> shortest path Ingress RBridge Tree associated with that VLAN.
> 
> --
> Eric
> 
> -- [SNIP] -- 
> --> 
> --> Trying to go to your issue about VLAN tagging (I did not fully
> --> understand it, like the rest of the people). Rbridges performs 
> --> Ethernet *encapsulation*, not VLAN stacking. There is a difference. 
> -->
> --> They may or not rely on VLAN IDs, but can you please further 
> --> clarify the question you have?
> --> 
> -- [SNIP] -- 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2FGZcG08026 for <[e-mail]>; Wed, 15 Mar 2006 08:35:39 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k2FGZWgL024585; Wed, 15 Mar 2006 11:35:32 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17529;  Wed, 15 Mar 2006 11:35:31 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <FG7SM4VR>; Wed, 15 Mar 2006 11:35:30 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Sofia, Rute" <[e-mail]>
Date: Wed, 15 Mar 2006 11:35:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] VLAN tag for the encapsulated packets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 15 Mar 2006 16:36:31 -0000
Status: RO
Content-Length: 2089

Rute,

	I had a brief dialog with Saikat off-line and I think I
can explain the issue that relates to your question below.  In
a sense, that portion of this discussion does relate to RBridges.

	The problem is a result of a combination of confusion on
how VLAN aware bridges are supposed to work when the physical 
topology has bridges participating in multiple overlapping VLANs, 
and some practical implementation issues in these cases.

	Technically, each VLAN is supposed to be treated as if it
is logically distinct from all other VLANs - even when multiple
VLANs share the same facilities and devices.  Practically, this
can lead to difficulty in correctly handling "virtualization" of 
LAN resources - including VLAN aware bridges, links, etc.

	If the virtualization is done correctly, than the "shortest
path" across VLAN aware bridges and RBridges can never include a
bridge or RBridge that is not part of the applicable VLAN. 

	On the other hand, it is possible to produce a realistic
scenario in which the topologically shortest path (in terms of
the physical topology) between two devices that are part of a
specific VLAN includes one or more VLAN aware devices that are 
not part of that VLAN.  It is thus possible for implementations
to (incorrectly) determine a topologically shortest path that 
may take VLAN tagged frames across links/devices, where those
devices would not know what to do with them.

	This simply should not occur in implementations, because
- if it does - the virtualization of VLAN resources is broken.
For RBridges, the way to avoid this is simply not to consider
links that are not part of a specific VLAN when computing the
shortest path Ingress RBridge Tree associated with that VLAN.

--
Eric

-- [SNIP] -- 
--> 
--> Trying to go to your issue about VLAN tagging (I did not fully
--> understand it, like the rest of the people). Rbridges performs 
--> Ethernet *encapsulation*, not VLAN stacking. There is a difference. 
-->
--> They may or not rely on VLAN IDs, but can you please further 
--> clarify the question you have?
--> 
-- [SNIP] -- 


Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2F9m2G23421 for <[e-mail]>; Wed, 15 Mar 2006 01:48:02 -0800 (PST)
Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k2F9ltaL023832 for <[e-mail]>; Wed, 15 Mar 2006 10:47:55 +0100
Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k2F9lsO4028384 for <[e-mail]>; Wed, 15 Mar 2006 10:47:55 +0100
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 15 Mar 2006 10:47:54 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 15 Mar 2006 10:47:54 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Please disregard the previous mail
thread-index: AcZHntFjQWppG2nRQvSGa4LoKdvOWgAAHBmQAByBHSAAAQfF0A==
From: "Sofia, Rute" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 15 Mar 2006 09:47:54.0648 (UTC) FILETIME=[88652180:01C64815]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k2F9m2G23421
Subject: [rbridge] Please disregard the previous mail
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 15 Mar 2006 09:48:27 -0000
Status: RO
Content-Length: 174

All,

my appologies for the last mail, I have no intention to feed a
discussion that is really not related to Rbridges itself. I am really
sorry for the wrong posting,

Rute


Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2F9kXG23014 for <[e-mail]>; Wed, 15 Mar 2006 01:46:33 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CD14AA5587; Wed, 15 Mar 2006 10:46:25 +0100 (CET)
Received: from [163.117.55.85] (unknown [163.117.55.85]) by smtp01.uc3m.es (Postfix) with ESMTP id 4419DA55BD; Wed, 15 Mar 2006 10:46:24 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 15 Mar 2006 10:46:24 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] VLAN tag for the encapsulated packets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 15 Mar 2006 09:47:32 -0000
Status: RO
Content-Length: 2962

I will not discuss the point, but only express the feeling that 
questions like this are  an indication that the combination of  spanning 
tree protocols, VLANs and  IS-IS  increases the complexity of the proposal.
Guillermo 

Sofia, Rute wrote:

>Saikat,
>
>the issues you are raising have in fact nothing to do with Rbridges but
>with the regular operation of STP/RSTP, etc.
>Answering your questions next, because there is no reason to do this on
>the Rbridges mlist:
>
>
>  
>
>>>In this case, you are talking about a LAN segment that is a link 
>>>between RBridges R1 and R2.  Presumably is has other 
>>>      
>>>
>>connectivity as 
>>    
>>
>>>well (hosts, routers, other RBridges, etc.).
>>>      
>>>
>>First, how many spanning tree instances will there be in this 
>>LAN segment if some physical links (ports of legacy bridges) 
>>are marked as VLAN1 and the rest as VLAN2?
>>
>>    
>>
>
>A VLAN is *always* associated to a ST. In other words, you cannot have a
>ST extending for two VLANs. This is in fact why STP is not suitable for
>scenarios where MSTP works better. Some time ago, I gave you an
>unpolished draft of a document which summarized most of the approaches
>and the differences between them. In this case you have to divert a bit
>from the algorithmic part and dig deeper into the protocolar. When you
>have a protocol that relies on multiple-STs, like MSTP, then you need of
>course either 1) a generic ST where you perform the broadcasts -
>forwarding of unknown/multicast traffic 2) two STs per bridge, etc.
>
>For instance, MSTP creates several STs (different VLANs) which may or
>not consist of the same bridges. This is great, allows load-balancing,
>etc, but requires a different ST when traffic has unknown destination
>(or multicast destination). So they do it with a common tree. The same
>goes for GOE: they create, for known traffic, a ST instance (associated
>to a different VLAN ID) per edge bridge, and then use a common ST for
>backward compatibility and for unknwon traffic.
>
>  
>
>>That's the problem. How do legacy handle a packet that has no VLAN ID?
>>
>>    
>>
>
>Trying to go to your issue about VLAN tagging (I did not fully
>understand it, like the rest of the people). Rbridges performs Ethernet
>*encapsulation*, not VLAN stacking. There is a difference. They may or
>not rely on VLAN IDs, but can you please further clarify the question
>you have?
>
>Also, a remark: in the future, I hope that these type of questions can
>first be exchanged among *us*, me included. It would possibly be
>quicker...then, if I cannot answer some question you have about some
>mechanism, there's the rest of the people :P
>
>Rute
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

-- 
Prof. Dr. Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid
http://www.it.uc3m.es/netcom/
609177932



Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2F9WCG18217 for <[e-mail]>; Wed, 15 Mar 2006 01:32:12 -0800 (PST)
Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k2F9W0A1013221; Wed, 15 Mar 2006 10:32:00 +0100
Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k2F9Vxgx003198; Wed, 15 Mar 2006 10:31:59 +0100
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 15 Mar 2006 10:31:49 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 15 Mar 2006 10:31:48 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] VLAN tag for the encapsulated packets
thread-index: AcZHntFjQWppG2nRQvSGa4LoKdvOWgAAHBmQAByBHSA=
From: "Sofia, Rute" <[e-mail]>
To: <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 15 Mar 2006 09:31:49.0890 (UTC) FILETIME=[495ABE20:01C64813]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k2F9WCG18217
Cc: [e-mail]
Subject: Re: [rbridge] VLAN tag for the encapsulated packets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 15 Mar 2006 09:32:30 -0000
Status: RO
Content-Length: 2326

Saikat,

the issues you are raising have in fact nothing to do with Rbridges but
with the regular operation of STP/RSTP, etc.
Answering your questions next, because there is no reason to do this on
the Rbridges mlist:


> 
> > In this case, you are talking about a LAN segment that is a link 
> > between RBridges R1 and R2.  Presumably is has other 
> connectivity as 
> > well (hosts, routers, other RBridges, etc.).
> 
> First, how many spanning tree instances will there be in this 
> LAN segment if some physical links (ports of legacy bridges) 
> are marked as VLAN1 and the rest as VLAN2?
> 

A VLAN is *always* associated to a ST. In other words, you cannot have a
ST extending for two VLANs. This is in fact why STP is not suitable for
scenarios where MSTP works better. Some time ago, I gave you an
unpolished draft of a document which summarized most of the approaches
and the differences between them. In this case you have to divert a bit
from the algorithmic part and dig deeper into the protocolar. When you
have a protocol that relies on multiple-STs, like MSTP, then you need of
course either 1) a generic ST where you perform the broadcasts -
forwarding of unknown/multicast traffic 2) two STs per bridge, etc.

For instance, MSTP creates several STs (different VLANs) which may or
not consist of the same bridges. This is great, allows load-balancing,
etc, but requires a different ST when traffic has unknown destination
(or multicast destination). So they do it with a common tree. The same
goes for GOE: they create, for known traffic, a ST instance (associated
to a different VLAN ID) per edge bridge, and then use a common ST for
backward compatibility and for unknwon traffic.

> 
> That's the problem. How do legacy handle a packet that has no VLAN ID?
> 

Trying to go to your issue about VLAN tagging (I did not fully
understand it, like the rest of the people). Rbridges performs Ethernet
*encapsulation*, not VLAN stacking. There is a difference. They may or
not rely on VLAN IDs, but can you please further clarify the question
you have?

Also, a remark: in the future, I hope that these type of questions can
first be exchanged among *us*, me included. It would possibly be
quicker...then, if I cannot answer some question you have about some
mechanism, there's the rest of the people :P

Rute


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2ELn2G09983 for <[e-mail]>; Tue, 14 Mar 2006 13:49:02 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k2ELmugL004477; Tue, 14 Mar 2006 16:48:56 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA29656;  Tue, 14 Mar 2006 16:48:56 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <FG7SLX16>; Tue, 14 Mar 2006 16:48:55 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: [e-mail]
Date: Tue, 14 Mar 2006 16:48:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: Re: [rbridge] VLAN tag for the encapsulated packets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2006 21:49:17 -0000
Status: RO
Content-Length: 1493

Saikat,

	Yes, but that just moves the question into the past.

	To have an entry that timed out, there must exist some 
form of connectivity - at least if the entry was correct for
the current scenario.  It is possible that the network has 
changed, but that's similar to saying it's possible a host 
was turned off - i.e. - the network may be disfunctional as 
far as some specific device is concerned.

	Assuming that there is a functional network connection
between RBridges R1 and R2, then either they are part of the 
same broadcast domain (hence flooding works) or they are not
(hence routing is necessarily involved).

	Barring a change in network topology that shifts the
relationship from one scenario to the other, then the fact
that a forwarding entry was obtainable previously means an
entry will be obtainable again.

	If there was a significant topology change, then 
other mechanisms will be involved.

--
Eric


--> -----Original Message-----
--> From: Saikat Ray [mailto:[e-mail]] 
--> Sent: Tuesday, March 14, 2006 3:18 PM
--> To: 'Gray, Eric'
--> Cc: 'Developing a hybrid router/bridge.'; 'Radia Perlman'
--> Subject: RE: [rbridge] VLAN tag for the encapsulated packets
--> 
--> > Why would this happen?  Some frame sender, somewhere, has to
--> > know that R2 exists or it would not have sent a frame to R2.
--> 
--> There is an aging mechanism on the legacy bridge entries. 
--> It is perfectly possible that the forwarding entry had 
--> been deleted.
--> 


Received: from lion.seas.upenn.edu (LION.SEAS.upenn.edu [158.130.12.194]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2EKI6G09746 for <[e-mail]>; Tue, 14 Mar 2006 12:18:06 -0800 (PST)
Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id k2EKI1hJ012198 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Mar 2006 15:18:01 -0500
Message-Id: <[e-mail]>
From: "Saikat Ray" <[e-mail]>
To: "'Gray, Eric'" <[e-mail]>
Date: Tue, 14 Mar 2006 15:18:24 -0500
Organization: University of Pennsylvania
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
Thread-Index: AcZHo2GjIhBtGQOGSvagz2F2yyqExwAAJenQ
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, 'Radia Perlman' <[e-mail]>
Subject: Re: [rbridge] VLAN tag for the encapsulated packets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2006 20:18:18 -0000
Status: RO
Content-Length: 255

> Why would this happen?  Some frame sender, somewhere, has to
> know that R2 exists or it would not have sent a frame to R2.

There is an aging mechanism on the legacy bridge entries. It is perfectly
possible that the forwarding entry had been deleted.



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2EKAdG07539 for <[e-mail]>; Tue, 14 Mar 2006 12:10:39 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k2EKAWgL002186; Tue, 14 Mar 2006 15:10:32 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17748;  Tue, 14 Mar 2006 15:10:31 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <FG7SLT7D>; Tue, 14 Mar 2006 15:10:31 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: [e-mail]
Date: Tue, 14 Mar 2006 15:10:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, 'Radia Perlman' <[e-mail]>
Subject: Re: [rbridge] VLAN tag for the encapsulated packets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2006 20:11:23 -0000
Status: RO
Content-Length: 3316

Saikat,

	Unfortunately, by demonstrating that the problem is
not related to operation of RBridges, you make it clear 
that most of this question is out of scope for this working 
group and this mailing list.  For the rest of the question,
see below.

	I'm happy to discuss this with you - to some degree
- off-line.  :-)

	This mailing list is not intended to be a forum for
discussing proper deployment, configuration and operation 
of VLAN equipment - at least not in the general sense.

	That includes specifically (but is not limited to)
how spanning trees work (or don't work) in VLANs involving
existing bridges.

	On the portion of the question concerning the way
in which RBridges that are not on a common VLAN will pass 
frames to each other, see in-line below...

--
Eric

--> -----Original Message-----
--> From: Saikat Ray [mailto:[e-mail]] 
--> Sent: Tuesday, March 14, 2006 2:31 PM
--> To: 'Gray, Eric'
--> Cc: 'Developing a hybrid router/bridge.'; 'Radia Perlman'
--> Subject: RE: [rbridge] VLAN tag for the encapsulated packets
--> 

... [SNIP] ...

--> Now consider two RBridges attached to this legacy LAN, R1 
--> and R2. Now consider the case when R1 sends the first packet 
--> to R2 which have no VLAN ID. 

Why would this happen?  Some frame sender, somewhere, has to 
know that R2 exists or it would not have sent a frame to R2.

If R2 is known, then its VLAN context is most likely known as
well (R2's MAC would only have been returned in response to an
ARP in the approriate VLAN context).

Remember that a VLAN - like a LAN - is separated from other 
LANs (and VLANs) by a router.

--> At that time [bridges] on this [LAN] do not have an entry 
--> for the MAC address of R2 on their forwarding database.  
--> Thus they need to broadcast on the [LAN]. 

LAN and VLAN contexts are logically identical.  Entities are
either in the same (V)LAN context, or they are not.  If they
are not than they are not in the same broadcast domain and
broadcasts are not used to convey frames beyond the (V)LAN
context.

--> 
--> Which spanning tree will they use (I am assuming that there 
--> are two instances of the spanning tree, one for VLAN1 and 
--> the other for VLAN2)? 

The assumption that there are two spanning trees implies that
the bridges are aware (e.g. - configured) with VLAN information
at least relating to VLAN1 and VLAN2.  In this case, VLAN aware
bridges will not share broadcast traffic between VLANs.

-->
--> Now suppose that VLAN1 does not connect R1 and R2.

Then R1 and R2 are not in the same broadcast domain and
are _necessarily_ separated by a routing function.

In this case, R1 is part of one RBridge campus and R2 is
part of another.

--> 
--> Then if R1 sends a packet for R2 with VLAN ID set to 
--> VLAN1, or if the legacy bridges use VLAN1 for sending

If, by R2, you mean R2's MAC address, this will not happen.
For R1 to send a frame to R2 - in a different VLAN context
- R1 will address the frame to the router whose MAC address
in VLAN1 is returned by ARP when R1 (or the original sender)
first tried to reach R2 (by a higher level <IP> address).

--> a packet with empty VLAN tag, then how will R2 get the 
--> (encapsulated) packet from R1? Put it differently, how 
--> will R1 know that it must use VLAN2 as the VLAN ID to 
--> reach R2?
--> 


Received: from lion.seas.upenn.edu (LION.SEAS.upenn.edu [158.130.12.194]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2EJqdG01449 for <[e-mail]>; Tue, 14 Mar 2006 11:52:39 -0800 (PST)
Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id k2EJqS3E011566 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Mar 2006 14:52:28 -0500
Message-Id: <[e-mail]>
From: "Saikat Ray" <[e-mail]>
To: "'Gray, Eric'" <[e-mail]>
Date: Tue, 14 Mar 2006 14:52:50 -0500
Organization: University of Pennsylvania
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
Thread-Index: AcZHntFjQWppG2nRQvSGa4LoKdvOWgAAHBmQ
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, 'Radia Perlman' <[e-mail]>
Subject: Re: [rbridge] VLAN tag for the encapsulated packets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2006 19:53:19 -0000
Status: RO
Content-Length: 2541

> In this case, you are talking about a LAN segment that is a
> link between RBridges R1 and R2.  Presumably is has other
> connectivity as well (hosts, routers, other RBridges, etc.).

First, how many spanning tree instances will there be in this LAN segment if
some physical links (ports of legacy bridges) are marked as VLAN1 and the
rest as VLAN2?

> R1 and R2 can be either VLAN aware or not.  In order to work
> in this scenario, if either of these is VLAN unaware, MAC
> addresses must be unique within the LAN context - but this is
> the case whenever VLAN un-aware bridges are used in a VLAN
> context.

That's fine. I assume that each RBridge has a globally unique MAC address.

> In scenarios like this, if the RBridges are intended to be
> VLAN aware (and behave accordingly) then they require all of
> the same VLAN association information that any other VLAN
> aware bridge would require. 

More than that. They need to maintain separate "link-cost" (and thus
separate forwarding decisions) to the neighboring RBridges for different
VLAN IDs. The set of "neighboring RBridges" would be different depending on
the VLAN ID.

> Similarly, if the RBridges are
> not intended to be VLAN aware (and behave accordingly) then
> they will deliver VLAN tagged frames on links they would not
> if they were VLAN aware.

That's the problem. How do legacy handle a packet that has no VLAN ID?

[snip]

> --> And, finally what happens when R1 sends an encapsulated
> --> packet to R2 with no VLAN ID and the legacy bridges on this
> --> legacy LAN do not know about the location of R2?
> 
> R2 has a MAC address.

I understand that. But the legacy bridges may not yet have "learned" that
MAC address; i.e., in the forwarding databases of the legacy LANs, that MAC
address may not exist. In that case the legacy bridges must broadcast the
packet on to every port that belongs to "a spanning tree" except on the one
where it received the packet. Now this is the issue: the spanning tree, no
matter whichever it is, must be the same on every legacy bridge to avoid the
possibility of a loop. How is it done?

> -->
> --> Isn't there a possibility that R2 would not get the packet
> --> in the previous scenarios?
> 
> No.

There is a possibility if there are multiple spanning trees (one per VLAN
ID) in the LAN segment. Hopefully my previous example will make it clear.

> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://www.postel.org/mailman/listinfo/rbridge
> -->



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2EJc0G26515 for <[e-mail]>; Tue, 14 Mar 2006 11:38:00 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k2EJbrgL001276; Tue, 14 Mar 2006 14:37:54 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13337;  Tue, 14 Mar 2006 14:37:53 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <FG7SLS42>; Tue, 14 Mar 2006 14:37:53 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: [e-mail]
Date: Tue, 14 Mar 2006 14:37:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, 'Radia Perlman' <[e-mail]>
Subject: Re: [rbridge] VLAN tag for the encapsulated packets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2006 19:38:21 -0000
Status: RO
Content-Length: 3902

Saikat,

	I may have answered this question in my previous mail,
but let me make sure.  Please see in-line below...

--
Eric 

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Saikat Ray
--> Sent: Tuesday, March 14, 2006 1:55 PM
--> To: 'Radia Perlman'
--> Cc: 'Developing a hybrid router/bridge.'
--> Subject: Re: [rbridge] VLAN tag for the encapsulated packets
--> 
--> Saikat:
--> =======
--> > > I have a basic doubt about it. My understanding is (and 
--> > > this could be plain wrong; please correct me if that is 
--> > > so) that there is one instance of spanning tree per VLAN 
--> > > ID. Then do bridges also create another spanning tree
--> > > instance for the "blank ID"?
--> > >
--> Radia:
--> ======
--> > Just want to clear up this misunderstanding. There is one 
--> > spanning tree per ingress RBridge.

This is an "Ingress RBridge Tree".

--> > This spanning tree is then pruned according to VLANs, as 
--> > well as IP multicast addresses. 

Standard Disclaimers: 

VLAN optimization may require explicit configuration.

Multicast address pruning is an optional optimization.
Note that multicast address pruning - while driven by
an association between an IP multicast address and a
corresponding MAC multicast address - will hinge on a
MAC multicast address in forwarding.

--> 
--> Saikat:
--> =======
--> This is at the level of RBridges (i.e., viewing the legacy 
--> LANs as "links"), right? My concern was about a given legacy 
--> LAN segment (which is a single "link" at the level of RBridges). 
--> 
--> Suppose that there are two VLANs on this legacy LAN, VLAN1 and 
--> VLAN2. Now there are two RBridges, R1 and R2, connected to this 
--> legacy LAN. Moreover, suppose that the "physical link" that 
--> connects R2 to this legacy LAN (i.e., to some legacy bridge) is 
--> on VLAN2, but not on VLAN1. Then, what happens when R1 sends 
--> an encapsulated packet to R2 with
--> 
--> i) No VLAN ID, and
--> 
--> ii) With VLAN ID set to VLAN1?
-->

First, we should avoid the term "legacy LAN".  It is well known
that the term "legacy" carries a lot of undesirable freight.

In this case, you are talking about a LAN segment that is a
link between RBridges R1 and R2.  Presumably is has other
connectivity as well (hosts, routers, other RBridges, etc.).

R1 and R2 can be either VLAN aware or not.  In order to work
in this scenario, if either of these is VLAN unaware, MAC
addresses must be unique within the LAN context - but this is
the case whenever VLAN un-aware bridges are used in a VLAN 
context.

In scenarios like this, if the RBridges are intended to be
VLAN aware (and behave accordingly) then they require all of
the same VLAN association information that any other VLAN
aware bridge would require.  Similarly, if the RBridges are
not intended to be VLAN aware (and behave accordingly) then
they will deliver VLAN tagged frames on links they would not
if they were VLAN aware.

The same observation applies within the LAN segment.  VLAN
un-aware bridges may deliver frames to an RBridge that does 
not need to receive them.

This is a problem that exists with or without RBridges.  We
cannot prevent people from making errors - in configuration 
or deployment.

These "errors" result in sub-optimal performance - possibly
to the point of pathological failure - but are not themselves
inherently pathological.


--> 
--> And, finally what happens when R1 sends an encapsulated 
--> packet to R2 with no VLAN ID and the legacy bridges on this 
--> legacy LAN do not know about the location of R2?

R2 has a MAC address.

--> 
--> Isn't there a possibility that R2 would not get the packet 
--> in the previous scenarios?

No.

--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from lion.seas.upenn.edu (LION.SEAS.upenn.edu [158.130.12.194]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2EJV5G23916 for <[e-mail]>; Tue, 14 Mar 2006 11:31:05 -0800 (PST)
Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id k2EJV0gM011150 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Mar 2006 14:31:00 -0500
Message-Id: <[e-mail]>
From: "Saikat Ray" <[e-mail]>
To: "'Gray, Eric'" <[e-mail]>
Date: Tue, 14 Mar 2006 14:31:22 -0500
Organization: University of Pennsylvania
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
Thread-Index: AcZHmyv6KudrdYFFT1eJpDuamDCdWwAAMM2w
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, 'Radia Perlman' <[e-mail]>
Subject: Re: [rbridge] VLAN tag for the encapsulated packets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2006 19:31:25 -0000
Status: RO
Content-Length: 3660

> Saikat,
> 
> 	Please see in-line below...
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [e-mail]
> --> [mailto:[e-mail]] On Behalf Of Saikat Ray
> --> Sent: Tuesday, March 14, 2006 1:32 PM
> --> To: 'Radia Perlman'; 'Developing a hybrid router/bridge.'
> --> Subject: Re: [rbridge] VLAN tag for the encapsulated packets
> -->
> --> > -----Original Message-----
> --> > From: Radia Perlman [mailto:[e-mail]]
> --> > Sent: Tuesday, March 14, 2006 1:08 PM
> --> > To: [e-mail]; Developing a hybrid router/bridge.
> --> > Subject: Re: [rbridge] VLAN tag for the encapsulated packets
> --> >
> --> > Do you mean on the outside header?
> -->
> --> Yes.
> -->
> --> > I was assuming no tag. We want all bridges that might be on an
> --> > intermediate link to be willing to forward the packet.
> -->
> --> I have a basic doubt about it. My understanding is (and
> --> this could be plain wrong; please correct me if that is
> --> so) that there is one instance of spanning tree per VLAN
> --> ID. Then do bridges also create another spanning tree
> --> instance for the "blank ID"? If they do not, which spanning
> --> tree would they use for a packet with no VLAN tag? The issue
> --> is that if there is no entry in the forwarding tables for
> --> the legacy bridges, then the encapsulated packet needs to be
> --> broadcast; in that case in order to avoid a loop, one perhaps
> --> needs to ensure that either (i) the broadcast packet is
> --> carrying a VLAN ID (which could be put in by the legacy
> --> bridges) so that the packet always goes along a given
> --> spanning tree, or (ii) the superposition of the different
> --> spanning trees is still a spanning tree. Otherwise if the
> --> packet goes from one spanning to another spanning tree, then
> --> loops are possible.
> 
> It is because of this kind of discussion that we have decided
> to use some term other than "spanning tree" for the way that
> frames are forwarded between RBridges in flooding, multicast
> and broadcast cases.

Please see my next email. I am not talking about the "Ingress RBridge Tree"
that is built by viewing each legacy LAN as a "link"; I am talking about a
single given legacy LAN (which is a single "link" at the level of RBridges)
and the spanning tree(s) in that legacy LAN.

To rephrase my question: Consider a legacy LAN (and for the moment, forget
about RBridges). Suppose that some "physical" links of this legacy LAN are
marked as VLAN1 and the rest are marked as VLAN2. Then my first question was
how many instances of spanning trees will there be in this legacy LAN? Just
one? One per VLAN (i.e., two)? One per VLAN + one for the packets with no
VLAN ID (i.e. three)? I have been told that the right answer is one per VLAN
(i.e., two); but I do not know for sure and want to confirm.

Now consider two RBridges attached to this legacy LAN, R1 and R2. Now
consider the case when R1 sends the first packet to R2 which have no VLAN
ID. At that time the legacy bridges on this legacy LAN do not have an entry
for the MAC address of R2 on their forwarding database. Thus they need to
broadcast on the legacy LAN. Which spanning tree will they use (I am
assuming that there are two instances of the spanning tree, one for VLAN1
and the other for VLAN2)? Now suppose that VLAN1 does not connect R1 and R2.
Then if R1 sends a packet for R2 with VLAN ID set to VLAN1, or if the legacy
bridges use VLAN1 for sending a packet with empty VLAN tag, then how will R2
get the (encapsulated) packet from R1? Put it differently, how will R1 know
that it must use VLAN2 as the VLAN ID to reach R2?



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2EJBqG17288 for <[e-mail]>; Tue, 14 Mar 2006 11:11:52 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k2EJBigL000499; Tue, 14 Mar 2006 14:11:45 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09717;  Tue, 14 Mar 2006 14:11:44 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <FG7SLRS5>; Tue, 14 Mar 2006 14:11:43 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: [e-mail]
Date: Tue, 14 Mar 2006 14:11:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, 'Radia Perlman' <[e-mail]>
Subject: Re: [rbridge] VLAN tag for the encapsulated packets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2006 19:12:29 -0000
Status: RO
Content-Length: 6278

Saikat,

	Please see in-line below...

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Saikat Ray
--> Sent: Tuesday, March 14, 2006 1:32 PM
--> To: 'Radia Perlman'; 'Developing a hybrid router/bridge.'
--> Subject: Re: [rbridge] VLAN tag for the encapsulated packets
--> 
--> > -----Original Message-----
--> > From: Radia Perlman [mailto:[e-mail]]
--> > Sent: Tuesday, March 14, 2006 1:08 PM
--> > To: [e-mail]; Developing a hybrid router/bridge.
--> > Subject: Re: [rbridge] VLAN tag for the encapsulated packets
--> > 
--> > Do you mean on the outside header? 
--> 
--> Yes.
--> 
--> > I was assuming no tag. We want all bridges that might be on an
--> > intermediate link to be willing to forward the packet.
--> 
--> I have a basic doubt about it. My understanding is (and 
--> this could be plain wrong; please correct me if that is 
--> so) that there is one instance of spanning tree per VLAN 
--> ID. Then do bridges also create another spanning tree
--> instance for the "blank ID"? If they do not, which spanning 
--> tree would they use for a packet with no VLAN tag? The issue 
--> is that if there is no entry in the forwarding tables for 
--> the legacy bridges, then the encapsulated packet needs to be 
--> broadcast; in that case in order to avoid a loop, one perhaps
--> needs to ensure that either (i) the broadcast packet is 
--> carrying a VLAN ID (which could be put in by the legacy 
--> bridges) so that the packet always goes along a given 
--> spanning tree, or (ii) the superposition of the different
--> spanning trees is still a spanning tree. Otherwise if the 
--> packet goes from one spanning to another spanning tree, then 
--> loops are possible.

It is because of this kind of discussion that we have decided
to use some term other than "spanning tree" for the way that
frames are forwarded between RBridges in flooding, multicast
and broadcast cases.

The term we are currently using (and encouraging others to use)
is "Ingress RBridge Tree".

What happens is that each RBridge along the path has forwarding 
entries determined for distinguishable frames.  The basic entry
is simply determined from the Link-State Routing protocol and
the local RBridge's current view of topology and shortest paths.
In the flooding, multicast and broadcast cases, distinguishing 
factors include the ingress RBridge (the source MAC in the outer 
header) and the VLAN context (tag, most likely) - at least 
primarily.

For multicast optimization, a local RBridge will likely also
include the multicast destination as a part of the look-up
and corresponding forwarding entries will be pruned based on 
some approach that is not in scope for this working group (but 
will likely involve snooping of multicast control protocol 
exchanges).

For Flooding Optimization, a local RBridge may decide to peek
inside the outer header to determine if it has a unicast entry
for the MAC destination of the inner MAC header.

Optimizations are not required behavior. However, the ability
to form and use the "Ingress RBridge Tree" mechanism is.

--> 
--> > 
--> > But now that you asked...I suppose it's possible that 
--> > there might be a link where bridges might do something 
--> > weird if there is no tag (as in, add a tag, or refuse
--> > to forward it).
--> > I guess on a link like that, there would have to be a tag.
--> 
--> Isn't there a significant configuration burden (at least 
--> similar to VLAN configuration)? E.g., how will an RBridge 
--> know which VLANs are present in the legacy LAN it is 
--> connected to? The second problem is  that a given VLAN
--> may not connect two RBridges and thus, depending up on the 
--> next hop, the current RBridge may need to choose different 
--> VLAN IDs.  Which then means that RBridges need to maintain 
--> different forwarding tables (e.g., for "link-cost") per 
--> VLAN. Is that how the system work?

The fact that VLAN configuration may be required is endemic
in your question about support for VLAN tags.  VLAN tags are
not required in the RBridge solution, except to support VLANs.
To the extent that configuration is already required for this,
it is still required for RBridges.

Either we want to avoid configuration and hence - most likely
- we avoid VLANs, or we want to support VLANs and we accept
that doing so requires no less configuration that it has in
the past.

--> 
--> > The outer header is really a hop-by-hop header, so it 
--> > should be whatever is appopriate to that hop. In theory 
--> > we could mix media, and have an intermediate link which 
--> > isn't even Ethernet, say it is link type L, in which 
--> > case the outer header would be an L header.
--> 
--> I agree.
--> 
--> > At any rate, if an intermediate bridge really did 
--> > decide to add a VLAN tag to the outer header, the
--> > next RBridge will remove the outer header anyway, 
--> > and generate a new outer header for the next hop.
--> > 
--> > Radia
--> > 
--> 
--> Yes, but the issue is with connectivity. If an intermediate 
--> legacy bridge adds a VLAN ID, is it guaranteed that the next 
--> RBridge would get the (encapsulated) packet (i.e., is it 
--> possible that the legacy bridge puts in a VLAN ID whose span 
--> does not include the next RBridge?)?

This is no more likely than it would be in a deployment that
only includes VLAN bridges.  This is a configuration error.
It is generally accepted that it is impossible (or at least
very difficult) to protect against arbitrary configuration 
errors in a protocol.

--> 
--> Thanks.
--> 
--> Saikat
--> 
--> > 
--> > Saikat Ray wrote:
--> > 
--> > >Hi All,
--> > >
--> > >I was wondering which VLAN tag will there be (if there 
--> will be any) on
--> > the
--> > >encapsulated packets.
--> > >
--> > >Thanks in advance for your answers.
--> > >
--> > >With regards,
--> > >
--> > >Saikat
--> > >
--> > >_______________________________________________
--> > >rbridge mailing list
--> > >[e-mail]
--> > >http://www.postel.org/mailman/listinfo/rbridge
--> > >
--> > >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from lion.seas.upenn.edu (LION.SEAS.upenn.edu [158.130.12.194]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2EIsjG11156 for <[e-mail]>; Tue, 14 Mar 2006 10:54:45 -0800 (PST)
Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id k2EIsi6h010448 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Mar 2006 13:54:44 -0500
Message-Id: <[e-mail]>
From: "Saikat Ray" <[e-mail]>
To: "'Radia Perlman'" <[e-mail]>
Date: Tue, 14 Mar 2006 13:55:07 -0500
Organization: University of Pennsylvania
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
Thread-Index: AcZHlr20nAj0VtsZS/iiYHZpJ+9Z3AAAORdw
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: Re: [rbridge] VLAN tag for the encapsulated packets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2006 18:55:51 -0000
Status: RO
Content-Length: 1299

> >I have a basic doubt about it. My understanding is (and this could be
> plain
> >wrong; please correct me if that is so) that there is one instance of
> >spanning tree per VLAN ID. Then do bridges also create another spanning
> tree
> >instance for the "blank ID"?
> >
> Just want to clear up this misunderstanding. There is one spanning tree
> per ingress RBridge.
> This spanning tree is then pruned according to VLANs, as well as IP
> multicast addresses. 

This is at the level of RBridges (i.e., viewing the legacy LANs as "links"),
right? My concern was about a given legacy LAN segment (which is a single
"link" at the level of RBridges). Suppose that there are two VLANs on this
legacy LAN, VLAN1 and VLAN2. Now there are two RBridges, R1 and R2,
connected to this legacy LAN. Moreover, suppose that the "physical link"
that connects R2 to this legacy LAN (i.e., to some legacy bridge) is on
VLAN2, but not on VLAN1. Then, what happens when R1 sends an encapsulated
packet to R2 with
i) No VLAN ID, and
ii) With VLAN ID set to VLAN1?

And, finally what happens when R1 sends an encapsulated packet to R2 with no
VLAN ID and the legacy bridges on this legacy LAN do not know about the
location of R2?

Isn't there a possibility that R2 would not get the packet in the previous
scenarios?



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2EIe5G06218 for <[e-mail]>; Tue, 14 Mar 2006 10:40:06 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 14 Mar 2006 10:40:00 -0800 (PST)
Received: from sun.com ([129.150.26.73]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 14 Mar 2006 10:40:00 -0800 (PST)
Date: Tue, 14 Mar 2006 10:39:59 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: Re: [rbridge] VLAN tag for the encapsulated packets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2006 18:40:15 -0000
Status: RO
Content-Length: 1776

Saikat Ray wrote:

>
>I have a basic doubt about it. My understanding is (and this could be plain
>wrong; please correct me if that is so) that there is one instance of
>spanning tree per VLAN ID. Then do bridges also create another spanning tree
>instance for the "blank ID"? 
>
Just want to clear up this misunderstanding. There is one spanning tree 
per ingress RBridge.
This spanning tree is then pruned according to VLANs, as well as IP 
multicast addresses.

So the actual spanning tree is selected based on the "ingress RBridge" 
specified in the shim header.
This spanning tree defines outgoing ports. Then, for each outgoing port 
(for this particular spanning tree),
there is a list of VLANs reachable through that port in this spanning 
tree, as well as IP multicasts.

So, that means if there is a VLAN A packet that is introduced into the 
campus by RBridge R1, the
shim header will indicate "R1". Some RBridge R2, in the center of the 
campus, receives the encapsulated
packet via port P1, say. R2 first says "is P1 the correct in-link for 
the "ingress R1" spanning tree? If not,
R2 drops the packet. If yes, then R2 will forward the packet onto some 
subset of the ports that are
indicated as outgoing for the ingress-R1-spanning tree. Let's say that 
in the Dijstra calculation that
calculates the ingress-R1 spanning tree, R2 concludes that ports P2, P7, 
and P8 are outgoing ports
for that spanning tree (with P1 the incoming port for that spanning 
tree). R2 has also marked that
there are VLAN A links reachable via P7 and P8, but not P2. THerefore, 
R2 will forward the
packet onto P7 and P8.

Hope that's understandable. Otherwise I'll have to draw those little 
ASCII pictures, which I hate drawing (and
only slightly less hate reading). :-)

Radia



Received: from lion.seas.upenn.edu (LION.SEAS.upenn.edu [158.130.12.194]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2EIVGG02779 for <[e-mail]>; Tue, 14 Mar 2006 10:31:17 -0800 (PST)
Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id k2EIVFwW009977 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Mar 2006 13:31:16 -0500
Message-Id: <[e-mail]>
From: "Saikat Ray" <[e-mail]>
To: "'Radia Perlman'" <[e-mail]>, "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Tue, 14 Mar 2006 13:31:38 -0500
Organization: University of Pennsylvania
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
Thread-Index: AcZHkketID2JrdI2S7+Z+VoaJ/ry4wAAI3TQ
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] VLAN tag for the encapsulated packets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2006 18:32:20 -0000
Status: RO
Content-Length: 3240

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]]
> Sent: Tuesday, March 14, 2006 1:08 PM
> To: [e-mail]; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] VLAN tag for the encapsulated packets
> 
> Do you mean on the outside header? 

Yes.

> I was assuming no tag. We want all bridges that might be on an
> intermediate link to be willing to forward the packet.

I have a basic doubt about it. My understanding is (and this could be plain
wrong; please correct me if that is so) that there is one instance of
spanning tree per VLAN ID. Then do bridges also create another spanning tree
instance for the "blank ID"? If they do not, which spanning tree would they
use for a packet with no VLAN tag? The issue is that if there is no entry in
the forwarding tables for the legacy bridges, then the encapsulated packet
needs to be broadcast; in that case in order to avoid a loop, one perhaps
needs to ensure that either (i) the broadcast packet is carrying a VLAN ID
(which could be put in by the legacy bridges) so that the packet always goes
along a given spanning tree, or (ii) the superposition of the different
spanning trees is still a spanning tree. Otherwise if the packet goes from
one spanning to another spanning tree, then loops are possible.

> 
> But now that you asked...I suppose it's possible that there might be a
> link where bridges
> might do something weird if there is no tag (as in, add a tag, or refuse
> to forward it).
> I guess on a link like that, there would have to be a tag.

Isn't there a significant configuration burden (at least similar to VLAN
configuration)? E.g., how will an RBridge know which VLANs are present in
the legacy LAN it is connected to? The second problem is that a given VLAN
may not connect two RBridges and thus, depending up on the next hop, the
current RBridge may need to choose different VLAN IDs. Which then means that
RBridges need to maintain different forwarding tables (e.g., for
"link-cost") per VLAN. Is that how the system work?

> The outer header is really a hop-by-hop header, so it should be whatever
> is appopriate to
> that hop. In theory we could mix media, and have an intermediate link
> which isn't even Ethernet,
> say it is link type L,
> in which case the outer header would be an L header.

I agree.

> At any rate, if an intermediate bridge really did decide to add a VLAN
> tag to the outer header,
> the next RBridge will remove the outer header anyway, and generate a new
> outer header for
> the next hop.
> 
> Radia
> 

Yes, but the issue is with connectivity. If an intermediate legacy bridge
adds a VLAN ID, is it guaranteed that the next RBridge would get the
(encapsulated) packet (i.e., is it possible that the legacy bridge puts in a
VLAN ID whose span does not include the next RBridge?)?

Thanks.

Saikat

> 
> Saikat Ray wrote:
> 
> >Hi All,
> >
> >I was wondering which VLAN tag will there be (if there will be any) on
> the
> >encapsulated packets.
> >
> >Thanks in advance for your answers.
> >
> >With regards,
> >
> >Saikat
> >
> >_______________________________________________
> >rbridge mailing list
> >[e-mail]
> >http://www.postel.org/mailman/listinfo/rbridge
> >
> >



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2EI8LG25187 for <[e-mail]>; Tue, 14 Mar 2006 10:08:21 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 14 Mar 2006 10:08:13 -0800 (PST)
Received: from sun.com ([129.150.26.73]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 14 Mar 2006 10:08:13 -0800 (PST)
Date: Tue, 14 Mar 2006 10:08:12 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] VLAN tag for the encapsulated packets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2006 18:09:25 -0000
Status: RO
Content-Length: 1217

Do you mean on the outside header? I was assuming no tag. We want all 
bridges that might
be on an intermediate link to be willing to forward the packet.

But now that you asked...I suppose it's possible that there might be a 
link where bridges
might do something weird if there is no tag (as in, add a tag, or refuse 
to forward it).
I guess on a link like that, there would have to be a tag.

The outer header is really a hop-by-hop header, so it should be whatever 
is appopriate to
that hop. In theory we could mix media, and have an intermediate link 
which isn't even Ethernet,
say it is link type L,
in which case the outer header would be an L header.

At any rate, if an intermediate bridge really did decide to add a VLAN 
tag to the outer header,
the next RBridge will remove the outer header anyway, and generate a new 
outer header for
the next hop.

Radia



Saikat Ray wrote:

>Hi All,
>
>I was wondering which VLAN tag will there be (if there will be any) on the
>encapsulated packets.
>
>Thanks in advance for your answers.
>
>With regards,
>
>Saikat
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>



Received: from lion.seas.upenn.edu (LION.SEAS.upenn.edu [158.130.12.194]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2EH7UG02642 for <[e-mail]>; Tue, 14 Mar 2006 09:07:30 -0800 (PST)
Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id k2EH7T4K029397 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Tue, 14 Mar 2006 12:07:29 -0500
Message-Id: <[e-mail]>
From: "Saikat Ray" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Tue, 14 Mar 2006 12:07:51 -0500
Organization: University of Pennsylvania
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
Thread-Index: AcZBz3Jmwe1st1yWQEypCwI8pqc0swFugG/g
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] VLAN tag for the encapsulated packets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2006 17:08:21 -0000
Status: RO
Content-Length: 167

Hi All,

I was wondering which VLAN tag will there be (if there will be any) on the
encapsulated packets.

Thanks in advance for your answers.

With regards,

Saikat



Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k279eeu00475 for <[e-mail]>; Tue, 7 Mar 2006 01:40:40 -0800 (PST)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 289B7845C5 for <[e-mail]>; Tue,  7 Mar 2006 10:40:34 +0100 (CET)
Received: from [163.117.139.221] (unknown [163.117.139.221]) by smtp03.uc3m.es (Postfix) with ESMTP id EE539845C3 for <[e-mail]>; Tue,  7 Mar 2006 10:40:32 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 07 Mar 2006 10:40:34 +0100
From: =?UTF-8?B?R3VpbGxlcm1vIEliw6HDsWV6?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<002c01c640cd$e0ea1b70$[e-mail]>	<[e-mail]> <001c01c6418a$52a05790$[e-mail]>
In-Reply-To: <001c01c6418a$52a05790$[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Additioanla clarification Abridges port types Re: A question about (R)STP and routing protocol / requestfor comments to Abridges draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2006 09:40:50 -0000
Status: RO
Content-Length: 15620

 I agree that the text in the draft is somewhat misleading regarding 
learning in the core. Learning occurs in the Acces side of the Abridges 
and does not in the Core side.
I will state more sharply these issues in next draft version.
Regards
Guillermo
robey wrote:

>Hi,Guillermo,
>See my interleaving opions.
>Thank you much!
>Robey
>
>----- Original Message ----- 
>From: "Guillermo Ibáñez" <[e-mail]>
>To: "Developing a hybrid router/bridge." <[e-mail]>
>Sent: Monday, March 06, 2006 5:56 PM
>Subject: Re: [rbridge] Additioanla clarification Abridges port types Re: A question about (R)STP and routing protocol / requestfor comments to Abridges draft
>
>
>  
>
>>robey wrote:
>>
>>    
>>
>>>Hi, Guillermo,
>>>
>>>
>>>
>>>I have the following questions to ask for you about the Abridge draft:
>>>
>>>
>>>
>>>(1) In one part of the daft it said ?Abridges overcome Rbridges L2 network size restrictions allowing applicability to very large Ethernet campus networks while maintaining zero configuration and high performance?,But I know when Abridges are applied in core network, you have to do some configuration, e.g. determine which abridge is edge bridge (do you want to each abridge is edge bridge, so don?t need to configure?),so how  can we maintain zero configuration? .
>>>
>>>      
>>>
>>By default all Abridges are edge bridges, transit Abridges are a subset 
>>functionally of edge Abridges. As in current spanning tree protocols, 
>>mechanisms operate at port level. A port detecting STP or RSTP BPDUs 
>>selfconfigures in Acces port mode, then that Abridge will work as edge 
>>bridge. A non edge (or transit) Abridge is an Abridge with no ports 
>>selfconfigured as Access ports, all ports selfconfigured as Core ports.
>>
>>    
>>
>I agree with your explanation.
>
>  
>
>>>Otherwise in other part of the draft it said ?The parameters to  configure are those common to RSTP, such as selection of the Root Bridge and configuration of the Backup Bridges for the region and their priorities.?. 
>>>
>>>(2) In the section 4.8,it describes the following:?-The bridge ID of the destination is translated to the  port MAC destination address of the destination Abridge at the internal Abridge table. - The frame is encapsulated with an external L2 header with  Destination Bridge ID.?I don?t know when port MAC destination address of the destination Abridge can be used in routing function? Does one destination Abridge have one or many port MAC destination address? 
>>>
>>>      
>>>
>>It might be done in both ways: many MACs of ports or a single bridge ID. 
>>The former requires learning of every corresponding MAC or port at 
>>corresponding tree branch. The later looks simpler, although a bit more 
>>different to current routing  in standard bridges, but the result and 
>>compatibility is the same.
>>    
>>
>
>Do you mean if using many MACs of ports Source address learning  have to be proceeded about source address of external hearder? But in section 6.2 it says " no address learning is used".Otherwise as you pointed address learning is not feasible in asymmetric spanning trees environment.
>
>  
>
>>>(3) In the section 4.8,it describes the following: ?Abridges only forward a frame received at a designated port, upstream, via the root port. The L2 external destination address can be the Destination Bridge ID itself?. I think when one switch receive in-coming data packets, it will forward data packets base ? destination address? and FID entries (also called FDB entries),so why doesn?t AMSP create FID entries in terms of root port ID and egress bridge MAC address previously? 
>>>
>>>      
>>>
>>Yes. I forgot to mention it explicitly.
>>    
>>
>
>Ok, you can explain it in the Abridge draft clearly.
>Otherwise, on the one hand one part of the draft says no address learning is need ,on the other hand other part of the draft says address learning has to be proceeded.
>Although I know you are right based your real meaning, but hope you can describe this exactly.e.g. in section 6.2 you can say " no address learning is needed in the core ports of core layer.
>
>  
>
>>>Hope you help me to clarify the above questions. Thank you much! Robey 
>>>
>>>----- Original Message ----- 
>>>From: "Guillermo Ibáñez" <[e-mail]>
>>>To: <[e-mail]>
>>>Cc: <[e-mail]>
>>>Sent: Tuesday, February 28, 2006 11:32 PM
>>>Subject: [rbridge] Additioanla clarification Abridges port types Re: A question about (R)STP and routing protocol / requestfor comments to Abridges draft
>>>
>>>
>>> 
>>>
>>>      
>>>
>>>>Hi Suping,
>>>> Just a clarification. Abridges have core ports (those connected to 
>>>>other Abridges) and distribution ports (those connected to standard 
>>>>bridges). Core ports run AMSTP protocol and distribution ports run RSTP 
>>>>or STP protocol. The ports selfconfigure as core or distribution ports 
>>>>according to the standard protocol migration procedure 802.1D (i.e. 
>>>>depending on the protocol type of STP BPDUs they hear from neighbour).
>>>>Distribution ports are standard ports regarding learning. Specific 
>>>>operation corresponds to core ports.
>>>>Regards
>>>>Guillermo
>>>>
>>>>Suping Zhai wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>Hi Guillermo,
>>>>>Thank you for your response. After I have gone through the following draft, there are some doubts wrt the following aspects,
>>>>>1) what's the orientation wrt the basic RSTP instance in the core Abrige network?  What I understand is per-Abridge RSTP is enough for the forwarding and there is no need for the aforementioned basic RSTP instance.
>>>>>
>>>>>2) In 4.3.2 it says that Abridge may learn from the received frames both outer MAC and inter MAC address, called the double MAC adress learning. On the other hand, when talk about the symmetric spanning tree problem in section 4.8 and 6.2, it says that Abridges don't learn addresses. So which is the right one or I missed some points?
>>>>>
>>>>>Regards
>>>>>Suping  
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>Let me give my opinions interleaved.
>>>>>>By the way, as the Abridges draft we submitted last december is 
>>>>>>somewhere between the current RBridges proposal and the IEEE Shortest 
>>>>>>Path Bridging, we think it would help clarify to obtain comments to our 
>>>>>>draft from the RBridges WG members.
>>>>>>Regards
>>>>>>Guillermo Ibanez
>>>>>>
>>>>>>
>>>>>>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt
>>>>>>
>>>>>>Guillermo Ibanez
>>>>>>
>>>>>>
>>>>>>Radia Perlman wrote:
>>>>>>
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>Suping Zhai,
>>>>>>>
>>>>>>>You are not the first person to ask these questions.
>>>>>>>There is a lot of confusion over what is different between RSTP and STP,
>>>>>>>and what is different between RSTP and link state routing.
>>>>>>>I'll try to explain.
>>>>>>>
>>>>>>>1) What's the difference between RSTP and STP?
>>>>>>>
>>>>>>>RSTP and STP are almost identical, are compatible,
>>>>>>>and it would be less confusing to think of RSTP as a different
>>>>>>>version of the bridge spec than a different protocol.
>>>>>>>
>>>>>>>RSTP calculates the
>>>>>>>same spanning tree, and uses the same algorithm and even
>>>>>>>packet formats as STP. Both RSTP and STP calculate a tree of shortest paths
>>>>>>>    
>>>>>>>
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>from the Root bridge, which is the bridge with lowest ID/priority.
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>The major difference between RSTP and STP
>>>>>>>is how they avoid temporary loops.
>>>>>>>STP did it with a timer. RSTP coordinates between neighbors
>>>>>>>to turn on links more quickly after topology changes.
>>>>>>>
>>>>>>>However, in either case, it is impossible to always avoid temporary
>>>>>>>loops...the simplest case is when a repeater comes up, or if too many
>>>>>>>spanning tree messages get lost due to congestion.
>>>>>>>
>>>>>>>So to summarize, both STP and RSTP use the same basic
>>>>>>>algorithm...the heart of algorithm is to calculate a tree
>>>>>>>of shortest paths from a single point.
>>>>>>>And the resulting tree and data packet
>>>>>>>forwarding path is the same in both (because it is the
>>>>>>>same algorithm). A single shared loop-free subset
>>>>>>>of the physical topology is calculated, upon which data packets are
>>>>>>>forwarded.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>2) What is the difference between RSTP and IS-IS?
>>>>>>>
>>>>>>>This is harder to answer than the difference between RSTP and STP,
>>>>>>>because IS-IS and spanning tree (RSTP/STP) are so very different from
>>>>>>>each other. IS-IS passes around topology
>>>>>>>information so that every RBridge calculates the shortest path between
>>>>>>>itself
>>>>>>>and each
>>>>>>>destination. With spanning tree (RSTP/STP) each bridge just knows which
>>>>>>>subset of its
>>>>>>>own ports are "in" or "out" of the spanning tree. If a link is not in
>>>>>>>the spanning tree,
>>>>>>>then it cannot be used, even if it is the shortest path between point A
>>>>>>>and B, and
>>>>>>>pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated
>>>>>>>on the links in the spanning tree, because no traffic can be on links
>>>>>>>not in the
>>>>>>>spanning tree.
>>>>>>>
>>>>>>>Also spanning tree bridges learn, based on
>>>>>>>seeing data traffic, which
>>>>>>>direction the source is. (which of its own local ports lead to the
>>>>>>>source of
>>>>>>>the data packet). So packets must always arrive from a particular source
>>>>>>>from
>>>>>>>the same direction or else bridges will get confused. In contrast, with
>>>>>>>IS-IS,
>>>>>>>switches can do path splitting; using multiple paths to reach a destination.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    
>>>>>>>
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>It is important to remember that the standard convergence times of RSTP 
>>>>>>are lower than those of routing protocols, unless specific measures for 
>>>>>>milliseconds convergence are applied.
>>>>>>
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>3) What is difference between RSTP and RBridge approach?
>>>>>>>
>>>>>>>RBridge incorporates
>>>>>>>a TTL into the header of forwarded data packets so a temporary loop is
>>>>>>>not really bad, so it need not
>>>>>>>be very conservative about avoiding loops. Also,
>>>>>>>a link state protocol (IS-IS) calculates shortest
>>>>>>>pair-wise paths. Also, it can calculate multiple paths to the
>>>>>>>destination, and do path splitting.
>>>>>>>
>>>>>>>
>>>>>>>    
>>>>>>>
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>Both IEEE Shortest Path Bridging and the Abridges draft proposal ( see
>>>>>>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt)
>>>>>>obtain shortest paths. They do not allow  path splitting, but are less 
>>>>>>complex than IS-IS
>>>>>>and do not mix STP and IS-IS protocols in same area.
>>>>>>
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>4) What is the difference between recent work in IEEE to calculate
>>>>>>>per-ingress trees, and RBridge approach?
>>>>>>>
>>>>>>>IEEE may indeed wind up doing the same thing as RBridge. Several years
>>>>>>>before TRILL I tried to get IEEE interested in doing this approach,
>>>>>>>but they were not interested, perhaps because I didn't explain it
>>>>>>>well enough. Now that work has started in IETF, I think it is possible
>>>>>>>that IEEE will converge on the same solution, which would actually
>>>>>>>be good for the industry.
>>>>>>>Radia
>>>>>>>
>>>>>>>
>>>>>>>    
>>>>>>>
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>I do not see an easy convergence between IEEE and RBridge proposals 
>>>>>>unless the two groups cooperate strongly.
>>>>>>IEEE will likely preserve basic RSTP mechanisms (fast convergence and 
>>>>>>distance vector to (multiple) root bridges) with multiple spanning trees 
>>>>>>(this is my guess, I do not follow their recent activities), while 
>>>>>>RBridge uses IS-IS (link state mechanisms) as basic protocol.
>>>>>>
>>>>>>
>>>>>>Guillermo Ibanez
>>>>>>
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>Suping Zhai wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    
>>>>>>>
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>hi,
>>>>>>>>I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details.
>>>>>>>>What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? 
>>>>>>>>How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? 
>>>>>>>>Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path?
>>>>>>>>
>>>>>>>>TIA.
>>>>>>>>
>>>>>>>>Best Regards,
>>>>>>>>[e-mail]
>>>>>>>>Huawei Technologies Co., Ltd.
>>>>>>>>Tel: [phone]
>>>>>>>>Fax: [phone]
>>>>>>>>2006-02-23
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>_______________________________________________
>>>>>>>>rbridge mailing list
>>>>>>>>[e-mail]
>>>>>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>>>>>>
>>>>>>>>
>>>>>>>> 
>>>>>>>>
>>>>>>>>      
>>>>>>>>
>>>>>>>>           
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>------------------------------------------------------------------------
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>rbridge mailing list
>>>>>>>[e-mail]
>>>>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>>>>>
>>>>>>>
>>>>>>>    
>>>>>>>
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>-- 
>>>>>>Guillermo Ibá?ez
>>>>>>Departamento de Ingeniería Telemática
>>>>>>Universidad Carlos III de Madrid
>>>>>>1.1.B.11 Colmenarejo 91-6241393
>>>>>>4.1.F.13 Leganés 91-6248794
>>>>>>
>>>>>>_______________________________________________
>>>>>>rbridge mailing list
>>>>>>[e-mail]
>>>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>--------------------------------------------------------------------------------
>>>
>>>
>>> 
>>>
>>>      
>>>
>>>>_______________________________________________
>>>>rbridge mailing list
>>>>[e-mail]
>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>_______________________________________________
>>>rbridge mailing list
>>>[e-mail]
>>>http://www.postel.org/mailman/listinfo/rbridge
>>> 
>>>
>>>      
>>>
>>-- 
>>Prof. Dr. Guillermo Ibáñez
>>Departamento de Ingeniería Telemática
>>Universidad Carlos III de Madrid
>>http://www.it.uc3m.es/netcom/
>>609177932
>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>>
>>    
>>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

-- 
Prof. Dr. Guillermo Ibáñez
Departamento de Ingeniería Telemática
Universidad Carlos III de Madrid
http://www.it.uc3m.es/netcom/
609177932



Received: from huawei.com (usaga01-in.huawei.com [12.129.211.51]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k271uOu13532 for <[e-mail]>; Mon, 6 Mar 2006 17:56:24 -0800 (PST)
Received: from huawei.com ([172.24.2.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 06 Mar 2006 17:53:09 -0800 (PST)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 07 Mar 2006 10:09:14 +0800 (CST)
Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 07 Mar 2006 10:09:14 +0800 (CST)
Received: from y41566 ([10.70.77.89]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <[e-mail]> for [e-mail]; Tue, 07 Mar 2006 10:12:41 +0800 (CST)
Date: Tue, 07 Mar 2006 09:56:17 +0800
From: robey <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <001c01c6418a$52a05790$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
Content-type: text/plain; charset=utf-8
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]> <002c01c640cd$e0ea1b70$[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by boreas.isi.edu id k271uOu13532
Subject: Re: [rbridge] Additioanla clarification Abridges port types Re: A question about (R)STP and routing protocol / requestfor comments to Abridges draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2006 01:56:47 -0000
Status: RO
Content-Length: 14186

Hi,Guillermo,
See my interleaving opions.
Thank you much!
Robey

----- Original Message ----- 
From: "Guillermo Ibáñez" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Sent: Monday, March 06, 2006 5:56 PM
Subject: Re: [rbridge] Additioanla clarification Abridges port types Re: A question about (R)STP and routing protocol / requestfor comments to Abridges draft


> 
> 
> robey wrote:
> 
>>Hi, Guillermo,
>>
>> 
>>
>>I have the following questions to ask for you about the Abridge draft:
>>
>> 
>>
>>(1) In one part of the daft it said ?Abridges overcome Rbridges L2 network size restrictions allowing applicability to very large Ethernet campus networks while maintaining zero configuration and high performance?,But I know when Abridges are applied in core network, you have to do some configuration, e.g. determine which abridge is edge bridge (do you want to each abridge is edge bridge, so don?t need to configure?),so how  can we maintain zero configuration? .
>>
> By default all Abridges are edge bridges, transit Abridges are a subset 
> functionally of edge Abridges. As in current spanning tree protocols, 
> mechanisms operate at port level. A port detecting STP or RSTP BPDUs 
> selfconfigures in Acces port mode, then that Abridge will work as edge 
> bridge. A non edge (or transit) Abridge is an Abridge with no ports 
> selfconfigured as Access ports, all ports selfconfigured as Core ports.
> 
I agree with your explanation.

>>Otherwise in other part of the draft it said ?The parameters to  configure are those common to RSTP, such as selection of the Root Bridge and configuration of the Backup Bridges for the region and their priorities.?. 
>>
>>(2) In the section 4.8,it describes the following:?-The bridge ID of the destination is translated to the  port MAC destination address of the destination Abridge at the internal Abridge table. - The frame is encapsulated with an external L2 header with  Destination Bridge ID.?I don?t know when port MAC destination address of the destination Abridge can be used in routing function? Does one destination Abridge have one or many port MAC destination address? 
>>
> It might be done in both ways: many MACs of ports or a single bridge ID. 
> The former requires learning of every corresponding MAC or port at 
> corresponding tree branch. The later looks simpler, although a bit more 
> different to current routing  in standard bridges, but the result and 
> compatibility is the same.

Do you mean if using many MACs of ports Source address learning  have to be proceeded about source address of external hearder? But in section 6.2 it says " no address learning is used".Otherwise as you pointed address learning is not feasible in asymmetric spanning trees environment.

> 
>>(3) In the section 4.8,it describes the following: ?Abridges only forward a frame received at a designated port, upstream, via the root port. The L2 external destination address can be the Destination Bridge ID itself?. I think when one switch receive in-coming data packets, it will forward data packets base ? destination address? and FID entries (also called FDB entries),so why doesn?t AMSP create FID entries in terms of root port ID and egress bridge MAC address previously? 
>>
> Yes. I forgot to mention it explicitly.

Ok, you can explain it in the Abridge draft clearly.
Otherwise, on the one hand one part of the draft says no address learning is need ,on the other hand other part of the draft says address learning has to be proceeded.
Although I know you are right based your real meaning, but hope you can describe this exactly.e.g. in section 6.2 you can say " no address learning is needed in the core ports of core layer.

>>Hope you help me to clarify the above questions. Thank you much! Robey 
>>
>>----- Original Message ----- 
>>From: "Guillermo Ibáñez" <[e-mail]>
>>To: <[e-mail]>
>>Cc: <[e-mail]>
>>Sent: Tuesday, February 28, 2006 11:32 PM
>>Subject: [rbridge] Additioanla clarification Abridges port types Re: A question about (R)STP and routing protocol / requestfor comments to Abridges draft
>>
>>
>>  
>>
>>>Hi Suping,
>>>  Just a clarification. Abridges have core ports (those connected to 
>>>other Abridges) and distribution ports (those connected to standard 
>>>bridges). Core ports run AMSTP protocol and distribution ports run RSTP 
>>>or STP protocol. The ports selfconfigure as core or distribution ports 
>>>according to the standard protocol migration procedure 802.1D (i.e. 
>>>depending on the protocol type of STP BPDUs they hear from neighbour).
>>>Distribution ports are standard ports regarding learning. Specific 
>>>operation corresponds to core ports.
>>>Regards
>>>Guillermo
>>>
>>>Suping Zhai wrote:
>>>
>>>    
>>>
>>>>Hi Guillermo,
>>>>Thank you for your response. After I have gone through the following draft, there are some doubts wrt the following aspects,
>>>>1) what's the orientation wrt the basic RSTP instance in the core Abrige network?  What I understand is per-Abridge RSTP is enough for the forwarding and there is no need for the aforementioned basic RSTP instance.
>>>>
>>>>2) In 4.3.2 it says that Abridge may learn from the received frames both outer MAC and inter MAC address, called the double MAC adress learning. On the other hand, when talk about the symmetric spanning tree problem in section 4.8 and 6.2, it says that Abridges don't learn addresses. So which is the right one or I missed some points?
>>>>
>>>>Regards
>>>>Suping  
>>>> 
>>>>
>>>>      
>>>>
>>>>>Let me give my opinions interleaved.
>>>>>By the way, as the Abridges draft we submitted last december is 
>>>>>somewhere between the current RBridges proposal and the IEEE Shortest 
>>>>>Path Bridging, we think it would help clarify to obtain comments to our 
>>>>>draft from the RBridges WG members.
>>>>>Regards
>>>>>Guillermo Ibanez
>>>>>
>>>>>
>>>>>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt
>>>>>
>>>>>Guillermo Ibanez
>>>>>
>>>>>
>>>>>Radia Perlman wrote:
>>>>>
>>>>>   
>>>>>
>>>>>        
>>>>>
>>>>>>Suping Zhai,
>>>>>>
>>>>>>You are not the first person to ask these questions.
>>>>>>There is a lot of confusion over what is different between RSTP and STP,
>>>>>>and what is different between RSTP and link state routing.
>>>>>>I'll try to explain.
>>>>>>
>>>>>>1) What's the difference between RSTP and STP?
>>>>>>
>>>>>>RSTP and STP are almost identical, are compatible,
>>>>>>and it would be less confusing to think of RSTP as a different
>>>>>>version of the bridge spec than a different protocol.
>>>>>>
>>>>>>RSTP calculates the
>>>>>>same spanning tree, and uses the same algorithm and even
>>>>>>packet formats as STP. Both RSTP and STP calculate a tree of shortest paths
>>>>>>     
>>>>>>
>>>>>>          
>>>>>>
>>>>>>from the Root bridge, which is the bridge with lowest ID/priority.
>>>>>   
>>>>>
>>>>>        
>>>>>
>>>>>>The major difference between RSTP and STP
>>>>>>is how they avoid temporary loops.
>>>>>>STP did it with a timer. RSTP coordinates between neighbors
>>>>>>to turn on links more quickly after topology changes.
>>>>>>
>>>>>>However, in either case, it is impossible to always avoid temporary
>>>>>>loops...the simplest case is when a repeater comes up, or if too many
>>>>>>spanning tree messages get lost due to congestion.
>>>>>>
>>>>>>So to summarize, both STP and RSTP use the same basic
>>>>>>algorithm...the heart of algorithm is to calculate a tree
>>>>>>of shortest paths from a single point.
>>>>>>And the resulting tree and data packet
>>>>>>forwarding path is the same in both (because it is the
>>>>>>same algorithm). A single shared loop-free subset
>>>>>>of the physical topology is calculated, upon which data packets are
>>>>>>forwarded.
>>>>>>
>>>>>>
>>>>>>
>>>>>>2) What is the difference between RSTP and IS-IS?
>>>>>>
>>>>>>This is harder to answer than the difference between RSTP and STP,
>>>>>>because IS-IS and spanning tree (RSTP/STP) are so very different from
>>>>>>each other. IS-IS passes around topology
>>>>>>information so that every RBridge calculates the shortest path between
>>>>>>itself
>>>>>>and each
>>>>>>destination. With spanning tree (RSTP/STP) each bridge just knows which
>>>>>>subset of its
>>>>>>own ports are "in" or "out" of the spanning tree. If a link is not in
>>>>>>the spanning tree,
>>>>>>then it cannot be used, even if it is the shortest path between point A
>>>>>>and B, and
>>>>>>pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated
>>>>>>on the links in the spanning tree, because no traffic can be on links
>>>>>>not in the
>>>>>>spanning tree.
>>>>>>
>>>>>>Also spanning tree bridges learn, based on
>>>>>>seeing data traffic, which
>>>>>>direction the source is. (which of its own local ports lead to the
>>>>>>source of
>>>>>>the data packet). So packets must always arrive from a particular source
>>>>>>from
>>>>>>the same direction or else bridges will get confused. In contrast, with
>>>>>>IS-IS,
>>>>>>switches can do path splitting; using multiple paths to reach a destination.
>>>>>>
>>>>>>
>>>>>>
>>>>>>     
>>>>>>
>>>>>>          
>>>>>>
>>>>>It is important to remember that the standard convergence times of RSTP 
>>>>>are lower than those of routing protocols, unless specific measures for 
>>>>>milliseconds convergence are applied.
>>>>>
>>>>>   
>>>>>
>>>>>        
>>>>>
>>>>>>3) What is difference between RSTP and RBridge approach?
>>>>>>
>>>>>>RBridge incorporates
>>>>>>a TTL into the header of forwarded data packets so a temporary loop is
>>>>>>not really bad, so it need not
>>>>>>be very conservative about avoiding loops. Also,
>>>>>>a link state protocol (IS-IS) calculates shortest
>>>>>>pair-wise paths. Also, it can calculate multiple paths to the
>>>>>>destination, and do path splitting.
>>>>>>
>>>>>>
>>>>>>     
>>>>>>
>>>>>>          
>>>>>>
>>>>>Both IEEE Shortest Path Bridging and the Abridges draft proposal ( see
>>>>>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt)
>>>>>obtain shortest paths. They do not allow  path splitting, but are less 
>>>>>complex than IS-IS
>>>>>and do not mix STP and IS-IS protocols in same area.
>>>>>
>>>>>   
>>>>>
>>>>>        
>>>>>
>>>>>>4) What is the difference between recent work in IEEE to calculate
>>>>>>per-ingress trees, and RBridge approach?
>>>>>>
>>>>>>IEEE may indeed wind up doing the same thing as RBridge. Several years
>>>>>>before TRILL I tried to get IEEE interested in doing this approach,
>>>>>>but they were not interested, perhaps because I didn't explain it
>>>>>>well enough. Now that work has started in IETF, I think it is possible
>>>>>>that IEEE will converge on the same solution, which would actually
>>>>>>be good for the industry.
>>>>>>Radia
>>>>>>
>>>>>>
>>>>>>     
>>>>>>
>>>>>>          
>>>>>>
>>>>>I do not see an easy convergence between IEEE and RBridge proposals 
>>>>>unless the two groups cooperate strongly.
>>>>>IEEE will likely preserve basic RSTP mechanisms (fast convergence and 
>>>>>distance vector to (multiple) root bridges) with multiple spanning trees 
>>>>>(this is my guess, I do not follow their recent activities), while 
>>>>>RBridge uses IS-IS (link state mechanisms) as basic protocol.
>>>>>
>>>>>
>>>>>Guillermo Ibanez
>>>>>
>>>>>   
>>>>>
>>>>>        
>>>>>
>>>>>>Suping Zhai wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>     
>>>>>>
>>>>>>          
>>>>>>
>>>>>>>hi,
>>>>>>>I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details.
>>>>>>>What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? 
>>>>>>>How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? 
>>>>>>>Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path?
>>>>>>>
>>>>>>>TIA.
>>>>>>>
>>>>>>>Best Regards,
>>>>>>>[e-mail]
>>>>>>>Huawei Technologies Co., Ltd.
>>>>>>>Tel: [phone]
>>>>>>>Fax: [phone]
>>>>>>>2006-02-23
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>------------------------------------------------------------------------
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>rbridge mailing list
>>>>>>>[e-mail]
>>>>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>>>>>
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>>       
>>>>>>>
>>>>>>>            
>>>>>>>
>>>>>>------------------------------------------------------------------------
>>>>>>
>>>>>>_______________________________________________
>>>>>>rbridge mailing list
>>>>>>[e-mail]
>>>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>>>>
>>>>>>
>>>>>>     
>>>>>>
>>>>>>          
>>>>>>
>>>>>-- 
>>>>>Guillermo Ibá?ez
>>>>>Departamento de Ingeniería Telemática
>>>>>Universidad Carlos III de Madrid
>>>>>1.1.B.11 Colmenarejo 91-6241393
>>>>>4.1.F.13 Leganés 91-6248794
>>>>>
>>>>>_______________________________________________
>>>>>rbridge mailing list
>>>>>[e-mail]
>>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>>>   
>>>>>
>>>>>        
>>>>>
>>>> 
>>>>
>>>>      
>>>>
>>
>>
>>--------------------------------------------------------------------------------
>>
>>
>>  
>>
>>>_______________________________________________
>>>rbridge mailing list
>>>[e-mail]
>>>http://www.postel.org/mailman/listinfo/rbridge
>>>
>>>    
>>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>>  
>>
> 
> -- 
> Prof. Dr. Guillermo Ibáñez
> Departamento de Ingeniería Telemática
> Universidad Carlos III de Madrid
> http://www.it.uc3m.es/netcom/
> 609177932
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
>


Received: from huawei.com (lhrga01-in.huawei.com [57.66.76.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k26AOEu14451 for <[e-mail]>; Mon, 6 Mar 2006 02:24:14 -0800 (PST)
Received: from huawei.com ([172.24.2.3]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 06 Mar 2006 09:54:21 +0000 (GMT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 06 Mar 2006 18:19:59 +0800 (CST)
Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 06 Mar 2006 18:19:59 +0800 (CST)
Received: from y41566 ([10.70.77.89]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 06 Mar 2006 18:25:47 +0800 (CST)
Date: Mon, 06 Mar 2006 18:09:25 +0800
From: robey <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <002201c64106$0bd2ee60$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
Content-type: text/plain; charset=UTF-8
X-Priority: 3
X-MSMail-priority: Normal
References: <004b01c640ce$cfc54350$[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by boreas.isi.edu id k26AOEu14451
Subject: [rbridge] Some questions about  Abridges draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Mar 2006 10:24:52 -0000
Status: RO
Content-Length: 1863

Hi, Guillermo,
Sorry for mess of characters in my last letter.I write it again.

I have the following questions to ask for you about the Abridge draft:
(1)  In one part of the daft ,it said "Abridges overcome Rbridges L2 network size restrictions allowing applicability to very large Ethernet campus networks while maintaining zero configuration and high performance?,But I know when Abridges are applied in core network, you have to do some configuration, e.g. determine which abridge is edge bridge (do you want to each abridge is edge bridge, so don?t need to configure?),so how  can we maintain zero configuration? Otherwise in other part of the draft it said "The parameters to  configure are those common to RSTP, such as selection of the Root Bridge and configuration of the Backup Bridges for the region and their priorities".

(2) In the section 4.8, it describes the following:
"The bridge ID of the destination is translated to the  port MAC destination address of the destination Abridge at the internal Abridge table. - The frame is encapsulated with an external L2 header with  Destination Bridge ID.", I don't know when port MAC destination address of the destination Abridge can be used in routing function? Does one destination Abridge have one or many port MAC destination address? 

(3) In the section 4.8,it describes the following: 
"Abridges only forward a frame received at a designated port, upstream, via the root port. The L2 external destination address can be the Destination Bridge ID itself". 
I think when one switch receive in-coming data packets, it will forward data packets base "destination address" and FID entries (also called FDB entries),so why doesn't AMSP create FID entries in terms of root port ID and egress bridge MAC address previously?

Hope you help me to clarify the above questions. 
Thank you much! 

Robey


Received: from huawei.com (usaga01-in.huawei.com [12.129.211.51]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k263RYu14338 for <[e-mail]>; Sun, 5 Mar 2006 19:27:34 -0800 (PST)
Received: from huawei.com ([172.24.2.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sun, 05 Mar 2006 19:24:13 -0800 (PST)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 06 Mar 2006 11:40:16 +0800 (CST)
Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 06 Mar 2006 11:40:16 +0800 (CST)
Received: from y41566 ([10.70.77.89]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 06 Mar 2006 11:43:42 +0800 (CST)
Date: Mon, 06 Mar 2006 11:27:21 +0800
From: robey <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <002c01c640cd$e0ea1b70$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
Content-type: text/plain; charset=UTF-8
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by boreas.isi.edu id k263RYu14338
Subject: Re: [rbridge] Additioanla clarification Abridges port types Re: A question about (R)STP and routing protocol / requestfor comments to Abridges draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Mar 2006 03:28:39 -0000
Status: RO
Content-Length: 10908

Hi, Guillermo,

 

I have the following questions to ask for you about the Abridge draft:

 

(1) In one part of the daft it said ?Abridges overcome Rbridges L2 network size restrictions allowing applicability to very large Ethernet campus networks while maintaining zero configuration and high performance?,But I know when Abridges are applied in core network, you have to do some configuration, e.g. determine which abridge is edge bridge (do you want to each abridge is edge bridge, so don?t need to configure?),so how  can we maintain zero configuration? .Otherwise in other part of the draft it said ?The parameters to  configure are those common to RSTP, such as selection of the Root Bridge and configuration of the Backup Bridges for the region and their priorities.?. (2) In the section 4.8,it describes the following:?-The bridge ID of the destination is translated to the  port MAC destination address of the destination Abridge at the internal Abridge table. - The frame is encapsulated with an external L2 header with  Destination Bridge ID.?I don?t know when port MAC destination address of the destination Abridge can be used in routing function? Does one destination Abridge have one or many port MAC destination address? (3) In the section 4.8,it describes the following: ?Abridges only forward a frame received at a designated port, upstream, via the root port. The L2 external destination address can be the Destination Bridge ID itself?. I think when one switch receive in-coming data packets, it will forward data packets base ? destination address? and FID entries (also called FDB entries),so why doesn?t AMSP create FID entries in terms of root port ID and egress bridge MAC address previously? Hope you help me to clarify the above questions. Thank you much! Robey 

----- Original Message ----- 
From: "Guillermo Ibáñez" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, February 28, 2006 11:32 PM
Subject: [rbridge] Additioanla clarification Abridges port types Re: A question about (R)STP and routing protocol / requestfor comments to Abridges draft


> Hi Suping,
>   Just a clarification. Abridges have core ports (those connected to 
> other Abridges) and distribution ports (those connected to standard 
> bridges). Core ports run AMSTP protocol and distribution ports run RSTP 
> or STP protocol. The ports selfconfigure as core or distribution ports 
> according to the standard protocol migration procedure 802.1D (i.e. 
> depending on the protocol type of STP BPDUs they hear from neighbour).
> Distribution ports are standard ports regarding learning. Specific 
> operation corresponds to core ports.
> Regards
> Guillermo
> 
> Suping Zhai wrote:
> 
>>Hi Guillermo,
>>Thank you for your response. After I have gone through the following draft, there are some doubts wrt the following aspects,
>>1) what's the orientation wrt the basic RSTP instance in the core Abrige network?  What I understand is per-Abridge RSTP is enough for the forwarding and there is no need for the aforementioned basic RSTP instance.
>>
>>2) In 4.3.2 it says that Abridge may learn from the received frames both outer MAC and inter MAC address, called the double MAC adress learning. On the other hand, when talk about the symmetric spanning tree problem in section 4.8 and 6.2, it says that Abridges don't learn addresses. So which is the right one or I missed some points?
>>
>>Regards
>>Suping  
>>  
>>
>>>Let me give my opinions interleaved.
>>>By the way, as the Abridges draft we submitted last december is 
>>>somewhere between the current RBridges proposal and the IEEE Shortest 
>>>Path Bridging, we think it would help clarify to obtain comments to our 
>>>draft from the RBridges WG members.
>>>Regards
>>>Guillermo Ibanez
>>>
>>>
>>>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt
>>>
>>>Guillermo Ibanez
>>>
>>>
>>>Radia Perlman wrote:
>>>
>>>    
>>>
>>>>Suping Zhai,
>>>>
>>>>You are not the first person to ask these questions.
>>>>There is a lot of confusion over what is different between RSTP and STP,
>>>>and what is different between RSTP and link state routing.
>>>>I'll try to explain.
>>>>
>>>>1) What's the difference between RSTP and STP?
>>>>
>>>>RSTP and STP are almost identical, are compatible,
>>>>and it would be less confusing to think of RSTP as a different
>>>>version of the bridge spec than a different protocol.
>>>>
>>>>RSTP calculates the
>>>>same spanning tree, and uses the same algorithm and even
>>>>packet formats as STP. Both RSTP and STP calculate a tree of shortest paths
>>>>      
>>>>
>>>>from the Root bridge, which is the bridge with lowest ID/priority.
>>>    
>>>
>>>>The major difference between RSTP and STP
>>>>is how they avoid temporary loops.
>>>>STP did it with a timer. RSTP coordinates between neighbors
>>>>to turn on links more quickly after topology changes.
>>>>
>>>>However, in either case, it is impossible to always avoid temporary
>>>>loops...the simplest case is when a repeater comes up, or if too many
>>>>spanning tree messages get lost due to congestion.
>>>>
>>>>So to summarize, both STP and RSTP use the same basic
>>>>algorithm...the heart of algorithm is to calculate a tree
>>>>of shortest paths from a single point.
>>>>And the resulting tree and data packet
>>>>forwarding path is the same in both (because it is the
>>>>same algorithm). A single shared loop-free subset
>>>>of the physical topology is calculated, upon which data packets are
>>>>forwarded.
>>>>
>>>> 
>>>>
>>>>2) What is the difference between RSTP and IS-IS?
>>>>
>>>>This is harder to answer than the difference between RSTP and STP,
>>>>because IS-IS and spanning tree (RSTP/STP) are so very different from
>>>>each other. IS-IS passes around topology
>>>>information so that every RBridge calculates the shortest path between
>>>>itself
>>>>and each
>>>>destination. With spanning tree (RSTP/STP) each bridge just knows which
>>>>subset of its
>>>>own ports are "in" or "out" of the spanning tree. If a link is not in
>>>>the spanning tree,
>>>>then it cannot be used, even if it is the shortest path between point A
>>>>and B, and
>>>>pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated
>>>>on the links in the spanning tree, because no traffic can be on links
>>>>not in the
>>>>spanning tree.
>>>>
>>>>Also spanning tree bridges learn, based on
>>>>seeing data traffic, which
>>>>direction the source is. (which of its own local ports lead to the
>>>>source of
>>>>the data packet). So packets must always arrive from a particular source
>>>>from
>>>>the same direction or else bridges will get confused. In contrast, with
>>>>IS-IS,
>>>>switches can do path splitting; using multiple paths to reach a destination.
>>>>
>>>> 
>>>>
>>>>      
>>>>
>>>It is important to remember that the standard convergence times of RSTP 
>>>are lower than those of routing protocols, unless specific measures for 
>>>milliseconds convergence are applied.
>>>
>>>    
>>>
>>>>3) What is difference between RSTP and RBridge approach?
>>>>
>>>>RBridge incorporates
>>>>a TTL into the header of forwarded data packets so a temporary loop is
>>>>not really bad, so it need not
>>>>be very conservative about avoiding loops. Also,
>>>>a link state protocol (IS-IS) calculates shortest
>>>>pair-wise paths. Also, it can calculate multiple paths to the
>>>>destination, and do path splitting.
>>>> 
>>>>
>>>>      
>>>>
>>>Both IEEE Shortest Path Bridging and the Abridges draft proposal ( see
>>>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt)
>>>obtain shortest paths. They do not allow  path splitting, but are less 
>>>complex than IS-IS
>>>and do not mix STP and IS-IS protocols in same area.
>>>
>>>    
>>>
>>>>4) What is the difference between recent work in IEEE to calculate
>>>>per-ingress trees, and RBridge approach?
>>>>
>>>>IEEE may indeed wind up doing the same thing as RBridge. Several years
>>>>before TRILL I tried to get IEEE interested in doing this approach,
>>>>but they were not interested, perhaps because I didn't explain it
>>>>well enough. Now that work has started in IETF, I think it is possible
>>>>that IEEE will converge on the same solution, which would actually
>>>>be good for the industry.
>>>>Radia
>>>> 
>>>>
>>>>      
>>>>
>>>I do not see an easy convergence between IEEE and RBridge proposals 
>>>unless the two groups cooperate strongly.
>>>IEEE will likely preserve basic RSTP mechanisms (fast convergence and 
>>>distance vector to (multiple) root bridges) with multiple spanning trees 
>>>(this is my guess, I do not follow their recent activities), while 
>>>RBridge uses IS-IS (link state mechanisms) as basic protocol.
>>>
>>>
>>>Guillermo Ibanez
>>>
>>>    
>>>
>>>>Suping Zhai wrote:
>>>>
>>>> 
>>>>
>>>>      
>>>>
>>>>>hi,
>>>>>I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details.
>>>>>What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? 
>>>>>How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? 
>>>>>Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path?
>>>>>
>>>>>TIA.
>>>>>
>>>>>Best Regards,
>>>>>[e-mail]
>>>>>Huawei Technologies Co., Ltd.
>>>>>Tel: [phone]
>>>>>Fax: [phone]
>>>>>2006-02-23
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>------------------------------------------------------------------------
>>>>>
>>>>>_______________________________________________
>>>>>rbridge mailing list
>>>>>[e-mail]
>>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>>>
>>>>>
>>>>>   
>>>>>
>>>>>        
>>>>>
>>>> 
>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>_______________________________________________
>>>>rbridge mailing list
>>>>[e-mail]
>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>> 
>>>>
>>>>      
>>>>
>>>-- 
>>>Guillermo Ibá?ez
>>>Departamento de Ingeniería Telemática
>>>Universidad Carlos III de Madrid
>>>1.1.B.11 Colmenarejo 91-6241393
>>>4.1.F.13 Leganés 91-6248794
>>>
>>>_______________________________________________
>>>rbridge mailing list
>>>[e-mail]
>>>http://www.postel.org/mailman/listinfo/rbridge
>>>    
>>>
>>
>>
>>
>>  
>>
>


--------------------------------------------------------------------------------


> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
>


Received: from nwkea-mail-5.sun.com (nwkea-mail-5.sun.com [192.18.42.27]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k230mxu09622 for <[e-mail]>; Thu, 2 Mar 2006 16:48:59 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k230mxxZ025090 for <[e-mail]>; Thu, 2 Mar 2006 16:48:59 -0800 (PST)
Received: from [129.146.229.202] (d-mpk17-229-202.SFBay.Sun.COM [129.146.229.202]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k230mwO3219193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 2 Mar 2006 16:48:58 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 02 Mar 2006 15:00:24 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5 (X11/20060113)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Tentative TRILL Agenda
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Mar 2006 00:50:03 -0000
Status: RO
Content-Length: 997

Tentative TRILL Agenda

  5 min  Administrativia (scribe etc)
  5 min  Agenda bashing

20 min  Problem and Applicability Statement, Joe Touch
         http://www.postel.org/rbridge/draft-touch-trill-rbridge-prob-00.txt
         Update? Adopt as a working group document?

30 min  The Architecture of an RBridge Solution to TRILL, Eric Grey
 
http://www.ietf.org/internet-drafts/draft-gray-trill-rbridge-arch-00.txt
	Changes from draft-touch-trill-rbridge-arch-00?
         Adopt as a working group document?

30 min  Rbridges: Base Protocol Specification, Radia Perlman, Joe Touch
 
http://www.ietf.org/internet-drafts/draft-perlman-trill-rbridge-protocol-00.txt
	Changes from draft-perlman-rbridge-03.txt
         Adopt as a working group document?

20 min  TRILL Routing Requirements in Support of Rbridges, Eric Grey
 
http://www.ietf.org/internet-drafts/draft-gray-trill-routing-reqs-00.txt
         Adopt as a working group document?

15 min  Charter milestones update

    Erik and Donald



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k22MJTu18917 for <[e-mail]>; Thu, 2 Mar 2006 14:19:29 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k22MJLgL003186 for <[e-mail]>; Thu, 2 Mar 2006 17:19:22 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA24533 for <[e-mail]>; Thu, 2 Mar 2006 17:19:20 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <FG7R9V3Z>; Thu, 2 Mar 2006 17:19:20 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge'" <[e-mail]>
Date: Thu, 2 Mar 2006 17:19:19 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Routing Requirements draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 02 Mar 2006 22:20:05 -0000
Status: RO
Content-Length: 665

The TRILL Routing Requirements draft is now available, at: 

http://www.ietf.org/internet-drafts/draft-gray-trill-routing-reqs-00.txt

One thing we need to do as soon as possible is determine if
there is consensus that we should ask the IS-IS working group
to take on the task of defining IS-IS extensions to support
TRILL/RBridge Routing Requirements.

Consequently it would be useful if a significant number of
people participating in the TRILL working group were to look
this over, determine if it is reasonably accurate in capturing
basic TRILL/RBridge Routing Requirements, and then determine
if IS-IS is an appropriate place to start this work.

--
Eric Gray