[rbridge] Consensus Withdrawn: Point to Point links

["Eastlake III Donald-LDE008" <[e-mail]>]

Based on the feedback on the mailing list, the tentative consensus below
from the Chicago meeting was not confirmed and is withdrawn.

Thanks,
Donald & Erik


From: [e-mail] 
[mailto:[e-mail]] On Behalf Of Eastlake III
Donald-LDE008
Sent: Tuesday, October 02, 2007 11:27 PM
To: [e-mail]
Subject: [rbridge] Consensus Check: Point to Point links
 
This is a check via the mailing list to confirm or refute an apparent
consensus from the minutes of the Chicago meeting for a change from
protocol draft -05:
 
   If it is known that a link is a point to point link between two
   RBridges, then the outer header, if it is an Ethernet header, can
   have any source and/or destination addresses, those addresses will
   be ignored on receipt, and the outer VLAN tag can be omitted.
 
If no particular controversy arises over this in the next two weeks, we
will declare it to be the working group consensus.
 
Thanks,
Donald & Erik

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




Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id lAU2WuCv022582 for <[e-mail]>; Thu, 29 Nov 2007 18:32:57 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-153.messagelabs.com!1196389974!10992826!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.189.100.101]
Received: (qmail 18705 invoked from network); 30 Nov 2007 02:32:55 -0000
Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-3.tower-153.messagelabs.com with SMTP; 30 Nov 2007 02:32:55 -0000
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lAU2WiOb026244 for <[e-mail]>; Thu, 29 Nov 2007 19:32:54 -0700 (MST)
Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lAU2Whjp001037 for <[e-mail]>; Thu, 29 Nov 2007 20:32:43 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAU2WgxW001027 for <[e-mail]>; Thu, 29 Nov 2007 20:32:42 -0600 (CST)
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: Thu, 29 Nov 2007 21:32:40 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Consensus Withdrawn: Point to Point links
thread-index: AcgFbTWE9oP+tClqRJuKgVk2MsooBgATWlnAAAtVxQAAAikIcAAN9u2ACzJi2IA=
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-CFilter-Loop: Reflected
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 lAU2WuCv022582
Subject: [rbridge] Consensus Withdrawn: Point to Point links
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Nov 2007 02:33:17 -0000
Status: RO
Content-Length: 973

Based on the feedback on the mailing list, the tentative consensus below
from the Chicago meeting was not confirmed and is withdrawn.

Thanks,
Donald & Erik


From: [e-mail] 
[mailto:[e-mail]] On Behalf Of Eastlake III
Donald-LDE008
Sent: Tuesday, October 02, 2007 11:27 PM
To: [e-mail]
Subject: [rbridge] Consensus Check: Point to Point links
 
This is a check via the mailing list to confirm or refute an apparent
consensus from the minutes of the Chicago meeting for a change from
protocol draft -05:
 
   If it is known that a link is a point to point link between two
   RBridges, then the outer header, if it is an Ethernet header, can
   have any source and/or destination addresses, those addresses will
   be ignored on receipt, and the outer VLAN tag can be omitted.
 
If no particular controversy arises over this in the next two weeks, we
will declare it to be the working group consensus.
 
Thanks,
Donald & Erik



Received: from people.com.cn ([202.99.23.227]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id lAODJ3B0022155 for <[e-mail]>; Sat, 24 Nov 2007 05:19:04 -0800 (PST)
Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1947483174; Sat, 24 Nov 2007 21:31:42 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm3e47434418; Wed, 21 Nov 2007 03:30:32 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 21 Nov 2007 03:30:32 +0800
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYZV-00082W-PH; Tue, 20 Nov 2007 14:15:45 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYZJ-0007fQ-NH for [e-mail]; Tue, 20 Nov 2007 14:15:33 -0500
Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuYZJ-0006WV-1T for [e-mail]; Tue, 20 Nov 2007 14:15:33 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id AC00D175AC; Tue, 20 Nov 2007 19:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuYYo-0002Wq-7T; Tue, 20 Nov 2007 14:15:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Tue, 20 Nov 2007 14:15:02 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Errors-To: [e-mail]
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-Auto-Forward: [e-mail] [e-mail]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-06.txt
X-BeenThere: [e-mail]
Reply-To: [e-mail]
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 24 Nov 2007 13:19:58 -0000
Status: RO
Content-Length: 3822

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title		: Rbridges: Base Protocol Specification
	Author(s)	: R. Perlman, et al.
	Filename	: draft-ietf-trill-rbridge-protocol-06.txt
	Pages		: 73
	Date		: 2007-11-20
	
RBridges allow for optimal pair-wise forwarding with zero
   configuration, safe forwarding even during periods of temporary
   loops, and multipathing for both unicast and multicast traffic. They
   achieve these goals using IS-IS routing and encapsulation of traffic
   with a header that includes a hop count.

   RBridges are compatible with previous IEEE 802.1 bridges as well as
   current IPv4 and IPv6 routers and end nodes. They are as invisible to
   current IP routers as bridges are and, like routers, they terminate
   the bridge spanning tree protocol.

   The design supports VLANs, and, optionally, optimization of the
   distribution of multi-destination frames based on VLAN and IP derived
   multicast groups.  It also allows forwarding tables to be based on
   RBridge destinations (rather than end node destinations), which
   allows internal forwarding tables to be substantially smaller than in
   conventional bridge systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-trill-rbridge-protocol-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-trill-rbridge-protocol-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trill-rbridge-protocol-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trill-rbridge-protocol-06.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id lALMkK7t019774 for <[e-mail]>; Wed, 21 Nov 2007 14:46:21 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-7.tower-128.messagelabs.com!1195685179!3682350!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 24241 invoked from network); 21 Nov 2007 22:46:19 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-128.messagelabs.com with SMTP; 21 Nov 2007 22:46:19 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lALMk8VW020144 for <[e-mail]>; Wed, 21 Nov 2007 15:46:18 -0700 (MST)
Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id lALMk89e007805 for <[e-mail]>; Wed, 21 Nov 2007 16:46:08 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id lALMk7DK007800 for <[e-mail]>; Wed, 21 Nov 2007 16:46:07 -0600 (CST)
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, 21 Nov 2007 17:46:06 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Rbridge Management
thread-index: AcgmQgHb2ibYLfrhRpiyvyIuvJSEywAc+r0AAB2nUjA=
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Eric Gray" <[e-mail]>
X-CFilter-Loop: Reflected
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 lALMkK7t019774
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Rbridge Management
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 21 Nov 2007 22:47:21 -0000
Status: RO
Content-Length: 3827

Hi Eric,

The suggested paragraph wasn't actually intended to "address management
of RBridges generally" and I would agree that it fails to do that.  I
think that should be done in a separate document. The paragraph was just
intended to reduce possible complaints that the document completely
ignored management or zero configuration management.

RFC 3410 seems to be the standard general SNMP reference when you just
want to mention just one RFC. As you say, RFC 3410 points to many
additional SNMP RFCs. If there is a better RFC to point to, the draft
should be changed to use that.

The text in protocol draft -06 was modified in response to your comment
to mention management via Layer 3.

Donald

> -----Original Message-----
> From: Eric Gray [mailto:[e-mail]] 
> Sent: Wednesday, November 14, 2007 7:21 AM
> To: Eastlake III Donald-LDE008; Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Rbridge Management
> 
> Donald,
> 
> 	Assuming that we can accept that RFC 3410 is the appropriate 
> reference for SNMP generally (it seems to be an informational RFC
> that talks about the relative advantages of different versions of
> SNMP), this assertion is technically correct.  One can use SNMP in
> the way it is described in RFC 4789 to manage RBridges.
> 
> 	However, there are probably at least 3 management models that
> may apply to RBridges, where there are issues/concerns with whether 
> SNMP/L2 would be sufficient (e.g. - from a security perspective,
> from a management platform support perspective, etc.).  The 3 models
> I can quickly imagine - where SNMP/L2 may be either inadequate or 
> not particularly useful - are:
> 
> 1) litteral plug-and-play - no management is anticipated and what 
>    small amount of management that may apply would most likely be
>    done via web-access (IP address required, probably configured
>    via DHCP) or direct connection to a computer;
> 2) some management anticipated (minimal VLAN configuration, or a
>    deployment involving/expecting use of non-default behavior in
>    one or more aspects (out-of-band, or console, management may
>    be sufficient, SNMP/L2 may provide inadequate or incompatible
>    security);
> 3) extensive management is the rule (plug and play is a non-goal,
>    avoidance of address configuration is explicitly a non-goal,
>    use of device interactive security access - requiring dialog
>    via IP - is unavoidable, etc.).
> 
> 	Considering (at least) these cases, while the paragraph you
> propose may be technically correct, it may also be insufficient to 
> address management of RBridges generally.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Eastlake III 
> > Donald-LDE008
> > Sent: Tuesday, November 13, 2007 5:11 PM
> > To: Developing a hybrid router/bridge.
> > Subject: [rbridge] Rbridge Management
> > 
> > Judging from the experience of previous documents in the 
> > IESG, I believe
> > it would be wise for the base protocol document to say 
> something about
> > management.
> > 
> > So I think that something like the following should be added, 
> > perhaps as
> > a paragraph just before the 2.1 Section heading.
> > 
> > "Rbridges can be managed with SNMP [RFC3410]. The Rbridge 
> MIB will be
> > specified in a separate document. SNMP can be transported 
> directly by
> > Layer 2 (see [RFC4789]) so its use within the bounds of an Rbridge
> > campus does not require that Rbridges be configured with Layer 3
> > addresses such as IP addresses."
> > 
> > Any comments?
> > 
> > Donald
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 



Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lAKJF682010136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 20 Nov 2007 11:15:07 -0800 (PST)
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id AC00D175AC; Tue, 20 Nov 2007 19:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuYYo-0002Wq-7T; Tue, 20 Nov 2007 14:15:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Tue, 20 Nov 2007 14:15:02 -0500
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-06.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Nov 2007 19:16:00 -0000
Status: RO
Content-Length: 3537

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title		: Rbridges: Base Protocol Specification
	Author(s)	: R. Perlman, et al.
	Filename	: draft-ietf-trill-rbridge-protocol-06.txt
	Pages		: 73
	Date		: 2007-11-20
	
RBridges allow for optimal pair-wise forwarding with zero
   configuration, safe forwarding even during periods of temporary
   loops, and multipathing for both unicast and multicast traffic. They
   achieve these goals using IS-IS routing and encapsulation of traffic
   with a header that includes a hop count.

   RBridges are compatible with previous IEEE 802.1 bridges as well as
   current IPv4 and IPv6 routers and end nodes. They are as invisible to
   current IP routers as bridges are and, like routers, they terminate
   the bridge spanning tree protocol.

   The design supports VLANs, and, optionally, optimization of the
   distribution of multi-destination frames based on VLAN and IP derived
   multicast groups.  It also allows forwarding tables to be based on
   RBridge destinations (rather than end node destinations), which
   allows internal forwarding tables to be substantially smaller than in
   conventional bridge systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-trill-rbridge-protocol-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-trill-rbridge-protocol-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trill-rbridge-protocol-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trill-rbridge-protocol-06.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart--


Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lAJ6K2xL024584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Sun, 18 Nov 2007 22:20:03 -0800 (PST)
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 11CBC2AC50; Mon, 19 Nov 2007 06:20:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItzzF-00009c-R3; Mon, 19 Nov 2007 01:20:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Mon, 19 Nov 2007 01:20:01 -0500
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: [rbridge] I-D Action:draft-ietf-trill-rbridge-arch-04.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2007 06:20:24 -0000
Status: RO
Content-Length: 4027

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.


	Title           : The Architecture of an RBridge Solution to TRILL
	Author(s)       : E. Gray, et al.
	Filename        : draft-ietf-trill-rbridge-arch-04.txt
	Pages           : 34
	Date            : 2007-11-19

RBridges are link layer (L2) devices that use a routing protocol 

  as a control plane. This combines several of the benefits of the 

  link layer with those of the network layer. For example RBridges 

  use existing link state routing, without necessarily requiring 

  configuration, to improve aggregate throughput, for RBridge to 






  Gray






 Expires May, 2008




 [page 1] 








  Internet-Draft


  RBridge Architecture


November 2007 





  RBridge traffic. RBridges also may support IP multicast and IP 

  address resolution optimizations. They are intended to be 

  applicable to L2 network sizes similar to those of conventional 

  bridges and are intended to be backward compatible with those 

  bridges as both ingress/egress and transit. They also support 

  VLANs (although this generally requires configuration) while 

  otherwise attempting to retain as much 'plug and play' as is 

  already available in existing bridges. This document proposes an 

  architecture for RBridge systems as a solution to the TRILL 

  problem, defines terminology, and describes basic components and 

  desired behavior. One (or more) separate documents will specify 

  protocols and mechanisms that satisfy the architecture presented 

  herein. 



































  Gray






 Expires May, 2008




 [page 2] 







  Internet-Draft


  RBridge Architecture


November 2007

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-04.txt

To remove yourself from the I-D Announcement list, send a message to
[e-mail] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-trill-rbridge-arch-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-trill-rbridge-arch-04.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trill-rbridge-arch-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trill-rbridge-arch-04.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-19011433.I-D\@ietf.org>


--OtherAccess--

--NextPart--


Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lAEISUh9025344 for <[e-mail]>; Wed, 14 Nov 2007 10:28:31 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.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]; Wed, 14 Nov 2007 10:28:30 -0800 (PST)
Received: from [129.145.154.66] ([192.18.43.225]) 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]; Wed, 14 Nov 2007 10:28:30 -0800 (PST)
Date: Wed, 14 Nov 2007 10:28:29 -0800
From: [e-mail]
In-reply-to: <[e-mail]>
To: Eric Gray <[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]> <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109
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] Rbridge Management
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 14 Nov 2007 18:29:16 -0000
Status: RO
Content-Length: 3232

I wouldn't want us to agonize over that paragraph and delay putting out
the next version of the spec. It seems fine to me, and does not preclude
configuring (or otherwise acquiring, e.g., with
DHCP) an IP address for the RBridge and
configuring it using SNMP over IP.

Radia


Eric Gray wrote:

>Donald,
>
>	Assuming that we can accept that RFC 3410 is the appropriate 
>reference for SNMP generally (it seems to be an informational RFC
>that talks about the relative advantages of different versions of
>SNMP), this assertion is technically correct.  One can use SNMP in
>the way it is described in RFC 4789 to manage RBridges.
>
>	However, there are probably at least 3 management models that
>may apply to RBridges, where there are issues/concerns with whether 
>SNMP/L2 would be sufficient (e.g. - from a security perspective,
>from a management platform support perspective, etc.).  The 3 models
>I can quickly imagine - where SNMP/L2 may be either inadequate or 
>not particularly useful - are:
>
>1) litteral plug-and-play - no management is anticipated and what 
>   small amount of management that may apply would most likely be
>   done via web-access (IP address required, probably configured
>   via DHCP) or direct connection to a computer;
>2) some management anticipated (minimal VLAN configuration, or a
>   deployment involving/expecting use of non-default behavior in
>   one or more aspects (out-of-band, or console, management may
>   be sufficient, SNMP/L2 may provide inadequate or incompatible
>   security);
>3) extensive management is the rule (plug and play is a non-goal,
>   avoidance of address configuration is explicitly a non-goal,
>   use of device interactive security access - requiring dialog
>   via IP - is unavoidable, etc.).
>
>	Considering (at least) these cases, while the paragraph you
>propose may be technically correct, it may also be insufficient to 
>address management of RBridges generally.
>
>--
>Eric Gray
>Principal Engineer
>Ericsson  
>
>  
>
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Eastlake III 
>>Donald-LDE008
>>Sent: Tuesday, November 13, 2007 5:11 PM
>>To: Developing a hybrid router/bridge.
>>Subject: [rbridge] Rbridge Management
>>
>>Judging from the experience of previous documents in the 
>>IESG, I believe
>>it would be wise for the base protocol document to say something about
>>management.
>>
>>So I think that something like the following should be added, 
>>perhaps as
>>a paragraph just before the 2.1 Section heading.
>>
>>"Rbridges can be managed with SNMP [RFC3410]. The Rbridge MIB will be
>>specified in a separate document. SNMP can be transported directly by
>>Layer 2 (see [RFC4789]) so its use within the bounds of an Rbridge
>>campus does not require that Rbridges be configured with Layer 3
>>addresses such as IP addresses."
>>
>>Any comments?
>>
>>Donald
>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>    
>>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lAECLRJG026326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 14 Nov 2007 04:21:28 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id lAECM6IY016155; Wed, 14 Nov 2007 06:22:06 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 14 Nov 2007 06:21:25 -0600
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, 14 Nov 2007 06:21:23 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Rbridge Management
Thread-Index: AcgmQgHb2ibYLfrhRpiyvyIuvJSEywAc+r0A
References: <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 14 Nov 2007 12:21:25.0683 (UTC) FILETIME=[E02B4830:01C826B8]
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 lAECLRJG026326
Subject: Re: [rbridge] Rbridge Management
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 14 Nov 2007 12:22:27 -0000
Status: RO
Content-Length: 2732

Donald,

	Assuming that we can accept that RFC 3410 is the appropriate 
reference for SNMP generally (it seems to be an informational RFC
that talks about the relative advantages of different versions of
SNMP), this assertion is technically correct.  One can use SNMP in
the way it is described in RFC 4789 to manage RBridges.

	However, there are probably at least 3 management models that
may apply to RBridges, where there are issues/concerns with whether 
SNMP/L2 would be sufficient (e.g. - from a security perspective,
from a management platform support perspective, etc.).  The 3 models
I can quickly imagine - where SNMP/L2 may be either inadequate or 
not particularly useful - are:

1) litteral plug-and-play - no management is anticipated and what 
   small amount of management that may apply would most likely be
   done via web-access (IP address required, probably configured
   via DHCP) or direct connection to a computer;
2) some management anticipated (minimal VLAN configuration, or a
   deployment involving/expecting use of non-default behavior in
   one or more aspects (out-of-band, or console, management may
   be sufficient, SNMP/L2 may provide inadequate or incompatible
   security);
3) extensive management is the rule (plug and play is a non-goal,
   avoidance of address configuration is explicitly a non-goal,
   use of device interactive security access - requiring dialog
   via IP - is unavoidable, etc.).

	Considering (at least) these cases, while the paragraph you
propose may be technically correct, it may also be insufficient to 
address management of RBridges generally.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Tuesday, November 13, 2007 5:11 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] Rbridge Management
> 
> Judging from the experience of previous documents in the 
> IESG, I believe
> it would be wise for the base protocol document to say something about
> management.
> 
> So I think that something like the following should be added, 
> perhaps as
> a paragraph just before the 2.1 Section heading.
> 
> "Rbridges can be managed with SNMP [RFC3410]. The Rbridge MIB will be
> specified in a separate document. SNMP can be transported directly by
> Layer 2 (see [RFC4789]) so its use within the bounds of an Rbridge
> campus does not require that Rbridges be configured with Layer 3
> addresses such as IP addresses."
> 
> Any comments?
> 
> Donald
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id lADMAdrB010106 for <[e-mail]>; Tue, 13 Nov 2007 14:10:40 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-12.tower-128.messagelabs.com!1194991838!16395070!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 2569 invoked from network); 13 Nov 2007 22:10:39 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-128.messagelabs.com with SMTP; 13 Nov 2007 22:10:39 -0000
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lADMAaIS016003 for <[e-mail]>; Tue, 13 Nov 2007 15:10:38 -0700 (MST)
Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lADMAai6004736 for <[e-mail]>; Tue, 13 Nov 2007 16:10:36 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id lADMAZhX004727 for <[e-mail]>; Tue, 13 Nov 2007 16:10:35 -0600 (CST)
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: Tue, 13 Nov 2007 17:10:32 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rbridge Management
thread-index: AcgmQgHb2ibYLfrhRpiyvyIuvJSEyw==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-CFilter-Loop: Reflected
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 lADMAdrB010106
Subject: [rbridge] Rbridge Management
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 13 Nov 2007 22:10:50 -0000
Status: RO
Content-Length: 609

Judging from the experience of previous documents in the IESG, I believe
it would be wise for the base protocol document to say something about
management.

So I think that something like the following should be added, perhaps as
a paragraph just before the 2.1 Section heading.

"Rbridges can be managed with SNMP [RFC3410]. The Rbridge MIB will be
specified in a separate document. SNMP can be transported directly by
Layer 2 (see [RFC4789]) so its use within the bounds of an Rbridge
campus does not require that Rbridges be configured with Layer 3
addresses such as IP addresses."

Any comments?

Donald



Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA7J21wC012727 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Wed, 7 Nov 2007 11:02:01 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.68.130]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lA7J1owU028811 for <[e-mail]>; Wed, 7 Nov 2007 19:02:01 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA7J1kv6631762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Nov 2007 11:01:50 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 07 Nov 2007 11:01:45 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (X11/20070723)
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] Agenda items for Vancouver?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 19:02:21 -0000
Status: RO
Content-Length: 131

I assume we will have issues to discuss/close on the protocol specification.

What other agenda items should we cover?

    Erik



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA7HJxvR002140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 7 Nov 2007 09:20:00 -0800 (PST)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id lA7HKJXI025848; Wed, 7 Nov 2007 11:20:19 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 7 Nov 2007 11:19:57 -0600
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, 7 Nov 2007 11:19:56 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Preview of changes for VLANs, etc.
Thread-Index: AcghTMHjyHbW2ShfTimSxGmdqzbXBwADzuIwAAFyfaA=
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Russ White" <[e-mail]>
X-OriginalArrivalTime: 07 Nov 2007 17:19:57.0940 (UTC) FILETIME=[6BD08B40:01C82162]
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 lA7HJxvR002140
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 17:20:47 -0000
Status: RO
Content-Length: 3671

Anoop,

	I think you make the mistake of thinking that - because 
all of the comments appear to be at a high level and none are
specifically calling out flaws in the existing text - there 
are no issues with the existing text.

	It may very well be the case that some of us feel that 
the existing text is heading in a way that will lead to a 
hopeless tangle and that pursuing detailed evaluation of the
existing text only helps to make that happen.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
> Sent: Wednesday, November 07, 2007 11:40 AM
> To: Russ White
> Cc: Developing a hybrid router/bridge.; Radia Perlman
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> 
> > -----Original Message-----
> > From: Russ White [mailto:[e-mail]] 
> > Sent: Wednesday, November 07, 2007 6:44 AM
> > To: Anoop Ghanwani
> > Cc: Radia Perlman; Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > 
> > > I thought that is what the draft does.
> > 
> > The current draft has all of these different forwarding modes in it?
> 
> It's been a while since I looked at it, but it looked
> reasonable in terms of forwarding rules.  We've had 
> some discussions around minor issues but nothing to
> the extent of revamping the whole thing.
>  
> > >> If an rbridge receives a unicast packet without a VLAN 
> > tag, it will:
> > > 
> > > Assuming we're talking about the inner tag...
> > 
> > No, the entire process. Look at the outer tag, determine it's 
> > not the real vlan (how do you do this?), then you do x, then 
> > y, then z....
> 
> Well, if the frame is not addressed to the RBridge,
> or if it's not addressed to the All-RBridges multicast
> address, then you pretty much treat it like
> a bridged frame.  I really recommend reading the
> draft.  Even in its current version it will tell
> you a lot about the issues and the thought process
> that has got us to where we are.
> 
> > What's the entire decision tree for all possible types of 
> > traffic--not little bits and pieces of it, the entire thing? 
> > IMHO, once you see the entire tree in one place, you're going 
> > to realize this is a very complex forwarding mechanism, 
> > compared to anything currently running.
> > 
> > Forwarding hardware eats power, space, and cooling. Simple 
> > forwarding processes are better than complex ones, where you 
> > have to do a lot of peeking and poking to figure out what to 
> > do with a packet.
> 
> No argument there whatsoever!
> 
> > > The problem with special casing the no-VLAN case is that 
> we're now 
> > > build a new type of bridging that combines 802.1D with 
> > 802.1Q, and in 
> > > the process will likely break both.  With 802.1Q a packet 
> > always has a 
> > > VLAN context.  With 802.D there is no VLAN context.  This matters 
> > > especially when you encounter situations with the same MAC 
> > addresses 
> > > in different VLANs.
> > 
> > Why do you need the vlan context in the cloud? You are 
> > forwarding to an egress rbridge, not along a vlan.
> 
> You don't for unicast (assuming you're talking
> about the inner tag).  For multicast, it's needed
> as an optimization to limit propagation to only
> those egress RBridges that are interested in 
> the frame.  A lot of this information is discussed
> in the draft.
> 
> Anoop
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA7HBRRp029331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 7 Nov 2007 09:11:27 -0800 (PST)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id lA7HBOsx017717; Wed, 7 Nov 2007 11:11:25 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 7 Nov 2007 11:11:24 -0600
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, 7 Nov 2007 11:11:24 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Preview of changes for VLANs, etc.
Thread-Index: Acgg0vKWDtDMre1mRfyg/GBQE1+AQgACdoggACCz+RA=
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Russ White" <[e-mail]>
X-OriginalArrivalTime: 07 Nov 2007 17:11:24.0962 (UTC) FILETIME=[3A0E5020:01C82161]
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 lA7HBRRp029331
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 17:12:02 -0000
Status: RO
Content-Length: 7021

Anoop,

	When you talk of an implementation that allows for sending
and receiving frames for multiple VLANs in a single interface, I
strongly suspect that this is because your model for what "logical
interfaces" are is different.

	If you define a logical (Ethernet) interface as being - for 
example - qualified by the MAC address and a specific VID, than
it is non-sensical to talk about having multiple VLAN associations
via that logical interface.  Many implementers use the term logical
interface exactly this way.

	On the other hand, if you define logical (Ethernet) interfaces
by MAC address alone - or perhaps using some distinguishing factor,
other than VID - then what you are saying is not incorrect.  

	I wonder, though, how useful that model is from an implementer
perspective.  VID is - with the exception of the SVL case - integral
to the forwarding context associated with any frames received on any
interface (and - obviously - the same would apply when sending, since
there is a similar implied context at the next receiver).  

	Hence - from the perspective of making a forwarding decision -
receiving a frame on a different VLAN is not different from receiving
it on a completely different physical interface.

	What can an implementer gain from distinguishing "forwarding 
context" from "logical interface"?

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
> Sent: Tuesday, November 06, 2007 8:39 PM
> To: Russ White
> Cc: Developing a hybrid router/bridge.; Radia Perlman
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> 
>  
> 
> > -----Original Message-----
> > From: Russ White [mailto:[e-mail]] 
> > Sent: Tuesday, November 06, 2007 4:09 PM
> > To: Anoop Ghanwani
> > Cc: Radia Perlman; Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > 
> > > - For ports that support both bridged and TRILL
> > >   traffic we have to go with what 802.1 says
> > >   (otherwise the traffic won't go through bridges).
> > > 
> > > Thus far, all RBridge ports are assumed to be 
> > > of the last type.  That means the encapsulation has
> > > to follow rules defined by 802.1 - i.e. you have
> > > a set of VLANs on that port.  We only transmit
> > > traffic on those VLANs.  Some of those VLANs belong
> > > to the "tagged set" in which case we transmit frames
> > > for those VLANs in tagged format; other VLANs belong
> > > to the "untagged" set in which case we transmit 
> > > frames without a tag.
> > 
> > In all implementations that I know of, such interfaces are always:
> > 
> > 1. Trunk ports, which I've already covered.
> > 2. A single physical interface with multiple logical 
> "subinterfaces."
> > 
> > Can you point to a single case where a device can send multiple vlan
> > traffic on a single logical interface, or where it treats a single
> > interface as a link with multiple vlans while not calling it 
> > a "trunk,"
> > and putting special operational rules around it (such as no end host
> > devices)?
> 
> We must be talking past each other because I'm
> not sure what the above comment is getting at.
> Nowhere have I talked about "multiple VLAN
> traffic on a single logical interface".  Please
> give me the full context if possible.
> 
> By the way, trunk ports in one large, prominent
> vendor's implementation is a subset of the 
> standard.  The 802.1 document does not talk
> about trunk ports at all, and on a given port
> you can have any bunch of VLANs, some of which
> are tagged and some of which are untagged.  
> And this is different that the "trunk port".
> 
> > > I think what we have defined so far is fine.
> > > There is no need to change it.  Making it optional
> > > won't work.
> > 
> > What has been defined so far is very complex--you're recreating
> > subinterfaces without subinterfaces, for no reason I can see.
> 
> The subinterfaces are there because an RBridge
> is also a bridge.  Just like a bridge has VLANs
> configured on ports, an RBridge will also have
> VLANs configured on ports.  The reason this is
> needed is because we have to know which VLANs
> are configured on a port when we receive
> a multicast packet from another RBridge that
> needs to be forwarded on the port.
>  
> > > Even routers have to follow those rules or
> > > their packets don't make it through the LAN!
> > 
> > Routers don't follow these rules.... They don't simply put 
> > "some random
> > vlan number" on any packet they are transmitting to "get the packet
> > through the LAN." There is no "common vlan" assigned to each link to
> > allow routers to communicate. There is no concept of a 
> "single hello"
> > for multiple virtual topologies on a single link, with all sorts of
> > stuff added so everyone on the link knows which virtual 
> > network everyone
> > else is on.
> 
> We are not talking about putting a random number.
> We are talking about putting some VLAN ID that is
> configured on the port.
> 
> > Routers operate exactly as I described previously. If a 
> > router receives
> > a packet on an interface, it will:
> > 
> > 1. Find the next hop, by looking at the tree.
> > 2. Figure out the outbound interface.
> > 3. Encap the packet with the correct layer 2 header for that 
> > interface.
> > 3a. If the outbound interface is a subinterface, the layer 2 
> > header will
> > include, of course, a vlan header.
> > 3b. If the outbound interface is not a subinterface, the 
> > layer 2 header
> > will not include a vlan header.
> 
> I agree with this.
>  
> > Whether or not there's a vlan tag that needs to be added 
> plays no part
> > in the forwarding decision.
> 
> That is correct...however, as you note in 3, 3a, 3b,
> you have to know the interface that you're forwarding
> the packet on.  That interface, in the RBridge world,
> is a VLAN on a specific port (for unicast) or a \
> VLAN on a set of ports (for multicast).
> 
> > IMHO, rbridges _should_ operate as much like routers as 
> > possible, rather
> > than using some new forwarding paradigm. Once the traffic is 
> > placed in a
> > tunnel, it should be carried--as much as possible--just like an IP
> > packet is carried.
> 
> So if I have the following configuration:
> (R1) <---(vlan1)---> (R2) <---(vlan1)---> (R3)
> the packets between the routers could either
> be tagging the frames or not and that depends
> on the configuration of the port in question.
> (In the implementation you are familiar with,
> untagged would mean there is no subinterface,
> and tagged means there is a subinterface with
> a tag of 1.  Just because I have a subinterface
> in the latter case, does not mean another 
> subinterface must exist on that router port.)
> 
> Anoop 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA7H1Ier026001 for <[e-mail]>; Wed, 7 Nov 2007 09:01:19 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,385,1188792000"; d="scan'208";a="75381749"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Nov 2007 12:01:18 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA7H1I4O025473;  Wed, 7 Nov 2007 12:01:18 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA7H0xdc022034;  Wed, 7 Nov 2007 17:01:14 GMT
Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 7 Nov 2007 12:01:04 -0500
Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 7 Nov 2007 12:01:04 -0500
Message-ID: <[e-mail]>
Date: Wed, 07 Nov 2007 12:00:26 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Anoop Ghanwani <[e-mail]>
References: <[e-mail]> <[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Nov 2007 17:01:04.0290 (UTC) FILETIME=[C81B4820:01C8215F]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.002
X-TM-AS-Result: No--10.080200-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1803; t=1194454878; x=1195318878; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Preview=20of=20changes=20for=20VLANs, =20e tc. |Sender:=20 |To:=20Anoop=20Ghanwani=20<[e-mail]>; bh=T9YgsKRvfPFO2G/qKdi8NhdZWYNeQTG9OWY8R3/Dv9A=; b=PYZUt8aWKpIDTBTHUvInFtv87Jdbxti/QyNQ2uGmwAI/OW27WpWhsf5g1nvadAYW8LS0O6c0 ITVkXp3c/fNlfBt8ks9ba/Sn6qxFGk4vLpU6gbIyK6NlID7rBrlGQRd+;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); 
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] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 17:01:46 -0000
Status: RO
Content-Length: 1782

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> It's been a while since I looked at it, but it looked
> reasonable in terms of forwarding rules.  We've had 
> some discussions around minor issues but nothing to
> the extent of revamping the whole thing.

The draft has been updated to include the discussion of the last two
weeks, and the idea of including a vlan tag on all packets, unicast and
multicast, in order to get across broadcast links?

>> Why do you need the vlan context in the cloud? You are 
>> forwarding to an egress rbridge, not along a vlan.
> 
> You don't for unicast (assuming you're talking
> about the inner tag).  For multicast, it's needed
> as an optimization to limit propagation to only
> those egress RBridges that are interested in 
> the frame.  A lot of this information is discussed
> in the draft.

But, the recent discussion has been to add it for _all_ packets, unicast
and multicast.

First, I think we may have overoptimized for multicast--when we get to
the point where we're adding context that's no needed in unicast to
optimize for multicast, we're eating the bandwidth we thought we'd be
saving through the optimization. Second, I think we may be overthinking
the problem in general. There's no reason, I don't think, for vlan
context tags even for multicast within the rbridge cloud. I suspect a
lot of this doesn't revolve around multicast optimization, but rather
around the idea of having fully mixed rbridge/bridge environments.

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMe8qER27sUhU9OQRAnIzAKDJSn+2i/3NlJCbIvX0Ab/G03yRNACg1hIL
Jxrd1GmKiZ1amTJx+W5Tk1Q=
=E9Hy
-----END PGP SIGNATURE-----


Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA7Gx1Kj024809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 7 Nov 2007 08:59:01 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id lA7GwxG3013125; Wed, 7 Nov 2007 10:59:00 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 7 Nov 2007 10:58:59 -0600
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, 7 Nov 2007 10:58:59 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Preview of changes for VLANs, etc.
Thread-Index: Acgg3dGFabL37koiR8iYRWGp8CgVMwAgTURg
References: <[e-mail]> <[e-mail]><[e-mail]><[e-mail]> <[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Russ White" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 07 Nov 2007 16:58:59.0229 (UTC) FILETIME=[7D907CD0:01C8215F]
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 lA7Gx1Kj024809
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 16:59:27 -0000
Status: RO
Content-Length: 2287

Radia,

	I have to agree with what Russ says below.  I think 
this has been a part of the issue in previous discussions:
people are trying to see things simply (by pretending that
VLANs can be treated arbritrarily) but have been making it
all much more complicated in doing so.

	Russ' description of VLAN interactions is simple and 
correct.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Russ White
> Sent: Tuesday, November 06, 2007 7:49 PM
> To: Radia Perlman
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > RBridges, on the other hand, like bridges, are 
> simultaneously supporting
> > multiple VLANs
> > over the same port. VLANs that the RBridge itself is not a 
> member of in
> > any sense -- just
> > that the RBridge is supposed to support to glue it to other 
> pieces of
> > the VLAN in other
> > parts of the campus.
> 
> Again, the only two instances I know of are:
> 
> 1. There are subinterfaces, or physical interfaces, which belong to a
> single vlan.
> 
> 2. The port is declared a trunk, and specific rules apply to the port,
> such as no end user traffic is allowed on the port.
> 
> And I still don't see what any of this has to do with all this
> complexity. I've described all the situations in previous emails, and
> how to handle them, without the concept of a "common vlan," 
> etc. Again,
> why do we need this complexity? What is it supporting? Can 
> someone point
> to a specific situation that wouldn't be handled by the 
> forwarding rules
> I proposed earlier--that's not contrived, and impossible with all
> current implementations?
> 
> :-)
> 
> Russ
> 
> - --
> [e-mail] CCIE <>< Grace Alone
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFHMQtxER27sUhU9OQRAoeAAKDx4z6UoUgHVEWSMibQ7Z/sOfknDgCg1+YI
> HDaYykz4jypmQnjo9P5KNcU=
> =yDY4
> -----END PGP SIGNATURE-----
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA7GrCff022475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 7 Nov 2007 08:53:12 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id lA7Gr9iN011030; Wed, 7 Nov 2007 10:53:10 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 7 Nov 2007 10:53:09 -0600
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, 7 Nov 2007 10:53:08 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] RBridge: a case of study
Thread-Index: AcgfwhTUjX8M824DQCWRzJk1fpQ2/AA+nr2wACgQ48A=
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, "James Carlson" <[e-mail]>
X-OriginalArrivalTime: 07 Nov 2007 16:53:09.0222 (UTC) FILETIME=[ACF1A860:01C8215E]
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 lA7GrCff022475
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RBridge: a case of study
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 16:53:17 -0000
Status: RO
Content-Length: 5447

Donald,

	Speaking of meta-data, I find it very difficult to 
figure out who you're responding to when you use the @@@ 
and ### notation.

	It looks as if you're responding (with ###) to James 
Carlson's response to your earlier mail (with @@@), which
was itsef a reply to James' response to me.  Have I got it
figured out right?

	In any case, I have to disagree with your assertion 
that "coloring" does not make sense on a P2P link.  While
your assertion that a wire is not going to queue frames,
or make decisions based on priority, the next hop RBridge
is going to do so.

	One of the obvious examples of where either the PCP
or the VID might be useful additional information can be 
seen by analogy with what a service provider might need to
do in transporting customer frames.  An SP may have a way
to map the customer's frames to compatible PCP and VID -
used to provide some form of assured service, for example
- that is compatible with but not the same as the PCP and
VID used by the customer.  In this case, the customer's
frame PCP and VID are not useful when forwarding frames
across the SP backbone, but the customer's PCP and VID
MUST be preserved.

	I know that - thus far - we've not opened the door 
in our charter to talk about the application of RBridge
technology to anything other than enterprise networks.
Yet the analogy still applies even in the enterprise.

	Even if you feel that this technology will not be
applied to even such an enterprise, I can see little 
value in specifying "extra stuff" just to make the work
we're doing unusable for such applications.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Tuesday, November 06, 2007 4:59 PM
> To: James Carlson
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] RBridge: a case of study
> 
> See below at ### 
> 
> -----Original Message-----
> From: James Carlson [mailto:[e-mail]] 
> Sent: Monday, November 05, 2007 10:16 AM
> To: Eastlake III Donald-LDE008
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] RBridge: a case of study
> 
> Eastlake III Donald-LDE008 writes:
> > From: James Carlson [mailto:[e-mail]] 
> [...]
> > Eric Gray writes:
> [...]
> > > 2) all frames forwarded from a (physical) port on one RBridge 
> > >    to a (physical) port on another RBridge MUST have the same
> > >    VID, or 
> [...]
> > @@@ Well, I am Donald and I meant something like (2) but a bit
> narrower.
> > I would have said "all TRILL frames" because "all frames" is way too
> > inclusive. What about control frames like 802.1AB? 
> Furthermore, in the
> > case of point-to-point links between two Rbridges (i.e., no 
> bridges or
> > end station connections in between), as far as I can see there is no
> > particular utility in considering the TRILL frames to have any
> external
> > VLAN coloring and certainly no need for them to be outer 
> tagged with a
> > VLAN ID or priority.
> 
> I mostly agree with that.  In fact, I think that's a desirable end
> state for TRILL, when all other bridges are obsolete.  Having no VLAN
> tag on the outside makes a lot of sense there.
> 
> (I think omitting the priority makes a bit less sense to me, though.
> Wouldn't you want the priority value set on an 802.1q header with VLAN
> ID 0 in this case?)
> 
> ### The way I look at it, the VLAN coloring and priority of a 
> frame are
> meta data associated with the frame. The priority is used in queuing
> decisions related to processing and transmitting the frame. Just what
> Q-tag gets put on the transmitted frame depends on configuration.
> 
> ### If a link is point-to-point between Rbridges, there is no need for
> an outer VLAN ID. If it is a data frame, the actual VLAN ID 
> of the data
> is in the inner Q-tag and so easily available to the next Rbridge for
> its decision processes. Similarly, I don't see any reason for priority
> in the outer Q-tag. It's not as if a piece of wire is going to look at
> the priority and re-order frames. If it is a data frame, the actual
> priority of the data is in the inner Q-tag and so is easily 
> available to
> the next Rbridge.
> 
> ### TRILL core IS-IS frames, of course, are different. They don't have
> any inner Q-tag because the don't have any inherent VLAN coloring and
> they only go one hop anyway. An Rbridge might want to associate
> "priority 7" or whatever as meta data with the core IS-IS 
> frame while it
> is internal to the Rbridge and that could effect transmission queuing
> but there is no particular reason for there to be a priority tag on it
> over a point-to-point link. The next Rbridge will see that it 
> is a core
> IS-IS message, will probably treat it a bit differently for 
> processing,
> and give it to its core IS-IS instance.
> 
> ### Thanks,
> ### Donald
> 
> I think the question is how to get there when there are networks that
> are half-TRILL and half-otherwise.
> 
> ...
> 
> -- 
> James Carlson, Solaris Networking              
> <[e-mail]>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA7GdehE016906 for <[e-mail]>; Wed, 7 Nov 2007 08:39:48 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,385,1188802800"; d="scan'208";a="13597014"
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 07 Nov 2007 08:39:40 -0800
Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 19A4C238302; Wed,  7 Nov 2007 08:39:40 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 7 Nov 2007 08:39:40 -0800
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, 7 Nov 2007 08:39:30 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Preview of changes for VLANs, etc.
Thread-Index: AcghTMHjyHbW2ShfTimSxGmdqzbXBwADzuIw
References: <[e-mail]> <[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Russ White" <[e-mail]>
X-OriginalArrivalTime: 07 Nov 2007 16:39:40.0314 (UTC) FILETIME=[CACC17A0:01C8215C]
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 lA7GdehE016906
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 16:40:22 -0000
Status: RO
Content-Length: 2564

> -----Original Message-----
> From: Russ White [mailto:[e-mail]] 
> Sent: Wednesday, November 07, 2007 6:44 AM
> To: Anoop Ghanwani
> Cc: Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > I thought that is what the draft does.
> 
> The current draft has all of these different forwarding modes in it?

It's been a while since I looked at it, but it looked
reasonable in terms of forwarding rules.  We've had 
some discussions around minor issues but nothing to
the extent of revamping the whole thing.
 
> >> If an rbridge receives a unicast packet without a VLAN 
> tag, it will:
> > 
> > Assuming we're talking about the inner tag...
> 
> No, the entire process. Look at the outer tag, determine it's 
> not the real vlan (how do you do this?), then you do x, then 
> y, then z....

Well, if the frame is not addressed to the RBridge,
or if it's not addressed to the All-RBridges multicast
address, then you pretty much treat it like
a bridged frame.  I really recommend reading the
draft.  Even in its current version it will tell
you a lot about the issues and the thought process
that has got us to where we are.

> What's the entire decision tree for all possible types of 
> traffic--not little bits and pieces of it, the entire thing? 
> IMHO, once you see the entire tree in one place, you're going 
> to realize this is a very complex forwarding mechanism, 
> compared to anything currently running.
> 
> Forwarding hardware eats power, space, and cooling. Simple 
> forwarding processes are better than complex ones, where you 
> have to do a lot of peeking and poking to figure out what to 
> do with a packet.

No argument there whatsoever!

> > The problem with special casing the no-VLAN case is that we're now 
> > build a new type of bridging that combines 802.1D with 
> 802.1Q, and in 
> > the process will likely break both.  With 802.1Q a packet 
> always has a 
> > VLAN context.  With 802.D there is no VLAN context.  This matters 
> > especially when you encounter situations with the same MAC 
> addresses 
> > in different VLANs.
> 
> Why do you need the vlan context in the cloud? You are 
> forwarding to an egress rbridge, not along a vlan.

You don't for unicast (assuming you're talking
about the inner tag).  For multicast, it's needed
as an optimization to limit propagation to only
those egress RBridges that are interested in 
the frame.  A lot of this information is discussed
in the draft.

Anoop



Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA7EiqF9029797 for <[e-mail]>; Wed, 7 Nov 2007 06:44:52 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,384,1188792000"; d="scan'208";a="75370432"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Nov 2007 09:44:52 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA7EipBM022022;  Wed, 7 Nov 2007 09:44:51 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA7EikWT007137;  Wed, 7 Nov 2007 14:44:47 GMT
Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 7 Nov 2007 09:44:41 -0500
Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 7 Nov 2007 09:44:40 -0500
Message-ID: <[e-mail]>
Date: Wed, 07 Nov 2007 09:44:03 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Anoop Ghanwani <[e-mail]>
References: <[e-mail]> <[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Nov 2007 14:44:40.0946 (UTC) FILETIME=[BA741520:01C8214C]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.002
X-TM-AS-Result: No--5.354700-8.000000-2
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1713; t=1194446691; x=1195310691; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Preview=20of=20changes=20for=20VLANs, =20e tc. |Sender:=20 |To:=20Anoop=20Ghanwani=20<[e-mail]>; bh=8E/N2QWho/IA51qoSeRxpuEAE4RAXqayz+lHMuZgv0U=; b=QSzSlTMgkx4MShoA2+6wEvKikV3jn/86XreOjVTEApUOlfPRKAuQ05D8pZgvU5rB+zuPm2AW iHOi1HWmyXQh9HDXVEYwxnb33GS1ULhEUmJL7PNlk3UBr1FgjyMPAuJy;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); 
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] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 14:45:22 -0000
Status: RO
Content-Length: 1691

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> I thought that is what the draft does.

The current draft has all of these different forwarding modes in it?

>> If an rbridge receives a unicast packet without a VLAN tag, it will:
> 
> Assuming we're talking about the inner tag...

No, the entire process. Look at the outer tag, determine it's not the
real vlan (how do you do this?), then you do x, then y, then z....

What's the entire decision tree for all possible types of traffic--not
little bits and pieces of it, the entire thing? IMHO, once you see the
entire tree in one place, you're going to realize this is a very complex
forwarding mechanism, compared to anything currently running.

Forwarding hardware eats power, space, and cooling. Simple forwarding
processes are better than complex ones, where you have to do a lot of
peeking and poking to figure out what to do with a packet.

> The problem with special casing the no-VLAN case
> is that we're now build a new type of bridging 
> that combines 802.1D with 802.1Q, and in the 
> process will likely break both.  With 802.1Q
> a packet always has a VLAN context.  With 802.D
> there is no VLAN context.  This matters especially
> when you encounter situations with the same
> MAC addresses in different VLANs.

Why do you need the vlan context in the cloud? You are forwarding to an
egress rbridge, not along a vlan.

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMc8zER27sUhU9OQRArt9AJ0ebnvnnRhJeOKqiDDiLlCsU9UDvwCfTZmB
V/Ny5UnlRpFEW0/UgxROX1A=
=S3ar
-----END PGP SIGNATURE-----


Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA7E6v1n015595 for <[e-mail]>; Wed, 7 Nov 2007 06:06:57 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,384,1188802800"; d="scan'208";a="13595001"
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 07 Nov 2007 06:06:47 -0800
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-plato-6 [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 74E33238301; Wed,  7 Nov 2007 06:06:47 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 7 Nov 2007 06:06:48 -0800
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, 7 Nov 2007 06:06:39 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Preview of changes for VLANs, etc.
Thread-Index: AcghPCOgmtrF0wkrT7eAz/ehSBhdKAACrxiA
References: <[e-mail]> <[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Russ White" <[e-mail]>
X-OriginalArrivalTime: 07 Nov 2007 14:06:48.0188 (UTC) FILETIME=[6FC8BBC0:01C82147]
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 lA7E6v1n015595
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 14:07:21 -0000
Status: RO
Content-Length: 1504

 

> -----Original Message-----
> From: Russ White [mailto:[e-mail]] 
> Sent: Wednesday, November 07, 2007 4:44 AM
> To: Anoop Ghanwani
> Cc: Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> >>> 1. Find the next hop, by looking at the tree.
> >>> 2. Figure out the outbound interface.
> >>> 3. Encap the packet with the correct layer 2 header for that 
> >>> interface.
> >>> 3a. If the outbound interface is a subinterface, the 
> layer 2 header 
> >>> will include, of course, a vlan header.
> >>> 3b. If the outbound interface is not a subinterface, the layer 2 
> >>> header will not include a vlan header.
> 
> >> I agree with this.
> 
> Since this is obviously not the forwarding path for rbridges, 
> I think it would be very useful if you could outline the 
> actual forwarding path, with all the possible "if" statements 
> involved.

I thought that is what the draft does.

> If an rbridge receives a unicast packet without a VLAN tag, it will:

Assuming we're talking about the inner tag...

The problem with special casing the no-VLAN case
is that we're now build a new type of bridging 
that combines 802.1D with 802.1Q, and in the 
process will likely break both.  With 802.1Q
a packet always has a VLAN context.  With 802.D
there is no VLAN context.  This matters especially
when you encounter situations with the same
MAC addresses in different VLANs.
 
Anoop



Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA7E14MC012910 for <[e-mail]>; Wed, 7 Nov 2007 06:01:13 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,384,1188802800"; d="scan'208";a="13594948"
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 07 Nov 2007 06:01:00 -0800
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-plato-6 [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id F4185238302; Wed,  7 Nov 2007 06:00:59 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 7 Nov 2007 06:01:00 -0800
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, 7 Nov 2007 06:00:52 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Preview of changes for VLANs, etc.
Thread-Index: AcghNM80JeHDF03ZQiuOq6xtMTuaQAAELNjQ
References: <[e-mail]> <[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Russ White" <[e-mail]>
X-OriginalArrivalTime: 07 Nov 2007 14:01:00.0664 (UTC) FILETIME=[A0A4C780:01C82146]
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 lA7E14MC012910
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 14:01:55 -0000
Status: RO
Content-Length: 3797

 

> -----Original Message-----
> From: Russ White [mailto:[e-mail]] 
> Sent: Wednesday, November 07, 2007 3:53 AM
> To: Anoop Ghanwani
> Cc: Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > The subinterfaces are there because an RBridge is also a 
> bridge.  Just 
> > like a bridge has VLANs configured on ports, an RBridge 
> will also have 
> > VLANs configured on ports.  The reason this is needed is because we 
> > have to know which VLANs are configured on a port when we receive a 
> > multicast packet from another RBridge that needs to be forwarded on 
> > the port.
> 
> I don't see where this matters.... All that matters is which 
> egress devices are within the correct vlan for the multicast 
> packet you've just received. You are forwarding to egress 
> devices, not along vlans within the cloud.
> 
> IMHO, this is why this entire confusion has arisen.... You 
> don't need to forward along a given tree, and along a given 
> vlan, and glue vlans together.... Choose one, not all three. 

We don't forward along a tree except for multicast.
We don't glue VLANs together unless they have the
same VID.  And there's no way around that either.

> The entire point of rbridges is that the entire "core" of the 
> rbridge network forwards towards egress bridges, rather than 
> mimicking the virtual topologies along the edge.
> You're now introducing requirements to do both--treat the 
> core as a vlan free space, and only forward along vlans 
> within the core.
> 
> It makes no sense.

I disagree.  What is the point in sending traffic to
an egress RBridge if it is going to discard it anyway?
 
> > We are not talking about putting a random number.
> > We are talking about putting some VLAN ID that is configured on the 
> > port.
> 
> The phrase "some random vlan number, just to get the packet 
> through the LAN," has been used multiple times on list. 

Well at least I have never used that, so I'll let
others who have proposed that I idea defend it.

> Second, restricting all traffic flowing between any set of 
> rbridges on a single link to one vlan across that link makes no sense.

Then you will have the problems for multicast pointed
out by Radia in an earlier email.
 
> >> Routers operate exactly as I described previously. If a router 
> >> receives a packet on an interface, it will:
> >>
> >> 1. Find the next hop, by looking at the tree.
> >> 2. Figure out the outbound interface.
> >> 3. Encap the packet with the correct layer 2 header for that 
> >> interface.
> >> 3a. If the outbound interface is a subinterface, the layer 
> 2 header 
> >> will include, of course, a vlan header.
> >> 3b. If the outbound interface is not a subinterface, the layer 2 
> >> header will not include a vlan header.
> > 
> > I agree with this.
> 
> Then you don't need all this vlan stuff in the middle. You 
> are forwarding through the underlying cloud to the address of 
> an egress device. That address should be in the tunnel encap 
> once the packet enters the cloud.

You deleted my nice picture with the routers discussing
the tagging/untagging issue.  You have to follow the
tag/untag rules of the intermediate bridged clouds.
You don't need it if there is no intermediate cloud.

> It appears we are creating different forwarding rules for 
> multicast than for unicast, without considering the 
> implications of such alternate rule sets on the forwarding 
> hardware, or the simplicity of managing and troubleshooting 
> this stuff.

If you have suggestions, we are all ears!  But
your proposal must be complete.  We have spent
_months_ on the list discussing these issues and
we're starting to revisit them all over again.

Anoop



Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA7Cj2IL015024 for <[e-mail]>; Wed, 7 Nov 2007 04:45:02 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,384,1188802800"; d="scan'208";a="414102938"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2007 04:45:02 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA7Cj1Gx028305;  Wed, 7 Nov 2007 04:45:01 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lA7CiuQ8009728; Wed, 7 Nov 2007 12:45:01 GMT
Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 7 Nov 2007 07:45:00 -0500
Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 7 Nov 2007 07:45:00 -0500
Message-ID: <[e-mail]>
Date: Wed, 07 Nov 2007 07:44:23 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Anoop Ghanwani <[e-mail]>
References: <[e-mail]> <[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Nov 2007 12:45:00.0466 (UTC) FILETIME=[028DC920:01C8213C]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.002
X-TM-AS-Result: No--9.328800-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2389; t=1194439501; x=1195303501; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Preview=20of=20changes=20for=20VLANs, =20e tc. |Sender:=20; bh=TDSoenlXY+n0Cnvs4KpQ8gj524KV3TZN8ViNbDEsnBc=; b=BYfKG3v44smgs6SPr3I6J/qkqiyZ3V5pbrfZWmrfQrq4rU+6xetQxH7z6Q+plcSp6FHvRpdG J+V29vwsvx8JaBSG5B+pl4Eu3uxgkXaqQaHoFF1rmde+XUa3W4EqYict;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); 
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] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 12:45:07 -0000
Status: RO
Content-Length: 2347

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>> 1. Find the next hop, by looking at the tree.
>>> 2. Figure out the outbound interface.
>>> 3. Encap the packet with the correct layer 2 header for that 
>>> interface.
>>> 3a. If the outbound interface is a subinterface, the layer 2 
>>> header will
>>> include, of course, a vlan header.
>>> 3b. If the outbound interface is not a subinterface, the 
>>> layer 2 header
>>> will not include a vlan header.

>> I agree with this.

Since this is obviously not the forwarding path for rbridges, I think it
would be very useful if you could outline the actual forwarding path,
with all the possible "if" statements involved.

If an rbridge receives a unicast packet without a VLAN tag, it will:

1. Examine the local tree to determine the egress rbridge.
2. Examine the local tree to determine the next hop towards that rbridge.
3. Encapsulate the packet in a tunnel header with the next hop being the
egress rbridge.
4. (add another tunnel header to get to the next hop with a "common
vlan" tag, to "get through the network???")

If an rbridge receives a multicast packet without a VLAN tag, it will:

1. Examine the local tree to determine the set of egress rbridges.
2. Examine the local tree to determine the next hop towards that set of
egress rbridges.
3. Add a VLAN tag to denote the VLAN on which this multicast belongs.
4. (add another VLAN tag to get the packet to the next hop, one per next
hop????)

If an rbridge receives a unicast packet with a VLAN tag, it will:

....

If an rbridge receives a multicast packet with a VLAN tag, it will:


....

I think it would be very useful to combine all of this into a single
forwarding path, so we can see what the complexity of this proposal is.
It would also be useful to explain the full process from the attachment
of a new IS onto a broadcast link through the ability of that IS to
forward rbridge traffic--every step involved. Again, it would be useful
to see the complexity level involved of all the different pieces being
proposed.

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMbMnER27sUhU9OQRAnaeAKCoxunj3mM6hoBXWZrrQ1ZWR1VzRQCgkiis
VpfuqQ3KpAOiHGKa4WZ+HMQ=
=nQ3o
-----END PGP SIGNATURE-----


Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA7BrOJa028619 for <[e-mail]>; Wed, 7 Nov 2007 03:53:24 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,384,1188792000"; d="scan'208";a="75355821"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Nov 2007 06:53:23 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA7BrN9E021565;  Wed, 7 Nov 2007 06:53:23 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA7BrNdQ013163;  Wed, 7 Nov 2007 11:53:23 GMT
Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 7 Nov 2007 06:53:22 -0500
Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 7 Nov 2007 06:53:22 -0500
Message-ID: <[e-mail]>
Date: Wed, 07 Nov 2007 06:52:45 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Anoop Ghanwani <[e-mail]>
References: <[e-mail]> <[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Nov 2007 11:53:22.0653 (UTC) FILETIME=[CC1D08D0:01C82134]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.002
X-TM-AS-Result: No--8.173100-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2884; t=1194436403; x=1195300403; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Preview=20of=20changes=20for=20VLANs, =20e tc. |Sender:=20 |To:=20Anoop=20Ghanwani=20<[e-mail]>; bh=1n/cb6azHBEdwSPR/Igwlqh4uxdhhyjuF+bBmxsCE04=; b=hOPDQQdkHcyEjTIJtWcLtgsBR+wNH6Y8qhF66z/R/y6fqVcOHVPyIgvsBD2oyHf7avitAay8 7S/vQF7FvYc7DTiEstB3ewprR1ZVKJZk136SETJG4aNSfzAnVxwZgIdg;
Authentication-Results: rtp-dkim-2; header.From=[e-mail]; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); 
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] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 11:53:37 -0000
Status: RO
Content-Length: 2834

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> The subinterfaces are there because an RBridge
> is also a bridge.  Just like a bridge has VLANs
> configured on ports, an RBridge will also have
> VLANs configured on ports.  The reason this is
> needed is because we have to know which VLANs
> are configured on a port when we receive
> a multicast packet from another RBridge that
> needs to be forwarded on the port.

I don't see where this matters.... All that matters is which egress
devices are within the correct vlan for the multicast packet you've just
received. You are forwarding to egress devices, not along vlans within
the cloud.

IMHO, this is why this entire confusion has arisen.... You don't need to
forward along a given tree, and along a given vlan, and glue vlans
together.... Choose one, not all three. The entire point of rbridges is
that the entire "core" of the rbridge network forwards towards egress
bridges, rather than mimicking the virtual topologies along the edge.
You're now introducing requirements to do both--treat the core as a vlan
free space, and only forward along vlans within the core.

It makes no sense.

> We are not talking about putting a random number.
> We are talking about putting some VLAN ID that is
> configured on the port.

The phrase "some random vlan number, just to get the packet through the
LAN," has been used multiple times on list. Second, restricting all
traffic flowing between any set of rbridges on a single link to one vlan
across that link makes no sense.

>> Routers operate exactly as I described previously. If a 
>> router receives
>> a packet on an interface, it will:
>>
>> 1. Find the next hop, by looking at the tree.
>> 2. Figure out the outbound interface.
>> 3. Encap the packet with the correct layer 2 header for that 
>> interface.
>> 3a. If the outbound interface is a subinterface, the layer 2 
>> header will
>> include, of course, a vlan header.
>> 3b. If the outbound interface is not a subinterface, the 
>> layer 2 header
>> will not include a vlan header.
> 
> I agree with this.

Then you don't need all this vlan stuff in the middle. You are
forwarding through the underlying cloud to the address of an egress
device. That address should be in the tunnel encap once the packet
enters the cloud.

It appears we are creating different forwarding rules for multicast than
for unicast, without considering the implications of such alternate rule
sets on the forwarding hardware, or the simplicity of managing and
troubleshooting this stuff.

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMacNER27sUhU9OQRAufBAKCdPJ9VLoa+cP4Ue6RBuvzLpug37gCfer53
58WguUcL6VZD7VwTjnGT/Jo=
=hrXM
-----END PGP SIGNATURE-----


Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id lA75IUkP015227 for <[e-mail]>; Tue, 6 Nov 2007 21:18:30 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-153.messagelabs.com!1194412709!8022912!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.189.100.105]
Received: (qmail 31515 invoked from network); 7 Nov 2007 05:18:29 -0000
Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-3.tower-153.messagelabs.com with SMTP; 7 Nov 2007 05:18:29 -0000
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id lA75IRPG007327 for <[e-mail]>; Tue, 6 Nov 2007 22:18:29 -0700 (MST)
Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lA75IQ6K011022 for <[e-mail]>; Tue, 6 Nov 2007 23:18:26 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lA75IOsY011004 for <[e-mail]>; Tue, 6 Nov 2007 23:18:25 -0600 (CST)
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, 7 Nov 2007 00:18:22 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Egress processing of unicast not locally known
thread-index: AcgGT/TieMR9BcXdTFeD5f3X6K6HCwOhW8kgAwVG5eA=
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-CFilter-Loop: Reflected
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 lA75IUkP015227
Subject: Re: [rbridge] Consensus Check: Egress processing of unicast not locally known
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 05:19:24 -0000
Status: RO
Content-Length: 4317

Since there have been no further comments, I assume that this consensus
from the Chicago IETF meeting, as expanded upon below, has been
confirmed.

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Monday, October 22, 2007 2:22 PM
To: Dinesh G Dutt
Cc: [e-mail]
Subject: Re: [rbridge] Consensus Check: Egress processing of unicast not
locally known

Dinesh,

Could you be more specific about your worries? I don't see that this
normally has much to do with "configuration".

This is only about the case where an ingress Rbridge receives a unicast
frame where it has learned the egress Rbridge. So it is a known unicast
which it encapsulates and sends off to the egress. The Egress Rbridge
receives this TRILL data frame, can see that it is supposed to be a
known unicast but, for whatever reason, it does not find the original
destination MAC address in its cache of learned addresses. Generally
speaking, this should be a rare occurrence. But you can imagine cases
where you could get a burst of these or cases where you have a chronic
trickle (something sending frames at an interval just slightly longer
than the address cache time out for example).

The alternatives discussed at the Chicago meeting included (1)
broadcasting the frame as an unknown unicast (presumably what 802.1D
bridges do), (2) just dropping the frame, or (3) decapsulating the frame
and sending it out on local links for which this egress Rbridge is the
DRB for the VLAN of the frame. Choice (3) was the consensus in Chicago.
Is that what you are disagreeing with?

There was also consensus in Chicago that the SHOULD do choice (3) did
not apply to a local link where the egress Rbridge knows that a station
with the destination MAC address could not be on that link. SHOULD means
you must do it unless you have a good reason not to. The release of the
"SHOULD" requirement if you know that the MAC address can't be on that
link merely gives the egress Rbridge complete freedom to act. The
consensus does NOT say that the egress Rbridge "SHOULD NOT" send the
frame on such a link. It is free to send it or not on whatever basis it
feels like and would still be in compliance with the standard. To
emphasize this, it says "This is a local decision."

Do you disagree with the consensus as explained in more detail above?

Thanks,
Donald

-----Original Message-----
From: Dinesh G Dutt [mailto:[e-mail]] 
Sent: Thursday, October 04, 2007 2:29 AM
To: Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: Re: [rbridge] Consensus Check: Egress processing of unicast not
locally known

Donald,

This is different from existing IEEE 802.1D bridges. I'm OK with it, as 
long as it is a MAY and not a MUST or a SHOULD. I'm worried that 
misconfigurations and such can cause silent packet drops which can be 
hard to debug.

Dinesh
Eastlake III Donald-LDE008 wrote:
> This is a check via the mailing list to confirm or refute an apparent
> consensus from the minutes of the Chicago meeting for a change from
> protocol draft -05:
>
>    Egress RBridges that receive a known unicast TRILL data frame whose
>    inner destination address is not known locally should send the
>    native form of the frame out on every link for which the RBridge
>    is DRB for the frame's VLAN unless it knows that an end station
>    with that MAC address could not be on that link. (For example,
>    there is a layer-2 registration procedure for end stations on that
>    link and the destination MAC address in question is not
>    registered.) This is a local decision. No "error" message will be
>    defined for this condition at this time.
>
> If no particular controversy arises over this in the next two weeks,
we
> will declare it to be the working group consensus.
>
> Thanks,
> Donald & Erik
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

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



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA71dH5J009098 for <[e-mail]>; Tue, 6 Nov 2007 17:39:22 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,381,1188802800"; d="scan'208";a="21046964"
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 06 Nov 2007 17:39:17 -0800
Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 82264238301; Tue,  6 Nov 2007 17:39:17 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 6 Nov 2007 17:39:17 -0800
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: Tue, 6 Nov 2007 17:39:08 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Preview of changes for VLANs, etc.
Thread-Index: Acgg0vKWDtDMre1mRfyg/GBQE1+AQgACdogg
References: <[e-mail]> <[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Russ White" <[e-mail]>
X-OriginalArrivalTime: 07 Nov 2007 01:39:17.0153 (UTC) FILETIME=[027BE910:01C820DF]
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 lA71dH5J009098
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 01:40:13 -0000
Status: RO
Content-Length: 4909

 

> -----Original Message-----
> From: Russ White [mailto:[e-mail]] 
> Sent: Tuesday, November 06, 2007 4:09 PM
> To: Anoop Ghanwani
> Cc: Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > - For ports that support both bridged and TRILL
> >   traffic we have to go with what 802.1 says
> >   (otherwise the traffic won't go through bridges).
> > 
> > Thus far, all RBridge ports are assumed to be 
> > of the last type.  That means the encapsulation has
> > to follow rules defined by 802.1 - i.e. you have
> > a set of VLANs on that port.  We only transmit
> > traffic on those VLANs.  Some of those VLANs belong
> > to the "tagged set" in which case we transmit frames
> > for those VLANs in tagged format; other VLANs belong
> > to the "untagged" set in which case we transmit 
> > frames without a tag.
> 
> In all implementations that I know of, such interfaces are always:
> 
> 1. Trunk ports, which I've already covered.
> 2. A single physical interface with multiple logical "subinterfaces."
> 
> Can you point to a single case where a device can send multiple vlan
> traffic on a single logical interface, or where it treats a single
> interface as a link with multiple vlans while not calling it 
> a "trunk,"
> and putting special operational rules around it (such as no end host
> devices)?

We must be talking past each other because I'm
not sure what the above comment is getting at.
Nowhere have I talked about "multiple VLAN
traffic on a single logical interface".  Please
give me the full context if possible.

By the way, trunk ports in one large, prominent
vendor's implementation is a subset of the 
standard.  The 802.1 document does not talk
about trunk ports at all, and on a given port
you can have any bunch of VLANs, some of which
are tagged and some of which are untagged.  
And this is different that the "trunk port".

> > I think what we have defined so far is fine.
> > There is no need to change it.  Making it optional
> > won't work.
> 
> What has been defined so far is very complex--you're recreating
> subinterfaces without subinterfaces, for no reason I can see.

The subinterfaces are there because an RBridge
is also a bridge.  Just like a bridge has VLANs
configured on ports, an RBridge will also have
VLANs configured on ports.  The reason this is
needed is because we have to know which VLANs
are configured on a port when we receive
a multicast packet from another RBridge that
needs to be forwarded on the port.
 
> > Even routers have to follow those rules or
> > their packets don't make it through the LAN!
> 
> Routers don't follow these rules.... They don't simply put 
> "some random
> vlan number" on any packet they are transmitting to "get the packet
> through the LAN." There is no "common vlan" assigned to each link to
> allow routers to communicate. There is no concept of a "single hello"
> for multiple virtual topologies on a single link, with all sorts of
> stuff added so everyone on the link knows which virtual 
> network everyone
> else is on.

We are not talking about putting a random number.
We are talking about putting some VLAN ID that is
configured on the port.

> Routers operate exactly as I described previously. If a 
> router receives
> a packet on an interface, it will:
> 
> 1. Find the next hop, by looking at the tree.
> 2. Figure out the outbound interface.
> 3. Encap the packet with the correct layer 2 header for that 
> interface.
> 3a. If the outbound interface is a subinterface, the layer 2 
> header will
> include, of course, a vlan header.
> 3b. If the outbound interface is not a subinterface, the 
> layer 2 header
> will not include a vlan header.

I agree with this.
 
> Whether or not there's a vlan tag that needs to be added plays no part
> in the forwarding decision.

That is correct...however, as you note in 3, 3a, 3b,
you have to know the interface that you're forwarding
the packet on.  That interface, in the RBridge world,
is a VLAN on a specific port (for unicast) or a \
VLAN on a set of ports (for multicast).

> IMHO, rbridges _should_ operate as much like routers as 
> possible, rather
> than using some new forwarding paradigm. Once the traffic is 
> placed in a
> tunnel, it should be carried--as much as possible--just like an IP
> packet is carried.

So if I have the following configuration:
(R1) <---(vlan1)---> (R2) <---(vlan1)---> (R3)
the packets between the routers could either
be tagging the frames or not and that depends
on the configuration of the port in question.
(In the implementation you are familiar with,
untagged would mean there is no subinterface,
and tagged means there is a subinterface with
a tag of 1.  Just because I have a subinterface
in the latter case, does not mean another 
subinterface must exist on that router port.)

Anoop 



Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA70nVHZ023145 for <[e-mail]>; Tue, 6 Nov 2007 16:49:31 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,381,1188802800"; d="scan'208";a="413959771"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2007 16:49:31 -0800
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA70nVxw022487;  Tue, 6 Nov 2007 16:49:31 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id lA70nQCL003393; Wed, 7 Nov 2007 00:49:27 GMT
Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 19:49:26 -0500
Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 19:49:25 -0500
Message-ID: <[e-mail]>
Date: Tue, 06 Nov 2007 19:48:49 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Nov 2007 00:49:25.0905 (UTC) FILETIME=[0B8FB010:01C820D8]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15528.002
X-TM-AS-Result: No--6.970200-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1363; t=1194396571; x=1195260571; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Preview=20of=20changes=20for=20VLANs, =20e tc. |Sender:=20; bh=4EnY8HbXOQPR5FgIXtdBDIXEEpDFZk1Nmg2T5lUWQSs=; b=hRM4Bo795DpEEvwBYqqXYWswoOIbdZm1E3J7z3LMUtLw+WWVUUIGVQKcNPstAjyOda+gsL/O +hAR0l2WhD9xzZ96qd+LvhAkndxGTo169YJ/QXa+4+GhSGnN+6heqPcfXn65ef9YCrrHxGe2PN 0kBZJNQOjhpxwJj5TH/WUHc6k=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); 
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] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 00:50:17 -0000
Status: RO
Content-Length: 1349

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> RBridges, on the other hand, like bridges, are simultaneously supporting
> multiple VLANs
> over the same port. VLANs that the RBridge itself is not a member of in
> any sense -- just
> that the RBridge is supposed to support to glue it to other pieces of
> the VLAN in other
> parts of the campus.

Again, the only two instances I know of are:

1. There are subinterfaces, or physical interfaces, which belong to a
single vlan.

2. The port is declared a trunk, and specific rules apply to the port,
such as no end user traffic is allowed on the port.

And I still don't see what any of this has to do with all this
complexity. I've described all the situations in previous emails, and
how to handle them, without the concept of a "common vlan," etc. Again,
why do we need this complexity? What is it supporting? Can someone point
to a specific situation that wouldn't be handled by the forwarding rules
I proposed earlier--that's not contrived, and impossible with all
current implementations?

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMQtxER27sUhU9OQRAoeAAKDx4z6UoUgHVEWSMibQ7Z/sOfknDgCg1+YI
HDaYykz4jypmQnjo9P5KNcU=
=yDY4
-----END PGP SIGNATURE-----


Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA70MfbO016020 for <[e-mail]>; Tue, 6 Nov 2007 16:22:41 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.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, 06 Nov 2007 16:22:41 -0800 (PST)
Received: from [129.150.22.40] ([192.18.43.225]) 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, 06 Nov 2007 16:22:41 -0800 (PST)
Date: Tue, 06 Nov 2007 16:24:08 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Russ White <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
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] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 00:25:10 -0000
Status: RO
Content-Length: 4164

Russ...as much as I share your love of the complexity of VLANs...

I think the reason RBridges are more complicated with the VLAN stuff 
than IP routers are
is that in IP a VLAN is an IP subnet, so a router would only be talking 
on a single VLAN
at a time over a particular port-as-seen-by-IP. If an IP node (whether it be
a router or a logically-multi-link endnode) were on multiple VLANs 
through the
same port, it would be configured so that the higher level software 
wouldn't have
to know anything about that stuff. If an IP node used a single port as 4 
logical ports,
by having each in a different VLAN, then each of those "ports" would be 
associated
with a single VLAN.

RBridges, on the other hand, like bridges, are simultaneously supporting 
multiple VLANs
over the same port. VLANs that the RBridge itself is not a member of in 
any sense -- just
that the RBridge is supposed to support to glue it to other pieces of 
the VLAN in other
parts of the campus.

Radia


Russ White wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>   
>> - For ports that support both bridged and TRILL
>>   traffic we have to go with what 802.1 says
>>   (otherwise the traffic won't go through bridges).
>>
>> Thus far, all RBridge ports are assumed to be 
>> of the last type.  That means the encapsulation has
>> to follow rules defined by 802.1 - i.e. you have
>> a set of VLANs on that port.  We only transmit
>> traffic on those VLANs.  Some of those VLANs belong
>> to the "tagged set" in which case we transmit frames
>> for those VLANs in tagged format; other VLANs belong
>> to the "untagged" set in which case we transmit 
>> frames without a tag.
>>     
>
> In all implementations that I know of, such interfaces are always:
>
> 1. Trunk ports, which I've already covered.
> 2. A single physical interface with multiple logical "subinterfaces."
>
> Can you point to a single case where a device can send multiple vlan
> traffic on a single logical interface, or where it treats a single
> interface as a link with multiple vlans while not calling it a "trunk,"
> and putting special operational rules around it (such as no end host
> devices)?
>
>   
>> I think what we have defined so far is fine.
>> There is no need to change it.  Making it optional
>> won't work.
>>     
>
> What has been defined so far is very complex--you're recreating
> subinterfaces without subinterfaces, for no reason I can see.
>
>   
>> Even routers have to follow those rules or
>> their packets don't make it through the LAN!
>>     
>
> Routers don't follow these rules.... They don't simply put "some random
> vlan number" on any packet they are transmitting to "get the packet
> through the LAN." There is no "common vlan" assigned to each link to
> allow routers to communicate. There is no concept of a "single hello"
> for multiple virtual topologies on a single link, with all sorts of
> stuff added so everyone on the link knows which virtual network everyone
> else is on.
>
> Routers operate exactly as I described previously. If a router receives
> a packet on an interface, it will:
>
> 1. Find the next hop, by looking at the tree.
> 2. Figure out the outbound interface.
> 3. Encap the packet with the correct layer 2 header for that interface.
> 3a. If the outbound interface is a subinterface, the layer 2 header will
> include, of course, a vlan header.
> 3b. If the outbound interface is not a subinterface, the layer 2 header
> will not include a vlan header.
>
> Whether or not there's a vlan tag that needs to be added plays no part
> in the forwarding decision.
>
> IMHO, rbridges _should_ operate as much like routers as possible, rather
> than using some new forwarding paradigm. Once the traffic is placed in a
> tunnel, it should be carried--as much as possible--just like an IP
> packet is carried.
>
> :-)
>
> Russ
>
> - --
> [e-mail] CCIE <>< Grace Alone
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHMQIxER27sUhU9OQRAo51AJ4wilUVzWflNoanrdcX7U/nCtICMwCbBog6
> 50JNAS2hu/otps6EXwSZ4lc=
> =6yb5
> -----END PGP SIGNATURE-----
>   



Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA70CpL3013702 for <[e-mail]>; Tue, 6 Nov 2007 16:12:52 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,381,1188792000"; d="scan'208";a="75333637"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 06 Nov 2007 19:12:51 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA70CgZA025625;  Tue, 6 Nov 2007 19:12:51 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA70Ande021269;  Wed, 7 Nov 2007 00:12:01 GMT
Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 19:09:57 -0500
Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 19:09:57 -0500
Message-ID: <[e-mail]>
Date: Tue, 06 Nov 2007 19:09:21 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Anoop Ghanwani <[e-mail]>
References: <[e-mail]> <[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Nov 2007 00:09:57.0280 (UTC) FILETIME=[87C03200:01C820D2]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15528.002
X-TM-AS-Result: No--5.590500-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3048; t=1194394371; x=1195258371; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Preview=20of=20changes=20for=20VLANs, =20e tc. |Sender:=20 |To:=20Anoop=20Ghanwani=20<[e-mail]>; bh=l6S7dKmm1lCzzd71W4oft5zBYaAK0nOE7FkWDmJXc6s=; b=m1ZDHvf0u0vgKqQ+LyIZ24DRMI1FyJiB+vt3P81dLPWRp1vimq1plpwKr1kKlKbpRCagI+o0 7hdeucnZ+2sy2DT09lYn1audHFlE3iMtQnkG6qYqI6XvQaH+0X3+Qv9a;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); 
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] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2007 00:14:50 -0000
Status: RO
Content-Length: 2996

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> - For ports that support both bridged and TRILL
>   traffic we have to go with what 802.1 says
>   (otherwise the traffic won't go through bridges).
> 
> Thus far, all RBridge ports are assumed to be 
> of the last type.  That means the encapsulation has
> to follow rules defined by 802.1 - i.e. you have
> a set of VLANs on that port.  We only transmit
> traffic on those VLANs.  Some of those VLANs belong
> to the "tagged set" in which case we transmit frames
> for those VLANs in tagged format; other VLANs belong
> to the "untagged" set in which case we transmit 
> frames without a tag.

In all implementations that I know of, such interfaces are always:

1. Trunk ports, which I've already covered.
2. A single physical interface with multiple logical "subinterfaces."

Can you point to a single case where a device can send multiple vlan
traffic on a single logical interface, or where it treats a single
interface as a link with multiple vlans while not calling it a "trunk,"
and putting special operational rules around it (such as no end host
devices)?

> I think what we have defined so far is fine.
> There is no need to change it.  Making it optional
> won't work.

What has been defined so far is very complex--you're recreating
subinterfaces without subinterfaces, for no reason I can see.

> Even routers have to follow those rules or
> their packets don't make it through the LAN!

Routers don't follow these rules.... They don't simply put "some random
vlan number" on any packet they are transmitting to "get the packet
through the LAN." There is no "common vlan" assigned to each link to
allow routers to communicate. There is no concept of a "single hello"
for multiple virtual topologies on a single link, with all sorts of
stuff added so everyone on the link knows which virtual network everyone
else is on.

Routers operate exactly as I described previously. If a router receives
a packet on an interface, it will:

1. Find the next hop, by looking at the tree.
2. Figure out the outbound interface.
3. Encap the packet with the correct layer 2 header for that interface.
3a. If the outbound interface is a subinterface, the layer 2 header will
include, of course, a vlan header.
3b. If the outbound interface is not a subinterface, the layer 2 header
will not include a vlan header.

Whether or not there's a vlan tag that needs to be added plays no part
in the forwarding decision.

IMHO, rbridges _should_ operate as much like routers as possible, rather
than using some new forwarding paradigm. Once the traffic is placed in a
tunnel, it should be carried--as much as possible--just like an IP
packet is carried.

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMQIxER27sUhU9OQRAo51AJ4wilUVzWflNoanrdcX7U/nCtICMwCbBog6
50JNAS2hu/otps6EXwSZ4lc=
=6yb5
-----END PGP SIGNATURE-----


Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id lA6Lwxtc027712 for <[e-mail]>; Tue, 6 Nov 2007 13:58:59 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-2.tower-128.messagelabs.com!1194386338!5926373!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.189.100.102]
Received: (qmail 14455 invoked from network); 6 Nov 2007 21:58:58 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-2.tower-128.messagelabs.com with SMTP; 6 Nov 2007 21:58:58 -0000
Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lA6LwlLN015598 for <[e-mail]>; Tue, 6 Nov 2007 14:58:57 -0700 (MST)
Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id lA6Lwk0f013680 for <[e-mail]>; Tue, 6 Nov 2007 15:58:47 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id lA6LwjB6013672 for <[e-mail]>; Tue, 6 Nov 2007 15:58:46 -0600 (CST)
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: Tue, 6 Nov 2007 16:58:44 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] RBridge: a case of study
thread-index: AcgfwhTUjX8M824DQCWRzJk1fpQ2/AA+nr2w
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "James Carlson" <[e-mail]>
X-CFilter-Loop: Reflected
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 lA6Lwxtc027712
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RBridge: a case of study
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 22:03:54 -0000
Status: RO
Content-Length: 3174

See below at ### 

-----Original Message-----
From: James Carlson [mailto:[e-mail]] 
Sent: Monday, November 05, 2007 10:16 AM
To: Eastlake III Donald-LDE008
Cc: Developing a hybrid router/bridge.
Subject: RE: [rbridge] RBridge: a case of study

Eastlake III Donald-LDE008 writes:
> From: James Carlson [mailto:[e-mail]] 
[...]
> Eric Gray writes:
[...]
> > 2) all frames forwarded from a (physical) port on one RBridge 
> >    to a (physical) port on another RBridge MUST have the same
> >    VID, or 
[...]
> @@@ Well, I am Donald and I meant something like (2) but a bit
narrower.
> I would have said "all TRILL frames" because "all frames" is way too
> inclusive. What about control frames like 802.1AB? Furthermore, in the
> case of point-to-point links between two Rbridges (i.e., no bridges or
> end station connections in between), as far as I can see there is no
> particular utility in considering the TRILL frames to have any
external
> VLAN coloring and certainly no need for them to be outer tagged with a
> VLAN ID or priority.

I mostly agree with that.  In fact, I think that's a desirable end
state for TRILL, when all other bridges are obsolete.  Having no VLAN
tag on the outside makes a lot of sense there.

(I think omitting the priority makes a bit less sense to me, though.
Wouldn't you want the priority value set on an 802.1q header with VLAN
ID 0 in this case?)

### The way I look at it, the VLAN coloring and priority of a frame are
meta data associated with the frame. The priority is used in queuing
decisions related to processing and transmitting the frame. Just what
Q-tag gets put on the transmitted frame depends on configuration.

### If a link is point-to-point between Rbridges, there is no need for
an outer VLAN ID. If it is a data frame, the actual VLAN ID of the data
is in the inner Q-tag and so easily available to the next Rbridge for
its decision processes. Similarly, I don't see any reason for priority
in the outer Q-tag. It's not as if a piece of wire is going to look at
the priority and re-order frames. If it is a data frame, the actual
priority of the data is in the inner Q-tag and so is easily available to
the next Rbridge.

### TRILL core IS-IS frames, of course, are different. They don't have
any inner Q-tag because the don't have any inherent VLAN coloring and
they only go one hop anyway. An Rbridge might want to associate
"priority 7" or whatever as meta data with the core IS-IS frame while it
is internal to the Rbridge and that could effect transmission queuing
but there is no particular reason for there to be a priority tag on it
over a point-to-point link. The next Rbridge will see that it is a core
IS-IS message, will probably treat it a bit differently for processing,
and give it to its core IS-IS instance.

### Thanks,
### Donald

I think the question is how to get there when there are networks that
are half-TRILL and half-otherwise.

...

-- 
James Carlson, Solaris Networking              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA6Lv7x4027216 for <[e-mail]>; Tue, 6 Nov 2007 13:57:07 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,380,1188802800"; d="scan'208";a="21037711"
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 06 Nov 2007 13:57:07 -0800
Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 58057238301; Tue,  6 Nov 2007 13:57:07 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 6 Nov 2007 13:57:07 -0800
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: Tue, 6 Nov 2007 13:56:58 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Preview of changes for VLANs, etc.
Thread-Index: Acggs+b1aiiEWhfOQ/WV9vfElWKVmgACoM3Q
References: <[e-mail]> <[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Russ White" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 06 Nov 2007 21:57:07.0949 (UTC) FILETIME=[F9A8C9D0:01C820BF]
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 lA6Lv7x4027216
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 21:57:38 -0000
Status: RO
Content-Length: 2124

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Russ White
> Sent: Tuesday, November 06, 2007 12:15 PM
> To: Radia Perlman
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > Certainly I'd love to get rid of the outer VLAN tag. Unfortunately, 
> > bridges on the link can be configured in weird ways such 
> that the only 
> > way to send a packet is using a particular set of VLAN tags. Then 
> > there are other complicated issues,
> 
> Since this is probably going to be 5% or less of the cases, 
> we should make this capability optional, and make the 95% 
> case the simpler case of sending with no vlan tag. The only 
> case this really arises in is when you have hosts on links 
> with through traffic, which any good network designer avoids 
> like the plague.
> 
> I'd rather not make this whole thing really complicated just 
> to support a small set of networks....

It's not that simple...again back to terminology:

- For ports that support only bridged traffic 802.1
  defines what they should do.
- For ports that support only TRILL traffic, we
  get to define how they operate (within some limits
  since we may still see link-local control traffic).
- For ports that support both bridged and TRILL
  traffic we have to go with what 802.1 says
  (otherwise the traffic won't go through bridges).

Thus far, all RBridge ports are assumed to be 
of the last type.  That means the encapsulation has
to follow rules defined by 802.1 - i.e. you have
a set of VLANs on that port.  We only transmit
traffic on those VLANs.  Some of those VLANs belong
to the "tagged set" in which case we transmit frames
for those VLANs in tagged format; other VLANs belong
to the "untagged" set in which case we transmit 
frames without a tag.

I think what we have defined so far is fine.
There is no need to change it.  Making it optional
won't work.

Even routers have to follow those rules or
their packets don't make it through the LAN!

Anoop



Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA6Lag0q020184 for <[e-mail]>; Tue, 6 Nov 2007 13:36:42 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,380,1188802800"; d="scan'208";a="543853813"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2007 13:36:42 -0800
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA6LafGD001546;  Tue, 6 Nov 2007 16:36:41 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA6LaXdQ017542;  Tue, 6 Nov 2007 21:36:33 GMT
Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 16:36:33 -0500
Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 16:36:32 -0500
Message-ID: <[e-mail]>
Date: Tue, 06 Nov 2007 16:35:56 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Eastlake III Donald-LDE008 <[e-mail]>
References: <[e-mail]> <[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Nov 2007 21:36:32.0967 (UTC) FILETIME=[198D7D70:01C820BD]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15528.002
X-TM-AS-Result: No--6.031600-8.000000-4
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1285; t=1194385001; x=1195249001; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Preview=20of=20changes=20for=20VLANs, =20e tc. |Sender:=20 |To:=20Eastlake=20III=20Donald-LDE008=20<[e-mail]>;  bh=s+03hPhaMkBdIHWeDFYDlyzaQg4iKFsz698EyPIGd30=; b=nQyeROVr0bjXRiafShbocCbP98MF5qm08oiDe5SFX2tE3YEz65nrSJUSgzf5YxzoHo4xoKr7 du4S4OjGXMQeKXKQcbW3fugUWd1ySDmdlO4bu7qWs+lhOvJZvEO+5Hov;
Authentication-Results: rtp-dkim-2; header.From=[e-mail]; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); 
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] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 21:37:55 -0000
Status: RO
Content-Length: 1277

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 	So, while I'm fine with noticing/configuring point-to-point
> Rbridge links and omitting the outer VLAN tag on them, since it pretty
> much serves no function, you want a scheme that has a reasonable chance
> of working if a link is a complex bridged LAN.

I'm not certain I can see where always putting an outer vlan tag on a
packet will really help on a mixed bridge/rbridge link.... You would
have the bridges configured with a bunch of subinterfaces, one for each
vlan, and you'd configure the rbridges the same way, I think. I don't
think it's useful to expect the rbridges to autodetect all the possible
vlans on the link, and try to sort out what the user normally sorts out
through manual configuration anyway.

The only other situation is an rbridge connected to a normal bridge
through a trunk port--but this would normally be a p-2-p link, so I
think the rules I suggested earlier would work in this situation.

:-)

Russ


- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMN48ER27sUhU9OQRAreFAKCZdYxmCdnCghiEelIXAhz8MRD74gCfS8Hg
yZHFWRD1wxz5auExfZmg+uM=
=WAk/
-----END PGP SIGNATURE-----


Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id lA6LVQhl018529 for <[e-mail]>; Tue, 6 Nov 2007 13:31:30 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-12.tower-119.messagelabs.com!1194384685!32429816!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 9485 invoked from network); 6 Nov 2007 21:31:25 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-119.messagelabs.com with SMTP; 6 Nov 2007 21:31:25 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lA6LVP6J020864 for <[e-mail]>; Tue, 6 Nov 2007 14:31:25 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lA6LVOsl010418 for <[e-mail]>; Tue, 6 Nov 2007 15:31:24 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lA6LVNDN010410 for <[e-mail]>; Tue, 6 Nov 2007 15:31:24 -0600 (CST)
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: Tue, 6 Nov 2007 16:31:22 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Preview of changes for VLANs, etc.
thread-index: Acggs4/qqBtgY8v5TCizg/wiv/jc6AABzJMw
References: <[e-mail]> <[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Russ White" <[e-mail]>
X-CFilter-Loop: Reflected
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 lA6LVQhl018529
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 21:31:43 -0000
Status: RO
Content-Length: 2210

The big problem is incremental deployment. Sure, looking at existing
802.3 bridged networks, you almost never have links with both bridges
and end station on them. But with incremental deployment of Rbridges, a
bridged LAN between N Rbridges will commonly look like a through link
that also has end stations on it. And furthermore, it can easily be a
link between these N Rbridges with odd, VLAN dependent connectivity.
Some people in the working group consider the mixed bridges and Rbridges
case very important.
	So, while I'm fine with noticing/configuring point-to-point
Rbridge links and omitting the outer VLAN tag on them, since it pretty
much serves no function, you want a scheme that has a reasonable chance
of working if a link is a complex bridged LAN.

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Russ White
Sent: Tuesday, November 06, 2007 3:15 PM
To: Radia Perlman
Cc: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Preview of changes for VLANs, etc.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> Certainly I'd love to get rid of the outer VLAN tag. Unfortunately,
> bridges on the link
> can be configured in weird ways such that the only way to send a
packet
> is using a
> particular set of VLAN tags. Then there are other complicated issues,

Since this is probably going to be 5% or less of the cases, we should
make this capability optional, and make the 95% case the simpler case of
sending with no vlan tag. The only case this really arises in is when
you have hosts on links with through traffic, which any good network
designer avoids like the plague.

I'd rather not make this whole thing really complicated just to support
a small set of networks....

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMMswER27sUhU9OQRAsoPAJ9BLiR9MOpIeoZr7O2IZ0+Dt4wEGwCcCsSz
L4dMGZWmOWwpkh+nJH2RPrY=
=PgGG
-----END PGP SIGNATURE-----
_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA6Kfks8028598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 6 Nov 2007 12:41:46 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id lA6Kg4Go027535; Tue, 6 Nov 2007 14:42:04 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 14:41:44 -0600
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: Tue, 6 Nov 2007 14:41:43 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Preview of changes for VLANs, etc.
Thread-Index: AcggrSAEXMvz8VppTQmD3WdqZPTrKwAAVxLw
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Russ White" <[e-mail]>
X-OriginalArrivalTime: 06 Nov 2007 20:41:44.0361 (UTC) FILETIME=[71640990:01C820B5]
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 lA6Kfks8028598
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 20:43:44 -0000
Status: RO
Content-Length: 3530

Radia,

	What gets us wrapped around the axle is attemtping to
specify things in such a way that we have to care about the
VLAN tag used in RBridge-to-RBridge forwarding.  The point
to using logical interfaces - or virtualization - is to hide
network complexity.  Trying to "unroll it" is not making it
simpler.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]] 
> Sent: Tuesday, November 06, 2007 12:35 PM
> To: Russ White
> Cc: Eric Gray; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> 
> Certainly I'd love to get rid of the outer VLAN tag. Unfortunately, 
> bridges on the link can be configured in weird ways such that the
> only way to send a packet is using a particular set of VLAN tags.
> Then there are other complicated issues, like finding which VLAN
> tag works for which neighbors. And then if you form an adjacency 
> with each neighbor via a potentially different (set of) VLAN tags,
> then how would you send multicast on a link? There wouldn't be
> guaranteed to be a single VLAN tag that would reach everyone on
> the link.
> 
> So the proposal is to use a single, unpartitioned VLAN tag for 
> communication on the link, and if anyone can't talk to the DRB on
> that link using the VLAN tag that the DRB specifies, then they
> basically can't use the link. 
>
> If "which VLAN number" is configurable, then we have to deal with
> different configurations in different RBridges, which we do by
> having the DRB inform all the other RBridges what VLAN tag to
> use.
> 
> Radia
> 
> 
> Russ White wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> >   
> >> - but without explicitly forbidding the use of a VLAN tag in 
> >> the link-level encapsulation required to get a frame from one
> >> RBridge to another.
> >>     
> >
> > Sure--If the only way to reach the next hop is through a 
> vlan, then you
> > would need to encap in that vlan to get to the next hop. I think the
> > cleanest way to do this is:
> >
> > 1. Receive packet.
> > 2. Look up exit rbridge.
> > 3. Find next hop to the exit.
> > 4. Look at the outbound interface towards this next hop.
> > 5. If the outbound interface is a 1q interface (logical, rather than
> > physical), then encap with the inside vlan stuff, then the tunnel
> > header, then put it in another tunnel header, with the destination
> > address being the next hop, and the vlan stuff being the 
> correct one to
> > reach that next hop.
> > 6. If the outbound interface is not a 1q interface (physical, rather
> > than logical), then encap with the vlan stuff, then the 
> tunnel header
> > for the outer edge rbridge (egress rbridge), and forward it.
> >
> > When the next hop receives the packet in the case of #5, it 
> will see the
> > packet is to it, strip the outer header, and then see the 
> inner tunnel,
> > and forward the packet according to local rules, based on it's tree,
> > etc. I think this is much simpler than having a "set" vlan 
> on any given
> > link, or having to carry around a set of vlans you forward 
> for, and such.
> >
> > :-)
> >
> > Russ
> >
> > - --
> > [e-mail] CCIE <>< Grace Alone
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFHMJOgER27sUhU9OQRAmPPAJ9QC7qUavulxDpa5am4RxbTUBJ38gCdGFc9
> > RfgcEqMnZgWPpnAh+RRwy0k=
> > =//s3
> > -----END PGP SIGNATURE-----
> >   
> 
> 



Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA6KKYZe020168 for <[e-mail]>; Tue, 6 Nov 2007 12:20:34 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,380,1188802800"; d="scan'208";a="30581359"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 06 Nov 2007 12:20:24 -0800
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA6KKN7F030626;  Tue, 6 Nov 2007 15:20:23 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA6KKNdS011193;  Tue, 6 Nov 2007 20:20:23 GMT
Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 15:20:19 -0500
Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 15:20:19 -0500
Message-ID: <[e-mail]>
Date: Tue, 06 Nov 2007 15:19:43 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Nov 2007 20:20:19.0576 (UTC) FILETIME=[73996780:01C820B2]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15528.002
X-TM-AS-Result: No--7.805800-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1875; t=1194380423; x=1195244423; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Can=20we=20ever=20have=20pt-to-pt=20links ? |Sender:=20 |To:=20Radia=20Perlman=20<[e-mail]>; bh=PTfhmlr8V+g8/qthFXLp/B9cr/Lt2Vdl8yyuzsI3AAk=; b=JTTYULqYnnQjCUnBaXFo3q0ixQvU/uU5b2v1QqJEysxgEMh+d9n8vkBrlQ0KwrubR/+xOsWV i4gNwr9nGZgWsxnb+TMSDXVyQgk61UVCmX0YXvceZfuSGkAG/wAcLoEz;
Authentication-Results: rtp-dkim-2; header.From=[e-mail]; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); 
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] Can we ever have pt-to-pt links?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 20:21:23 -0000
Status: RO
Content-Length: 1857

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> I'm going to ask on the IS-IS list. Manual configuration is actually
> scarier (and harder) because different
> RBridges can be configured differently. With this proposal (the DRB

I'm pretty certain the worst that is going to have with two ends
configured differently is that the link won't be used for transit. One
end will be transmitting a pnode, but the other end won't be advertising
a connection to it--instead, it will be advertising a connection to the
other is on the link. This means the twcc won't work, and the tree won't
build through that link.

The only other possibility is that the link could be configured for
p-2-p, while there are actually three devices on it. A good
implementation would shut down all adj's on such a link, but that's
implementation specific, though perhaps we should have suggested in the
p-2-p draft.... Even if it tries to form, the twcc across the 0 cost
backlinks to the pnode are going to cause the tree to fail to build
through the link, I think. It might build for the pair that do build an
adjacency, but the third is on the link will just be left out in
everyone else's tree.....

Hence, I think the manual configuration option is pretty safe.... And,
the protocol can't tell if the link was intended to be a p-2-p or not.
If you have a link with three is', and one fails, auto detecting the
link has now become p-2-p makes everyone in the domain run SPF. If you
don't do the auto-detection, they can run a partial, just slicing off
the link that failed.

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMMxfER27sUhU9OQRAkiiAJ0TVIpBTMINkn8xvYm5+5njibqlywCdF+u7
27otCI2fnWz1MQXz0tAVv6o=
=z9eC
-----END PGP SIGNATURE-----


Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA6KFflD018280 for <[e-mail]>; Tue, 6 Nov 2007 12:15:41 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,380,1188802800"; d="scan'208";a="14873081"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 06 Nov 2007 12:15:40 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA6KFeZl019362;  Tue, 6 Nov 2007 12:15:40 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lA6KF1Qa015507; Tue, 6 Nov 2007 20:15:40 GMT
Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 15:15:16 -0500
Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 15:15:16 -0500
Message-ID: <[e-mail]>
Date: Tue, 06 Nov 2007 15:14:40 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Nov 2007 20:15:16.0530 (UTC) FILETIME=[BEF84120:01C820B1]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15528.002
X-TM-AS-Result: No--7.763300-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1024; t=1194380140; x=1195244140; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Preview=20of=20changes=20for=20VLANs, =20e tc. |Sender:=20; bh=YkVc28GMtVfIscspp3vGcLHpdNcnoWGMwiEnmXnWnrE=; b=sMcyviUVsDv50NbOWUH1qbReIElVP420VVn/J+JaMng0KiQenh01Obj9lIdhb3+YfzoATY9D 4cd4ZHWRPwhbugJ3GrngrPul5IJlZzQIZqfNZGiTXwzVgfB2juFkXCzj;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); 
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] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 20:16:09 -0000
Status: RO
Content-Length: 1019

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> Certainly I'd love to get rid of the outer VLAN tag. Unfortunately,
> bridges on the link
> can be configured in weird ways such that the only way to send a packet
> is using a
> particular set of VLAN tags. Then there are other complicated issues,

Since this is probably going to be 5% or less of the cases, we should
make this capability optional, and make the 95% case the simpler case of
sending with no vlan tag. The only case this really arises in is when
you have hosts on links with through traffic, which any good network
designer avoids like the plague.

I'd rather not make this whole thing really complicated just to support
a small set of networks....

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMMswER27sUhU9OQRAsoPAJ9BLiR9MOpIeoZr7O2IZ0+Dt4wEGwCcCsSz
L4dMGZWmOWwpkh+nJH2RPrY=
=PgGG
-----END PGP SIGNATURE-----


Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA6JpkN9008769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 6 Nov 2007 11:51:47 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id lA6Jq5vR006303; Tue, 6 Nov 2007 13:52:05 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 13:51:45 -0600
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: Tue, 6 Nov 2007 13:51:42 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Can we ever have pt-to-pt links?
Thread-Index: AcggojL8gIFcNHzXSO2LubrbcmaeLwACb8MA
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]><[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Russ White" <[e-mail]>
X-OriginalArrivalTime: 06 Nov 2007 19:51:45.0454 (UTC) FILETIME=[75E724E0:01C820AE]
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 lA6JpkN9008769
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Can we ever have pt-to-pt links?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 19:52:30 -0000
Status: RO
Content-Length: 4136

Radia,

	I think taking this to the IS-IS mailing list is a great idea.
I'd hate to think we were trying to "fix" something to do with IS-IS
generally, in this working group.

	However, as a general observation, the argument that putting
complexity into protocol - to avoid some types of configuration
errors - is often used, and frequently either wrong or irrelevant.

	As the paraphrased saying goes, people who think anything can 
be made proof against configuration error are under-estimating the
ability, inventiveness and - possibly - evil intentions of the person 
doing the configuration.

	Also, in many cases, it is better for a misconfigured network
to not work at all, than it is to have it working in some unexpected
way.

	In my opinion, implementers want to build equipment that 
behaves reasonably under misconfigured operating conditions, and
that may simply mean that it doesn't fail in some spectacular way.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Radia Perlman
> Sent: Tuesday, November 06, 2007 12:44 PM
> To: Russ White
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Can we ever have pt-to-pt links?
> 
> I'm going to ask on the IS-IS list. Manual configuration is actually 
> scarier (and harder) because different RBridges can be configured 
> differently. With this proposal (the DRB switches over to pseudonode
> once there are, say, 3 other RBridges on the link, and perhaps stays
> that way forever, or until there is ever a time when there is just 
> one (or zero) RBridge neighbors.
>
> It's not disruptive to take away the pseudonode when there are very
> few neighbors, since the coming or going of an RBridge neighbor would
> require reissuing the pseudonode LSP anyway. So if there were three
> guys, R1, R2, and R3, with pseudonode R1.x, then if R3 went away, and
> we kept the pseudonode, then the pseudonode (R1.x) would reissue its
> LSP saying it now had just two neighbors (R1 and R2), whereas if R1 
> decided to go with "no pseudonode now", then R1 would change its
> Hello to be "no pseudonode", and R1 and R2 would reissue their LSPs 
> to say their only neighbor was each other (R1 would remove R1.x as a
> neighbor and say it is connected to R2....similarly R2).
> 
> There is no confusion about whether or not there is a pseudonode
> because the DRB decides.
>
> The exact algorithm for deciding doesn't have to be standardized even,

> though we certainly should recommend something.
> 
> Radia
> 
> 
> 
> 
> Russ White wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> >   
> >>> The only thing special we were doing with the pseudonode 
> was reporting
> >>> the bridge root.
> >>> So that means that R1, the DRB, would report the root 
> bridge ID in its
> >>> LSP if
> >>> R1 has decided not to create a pseudonode.
> >>>
> >>>       
> >> Actually, let me change that to: "Let's always report the 
> root bridge ID
> >> in the DRB's
> >> LSP, not the pseudonode LSP"
> >>
> >> So I'm getting more comfortable with that proposal -- the DRB only
> >> declares a pseudonode
> >> if there really are too many neighbors, and switching over from
> >> non-pseudonode to
> >> pseudnode is really not very disruptive.
> >>     
> >
> > In most implementations of IS-IS, there is a way to 
> manually configured
> > a link as point-to-point, no matter what the layer 2 part 
> of the device
> > thinks it is. The IS-IS WG pretty much eschewed 
> auto-detection schemes
> > when we went through this exercise.
> >
> > :-)
> >
> > Russ
> >
> > - --
> > [e-mail] CCIE <>< Grace Alone
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFHMHu0ER27sUhU9OQRAgyEAKC3ic9tS1kROaWxVSWuwnrr2HUh9gCeJJss
> > wNbLsz14yV/oQ3FCO6Xh2Pg=
> > =vYAd
> > -----END PGP SIGNATURE-----
> >   
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA6J6DYY018275 for <[e-mail]>; Tue, 6 Nov 2007 11:06:13 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.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, 06 Nov 2007 11:06:09 -0800 (PST)
Received: from [129.150.22.40] ([192.18.43.225]) 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, 06 Nov 2007 11:06:09 -0800 (PST)
Date: Tue, 06 Nov 2007 11:07:37 -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=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Can we ever have pt-to-pt links?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 19:06:38 -0000
Status: RO
Content-Length: 1952

FYI: This is the proposal I'm running by the IS-IS list. Summary: DRB 
chooses whether
or not to create a pseudonode on the port, and tells the other RBridges 
whether to
claim pt-to-pt links to the other RBridges on the link, or attachment to 
a pseudonode.
Algorithm: if R1 has zero or one RBridge neighbor, no pseudonode. If R1 has
4 or more RBridge neighbors, R1 creates pseudonode for the port. If R1 
has 2 o3
3 RBridge neighbors, R1 leaves the state of the link (pseudonode or not) 
alone.

**********************************

a) perform normal DR election. If R1 is the only router, R1 is the DR. 
Assuming there
are other routers on the link, say R1, R2, R3, and R4, let's say R1 is 
the DR.

b) R1 (DR) is the one that decides on behalf of the link whether there will
be a pseudonode or not.
R1 has some algorithm for deciding if there should be a pseudonode. In 
R1's Hello
it says "the name of the pseudonode is R1.x", which means that there 
will be a pseudonode.
The other routers issue LSPs claiming to be connected to R1.x. 
However....if R1
decides not to have a pseudonode, then R1's Hello says "the name of the 
pseudonode is 0"
in which case any routers on the link claim the other routers on the 
link as direct neighbors.

c) a reasonable strategy for DR R1 to decide when to have a pseudonode: 
If R1 has zero or
one router neighbors on the link, R1 puts the link into "no pseudonode" 
mode.
If R1 has at least 4 router neighbors, R1 puts the link into 
"pseudonode" mode.
If R1 has 2 or 3 router neighbors, R1 does not change the state of the 
link. (so 3 router
neighbors have to come up or go down before R1 switches the link between 
pseudonode
vs no pseudonode).

d) if you aren't DR, then you do as you are told.

I believe this proposal is
1) zero configuration
2) safe
3) simple
4) not disruptive if a router is going up and down
5) no danger of confusion
6) much more efficient than creating a pseudonode for every port


Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA6HgdXQ016709 for <[e-mail]>; Tue, 6 Nov 2007 09:42:39 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.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, 06 Nov 2007 09:42:39 -0800 (PST)
Received: from [129.150.22.40] ([192.18.43.225]) 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, 06 Nov 2007 09:42:38 -0800 (PST)
Date: Tue, 06 Nov 2007 09:44:07 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Russ White <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
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] Can we ever have pt-to-pt links?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 17:43:21 -0000
Status: RO
Content-Length: 2557

I'm going to ask on the IS-IS list. Manual configuration is actually 
scarier (and harder) because different
RBridges can be configured differently. With this proposal (the DRB
switches over to pseudonode once there are, say, 3 other RBridges on the 
link, and perhaps
stays that way forever, or until there is ever a time when there is just 
one (or zero) RBridge neighbors.
It's not disruptive to take away the pseudonode when there are very few 
neighbors, since
the coming or going of an RBridge neighbor would require reissuing the 
pseudonode LSP
anyway. So if there were three guys, R1, R2, and R3, with pseudonode 
R1.x, then if
R3 went away, and we kept the pseudonode, then the pseudonode (R1.x) 
would reissue its
LSP saying it now had just two neighbors (R1 and R2), whereas if R1 
decided to
go with "no pseudonode now", then R1 would change its Hello to be "no 
pseudonode",
and R1 and R2 would reissue their LSPs to say their only neighbor was 
eachother (R1 would
remove R1.x as a neighbor and say it is connected to R2....similarly R2).

There is no confusion about whether or not there is a pseudonode because 
the DRB decides.
The exact algorithm for deciding doesn't have to be standardized even, 
though we certainly
should recommend something.

Radia




Russ White wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>   
>>> The only thing special we were doing with the pseudonode was reporting
>>> the bridge root.
>>> So that means that R1, the DRB, would report the root bridge ID in its
>>> LSP if
>>> R1 has decided not to create a pseudonode.
>>>
>>>       
>> Actually, let me change that to: "Let's always report the root bridge ID
>> in the DRB's
>> LSP, not the pseudonode LSP"
>>
>> So I'm getting more comfortable with that proposal -- the DRB only
>> declares a pseudonode
>> if there really are too many neighbors, and switching over from
>> non-pseudonode to
>> pseudnode is really not very disruptive.
>>     
>
> In most implementations of IS-IS, there is a way to manually configured
> a link as point-to-point, no matter what the layer 2 part of the device
> thinks it is. The IS-IS WG pretty much eschewed auto-detection schemes
> when we went through this exercise.
>
> :-)
>
> Russ
>
> - --
> [e-mail] CCIE <>< Grace Alone
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHMHu0ER27sUhU9OQRAgyEAKC3ic9tS1kROaWxVSWuwnrr2HUh9gCeJJss
> wNbLsz14yV/oQ3FCO6Xh2Pg=
> =vYAd
> -----END PGP SIGNATURE-----
>   



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA6HXjTE012374 for <[e-mail]>; Tue, 6 Nov 2007 09:33:45 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.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, 06 Nov 2007 09:33:31 -0800 (PST)
Received: from [129.150.22.40] ([192.18.43.225]) 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, 06 Nov 2007 09:33:31 -0800 (PST)
Date: Tue, 06 Nov 2007 09:34:55 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Russ White <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
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] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 17:34:04 -0000
Status: RO
Content-Length: 2747

Certainly I'd love to get rid of the outer VLAN tag. Unfortunately, 
bridges on the link
can be configured in weird ways such that the only way to send a packet 
is using a
particular set of VLAN tags. Then there are other complicated issues, 
like finding which
VLAN tag works for which neighbors. And then if you form an adjacency 
with each
neighbor via a potentially different (set of) VLAN tags, then how would 
you send multicast on
a link? There wouldn't be guaranteed to be a single VLAN tag that would 
reach everyone on
the link.

So the proposal is to use a single, unpartitioned VLAN tag for 
communication on
the link, and if anyone can't talk to the DRB on that link using the 
VLAN tag that the
DRB specifies, then they basically can't use the link. If "which VLAN 
number" is
configurable, then we have to deal with different configurations in 
different RBridges,
which we do by having the DRB inform all the other RBridges what VLAN tag to
use.

Radia


Russ White wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>   
>> - but without explicitly forbidding the use of a VLAN tag in 
>> the link-level encapsulation required to get a frame from one
>> RBridge to another.
>>     
>
> Sure--If the only way to reach the next hop is through a vlan, then you
> would need to encap in that vlan to get to the next hop. I think the
> cleanest way to do this is:
>
> 1. Receive packet.
> 2. Look up exit rbridge.
> 3. Find next hop to the exit.
> 4. Look at the outbound interface towards this next hop.
> 5. If the outbound interface is a 1q interface (logical, rather than
> physical), then encap with the inside vlan stuff, then the tunnel
> header, then put it in another tunnel header, with the destination
> address being the next hop, and the vlan stuff being the correct one to
> reach that next hop.
> 6. If the outbound interface is not a 1q interface (physical, rather
> than logical), then encap with the vlan stuff, then the tunnel header
> for the outer edge rbridge (egress rbridge), and forward it.
>
> When the next hop receives the packet in the case of #5, it will see the
> packet is to it, strip the outer header, and then see the inner tunnel,
> and forward the packet according to local rules, based on it's tree,
> etc. I think this is much simpler than having a "set" vlan on any given
> link, or having to carry around a set of vlans you forward for, and such.
>
> :-)
>
> Russ
>
> - --
> [e-mail] CCIE <>< Grace Alone
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHMJOgER27sUhU9OQRAmPPAJ9QC7qUavulxDpa5am4RxbTUBJ38gCdGFc9
> RfgcEqMnZgWPpnAh+RRwy0k=
> =//s3
> -----END PGP SIGNATURE-----
>   



Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA6GITXF015480 for <[e-mail]>; Tue, 6 Nov 2007 08:18:30 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,378,1188802800"; d="scan'208";a="413804461"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2007 08:18:29 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lA6GISaC011898;  Tue, 6 Nov 2007 08:18:28 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lA6GIHw2019062; Tue, 6 Nov 2007 16:18:28 GMT
Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 11:18:12 -0500
Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 11:18:11 -0500
Message-ID: <[e-mail]>
Date: Tue, 06 Nov 2007 11:17:36 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Eric Gray <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Nov 2007 16:18:11.0822 (UTC) FILETIME=[A06210E0:01C82090]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15528.002
X-TM-AS-Result: No--2.594100-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1676; t=1194365908; x=1195229908; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Preview=20of=20changes=20for=20VLANs, =20e tc. |Sender:=20; bh=RnfHc/Mw9w/zYenh/SDFtHcB7k1zBcoMApMRnaj73KY=; b=etqYAHzh0Sf9/f36plXigIvIf8IFe63HE63Z6gsmr/+FRbLEDgZjXkL7yL7/QpjIdpqtyR7Q x+UTFMlfYALFK/vmdjFlD1j8KdzKF8WxN/jafzLyCgdmNQiG6LbpwwaO;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, [e-mail]
Subject: Re: [rbridge] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 16:20:01 -0000
Status: RO
Content-Length: 1659

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> - but without explicitly forbidding the use of a VLAN tag in 
> the link-level encapsulation required to get a frame from one
> RBridge to another.

Sure--If the only way to reach the next hop is through a vlan, then you
would need to encap in that vlan to get to the next hop. I think the
cleanest way to do this is:

1. Receive packet.
2. Look up exit rbridge.
3. Find next hop to the exit.
4. Look at the outbound interface towards this next hop.
5. If the outbound interface is a 1q interface (logical, rather than
physical), then encap with the inside vlan stuff, then the tunnel
header, then put it in another tunnel header, with the destination
address being the next hop, and the vlan stuff being the correct one to
reach that next hop.
6. If the outbound interface is not a 1q interface (physical, rather
than logical), then encap with the vlan stuff, then the tunnel header
for the outer edge rbridge (egress rbridge), and forward it.

When the next hop receives the packet in the case of #5, it will see the
packet is to it, strip the outer header, and then see the inner tunnel,
and forward the packet according to local rules, based on it's tree,
etc. I think this is much simpler than having a "set" vlan on any given
link, or having to carry around a set of vlans you forward for, and such.

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMJOgER27sUhU9OQRAmPPAJ9QC7qUavulxDpa5am4RxbTUBJ38gCdGFc9
RfgcEqMnZgWPpnAh+RRwy0k=
=//s3
-----END PGP SIGNATURE-----


Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA6FnMwj003919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 6 Nov 2007 07:49:22 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id lA6Fn9rR032723; Tue, 6 Nov 2007 09:49:40 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 09:49:19 -0600
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: Tue, 6 Nov 2007 09:49:18 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Preview of changes for VLANs, etc.
Thread-Index: AcggiMuKbIx3P2GpSaKky5XKdRw5HAAA0XMg
References: <[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Russ White" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 06 Nov 2007 15:49:19.0482 (UTC) FILETIME=[97D3F5A0:01C8208C]
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 lA6FnMwj003919
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 15:49:58 -0000
Status: RO
Content-Length: 4433

Russ,

	I think you have made a very valid point, here.  I would
like to qualify it somewhat by saying that we should specify 
this as the default behavior - for the exact reason you state
- but without explicitly forbidding the use of a VLAN tag in 
the link-level encapsulation required to get a frame from one
RBridge to another.

	It's important to remember that VLAN tags may be used to
"virtualize" a LAN (link) and it may be the case that a VID is
mandated for some other reason.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Russ White
> Sent: Tuesday, November 06, 2007 9:33 AM
> To: [e-mail]
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > a) all RBridges on a link can talk to each other using a 
> single (outer) VLAN tag, and
> > that VLAN is not allowed to be partitioned. If it is, 
> whichever RBridges can't talk
> > to the DRB on that VLAN are just orphaned. All the other 
> RBridges send IS-IS
> > messages (Hellos, LSPs, CSNPs) on that link tagged with the 
> one VLAN tag.
> 
> Why have this vlan tag at all? If the traffic for any given vlan is
> tunneled to the outer edge using the direct layer 2 address 
> of the exit
> rbridge, then the "outer" vlan tag is an unnecessary complication. The
> simpler rule would be the only traffic on link which should 
> have a vlan
> tag will be that originating from a non-rbridge device. Once traffic
> hits the first rbridge, there should never be an "outer" vlan 
> tag, just
> the destination address in the outer tunnel header.
> 
> All the other stuff you talk about seems to be much easier 
> without this
> outer header--the way IS-IS runs, the DIS election on each link,
> forwarding, etc.
> 
> > f) Hellos shouldn't have to be bigger with this proposal. 
> What's in a Hello?
> > . my ID
> > . my priority for becoming DRB
> > . name of the pseudonode if I am DRB
> > . VLAN tag "V" to use for outer VLAN tag on this cloud if I am DRB
> > . set of neighbors I've heard Hellos from on the specified
> > VLAN tag (V)
> > . flag "please send CSNP" used when starting up, to ensure that
> > you have synchronized LSP databases with your neighbors
> > 
> > Now there might also be the following in the Hello:
> > . "Bidding for VLANs": If I'm not DRB, set of (priority, 
> {set of VLAN tags}) that I would like
> > to be assigned to en/decapsulate for
> 
> This does make the hello larger. Probably much larger....
> 
> > . "VLAN assignments" If I am DRB, en/decapsulator 
> assignments, of the form
> > (RBridge neighbor ID, {set of VLANs}) that I want that RBridge
> > to encapsulate/decapsulate for.
> 
> I don't understand why we need this.... I don't think you're really
> going to have a case where a single interface on the user side
> "services" multiple vlans, which are generally separated at the edge
> through virtual interfaces on the box. IE, if I receive a packet on
> interface ethernet 1.1, then it's vlan x, if it's on ethernet 
> 1.2, then
> it's vlan y. There's no reason not to stick with this convention--the
> chipsets already know how to separate things this way, I think.
> 
> IE, forwarding would look like this:
> 
> 1. Receive packet on interface X.
> 2. Check to see if there's a 1q header.
> 3. If so, then look up appropriate edge destination, encap in 
> a tunnel,
> and resend.
> 3. If not, then find correct vlan, look up appropriate edge 
> destination,
> place vlan header on packet, encap in tunnel, and resend.
> 
> On the receiving side, you just strip off mac headers and process them
> normally. There's no need for special processing of any type, 
> is there?
> 
> I don't see anything about the "merging" vlans 
> automatically.... I don't
> think this should be done, in any case.
> 
> :-)
> 
> Russ
> 
> - --
> [e-mail] CCIE <>< Grace Alone
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFHMHswER27sUhU9OQRAkk+AKDf3LMTQCXPCL3Z7vNy5mmZT9c7bgCfbldB
> RYbmkapg1cE1sSlsgQNVneQ=
> =1x27
> -----END PGP SIGNATURE-----
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA6Fd5Db000345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 6 Nov 2007 07:39:05 -0800 (PST)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id lA6FdNHm028427; Tue, 6 Nov 2007 09:39:23 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 09:39:04 -0600
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: Tue, 6 Nov 2007 09:39:03 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Can we ever have pt-to-pt links?
Thread-Index: AcggQMJ+9MY4Rf2ASa2QNcxaPzgqtAASF8Rg
References: <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 06 Nov 2007 15:39:04.0499 (UTC) FILETIME=[29450030:01C8208B]
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 lA6Fd5Db000345
Subject: Re: [rbridge] Can we ever have pt-to-pt links?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 15:40:27 -0000
Status: RO
Content-Length: 3167

Radia,

The usual approach to specifying the (optimized) behavior you 
describe would be to say something like:

"An implementation MAY be aware that a specific link is point-to-
 point, in which case <the DRB election process> MAY be omitted."

However, it is worth realizing that this relies on a common view
at both ends of the point-to-point link.  What happens if one end
tries to perform a DRB election and the other does not?

It then becomes necessary to specify the behavior in this case.

I suspect that - if one has valid reasons to think that a link is 
point-to-point - one might configure both ends to assume this is 
the case.  In the event that any RBridge on the link tries to do
DRB election, then this MUST become the common mode.

Using that approach, the only failure mode where RBridges will
become confused is if three (or more) RBridges are 1) connected
to the same shared media and 2) configured to assume P2P.

Clever implementations MAY deal with that scenario in some robust
way - but we should not need to specify how that may be done (it
is always possible to misconfigure yourself into a hole, so there
is little point in trying to prevent that).

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Radia Perlman
> Sent: Tuesday, November 06, 2007 1:11 AM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] Can we ever have pt-to-pt links?
> 
> Suppose the topology consisted only of RBridges with pt-to-pt links 
> either to each other or
> to endnodes, e.g., no bridges, no CSMA/CD. As specified,  
> we'd wind up 
> creating
> a pseudonode for each link. Not a total disaster, but it does seem 
> suboptimal, especially
> if we created a pseudonode for every port that contains an endnode.
> 
> I think we discussed this and said that there was no way of 
> knowing for 
> sure that a port
> was a pt-to-pt link.
> 
> Do we want to try to optimize this case, for instance by:
> a) allowing a port to be configured as "pt-to-pt", and 
> freaking out (as 
> in disabling
> the port and declaring an error) if an RBridge sees multiple nodes on 
> that port, or sees
> a BPDU?
> b) assuming if there is only one RBridge neighbors on a port 
> that it is 
> a pt-to-pt
> link and there does not need to be a pseudonode? That makes 
> me nervous 
> because if
> a third RBridge comes and goes, then things could get messy.
> c) if there are zero RBridge neighbors on a port (just an endnode or
> set of endnodes), do not create a pseudonode
> for it
> d) something else?
> 
> Or is it fine as is (if R1 and R2 are connected with a 
> pt-to-pt link, R1 
> will get elected DRB,
> name the link R1.x, and issue two LSPs -- one for R1, one for 
> R1.x, with 
> R1.x claiming
> connectivity to R1 and R2). Basically, there will be a pseudonode for 
> every RBridge-RBridge
> link. I hope we don't have to create a pseudonode for every port to 
> every endnode.
> 
> Radia
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA6EbNaR006033 for <[e-mail]>; Tue, 6 Nov 2007 06:37:23 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,378,1188802800"; d="scan'208";a="413767721"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2007 06:37:04 -0800
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA6Eb32c011370;  Tue, 6 Nov 2007 09:37:03 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA6Eb3ep007785;  Tue, 6 Nov 2007 14:37:03 GMT
Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 09:36:08 -0500
Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 09:36:08 -0500
Message-ID: <[e-mail]>
Date: Tue, 06 Nov 2007 09:35:32 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Nov 2007 14:36:08.0369 (UTC) FILETIME=[5E854A10:01C82082]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15528.002
X-TM-AS-Result: No--5.856700-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1186; t=1194359823; x=1195223823; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Can=20we=20ever=20have=20pt-to-pt=20links ? |Sender:=20 |To:=20Radia=20Perlman=20<[e-mail]>; bh=iY1NJDUozK/78qqj2uti7Oic5Rba22P9k44wXVBuVRk=; b=IAmUxxhYz1kswQ+mlZWol5CCiwRL6jEGaSxod+0yULpIpTnFwfwvDWDpLABqMhRnTkUk6H45 Nx93tGybHHt3LqDi2wmwbJAFmFWJUzNRu9HBXrYt5c5vpzLBLl908L+y;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); 
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] Can we ever have pt-to-pt links?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 14:38:20 -0000
Status: RO
Content-Length: 1175

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>> The only thing special we were doing with the pseudonode was reporting
>> the bridge root.
>> So that means that R1, the DRB, would report the root bridge ID in its
>> LSP if
>> R1 has decided not to create a pseudonode.
>>
> Actually, let me change that to: "Let's always report the root bridge ID
> in the DRB's
> LSP, not the pseudonode LSP"
>
> So I'm getting more comfortable with that proposal -- the DRB only
> declares a pseudonode
> if there really are too many neighbors, and switching over from
> non-pseudonode to
> pseudnode is really not very disruptive.

In most implementations of IS-IS, there is a way to manually configured
a link as point-to-point, no matter what the layer 2 part of the device
thinks it is. The IS-IS WG pretty much eschewed auto-detection schemes
when we went through this exercise.

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMHu0ER27sUhU9OQRAgyEAKC3ic9tS1kROaWxVSWuwnrr2HUh9gCeJJss
wNbLsz14yV/oQ3FCO6Xh2Pg=
=vYAd
-----END PGP SIGNATURE-----


Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA6Eaoe0005818 for <[e-mail]>; Tue, 6 Nov 2007 06:36:50 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,378,1188802800"; d="scan'208";a="543704562"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2007 06:36:48 -0800
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA6EaldO011134;  Tue, 6 Nov 2007 09:36:47 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA6EaCgE025265;  Tue, 6 Nov 2007 14:36:45 GMT
Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 09:33:56 -0500
Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Nov 2007 09:33:55 -0500
Message-ID: <[e-mail]>
Date: Tue, 06 Nov 2007 09:33:20 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Nov 2007 14:33:55.0572 (UTC) FILETIME=[0F5E1340:01C82082]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15528.002
X-TM-AS-Result: No--3.313200-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3283; t=1194359807; x=1195223807; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Preview=20of=20changes=20for=20VLANs, =20e tc. |Sender:=20 |To:=[e-mail]; bh=VXNEYQn1k56UrB8faNICtmQP57l2z5u691RZ0XgiIj0=; b=Gd3lDsqFECNA+77fpg6UZBHgOrxP+nP3hOCCLWxd9vG4YDcB8V0oiq63CH8x0VhcXM0SMNXi DaniUBNkhTK9SuJuF8rs2ZF42eNNDrv4ExLW2F/mV1ENcmqnDc3gu6fq;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); 
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] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 14:37:32 -0000
Status: RO
Content-Length: 3233

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> a) all RBridges on a link can talk to each other using a single (outer) VLAN tag, and
> that VLAN is not allowed to be partitioned. If it is, whichever RBridges can't talk
> to the DRB on that VLAN are just orphaned. All the other RBridges send IS-IS
> messages (Hellos, LSPs, CSNPs) on that link tagged with the one VLAN tag.

Why have this vlan tag at all? If the traffic for any given vlan is
tunneled to the outer edge using the direct layer 2 address of the exit
rbridge, then the "outer" vlan tag is an unnecessary complication. The
simpler rule would be the only traffic on link which should have a vlan
tag will be that originating from a non-rbridge device. Once traffic
hits the first rbridge, there should never be an "outer" vlan tag, just
the destination address in the outer tunnel header.

All the other stuff you talk about seems to be much easier without this
outer header--the way IS-IS runs, the DIS election on each link,
forwarding, etc.

> f) Hellos shouldn't have to be bigger with this proposal. What's in a Hello?
> . my ID
> . my priority for becoming DRB
> . name of the pseudonode if I am DRB
> . VLAN tag "V" to use for outer VLAN tag on this cloud if I am DRB
> . set of neighbors I've heard Hellos from on the specified
> VLAN tag (V)
> . flag "please send CSNP" used when starting up, to ensure that
> you have synchronized LSP databases with your neighbors
> 
> Now there might also be the following in the Hello:
> . "Bidding for VLANs": If I'm not DRB, set of (priority, {set of VLAN tags}) that I would like
> to be assigned to en/decapsulate for

This does make the hello larger. Probably much larger....

> . "VLAN assignments" If I am DRB, en/decapsulator assignments, of the form
> (RBridge neighbor ID, {set of VLANs}) that I want that RBridge
> to encapsulate/decapsulate for.

I don't understand why we need this.... I don't think you're really
going to have a case where a single interface on the user side
"services" multiple vlans, which are generally separated at the edge
through virtual interfaces on the box. IE, if I receive a packet on
interface ethernet 1.1, then it's vlan x, if it's on ethernet 1.2, then
it's vlan y. There's no reason not to stick with this convention--the
chipsets already know how to separate things this way, I think.

IE, forwarding would look like this:

1. Receive packet on interface X.
2. Check to see if there's a 1q header.
3. If so, then look up appropriate edge destination, encap in a tunnel,
and resend.
3. If not, then find correct vlan, look up appropriate edge destination,
place vlan header on packet, encap in tunnel, and resend.

On the receiving side, you just strip off mac headers and process them
normally. There's no need for special processing of any type, is there?

I don't see anything about the "merging" vlans automatically.... I don't
think this should be done, in any case.

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMHswER27sUhU9OQRAkk+AKDf3LMTQCXPCL3Z7vNy5mmZT9c7bgCfbldB
RYbmkapg1cE1sSlsgQNVneQ=
=1x27
-----END PGP SIGNATURE-----


Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA67Ae7q029532 for <[e-mail]>; Mon, 5 Nov 2007 23:10:40 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.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]; Mon, 05 Nov 2007 23:10:29 -0800 (PST)
Received: from [129.150.22.40] ([192.18.43.225]) 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]; Mon, 05 Nov 2007 23:10:28 -0800 (PST)
Date: Mon, 05 Nov 2007 23:11:52 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Radia Perlman <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
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] Can we ever have pt-to-pt links?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 07:11:17 -0000
Status: RO
Content-Length: 587

Radia Perlman wrote:
>
> The only thing special we were doing with the pseudonode was reporting 
> the bridge root.
> So that means that R1, the DRB, would report the root bridge ID in its 
> LSP if
> R1 has decided not to create a pseudonode.
>   
Actually, let me change that to: "Let's always report the root bridge ID 
in the DRB's
LSP, not the pseudonode LSP"

So I'm getting more comfortable with that proposal -- the DRB only 
declares a pseudonode
if there really are too many neighbors, and switching over from 
non-pseudonode to
pseudnode is really not very disruptive.

Radia


Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA66rGtn023975 for <[e-mail]>; Mon, 5 Nov 2007 22:53:16 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.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]; Mon, 05 Nov 2007 22:53:16 -0800 (PST)
Received: from [129.150.22.40] ([192.18.43.225]) 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]; Mon, 05 Nov 2007 22:53:16 -0800 (PST)
Date: Mon, 05 Nov 2007 22:54:44 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Anoop Ghanwani <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
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] Can we ever have pt-to-pt links?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 06:53:40 -0000
Status: RO
Content-Length: 4261

Hmm. I don't know what LLDP is, but here is a proposal.

Observation: It's actually OK to consider a link with n RBridges to be 
n*2 pt-to-pt
links as long as n isn't very large.

So here's a proposal:

The Designated RBridge, R1, gets to decide if a particular link is to 
have a pseudonode
or not. R1 specifies either a pseudonode name in its Hello, or some 
value (like 0) that
says "Hey, I don't want to bother with a pseudonode, so just report all 
your RBridge
neighbors as pt-to-pt links".

So if there is a link with R1, R2, R3, and R4, then R1 gets to decide 
whether to
a) create pseudonode R1.x, and R1, R2, R3, and R4 all claim just the 
neighbor R1.x,
and R1.x claims neighbors R1, R2, R3, and R4, or
b) don't create a pseudonode, so R1 claims neighbors R2, R3, and R4...R2 
claims
neighbors R1, R3, and R4, etc.

The only thing special we were doing with the pseudonode was reporting 
the bridge root.
So that means that R1, the DRB, would report the root bridge ID in its 
LSP if
R1 has decided not to create a pseudonode.

We could declare some threshold, like 4 RBridges, and if R1 is DRB and 
there are
every 3 RBridge neighbors on a port, then R1 declares a pseudonode, and 
perhaps
leaves the pseudonode even if one of the neighbors goes down. Maybe once 
a port
is a pseudonode, it stays a pseudonode.

That way R1 would definitely not create pseudonodes for ports with just 
endnodes, or
for ports that are just pt-to-pt links.

The default would be "no pseudonode", but once a port had 3 RBridge 
neighbors, R1 decides
that port should have a pseudonode.

Radia



Anoop Ghanwani wrote:
>  
>
>   
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Radia Perlman
>> Sent: Monday, November 05, 2007 10:11 PM
>> To: Developing a hybrid router/bridge.
>> Subject: [rbridge] Can we ever have pt-to-pt links?
>>
>> Suppose the topology consisted only of RBridges with pt-to-pt 
>> links either to each other or to endnodes, e.g., no bridges, 
>> no CSMA/CD. As specified,  we'd wind up creating a pseudonode 
>> for each link. Not a total disaster, but it does seem 
>> suboptimal, especially if we created a pseudonode for every 
>> port that contains an endnode.
>>
>> I think we discussed this and said that there was no way of 
>> knowing for sure that a port was a pt-to-pt link.
>>     
>
> If you were using LLDP, you could be certain that the link
> is a point to point link if the system information in LLDP
> matches what you receive in the IS-IS hello.  Or you we could
> identify RBridges as a type of device in LLDP itself.
>  
>   
>> Do we want to try to optimize this case, for instance by:
>>     
>
> I think it would be useful to optimize.
>
>   
>> a) allowing a port to be configured as "pt-to-pt", and 
>> freaking out (as in disabling the port and declaring an 
>> error) if an RBridge sees multiple nodes on that port, or sees a BPDU?
>> b) assuming if there is only one RBridge neighbors on a port 
>> that it is a pt-to-pt link and there does not need to be a 
>> pseudonode? That makes me nervous because if a third RBridge 
>> comes and goes, then things could get messy.
>> c) if there are zero RBridge neighbors on a port (just an 
>> endnode or set of endnodes), do not create a pseudonode for it
>> d) something else?
>>     
>
> Is a combination of (a) and (b) possible?  A node can
> either use LLDP to discover it is point to point (and
> that won't change as long as the link stays up), or 
> it can be manually configured (in which case if a third
> adjacency is discovered, then you switch to broadcast-media
> mode and once in broadcast-media mode you never switch
> back).
>
>   
>> Or is it fine as is (if R1 and R2 are connected with a 
>> pt-to-pt link, R1 will get elected DRB, name the link R1.x, 
>> and issue two LSPs -- one for R1, one for R1.x, with R1.x 
>> claiming connectivity to R1 and R2). Basically, there will be 
>> a pseudonode for every RBridge-RBridge link. I hope we don't 
>> have to create a pseudonode for every port to every endnode.
>>
>> Radia
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>     



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA66QRU2016649 for <[e-mail]>; Mon, 5 Nov 2007 22:26:27 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,376,1188802800"; d="scan'208";a="21005289"
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 05 Nov 2007 22:26:22 -0800
Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id D54E6238301; Mon,  5 Nov 2007 22:26:22 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 5 Nov 2007 22:26:22 -0800
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: Mon, 5 Nov 2007 22:26:14 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Can we ever have pt-to-pt links?
Thread-Index: AcggPJBuHlM44m0YSzWXxdrtc3CJIQAALJAg
References: <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 06 Nov 2007 06:26:22.0854 (UTC) FILETIME=[F3638A60:01C8203D]
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 lA66QRU2016649
Subject: Re: [rbridge] Can we ever have pt-to-pt links?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 06:26:47 -0000
Status: RO
Content-Length: 2529

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Radia Perlman
> Sent: Monday, November 05, 2007 10:11 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] Can we ever have pt-to-pt links?
> 
> Suppose the topology consisted only of RBridges with pt-to-pt 
> links either to each other or to endnodes, e.g., no bridges, 
> no CSMA/CD. As specified,  we'd wind up creating a pseudonode 
> for each link. Not a total disaster, but it does seem 
> suboptimal, especially if we created a pseudonode for every 
> port that contains an endnode.
> 
> I think we discussed this and said that there was no way of 
> knowing for sure that a port was a pt-to-pt link.

If you were using LLDP, you could be certain that the link
is a point to point link if the system information in LLDP
matches what you receive in the IS-IS hello.  Or you we could
identify RBridges as a type of device in LLDP itself.
 
> Do we want to try to optimize this case, for instance by:

I think it would be useful to optimize.

> a) allowing a port to be configured as "pt-to-pt", and 
> freaking out (as in disabling the port and declaring an 
> error) if an RBridge sees multiple nodes on that port, or sees a BPDU?
> b) assuming if there is only one RBridge neighbors on a port 
> that it is a pt-to-pt link and there does not need to be a 
> pseudonode? That makes me nervous because if a third RBridge 
> comes and goes, then things could get messy.
> c) if there are zero RBridge neighbors on a port (just an 
> endnode or set of endnodes), do not create a pseudonode for it
> d) something else?

Is a combination of (a) and (b) possible?  A node can
either use LLDP to discover it is point to point (and
that won't change as long as the link stays up), or 
it can be manually configured (in which case if a third
adjacency is discovered, then you switch to broadcast-media
mode and once in broadcast-media mode you never switch
back).

> Or is it fine as is (if R1 and R2 are connected with a 
> pt-to-pt link, R1 will get elected DRB, name the link R1.x, 
> and issue two LSPs -- one for R1, one for R1.x, with R1.x 
> claiming connectivity to R1 and R2). Basically, there will be 
> a pseudonode for every RBridge-RBridge link. I hope we don't 
> have to create a pseudonode for every port to every endnode.
> 
> Radia
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA669KUR010822 for <[e-mail]>; Mon, 5 Nov 2007 22:09:21 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.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]; Mon, 05 Nov 2007 22:09:10 -0800 (PST)
Received: from [129.150.22.40] ([192.18.43.225]) 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]; Mon, 05 Nov 2007 22:09:10 -0800 (PST)
Date: Mon, 05 Nov 2007 22:10:39 -0800
From: Radia Perlman <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Can we ever have pt-to-pt links?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 06:09:38 -0000
Status: RO
Content-Length: 1425

Suppose the topology consisted only of RBridges with pt-to-pt links 
either to each other or
to endnodes, e.g., no bridges, no CSMA/CD. As specified,  we'd wind up 
creating
a pseudonode for each link. Not a total disaster, but it does seem 
suboptimal, especially
if we created a pseudonode for every port that contains an endnode.

I think we discussed this and said that there was no way of knowing for 
sure that a port
was a pt-to-pt link.

Do we want to try to optimize this case, for instance by:
a) allowing a port to be configured as "pt-to-pt", and freaking out (as 
in disabling
the port and declaring an error) if an RBridge sees multiple nodes on 
that port, or sees
a BPDU?
b) assuming if there is only one RBridge neighbors on a port that it is 
a pt-to-pt
link and there does not need to be a pseudonode? That makes me nervous 
because if
a third RBridge comes and goes, then things could get messy.
c) if there are zero RBridge neighbors on a port (just an endnode or
set of endnodes), do not create a pseudonode
for it
d) something else?

Or is it fine as is (if R1 and R2 are connected with a pt-to-pt link, R1 
will get elected DRB,
name the link R1.x, and issue two LSPs -- one for R1, one for R1.x, with 
R1.x claiming
connectivity to R1 and R2). Basically, there will be a pseudonode for 
every RBridge-RBridge
link. I hope we don't have to create a pseudonode for every port to 
every endnode.

Radia


Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA63mwga001027 for <[e-mail]>; Mon, 5 Nov 2007 19:48:58 -0800 (PST)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by mail-mta.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]; Mon, 05 Nov 2007 19:48:54 -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]; Mon, 05 Nov 2007 19:48:53 -0800 (PST)
Received: from [152.70.2.164] (Forwarded-For: [67.161.89.58]) by mail-srv.sfvic.sunlabs.com (mshttpd); Mon, 05 Nov 2007 19:48:53 -0800
Date: Mon, 05 Nov 2007 19:48:53 -0800
From: [e-mail]
To: Russ White <[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]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 03:49:15 -0000
Status: RO
Content-Length: 8851

Russ,

The way to look at it is that the VLAN tag with which RBridges talk to each other on one link is
irrelevant outside the link. So really...one pseudonode, and one VLAN per link
for interRBridge communication is a simplification. Really. Though I'm
not surprised if my sketch of a design might have not been self-explanatory.

Let me try to explain a bit more, and from an IS-IS point of view. If this isn't
clear, or if you still have concerns,
then we (you and I) can have a quick phone call (are you available tomorrow afternoon?),
or you can wait until
you see the details in the spec. Or you can ask another question on the list.

a) all RBridges on a link can talk to each other using a single (outer) VLAN tag, and
that VLAN is not allowed to be partitioned. If it is, whichever RBridges can't talk
to the DRB on that VLAN are just orphaned. All the other RBridges send IS-IS
messages (Hellos, LSPs, CSNPs) on that link tagged with the one VLAN tag.

b) All RBridge-RBridge links can be used as transit for data that
belongs on any VLAN. So a data packet from VLAN x on one link destined
to VLAN x on some other link in the campus can transit any RBridge-RBridge
link (say from R2 to R3) regardless of what VLAN tag R2 has to slap on the
outside of the frame in order to carry the frame from R2 to R3.

c) the only time VLANs are relevant, in terms of IS-IS forwarding, is when
pruning multicast (you don't have to send down a branch if none of the links
at the end of that branch support that VLAN. But for sending unicast...you
are sending to the specified egress RBridge. The forwarding RBridge
does not care at all what the inner VLAN is. It also doesn't care
what VLAN tag R3 has to tack on in order to forward it across the next
hop to R4.

e) A LAN will have a single DRB. A single pseudonode. No VLANs or
endnodes are
associated with the pseudonode.  Endnodes and VLANs are
only associated with RBridges. If R1 is DRB for pseudonode R1.25,
then R1.25's LSP only lists the other RBridges attached to R1.25.
Whatever RBridge R2 is appointed by R1 to forward VLAN x traffic
to/from pseudonode R1.25 will specify in R2's LSP, "I, R2, am
attached to VLAN x". R2 might even have lots of links attached
to VLAN x. But R2 just says in R2's LSP "I am attached to VLAN x".

f) Hellos shouldn't have to be bigger with this proposal. What's in a Hello?
. my ID
. my priority for becoming DRB
. name of the pseudonode if I am DRB
. VLAN tag "V" to use for outer VLAN tag on this cloud if I am DRB
. set of neighbors I've heard Hellos from on the specified
VLAN tag (V)
. flag "please send CSNP" used when starting up, to ensure that
you have synchronized LSP databases with your neighbors

Now there might also be the following in the Hello:
. "Bidding for VLANs": If I'm not DRB, set of (priority, {set of VLAN tags}) that I would like
to be assigned to en/decapsulate for
. "VLAN assignments" If I am DRB, en/decapsulator assignments, of the form
(RBridge neighbor ID, {set of VLANs}) that I want that RBridge
to encapsulate/decapsulate for.

I think we could come up with reasonably compact encodings for those. Though
they don't really have to be in the Hello. Instead, especially the "bidding"
part could be in a separate message to the DRB.  I like having the
DRB specify assignments in its Hello, though, to ensure there is no confusion.
I'd think that 99% of the time there would be no assignments, and the DRB itself
would be the encapsulator/decapsulator for all VLANs on that link.


Hope that's clearer...

Radia

----- Original Message -----
From: Russ White <[e-mail]>
Date: Monday, November 5, 2007 5:53 pm
Subject: Re: [rbridge] Preview of changes for VLANs, etc.

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > Based on talking to people, here is how I'm assuming the VLAN stuff
> > will look. The main points are
> 
> I'm a bit confused by this entire thread, and these changes....
> 
> > a) single DRB per link (rather than DRB election per VLAN).
> 
> I assume this is to reduce overhead by reducing the number of
> hello's.... But, then we turn around and make the hellos significantly
> larger, and change the format significantly, and we change their
> processing significantly.... I don't think there's any savings here.
> 
> Further, how does this look in SPF to other devices? Suppose you have
> one pnode per link, with multiple vlans:
> 
> o Do all the devices on the link advertise themselves as connected to
> the pnode? How does the pnode indicate all the vlans it transits, 
> so the
> SPF tree will work correctly? Does the pnode advertise one lsp per 
> vlan?If so, then how does this one pnode per link really save 
> anything?
> o What if there is no device that's actually on every vlan on the
> segment? Does it act as the pnode for vlans in which it doesn't
> participate? How do other is' build a tree in this situation--do they
> route through a pnode that's not on the vlan they're building a 
> tree for?
> 
> > b) that DRB can delegate to another RBridge on the link the
> > job of forwarding VLAN-x data to/from the link.
> 
> I think this kills all thoughts of load sharing through any sort of
> multiaccess medium. You'll still be able to load share on point-to-
> pointlinks, but not across Ethernet, for instance.... Is that an 
> acceptabletradeoff?
> 
> What if an rbridge sends some traffic to the only path on which it can
> send traffic for a specific vlan, and the exit point finds the only 
> pathit has is through the rbridge that just sent it the traffic? 
> How do we
> resolve this? Do we need ICMP redirects for TRILL?
> 
> > c) RBridges MAY be configured to send Hellos on a set of VLANs,
> > though VLAN 1 is the default. They are also configured with a single
> > preferred VLAN "V". If RBridge RB1 is DRB, it tells all the other 
> RBridges> on the link to send ALL RBridge-Rbridge traffic (Hellos, 
> LSPs,> forwarded encapsulated data traffic) with outer VLAN tag "V".
> 
> Doesn't this concept of a single "management" vlan on any given link
> destroy the ability to see what's going on on a specific vlan 
> throughouta network? IE, if I want to look at the neighbor 
> adjacencies for vlan x,
> I must look at debugs for vlan y, because the hellos are only sent on
> vlan y. I find this confusing--it will probably contribute to many 
> hoursof lost network time as engineers try to figure out what "vlan 
> v" is so
> they can see what's actually going on.
> 
> > d) For safety, the DRB RB1 continues to send Hellos not only on V,
> > but on all the VLANs that RB1 is configured to send Hellos on.
> 
> Which kills off any advantages from not sending all those hellos and
> doing dis election on all those vlans, doesn't it?
> 
> > f) We use all the link-avoidance stuff we'd discussed before (don't
> > decapsulate from ingress RBx unless you have RBx's LSP and all 
> pseudonodes> that RBx claims to be attached to, and can verify that 
> none of them
> > have the same root bridge ID as the link you are about to 
> decapsulate> onto -- also, be conservative about when you start 
> encapsulting data
> > off the link by waiting a few Hello intervals, and waiting until
> > you've synchornized LSP databases with your neighbors).
> 
> This is a lot of complex stuff at layer 2.... Are current chipsets 
> goingto be able to handle all of this? Or have we abandoned the 
> idea of minor
> or no modifications in hardware?
> 
> > g) IS-IS Hellos list the set of neighbors from which Hellos are 
> heard.> Once the DRB RB1 specifies "V" as the VLAN, the only 
> neighbors listed
> > in IS-IS Hellos are those from which a Hello is received on VLAN V.
> 
> What if someone's not configured to run on vlan v? What if a box 
> has a
> limited number of vlans it can support, and already has that number of
> vlans configured? There will probably be an upper limit on support on
> any given box, after all, so this is always a possibility as we get 
> intothe virtualization that rbridges will open up as possibilities.
> 
> Finally, I see a lot of stuff about welding together vlans with the 
> sameid no matter where they are in the network. I consider this to 
> be a huge
> "surprise" problem, at the least, and extremely dangerous, at the
> worst.... Just because two vlans are configured with the same id does
> not mean they were intended to be in the same broadcast domain.
> 
> So, can someone explain why we are doing all of this work, changing
> fundamental principles of IS-IS, changing SPF operation, etc.?
> 
> :-)
> 
> Russ
> 
> - --
> [e-mail] CCIE <>< Grace Alone
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFHL8kaER27sUhU9OQRAjcEAKCFZEHG7u6OzBc8ysqc6h5u7IQMIACg9tCG
> RBP6jhPZ0HtaYae+XAYg+5A=
> =J+a1
> -----END PGP SIGNATURE-----
> 



Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA61sABM024400 for <[e-mail]>; Mon, 5 Nov 2007 17:54:10 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,375,1188792000"; d="scan'208";a="136184347"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Nov 2007 20:54:10 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA61sA4G026910;  Mon, 5 Nov 2007 20:54:10 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA61rmfw028803;  Tue, 6 Nov 2007 01:54:10 GMT
Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 5 Nov 2007 20:54:05 -0500
Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 5 Nov 2007 20:54:04 -0500
Message-ID: <[e-mail]>
Date: Mon, 05 Nov 2007 20:53:30 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Nov 2007 01:54:04.0701 (UTC) FILETIME=[E9173CD0:01C82017]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15522.000
X-TM-AS-Result: No--11.807400-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4984; t=1194314050; x=1195178050; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Preview=20of=20changes=20for=20VLANs, =20e tc. |Sender:=20 |To:=20Radia=20Perlman=20<[e-mail]>; bh=q0YjMr9GSZyGxLcvodwIpoCl9YkFbq0fl8cFzfgGkWE=; b=fsS7o1jJaBipdSFNNTNLs6DN6SELs2D93yW6+L/EBgAvYesVzUsCtdo3G4rSMoKNrFii8z3N /+Q8EIIUV5ls9L7Xb9odYnpyWy57G5p+9/SA026pIcE6qvZnsxt9Pcj2;
Authentication-Results: rtp-dkim-2; header.From=[e-mail]; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); 
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] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 01:55:01 -0000
Status: RO
Content-Length: 4905

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> Based on talking to people, here is how I'm assuming the VLAN stuff
> will look. The main points are

I'm a bit confused by this entire thread, and these changes....

> a) single DRB per link (rather than DRB election per VLAN).

I assume this is to reduce overhead by reducing the number of
hello's.... But, then we turn around and make the hellos significantly
larger, and change the format significantly, and we change their
processing significantly.... I don't think there's any savings here.

Further, how does this look in SPF to other devices? Suppose you have
one pnode per link, with multiple vlans:

o Do all the devices on the link advertise themselves as connected to
the pnode? How does the pnode indicate all the vlans it transits, so the
SPF tree will work correctly? Does the pnode advertise one lsp per vlan?
If so, then how does this one pnode per link really save anything?

o What if there is no device that's actually on every vlan on the
segment? Does it act as the pnode for vlans in which it doesn't
participate? How do other is' build a tree in this situation--do they
route through a pnode that's not on the vlan they're building a tree for?

> b) that DRB can delegate to another RBridge on the link the
> job of forwarding VLAN-x data to/from the link.

I think this kills all thoughts of load sharing through any sort of
multiaccess medium. You'll still be able to load share on point-to-point
links, but not across Ethernet, for instance.... Is that an acceptable
tradeoff?

What if an rbridge sends some traffic to the only path on which it can
send traffic for a specific vlan, and the exit point finds the only path
it has is through the rbridge that just sent it the traffic? How do we
resolve this? Do we need ICMP redirects for TRILL?

> c) RBridges MAY be configured to send Hellos on a set of VLANs,
> though VLAN 1 is the default. They are also configured with a single
> preferred VLAN "V". If RBridge RB1 is DRB, it tells all the other RBridges
> on the link to send ALL RBridge-Rbridge traffic (Hellos, LSPs,
> forwarded encapsulated data traffic) with outer VLAN tag "V".

Doesn't this concept of a single "management" vlan on any given link
destroy the ability to see what's going on on a specific vlan throughout
a network? IE, if I want to look at the neighbor adjacencies for vlan x,
I must look at debugs for vlan y, because the hellos are only sent on
vlan y. I find this confusing--it will probably contribute to many hours
of lost network time as engineers try to figure out what "vlan v" is so
they can see what's actually going on.

> d) For safety, the DRB RB1 continues to send Hellos not only on V,
> but on all the VLANs that RB1 is configured to send Hellos on.

Which kills off any advantages from not sending all those hellos and
doing dis election on all those vlans, doesn't it?

> f) We use all the link-avoidance stuff we'd discussed before (don't
> decapsulate from ingress RBx unless you have RBx's LSP and all pseudonodes
> that RBx claims to be attached to, and can verify that none of them
> have the same root bridge ID as the link you are about to decapsulate
> onto -- also, be conservative about when you start encapsulting data
> off the link by waiting a few Hello intervals, and waiting until
> you've synchornized LSP databases with your neighbors).

This is a lot of complex stuff at layer 2.... Are current chipsets going
to be able to handle all of this? Or have we abandoned the idea of minor
or no modifications in hardware?

> g) IS-IS Hellos list the set of neighbors from which Hellos are heard.
> Once the DRB RB1 specifies "V" as the VLAN, the only neighbors listed
> in IS-IS Hellos are those from which a Hello is received on VLAN V.

What if someone's not configured to run on vlan v? What if a box has a
limited number of vlans it can support, and already has that number of
vlans configured? There will probably be an upper limit on support on
any given box, after all, so this is always a possibility as we get into
the virtualization that rbridges will open up as possibilities.

Finally, I see a lot of stuff about welding together vlans with the same
id no matter where they are in the network. I consider this to be a huge
"surprise" problem, at the least, and extremely dangerous, at the
worst.... Just because two vlans are configured with the same id does
not mean they were intended to be in the same broadcast domain.

So, can someone explain why we are doing all of this work, changing
fundamental principles of IS-IS, changing SPF operation, etc.?

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHL8kaER27sUhU9OQRAjcEAKCFZEHG7u6OzBc8ysqc6h5u7IQMIACg9tCG
RBP6jhPZ0HtaYae+XAYg+5A=
=J+a1
-----END PGP SIGNATURE-----


Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA61HbKg011579 for <[e-mail]>; Mon, 5 Nov 2007 17:17:37 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,375,1188802800"; d="scan'208";a="13577880"
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 05 Nov 2007 17:17:37 -0800
Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 0A8C7238301; Mon,  5 Nov 2007 17:17:37 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 5 Nov 2007 17:17:37 -0800
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: Mon, 5 Nov 2007 17:17:28 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Preview of changes for VLANs, etc.
Thread-Index: AcggEjxMmlsLzLwyT8Kc2qiOyIAePwAAEU1Q
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 06 Nov 2007 01:17:37.0245 (UTC) FILETIME=[D143F0D0:01C82012]
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 lA61HbKg011579
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 01:18:00 -0000
Status: RO
Content-Length: 568

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]] 
> Sent: Monday, November 05, 2007 5:15 PM
> To: Anoop Ghanwani
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.

> But...if an RBridge is configured to accept frames with any 
> VLAN tag, is it burdensome for it to accept Hellos on any of 
> those VLANs?

It most certainly would be.  Data frames are all processed
in hardware while the hellos would have to make their
way through system bus up the software stack to IS-IS.

Anoop



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA61DaUX010248 for <[e-mail]>; Mon, 5 Nov 2007 17:13:36 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.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]; Mon, 05 Nov 2007 17:13:26 -0800 (PST)
Received: from [129.150.22.40] ([192.18.43.225]) 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]; Mon, 05 Nov 2007 17:13:25 -0800 (PST)
Date: Mon, 05 Nov 2007 17:14:53 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Anoop Ghanwani <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
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] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2007 01:14:17 -0000
Status: RO
Content-Length: 3892

Good question. Once an RBridge knows it isn't the DRB, it seems like the 
only
VLAN it should need to send or receive Hellos on is the one that the DRB 
specifies
should be used for interbridge communication.

I think the "safety" case is to maximize the probability that RB1 and 
RB2 can hear
each other if they both believe they are DRB. That was why I was suggesting
that the DRB continue to send Hellos on all the VLANs that it is 
configured to
send Hellos on, which is hopefully a much smaller set than the set of 
VLANs it supports.
In other words, even if an RBridge is configured to accept frames with 
any of the
4000 VLANs on a link, that doesn't mean it would send Hellos on all 
4000. It would
have to be separately configured for the set of VLANs to send Hellos on, 
and hopefully
it would only be configured to send Hellos on a handful of VLANs (3 or 4).

But...if an RBridge is configured to accept frames with any VLAN tag, is 
it burdensome
for it to accept Hellos on any of those VLANs?

Radia


Anoop Ghanwani wrote:
> Hi Radia,
>
> I think the proposal is reasonable in that per-VLAN
> hellos are now optional (and can be made use of in
> certain scenarios).  However, what is not specified
> is the recipient behavior.  Can an RBridge choose
> to ignore hellos from all other VLANs except the
> one it is configured to send hellos on?  It seems
> like that should be allowed because it won't do 
> anything other than detect misconfigurations that
> can also be detected by other means (although 
> perhaps taking slightly longer to be detected).
>
> If that recipient behavior is not allowed, we will
> still get into scaling issues with having to receive
> and process hellos from potentially all VLANs 
> configured on a port.
>
> Anoop 
>
>   
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Radia Perlman
>> Sent: Monday, November 05, 2007 2:52 PM
>> To: Developing a hybrid router/bridge.
>> Subject: [rbridge] Preview of changes for VLANs, etc.
>>
>> Based on talking to people, here is how I'm assuming the VLAN 
>> stuff will look. The main points are
>>
>> a) single DRB per link (rather than DRB election per VLAN).
>>
>> b) that DRB can delegate to another RBridge on the link the 
>> job of forwarding VLAN-x data to/from the link.
>>
>> c) RBridges MAY be configured to send Hellos on a set of 
>> VLANs, though VLAN 1 is the default. They are also configured 
>> with a single preferred VLAN "V". If RBridge RB1 is DRB, it 
>> tells all the other RBridges on the link to send ALL 
>> RBridge-Rbridge traffic (Hellos, LSPs, forwarded encapsulated 
>> data traffic) with outer VLAN tag "V".
>>
>> d) For safety, the DRB RB1 continues to send Hellos not only 
>> on V, but on all the VLANs that RB1 is configured to send Hellos on.
>>
>> e) The set of VLANs that RB1 is configured to support on the 
>> link may be greater than the set of VLANs that RB1 is 
>> configured to send Hellos on
>>
>> f) We use all the link-avoidance stuff we'd discussed before 
>> (don't decapsulate from ingress RBx unless you have RBx's LSP 
>> and all pseudonodes that RBx claims to be attached to, and 
>> can verify that none of them have the same root bridge ID as 
>> the link you are about to decapsulate onto -- also, be 
>> conservative about when you start encapsulting data off the 
>> link by waiting a few Hello intervals, and waiting until 
>> you've synchornized LSP databases with your neighbors).
>>
>> g) IS-IS Hellos list the set of neighbors from which Hellos are heard.
>> Once the DRB RB1 specifies "V" as the VLAN, the only 
>> neighbors listed in IS-IS Hellos are those from which a Hello 
>> is received on VLAN V.
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>     



Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA5NtWmi013647 for <[e-mail]>; Mon, 5 Nov 2007 15:55:36 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.21,374,1188802800"; d="scan'208";a="13576607"
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 05 Nov 2007 15:28:25 -0800
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-plato-6 [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 8314D238301; Mon,  5 Nov 2007 15:28:25 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 5 Nov 2007 15:28:25 -0800
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: Mon, 5 Nov 2007 15:28:17 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Preview of changes for VLANs, etc.
Thread-Index: Acgf/6RHGiYbi/SRRyK5CPE2cVERPAAA1j9w
References: <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 05 Nov 2007 23:28:25.0568 (UTC) FILETIME=[90295E00:01C82003]
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 lA5NtWmi013647
Subject: Re: [rbridge] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2007 23:56:08 -0000
Status: RO
Content-Length: 2769

Hi Radia,

I think the proposal is reasonable in that per-VLAN
hellos are now optional (and can be made use of in
certain scenarios).  However, what is not specified
is the recipient behavior.  Can an RBridge choose
to ignore hellos from all other VLANs except the
one it is configured to send hellos on?  It seems
like that should be allowed because it won't do 
anything other than detect misconfigurations that
can also be detected by other means (although 
perhaps taking slightly longer to be detected).

If that recipient behavior is not allowed, we will
still get into scaling issues with having to receive
and process hellos from potentially all VLANs 
configured on a port.

Anoop 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Radia Perlman
> Sent: Monday, November 05, 2007 2:52 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] Preview of changes for VLANs, etc.
> 
> Based on talking to people, here is how I'm assuming the VLAN 
> stuff will look. The main points are
> 
> a) single DRB per link (rather than DRB election per VLAN).
> 
> b) that DRB can delegate to another RBridge on the link the 
> job of forwarding VLAN-x data to/from the link.
> 
> c) RBridges MAY be configured to send Hellos on a set of 
> VLANs, though VLAN 1 is the default. They are also configured 
> with a single preferred VLAN "V". If RBridge RB1 is DRB, it 
> tells all the other RBridges on the link to send ALL 
> RBridge-Rbridge traffic (Hellos, LSPs, forwarded encapsulated 
> data traffic) with outer VLAN tag "V".
> 
> d) For safety, the DRB RB1 continues to send Hellos not only 
> on V, but on all the VLANs that RB1 is configured to send Hellos on.
> 
> e) The set of VLANs that RB1 is configured to support on the 
> link may be greater than the set of VLANs that RB1 is 
> configured to send Hellos on
> 
> f) We use all the link-avoidance stuff we'd discussed before 
> (don't decapsulate from ingress RBx unless you have RBx's LSP 
> and all pseudonodes that RBx claims to be attached to, and 
> can verify that none of them have the same root bridge ID as 
> the link you are about to decapsulate onto -- also, be 
> conservative about when you start encapsulting data off the 
> link by waiting a few Hello intervals, and waiting until 
> you've synchornized LSP databases with your neighbors).
> 
> g) IS-IS Hellos list the set of neighbors from which Hellos are heard.
> Once the DRB RB1 specifies "V" as the VLAN, the only 
> neighbors listed in IS-IS Hellos are those from which a Hello 
> is received on VLAN V.
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA5MpKBN004060 for <[e-mail]>; Mon, 5 Nov 2007 14:51:20 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.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]; Mon, 05 Nov 2007 14:51:00 -0800 (PST)
Received: from [129.150.22.40] ([192.18.43.225]) 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]; Mon, 05 Nov 2007 14:51:00 -0800 (PST)
Date: Mon, 05 Nov 2007 14:52:29 -0800
From: Radia Perlman <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Preview of changes for VLANs, etc.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2007 22:51:39 -0000
Status: RO
Content-Length: 1562

Based on talking to people, here is how I'm assuming the VLAN stuff
will look. The main points are

a) single DRB per link (rather than DRB election per VLAN).

b) that DRB can delegate to another RBridge on the link the
job of forwarding VLAN-x data to/from the link.

c) RBridges MAY be configured to send Hellos on a set of VLANs,
though VLAN 1 is the default. They are also configured with a single
preferred VLAN "V". If RBridge RB1 is DRB, it tells all the other RBridges
on the link to send ALL RBridge-Rbridge traffic (Hellos, LSPs,
forwarded encapsulated data traffic) with outer VLAN tag "V".

d) For safety, the DRB RB1 continues to send Hellos not only on V,
but on all the VLANs that RB1 is configured to send Hellos on.

e) The set of VLANs that RB1 is configured to support on the link
may be greater than the set of VLANs that RB1 is configured to
send Hellos on

f) We use all the link-avoidance stuff we'd discussed before (don't
decapsulate from ingress RBx unless you have RBx's LSP and all pseudonodes
that RBx claims to be attached to, and can verify that none of them
have the same root bridge ID as the link you are about to decapsulate
onto -- also, be conservative about when you start encapsulting data
off the link by waiting a few Hello intervals, and waiting until
you've synchornized LSP databases with your neighbors).

g) IS-IS Hellos list the set of neighbors from which Hellos are heard.
Once the DRB RB1 specifies "V" as the VLAN, the only neighbors listed
in IS-IS Hellos are those from which a Hello is received on VLAN V.



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA5KjTKL017935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 5 Nov 2007 12:45:29 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id lA5KjScI003574; Mon, 5 Nov 2007 14:45:28 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 5 Nov 2007 14:45:28 -0600
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: Mon, 5 Nov 2007 14:45:26 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] RBridge: a case of study
Thread-Index: AcgcCAZhrdJXc76bTRGby8lmIMMrSgD3QmfA
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 05 Nov 2007 20:45:28.0519 (UTC) FILETIME=[CC961570:01C81FEC]
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 lA5KjTKL017935
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RBridge: a case of study
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2007 20:46:28 -0000
Status: RO
Content-Length: 12548

Radia,

	On looking at this again, it seems as if you've tried to
answer a question I am not asking.  

	I will try this again.   Please see in-line below.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]] 
> Sent: Wednesday, October 31, 2007 5:51 PM
> To: Eric Gray
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] RBridge: a case of study
> Importance: High
> 
> Eric....if I understand your concern...
> 
> Having all RBridge-RBridge traffic between neighbor RBridges 
> (RBridges on a single layer 2 cloud) take place on a single 
> VLAN (whether the VLAN used be configurable for that cloud, 
> or whether it's always VLAN 1), does not preclude load 
> splitting. 

For some types of load splitting, what you're saying may be
correct.  At the egress from, and ingress to, the RBridge
campus, the only form of load-splitting that we have talked
about thus far is based on the DRB election process - in
combination with VLAN-specific DRB election.

The why's and wherefore's of the issues of other forms of 
load splitting at the campus edge have to do with the need
to have symmetrical frame delivery - and that's a discussion 
complex enough to ignore (because it is irrelevant) in this 
discussion.

For this particular form of load-splitting, obviously using
only one VLAN for forwarding precludes it.

>
> "VLAN 1" as the VLAN tag in the outer header is just used in 
> order to get a packet from one RBridge to a neighbor RBridge.
> Layer 3 techniques for load splitting, traffic engineering, 
> etc., can be used for having RBridges choose paths across the
> campus. When doing load splitting, a smart RBridge, just like
> a router, could choose anything it can see in order to decide
> which path to send a frame on, or which traffic to drop when
> there is congestion, including the inner VLAN tag. 
> And although some might consider it architecturally impure,
> there isn't anything precluding an RBridge from looking
> even further into the packet and making forwarding/traffic 
> splitting/traffic dropping decisions based on things like the
> diffsrv field in the IP header, or the TCP ports.

And this is where we're missing the point.  If there is only 
one DRB for a given TRILL link, only that device will act as 
egress from, and ingress to, the link.

Many of the clever load-splitting approaches out there will
break a layer 2 network because they lead to asymmetrical
forwarding.

> 
> The outer VLAN tag is just how to wrap up the frame when 
> forwarding to the next hop RBridge that the RBridge forwarding
> decision has selected for this frame.

And - for the case where the forwarding RBridge is not the DRB
- it is necessary for the frame to traverse the local network
twice; once with TRILL encaps and again without.  It is quite
likely that this will often result in the DRB forwarding frames
onto a local bridged LAN for a VLAN that it would otherwise not
participate in.

> 
> Radia
> 

My earlier response pointed out - possibly at too much length - 
that you CANNOT assume that a link that provides egress from the
RBridge campus is not also a link between RBridges, nor that a
link between RBridges is not also an egress/ingress point.

I thought this obvious because I did qualify the concern by the
words "based on VLAN separation" - in reference to the specific
mechanism by which load-splitting would occur.  Even if we are
talking about traffic that is not going to be egressed onto the 
local link, this statement would have been true.

All of that said, if you are referring JUST to traffic that is 
literally traversing the local link, then what you say is true.
The DRB election does not apply in that case.  However, that is 
not the way I initially interpretted what you said.

In part, that is because of the earlier statement from Donald
- regarding the use of a single VLAN ID for all traffic sent on
any physical interface.

If that is not what you were referring to, then my objection to 
the idea is simply that it's unnecessarily restrictive and may, 
in fact, interfere with deployment.

> 
> 
> Eric Gray wrote:
> > Anoop,
> >
> > 	This is a generic VLAN bridging problem, commonly
> > dealt with using VLAN bridges today.  Clearly, it is not
> > the case that all VLAN bridges are required to use a 
> > common VLAN for frame forwarding.
> >
> > 	In addition, as I understand it (in part based on
> > James' reply), we are NOT saying that the common VLAN
> > you mention must be used for all frame forwarding - 
> > hence it is likely that the existence of a common VLAN
> > does not necessarily fix the problem.
> >
> > 	Just to be clear, if we were saying that a common
> > VLAN must be used for all forwarding between RBridges,
> > it quickly becomes obvious that load-sharing based on
> > VLAN separation becomes useless in practice.  If load
> > sharing based on VID is not useful, then MSTP already
> > provides L2 forwarding that makes more efficient use of
> > links than would be possible using RBridges (unless all
> > RBridge-to-RBridge connections are via P2P links).
> >
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson  
> >
> >   
> >> -----Original Message-----
> >> From: Anoop Ghanwani [mailto:[e-mail]] 
> >> Sent: Wednesday, October 31, 2007 1:33 PM
> >> To: Zhi-Hern Loh; Eric Gray
> >> Cc: Developing a hybrid router/bridge.
> >> Subject: RE: [rbridge] RBridge: a case of study
> >> Importance: High
> >>
> >>
> >> Hern,
> >>
> >> That's one of the problems that we're trying to avoid
> >> by forcing all RBridges on a bridged LAN to be configured
> >> such that they are all reachable and see one another on
> >> a single VLAN.
> >>
> >> Anoop 
> >>
> >>     
> >>> -----Original Message-----
> >>> From: [e-mail] 
> >>> [mailto:[e-mail]] On Behalf Of Zhi-Hern Loh
> >>> Sent: Wednesday, October 31, 2007 10:17 AM
> >>> To: Eric Gray
> >>> Cc: Developing a hybrid router/bridge.
> >>> Subject: Re: [rbridge] RBridge: a case of study
> >>>
> >>> Donald,
> >>>
> >>> In addition to Eric's questions, could you (or anyone else) 
> >>> explain what would happen in the following scenario?
> >>>
> >>> Toplogy:
> >>>
> >>>                 RBa
> >>>                 /
> >>>               VID a
> >>>                /
> >>>    RBn-link X-----VID b------RBb
> >>>
> >>> Problem:
> >>>
> >>>   RBn is connected to 2 VLANs on link/port X. Connectivity to 
> >>> RBa is via VLAN a, and connectivity to RBb is via VLAN b.
> >>>
> >>>   Suppose that RBa and RBb are in the multi-destination 
> >>> distribution tree from RBn. For a multi-destination frame 
> >>> going out link/port X on RBn to RBa and RBb, what is the VID 
> >>> on the outer VLAN tag? Or could there be need to send 2 
> >>> frames, one with VID a and another with VID b?
> >>>
> >>>
> >>>
> >>> Thanks,
> >>> Hern
> >>> Fulcrum Microsystems
> >>>
> >>>
> >>> ----- Original Message -----
> >>> From: "Eric Gray" <[e-mail]>
> >>> To: "Eastlake III Donald-LDE008" 
> >>> <[e-mail]>, "Zhi-Hern Loh" 
> >>>       
> >> <[e-mail]>
> >>     
> >>> Cc: "Developing a hybrid router/bridge." <[e-mail]>
> >>> Sent: Wednesday, October 31, 2007 4:16:33 AM (GMT-0800) 
> >>> America/Los_Angeles
> >>> Subject: RE: [rbridge] RBridge: a case of study
> >>>
> >>> Donald,
> >>>
> >>> 	When you say "would all have the same Outer [VID]"
> >>> - do you mean:
> >>>
> >>> 1) all frames MUST have the same VID within the an RBridge 
> >>>    campus,
> >>> 2) all frames forwarded from a (physical) port on one RBridge 
> >>>    to a (physical) port on another RBridge MUST have the same
> >>>    VID, or
> >>> 3) something else?
> >>>
> >>> --
> >>> Eric Gray
> >>> Principal Engineer
> >>> Ericsson  
> >>>
> >>>       
> >>>> -----Original Message-----
> >>>> From: [e-mail]
> >>>> [mailto:[e-mail]] On Behalf Of Eastlake III
> >>>> Donald-LDE008
> >>>> Sent: Wednesday, October 31, 2007 12:22 AM
> >>>> To: Zhi-Hern Loh
> >>>> Cc: Developing a hybrid router/bridge.
> >>>> Subject: Re: [rbridge] RBridge: a case of study
> >>>>
> >>>> Hi,
> >>>>
> >>>> Yes, as noted in protocol draft -05, the pseudo code was 
> >>>>         
> >> unchanged 
> >>     
> >>>> from
> >>>> -04 and is out of date.
> >>>>
> >>>> As currently being discussed, the TRILL encapsulated data being 
> >>>> forwarded out a particular physical port would all have the 
> >>>>         
> >>> same Outer 
> >>>       
> >>>> VLAN ID.
> >>>>
> >>>> Thanks,
> >>>> Donald
> >>>>
> >>>> -----Original Message-----
> >>>> From: [e-mail]
> >>>> [mailto:[e-mail]] On Behalf Of Zhi-Hern Loh
> >>>> Sent: Tuesday, October 30, 2007 10:54 PM
> >>>> To: Anoop Ghanwani
> >>>> Cc: Developing a hybrid router/bridge.; Radia Perlman; 
> >>>>         
> >> James Carlson
> >>     
> >>>> Subject: Re: [rbridge] RBridge: a case of study
> >>>>
> >>>>
> >>>> ----- "Anoop Ghanwani" <[e-mail]> wrote:
> >>>>         
> >>>>>> -----Original Message-----
> >>>>>> From: [e-mail] 
> >>>>>> [mailto:[e-mail]] On Behalf Of James Carlson
> >>>>>> Sent: Tuesday, October 30, 2007 2:37 PM
> >>>>>> To: Silvano Gai
> >>>>>> Cc: Developing a hybrid router/bridge.; [e-mail]
> >>>>>> Subject: Re: [rbridge] RBridge: a case of study
> >>>>>>
> >>>>>> Silvano Gai writes:
> >>>>>>             
> >>>>>>> Radia,
> >>>>>>>
> >>>>>>> I have added few slides to the example and I suggest that 
> >>>>>>>               
> >>>>>> we use it as 
> >>>>>>             
> >>>>>>> a possible case of study for TRILL (of course, not the 
> >>>>>>>               
> >>>> only one).
> >>>>         
> >>>>>>> Let's see if the solutions we have discussed work on this
> >>>>>>>               
> >>>>> example.
> >>>>>           
> >>>>>>> The complete case of study is at:
> >>>>>>>
> >>>>>>> http://www.ip6.com/acme-example-v1.ppt
> >>>>>>>               
> >>>>>> I have a few narrow questions that I think might help me 
> >>>>>> understand this picture a bit better.  (I probably have more 
> >>>>>> questions once I know the narrow answers.  ;-})
> >>>>>>             
> >>>>> Let me take a shot at answering these.
> >>>>>
> >>>>>           
> >>>>>>   1.  After the proposed fix, should VLAN 3 on Cloud L 
> >>>>>>             
> >>> be bridged
> >>>       
> >>>>>>       together with VLAN 3 on Cloud R, even though 
> >>>>>>             
> >> the backbone
> >>     
> >>>>> itself
> >>>>>           
> >>>>>>       doesn't directly carry VLAN 3?  (I.e., are TRILL 
> >>>>>>             
> >>>> packets with
> >>>>         
> >>>>>>       outer VLAN ID 7 or 8 and with inner VLAN 3 
> >>>>>>             
> >> present on the
> >>     
> >>>>>>       backbone?)
> >>>>>>             
> >>>>> Yes, that's pretty much what ends up happening.  
> >>>>> We have effectively extended the bridged LAN.
> >>>>>
> >>>>>           
> >>>> Anoop, I'm reading the RBridge protocol specification 
> >>>>         
> >>> version 5 and it
> >>>       
> >>>> seems to me that your comment is inconsistent with the spec. 
> >>>> In section,
> >>>> 5.2.2.3, the spec says that the outer VLAN tag of TRILL data 
> >>>> frames has
> >>>> the same VID as the inner tag. Is this section going to 
> >>>>         
> >> be changed?
> >>     
> >>>> Futhermore, if we were to use different VIDs on outer VLAN 
> >>>> tags then we
> >>>> would need to handle the multi-destination case where one 
> >>>> would need to
> >>>> send a multi-destination frame per outer VID to communicate 
> >>>> with the RBs
> >>>> in the distribution tree which are using different VIDs. Is this
> >>>> correct?
> >>>>
> >>>> Thanks,
> >>>> Hern
> >>>> Fulcrum Microsystems
> >>>>
> >>>> _______________________________________________
> >>>> rbridge mailing list
> >>>> [e-mail]
> >>>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>>
> >>>> _______________________________________________
> >>>> rbridge mailing list
> >>>> [e-mail]
> >>>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>>
> >>>>         
> >>> _______________________________________________
> >>> rbridge mailing list
> >>> [e-mail]
> >>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>
> >>>       
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >   
> 
> 



Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA5FphrE025598 for <[e-mail]>; Mon, 5 Nov 2007 07:51:43 -0800 (PST)
Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA5FpgQe028118 for <[e-mail]>; Mon, 5 Nov 2007 15:51:42 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lA5Fpg88049808 for <[e-mail]>; Mon, 5 Nov 2007 10:51:42 -0500 (EST)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA5FL50S021544; Mon, 5 Nov 2007 10:21:05 -0500 (EST)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lA5FL3OR021541; Mon, 5 Nov 2007 10:21:03 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 5 Nov 2007 10:21:03 -0500
From: James Carlson <[e-mail]>
To: Eastlake III Donald-LDE008 <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
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] RBridge: a case of study
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2007 15:52:29 -0000
Status: RO
Content-Length: 1719

Eastlake III Donald-LDE008 writes:
> @@@ This is not some new change just coming from Silvano. For some time
> now the base protocol specification has assumed that all the islands of
> a VLAN seen by an Rbridge get glued together. Bridges can keep them
> apart because they are myopic. Rbridges have a global view and it would
> add significant complexity to the protocol to somehow defeat the
> automatic connection of station on a VLAN by Rbridges. This was
> discussed extensively on the list including such ideas as adding a
> further qualifying "island-ID" or something to the VLANID+Address that
> are the current basis for TRILL routing. There was no support for such
> added complexity.

I'm asking about how Silvano Gai's diagram agrees with the current
spec.

According to the current spec, you have to configure any outer VLAN ID
number that's present.  It's in the realm of manual configuration and
thus doesn't violate anything the administrator has specifically set
up.

If I read Silvano Gai's diagram correctly, that configuration isn't
present.  Instead, the RBridges _automatically_ discover the
non-default connections amongst themselves, and use them as they see
fit.  (At a guess, they do so by sending Hello messages on all 4094
VLAN ID numbers.)

I'm not asking to have islands supported.  I agree that it'd be a
mess.  I'm asking whether he's assuming they'll always be
automatically glued together without manual configuration, even if
there are restricted outer VLANs.

-- 
James Carlson, Solaris Networking              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA5FkokV024367 for <[e-mail]>; Mon, 5 Nov 2007 07:46:50 -0800 (PST)
Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA5FknXU001303 for <[e-mail]>; Mon, 5 Nov 2007 15:46:49 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lA5FkngM041217 for <[e-mail]>; Mon, 5 Nov 2007 10:46:49 -0500 (EST)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA5FG9DT021528; Mon, 5 Nov 2007 10:16:14 -0500 (EST)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lA5FFwM7021525; Mon, 5 Nov 2007 10:15:58 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 5 Nov 2007 10:15:58 -0500
From: James Carlson <[e-mail]>
To: Eastlake III Donald-LDE008 <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
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] RBridge: a case of study
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2007 15:47:59 -0000
Status: RO
Content-Length: 3091

Eastlake III Donald-LDE008 writes:
> From: James Carlson [mailto:[e-mail]] 
[...]
> Eric Gray writes:
[...]
> > 2) all frames forwarded from a (physical) port on one RBridge 
> >    to a (physical) port on another RBridge MUST have the same
> >    VID, or 
[...]
> @@@ Well, I am Donald and I meant something like (2) but a bit narrower.
> I would have said "all TRILL frames" because "all frames" is way too
> inclusive. What about control frames like 802.1AB? Furthermore, in the
> case of point-to-point links between two Rbridges (i.e., no bridges or
> end station connections in between), as far as I can see there is no
> particular utility in considering the TRILL frames to have any external
> VLAN coloring and certainly no need for them to be outer tagged with a
> VLAN ID or priority.

I mostly agree with that.  In fact, I think that's a desirable end
state for TRILL, when all other bridges are obsolete.  Having no VLAN
tag on the outside makes a lot of sense there.

(I think omitting the priority makes a bit less sense to me, though.
Wouldn't you want the priority value set on an 802.1q header with VLAN
ID 0 in this case?)

I think the question is how to get there when there are networks that
are half-TRILL and half-otherwise.

> @@@ Well, your version of (3) above is, as I recall, roughly how things
> were in draft -04.

Yes.

> However, by -05 posted in July of this year (except
> in the pseudo code which is clearly labeled as still being that from
> -04), in order to actually provide the promised optimal pair-wise
> routing, the Outer and Inner VLANs are completely decoupled. See, for
> example, Section 4.1.2 of -05. And some recent proposals suggest using a
> single Outer VLAN ID on a link. 

As long as these things are manually configured, as described in
4.1.2, I don't see a problem.

As I understood Silvano Gai's discussion, it seemed he didn't want to
have those things be manually configured, so the RBridges would
somehow "find" each other on whatever underlying outer VLAN IDs might
be available and then forward packets without regard to the
restrictions placed on those other VLANs.

Perhaps I've misunderstood *that* part of it, but it's that part that
I wanted to clarify.

> The distinction with (2) in your list is that (2) appears to rule out
> the use of so-called "tagged" or leaf or ingress ports, forcing all
> ports to carry VLAN tags.
> 
> @@@ I find your above statement a bit confusing. Item (2) seems to be
> talking about TRILL frames between Rbridges which doesn't have anything
> to do with ingressing native frames.

The original statement said this:

  2) all frames forwarded from a (physical) port on one RBridge 
     to a (physical) port on another RBridge MUST have the same
     VID [...]

Packets that don't have VLAN tags (such as those on "tagged" ports)
don't have ID numbers.

-- 
James Carlson, Solaris Networking              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id lA3HNhSK021665 for <[e-mail]>; Sat, 3 Nov 2007 10:23:44 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-15.tower-119.messagelabs.com!1194110216!28608393!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 4384 invoked from network); 3 Nov 2007 17:16:57 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 3 Nov 2007 17:16:57 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lA3HGuAd010010 for <[e-mail]>; Sat, 3 Nov 2007 10:16:56 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id lA3HGu7l017655 for <[e-mail]>; Sat, 3 Nov 2007 12:16:56 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id lA3HGt9w017649 for <[e-mail]>; Sat, 3 Nov 2007 12:16:55 -0500 (CDT)
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: Sat, 3 Nov 2007 13:16:54 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] RBridge: a case of study
Thread-Index: Acgb48G1MhOQV4+OTEqyts4Xo9TpTwAAC0pgAJYqIxA=
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Zhi-Hern Loh" <[e-mail]>
X-CFilter-Loop: Reflected
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 lA3HNhSK021665
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RBridge: a case of study
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 03 Nov 2007 17:24:06 -0000
Status: RO
Content-Length: 6571

Hern,

Your question is the same as my question in point 2 of my mail at
http://www.postel.org/pipermail/rbridge/2007-October/002584.html.
The way things are described in the text of draft -05, I think you would
indeed have to send some TRILL data frames multiple times. That is why
there is currently discussion of ways to avoid this problem while
maintaining our charter goal of optional pairwise routing.

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Anoop Ghanwani
Sent: Wednesday, October 31, 2007 1:33 PM
To: Zhi-Hern Loh; Eric Gray
Cc: Developing a hybrid router/bridge.
Subject: Re: [rbridge] RBridge: a case of study


Hern,

That's one of the problems that we're trying to avoid
by forcing all RBridges on a bridged LAN to be configured
such that they are all reachable and see one another on
a single VLAN.

Anoop 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Zhi-Hern Loh
> Sent: Wednesday, October 31, 2007 10:17 AM
> To: Eric Gray
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] RBridge: a case of study
> 
> Donald,
> 
> In addition to Eric's questions, could you (or anyone else) 
> explain what would happen in the following scenario?
> 
> Toplogy:
> 
>                 RBa
>                 /
>               VID a
>                /
>    RBn-link X-----VID b------RBb
> 
> Problem:
> 
>   RBn is connected to 2 VLANs on link/port X. Connectivity to 
> RBa is via VLAN a, and connectivity to RBb is via VLAN b.
> 
>   Suppose that RBa and RBb are in the multi-destination 
> distribution tree from RBn. For a multi-destination frame 
> going out link/port X on RBn to RBa and RBb, what is the VID 
> on the outer VLAN tag? Or could there be need to send 2 
> frames, one with VID a and another with VID b?
> 
> 
> 
> Thanks,
> Hern
> Fulcrum Microsystems
> 
> 
> ----- Original Message -----
> From: "Eric Gray" <[e-mail]>
> To: "Eastlake III Donald-LDE008" 
> <[e-mail]>, "Zhi-Hern Loh" <[e-mail]>
> Cc: "Developing a hybrid router/bridge." <[e-mail]>
> Sent: Wednesday, October 31, 2007 4:16:33 AM (GMT-0800) 
> America/Los_Angeles
> Subject: RE: [rbridge] RBridge: a case of study
> 
> Donald,
> 
> 	When you say "would all have the same Outer [VID]"
> - do you mean:
> 
> 1) all frames MUST have the same VID within the an RBridge 
>    campus,
> 2) all frames forwarded from a (physical) port on one RBridge 
>    to a (physical) port on another RBridge MUST have the same
>    VID, or
> 3) something else?
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Eastlake III
> > Donald-LDE008
> > Sent: Wednesday, October 31, 2007 12:22 AM
> > To: Zhi-Hern Loh
> > Cc: Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] RBridge: a case of study
> > 
> > Hi,
> > 
> > Yes, as noted in protocol draft -05, the pseudo code was unchanged 
> > from
> > -04 and is out of date.
> > 
> > As currently being discussed, the TRILL encapsulated data being 
> > forwarded out a particular physical port would all have the 
> same Outer 
> > VLAN ID.
> > 
> > Thanks,
> > Donald
> > 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Zhi-Hern Loh
> > Sent: Tuesday, October 30, 2007 10:54 PM
> > To: Anoop Ghanwani
> > Cc: Developing a hybrid router/bridge.; Radia Perlman; James Carlson
> > Subject: Re: [rbridge] RBridge: a case of study
> > 
> > 
> > ----- "Anoop Ghanwani" <[e-mail]> wrote:
> > > > -----Original Message-----
> > > > From: [e-mail] 
> > > > [mailto:[e-mail]] On Behalf Of James Carlson
> > > > Sent: Tuesday, October 30, 2007 2:37 PM
> > > > To: Silvano Gai
> > > > Cc: Developing a hybrid router/bridge.; [e-mail]
> > > > Subject: Re: [rbridge] RBridge: a case of study
> > > > 
> > > > Silvano Gai writes:
> > > > > Radia,
> > > > > 
> > > > > I have added few slides to the example and I suggest that 
> > > > we use it as 
> > > > > a possible case of study for TRILL (of course, not the 
> > only one).
> > > > > 
> > > > > Let's see if the solutions we have discussed work on this
> > > example.
> > > > > 
> > > > > The complete case of study is at:
> > > > > 
> > > > > http://www.ip6.com/acme-example-v1.ppt
> > > > 
> > > > I have a few narrow questions that I think might help me 
> > > > understand this picture a bit better.  (I probably have more 
> > > > questions once I know the narrow answers.  ;-})
> > > 
> > > Let me take a shot at answering these.
> > > 
> > > >   1.  After the proposed fix, should VLAN 3 on Cloud L 
> be bridged
> > > >       together with VLAN 3 on Cloud R, even though the backbone
> > > itself
> > > >       doesn't directly carry VLAN 3?  (I.e., are TRILL 
> > packets with
> > > >       outer VLAN ID 7 or 8 and with inner VLAN 3 present on the
> > > >       backbone?)
> > > 
> > > Yes, that's pretty much what ends up happening.  
> > > We have effectively extended the bridged LAN.
> > > 
> > 
> > Anoop, I'm reading the RBridge protocol specification 
> version 5 and it
> > seems to me that your comment is inconsistent with the spec. 
> > In section,
> > 5.2.2.3, the spec says that the outer VLAN tag of TRILL data 
> > frames has
> > the same VID as the inner tag. Is this section going to be changed?
> > 
> > Futhermore, if we were to use different VIDs on outer VLAN 
> > tags then we
> > would need to handle the multi-destination case where one 
> > would need to
> > send a multi-destination frame per outer VID to communicate 
> > with the RBs
> > in the distribution tree which are using different VIDs. Is this
> > correct?
> > 
> > Thanks,
> > Hern
> > Fulcrum Microsystems
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

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



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id lA3GoAbp010100 for <[e-mail]>; Sat, 3 Nov 2007 09:50:10 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-13.tower-119.messagelabs.com!1194108608!38663126!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.189.100.103]
Received: (qmail 881 invoked from network); 3 Nov 2007 16:50:09 -0000
Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-13.tower-119.messagelabs.com with SMTP; 3 Nov 2007 16:50:09 -0000
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lA3Go8U5028621 for <[e-mail]>; Sat, 3 Nov 2007 09:50:08 -0700 (MST)
Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lA3Go7uw026593 for <[e-mail]>; Sat, 3 Nov 2007 11:50:07 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lA3Go64C026579 for <[e-mail]>; Sat, 3 Nov 2007 11:50:06 -0500 (CDT)
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: Sat, 3 Nov 2007 12:50:04 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] RBridge: a case of study
Thread-Index: AcgbwLw2KmM1SDUrSoGtu1W4Ky6JogCDqsog
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "James Carlson" <[e-mail]>
X-CFilter-Loop: Reflected
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 lA3GoAbp010100
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RBridge: a case of study
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 03 Nov 2007 16:50:31 -0000
Status: RO
Content-Length: 4507

Hi,

See below at @@@

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of James Carlson
Sent: Wednesday, October 31, 2007 9:02 AM
To: Silvano Gai
Cc: Developing a hybrid router/bridge.; [e-mail]
Subject: Re: [rbridge] RBridge: a case of study

Silvano Gai writes:
> James,
> 
> -- snip --
> 
> > 
> >   3.  Suppose we were to configure VLAN 7 within Cloud L.  Would you
> >       expect H1 to be able to access nodes within the backbone Cloud
G
> >       at that point?  (I'm trying to figure out whether the "X" and
> >       "Y" interfaces are of fundamentally different types or if the
> >       RBridges are just bridges.  I suspect they're different.)
> > 
> 
> I have produced an updated drawing to cover the case of "hybrid
ports".
> 
> http://www.ip6.com/example-v2.ppt
> 
> In this drawing I assume that H5 is able to talk with H6.

That new diagram still does not show the confusing situation that I
was referring to above.  In fact, it shows a situation that is
essentially _identical_ to the previous one you showed in terms of
added bridge functionality.

To replicate the confusing functionality, consider what happens when
adding a host (call it H7) attached to Cloud P.  Without VLAN 7 in
Cloud P, H7 will not be able to participate in VLAN 7 even though all
attached RBridges are in fact transiting VLAN 7 traffic on that
network.  If VLAN 7 is provisioned onto Cloud P (exactly how does this
happen?), then H7 can play.  I see no functionality comparable to this
in the existing draft.

The core change that I think you're asserting here is that when the
user deploys RBridges, the network automatically discovers all of the
far-flung and disjoint islands of VLAN ID usage, and glues those
together by tunneling over whatever VLANs might be in the way between
them.  It no longer matters what configuration separates them.

@@@ This is not some new change just coming from Silvano. For some time
now the base protocol specification has assumed that all the islands of
a VLAN seen by an Rbridge get glued together. Bridges can keep them
apart because they are myopic. Rbridges have a global view and it would
add significant complexity to the protocol to somehow defeat the
automatic connection of station on a VLAN by Rbridges. This was
discussed extensively on the list including such ideas as adding a
further qualifying "island-ID" or something to the VLANID+Address that
are the current basis for TRILL routing. There was no support for such
added complexity.

This is quite a departure from traditional bridging, and I think it's
likely to be both confusing and dangerous, so I'm not sure it ought to
be the default behavior.  In today's bridges, if I configure a trunk
port such that VLAN 3 traffic does not traverse the link, then --
quite simply -- no packets with VLAN ID set to 3 go over that link.
In the new model, that restriction does not apply.

If I say "allow VLAN ID 3," then both an O-RBridge (original RBridge
as I understood it) and the new G-RBridge (Silvano Gai modified
RBridge) will allow VLAN ID 3 across the link.  If I say "disallow
VLAN ID 3 and allow only VLAN 7," then the O-RBridge would stop
passing VLAN ID 3 traffic, but the G-RBridge would simply switch the
outer VLAN ID number and use VLAN 7 effectively as a tunnel to pass
VLAN 3.  The TRILL-encapsulated packets will have VLAN 3 on the inside
and VLAN 7 on the outside.

@@@ The only suggestion that was made to preserve VLAN islands was to,
in effect, create a bigger VLAN ID or other higher order qualifier on
top of the 60 bits of VLAN plus address. There was no support in the
working group for this suggestion.

@@@ Thanks,
@@@ Donald

I'm not at all sure that's a good thing.  I can see why folks who are
struggling with the unkempt nature of VLAN ID provisioning across
complex (and politically divided) networks would be excited about a
"do what I mean" option -- particularly if it means that I don't have
to tell my local IT group to reconfigure switches to allow separated
chunks of my new VLAN to connect together -- but the side-effects seem
extreme.

-- 
James Carlson, Solaris Networking              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]
_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id lA3Gd0VK007140 for <[e-mail]>; Sat, 3 Nov 2007 09:39:00 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-119.messagelabs.com!1194107937!33715957!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 23933 invoked from network); 3 Nov 2007 16:38:57 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-119.messagelabs.com with SMTP; 3 Nov 2007 16:38:57 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lA3GctX5005909 for <[e-mail]>; Sat, 3 Nov 2007 09:38:57 -0700 (MST)
Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lA3Gcs01027608 for <[e-mail]>; Sat, 3 Nov 2007 11:38:54 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lA3Gcsxm027603 for <[e-mail]>; Sat, 3 Nov 2007 11:38:54 -0500 (CDT)
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: Sat, 3 Nov 2007 12:38:52 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] RBridge: a case of study
Thread-Index: AcgbzbqlXVjQi+BuRZapUUjeb2wKiACAsmEw
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "James Carlson" <[e-mail]>
X-CFilter-Loop: Reflected
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 lA3Gd0VK007140
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RBridge: a case of study
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 03 Nov 2007 16:39:39 -0000
Status: RO
Content-Length: 2679

See below at @@@

-----Original Message-----
From: James Carlson [mailto:[e-mail]] 
Sent: Wednesday, October 31, 2007 10:14 AM
To: Eric Gray
Cc: Eastlake III Donald-LDE008; Zhi-Hern Loh; Developing a hybrid
router/bridge.
Subject: Re: [rbridge] RBridge: a case of study

Eric Gray writes:
> Donald,
> 
> 	When you say "would all have the same Outer [VID]"
> - do you mean:
> 
> 1) all frames MUST have the same VID within the an RBridge 
>    campus, 
> 2) all frames forwarded from a (physical) port on one RBridge 
>    to a (physical) port on another RBridge MUST have the same
>    VID, or 
> 3) something else?

(I'm not Donald, but ...)

@@@ Well, I am Donald and I meant something like (2) but a bit narrower.
I would have said "all TRILL frames" because "all frames" is way too
inclusive. What about control frames like 802.1AB? Furthermore, in the
case of point-to-point links between two Rbridges (i.e., no bridges or
end station connections in between), as far as I can see there is no
particular utility in considering the TRILL frames to have any external
VLAN coloring and certainly no need for them to be outer tagged with a
VLAN ID or priority.

My understanding was more like:

  3) Where an outer VLAN tag is present, all frames transmitted by an
     RBridge must have the same inner and outer VLAN tag numbers.
     Where an outer VLAN tag is not present, the implicit tag for that
     port must match or be compatible with the inner tag.

... which would be consistent with "traditional" bridge behavior and
would effectively rule out the type of solution that Silvano Gai has
been proposing.

@@@ Well, your version of (3) above is, as I recall, roughly how things
were in draft -04. However, by -05 posted in July of this year (except
in the pseudo code which is clearly labeled as still being that from
-04), in order to actually provide the promised optimal pair-wise
routing, the Outer and Inner VLANs are completely decoupled. See, for
example, Section 4.1.2 of -05. And some recent proposals suggest using a
single Outer VLAN ID on a link. 

The distinction with (2) in your list is that (2) appears to rule out
the use of so-called "tagged" or leaf or ingress ports, forcing all
ports to carry VLAN tags.

@@@ I find your above statement a bit confusing. Item (2) seems to be
talking about TRILL frames between Rbridges which doesn't have anything
to do with ingressing native frames.

@@@ Thanks,
@@@ Donald

-- 
James Carlson, Solaris Networking              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id lA342rTY007938 for <[e-mail]>; Fri, 2 Nov 2007 21:02:53 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-12.tower-128.messagelabs.com!1194062572!15038720!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.189.100.101]
Received: (qmail 16252 invoked from network); 3 Nov 2007 04:02:52 -0000
Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-12.tower-128.messagelabs.com with SMTP; 3 Nov 2007 04:02:52 -0000
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lA342fE4007151 for <[e-mail]>; Fri, 2 Nov 2007 21:02:51 -0700 (MST)
Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lA342eWe012700 for <[e-mail]>; Fri, 2 Nov 2007 23:02:41 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lA342dAQ012693 for <[e-mail]>; Fri, 2 Nov 2007 23:02:40 -0500 (CDT)
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: Sat, 3 Nov 2007 00:02:38 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Separating DRB election from encapsulator/decapsulator
Thread-Index: AcgcPhjJyeKosKJWSTiIC76n1it2JQBkC/2A
References: <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-CFilter-Loop: Reflected
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 lA342rTY007938
Subject: Re: [rbridge] Separating DRB election from encapsulator/decapsulator
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 03 Nov 2007 04:03:40 -0000
Status: RO
Content-Length: 1820

That seems like a good idea and should simplify the Hellos.

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Thursday, November 01, 2007 12:01 AM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Separating DRB election from
encapsulator/decapsulator

When trying to carefully write up all the rules with respect to RBridges

and VLANs, it occurs
to me that one place in which things can be simplified is to separate 
the function of the DRB on
a layer 2 cloud from the selection of data packet 
encapsulator/decapsulator for each VLAN.

What I mean is that instead of having n different DRB elections with 
different priorities for
different, possibly overlapping sets of VLANs for that cloud, we instead

have a single
DRB election for that cloud, and as a result, a single pseudonode
associated with the cloud that would be visible to
any RBridges not on the cloud. The DRB on a cloud has the following
duties:

a) names the pseudonode associated with the cloud
b) reports an LSP on behalf of the pseudonode
c) issues IS-IS CSNPs (a way of acknowledging LSPs that have been
sent on the cloud)
d) specifies, for each VLAN supported on that cloud, which RBridge on
the
cloud will be doing encapsulation/decapsulation for that VLAN
e) chooses a VLAN tag with which all RBridge-RBridge communication on
that cloud will be tagged in the outer header (explanation of this will 
be in a future email).

For now, does anyone see any problem with this? It's unfortunately a bit

entwined with
the other hairy discussion going on, but I think that we're going to 
converge for that.

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



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA199ZgY015844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 1 Nov 2007 02:09:35 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id lA199YI9005867; Thu, 1 Nov 2007 03:09:35 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 1 Nov 2007 04:09:34 -0500
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: Thu, 1 Nov 2007 04:09:31 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] RBridge: a case of study
Thread-Index: AcgcCAZhrdJXc76bTRGby8lmIMMrSgAVvImA
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 01 Nov 2007 09:09:34.0639 (UTC) FILETIME=[EBAE9BF0:01C81C66]
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 lA199ZgY015844
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RBridge: a case of study
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 01 Nov 2007 09:10:10 -0000
Status: RO
Content-Length: 12490

Radia,

	I don't think you've quite captured the concern.

	As a matter of practicality, it is most likely to be
the case that the (at least intended) "normal" paths across 
an RBridge campus will use either point to point, or RBridge
exclusive LAN connections.

	In these cases, what you are saying is correct.

	However, it may be the case that there are also end
stations located on a LAN connecting RBridges that are also
(perhaps mostly) used as intermediate RBridges.  

	Simple picture:
   _____             _____             _____
  /     \   +---+   /     \   +---+   /     \
 { LAN-A }--+ 1 +--{ LAN-B }--+ 2 +--{ LAN-C }
  \_____/   +---+   \_____/   +---+   \_____/
                       |
                     +-+-+
                     | 3 |
                     +-+-+
                     __|__
                    /     \
                   { LAN-D }
                    \_____/

If you consider that LAN-B may have end stations, then part 
of the "load-sharing" concern has to do with sharing "load"
associated with delivering frames to (or from) those local
end stations.  To do this, the VLAN-based DRB election may
require that multiple RBridges (1, 2 and/or 3 in this case)
- of course depending on the possibility that there are end
stations in LAN-B in more than one VLAN.

	One could argue that a scenario like this - where the
number of end-stations on LAN-B is sufficient to justify a
"load sharing" concern - is artificially "constructed" (i.e.
- unlikely to occur in a real network).  However, it is a
good idea to consider that one can arrive at this scenario,
or one very like it, as a result of a fault in a deployment 
where redundancy is provided.

	For example, this topology -
   _____         
  /     \   +---+ 
 { LAN-A }--+ 1 +-.
  \_____/   +---+  \
     |              \_ _____
   +-+-+              /     \
   | 4 |             { LAN-B }
   +-+-+             _\_____/
   __|__            /
  /     \   +---+  /
 { LAN-C }--+ 2 +-'
  \_____/   +---+

- fails to this topology (on removing RBridge 4):
   _____             _____             _____
  /     \   +---+   /     \   +---+   /     \
 { LAN-A }--+ 1 +--{ LAN-B }--+ 2 +--{ LAN-C }
  \_____/   +---+   \_____/   +---+   \_____/

The interesting point - in this case - is that it seems
likely that a load-sharing election process was needed
in the initial (unbroken) topology - and MUST NOT be 
broken by the "recovery" process associated with remote
failure of RBridge 4.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]] 
> Sent: Wednesday, October 31, 2007 5:51 PM
> To: Eric Gray
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] RBridge: a case of study
> Importance: High
> 
> Eric....if I understand your concern...
> 
> Having all RBridge-RBridge traffic between neighbor
> RBridges (RBridges on a single layer 2 cloud) take place on a 
> single VLAN
> (whether the VLAN used be configurable for that cloud, or 
> whether it's 
> always VLAN 1),
> does not preclude load splitting. "VLAN 1" as the VLAN tag in
> the outer header is just used in order to get a packet from one
> RBridge to a neighbor RBridge. Layer 3 techniques for load splitting, 
> traffic engineering, etc.,
> can be used for having RBridges choose paths across the campus. When 
> doing load
> splitting, a smart RBridge, just like a router, could choose 
> anything it 
> can see in order to decide which
> path to send a frame on, or which traffic to drop when there is
> congestion, including the inner VLAN tag. And although some might 
> consider it
> architecturally impure, there isn't anything precluding an 
> RBridge from 
> looking
> even further into the packet and making forwarding/traffic 
> splitting/traffic dropping decisions based
> on things like the diffsrv field in the IP
> header, or the TCP ports.
> 
> The outer VLAN tag is just how to wrap up the frame when 
> forwarding to 
> the next hop
> RBridge that the RBridge forwarding decision has selected for 
> this frame.
> 
> Radia
> 
> 
> 
> Eric Gray wrote:
> > Anoop,
> >
> > 	This is a generic VLAN bridging problem, commonly
> > dealt with using VLAN bridges today.  Clearly, it is not
> > the case that all VLAN bridges are required to use a 
> > common VLAN for frame forwarding.
> >
> > 	In addition, as I understand it (in part based on
> > James' reply), we are NOT saying that the common VLAN
> > you mention must be used for all frame forwarding - 
> > hence it is likely that the existence of a common VLAN
> > does not necessarily fix the problem.
> >
> > 	Just to be clear, if we were saying that a common
> > VLAN must be used for all forwarding between RBridges,
> > it quickly becomes obvious that load-sharing based on
> > VLAN separation becomes useless in practice.  If load
> > sharing based on VID is not useful, then MSTP already
> > provides L2 forwarding that makes more efficient use of
> > links than would be possible using RBridges (unless all
> > RBridge-to-RBridge connections are via P2P links).
> >
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson  
> >
> >   
> >> -----Original Message-----
> >> From: Anoop Ghanwani [mailto:[e-mail]] 
> >> Sent: Wednesday, October 31, 2007 1:33 PM
> >> To: Zhi-Hern Loh; Eric Gray
> >> Cc: Developing a hybrid router/bridge.
> >> Subject: RE: [rbridge] RBridge: a case of study
> >> Importance: High
> >>
> >>
> >> Hern,
> >>
> >> That's one of the problems that we're trying to avoid
> >> by forcing all RBridges on a bridged LAN to be configured
> >> such that they are all reachable and see one another on
> >> a single VLAN.
> >>
> >> Anoop 
> >>
> >>     
> >>> -----Original Message-----
> >>> From: [e-mail] 
> >>> [mailto:[e-mail]] On Behalf Of Zhi-Hern Loh
> >>> Sent: Wednesday, October 31, 2007 10:17 AM
> >>> To: Eric Gray
> >>> Cc: Developing a hybrid router/bridge.
> >>> Subject: Re: [rbridge] RBridge: a case of study
> >>>
> >>> Donald,
> >>>
> >>> In addition to Eric's questions, could you (or anyone else) 
> >>> explain what would happen in the following scenario?
> >>>
> >>> Toplogy:
> >>>
> >>>                 RBa
> >>>                 /
> >>>               VID a
> >>>                /
> >>>    RBn-link X-----VID b------RBb
> >>>
> >>> Problem:
> >>>
> >>>   RBn is connected to 2 VLANs on link/port X. Connectivity to 
> >>> RBa is via VLAN a, and connectivity to RBb is via VLAN b.
> >>>
> >>>   Suppose that RBa and RBb are in the multi-destination 
> >>> distribution tree from RBn. For a multi-destination frame 
> >>> going out link/port X on RBn to RBa and RBb, what is the VID 
> >>> on the outer VLAN tag? Or could there be need to send 2 
> >>> frames, one with VID a and another with VID b?
> >>>
> >>>
> >>>
> >>> Thanks,
> >>> Hern
> >>> Fulcrum Microsystems
> >>>
> >>>
> >>> ----- Original Message -----
> >>> From: "Eric Gray" <[e-mail]>
> >>> To: "Eastlake III Donald-LDE008" 
> >>> <[e-mail]>, "Zhi-Hern Loh" 
> >>>       
> >> <[e-mail]>
> >>     
> >>> Cc: "Developing a hybrid router/bridge." <[e-mail]>
> >>> Sent: Wednesday, October 31, 2007 4:16:33 AM (GMT-0800) 
> >>> America/Los_Angeles
> >>> Subject: RE: [rbridge] RBridge: a case of study
> >>>
> >>> Donald,
> >>>
> >>> 	When you say "would all have the same Outer [VID]"
> >>> - do you mean:
> >>>
> >>> 1) all frames MUST have the same VID within the an RBridge 
> >>>    campus,
> >>> 2) all frames forwarded from a (physical) port on one RBridge 
> >>>    to a (physical) port on another RBridge MUST have the same
> >>>    VID, or
> >>> 3) something else?
> >>>
> >>> --
> >>> Eric Gray
> >>> Principal Engineer
> >>> Ericsson  
> >>>
> >>>       
> >>>> -----Original Message-----
> >>>> From: [e-mail]
> >>>> [mailto:[e-mail]] On Behalf Of Eastlake III
> >>>> Donald-LDE008
> >>>> Sent: Wednesday, October 31, 2007 12:22 AM
> >>>> To: Zhi-Hern Loh
> >>>> Cc: Developing a hybrid router/bridge.
> >>>> Subject: Re: [rbridge] RBridge: a case of study
> >>>>
> >>>> Hi,
> >>>>
> >>>> Yes, as noted in protocol draft -05, the pseudo code was 
> >>>>         
> >> unchanged 
> >>     
> >>>> from
> >>>> -04 and is out of date.
> >>>>
> >>>> As currently being discussed, the TRILL encapsulated data being 
> >>>> forwarded out a particular physical port would all have the 
> >>>>         
> >>> same Outer 
> >>>       
> >>>> VLAN ID.
> >>>>
> >>>> Thanks,
> >>>> Donald
> >>>>
> >>>> -----Original Message-----
> >>>> From: [e-mail]
> >>>> [mailto:[e-mail]] On Behalf Of Zhi-Hern Loh
> >>>> Sent: Tuesday, October 30, 2007 10:54 PM
> >>>> To: Anoop Ghanwani
> >>>> Cc: Developing a hybrid router/bridge.; Radia Perlman; 
> >>>>         
> >> James Carlson
> >>     
> >>>> Subject: Re: [rbridge] RBridge: a case of study
> >>>>
> >>>>
> >>>> ----- "Anoop Ghanwani" <[e-mail]> wrote:
> >>>>         
> >>>>>> -----Original Message-----
> >>>>>> From: [e-mail] 
> >>>>>> [mailto:[e-mail]] On Behalf Of James Carlson
> >>>>>> Sent: Tuesday, October 30, 2007 2:37 PM
> >>>>>> To: Silvano Gai
> >>>>>> Cc: Developing a hybrid router/bridge.; [e-mail]
> >>>>>> Subject: Re: [rbridge] RBridge: a case of study
> >>>>>>
> >>>>>> Silvano Gai writes:
> >>>>>>             
> >>>>>>> Radia,
> >>>>>>>
> >>>>>>> I have added few slides to the example and I suggest that 
> >>>>>>>               
> >>>>>> we use it as 
> >>>>>>             
> >>>>>>> a possible case of study for TRILL (of course, not the 
> >>>>>>>               
> >>>> only one).
> >>>>         
> >>>>>>> Let's see if the solutions we have discussed work on this
> >>>>>>>               
> >>>>> example.
> >>>>>           
> >>>>>>> The complete case of study is at:
> >>>>>>>
> >>>>>>> http://www.ip6.com/acme-example-v1.ppt
> >>>>>>>               
> >>>>>> I have a few narrow questions that I think might help me 
> >>>>>> understand this picture a bit better.  (I probably have more 
> >>>>>> questions once I know the narrow answers.  ;-})
> >>>>>>             
> >>>>> Let me take a shot at answering these.
> >>>>>
> >>>>>           
> >>>>>>   1.  After the proposed fix, should VLAN 3 on Cloud L 
> >>>>>>             
> >>> be bridged
> >>>       
> >>>>>>       together with VLAN 3 on Cloud R, even though 
> >>>>>>             
> >> the backbone
> >>     
> >>>>> itself
> >>>>>           
> >>>>>>       doesn't directly carry VLAN 3?  (I.e., are TRILL 
> >>>>>>             
> >>>> packets with
> >>>>         
> >>>>>>       outer VLAN ID 7 or 8 and with inner VLAN 3 
> >>>>>>             
> >> present on the
> >>     
> >>>>>>       backbone?)
> >>>>>>             
> >>>>> Yes, that's pretty much what ends up happening.  
> >>>>> We have effectively extended the bridged LAN.
> >>>>>
> >>>>>           
> >>>> Anoop, I'm reading the RBridge protocol specification 
> >>>>         
> >>> version 5 and it
> >>>       
> >>>> seems to me that your comment is inconsistent with the spec. 
> >>>> In section,
> >>>> 5.2.2.3, the spec says that the outer VLAN tag of TRILL data 
> >>>> frames has
> >>>> the same VID as the inner tag. Is this section going to 
> >>>>         
> >> be changed?
> >>     
> >>>> Futhermore, if we were to use different VIDs on outer VLAN 
> >>>> tags then we
> >>>> would need to handle the multi-destination case where one 
> >>>> would need to
> >>>> send a multi-destination frame per outer VID to communicate 
> >>>> with the RBs
> >>>> in the distribution tree which are using different VIDs. Is this
> >>>> correct?
> >>>>
> >>>> Thanks,
> >>>> Hern
> >>>> Fulcrum Microsystems
> >>>>
> >>>> _______________________________________________
> >>>> rbridge mailing list
> >>>> [e-mail]
> >>>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>>
> >>>> _______________________________________________
> >>>> rbridge mailing list
> >>>> [e-mail]
> >>>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>>
> >>>>         
> >>> _______________________________________________
> >>> rbridge mailing list
> >>> [e-mail]
> >>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>
> >>>       
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >   
> 
>