[rbridge] Proposed new milestones

[sgai at nuovasystems.com (Silvano Gai)]

My understanding was that we added a milestone to last call the frame
format before the end of the year.

-- Silvano

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Erik Nordmark
> Sent: Friday, August 31, 2007 9:00 AM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] Proposed new milestones
> 
> Any comments on these proposed new milestone dates? We discussed
> withdrawing the second milestone at and before Chicago. Do the dates
> look reasonable?
> 
> 
> Dec 2007	Submit architecture document to IEEE/IETF expert review
> 
> WITHDRAWN	Submit routing protocol requirements to the IESG for
> 		publication as an Informational RFC
> 
> Dec 2007	Submit problem statement and applicability to IESG for
> 		Informational RFC
> 
> Mar 2007	Submit architecture document to the IESG for publication
> 		as an Informational RFC
> 
> Done		Choose routing protocol(s) that can meet the
> 		requirements
> 
> Dec 2007	Submit base protocol specification to IEEE/IETF
> 		expert review
> 
> Mar 2008	Base protocol specification submitted to the
> 		IESG for publication as a Proposed Standard RFC
> 
> Dec 2008	Re-charter or shut down the WG
> 
> ------
> 
> For reference - the currently posted list of milestones are:
> Done	  	Accept base protocol specification as a WG document
> 
> Done	  	Accept problem statement and applicability as a WG work
> 		item
> 
> Done	  	Start work with routing area WG(s) to undertake TRILL
> 		extensions
> 
> Done	  	Accept architecture document as a WG work item
> 
> Done	  	Accept routing protocol requirements as a WG work item
> 
> Aug 2006	Submit architecture document to IEEE/IETF expert review
> 
> Aug 2006	Submit routing protocol requirements to the IESG for
> 		publication as an Informational RFC
> 
> Aug 2006	Submit problem statement and applicability to IESG for
> 		Informational RFC
> 
> Nov 2006	Submit architecture document to the IESG for publication
> 		as an Informational RFC
> 
> Dec 2006	Choose routing protocol(s) that can meet the
> 		requirements
> 
> Dec 2006	Submit base protocol specification to IEEE/IETF
> 		expert review
> 
> Mar 2007	Base protocol specification submitted to the
> 		IESG for publication as a Proposed Standard RFC
> 
> Jul 2007	Re-charter or shut down the WG
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l7VHscYQ028172 for <[e-mail]>; Fri, 31 Aug 2007 10:54:39 -0700 (PDT)
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: Fri, 31 Aug 2007 10:54:30 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Proposed new milestones
Thread-Index: Acfr6h2xl88pcYiSRuOhm1l6R/ig2wADb3Ww
References: <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Erik Nordmark" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l7VHscYQ028172
Subject: Re: [rbridge] Proposed new milestones
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, 31 Aug 2007 17:54:56 -0000
Status: RO
Content-Length: 2468

My understanding was that we added a milestone to last call the frame
format before the end of the year.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Erik Nordmark
> Sent: Friday, August 31, 2007 9:00 AM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] Proposed new milestones
> 
> Any comments on these proposed new milestone dates? We discussed
> withdrawing the second milestone at and before Chicago. Do the dates
> look reasonable?
> 
> 
> Dec 2007	Submit architecture document to IEEE/IETF expert review
> 
> WITHDRAWN	Submit routing protocol requirements to the IESG for
> 		publication as an Informational RFC
> 
> Dec 2007	Submit problem statement and applicability to IESG for
> 		Informational RFC
> 
> Mar 2007	Submit architecture document to the IESG for publication
> 		as an Informational RFC
> 
> Done		Choose routing protocol(s) that can meet the
> 		requirements
> 
> Dec 2007	Submit base protocol specification to IEEE/IETF
> 		expert review
> 
> Mar 2008	Base protocol specification submitted to the
> 		IESG for publication as a Proposed Standard RFC
> 
> Dec 2008	Re-charter or shut down the WG
> 
> ------
> 
> For reference - the currently posted list of milestones are:
> Done	  	Accept base protocol specification as a WG document
> 
> Done	  	Accept problem statement and applicability as a WG work
> 		item
> 
> Done	  	Start work with routing area WG(s) to undertake TRILL
> 		extensions
> 
> Done	  	Accept architecture document as a WG work item
> 
> Done	  	Accept routing protocol requirements as a WG work item
> 
> Aug 2006	Submit architecture document to IEEE/IETF expert review
> 
> Aug 2006	Submit routing protocol requirements to the IESG for
> 		publication as an Informational RFC
> 
> Aug 2006	Submit problem statement and applicability to IESG for
> 		Informational RFC
> 
> Nov 2006	Submit architecture document to the IESG for publication
> 		as an Informational RFC
> 
> Dec 2006	Choose routing protocol(s) that can meet the
> 		requirements
> 
> Dec 2006	Submit base protocol specification to IEEE/IETF
> 		expert review
> 
> Mar 2007	Base protocol specification submitted to the
> 		IESG for publication as a Proposed Standard RFC
> 
> Jul 2007	Re-charter or shut down the WG
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



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 l7VFxbsA018731 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Fri, 31 Aug 2007 08:59:37 -0700 (PDT)
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 l7VFxaxu027172 for <[e-mail]>; Fri, 31 Aug 2007 15:59:36 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 l7VFxauu659109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2007 08:59:36 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 31 Aug 2007 08:59:32 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 2.0b2 (X11/20070326)
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] Proposed new milestones
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, 31 Aug 2007 16:00:02 -0000
Status: RO
Content-Length: 1820

Any comments on these proposed new milestone dates? We discussed 
withdrawing the second milestone at and before Chicago. Do the dates 
look reasonable?


Dec 2007	Submit architecture document to IEEE/IETF expert review

WITHDRAWN	Submit routing protocol requirements to the IESG for
		publication as an Informational RFC

Dec 2007	Submit problem statement and applicability to IESG for
		Informational RFC

Mar 2007	Submit architecture document to the IESG for publication
		as an Informational RFC

Done		Choose routing protocol(s) that can meet the
		requirements

Dec 2007	Submit base protocol specification to IEEE/IETF
		expert review

Mar 2008	Base protocol specification submitted to the
		IESG for publication as a Proposed Standard RFC

Dec 2008	Re-charter or shut down the WG

------

For reference - the currently posted list of milestones are:
Done	  	Accept base protocol specification as a WG document

Done	  	Accept problem statement and applicability as a WG work
		item

Done	  	Start work with routing area WG(s) to undertake TRILL
		extensions

Done	  	Accept architecture document as a WG work item

Done	  	Accept routing protocol requirements as a WG work item

Aug 2006	Submit architecture document to IEEE/IETF expert review

Aug 2006	Submit routing protocol requirements to the IESG for
		publication as an Informational RFC

Aug 2006	Submit problem statement and applicability to IESG for
		Informational RFC

Nov 2006	Submit architecture document to the IESG for publication
		as an Informational RFC

Dec 2006	Choose routing protocol(s) that can meet the
		requirements

Dec 2006	Submit base protocol specification to IEEE/IETF
		expert review

Mar 2007	Base protocol specification submitted to the
		IESG for publication as a Proposed Standard RFC

Jul 2007	Re-charter or shut down the WG


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 l7V24AE6002787 for <[e-mail]>; Thu, 30 Aug 2007 19:04:10 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 30 Aug 2007 19:03:56 -0700 (PDT)
Received: from [129.150.17.145] ([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]; Thu, 30 Aug 2007 19:03:56 -0700 (PDT)
Date: Thu, 30 Aug 2007 19:04:58 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=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]> <[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]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 31 Aug 2007 02:04:26 -0000
Status: RO
Content-Length: 6709

I'm not sure it matters to find a common VLAN. I think what matters for 
non-DRBs is
that the DRB hears you. What matters for the DRB is that all the other 
RBs hears you.

So for instance, it might be that DRB R1 transmits on {2, 3, and 4}, and 
R3 can't hear VLAN 2,
and R2 can't hear VLAN 2. It could be that if everyone transmitted on 
VLAN 4 that everyone
would hear each other, but that by the "reporting lowest VLAN ID" R1 
convinces R2 to send
Hellos on VLAN 2 and convinces R3 to send Hellos on VLAN 3, that it will 
wind up
that when R2 needs to forward to R3 on that layer 2 cloud there will be 
a one-hop suboptimality
(since when R2 needs to forward to R3 it will send to the DRB, R1).
Frankly, I don't care about that case. It works...it's just suboptimal. 
And if some customer
has specifically created partitioned VLANs consciously through careful 
configuration of
bridges, and they care about the one hop suboptimality, they can 
configure the RBridges to all
talk on 4.

I was also worried about how long an IS-IS Hello that applied to lots of 
different VLANs
might become in the most general conceivable case, if in one Hello R1 
announced a bunch
of different priorities, and then for each priority, a set of VLANs it 
applied to, with the VLAN
tags such that there was no way to aggregate them.

So I'd propose to say that if an RBridge is configured to have a 
different priority for one set
of VLANs than another, it will issue a different Hello. And also, that 
the VLANs for which
you are a particular priority must be in one range. The only reason to 
have multiple priorities
is for load splitting, and so there's no reason for standing one our 
head to allow someone to
configure priority x for all the even VLANs and y for all the odd VLANs.

So that means that a Hello will contain "my priority, range of VLAN tags 
this Hello applies to"
(where "range" is a low number and a high number of the range of VLAN 
tags, so it's only
4 bytes).

And there is also the list of neighbors you have heard Hellos from, 
along with the lowest
VLAN tag that you've heard from them. You *could* transmit on all the 
potential VLAN
tags you need in order to talk to all the neighbors reported in the 
DRB's Hello. So, in the
example in the 2nd paragraph above, R1 (the DRB) announces it hears from 
R2 on VLAN 2
and R3 on VLAN 3. We then could specify that R2 just transmits on VLAN 
2, and
R3 just transmits on VLAN 3. Or we could say that if R2 sees another 
non-DRB listed
in R1's Hello and R2 doesn't hear that one, that R2 could try sending 
Hellos on other
VLAN tags to see if it can create an adjacency to R3. But again, I'd 
have R2 declare
victory if R2 found a VLAN tag that the DRB can hear it on, and have R2 
just transmit
on a single VLAN tag (until it loses connectivity to the DRB).

So the rule I'm proposing is
a) initially there might be a set of VLAN tags to transmit on. This is 
either that the default
is to transmit on every VLAN tag that you support on that layer 2 cloud, 
or that the default
is to only transmit untagged, or on VLAN tag 1, and you have to be 
configured to transmit on more
VLANs than that. If you are configured (or the default is that) to only 
transmit with one VLAN
tag, then we don't need b)

b) if you are configured with a different priority for one set of VLANs 
than another, you
transmit a separate Hello for each priority, listing the range of VLANs 
that Hello applies to.
If you believe yourself to be DRB, then you continue to send on all the 
VLANs that you
are configured to send on for that priority. If you lose the DRB 
election for some set of
VLANs, then you only transmit on the VLAN tag that the DRB says to 
transmit on.
One bizarreness is that R1 might be priority 5 for VLANs {a, b, c, d, e, 
f, g}, and
R2 might be priority 4 for VLANs {a, b, c,} and priority 6 for {d, e, f, g}.
In that case (assuming lower number priority wins), R1 will be DRB for 
VLANs {d,e,f,g}
and R2 would be DRB for VLANs {a, b, c}. And in R1's pseudonode it only 
reports
{d,e,f,g} as attached VLANs, and R2 reports {a, b, c}

We need to come up with a concrete proposal for all these things, and 
hopefully soon. I think
we haven't reached consensus, though I don't think anyone's opinions 
differ by a lot. I think
the only contentious thing is what the default is.

Anyway, this is long enough -- see if people agree with this, which is 
basically a proposal
for having the DRB always send on all the VLANs it is configured to send 
Hellos on, and
non-DRBs start sending on all the VLANs they are configured to send 
Hellos on, but stop
when the DRB lets them know of a VLAN tag that works, and thenceforth 
only sends
on that one VLAN tag.

Radia


James Carlson wrote:
> Eastlake III Donald-LDE008 writes:
>   
>> So, thinking some more about what I said below, about only reporting the
>> lowest numbered VLAN seen in Hellos from a particular other Rbridge, I
>> was considering only the pairwise case. If it is just two Rbridges with
>> a bridged LAN between then, then indeed reporting only the lowest
>> numbered VLAN on which you heard a Hello from a neighbor in fine. But
>> this is insufficient in the general case. Consider the following
>> symmetric connectivity
>>
>>  RB    VLANs    RB
>>   A     2, 3     B
>>   A        3     C
>>
>> If RB-A and RB-B just report the lowest numbered VLAN on which they see
>> each other, it will be VLAN 2. But for RB-A and RB-C, it would be VLAN
>> 3. However, if RB-A multicasts on both VLAN 2 and 3, which the
>> information would indicate it should, RB-B will get two copies. In this
>> case, RB-A should only multicast on VLAN 3, but it can't tell that.
>>     
>
> I think this could still be made to work by having the RBs remove
> VLANs from their candidate set of lowest-common-VLAN numbers as they
> see Hellos disproving the original contention.
>
> Thus, when RB-A sees VLAN 2 from RB-B, it tentatively believes this to
> be the lowest common number.  When it sees VLAN 3 from RB-C, it must
> now eliminate all those candidate VLANs less then 3 (just ID 2 in this
> example) and start upwards from there -- now saying that VLAN 3 is the
> minimum.
>
> If you get to 4095, then there's nothing in common; stop and report
> error.
>
> You could make it more robust by including the minimum VLAN number
> along with the "LAN ADDRESS" Intermediate System Neighbours in the
> Hello.  When RB-A sends a Hello indicating that it can hear RB-C on
> a minimum VLAN 3, RB-B knows that numbers below 3 aren't useful.
>
> If someone actually configures a system where 4094 really is the
> minimum common VLAN and all the others are allocated, well, I think he
> gets what he deserves.
>
>   



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 l7UMWrSr001204 for <[e-mail]>; Thu, 30 Aug 2007 15:32:53 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.17.57]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7UMWqXw002160 for <[e-mail]>; Thu, 30 Aug 2007 22:32:53 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 l7UMWqpp601502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Aug 2007 15:32:52 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 30 Aug 2007 15:32:52 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 2.0b2 (X11/20070326)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Draft minutes posted
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
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, 30 Aug 2007 22:33:24 -0000
Status: RO
Content-Length: 90

at
http://www3.ietf.org/proceedings/07jul/minutes/trill.txt

Any corrections?

    Erik



Received: from sweeper2.calix.local (sweeper2.calix.com [208.201.250.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l7O3SHcl029940 for <[e-mail]>; Thu, 23 Aug 2007 20:28:17 -0700 (PDT)
Received: from PETWM02.calix.local (petwm02.calix.local [172.21.50.133]) by sweeper2.calix.local (Clearswift SMTPRS 5.2.5) with ESMTP id <[e-mail]>;  Thu, 23 Aug 2007 20:28:16 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E5FE.CF588A08"
Date: Thu, 23 Aug 2007 20:28:16 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] RSTP BRIDGE not receiving BPDUs
Thread-Index: Acfl4oK+JHoOByjcTa+r3Iwng6ziYwAAg86gAAIB+CAABEpTLQ==
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Amit Gupta" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] RSTP BRIDGE not receiving BPDUs
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, 24 Aug 2007 03:28:44 -0000
Status: RO
Content-Length: 9272

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7E5FE.CF588A08
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The scenario here is that the2 bridges are connected in a ring topology =
with eaps providing the ring protection while RSTP is providing the =
uplink/downlink protection. The reason the other port is not receiving =
the BPDU is because the EAPS is blocking one of the links to avoid loops =
in the ring.Thus even though the each bridge has 2 paths 2 reach the =
other but at any given time will only be able to receive BPDU from the =
path that is not blocked by EAPS. so thats why I was wondering what =
state/role would be the port that is not receiving the BPDU.=20
Will it keep sending the Hello BPDU even though it is not receiving any =
?
=20

________________________________

From: Eastlake III Donald-LDE008 [mailto:[e-mail]]
Sent: Thu 8/23/2007 6:28 PM
To: Amit Gupta
Cc: [e-mail]
Subject: RE: [rbridge] RSTP BRIDGE not receiving BPDUs


Well, I'm sure there are people on this list who could help you but this =
is really not the 802.1 mailing list, which would seem more appropriate.
=20
It is a generally characteristic of STP protocols that the loss of =
frames leads to ports becoming enabled. So, while I am not an RSTP =
expert, I would guess that in the normal case the port not receiving =
BPDUs would end up in Forwarding state and would believe itself to be =
root unless their is a better root visible out some other port...
=20
But I could be wrong and maybe I am misunderstanding you.... I am =
assuming you mean "2 bridges are interconnected and of the 2 ports only =
1 port on *one* bridge is receiving BPDU's" but in your statement in the =
message below, you say "each" rather than "one" which seems =
inconsistent.
=20
On wonders what is blocking the BPDUs and why the one hop physical link =
between the bridges is letting BPDUs through in only on direction and =
not the other...
=20
Donald

________________________________

From: [e-mail] [mailto:[e-mail]] On =
Behalf Of Amit Gupta
Sent: Thursday, August 23, 2007 8:21 PM
To: [e-mail]
Subject: Re: [rbridge] RSTP BRIDGE not receiving BPDUs



It is a very basic question. What would be the state and role of a port =
if you stop receiving the RSTP BPDU's on that bridge port.

If 2 bridges are interconnected and of the 2 ports only 1 port on each =
bridge is receiving BPDU's , will that cause any issues ?

=20

Thanks,

-A

=20


------_=_NextPart_001_01C7E5FE.CF588A08
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">=0A=
<HTML                                                                    =
                                                                         =
     ><HEAD>=0A=
=0A=
<META content=3D"MSHTML 6.00.2900.3132" name=3DGENERATOR>=0A=
<STYLE>=0A=
P.MsoNormal {=0A=
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"=0A=
}=0A=
LI.MsoNormal {=0A=
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"=0A=
}=0A=
DIV.MsoNormal {=0A=
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"=0A=
}=0A=
A:link {=0A=
	COLOR: blue; TEXT-DECORATION: underline=0A=
}=0A=
SPAN.MsoHyperlink {=0A=
	COLOR: blue; TEXT-DECORATION: underline=0A=
}=0A=
A:visited {=0A=
	COLOR: purple; TEXT-DECORATION: underline=0A=
}=0A=
SPAN.MsoHyperlinkFollowed {=0A=
	COLOR: purple; TEXT-DECORATION: underline=0A=
}=0A=
SPAN.EmailStyle17 {=0A=
	COLOR: windowtext; FONT-FAMILY: Arial;}=0A=
SPAN.EmailStyle18 {=0A=
	COLOR: navy; FONT-FAMILY: Arial;}=0A=
DIV.Section1 {=0A=
	page: Section1=0A=
}=0A=
</STYLE>=0A=
</HEAD>=0A=
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>=0A=
<DIV id=3DidOWAReplyText86668 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>The scenario =
here is that =0A=
the2 bridges are connected in a ring topology with eaps providing the =
ring =0A=
protection while RSTP is providing the uplink/downlink protection. The =
reason =0A=
the other port is not receiving the BPDU is because the EAPS is blocking =
one of =0A=
the links to avoid loops in the ring.Thus even though the each bridge =
has 2 =0A=
paths 2 reach the other but at any given time will only be able to =
receive BPDU =0A=
from the path that is not blocked by EAPS. so thats why I was wondering =
what =0A=
state/role would be the port that is not receiving the BPDU. =
</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Will it keep sending the =
Hello BPDU even =0A=
though it is not receiving any ?</FONT></DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> Eastlake III Donald-LDE008 =0A=
[mailto:[e-mail]]<BR><B>Sent:</B> Thu 8/23/2007 6:28 =0A=
PM<BR><B>To:</B> Amit Gupta<BR><B>Cc:</B> =
[e-mail]<BR><B>Subject:</B> =0A=
RE: [rbridge] RSTP BRIDGE not receiving BPDUs<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN =0A=
class=3D965551701-24082007>Well, I'm sure there are people on this list =
who could =0A=
help you but this is really not the 802.1 mailing list, which would seem =
more =0A=
appropriate.</SPAN></FONT></DIV>=0A=
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN =0A=
class=3D965551701-24082007></SPAN></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN =0A=
class=3D965551701-24082007>It is a generally characteristic of STP =
protocols that =0A=
the loss of frames leads to ports becoming enabled. So, while I am not =
an RSTP =0A=
expert, I would guess that in the normal case the port not receiving =
BPDUs would =0A=
end up in Forwarding state and would believe itself to be root unless =
their is a =0A=
better root visible out some other port...</SPAN></FONT></DIV>=0A=
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN =0A=
class=3D965551701-24082007></SPAN></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN =0A=
class=3D965551701-24082007>But I could be wrong and maybe I am =
misunderstanding =0A=
you.... I am assuming you mean "2 bridges are interconnected and of the =
2 ports =0A=
only 1 port on *one* bridge is receiving BPDU&#8217;s" but in your =
statement in the =0A=
message below, you say "each" rather than "one" which seems =0A=
inconsistent.</SPAN></FONT></DIV>=0A=
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN =0A=
class=3D965551701-24082007></SPAN></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN =0A=
class=3D965551701-24082007>On wonders what is blocking the BPDUs and why =
the one =0A=
hop physical link between the bridges is letting BPDUs through in only =
on =0A=
direction and not the other...</SPAN></FONT></DIV>=0A=
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN =0A=
class=3D965551701-24082007></SPAN></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN =0A=
class=3D965551701-24082007>Donald</SPAN></FONT></DIV><BR>=0A=
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =0A=
[mailto:[e-mail]] <B>On Behalf Of </B>Amit =0A=
Gupta<BR><B>Sent:</B> Thursday, August 23, 2007 8:21 PM<BR><B>To:</B> =0A=
[e-mail]<BR><B>Subject:</B> Re: [rbridge] RSTP BRIDGE not =
receiving =0A=
BPDUs<BR></FONT><BR></DIV>=0A=
<DIV></DIV>=0A=
<DIV class=3DSection1>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">It is a very =
basic =0A=
question. </SPAN></FONT><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">What would be the state =
and role of =0A=
a port if you stop receiving the RSTP BPDU&#8217;s on that bridge =0A=
port.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">If 2 bridges are =
interconnected and =0A=
of the 2 ports only 1 port on each bridge is receiving BPDU&#8217;s , =
will that cause =0A=
any issues ?</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thanks,</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">-A</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P></DIV></DIV></BODY></HTML>=0A=

------_=_NextPart_001_01C7E5FE.CF588A08--


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 l7O1SLqc029434 for <[e-mail]>; Thu, 23 Aug 2007 18:28:21 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-9.tower-153.messagelabs.com!1187918899!5983525!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 29311 invoked from network); 24 Aug 2007 01:28:19 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-153.messagelabs.com with SMTP; 24 Aug 2007 01:28: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 l7O1SJui025801 for <[e-mail]>; Thu, 23 Aug 2007 18:28:19 -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 l7O1SJmA008316 for <[e-mail]>; Thu, 23 Aug 2007 20:28:19 -0500 (CDT)
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 l7O1SI28008303 for <[e-mail]>; Thu, 23 Aug 2007 20:28:18 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E5EE.0C9BCDAA"
Date: Thu, 23 Aug 2007 21:28:16 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] RSTP BRIDGE not receiving BPDUs
thread-index: Acfl4oK+JHoOByjcTa+r3Iwng6ziYwAAg86gAAIB+CA=
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Amit Gupta" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] RSTP BRIDGE not receiving BPDUs
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, 24 Aug 2007 01:28:41 -0000
Status: RO
Content-Length: 6984

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7E5EE.0C9BCDAA
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Well, I'm sure there are people on this list who could help you but this
is really not the 802.1 mailing list, which would seem more appropriate.
=20
It is a generally characteristic of STP protocols that the loss of
frames leads to ports becoming enabled. So, while I am not an RSTP
expert, I would guess that in the normal case the port not receiving
BPDUs would end up in Forwarding state and would believe itself to be
root unless their is a better root visible out some other port...
=20
But I could be wrong and maybe I am misunderstanding you.... I am
assuming you mean "2 bridges are interconnected and of the 2 ports only
1 port on *one* bridge is receiving BPDU's" but in your statement in the
message below, you say "each" rather than "one" which seems
inconsistent.
=20
On wonders what is blocking the BPDUs and why the one hop physical link
between the bridges is letting BPDUs through in only on direction and
not the other...
=20
Donald

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Amit Gupta
Sent: Thursday, August 23, 2007 8:21 PM
To: [e-mail]
Subject: Re: [rbridge] RSTP BRIDGE not receiving BPDUs



It is a very basic question. What would be the state and role of a port
if you stop receiving the RSTP BPDU's on that bridge port.

If 2 bridges are interconnected and of the 2 ports only 1 port on each
bridge is receiving BPDU's , will that cause any issues ?

=20

Thanks,

-A

=20


------_=_NextPart_001_01C7E5EE.0C9BCDAA
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3132" name=3DGENERATOR>
<STYLE>@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in =
1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D965551701-24082007>Well, I'm sure there are people on this list =
who could=20
help you but this is really not the 802.1 mailing list, which would seem =
more=20
appropriate.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D965551701-24082007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D965551701-24082007>It is a generally characteristic of STP =
protocols that=20
the loss of frames leads to ports becoming enabled. So, while I am not =
an RSTP=20
expert, I would guess that in the normal case the port not receiving =
BPDUs would=20
end up in Forwarding state and would believe itself to be root unless =
their is a=20
better root visible out some other port...</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
class=3D965551701-24082007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D965551701-24082007>But I could be wrong and maybe I am =
misunderstanding=20
you.... I am assuming you mean "2 bridges are interconnected and of the =
2 ports=20
only 1 port on *one* bridge is receiving BPDU&#8217;s" but in your =
statement in the=20
message below, you say "each" rather than "one" which seems=20
inconsistent.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D965551701-24082007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D965551701-24082007>On wonders what is blocking the BPDUs and why =
the one=20
hop physical link between the bridges is letting BPDUs through in only =
on=20
direction and not the other...</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D965551701-24082007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D965551701-24082007>Donald</SPAN></FONT></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
[mailto:[e-mail]] <B>On Behalf Of </B>Amit=20
Gupta<BR><B>Sent:</B> Thursday, August 23, 2007 8:21 PM<BR><B>To:</B>=20
[e-mail]<BR><B>Subject:</B> Re: [rbridge] RSTP BRIDGE not =
receiving=20
BPDUs<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DSection1>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">It is a very =
basic=20
question. </SPAN></FONT><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">What would be the state =
and role of=20
a port if you stop receiving the RSTP BPDU&#8217;s on that bridge=20
port.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">If 2 bridges are =
interconnected and=20
of the 2 ports only 1 port on each bridge is receiving BPDU&#8217;s , =
will that cause=20
any issues ?<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">-A<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BODY></HTML>

------_=_NextPart_001_01C7E5EE.0C9BCDAA--


Received: from sweeper2.calix.local (sweeper2.calix.com [208.201.250.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l7O0LHiY012632 for <[e-mail]>; Thu, 23 Aug 2007 17:21:17 -0700 (PDT)
Received: from PETWM02.calix.local (petwm02.calix.local [172.21.50.133]) by sweeper2.calix.local (Clearswift SMTPRS 5.2.5) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 23 Aug 2007 17:21:17 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E5E4.B007DA56"
Date: Thu, 23 Aug 2007 17:21:16 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] RSTP BRIDGE not receiving BPDUs
Thread-Index: Acfl4oK+JHoOByjcTa+r3Iwng6ziYwAAg86g
References: <[e-mail]>
From: "Amit Gupta" <[e-mail]>
To: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] RSTP BRIDGE not receiving BPDUs
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, 24 Aug 2007 00:21:37 -0000
Status: RO
Content-Length: 2910

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7E5E4.B007DA56
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

It is a very basic question. What would be the state and role of a port
if you stop receiving the RSTP BPDU's on that bridge port.

If 2 bridges are interconnected and of the 2 ports only 1 port on each
bridge is receiving BPDU's , will that cause any issues ?

=20

Thanks,

-A

=20


------_=_NextPart_001_01C7E5E4.B007DA56
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>It is a very basic question. =
</span></font><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>What would
be the state and role of a port if you stop receiving the RSTP =
BPDU&#8217;s on
that bridge port.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>If 2 bridges are interconnected and of the 2 ports =
only 1
port on each bridge is receiving BPDU&#8217;s , will that cause any =
issues ?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>-A<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C7E5E4.B007DA56--


Received: from sweeper2.calix.local (sweeper2.calix.com [208.201.250.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l7O06fgP008494 for <[e-mail]>; Thu, 23 Aug 2007 17:06:41 -0700 (PDT)
Received: from PETWM02.calix.local (petwm02.calix.local [172.21.50.133]) by sweeper2.calix.local (Clearswift SMTPRS 5.2.5) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 23 Aug 2007 17:06:41 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E5E2.82FF5108"
Date: Thu, 23 Aug 2007 17:05:42 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RSTP BRIDGE not receiving BPDUs
Thread-Index: Acfl4oK+JHoOByjcTa+r3Iwng6ziYw==
From: "Amit Gupta" <[e-mail]>
To: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] RSTP BRIDGE not receiving BPDUs
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, 24 Aug 2007 00:07:13 -0000
Status: RO
Content-Length: 2612

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7E5E2.82FF5108
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

What would be the state of a port if you stop receiving the RSTP BPDU's
on that bridge port.

If 2 bridges are interconnected and of the 2 ports only 1 port on each
bridge is receiving BPDU's , will that cause any issues ?

=20

=20

Thanks,

-A


------_=_NextPart_001_01C7E5E2.82FF5108
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>What would be the state of a port if you stop =
receiving the
RSTP BPDU&#8217;s on that bridge port.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>If 2 bridges are interconnected and of the 2 ports =
only 1
port on each bridge is receiving BPDU&#8217;s , will that cause any =
issues ?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>-A<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C7E5E2.82FF5108--


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 l7MLHI5S009127 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Wed, 22 Aug 2007 14:17:19 -0700 (PDT)
Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l7MLHIav018941 for <[e-mail]>; Wed, 22 Aug 2007 21:17:18 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id l7MLGfmu002618 for <[e-mail]>; Wed, 22 Aug 2007 17:16:56 -0400 (EDT)
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 l7MKkESK003087; Wed, 22 Aug 2007 16:46:14 -0400 (EDT)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l7MKkDm3003084; Wed, 22 Aug 2007 16:46:13 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 22 Aug 2007 16:46:13 -0400
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]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <"<3870C46029D1F945B1472F170D2D979002EE39FC"@de01exm64.ds.mot.com> <[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: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with	all the VLAN tags
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, 22 Aug 2007 21:18:21 -0000
Status: RO
Content-Length: 2117

Eastlake III Donald-LDE008 writes:
> So, thinking some more about what I said below, about only reporting the
> lowest numbered VLAN seen in Hellos from a particular other Rbridge, I
> was considering only the pairwise case. If it is just two Rbridges with
> a bridged LAN between then, then indeed reporting only the lowest
> numbered VLAN on which you heard a Hello from a neighbor in fine. But
> this is insufficient in the general case. Consider the following
> symmetric connectivity
> 
>  RB    VLANs    RB
>   A     2, 3     B
>   A        3     C
> 
> If RB-A and RB-B just report the lowest numbered VLAN on which they see
> each other, it will be VLAN 2. But for RB-A and RB-C, it would be VLAN
> 3. However, if RB-A multicasts on both VLAN 2 and 3, which the
> information would indicate it should, RB-B will get two copies. In this
> case, RB-A should only multicast on VLAN 3, but it can't tell that.

I think this could still be made to work by having the RBs remove
VLANs from their candidate set of lowest-common-VLAN numbers as they
see Hellos disproving the original contention.

Thus, when RB-A sees VLAN 2 from RB-B, it tentatively believes this to
be the lowest common number.  When it sees VLAN 3 from RB-C, it must
now eliminate all those candidate VLANs less then 3 (just ID 2 in this
example) and start upwards from there -- now saying that VLAN 3 is the
minimum.

If you get to 4095, then there's nothing in common; stop and report
error.

You could make it more robust by including the minimum VLAN number
along with the "LAN ADDRESS" Intermediate System Neighbours in the
Hello.  When RB-A sends a Hello indicating that it can hear RB-C on
a minimum VLAN 3, RB-B knows that numbers below 3 aren't useful.

If someone actually configures a system where 4094 really is the
minimum common VLAN and all the others are allocated, well, I think he
gets what he deserves.

-- 
James Carlson, Solaris Networking              <[e-mail]>
Sun Microsystems / 1 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 l7MKFAFb021164 for <[e-mail]>; Wed, 22 Aug 2007 13:15:10 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-14.tower-128.messagelabs.com!1187813709!14697132!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 6602 invoked from network); 22 Aug 2007 20:15:09 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-128.messagelabs.com with SMTP; 22 Aug 2007 20:15:09 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l7MKF5IX008152 for <[e-mail]>; Wed, 22 Aug 2007 13:15:09 -0700 (MST)
Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l7MKF4FE024935 for <[e-mail]>; Wed, 22 Aug 2007 15:15:04 -0500 (CDT)
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 l7MKF4Ji024919 for <[e-mail]>; Wed, 22 Aug 2007 15:15:04 -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: Wed, 22 Aug 2007 16:15:03 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
thread-index: Acfe/qLNwm4jwSdHShy82bBBZAjY5wBOb0tAACvU04A=
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]><[e-mail]><[e-mail]><46C28DAA.5050503@sun. com> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Vontu: Pass
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 l7MKFAFb021164
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 22 Aug 2007 20:15:18 -0000
Status: RO
Content-Length: 5397

So, thinking some more about what I said below, about only reporting the
lowest numbered VLAN seen in Hellos from a particular other Rbridge, I
was considering only the pairwise case. If it is just two Rbridges with
a bridged LAN between then, then indeed reporting only the lowest
numbered VLAN on which you heard a Hello from a neighbor in fine. But
this is insufficient in the general case. Consider the following
symmetric connectivity

 RB    VLANs    RB
  A     2, 3     B
  A        3     C

If RB-A and RB-B just report the lowest numbered VLAN on which they see
each other, it will be VLAN 2. But for RB-A and RB-C, it would be VLAN
3. However, if RB-A multicasts on both VLAN 2 and 3, which the
information would indicate it should, RB-B will get two copies. In this
case, RB-A should only multicast on VLAN 3, but it can't tell that.

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Thursday, August 16, 2007 4:42 PM
To: Radia Perlman
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
withall the VLAN tags

See below at @@@

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Wednesday, August 15, 2007 1:23 AM
To: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
with all the VLAN tags

...


So here's an attempt at writing how that would work.

a) accept Hellos tagged with any VLAN tag

b) in your Hello, in which you list the IS-IS neighbors you
have heard Hellos from, list at least one VLAN tag for each neighbor
with which you have heard a Hello.

!!!Question: should you list *all* VLAN
tags that you've heard from that neighbor? Or is it fine to just list
one?
I'd suggest that you should list only one: the lowest numbered VLAN that

you've heard
from that neighbor on?!!!

@@@ I think it should be OK to list just one. For example, assume that
RB-a and RB-b are connected by a bridged LAN and are configured on their
ports to egress tagged native frames for VLAN 2 and 3 and to send Hellos
on those VLANs. (If they are also sending untagged frames, assume they
won't get through either way.) If the bridged LAN is providing full
connectivity, they should both see both Hellos, report VLAN 2, and
settle on using VLAN 2 tagged TRILL frames to communicate. Even if the
bridged LAN is acting like a pair of diodes and, for these ports, only
VLAN 2 gets from RB-a to RB-b but only VLAN 3 gets from RB-b to RB-a,
this is quite obvious and the Rbridges can communicate with appropriate
tagged frames. (It is left as an exercise for the reader to show that
other combinations of diodes, etc., work as long at least one tagging of
Hellos can get through in each direction.)

@@@ A few things occur to me thinking about this: If some Hellos are
getting through from RB-a to RB-b, and vice versa, then what RB-a wants
to know from RB-b is the "tagging" (or rather at least one of the
taggings) with which RB-a is sending Hellos that get through. It could
be that, if RB-a is sending frames tagged as VLAN 3, the tagging is
being stripped and they are being successfully received by RB-b but in
an untagged form. It could be that, of all the Hellos RB-a is sending on
this port, only the untagged ones are getting through to RB-b in which
case they might be arriving at RB-b untagged or tagged as being in some
arbitrary VLAN X. It could be that the only Hellos emitted by RB-a on
this port that get to RB-b are those sent tagged as VLAN X but they
arrive at RB-b tagged as VLAN Y. (This last is, I think, much less
likely than the others so we may not want to go to any extra trouble to
fix it but I think the same solution as for the other cases fixes it
also.)

@@@ All these cases point to a requirement that the outer VLAN tagging
status of a TRILL core IS-IS Hello when it is emitted must be noted
inside the TRILL encapsulation somewhere. The obvious place to put this
in the current design would be the inner VLAN tag but we have already
decided to use that to indicate per VLAN IS-IS messages as distinguished
from core IS-IS. (All of this discussion is about core instance IS-IS
Hellos.) This leaves approximately three choices: (1) revise the design
so that core versus per VLAN IS-IS instances are distinguished by a
TRILL Header flag bit and the inner VLAN tag in a core IS-IS Hellos
indicates the VLAN with which it was initially sent; (2) put the initial
VLAN tagging ID info inside the Hellos; or (3) something even more
disruptive to the current design. (Minor note: you would need some way
to indicate that a frame was not tagged with a VLAN ID. The obvious way
to do this is with the null VLAN ID, zero, as is done in a priority
tag.)

@@@ You don't have to worry about this for any other IS-IS PDUs besides
Hellos. The Hellos would map the topology and tell you what tagging to
use for other IS-IS PDU types. You don't have to worry about this for
any optional per VLAN IS-IS instances. They use the core IS-IS
determined topology and transport.

@@@ Also, if you can tell there are no intervening bridges, which I
believe can be fairly easily determined with 802.1AB, then just sending
truly untagged TRILL IS-IS frames is the way to go; there is no reason
to even priority tag them.

...

@@@ Donald



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l7KI6iT7028303 for <[e-mail]>; Mon, 20 Aug 2007 11:06:44 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 20 Aug 2007 11:06:44 -0700
X-IronPort-AV: i="4.19,285,1183359600";  d="scan'208"; a="12100591:sNHT19698119"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 2F1A5238381; Mon, 20 Aug 2007 11:06:44 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 20 Aug 2007 11:06:44 -0700
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, 20 Aug 2007 11:06:25 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
Thread-Index: AcfiLF05icHAyQP1ToG9geh3RNPfLwBJzoKg
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]> <[e-mail]> <[e-mail] > <46C7E [e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Silvano Gai" <[e-mail]>
X-OriginalArrivalTime: 20 Aug 2007 18:06:44.0000 (UTC) FILETIME=[DDB91200:01C7E354]
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 l7KI6iT7028303
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 20 Aug 2007 18:07:16 -0000
Status: RO
Content-Length: 2182

 

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]] 
> Sent: Saturday, August 18, 2007 11:45 PM
> To: Silvano Gai
> Cc: Eastlake III Donald-LDE008; Anoop Ghanwani; [e-mail]
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos 
> tagged with all the VLAN tags
> 
> Some thoughts...
> 
> Remind me again what was wrong with the rule "you participate 
> in the bridge spanning tree algorithm, and become DRB if and 
> only if you are root bridge".? That seems to avoid the 
> necessity of sending 4000 Hellos, or specifying in the Hellos 
> "these are all the VLAN tags I can hear each of my neighbors on".

There is no problem with that (at least not one
that I can see).  In fact, that would address
Dinesh's problem very well.  The only issue is that it
imposes on the user a network design issue which says:
"if you have RBridges in the network, then one of
them is going to be your STP root."  This may or
may not be desireable based on the network design.

> I guess if you want to do load splitting so that R1 is DRB 
> for VLAN A and R2 is DRB for VLAN B that might be tricky if 
> there's only one spanning tree instance on the layer 2 cloud.
> 
> But it does seem as though "become DRB iff you are the root 
> of the spanning tree" is the most robust solution. It doesn't 
> seem to require sending Hellos for every possible VLAN tag.
> 
> Also, having multiple DRBs for load splitting -- shouldn't we 
> be scared about the case where bridge configuration can turn 
> a VLAN A tag into a VLAN B tag?

I don't think this is a concern.  First off, a standard
bridge does not swap C-tags.  This function is only
allowed for S-tags.  That said, this is a feature that
must be carefully configured/managed by the operator.

Basically a VLAN A tag in one portion of the network
is equivalent to the VLAN B tag in the other portion
of the network.  This tends to be useful when joining
two networks; e.g. if I have 2 networks X & Y with VLANs
1-100 configured and I want to join them, at the
bridge that joins them, I will translate VLAN X's
1-100 so that they show up at 1001-1100 in VLAN Y's
network, and vice versa.

Anoop



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 l7KHvmaI025135 for <[e-mail]>; Mon, 20 Aug 2007 10:57:48 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 20 Aug 2007 10:57:47 -0700
X-IronPort-AV: i="4.19,285,1183359600";  d="scan'208"; a="16943702:sNHT25600708"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 86FBD238381; Mon, 20 Aug 2007 10:57:47 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 20 Aug 2007 10:57:47 -0700
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, 20 Aug 2007 10:57:29 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
Thread-Index: AcfiLF0RoLsbneu8Rm6zaUk112dXsgAsT9wgAB1f2LA=
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]> <[e-mail]> <[e-mail] > <46C7 E6F8.3000909 @sun.com> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 20 Aug 2007 17:57:47.0391 (UTC) FILETIME=[9DE108F0:01C7E353]
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 l7KHvmaI025135
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 20 Aug 2007 17:58:21 -0000
Status: RO
Content-Length: 2259

 

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Sunday, August 19, 2007 8:57 PM
> To: Radia Perlman
> Cc: Eastlake III Donald-LDE008; Anoop Ghanwani; [e-mail]
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos 
> tagged with all the VLAN tags
> 
> Radia,
> 
> You need to understand what type of ST is run in the network.
> If it is per-VLAN ST, you need to send 4,000 BPDUs, worst 
> than sending 4000 Hellos.
> If you don't understand the ST configuration, you will have loops.

Thought it might be useful to point out that per-VLAN ST
is a proprietary technology.

> P.S. I don't know why we are so stubborn on the 4000. By 
> default there is only VLAN 1 and we have other VLANs only if 
> explicitly configured.

Because most folks won't use the switch with it's default
configuration.  They configure many VLANs (100's is very 
typical) before actually deploying in the network.

Anoop

> 
> > -----Original Message-----
> > From: Radia Perlman [mailto:[e-mail]]
> > Sent: Saturday, August 18, 2007 11:45 PM
> > To: Silvano Gai
> > Cc: Eastlake III Donald-LDE008; Anoop Ghanwani; [e-mail]
> > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> with
> > all the VLAN tags
> > 
> > Some thoughts...
> > 
> > Remind me again what was wrong with the rule "you 
> participate in the 
> > bridge spanning tree algorithm, and become DRB if and only 
> if you are 
> > root bridge".? That seems to avoid the necessity of sending 4000 
> > Hellos, or specifying in the Hellos "these
> are
> > all the VLAN
> > tags I can hear each of my neighbors on".
> > 
> > I guess if you want to do load splitting so that R1 is DRB 
> for VLAN A 
> > and R2 is DRB for VLAN B that might be tricky if there's only one 
> > spanning tree instance on the layer 2 cloud.
> > 
> > But it does seem as though "become DRB iff you are the root of the 
> > spanning tree" is the most robust solution. It doesn't seem 
> to require 
> > sending Hellos for every possible VLAN tag.
> > 
> > Also, having multiple DRBs for load splitting -- shouldn't we be
> scared
> > about the case where
> > bridge configuration can turn a VLAN A tag into a VLAN B tag?
> > 
> > Radia
> 



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l7K3vXGh010286 for <[e-mail]>; Sun, 19 Aug 2007 20:57:33 -0700 (PDT)
Content-class: urn:content-classes:message
Date: Sun, 19 Aug 2007 20:56:40 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.5
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
Thread-Index: AcfiLF0RoLsbneu8Rm6zaUk112dXsgAsT9wg
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]> <[e-mail]> <[e-mail]> <46C7E [e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l7K3vXGh010286
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 20 Aug 2007 03:57:50 -0000
Status: RO
Content-Length: 1591

Radia,

You need to understand what type of ST is run in the network.
If it is per-VLAN ST, you need to send 4,000 BPDUs, worst than sending
4000 Hellos.
If you don't understand the ST configuration, you will have loops.

-- Silvano

P.S. I don't know why we are so stubborn on the 4000. By default there
is only VLAN 1 and we have other VLANs only if explicitly configured.


> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]]
> Sent: Saturday, August 18, 2007 11:45 PM
> To: Silvano Gai
> Cc: Eastlake III Donald-LDE008; Anoop Ghanwani; [e-mail]
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
with
> all the VLAN tags
> 
> Some thoughts...
> 
> Remind me again what was wrong with the rule "you participate in the
> bridge spanning tree
> algorithm, and become DRB if and only if you are root bridge".? That
> seems to avoid the
> necessity of sending 4000 Hellos, or specifying in the Hellos "these
are
> all the VLAN
> tags I can hear each of my neighbors on".
> 
> I guess if you want to do load splitting so that R1 is DRB for VLAN A
> and R2 is DRB for
> VLAN B that might be tricky if there's only one spanning tree instance
> on the layer 2 cloud.
> 
> But it does seem as though "become DRB iff you are the root of the
> spanning tree" is the
> most robust solution. It doesn't seem to require sending Hellos for
> every possible VLAN tag.
> 
> Also, having multiple DRBs for load splitting -- shouldn't we be
scared
> about the case where
> bridge configuration can turn a VLAN A tag into a VLAN B tag?
> 
> 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 l7J6iQ65009709 for <[e-mail]>; Sat, 18 Aug 2007 23:44:26 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 18 Aug 2007 23:44:15 -0700 (PDT)
Received: from [129.150.16.245] ([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]; Sat, 18 Aug 2007 23:44:12 -0700 (PDT)
Date: Sat, 18 Aug 2007 23:45:12 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Silvano Gai <[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]> <[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: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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: Sun, 19 Aug 2007 06:44:42 -0000
Status: RO
Content-Length: 860

Some thoughts...

Remind me again what was wrong with the rule "you participate in the 
bridge spanning tree
algorithm, and become DRB if and only if you are root bridge".? That 
seems to avoid the
necessity of sending 4000 Hellos, or specifying in the Hellos "these are 
all the VLAN
tags I can hear each of my neighbors on".

I guess if you want to do load splitting so that R1 is DRB for VLAN A 
and R2 is DRB for
VLAN B that might be tricky if there's only one spanning tree instance 
on the layer 2 cloud.

But it does seem as though "become DRB iff you are the root of the 
spanning tree" is the
most robust solution. It doesn't seem to require sending Hellos for 
every possible VLAN tag.

Also, having multiple DRBs for load splitting -- shouldn't we be scared 
about the case where
bridge configuration can turn a VLAN A tag into a VLAN B tag?

Radia


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 l7GKgROw027317 for <[e-mail]>; Thu, 16 Aug 2007 13:42:31 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-8.tower-119.messagelabs.com!1187296946!20150024!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.10]
Received: (qmail 6908 invoked from network); 16 Aug 2007 20:42:26 -0000
Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-8.tower-119.messagelabs.com with SMTP; 16 Aug 2007 20:42:26 -0000
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l7GKgP9I014375 for <[e-mail]>; Thu, 16 Aug 2007 13:42:25 -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 l7GKgOxX004539 for <[e-mail]>; Thu, 16 Aug 2007 15:42:25 -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 l7GKgNS7004527 for <[e-mail]>; Thu, 16 Aug 2007 15:42:23 -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: Thu, 16 Aug 2007 16:42:22 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
thread-index: Acfe/qLNwm4jwSdHShy82bBBZAjY5wBOb0tA
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]><[e-mail]><[e-mail]> <46C28DAA.5050503@sun. com>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-Vontu: Pass
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 l7GKgROw027317
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 16 Aug 2007 20:42:48 -0000
Status: RO
Content-Length: 9060

See below at @@@

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Wednesday, August 15, 2007 1:23 AM
To: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
with all the VLAN tags

So...if I understand Donald's explanation, it seems like the zero
configuration case is to send untagged frames and receive packets
tagged with any VLAN.

@@@ Yes, frames that are, while inside the bridge, associated with VLAN
1 are the only ones emitted and they are sent untagged. They could have
been received as untagged, priority tagged, or tagged as VLAN 1.

That seems like there is no choice: the zero configuration case is
to only send Hellos untagged.

@@@ Untagged as far as VLAN goes. For the most rapid topology
convergence, I still think that if there might be intervening bridges,
Hellos should be sent priority tagged with the maximum priority, 7.

But then bridges and RBridges, through
configuration, can support other VLANs.
At that point
when we say "support VLAN 215", would we want that to mean that
you should *also* send Hellos tagged with VLAN 215? That seems like the
only point of disagreement. Proposal "A" is no matter how many VLANs we
might support, we'd only send Hellos with VLAN 1/untagged (and perhaps
with extra configuration, we can say "not only support VLAN 215, but
send Hellos on it"). Proposal
"B" is that once we say "support VLAN 215, it also means we send Hellos 
on 215,
with perhaps extra configuration to say "but don't send Hellos on 215".

Those two do not seem very different to me -- supporting anything other
than
VLAN 1 requires configuration, so hopefully we can reach consensus on 
something soon.

Whatever we do, if we allow any configuration other than "always
send all IS-IS Hellos untagged (or VLAN 1), then we might wind up
with a case where different RBridges are sending with different VLAN
tags.

So here's an attempt at writing how that would work.

a) accept Hellos tagged with any VLAN tag

b) in your Hello, in which you list the IS-IS neighbors you
have heard Hellos from, list at least one VLAN tag for each neighbor
with which you have heard a Hello.

!!!Question: should you list *all* VLAN
tags that you've heard from that neighbor? Or is it fine to just list
one?
I'd suggest that you should list only one: the lowest numbered VLAN that

you've heard
from that neighbor on?!!!

@@@ I think it should be OK to list just one. For example, assume that
RB-a and RB-b are connected by a bridged LAN and are configured on their
ports to egress tagged native frames for VLAN 2 and 3 and to send Hellos
on those VLANs. (If they are also sending untagged frames, assume they
won't get through either way.) If the bridged LAN is providing full
connectivity, they should both see both Hellos, report VLAN 2, and
settle on using VLAN 2 tagged TRILL frames to communicate. Even if the
bridged LAN is acting like a pair of diodes and, for these ports, only
VLAN 2 gets from RB-a to RB-b but only VLAN 3 gets from RB-b to RB-a,
this is quite obvious and the Rbridges can communicate with appropriate
tagged frames. (It is left as an exercise for the reader to show that
other combinations of diodes, etc., work as long at least one tagging of
Hellos can get through in each direction.)

@@@ A few things occur to me thinking about this: If some Hellos are
getting through from RB-a to RB-b, and vice versa, then what RB-a wants
to know from RB-b is the "tagging" (or rather at least one of the
taggings) with which RB-a is sending Hellos that get through. It could
be that, if RB-a is sending frames tagged as VLAN 3, the tagging is
being stripped and they are being successfully received by RB-b but in
an untagged form. It could be that, of all the Hellos RB-a is sending on
this port, only the untagged ones are getting through to RB-b in which
case they might be arriving at RB-b untagged or tagged as being in some
arbitrary VLAN X. It could be that the only Hellos emitted by RB-a on
this port that get to RB-b are those sent tagged as VLAN X but they
arrive at RB-b tagged as VLAN Y. (This last is, I think, much less
likely than the others so we may not want to go to any extra trouble to
fix it but I think the same solution as for the other cases fixes it
also.)

@@@ All these cases point to a requirement that the outer VLAN tagging
status of a TRILL core IS-IS Hello when it is emitted must be noted
inside the TRILL encapsulation somewhere. The obvious place to put this
in the current design would be the inner VLAN tag but we have already
decided to use that to indicate per VLAN IS-IS messages as distinguished
from core IS-IS. (All of this discussion is about core instance IS-IS
Hellos.) This leaves approximately three choices: (1) revise the design
so that core versus per VLAN IS-IS instances are distinguished by a
TRILL Header flag bit and the inner VLAN tag in a core IS-IS Hellos
indicates the VLAN with which it was initially sent; (2) put the initial
VLAN tagging ID info inside the Hellos; or (3) something even more
disruptive to the current design. (Minor note: you would need some way
to indicate that a frame was not tagged with a VLAN ID. The obvious way
to do this is with the null VLAN ID, zero, as is done in a priority
tag.)

@@@ You don't have to worry about this for any other IS-IS PDUs besides
Hellos. The Hellos would map the topology and tell you what tagging to
use for other IS-IS PDU types. You don't have to worry about this for
any optional per VLAN IS-IS instances. They use the core IS-IS
determined topology and transport.

@@@ Also, if you can tell there are no intervening bridges, which I
believe can be fairly easily determined with 802.1AB, then just sending
truly untagged TRILL IS-IS frames is the way to go; there is no reason
to even priority tag them.

c) If the DRB reports that it
hears you on VLAN ni, and you were sending
Hellos on {n1, n2, n3, n4, n5, ..}, you can stop sending on all the
other VLANs, and just send on ni

d) Perhaps the goal would be to just send on VLAN 1, so if you were
sending on VLANs 1, 2, 3, 4, and 5, and the DRB reports it heard you
on 3, then you should continue sending on 3 and 1, hoping eventually
it will hear you on 1 so you can stop sending on 3. Our assumption
will be that the only reason VLAN 1 is partitioned is because of
misconfiguration, so we'd like to have it stabilize to only sending on
1 if possible.

e) For each other RBridge Ri, Rj keeps track of the lowest numbered VLAN
that Rj hear Hellos on from Ri. Way this is VLAN 17.
When forwarding encapsulated packets to Ri, Rj tags them with VLAN 17.

!!!Question: If Rj hears Hellos from Ri tagged with VLAN 17, does that
mean that Ri can hear Rj when Rj marks things with VLAN 17?!!!

@@@ Nope, as above and per later message from Anoop, you can easily
configure diodes.

f) As with the design we already have -- if Ri needs to send to Rj (with

neither being DRB), and
Rj has not reported that it can hear Ri, then Ri sends to the DRB when 
it needs to
forward to Rj

g) As with the design we already have -- the DRB reports in the 
pseudonode LSP the VLANs
on which that DRB is designated for that LAN, and the root bridge for
that set of VLANs. (!!!Question:  With multiple spanning trees, is it 
possible to
get different root bridges for each of the spanning trees? In that case 
the pseudonode might
have to report {(root bridge {set of VLANs}, root bridge {set of
VLANs})!!!

@@@ Yes, I believe that with Multiple STP (MSTP) you can get one root
bridge per spanning tree out a port. Seems like it would be pretty messy
to take this into account. This also relates to just what the Rbridge
port is doing with respect to *STP. It's pretty easy to just listen for
STP or RSTP BPDUs and grab the root bridge. For an MSTP BPDU, you can
equally easily grab the CIST root (CIST = Common and Internal Spanning
Tree) but it is not immediately clear to me if that is adequate. Each
MSTP BPDU can also have a variable number of multiple spanning tree
instance regional root identifiers in it...

@@@ Donald

If you see an LSP for a pseudonode with the same root bridge and VLAN 
that you think
you are DRB for, then (depending on some tie-breaker based on IS-IS 
system ID), you
stop forwarding traffic marked with that VLAN tag to/from that link

h) As with the design we already have, to avoid loops, DRB R1 does not 
decapsulate
a packet with ingress R2 unless R1 has R2's LSP and LSPs for all 
pseudonodes for which R2 is
DRB

i) As with the design we already have, to avoid temporary duplication, 
when DRB R1 first
comes up, R1 does not
start forwarding packets off the LAN until R1 has synchronized LSP 
datases with each of
its neighbors

**************
So, the goal of the above is that even if everyone sends on lots of
VLANs, it converges to sending on just VLAN 1 if at all possible.

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



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l7GHvAus023308 for <[e-mail]>; Thu, 16 Aug 2007 10:57:10 -0700 (PDT)
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, 16 Aug 2007 10:56:25 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
Thread-Index: Acfd49d50j9PAhCXSt+/E2d5JC6qPgABtenAAABXYWAAkJthIA==
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]> <[e-mail]> <[e-mail]> <4C94DE2070B172459E4F1EE14BD2364E45FD90@HQ-E XCH-5.corp.b rocade.com> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l7GHvAus023308
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 16 Aug 2007 17:58:42 -0000
Status: RO
Content-Length: 12008

Donald,

I think that what you are saying is equivalent to: "by default a bridge
forwards only VLAN 1, but it receives management frames on any other
VLAN". 

To emulate this behavior, there is the need to send ONLY one ISIS hello.

-- Silvano

> -----Original Message-----
> From: Eastlake III Donald-LDE008 [mailto:[e-mail]]
> Sent: Monday, August 13, 2007 8:52 PM
> To: Anoop Ghanwani; Radia Perlman
> Cc: Silvano Gai; [e-mail]
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
with
> all the VLAN tags
> 
> Radia,
> 
> A zero configuration 802.1Q bridge will ingress frames tagged with any
> VLAN ID. In addition, when it receives untagged or priority tagged
> frames, it will accept them and associate them with VLAN 1. Egressing
> frames, however, is a whole different matter. At an 802.1Q bridge,
VLANs
> have a member set of the ports that are considered to be in that VLAN.
> The zero configuration situation is that all ports are in the member
set
> of VLAN 1 and only VLAN 1 and are set to send frames associated with
> VLAN 1 as untagged. A port can be added to the member set for other
> VLANs by configuration or by receipt of a GVRP (GARP VLAN Registration
> Protocol) message. If you are doing things by dynamic configuration,
the
> idea is that an end station that was going to send frames tagged as in
> VLAN X or a bridge with one or more ports configured to associate
> untagged or priority tagged frames with VLAN X would send GVRP
messages
> along the spanning tree (or trees for MSTP) so that appropriate bridge
> ports along the spanning tree are put in their bridge's member set for
> VLAN X so as to establish full VLAN X connectivity. With GVRP
> implemented and used as intended in 802.1Q, there wouldn't be isolated
> islands of VLAN X stations and 802.1Q bridges would be able to prune
> based on what VLANs have downstream stations. 802.1Q bridges are
> prohibited from egressing a frame in VLAN X on a port which is not in
> the member set for that VLAN.
> 
> Donald
> 
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Monday, August 13, 2007 4:50 PM
> To: Radia Perlman
> Cc: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> with all the VLAN tags
> 
> 
> Radia,
> 
> The default configuration of an 802.1Q bridge
> would be all ports in VLAN 1 only.  With some
> vendors the default is that the ports are
> all disabled and you have to explicitly assign
> a port to a VLAN to actually get it to do
> something.
> 
> It seems you're saying an RBridge would
> support both mechanisms from the standpoint
> of receiving messages, but may support
> only one mode for transmission.  The problem with
> that is that the device that didn't implement
> per-VLAN hello transmission would probably not
> have the ability to sink that volume of per-VLAN
> hellos either (although it is less burdensome
> than having to do both the transmit and receive
> function).
> 
> Anoop
> 
> > -----Original Message-----
> > From: Radia Perlman [mailto:[e-mail]]
> > Sent: Monday, August 13, 2007 12:56 PM
> > To: Anoop Ghanwani
> > Cc: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
> > tagged with all the VLAN tags
> >
> > What is the zero configuration behavior of a bridge with
> > VLANs? Is it to support all VLANs?
> > Or just one? And if just one, which one?
> >
> > We seem to only be arguing about what the default
> > configuration should be.
> > Assuming the bridge zero configuration is to only support one
> > VLAN, then it seems like the only possible "zero
> > configuration" case is to only support one VLAN, and to only
> > send IS-IS Hellos on that VLAN.
> >
> > So since support for other VLANs requires configuration, it
> > doesn't seem too important which case ("add VLAN  *with*
> > sending Hellos" or "add VLAN "without sending extra Hellos")
> > is the default.
> >
> > I'm also not sure whether we've worked out the details of how
> > it works if each of the RBridges on a layer 2 cloud are
> > sending Hellos on different subsets of the VLANs.
> >
> > I wrote out all the details when all RBridges send on a
> > single VLAN, and I think we also know what all the details
> > are when all RBridges send on all VLANs that they support.
> > I'm not sure we understand what is supposed to happen if,
> > say, each VLAN is sending Hellos on a different subset of the VLANs.
> >
> > One thing I'm sure of in that case is that regardless of what
> > VLAN tags you use when you transmit a Hello, you should
> > accept a Hello on any VLAN. But I think we need to write it
> > all out carefully if each RBridge is configured to send on
> > different VLANs.
> >
> > Radia
> >
> >
> > Anoop Ghanwani wrote:
> > > Hi Silvano,
> > >
> > > By making per-VLAN IS-IS hellos the default we will pretty much be
> > > limiting RBridge technology to only high-end devices (or low end
> > > devices will only be able to support a handful of VLANs).  This
> > > bothers me a lot.
> > >
> > > The correctness of the algorithm is also of concern which
> > is why we're
> > > having these discussions about the single IS-IS instance.
> > > We have found one corner case where it is possible for frame
> > > duplication to happen for a short period of time.  I don't
> > think this
> > > is a deal breaker. Why not?  Because it is possible to get
> > small frame
> > > duplication even in 802.1 networks running RSTP.
> > >
> > > (With STP it is possible to completely eliminate this, but
> > convergence
> > > is a lot slower.  See Annex K of 802.1D-2004.)
> > >
> > > Anoop
> > >
> > >
> > >> -----Original Message-----
> > >> From: Silvano Gai [mailto:[e-mail]]
> > >> Sent: Sunday, August 12, 2007 8:30 AM
> > >> To: Anoop Ghanwani; Eastlake III Donald-LDE008;
[e-mail]
> > >> Subject: RE: [rbridge] Avoiding sending multiple IS-IS
> > Hellos tagged
> > >> with all the VLAN tags
> > >>
> > >>
> > >> Anoop,
> > >>
> > >> I am not asking to do per-VLAN hello only.
> > >> I am not prohibiting a shared Hello,
> > >> I am just saying that since we don't have implementation
> > experience
> > >> on the shared hello it should not be the default solution.
> > >>
> > >> You are unrealistic asking to have as a default solution
something
> > >> that is not completely understood.
> > >>
> > >> -- Silvano
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: Anoop Ghanwani [mailto:[e-mail]]
> > >>> Sent: Saturday, August 11, 2007 4:55 PM
> > >>> To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> > >>> Subject: RE: [rbridge] Avoiding sending multiple IS-IS
> > Hellos tagged
> > >>>
> > >> with
> > >>
> > >>> all the VLAN tags
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Silvano Gai [mailto:[e-mail]]
> > >>>> Sent: Saturday, August 11, 2007 1:22 PM
> > >>>> To: Anoop Ghanwani; Eastlake III Donald-LDE008;
> > [e-mail]
> > >>>> Subject: RE: [rbridge] Avoiding sending multiple IS-IS
> > >>>>
> > >> Hellos tagged
> > >>
> > >>>> with all the VLAN tags
> > >>>>
> > >>>>
> > >>>> Anoop,
> > >>>>
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Anoop Ghanwani [mailto:[e-mail]]
> > >>>>> Sent: Friday, August 10, 2007 10:31 AM
> > >>>>> To: Silvano Gai; Eastlake III Donald-LDE008;
[e-mail]
> > >>>>> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos
> > >>>>>
> > >> tagged
> > >>
> > >>>> with
> > >>>>
> > >>>>> all the VLAN tags
> > >>>>>
> > >>>>>
> > >>>>> anoop> We're doing things to detect those corner cases where
> > >>>>>
> > >> things
> > >>
> > >>>> are
> > >>>>
> > >>>>> anoop> misconfigured.
> > >>>>>
> > >>>>> silvano> But you have failed to prove that "these things"
> > >>>>>
> > >>>> are robust.
> > >>>>
> > >>>>> silvano>
> > >>>>> silvano> Sending a Hello on each VLAN is robust and it
> > >>>>>
> > >>>> should be the
> > >>>>
> > >>>>> silvano> default solution.
> > >>>>>
> > >>>>> It's a question of what the robustness requirement is.
> > >>>>> I believe the solution Radia has proposed is adequate.
> > >>>>> There is one corner case pointed out by Dinesh where
> > >>>>>
> > >> one may get
> > >>
> > >>>>> duplication of traffic for a short period (probably a
> > >>>>>
> > >> few seconds)
> > >>
> > >>>>> until the misconfiguration is detected.  I think this
> > >>>>>
> > >> is adequate.
> > >>
> > >>>> I strongly disagree.
> > >>>>
> > >>>> 1) Duplicated frames are bad and several applications cannot
> > >>>> tolerate them. I am pretty sure that one of your favorite
> > >>>> applications is FCoE (Fibre Channel over Ethernet). You
> > >>>>
> > >> don't want
> > >>
> > >>>> to have duplicated SCSI frames.
> > >>>>
> > >>> That is true.  But it happens only when the network is
> > >>>
> > >> misconfigured
> > >>
> > >>> and that too for a limited time (i.e. until the
> > misconfiguration is
> > >>> detected).
> > >>>
> > >>>
> > >>>> 2) There is also the issue pointed out by James Carlson: "if
the
> > >>>> user has two RBridges (R1 and R2) attached to the same Ethernet
> > >>>> subnetwork, and R1 supports only VLANs {A,B} while
> > >>>> R2 supports only VLANs {A,C}, then neither one can
> > >>>>
> > >> actually be the
> > >>
> > >>>> DRB for that whole network."
> > >>>>
> > >>> This is not an issue because (and I think Radia has
> > already pointed
> > >>> this out) we can always run the DRB election per VLAN or
> > >>>
> > >> per group of
> > >>
> > >>> VLANs over the base instance.
> > >>>
> > >>>
> > >>>> 3) There are many other corner cases, but to point them
> > >>>>
> > >> out I need
> > >>
> > >>>> the pseudo-code you intend to use. If you post it and
> > >>>>
> > >> give me some
> > >>
> > >>>> time, I'll find the corner case.
> > >>>>
> > >>>> I remain opposed to use a technique different to per-VLAN
Hello.
> > >>>> In general I think optimizations are better dealt with in
> > >>>>
> > >> the second
> > >>
> > >>>> version of the protocol.
> > >>>>
> > >>> Let's take a hypothetical scenario and say we go with per
> > >>>
> > >> VLAN hellos.
> > >>
> > >>> Let's say someone deploys it in their network and they
> > have a clean
> > >>> edge-core-edge architecture - TRILL only runs in the
> > core; traffic
> > >>> from edge ports is encap'ed and transported over the TRILL core.
> > >>> There are 100's, perhaps 1000's of VLANs at the edges.  I
> > start out
> > >>> with per-VLAN IS-IS hellos going out all ports (core and
> > >>>
> > >> edge), but in
> > >>
> > >>> the core I only have one VLAN.  I find that my CPU is
> > >>>
> > >> having trouble
> > >>
> > >>> keeping up (because of many edge ports and many VLANs on
> > >>>
> > >> each of those
> > >>
> > >>> ports).
> > >>> I figure IS-IS is not really
> > >>> buying me much at the edges so I turn it off on all those ports.
> > >>> Things look and work great!  Next, I have a
> > misconfiguration in my
> > >>> network (the kind that we've been talking about all along).
> > >>>
> > >>  Now, with
> > >>
> > >>> per-VLAN IS-IS off, I have no way to detect it -- bad
> > stuff happens
> > >>> forever!!!  With the single instance running, I would at
> > least have
> > >>> detected a problem and alerted the network operator.
> > >>>
> > >>> The burden we would impose with per-VLAN IS-IS is
> > >>>
> > >> unrealistic.  I urge
> > >>
> > >>> you to give it a second thought.
> > >>>
> > >>> Routers have come a long way today with distributed control
plane
> > >>> architectures, but those push the cost of equipment up.
> > >>>
> > >>> If we have to allow per-VLAN IS-IS messages they should
> > be optional.
> > >>>
> > >>> Anoop
> > >>>
> > >
> > > _______________________________________________
> > > 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 l7G0MTmq018282 for <[e-mail]>; Wed, 15 Aug 2007 17:22:37 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 15 Aug 2007 17:22:18 -0700
X-IronPort-AV: i="4.19,268,1183359600";  d="scan'208"; a="16712641:sNHT20444319"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id D22C3238370; Wed, 15 Aug 2007 17:22:18 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 15 Aug 2007 17:22:18 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 15 Aug 2007 17:22:01 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Questions about VLANs
Thread-Index: AcffbWsZ6QCia3dhT4K49qkYZy6tsgALIelQ
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]><[e-mail]><[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 16 Aug 2007 00:22:18.0795 (UTC) FILETIME=[817127B0:01C7DF9B]
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 l7G0MTmq018282
Subject: Re: [rbridge] Questions about VLANs
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, 16 Aug 2007 00:23:12 -0000
Status: RO
Content-Length: 2816

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Radia Perlman
> Sent: Wednesday, August 15, 2007 11:40 AM
> To: [e-mail]
> Subject: [rbridge] Questions about VLANs
> 
> 
> a) on a port involving transporting frames between bridges, 
> where the port is allowed for forwarding any VLANs, would the 
> bridges be configured to enable all 4000 VLANs? If so...would 
> that mean that most of the "core links" 
> between
> RBridges would be enabled for 4000 VLANs? (and for our 
> purposes, if there are
> *only* RBridges (as in, no bridges, no end stations) on a 
> link, then there is no need to support any VLANs on that 
> link. And if there are just endnodes (no bridges), then I'd 
> guess most likely there would just be one or two VLANs 
> enabled on the link. 
> But the question
> is what happens with bridge to bridge links that are allowed 
> to carry any VLAN? That I think would be a common case, and 
> if it means that the bridges are configured to support all 
> 4000 VLANs, wouldn't that mean that the RBridges would have 
> to be as well? I don't think we'd want to send 4000 Hellos in 
> that case.

Some vendors require you to explicitly configure all VLANs
that need to be supported on a port; others have a single
command that designates the port as a trunk and then
an optional "exclude" list can be provided.  And yes, it's
quite common to see bridge to bridge links with many
VLANs.  If the other end of that link is an RBridge then
the Rbridge would have to be configured with all of
those VLANs and would have to send hellos for all of them.
And that is precisely the scenario that I'm concerned
about.

> b) Can we assume that connectivity with VLAN tag x is 
> commutative on a link, as in, if RB1 can hear RB2 when RB2 
> sends a Hello tagged with VLAN x, does that mean that RB2 can 
> hear RB1 when RB1 sends a Hello tagged with VLAN x? (and I 
> know that if RB1's transmitter is broken, that would mean 
> that regardless of VLAN tag, RB1 can hear RB2, but not vice 
> versa. But what I'm asking is, is it possible for RB1 to hear RB2 when
> RB2 transmits with VLAN x, but RB2 can only hear RB1 when RB1 
> transmits with VLAN y?

Because ingress filtering is an optional function, it
_is_ possible to build one-way communication topologies
(a port by defaults accept traffic from all VLANs, but
only transmits on VLAN1).  If I have ingress filtering
off and I have port p1 with VLAN membership v1, and
port p2 with VLAN membership v1, v2, and ingress filtering
is off, a device on p1 will be able send a frame to
a device on p2 on VLAN v2, but the device on p2 wouldn't
be able to send traffic to the device on p2 on v2.

That said, I doubt there are any networks that deploy 
VLANs in this way.

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 l7FIcXUU015037 for <[e-mail]>; Wed, 15 Aug 2007 11:38:33 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 15 Aug 2007 11:38:32 -0700 (PDT)
Received: from [129.150.17.97] ([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, 15 Aug 2007 11:38:32 -0700 (PDT)
Date: Wed, 15 Aug 2007 11:39:31 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=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]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Questions about VLANs
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, 15 Aug 2007 18:38:56 -0000
Status: RO
Content-Length: 1431

a) on a port involving transporting frames between bridges, where the 
port is
allowed for forwarding any VLANs, would the bridges be configured to enable
all 4000 VLANs? If so...would that mean that most of the "core links" 
between
RBridges would be enabled for 4000 VLANs? (and for our purposes, if 
there are
*only* RBridges (as in, no bridges, no end stations) on a link, then 
there is no
need to support any VLANs on that link. And if there are just endnodes 
(no bridges), then I'd guess
most likely there would just be one or two VLANs enabled on the link. 
But the question
is what happens with bridge to bridge links that are allowed to carry 
any VLAN? That I think
would be a common case, and if it means that the bridges are configured 
to support all 4000 VLANs,
wouldn't that mean that the RBridges would have to be as well? I don't 
think we'd want to
send 4000 Hellos in that case.

b) Can we assume that connectivity with VLAN tag x is commutative on a 
link, as in,
if RB1 can hear RB2 when RB2 sends a Hello tagged with VLAN x, does that 
mean that RB2
can hear RB1 when RB1 sends a Hello tagged with VLAN x? (and I know that if
RB1's transmitter is broken, that would mean that regardless of VLAN 
tag, RB1 can hear
RB2, but not vice versa. But what I'm asking is, is it possible for RB1 
to hear RB2 when
RB2 transmits with VLAN x, but RB2 can only hear RB1 when RB1 transmits with
VLAN y?

Thanks,

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 l7F5LwI6026211 for <[e-mail]>; Tue, 14 Aug 2007 22:21:58 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 14 Aug 2007 22:21:53 -0700 (PDT)
Received: from [129.150.17.97] ([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, 14 Aug 2007 22:21:52 -0700 (PDT)
Date: Tue, 14 Aug 2007 22:22:50 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=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]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 15 Aug 2007 05:22:34 -0000
Status: RO
Content-Length: 4079

So...if I understand Donald's explanation, it seems like the zero
configuration case is to send untagged frames and receive packets
tagged with any VLAN.

That seems like there is no choice: the zero configuration case is
to only send Hellos untagged.

But then bridges and RBridges, through
configuration, can support other VLANs.
At that point
when we say "support VLAN 215", would we want that to mean that
you should *also* send Hellos tagged with VLAN 215? That seems like the
only point of disagreement. Proposal "A" is no matter how many VLANs we
might support, we'd only send Hellos with VLAN 1/untagged (and perhaps
with extra configuration, we can say "not only support VLAN 215, but
send Hellos on it"). Proposal
"B" is that once we say "support VLAN 215, it also means we send Hellos 
on 215,
with perhaps extra configuration to say "but don't send Hellos on 215".

Those two do not seem very different to me -- supporting anything other than
VLAN 1 requires configuration, so hopefully we can reach consensus on 
something soon.

Whatever we do, if we allow any configuration other than "always
send all IS-IS Hellos untagged (or VLAN 1), then we might wind up
with a case where different RBridges are sending with different VLAN tags.

So here's an attempt at writing how that would work.

a) accept Hellos tagged with any VLAN tag

b) in your Hello, in which you list the IS-IS neighbors you
have heard Hellos from, list at least one VLAN tag for each neighbor
with which you have heard a Hello.

!!!Question: should you list *all* VLAN
tags that you've heard from that neighbor? Or is it fine to just list one?
I'd suggest that you should list only one: the lowest numbered VLAN that 
you've heard
from that neighbor on?!!!

c) If the DRB reports that it
hears you on VLAN ni, and you were sending
Hellos on {n1, n2, n3, n4, n5, ..}, you can stop sending on all the
other VLANs, and just send on ni

d) Perhaps the goal would be to just send on VLAN 1, so if you were
sending on VLANs 1, 2, 3, 4, and 5, and the DRB reports it heard you
on 3, then you should continue sending on 3 and 1, hoping eventually
it will hear you on 1 so you can stop sending on 3. Our assumption
will be that the only reason VLAN 1 is partitioned is because of
misconfiguration, so we'd like to have it stabilize to only sending on
1 if possible.

e) For each other RBridge Ri, Rj keeps track of the lowest numbered VLAN
that Rj hear Hellos on from Ri. Way this is VLAN 17.
When forwarding encapsulated packets to Ri, Rj tags them with VLAN 17.

!!!Question: If Rj hears Hellos from Ri tagged with VLAN 17, does that
mean that Ri can hear Rj when Rj marks things with VLAN 17?!!!

f) As with the design we already have -- if Ri needs to send to Rj (with 
neither being DRB), and
Rj has not reported that it can hear Ri, then Ri sends to the DRB when 
it needs to
forward to Rj

g) As with the design we already have -- the DRB reports in the 
pseudonode LSP the VLANs
on which that DRB is designated for that LAN, and the root bridge for
that set of VLANs. (!!!Question:  With multiple spanning trees, is it 
possible to
get different root bridges for each of the spanning trees? In that case 
the pseudonode might
have to report {(root bridge {set of VLANs}, root bridge {set of VLANs})!!!
If you see an LSP for a pseudonode with the same root bridge and VLAN 
that you think
you are DRB for, then (depending on some tie-breaker based on IS-IS 
system ID), you
stop forwarding traffic marked with that VLAN tag to/from that link

h) As with the design we already have, to avoid loops, DRB R1 does not 
decapsulate
a packet with ingress R2 unless R1 has R2's LSP and LSPs for all 
pseudonodes for which R2 is
DRB

i) As with the design we already have, to avoid temporary duplication, 
when DRB R1 first
comes up, R1 does not
start forwarding packets off the LAN until R1 has synchronized LSP 
datases with each of
its neighbors

**************
So, the goal of the above is that even if everyone sends on lots of
VLANs, it converges to sending on just VLAN 1 if at all possible.

Radia


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 l7E3qdxS015686 for <[e-mail]>; Mon, 13 Aug 2007 20:52:39 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-119.messagelabs.com!1187063550!25912798!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [144.189.100.102]
Received: (qmail 31905 invoked from network); 14 Aug 2007 03:52:31 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-3.tower-119.messagelabs.com with SMTP; 14 Aug 2007 03:52:31 -0000
Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l7E3qUcA011351 for <[e-mail]>; Mon, 13 Aug 2007 20:52:30 -0700 (MST)
Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l7E3qS96001076 for <[e-mail]>; Mon, 13 Aug 2007 22:52:29 -0500 (CDT)
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 l7E3qRqg001049 for <[e-mail]>; Mon, 13 Aug 2007 22:52:27 -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: Mon, 13 Aug 2007 23:52:20 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
thread-index: Acfd49d50j9PAhCXSt+/E2d5JC6qPgABtenAAABXYWA=
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]> <[e-mail]> <[e-mail]> <4C94DE2070B172459E4F1EE14BD2364E45FD90@HQ-E XCH-5.corp.brocade.com>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-Vontu: Pass
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 l7E3qdxS015686
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 14 Aug 2007 03:52:53 -0000
Status: RO
Content-Length: 11257

Radia,

A zero configuration 802.1Q bridge will ingress frames tagged with any
VLAN ID. In addition, when it receives untagged or priority tagged
frames, it will accept them and associate them with VLAN 1. Egressing
frames, however, is a whole different matter. At an 802.1Q bridge, VLANs
have a member set of the ports that are considered to be in that VLAN.
The zero configuration situation is that all ports are in the member set
of VLAN 1 and only VLAN 1 and are set to send frames associated with
VLAN 1 as untagged. A port can be added to the member set for other
VLANs by configuration or by receipt of a GVRP (GARP VLAN Registration
Protocol) message. If you are doing things by dynamic configuration, the
idea is that an end station that was going to send frames tagged as in
VLAN X or a bridge with one or more ports configured to associate
untagged or priority tagged frames with VLAN X would send GVRP messages
along the spanning tree (or trees for MSTP) so that appropriate bridge
ports along the spanning tree are put in their bridge's member set for
VLAN X so as to establish full VLAN X connectivity. With GVRP
implemented and used as intended in 802.1Q, there wouldn't be isolated
islands of VLAN X stations and 802.1Q bridges would be able to prune
based on what VLANs have downstream stations. 802.1Q bridges are
prohibited from egressing a frame in VLAN X on a port which is not in
the member set for that VLAN.

Donald


-----Original Message-----
From: Anoop Ghanwani [mailto:[e-mail]] 
Sent: Monday, August 13, 2007 4:50 PM
To: Radia Perlman
Cc: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
with all the VLAN tags


Radia,

The default configuration of an 802.1Q bridge
would be all ports in VLAN 1 only.  With some
vendors the default is that the ports are
all disabled and you have to explicitly assign
a port to a VLAN to actually get it to do
something.

It seems you're saying an RBridge would
support both mechanisms from the standpoint 
of receiving messages, but may support
only one mode for transmission.  The problem with
that is that the device that didn't implement
per-VLAN hello transmission would probably not
have the ability to sink that volume of per-VLAN
hellos either (although it is less burdensome
than having to do both the transmit and receive
function).

Anoop 

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]] 
> Sent: Monday, August 13, 2007 12:56 PM
> To: Anoop Ghanwani
> Cc: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos 
> tagged with all the VLAN tags
> 
> What is the zero configuration behavior of a bridge with 
> VLANs? Is it to support all VLANs?
> Or just one? And if just one, which one?
> 
> We seem to only be arguing about what the default 
> configuration should be.
> Assuming the bridge zero configuration is to only support one 
> VLAN, then it seems like the only possible "zero 
> configuration" case is to only support one VLAN, and to only 
> send IS-IS Hellos on that VLAN.
> 
> So since support for other VLANs requires configuration, it 
> doesn't seem too important which case ("add VLAN  *with* 
> sending Hellos" or "add VLAN "without sending extra Hellos") 
> is the default.
> 
> I'm also not sure whether we've worked out the details of how 
> it works if each of the RBridges on a layer 2 cloud are 
> sending Hellos on different subsets of the VLANs.
> 
> I wrote out all the details when all RBridges send on a 
> single VLAN, and I think we also know what all the details 
> are when all RBridges send on all VLANs that they support. 
> I'm not sure we understand what is supposed to happen if, 
> say, each VLAN is sending Hellos on a different subset of the VLANs.
> 
> One thing I'm sure of in that case is that regardless of what 
> VLAN tags you use when you transmit a Hello, you should 
> accept a Hello on any VLAN. But I think we need to write it 
> all out carefully if each RBridge is configured to send on 
> different VLANs.
> 
> Radia
> 
> 
> Anoop Ghanwani wrote:
> > Hi Silvano,
> >
> > By making per-VLAN IS-IS hellos the default we will pretty much be 
> > limiting RBridge technology to only high-end devices (or low end 
> > devices will only be able to support a handful of VLANs).  This 
> > bothers me a lot.
> >
> > The correctness of the algorithm is also of concern which 
> is why we're 
> > having these discussions about the single IS-IS instance.
> > We have found one corner case where it is possible for frame 
> > duplication to happen for a short period of time.  I don't 
> think this 
> > is a deal breaker. Why not?  Because it is possible to get 
> small frame 
> > duplication even in 802.1 networks running RSTP.
> >
> > (With STP it is possible to completely eliminate this, but 
> convergence 
> > is a lot slower.  See Annex K of 802.1D-2004.)
> >
> > Anoop
> >
> >   
> >> -----Original Message-----
> >> From: Silvano Gai [mailto:[e-mail]]
> >> Sent: Sunday, August 12, 2007 8:30 AM
> >> To: Anoop Ghanwani; Eastlake III Donald-LDE008; [e-mail]
> >> Subject: RE: [rbridge] Avoiding sending multiple IS-IS 
> Hellos tagged 
> >> with all the VLAN tags
> >>
> >>
> >> Anoop,
> >>
> >> I am not asking to do per-VLAN hello only.
> >> I am not prohibiting a shared Hello,
> >> I am just saying that since we don't have implementation 
> experience 
> >> on the shared hello it should not be the default solution.
> >>
> >> You are unrealistic asking to have as a default solution something 
> >> that is not completely understood.
> >>
> >> -- Silvano
> >>
> >>     
> >>> -----Original Message-----
> >>> From: Anoop Ghanwani [mailto:[e-mail]]
> >>> Sent: Saturday, August 11, 2007 4:55 PM
> >>> To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> >>> Subject: RE: [rbridge] Avoiding sending multiple IS-IS 
> Hellos tagged
> >>>       
> >> with
> >>     
> >>> all the VLAN tags
> >>>
> >>>
> >>>
> >>>       
> >>>> -----Original Message-----
> >>>> From: Silvano Gai [mailto:[e-mail]]
> >>>> Sent: Saturday, August 11, 2007 1:22 PM
> >>>> To: Anoop Ghanwani; Eastlake III Donald-LDE008; 
> [e-mail]
> >>>> Subject: RE: [rbridge] Avoiding sending multiple IS-IS
> >>>>         
> >> Hellos tagged
> >>     
> >>>> with all the VLAN tags
> >>>>
> >>>>
> >>>> Anoop,
> >>>>
> >>>>         
> >>>>> -----Original Message-----
> >>>>> From: Anoop Ghanwani [mailto:[e-mail]]
> >>>>> Sent: Friday, August 10, 2007 10:31 AM
> >>>>> To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> >>>>> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos
> >>>>>           
> >> tagged
> >>     
> >>>> with
> >>>>         
> >>>>> all the VLAN tags
> >>>>>
> >>>>>
> >>>>> anoop> We're doing things to detect those corner cases where
> >>>>>           
> >> things
> >>     
> >>>> are
> >>>>         
> >>>>> anoop> misconfigured.
> >>>>>
> >>>>> silvano> But you have failed to prove that "these things"
> >>>>>           
> >>>> are robust.
> >>>>         
> >>>>> silvano>
> >>>>> silvano> Sending a Hello on each VLAN is robust and it
> >>>>>           
> >>>> should be the
> >>>>         
> >>>>> silvano> default solution.
> >>>>>
> >>>>> It's a question of what the robustness requirement is.
> >>>>> I believe the solution Radia has proposed is adequate.
> >>>>> There is one corner case pointed out by Dinesh where
> >>>>>           
> >> one may get
> >>     
> >>>>> duplication of traffic for a short period (probably a
> >>>>>           
> >> few seconds)
> >>     
> >>>>> until the misconfiguration is detected.  I think this
> >>>>>           
> >> is adequate.
> >>     
> >>>> I strongly disagree.
> >>>>
> >>>> 1) Duplicated frames are bad and several applications cannot 
> >>>> tolerate them. I am pretty sure that one of your favorite 
> >>>> applications is FCoE (Fibre Channel over Ethernet). You
> >>>>         
> >> don't want
> >>     
> >>>> to have duplicated SCSI frames.
> >>>>         
> >>> That is true.  But it happens only when the network is
> >>>       
> >> misconfigured
> >>     
> >>> and that too for a limited time (i.e. until the 
> misconfiguration is 
> >>> detected).
> >>>
> >>>       
> >>>> 2) There is also the issue pointed out by James Carlson: "if the 
> >>>> user has two RBridges (R1 and R2) attached to the same Ethernet 
> >>>> subnetwork, and R1 supports only VLANs {A,B} while
> >>>> R2 supports only VLANs {A,C}, then neither one can
> >>>>         
> >> actually be the
> >>     
> >>>> DRB for that whole network."
> >>>>         
> >>> This is not an issue because (and I think Radia has 
> already pointed 
> >>> this out) we can always run the DRB election per VLAN or
> >>>       
> >> per group of
> >>     
> >>> VLANs over the base instance.
> >>>
> >>>       
> >>>> 3) There are many other corner cases, but to point them
> >>>>         
> >> out I need
> >>     
> >>>> the pseudo-code you intend to use. If you post it and
> >>>>         
> >> give me some
> >>     
> >>>> time, I'll find the corner case.
> >>>>
> >>>> I remain opposed to use a technique different to per-VLAN Hello.
> >>>> In general I think optimizations are better dealt with in
> >>>>         
> >> the second
> >>     
> >>>> version of the protocol.
> >>>>         
> >>> Let's take a hypothetical scenario and say we go with per
> >>>       
> >> VLAN hellos.  
> >>     
> >>> Let's say someone deploys it in their network and they 
> have a clean 
> >>> edge-core-edge architecture - TRILL only runs in the 
> core; traffic 
> >>> from edge ports is encap'ed and transported over the TRILL core.
> >>> There are 100's, perhaps 1000's of VLANs at the edges.  I 
> start out 
> >>> with per-VLAN IS-IS hellos going out all ports (core and
> >>>       
> >> edge), but in
> >>     
> >>> the core I only have one VLAN.  I find that my CPU is
> >>>       
> >> having trouble
> >>     
> >>> keeping up (because of many edge ports and many VLANs on
> >>>       
> >> each of those
> >>     
> >>> ports).
> >>> I figure IS-IS is not really
> >>> buying me much at the edges so I turn it off on all those ports.  
> >>> Things look and work great!  Next, I have a 
> misconfiguration in my 
> >>> network (the kind that we've been talking about all along).
> >>>       
> >>  Now, with
> >>     
> >>> per-VLAN IS-IS off, I have no way to detect it -- bad 
> stuff happens 
> >>> forever!!!  With the single instance running, I would at 
> least have 
> >>> detected a problem and alerted the network operator.
> >>>
> >>> The burden we would impose with per-VLAN IS-IS is
> >>>       
> >> unrealistic.  I urge
> >>     
> >>> you to give it a second thought.
> >>>
> >>> Routers have come a long way today with distributed control plane 
> >>> architectures, but those push the cost of equipment up.
> >>>
> >>> If we have to allow per-VLAN IS-IS messages they should 
> be optional.
> >>>
> >>> Anoop
> >>>       
> >
> > _______________________________________________
> > 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 l7DKoWOF006705 for <[e-mail]>; Mon, 13 Aug 2007 13:50:37 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 13 Aug 2007 13:50:32 -0700
X-IronPort-AV: i="4.19,256,1183359600";  d="scan'208"; a="16584885:sNHT43986607"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 55634238381; Mon, 13 Aug 2007 13:50:32 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 13 Aug 2007 13:50:32 -0700
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, 13 Aug 2007 13:50:20 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
Thread-Index: Acfd49d50j9PAhCXSt+/E2d5JC6qPgABtenA
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]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 13 Aug 2007 20:50:32.0174 (UTC) FILETIME=[96E128E0:01C7DDEB]
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 l7DKoWOF006705
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 13 Aug 2007 20:50:57 -0000
Status: RO
Content-Length: 9525

Radia,

The default configuration of an 802.1Q bridge
would be all ports in VLAN 1 only.  With some
vendors the default is that the ports are
all disabled and you have to explicity assign
a port to a VLAN to actually get it to do
something.

It seems you're saying an RBridge would
support both mechanisms from the standpoint 
of receiving messages, but may support
only one mode for transmission.  The problem with
that is that the device that didn't implement
per-VLAN hello transmission would probably not
have the ability to sink that volume of per-VLAN
hellos either (although it is less burdensome
than having to do both the transmit and receive
function).

Anoop 

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]] 
> Sent: Monday, August 13, 2007 12:56 PM
> To: Anoop Ghanwani
> Cc: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos 
> tagged with all the VLAN tags
> 
> What is the zero configuration behavior of a bridge with 
> VLANs? Is it to support all VLANs?
> Or just one? And if just one, which one?
> 
> We seem to only be arguing about what the default 
> configuration should be.
> Assuming the bridge zero configuration is to only support one 
> VLAN, then it seems like the only possible "zero 
> configuration" case is to only support one VLAN, and to only 
> send IS-IS Hellos on that VLAN.
> 
> So since support for other VLANs requires configuration, it 
> doesn't seem too important which case ("add VLAN  *with* 
> sending Hellos" or "add VLAN "without sending extra Hellos") 
> is the default.
> 
> I'm also not sure whether we've worked out the details of how 
> it works if each of the RBridges on a layer 2 cloud are 
> sending Hellos on different subsets of the VLANs.
> 
> I wrote out all the details when all RBridges send on a 
> single VLAN, and I think we also know what all the details 
> are when all RBridges send on all VLANs that they support. 
> I'm not sure we understand what is supposed to happen if, 
> say, each VLAN is sending Hellos on a different subset of the VLANs.
> 
> One thing I'm sure of in that case is that regardless of what 
> VLAN tags you use when you transmit a Hello, you should 
> accept a Hello on any VLAN. But I think we need to write it 
> all out carefully if each RBridge is configured to send on 
> different VLANs.
> 
> Radia
> 
> 
> Anoop Ghanwani wrote:
> > Hi Silvano,
> >
> > By making per-VLAN IS-IS hellos the default we will pretty much be 
> > limiting RBridge technology to only high-end devices (or low end 
> > devices will only be able to support a handful of VLANs).  This 
> > bothers me a lot.
> >
> > The correctness of the algorithm is also of concern which 
> is why we're 
> > having these discussions about the single IS-IS instance.
> > We have found one corner case where it is possible for frame 
> > duplication to happen for a short period of time.  I don't 
> think this 
> > is a deal breaker. Why not?  Because it is possible to get 
> small frame 
> > duplication even in 802.1 networks running RSTP.
> >
> > (With STP it is possible to completely eliminate this, but 
> convergence 
> > is a lot slower.  See Annex K of 802.1D-2004.)
> >
> > Anoop
> >
> >   
> >> -----Original Message-----
> >> From: Silvano Gai [mailto:[e-mail]]
> >> Sent: Sunday, August 12, 2007 8:30 AM
> >> To: Anoop Ghanwani; Eastlake III Donald-LDE008; [e-mail]
> >> Subject: RE: [rbridge] Avoiding sending multiple IS-IS 
> Hellos tagged 
> >> with all the VLAN tags
> >>
> >>
> >> Anoop,
> >>
> >> I am not asking to do per-VLAN hello only.
> >> I am not prohibiting a shared Hello,
> >> I am just saying that since we don't have implementation 
> experience 
> >> on the shared hello it should not be the default solution.
> >>
> >> You are unrealistic asking to have as a default solution something 
> >> that is not completely understood.
> >>
> >> -- Silvano
> >>
> >>     
> >>> -----Original Message-----
> >>> From: Anoop Ghanwani [mailto:[e-mail]]
> >>> Sent: Saturday, August 11, 2007 4:55 PM
> >>> To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> >>> Subject: RE: [rbridge] Avoiding sending multiple IS-IS 
> Hellos tagged
> >>>       
> >> with
> >>     
> >>> all the VLAN tags
> >>>
> >>>
> >>>
> >>>       
> >>>> -----Original Message-----
> >>>> From: Silvano Gai [mailto:[e-mail]]
> >>>> Sent: Saturday, August 11, 2007 1:22 PM
> >>>> To: Anoop Ghanwani; Eastlake III Donald-LDE008; 
> [e-mail]
> >>>> Subject: RE: [rbridge] Avoiding sending multiple IS-IS
> >>>>         
> >> Hellos tagged
> >>     
> >>>> with all the VLAN tags
> >>>>
> >>>>
> >>>> Anoop,
> >>>>
> >>>>         
> >>>>> -----Original Message-----
> >>>>> From: Anoop Ghanwani [mailto:[e-mail]]
> >>>>> Sent: Friday, August 10, 2007 10:31 AM
> >>>>> To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> >>>>> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos
> >>>>>           
> >> tagged
> >>     
> >>>> with
> >>>>         
> >>>>> all the VLAN tags
> >>>>>
> >>>>>
> >>>>> anoop> We're doing things to detect those corner cases where
> >>>>>           
> >> things
> >>     
> >>>> are
> >>>>         
> >>>>> anoop> misconfigured.
> >>>>>
> >>>>> silvano> But you have failed to prove that "these things"
> >>>>>           
> >>>> are robust.
> >>>>         
> >>>>> silvano>
> >>>>> silvano> Sending a Hello on each VLAN is robust and it
> >>>>>           
> >>>> should be the
> >>>>         
> >>>>> silvano> default solution.
> >>>>>
> >>>>> It's a question of what the robustness requirement is.
> >>>>> I believe the solution Radia has proposed is adequate.
> >>>>> There is one corner case pointed out by Dinesh where
> >>>>>           
> >> one may get
> >>     
> >>>>> duplication of traffic for a short period (probably a
> >>>>>           
> >> few seconds)
> >>     
> >>>>> until the misconfiguration is detected.  I think this
> >>>>>           
> >> is adequate.
> >>     
> >>>> I strongly disagree.
> >>>>
> >>>> 1) Duplicated frames are bad and several applications cannot 
> >>>> tolerate them. I am pretty sure that one of your favorite 
> >>>> applications is FCoE (Fibre Channel over Ethernet). You
> >>>>         
> >> don't want
> >>     
> >>>> to have duplicated SCSI frames.
> >>>>         
> >>> That is true.  But it happens only when the network is
> >>>       
> >> misconfigured
> >>     
> >>> and that too for a limited time (i.e. until the 
> misconfiguration is 
> >>> detected).
> >>>
> >>>       
> >>>> 2) There is also the issue pointed out by James Carlson: "if the 
> >>>> user has two RBridges (R1 and R2) attached to the same Ethernet 
> >>>> subnetwork, and R1 supports only VLANs {A,B} while
> >>>> R2 supports only VLANs {A,C}, then neither one can
> >>>>         
> >> actually be the
> >>     
> >>>> DRB for that whole network."
> >>>>         
> >>> This is not an issue because (and I think Radia has 
> already pointed 
> >>> this out) we can always run the DRB election per VLAN or
> >>>       
> >> per group of
> >>     
> >>> VLANs over the base instance.
> >>>
> >>>       
> >>>> 3) There are many other corner cases, but to point them
> >>>>         
> >> out I need
> >>     
> >>>> the pseudo-code you intend to use. If you post it and
> >>>>         
> >> give me some
> >>     
> >>>> time, I'll find the corner case.
> >>>>
> >>>> I remain opposed to use a technique different to per-VLAN Hello.
> >>>> In general I think optimizations are better dealt with in
> >>>>         
> >> the second
> >>     
> >>>> version of the protocol.
> >>>>         
> >>> Let's take a hypothetical scenario and say we go with per
> >>>       
> >> VLAN hellos.  
> >>     
> >>> Let's say someone deploys it in their network and they 
> have a clean 
> >>> edge-core-edge architecture - TRILL only runs in the 
> core; traffic 
> >>> from edge ports is encap'ed and transported over the TRILL core.
> >>> There are 100's, perhaps 1000's of VLANs at the edges.  I 
> start out 
> >>> with per-VLAN IS-IS hellos going out all ports (core and
> >>>       
> >> edge), but in
> >>     
> >>> the core I only have one VLAN.  I find that my CPU is
> >>>       
> >> having trouble
> >>     
> >>> keeping up (because of many edge ports and many VLANs on
> >>>       
> >> each of those
> >>     
> >>> ports).
> >>> I figure IS-IS is not really
> >>> buying me much at the edges so I turn it off on all those ports.  
> >>> Things look and work great!  Next, I have a 
> misconfiguration in my 
> >>> network (the kind that we've been talking about all along).
> >>>       
> >>  Now, with
> >>     
> >>> per-VLAN IS-IS off, I have no way to detect it -- bad 
> stuff happens 
> >>> forever!!!  With the single instance running, I would at 
> least have 
> >>> detected a problem and alerted the network operator.
> >>>
> >>> The burden we would impose with per-VLAN IS-IS is
> >>>       
> >> unrealistic.  I urge
> >>     
> >>> you to give it a second thought.
> >>>
> >>> Routers have come a long way today with distributed control plane 
> >>> architectures, but those push the cost of equipment up.
> >>>
> >>> If we have to allow per-VLAN IS-IS messages they should 
> be optional.
> >>>
> >>> Anoop
> >>>       
> >
> > _______________________________________________
> > 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 l7DJtD2B018957 for <[e-mail]>; Mon, 13 Aug 2007 12:55:14 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 13 Aug 2007 12:55:03 -0700 (PDT)
Received: from [129.150.18.24] ([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, 13 Aug 2007 12:55:03 -0700 (PDT)
Date: Mon, 13 Aug 2007 12:56:02 -0700
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]> <[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]>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 13 Aug 2007 19:55:43 -0000
Status: RO
Content-Length: 8018

What is the zero configuration behavior of a bridge
with VLANs? Is it to support all VLANs?
Or just one? And if just one, which one?

We seem to only be arguing about what the default configuration should be.
Assuming the bridge zero configuration is to only support one VLAN, then
it seems like the only possible "zero configuration" case is to only support
one VLAN, and to only send IS-IS Hellos on that VLAN.

So since support for other VLANs requires configuration, it doesn't seem too
important which case ("add VLAN  *with* sending Hellos" or "add VLAN 
"without
sending extra Hellos") is the default.

I'm also not sure whether we've worked out the details of how it works 
if each of
the RBridges on a layer 2 cloud are sending Hellos on different subsets 
of the VLANs.

I wrote out all the details when all RBridges send on a single VLAN,
and I think we also know what all the details are when all RBridges send 
on all VLANs that they support. I'm not sure we understand what is 
supposed to happen if, say, each VLAN is sending Hellos on a different 
subset of the VLANs.

One thing I'm sure of in that case is that regardless of what VLAN tags 
you use when you transmit a Hello, you should accept a Hello on any 
VLAN. But I think we need to write it all out carefully if each RBridge 
is configured to send on different VLANs.

Radia


Anoop Ghanwani wrote:
> Hi Silvano,
>
> By making per-VLAN IS-IS hellos the default
> we will pretty much be limiting RBridge 
> technology to only high-end devices (or
> low end devices will only be able to support
> a handful of VLANs).  This bothers me a lot.
>
> The correctness of the algorithm is also 
> of concern which is why we're having these
> discussions about the single IS-IS instance.
> We have found one corner case where it is
> possible for frame duplication to happen
> for a short period of time.  I don't think 
> this is a deal breaker. Why not?  Because 
> it is possible to get small frame duplication
> even in 802.1 networks running RSTP.  
>
> (With STP it is possible to completely 
> eliminate this, but convergence is a lot 
> slower.  See Annex K of 802.1D-2004.)
>
> Anoop 
>
>   
>> -----Original Message-----
>> From: Silvano Gai [mailto:[e-mail]] 
>> Sent: Sunday, August 12, 2007 8:30 AM
>> To: Anoop Ghanwani; Eastlake III Donald-LDE008; [e-mail]
>> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos 
>> tagged with all the VLAN tags
>>
>>
>> Anoop,
>>
>> I am not asking to do per-VLAN hello only.
>> I am not prohibiting a shared Hello,
>> I am just saying that since we don't have implementation 
>> experience on the shared hello it should not be the default solution.
>>
>> You are unrealistic asking to have as a default solution 
>> something that is not completely understood.
>>
>> -- Silvano
>>
>>     
>>> -----Original Message-----
>>> From: Anoop Ghanwani [mailto:[e-mail]]
>>> Sent: Saturday, August 11, 2007 4:55 PM
>>> To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
>>> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
>>>       
>> with
>>     
>>> all the VLAN tags
>>>
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From: Silvano Gai [mailto:[e-mail]]
>>>> Sent: Saturday, August 11, 2007 1:22 PM
>>>> To: Anoop Ghanwani; Eastlake III Donald-LDE008; [e-mail]
>>>> Subject: RE: [rbridge] Avoiding sending multiple IS-IS 
>>>>         
>> Hellos tagged 
>>     
>>>> with all the VLAN tags
>>>>
>>>>
>>>> Anoop,
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: Anoop Ghanwani [mailto:[e-mail]]
>>>>> Sent: Friday, August 10, 2007 10:31 AM
>>>>> To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
>>>>> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos
>>>>>           
>> tagged
>>     
>>>> with
>>>>         
>>>>> all the VLAN tags
>>>>>
>>>>>
>>>>> anoop> We're doing things to detect those corner cases where
>>>>>           
>> things
>>     
>>>> are
>>>>         
>>>>> anoop> misconfigured.
>>>>>
>>>>> silvano> But you have failed to prove that "these things"
>>>>>           
>>>> are robust.
>>>>         
>>>>> silvano>
>>>>> silvano> Sending a Hello on each VLAN is robust and it
>>>>>           
>>>> should be the
>>>>         
>>>>> silvano> default solution.
>>>>>
>>>>> It's a question of what the robustness requirement is.
>>>>> I believe the solution Radia has proposed is adequate.
>>>>> There is one corner case pointed out by Dinesh where 
>>>>>           
>> one may get 
>>     
>>>>> duplication of traffic for a short period (probably a 
>>>>>           
>> few seconds) 
>>     
>>>>> until the misconfiguration is detected.  I think this 
>>>>>           
>> is adequate.
>>     
>>>> I strongly disagree.
>>>>
>>>> 1) Duplicated frames are bad and several applications cannot 
>>>> tolerate them. I am pretty sure that one of your favorite 
>>>> applications is FCoE (Fibre Channel over Ethernet). You 
>>>>         
>> don't want 
>>     
>>>> to have duplicated SCSI frames.
>>>>         
>>> That is true.  But it happens only when the network is 
>>>       
>> misconfigured 
>>     
>>> and that too for a limited time (i.e. until the misconfiguration is 
>>> detected).
>>>
>>>       
>>>> 2) There is also the issue pointed out by James Carlson: "if the 
>>>> user has two RBridges (R1 and R2) attached to the same Ethernet 
>>>> subnetwork, and R1 supports only VLANs {A,B} while
>>>> R2 supports only VLANs {A,C}, then neither one can 
>>>>         
>> actually be the 
>>     
>>>> DRB for that whole network."
>>>>         
>>> This is not an issue because (and I think Radia has already pointed 
>>> this out) we can always run the DRB election per VLAN or 
>>>       
>> per group of 
>>     
>>> VLANs over the base instance.
>>>
>>>       
>>>> 3) There are many other corner cases, but to point them 
>>>>         
>> out I need 
>>     
>>>> the pseudo-code you intend to use. If you post it and 
>>>>         
>> give me some 
>>     
>>>> time, I'll find the corner case.
>>>>
>>>> I remain opposed to use a technique different to per-VLAN Hello.
>>>> In general I think optimizations are better dealt with in 
>>>>         
>> the second 
>>     
>>>> version of the protocol.
>>>>         
>>> Let's take a hypothetical scenario and say we go with per 
>>>       
>> VLAN hellos.  
>>     
>>> Let's say someone deploys it in their network and they have a clean 
>>> edge-core-edge architecture - TRILL only runs in the core; traffic 
>>> from edge ports is encap'ed and transported over the TRILL core.  
>>> There are 100's, perhaps 1000's of VLANs at the edges.  I start out 
>>> with per-VLAN IS-IS hellos going out all ports (core and 
>>>       
>> edge), but in 
>>     
>>> the core I only have one VLAN.  I find that my CPU is 
>>>       
>> having trouble 
>>     
>>> keeping up (because of many edge ports and many VLANs on 
>>>       
>> each of those 
>>     
>>> ports).
>>> I figure IS-IS is not really
>>> buying me much at the edges so I turn it off on all those ports.  
>>> Things look and work great!  Next, I have a misconfiguration in my 
>>> network (the kind that we've been talking about all along). 
>>>       
>>  Now, with 
>>     
>>> per-VLAN IS-IS off, I have no way to detect it -- bad stuff happens 
>>> forever!!!  With the single instance running, I would at least have 
>>> detected a problem and alerted the network operator.
>>>
>>> The burden we would impose with per-VLAN IS-IS is 
>>>       
>> unrealistic.  I urge 
>>     
>>> you to give it a second thought.
>>>
>>> Routers have come a long way today with distributed control plane 
>>> architectures, but those push the cost of equipment up.
>>>
>>> If we have to allow per-VLAN IS-IS messages they should be optional.
>>>
>>> Anoop
>>>       
>
> _______________________________________________
> 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 l7DHn9UI005454 for <[e-mail]>; Mon, 13 Aug 2007 10:49:17 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 13 Aug 2007 10:49:09 -0700
X-IronPort-AV: i="4.19,255,1183359600";  d="scan'208"; a="16572540:sNHT19308996"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 6CC0A23837D; Mon, 13 Aug 2007 10:49:09 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 13 Aug 2007 10:49:09 -0700
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, 13 Aug 2007 10:48:57 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
Thread-Index: AcfVZps1BZNs/e+/T7aePZVYAElOwgAGmAGAACX5VLAAPTY/gABPmHwgAJoqbHAACKtGUAAB/HqwAAP/ryAAINptcAA4DckgAAdB8rAAIUtUgAA2lS+g
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]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail].b rocad e.com> <34BD [e-mail]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 13 Aug 2007 17:49:09.0369 (UTC) FILETIME=[4038E690:01C7DDD2]
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 l7DHn9UI005454
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 13 Aug 2007 17:49:41 -0000
Status: RO
Content-Length: 5898

Hi Silvano,

By making per-VLAN IS-IS hellos the default
we will pretty much be limiting RBridge 
technology to only high-end devices (or
low end devices will only be able to support
a handful of VLANs).  This bothers me a lot.

The correctness of the algorithm is also 
of concern which is why we're having these
discussions about the single IS-IS instance.
We have found one corner case where it is
possible for frame duplication to happen
for a short period of time.  I don't think 
this is a deal breaker. Why not?  Because 
it is possible to get small frame duplication
even in 802.1 networks running RSTP.  

(With STP it is possible to completely 
eliminate this, but convergence is a lot 
slower.  See Annex K of 802.1D-2004.)

Anoop 

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Sunday, August 12, 2007 8:30 AM
> To: Anoop Ghanwani; Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos 
> tagged with all the VLAN tags
> 
> 
> Anoop,
> 
> I am not asking to do per-VLAN hello only.
> I am not prohibiting a shared Hello,
> I am just saying that since we don't have implementation 
> experience on the shared hello it should not be the default solution.
> 
> You are unrealistic asking to have as a default solution 
> something that is not completely understood.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Saturday, August 11, 2007 4:55 PM
> > To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> > Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> with
> > all the VLAN tags
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Saturday, August 11, 2007 1:22 PM
> > > To: Anoop Ghanwani; Eastlake III Donald-LDE008; [e-mail]
> > > Subject: RE: [rbridge] Avoiding sending multiple IS-IS 
> Hellos tagged 
> > > with all the VLAN tags
> > >
> > >
> > > Anoop,
> > >
> > > > -----Original Message-----
> > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > Sent: Friday, August 10, 2007 10:31 AM
> > > > To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> > > > Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos
> tagged
> > > with
> > > > all the VLAN tags
> > > >
> > > >
> > > > anoop> We're doing things to detect those corner cases where
> things
> > > are
> > > > anoop> misconfigured.
> > > >
> > > > silvano> But you have failed to prove that "these things"
> > > are robust.
> > > > silvano>
> > > > silvano> Sending a Hello on each VLAN is robust and it
> > > should be the
> > > > silvano> default solution.
> > > >
> > > > It's a question of what the robustness requirement is.
> > > > I believe the solution Radia has proposed is adequate.
> > > > There is one corner case pointed out by Dinesh where 
> one may get 
> > > > duplication of traffic for a short period (probably a 
> few seconds) 
> > > > until the misconfiguration is detected.  I think this 
> is adequate.
> > > >
> > >
> > > I strongly disagree.
> > >
> > > 1) Duplicated frames are bad and several applications cannot 
> > > tolerate them. I am pretty sure that one of your favorite 
> > > applications is FCoE (Fibre Channel over Ethernet). You 
> don't want 
> > > to have duplicated SCSI frames.
> > 
> > That is true.  But it happens only when the network is 
> misconfigured 
> > and that too for a limited time (i.e. until the misconfiguration is 
> > detected).
> > 
> > > 2) There is also the issue pointed out by James Carlson: "if the 
> > > user has two RBridges (R1 and R2) attached to the same Ethernet 
> > > subnetwork, and R1 supports only VLANs {A,B} while
> > > R2 supports only VLANs {A,C}, then neither one can 
> actually be the 
> > > DRB for that whole network."
> > 
> > This is not an issue because (and I think Radia has already pointed 
> > this out) we can always run the DRB election per VLAN or 
> per group of 
> > VLANs over the base instance.
> > 
> > > 3) There are many other corner cases, but to point them 
> out I need 
> > > the pseudo-code you intend to use. If you post it and 
> give me some 
> > > time, I'll find the corner case.
> > >
> > > I remain opposed to use a technique different to per-VLAN Hello.
> > > In general I think optimizations are better dealt with in 
> the second 
> > > version of the protocol.
> > 
> > Let's take a hypothetical scenario and say we go with per 
> VLAN hellos.  
> > Let's say someone deploys it in their network and they have a clean 
> > edge-core-edge architecture - TRILL only runs in the core; traffic 
> > from edge ports is encap'ed and transported over the TRILL core.  
> > There are 100's, perhaps 1000's of VLANs at the edges.  I start out 
> > with per-VLAN IS-IS hellos going out all ports (core and 
> edge), but in 
> > the core I only have one VLAN.  I find that my CPU is 
> having trouble 
> > keeping up (because of many edge ports and many VLANs on 
> each of those 
> > ports).
> > I figure IS-IS is not really
> > buying me much at the edges so I turn it off on all those ports.  
> > Things look and work great!  Next, I have a misconfiguration in my 
> > network (the kind that we've been talking about all along). 
>  Now, with 
> > per-VLAN IS-IS off, I have no way to detect it -- bad stuff happens 
> > forever!!!  With the single instance running, I would at least have 
> > detected a problem and alerted the network operator.
> > 
> > The burden we would impose with per-VLAN IS-IS is 
> unrealistic.  I urge 
> > you to give it a second thought.
> > 
> > Routers have come a long way today with distributed control plane 
> > architectures, but those push the cost of equipment up.
> > 
> > If we have to allow per-VLAN IS-IS messages they should be optional.
> > 
> > Anoop
> 



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l7CFUZmG006339 for <[e-mail]>; Sun, 12 Aug 2007 08:30:35 -0700 (PDT)
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: Sun, 12 Aug 2007 08:29:45 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
Thread-Index: AcfVZps1BZNs/e+/T7aePZVYAElOwgAGmAGAACX5VLAAPTY/gABPmHwgAJoqbHAACKtGUAAB/HqwAAP/ryAAINptcAA4DckgAAdB8rAAIUtUgA==
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]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail].b rocade .com> <34BDD [e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l7CFUZmG006339
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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: Sun, 12 Aug 2007 15:30:47 -0000
Status: RO
Content-Length: 4550

Anoop,

I am not asking to do per-VLAN hello only.
I am not prohibiting a shared Hello,
I am just saying that since we don't have implementation experience on
the shared hello it should not be the default solution.

You are unrealistic asking to have as a default solution something that
is not completely understood.

-- Silvano

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Saturday, August 11, 2007 4:55 PM
> To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
with
> all the VLAN tags
> 
> 
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Saturday, August 11, 2007 1:22 PM
> > To: Anoop Ghanwani; Eastlake III Donald-LDE008; [e-mail]
> > Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos
> > tagged with all the VLAN tags
> >
> >
> > Anoop,
> >
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > Sent: Friday, August 10, 2007 10:31 AM
> > > To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> > > Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos
tagged
> > with
> > > all the VLAN tags
> > >
> > >
> > > anoop> We're doing things to detect those corner cases where
things
> > are
> > > anoop> misconfigured.
> > >
> > > silvano> But you have failed to prove that "these things"
> > are robust.
> > > silvano>
> > > silvano> Sending a Hello on each VLAN is robust and it
> > should be the
> > > silvano> default solution.
> > >
> > > It's a question of what the robustness requirement is.
> > > I believe the solution Radia has proposed is adequate.
> > > There is one corner case pointed out by Dinesh where one may get
> > > duplication of traffic for a short period (probably a few seconds)
> > > until the misconfiguration is detected.  I think this is adequate.
> > >
> >
> > I strongly disagree.
> >
> > 1) Duplicated frames are bad and several applications cannot
> > tolerate them. I am pretty sure that one of your favorite
> > applications is FCoE (Fibre Channel over Ethernet). You don't
> > want to have duplicated SCSI frames.
> 
> That is true.  But it happens only when the network is
> misconfigured and that too for a limited time (i.e. until
> the misconfiguration is detected).
> 
> > 2) There is also the issue pointed out by James Carlson: "if
> > the user has two RBridges (R1 and R2) attached to the same
> > Ethernet subnetwork, and R1 supports only VLANs {A,B} while
> > R2 supports only VLANs {A,C}, then neither one can actually
> > be the DRB for that whole network."
> 
> This is not an issue because (and I think Radia has already
> pointed this out) we can always run the DRB election per VLAN
> or per group of VLANs over the base instance.
> 
> > 3) There are many other corner cases, but to point them out I
> > need the pseudo-code you intend to use. If you post it and
> > give me some time, I'll find the corner case.
> >
> > I remain opposed to use a technique different to per-VLAN Hello.
> > In general I think optimizations are better dealt with in the
> > second version of the protocol.
> 
> Let's take a hypothetical scenario and say we go with per VLAN
> hellos.  Let's say someone deploys it in their network and
> they have a clean edge-core-edge architecture - TRILL only
> runs in the core; traffic from edge ports is encap'ed and
> transported over the TRILL core.  There are 100's, perhaps
> 1000's of VLANs at the edges.  I start out with per-VLAN
> IS-IS hellos going out all ports (core and edge), but
> in the core I only have one VLAN.  I find that my CPU is
> having trouble keeping up (because of many edge ports
> and many VLANs on each of those ports).
> I figure IS-IS is not really
> buying me much at the edges so I turn it off on all those
> ports.  Things look and work great!  Next, I have a
> misconfiguration in my network (the kind that we've
> been talking about all along).  Now, with per-VLAN IS-IS
> off, I have no way to detect it -- bad stuff happens
> forever!!!  With the single instance running, I would at
> least have detected a problem and alerted the network operator.
> 
> The burden we would impose with per-VLAN IS-IS is
> unrealistic.  I urge you to give it a second thought.
> 
> Routers have come a long way today with distributed
> control plane architectures, but those push the cost
> of equipment up.
> 
> If we have to allow per-VLAN IS-IS messages they
> should be optional.
> 
> Anoop



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 l7BNskd2014965 for <[e-mail]>; Sat, 11 Aug 2007 16:54:50 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 11 Aug 2007 16:54:46 -0700
X-IronPort-AV: i="4.19,249,1183359600";  d="scan'208"; a="16502549:sNHT21120897"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 03084238381; Sat, 11 Aug 2007 16:54:46 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Sat, 11 Aug 2007 16:54:46 -0700
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, 11 Aug 2007 16:54:37 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
Thread-Index: AcfVZps1BZNs/e+/T7aePZVYAElOwgAGmAGAACX5VLAAPTY/gABPmHwgAJoqbHAACKtGUAAB/HqwAAP/ryAAINptcAA4DckgAAdB8rA=
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]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail].b rocade. com> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 11 Aug 2007 23:54:46.0291 (UTC) FILETIME=[FED20E30:01C7DC72]
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 l7BNskd2014965
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 11 Aug 2007 23:55:23 -0000
Status: RO
Content-Length: 3771

 

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Saturday, August 11, 2007 1:22 PM
> To: Anoop Ghanwani; Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos 
> tagged with all the VLAN tags
> 
> 
> Anoop,
> 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Friday, August 10, 2007 10:31 AM
> > To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> > Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> with
> > all the VLAN tags
> > 
> > 
> > anoop> We're doing things to detect those corner cases where things
> are
> > anoop> misconfigured.
> > 
> > silvano> But you have failed to prove that "these things" 
> are robust.
> > silvano>
> > silvano> Sending a Hello on each VLAN is robust and it 
> should be the 
> > silvano> default solution.
> > 
> > It's a question of what the robustness requirement is.
> > I believe the solution Radia has proposed is adequate.
> > There is one corner case pointed out by Dinesh where one may get 
> > duplication of traffic for a short period (probably a few seconds) 
> > until the misconfiguration is detected.  I think this is adequate.
> > 
> 
> I strongly disagree. 
> 
> 1) Duplicated frames are bad and several applications cannot 
> tolerate them. I am pretty sure that one of your favorite 
> applications is FCoE (Fibre Channel over Ethernet). You don't 
> want to have duplicated SCSI frames.

That is true.  But it happens only when the network is
misconfigured and that too for a limited time (i.e. until
the misconfiguration is detected).

> 2) There is also the issue pointed out by James Carlson: "if 
> the user has two RBridges (R1 and R2) attached to the same 
> Ethernet subnetwork, and R1 supports only VLANs {A,B} while 
> R2 supports only VLANs {A,C}, then neither one can actually 
> be the DRB for that whole network."

This is not an issue because (and I think Radia has already
pointed this out) we can always run the DRB election per VLAN
or per group of VLANs over the base instance.

> 3) There are many other corner cases, but to point them out I 
> need the pseudo-code you intend to use. If you post it and 
> give me some time, I'll find the corner case.
>
> I remain opposed to use a technique different to per-VLAN Hello.
> In general I think optimizations are better dealt with in the 
> second version of the protocol.

Let's take a hypothetical scenario and say we go with per VLAN
hellos.  Let's say someone deploys it in their network and
they have a clean edge-core-edge architecture - TRILL only
runs in the core; traffic from edge ports is encap'ed and
transported over the TRILL core.  There are 100's, perhaps
1000's of VLANs at the edges.  I start out with per-VLAN
IS-IS hellos going out all ports (core and edge), but
in the core I only have one VLAN.  I find that my CPU is
having trouble keeping up (because of many edge ports
and many VLANs on each of those ports).  
I figure IS-IS is not really
buying me much at the edges so I turn it off on all those
ports.  Things look and work great!  Next, I have a 
misconfiguration in my network (the kind that we've 
been talking about all along).  Now, with per-VLAN IS-IS
off, I have no way to detect it -- bad stuff happens
forever!!!  With the single instance running, I would at 
least have detected a problem and alerted the network operator.

The burden we would impose with per-VLAN IS-IS is
unrealistic.  I urge you to give it a second thought.

Routers have come a long way today with distributed
control plane architectures, but those push the cost
of equipment up.

If we have to allow per-VLAN IS-IS messages they
should be optional.
 
Anoop



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l7BKMRw6019348 for <[e-mail]>; Sat, 11 Aug 2007 13:22:27 -0700 (PDT)
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, 11 Aug 2007 13:21:38 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
Thread-Index: AcfVZps1BZNs/e+/T7aePZVYAElOwgAGmAGAACX5VLAAPTY/gABPmHwgAJoqbHAACKtGUAAB/HqwAAP/ryAAINptcAA4Dckg
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]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail].c om>
From: "Silvano Gai" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l7BKMRw6019348
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 11 Aug 2007 20:22:52 -0000
Status: RO
Content-Length: 2271

Anoop,

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Friday, August 10, 2007 10:31 AM
> To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
with
> all the VLAN tags
> 
> 
> anoop> We're doing things to detect those corner cases where things
are
> anoop> misconfigured.
> 
> silvano> But you have failed to prove that "these things" are robust.
> silvano>
> silvano> Sending a Hello on each VLAN is robust and it should be the
> silvano> default solution.
> 
> It's a question of what the robustness requirement is.
> I believe the solution Radia has proposed is adequate.
> There is one corner case pointed out by Dinesh where
> one may get duplication of traffic for a short period
> (probably a few seconds) until the misconfiguration is
> detected.  I think this is adequate.
> 

I strongly disagree. 

1) Duplicated frames are bad and several applications cannot tolerate
them. I am pretty sure that one of your favorite applications is FCoE
(Fibre Channel over Ethernet). You don't want to have duplicated SCSI
frames.

2) There is also the issue pointed out by James Carlson: "if the user
has two RBridges (R1 and R2) attached to the same Ethernet subnetwork,
and R1 supports only VLANs {A,B} while R2 supports only VLANs {A,C},
then neither one can actually be the DRB for that whole network."

3) There are many other corner cases, but to point them out I need the
pseudo-code you intend to use. If you post it and give me some time,
I'll find the corner cases.

I remain opposed to use a technique different to per-VLAN Hello.
In general I think optimizations are better dealt with in the second
version of the protocol.

I also remain strongly in favor of doing a last call on the frame
format: if we continue to introduce optimization in the control plane,
it will be a while before the control plane is stable.

-- Silvano


> Other than that I don't see any issues.
> If there are any other scenarios you are concerned
> about please post them.
> 
> If at all, the per-VLAN IS-IS instances should be
> optional.  Those that are willing to bear the cost
> for whatever benefit it gives them may choose to
> implement it.
> 
> Anoop



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l7AHUsm6005118 for <[e-mail]>; Fri, 10 Aug 2007 10:30:54 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 10 Aug 2007 10:30:48 -0700
X-IronPort-AV: i="4.19,245,1183359600";  d="scan'208"; a="11926735:sNHT17001089"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id E01BE23837D; Fri, 10 Aug 2007 10:30:48 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 10 Aug 2007 10:30:48 -0700
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: Fri, 10 Aug 2007 10:30:39 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
Thread-Index: AcfVZps1BZNs/e+/T7aePZVYAElOwgAGmAGAACX5VLAAPTY/gABPmHwgAJoqbHAACKtGUAAB/HqwAAP/ryAAINptcA==
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]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 10 Aug 2007 17:30:48.0898 (UTC) FILETIME=[310D1A20:01C7DB74]
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 l7AHUsm6005118
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 10 Aug 2007 17:31:05 -0000
Status: RO
Content-Length: 876

anoop> We're doing things to detect those corner cases where things are 
anoop> misconfigured.
 
silvano> But you have failed to prove that "these things" are robust.
silvano> 
silvano> Sending a Hello on each VLAN is robust and it should be the 
silvano> default solution.

It's a question of what the robustness requirement is.
I believe the solution Radia has proposed is adequate.
There is one corner case pointed out by Dinesh where
one may get duplication of traffic for a short period
(probably a few seconds) until the misconfiguration is
detected.  I think this is adequate.  

Other than that I don't see any issues.
If there are any other scenarios you are concerned
about please post them.

If at all, the per-VLAN IS-IS instances should be
optional.  Those that are willing to bear the cost
for whatever benefit it gives them may choose to
implement it.

Anoop



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 l7A3lSuo011289 for <[e-mail]>; Thu, 9 Aug 2007 20:47:28 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-7.tower-153.messagelabs.com!1186717647!5502499!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 30233 invoked from network); 10 Aug 2007 03:47:27 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-153.messagelabs.com with SMTP; 10 Aug 2007 03:47:27 -0000
Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l7A3lQSG029371 for <[e-mail]>; Thu, 9 Aug 2007 20:47:27 -0700 (MST)
Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l7A3lPXF022829 for <[e-mail]>; Thu, 9 Aug 2007 22:47:26 -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 l7A3lOmn022820 for <[e-mail]>; Thu, 9 Aug 2007 22:47:25 -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: Thu, 9 Aug 2007 23:47:18 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft links have been updated on Rbridge home page
thread-index: AcfbASX04XZdLAxxQ0OYrO2CkMbjmQ==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Vontu: Pass
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 l7A3lSuo011289
Subject: [rbridge] Draft links have been updated on Rbridge home page
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, 10 Aug 2007 03:47:42 -0000
Status: RO
Content-Length: 125

Thanks to Joe Touch, the latest drafts are now linked out of the Rbridge
home page at
http://www.postel.org/rbridge

Donald



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l7A1gUuG010260 for <[e-mail]>; Thu, 9 Aug 2007 18:42:30 -0700 (PDT)
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, 9 Aug 2007 18:41:42 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
Thread-Index: AcfVZps1BZNs/e+/T7aePZVYAElOwgAGmAGAACX5VLAAPTY/gABPmHwgAJoqbHAACKtGUAAB/HqwAAP/ryA=
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]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l7A1gUuG010260
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 10 Aug 2007 01:42:58 -0000
Status: RO
Content-Length: 17210

Anoop,

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Thursday, August 09, 2007 5:00 PM
> To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
with
> all the VLAN tags
> 
> 
> Hi Silvano,
> 
> We're doing things to detect those corner cases where
> things are misconfigured.  

But you have failed to prove that "these things" are robust.

Sending a Hello on each VLAN is robust and it should be the default
solution.

-- Silvano


If I'm migrating a network
> to using RBridges and bridge port that I'm about to
> switch to the RBridge happens to be receiving traffic
> from 200 VLANs, I will need to start sending 200 hellos
> on that port.  If the control plane runs into scaling
> problems, the only way to solve this issue would
> be to start splitting all the traffic that goes
> into _one_ regular bridge across multiple RBridges.
> 
> Anoop
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Silvano Gai
> > Sent: Thursday, August 09, 2007 3:59 PM
> > To: Eastlake III Donald-LDE008; [e-mail]
> > Subject: Re: [rbridge] Avoiding sending multiple IS-IS
> > Hellostaggedwithallthe VLAN tags
> >
> >
> > Donald,
> >
> > I never asked to send 4094 Hellos on every port.
> >
> > If you read IEEE 802.1Q-2005, A.12 Implementation parameters,
> > you will see that you can specify the VLAN design parameters
> > for a Bridge.
> >
> > If you read 5.3 VLAN-aware Bridge requirements you see that
> > only one VLAN is required to be supported for compliance.
> >
> > An RBridge should do exactly the same, specify these
> > parameters and send by default an Hello for each supported
> > VLAN (see item IMP-4), since per-VLAN is the only robust
> > solution that works in any configuration.
> >
> > I am OK with an option to enable the single-VLAN, and this
> > may work well in network that are appropriately designed, but
> > I am pretty sure that there are corner cases in which it does
> > not work.
> >
> > If in this second case you want to have different RBridge
> > implementation parameters (e.g. more VLANs supported) I am OK.
> >
> > Cheers
> >
> > -- Silvano
> >
> > > -----Original Message-----
> > > From: [e-mail]
[mailto:[e-mail]]
> > On
> > > Behalf Of Eastlake III Donald-LDE008
> > > Sent: Thursday, August 09, 2007 12:52 PM
> > > To: [e-mail]
> > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
> > > taggedwithallthe VLAN tags
> > >
> > > Hi Silvano,
> > >
> > > Defaulting to having to send 4094 Hellos on every port
> > seems like an
> > > excessive burden for low end and middle range Rbridges, for
> > software
> > > implementations, unmanaged Rbridges, etc. On the other hand, in
high
> > end
> > > Rbridges, where this would not be much of a burden, you generally
> > > already have a lot of configuration going on. In fact, you
> > don't have
> > a
> > > problem that needs to be solved with these thousands of Hellos per
> > port
> > > unless you have complex legacy configured 802.1Q bridged
> > LANs in the
> > > picture, which I would think almost entirely occurs at the high
end.
> > >
> > > While I certainly don't think the interests of high end Rbridges
> > should
> > > be ignored, I also don't think other use scenarios should
> > be ignored.
> > >
> > > Low end and mid-range Rbridges, where sending large numbers
> > of Hellos
> > > would be the most burdensome, are the Rbridges most likely to be
> > > unmanaged or minimally managed, and in these cases the networks
are
> > > likely to be fairly simple, without discontinuous legacy
> > bridge VLANs.
> > > High end Rbridges, where sending large number of Hellos
> > would be less
> > > burdensome, are the Rbridges very likely to be heavily managed and
> > > configured, so it does not seem to me that it should be
> > that much of a
> > > problem for those network manages to configure them to do multiple
> > > Hellos. Also these high end Rbridges are more likely to be
connected
> > to
> > > complex discontinuous VLAN legacy bridged LANs where the multiple
> > Hellos
> > > might actually be needed.
> > >
> > > Furthermore, the desired end state is that there aren't any legacy
> > 802.1
> > > Q bridges in the network and it seems very wasteful, in that end
> > state,
> > > to have to keep configuring Rbridges just to turn off
> > multiple Hellos.
> > >
> > > Based on the above, my conclusion is that the zero configuration
> > default
> > > should be to send a single Hello.
> > >
> > > As I've described before, I tend to think this Hello should
> > by default
> > > be sent with maximum priority 7 but no VLAN ID (i.e., the VLAN ID
> > field
> > > should be zero) and thus the technically correct description of
the
> > zero
> > > configuration default Rbridge Hello frames is that they are
> > "priority
> > > tagged" with priority 7.
> > >
> > > Donald
> > >
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Monday, August 06, 2007 1:08 PM
> > > To: Eastlake III Donald-LDE008; [e-mail]
> > > Subject: RE: [rbridge] Avoiding sending multiple IS-IS
> > Hellos tagged
> > > withallthe VLAN tags
> > >
> > > Donald,
> > >
> > > I am OK with this change as long as the default is to run one DRB
> > > election per VLAN, since this is the most robust scheme.
> > >
> > > -- Silvano
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > [mailto:[e-mail]]
> > > On
> > > > Behalf Of Eastlake III Donald-LDE008
> > > > Sent: Saturday, August 04, 2007 8:58 PM
> > > > To: [e-mail]
> > > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS
> > Hellos tagged
> > > > withallthe VLAN tags
> > > >
> > > > Silvano,
> > > >
> > > > I think that the provisions in the draft should be changed. At a
> > > > minimum, it seems useful when someone is doing a DRB
> > election on one
> > > > VLAN intending to produce results that apply to multiple
> > VLANs that
> > > the
> > > > Hellos list the VLANs and be able to specify different
priorities
> > for
> > > > them so the elections are not all required to come out
> > the same. And
> > > > some additional logic to handle partitions seems reasonable.
> > > >
> > > > Donald
> > > >
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Friday, August 03, 2007 5:59 PM
> > > > To: Eastlake III Donald-LDE008; [e-mail]
> > > > Subject: RE: [rbridge] Avoiding sending multiple IS-IS
> > Hellos tagged
> > > > withall the VLAN tags
> > > >
> > > > Donald,
> > > >
> > > > I am OK with the text in -05, I thought that Radia wanted
> > to change
> > > it.
> > > >
> > > > As far as I am not prevented from running one DRB per
> > VLAN, I don't
> > > care
> > > > too much which is the default.
> > > >
> > > > I don't want TRILL to mandate implementing a single DRB
> > election and
> > > > additional tests that don't cover all the cases.
> > > >
> > > > Let's keep it simple. The current text is fine.
> > > >
> > > > -- Silvano
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > [mailto:[e-mail]]
> > > > On
> > > > > Behalf Of Eastlake III Donald-LDE008
> > > > > Sent: Friday, August 03, 2007 1:37 PM
> > > > > To: [e-mail]
> > > > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
> > tagged
> > > > > withall the VLAN tags
> > > > >
> > > > > So why should the default be to tag Hellos with any VLAN ID?
It
> > > seems
> > > > to
> > > > > me that there are two cases.
> > > > >
> > > > > If you know, via configuration or otherwise, that there are no
> > > > > intervening legacy bridges (doesn't particularly matter if its
> > > > > point-to-point between two Rbridges or a multiaccess link with
> > > several
> > > > > Rbridges as long as there are no bridges in the way), then all
> > TRILL
> > > > > IS-IS and TRILL data frames should be untagged.
> > > > >
> > > > > If there are or might be intervening bridges, then I would
think
> > the
> > > > > default should be for Hellos to be priority tagged with
priority
> > 7.
> > > > This
> > > > > means the tag has the null VLAN ID zero, that is, it does not
> > > specify
> > > > > any VLAN. If it turns out there actually aren't any
> > bridges, this
> > > > works
> > > > > fine. If the link is actually a bridged LAN, the requirement
is
> > then
> > > > > that the bridge ports that the Rbridges are connected to be
> > > configured
> > > > > to be the same VLAN, whatever that is, and that that VLAN be
> > > connected
> > > > > through that particular bridged LAN. If these bridge ports are
> > > default
> > > > > configured, this means the TRILL IS-IS Hello frames will
acquire
> > > VLAN
> > > > 1
> > > > > tagging on bridged LAN ingress and have that tag stripped on
> > bridged
> > > > LAN
> > > > > egress and you would want VLAN 1 to be well connected
> > through the
> > > > > bridged LAN. If, for some reason, VLAN 1 is inconvenient for
the
> > > > network
> > > > > operator to use in the particular bridged LAN in question, the
> > > network
> > > > > operator would be free to configure the bridge ports so that
the
> > > TRILL
> > > > > frames get tagged with whatever VLAN is more convenient for
them
> > to
> > > > use
> > > > > to provide connectivity. It could still be possible to
> > configure
> > > > > Rbridges, on a per port basis, to tag outgoing TRILL frames
with
> > > some
> > > > > specific VLAN ID if that is more convenient.
> > > > >
> > > > > I would like to point out that, while the proposal from Radia
> > below
> > > is
> > > > > much more detailed and better worked out and while the related
> > > > > provisions in the current protocol draft are much more vague,
> > > > > nevertheless, the current protocol draft approximately
> > corresponds
> > > to
> > > > > this proposal. In particular, due to previous concerns about
> > > multiple
> > > > > Hellos, among other things the protocol draft (-05) says:
> > > > >
> > > > > Section 2, Page 7:
> > > > >    If a link is actually a bridged LAN configured for
> > VLANs, it is
> > > > >    possible that the link might be partitioned with respect to
> > some
> > > > >    VLANs.  The default is to run a single DRB election
> > on a link,
> > > with
> > > > >    the IS-IS Hellos either with no VLAN tag (the
> > default), or with
> > > the
> > > > >    VLAN tag specifying the default VLAN for the link. If the
> > RBridge
> > > > is
> > > > >    configured to support a set of k VLANs on the link, then
the
> > > > RBridge
> > > > >    runs the IS-IS DRB election up to k times, each
> > instance tagged
> > > > with
> > > > >    one of the VLANs in that set of VLANs depending on its
> > > > configuration.
> > > > >    Therefore there might be multiple DRBs on the link,
> > but at most
> > > one
> > > > >    on that link per VLAN. By configuration, the DRB for
> > some VLANs
> > > may
> > > > >    be set by copying the DRB status in the relevant
> > RBridges from
> > a
> > > > >    different VLAN rather than by election.
> > > > >
> > > > > So, arguably, the single Hello proposal below is approximately
> > like
> > > > > using the current vague provisions in the protocol configured
to
> > > only
> > > > > Hello on VLAN 1 and applying the result to all VLANs. The main
> > > > > difference is the proposal provides the per VLAN
> > priorities in the
> > > > Hello
> > > > > so you don't need this stuff about copying DRB status but can
> > > > > independently determine it for different VLANs without
> > a per VLAN
> > > > > Hello...
> > > > >
> > > > > Donald
> > > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > [mailto:[e-mail]]
> > > > On
> > > > > Behalf Of Radia Perlman
> > > > > Sent: Thursday, August 02, 2007 8:23 PM
> > > > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
> > tagged
> > > > > with allthe VLAN tags
> > > > >
> > > > > ...
> > > > >
> > > > > But at this point let's close this issue, which is basically
to
> > > adopt
> > > > > Anoop's
> > > > > proposal of only sending IS-IS Hellos tagged with VLAN
> > 1, plus my
> > > > > addendum to avoid temporary loops when VLAN 1 is
> > partitioned
> > > > by
> > > > > having RB2 refuse to decapsulate packets onto a port
> > from ingress
> > > > > RBridge RB1 unless
> > > > > RB2 has received LSPs from RB1 and all pseudonodes that
> > RB1 is DRB
> > > > for.
> > > > >
> > > > > *************
> > > > > To review it:
> > > > >
> > > > > a) declare that bridges must be configured so that VLAN
> > 1 (default
> > > > > VLAN) must not be partitioned on a layer 2 cloud. We
> > will detect
> > > > > the
> > misconfiguration
> > > > > if it occurs (see d)) so that we do not have loops, but
> > if VLAN 1
> > > > > is partitioned parts of the layer 2 cloud might wind up
> > orphaned
> > > > > from the rest of the campus.
> > > > >
> > > > > b) Send IS-IS Hellos tagged with VLAN 1, containing the
> > following:
> > > > >
> > > > > . I am R1
> > > > > . I hear Hellos from {R2, R3, R7, R11} . If I am DRB, the
> > > > > pseudonode name will be R1.59 . My priority for the set
> > of VLANs
> > > > > {A, D, W} is 7 . My priority for the set of VLANs {B,
> > C, F, G, H}
> > > > > is 3
> > > > >
> > > > > c) If R1 becomes DRB for at least one of the VLANs on
> > the cloud,
> > > > > then R1 announces (in R1's LSP) connectivity to
> > pseudonode R1.59,
> > > > > together with a flag saying "I am DRB for this
> > pseudonode". Also,
> > > > > in R1's LSP on behalf of pseudonode R1.59, R1 announces
> > the ID of
> > > > > the root bridge on the primary spanning tree instance for that
> > > > > layer 2 cloud, along with the set of VLANs for
> > > which
> > > > > R1 is DRB on that cloud.
> > > > >
> > > > > d) If R2 thinks itself is DRB for VLAN A on a port with root
> > bridge
> > > > r11,
> > > > > and R2 sees an LSP for R1.59 that has the same root bridge and
> > VLAN
> > > A
> > > > > listed as one of the VLANs, this indicates that VLAN 1 on that
> > layer
> > > > > 2 cloud is partitioned. So one of R1 or R2 should stop
> > forwarding
> > > > > data to/from that cloud for VLAN A. Use ID as a tie
> > breaker, so if
> > > > > R2's IS-IS system ID is lower than R1's, then R2 stops
> > forwarding
> > > > > VLAN A
> > > > > traffic to and from the port that has root bridge r11.
> > > > > This is the behavior that will occur if VLAN 1 on that port is
> > > > > actually partitioned. If VLAN 1 is *not* partitioned,
> > then R1 and
> > R2
> > > > > would
> > > > > have seen each other's Hellos and not both think they
> > are DRB for
> > > VLAN
> > > > A
> > > > > (or
> > > > > any other VLAN).
> > > > >
> > > > > e) This proposal supports multiple DRBs on a cloud for load
> > > splitting
> > > > > based on VLANs, since the RBridges can have different
> > priorities
> > > > > for different VLANs. It still requires only sending one Hello,
> > > tagged
> > > > > with VLAN 1. R2 should
> > > > > not panic if R2 notices that R1.59 has the same root
> > bridge as on
> > > > > a port on which R2 is DRB, if R1.59's listed set of
> > VLANs does not
> > > > > include any VLANs for which R2 is DRB on the link with
> > that root
> > > > > bridge. If there is only partial overlap of VLAN IDs, say the
> > > > > overlap is VLANs {D, F, and H}, then (the loser based on ID
> > > > > tie-breaker) will stop forwarding
> > > traffic
> > > > > to/from that link that is tagged with VLANs D, F, or H.
> > > > >
> > > > > f) If some VLAN, say VLAN C, is actually partitioned, then the
> > > > > result of this is that some VLAN C endnodes on that
> > layer 2 cloud
> > > > > will be orphaned. We will choose NOT to solve that.
> > > > >
> > > > > g) To avoid temporary loops when VLAN 1 is partitioned,
> > for each
> > > > > other RBridge RB1, RB2 sets an (internal) flag "OK to
> > decapsulate
> > > > > from", provided that RB2 has an LSP from RB1 and all
pseudonodes
> > > > > RB1 claims to be attached to. If RB2 receives a frame
> > from ingress
> > > > > RB1 and this flag is NOT true, then RB2 will refuse to
> > decapsulate
> > > > > the packet onto any ports. (regardless of VLAN and regardless
of
> > > > whether
> > > > > the frame is multidestination or unicast).
> > > > >
> > > > >
> > > > > Radia
> > > > >
> > > > > _______________________________________________
> > > > > 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 mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l7A00TB0014156 for <[e-mail]>; Thu, 9 Aug 2007 17:00:33 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 09 Aug 2007 17:00:29 -0700
X-IronPort-AV: i="4.19,243,1183359600";  d="scan'208"; a="16410153:sNHT103060741"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 358D7238378; Thu,  9 Aug 2007 17:00:29 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 9 Aug 2007 17:00:29 -0700
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, 9 Aug 2007 17:00:21 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
Thread-Index: AcfVZps1BZNs/e+/T7aePZVYAElOwgAGmAGAACX5VLAAPTY/gABPmHwgAJoqbHAACKtGUAAB/Hqw
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]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 10 Aug 2007 00:00:29.0191 (UTC) FILETIME=[7660F170:01C7DAE1]
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 l7A00TB0014156
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 10 Aug 2007 00:01:13 -0000
Status: RO
Content-Length: 15977

Hi Silvano,

We're doing things to detect those corner cases where
things are misconfigured.  If I'm migrating a network
to using RBridges and bridge port that I'm about to
switch to the RBridge happens to be receiving traffic 
from 200 VLANs, I will need to start sending 200 hellos
on that port.  If the control plane runs into scaling
problems, the only way to solve this issue would
be to start splitting all the traffic that goes
into _one_ regular bridge across multiple RBridges.

Anoop

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Silvano Gai
> Sent: Thursday, August 09, 2007 3:59 PM
> To: Eastlake III Donald-LDE008; [e-mail]
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS 
> Hellostaggedwithallthe VLAN tags
> 
> 
> Donald,
> 
> I never asked to send 4094 Hellos on every port.
> 
> If you read IEEE 802.1Q-2005, A.12 Implementation parameters, 
> you will see that you can specify the VLAN design parameters 
> for a Bridge.
> 
> If you read 5.3 VLAN-aware Bridge requirements you see that 
> only one VLAN is required to be supported for compliance.
> 
> An RBridge should do exactly the same, specify these 
> parameters and send by default an Hello for each supported 
> VLAN (see item IMP-4), since per-VLAN is the only robust 
> solution that works in any configuration.
> 
> I am OK with an option to enable the single-VLAN, and this 
> may work well in network that are appropriately designed, but 
> I am pretty sure that there are corner cases in which it does 
> not work.
> 
> If in this second case you want to have different RBridge 
> implementation parameters (e.g. more VLANs supported) I am OK.
> 
> Cheers
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eastlake III Donald-LDE008
> > Sent: Thursday, August 09, 2007 12:52 PM
> > To: [e-mail]
> > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos 
> > taggedwithallthe VLAN tags
> > 
> > Hi Silvano,
> > 
> > Defaulting to having to send 4094 Hellos on every port 
> seems like an 
> > excessive burden for low end and middle range Rbridges, for 
> software 
> > implementations, unmanaged Rbridges, etc. On the other hand, in high
> end
> > Rbridges, where this would not be much of a burden, you generally 
> > already have a lot of configuration going on. In fact, you 
> don't have
> a
> > problem that needs to be solved with these thousands of Hellos per
> port
> > unless you have complex legacy configured 802.1Q bridged 
> LANs in the 
> > picture, which I would think almost entirely occurs at the high end.
> > 
> > While I certainly don't think the interests of high end Rbridges
> should
> > be ignored, I also don't think other use scenarios should 
> be ignored.
> > 
> > Low end and mid-range Rbridges, where sending large numbers 
> of Hellos 
> > would be the most burdensome, are the Rbridges most likely to be 
> > unmanaged or minimally managed, and in these cases the networks are 
> > likely to be fairly simple, without discontinuous legacy 
> bridge VLANs.
> > High end Rbridges, where sending large number of Hellos 
> would be less 
> > burdensome, are the Rbridges very likely to be heavily managed and 
> > configured, so it does not seem to me that it should be 
> that much of a 
> > problem for those network manages to configure them to do multiple 
> > Hellos. Also these high end Rbridges are more likely to be connected
> to
> > complex discontinuous VLAN legacy bridged LANs where the multiple
> Hellos
> > might actually be needed.
> > 
> > Furthermore, the desired end state is that there aren't any legacy
> 802.1
> > Q bridges in the network and it seems very wasteful, in that end
> state,
> > to have to keep configuring Rbridges just to turn off 
> multiple Hellos.
> > 
> > Based on the above, my conclusion is that the zero configuration
> default
> > should be to send a single Hello.
> > 
> > As I've described before, I tend to think this Hello should 
> by default 
> > be sent with maximum priority 7 but no VLAN ID (i.e., the VLAN ID
> field
> > should be zero) and thus the technically correct description of the
> zero
> > configuration default Rbridge Hello frames is that they are 
> "priority 
> > tagged" with priority 7.
> > 
> > Donald
> > 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Monday, August 06, 2007 1:08 PM
> > To: Eastlake III Donald-LDE008; [e-mail]
> > Subject: RE: [rbridge] Avoiding sending multiple IS-IS 
> Hellos tagged 
> > withallthe VLAN tags
> > 
> > Donald,
> > 
> > I am OK with this change as long as the default is to run one DRB 
> > election per VLAN, since this is the most robust scheme.
> > 
> > -- Silvano
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> [mailto:[e-mail]]
> > On
> > > Behalf Of Eastlake III Donald-LDE008
> > > Sent: Saturday, August 04, 2007 8:58 PM
> > > To: [e-mail]
> > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS 
> Hellos tagged 
> > > withallthe VLAN tags
> > >
> > > Silvano,
> > >
> > > I think that the provisions in the draft should be changed. At a 
> > > minimum, it seems useful when someone is doing a DRB 
> election on one 
> > > VLAN intending to produce results that apply to multiple 
> VLANs that
> > the
> > > Hellos list the VLANs and be able to specify different priorities
> for
> > > them so the elections are not all required to come out 
> the same. And 
> > > some additional logic to handle partitions seems reasonable.
> > >
> > > Donald
> > >
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Friday, August 03, 2007 5:59 PM
> > > To: Eastlake III Donald-LDE008; [e-mail]
> > > Subject: RE: [rbridge] Avoiding sending multiple IS-IS 
> Hellos tagged 
> > > withall the VLAN tags
> > >
> > > Donald,
> > >
> > > I am OK with the text in -05, I thought that Radia wanted 
> to change
> > it.
> > >
> > > As far as I am not prevented from running one DRB per 
> VLAN, I don't
> > care
> > > too much which is the default.
> > >
> > > I don't want TRILL to mandate implementing a single DRB 
> election and 
> > > additional tests that don't cover all the cases.
> > >
> > > Let's keep it simple. The current text is fine.
> > >
> > > -- Silvano
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> [mailto:[e-mail]]
> > > On
> > > > Behalf Of Eastlake III Donald-LDE008
> > > > Sent: Friday, August 03, 2007 1:37 PM
> > > > To: [e-mail]
> > > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
> tagged
> > > > withall the VLAN tags
> > > >
> > > > So why should the default be to tag Hellos with any VLAN ID? It
> > seems
> > > to
> > > > me that there are two cases.
> > > >
> > > > If you know, via configuration or otherwise, that there are no 
> > > > intervening legacy bridges (doesn't particularly matter if its 
> > > > point-to-point between two Rbridges or a multiaccess link with
> > several
> > > > Rbridges as long as there are no bridges in the way), then all
> TRILL
> > > > IS-IS and TRILL data frames should be untagged.
> > > >
> > > > If there are or might be intervening bridges, then I would think
> the
> > > > default should be for Hellos to be priority tagged with priority
> 7.
> > > This
> > > > means the tag has the null VLAN ID zero, that is, it does not
> > specify
> > > > any VLAN. If it turns out there actually aren't any 
> bridges, this
> > > works
> > > > fine. If the link is actually a bridged LAN, the requirement is
> then
> > > > that the bridge ports that the Rbridges are connected to be
> > configured
> > > > to be the same VLAN, whatever that is, and that that VLAN be
> > connected
> > > > through that particular bridged LAN. If these bridge ports are
> > default
> > > > configured, this means the TRILL IS-IS Hello frames will acquire
> > VLAN
> > > 1
> > > > tagging on bridged LAN ingress and have that tag stripped on
> bridged
> > > LAN
> > > > egress and you would want VLAN 1 to be well connected 
> through the 
> > > > bridged LAN. If, for some reason, VLAN 1 is inconvenient for the
> > > network
> > > > operator to use in the particular bridged LAN in question, the
> > network
> > > > operator would be free to configure the bridge ports so that the
> > TRILL
> > > > frames get tagged with whatever VLAN is more convenient for them
> to
> > > use
> > > > to provide connectivity. It could still be possible to 
> configure 
> > > > Rbridges, on a per port basis, to tag outgoing TRILL frames with
> > some
> > > > specific VLAN ID if that is more convenient.
> > > >
> > > > I would like to point out that, while the proposal from Radia
> below
> > is
> > > > much more detailed and better worked out and while the related 
> > > > provisions in the current protocol draft are much more vague, 
> > > > nevertheless, the current protocol draft approximately 
> corresponds
> > to
> > > > this proposal. In particular, due to previous concerns about
> > multiple
> > > > Hellos, among other things the protocol draft (-05) says:
> > > >
> > > > Section 2, Page 7:
> > > >    If a link is actually a bridged LAN configured for 
> VLANs, it is
> > > >    possible that the link might be partitioned with respect to
> some
> > > >    VLANs.  The default is to run a single DRB election 
> on a link,
> > with
> > > >    the IS-IS Hellos either with no VLAN tag (the 
> default), or with
> > the
> > > >    VLAN tag specifying the default VLAN for the link. If the
> RBridge
> > > is
> > > >    configured to support a set of k VLANs on the link, then the
> > > RBridge
> > > >    runs the IS-IS DRB election up to k times, each 
> instance tagged
> > > with
> > > >    one of the VLANs in that set of VLANs depending on its
> > > configuration.
> > > >    Therefore there might be multiple DRBs on the link, 
> but at most
> > one
> > > >    on that link per VLAN. By configuration, the DRB for 
> some VLANs
> > may
> > > >    be set by copying the DRB status in the relevant 
> RBridges from
> a
> > > >    different VLAN rather than by election.
> > > >
> > > > So, arguably, the single Hello proposal below is approximately
> like
> > > > using the current vague provisions in the protocol configured to
> > only
> > > > Hello on VLAN 1 and applying the result to all VLANs. The main 
> > > > difference is the proposal provides the per VLAN 
> priorities in the
> > > Hello
> > > > so you don't need this stuff about copying DRB status but can 
> > > > independently determine it for different VLANs without 
> a per VLAN 
> > > > Hello...
> > > >
> > > > Donald
> > > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> [mailto:[e-mail]]
> > > On
> > > > Behalf Of Radia Perlman
> > > > Sent: Thursday, August 02, 2007 8:23 PM
> > > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
> tagged
> > > > with allthe VLAN tags
> > > >
> > > > ...
> > > >
> > > > But at this point let's close this issue, which is basically to
> > adopt
> > > > Anoop's
> > > > proposal of only sending IS-IS Hellos tagged with VLAN 
> 1, plus my 
> > > > addendum to avoid temporary loops when VLAN 1 is
> partitioned
> > > by
> > > > having RB2 refuse to decapsulate packets onto a port 
> from ingress 
> > > > RBridge RB1 unless
> > > > RB2 has received LSPs from RB1 and all pseudonodes that 
> RB1 is DRB
> > > for.
> > > >
> > > > *************
> > > > To review it:
> > > >
> > > > a) declare that bridges must be configured so that VLAN 
> 1 (default 
> > > > VLAN) must not be partitioned on a layer 2 cloud. We 
> will detect 
> > > > the
> misconfiguration
> > > > if it occurs (see d)) so that we do not have loops, but 
> if VLAN 1 
> > > > is partitioned parts of the layer 2 cloud might wind up 
> orphaned 
> > > > from the rest of the campus.
> > > >
> > > > b) Send IS-IS Hellos tagged with VLAN 1, containing the 
> following:
> > > >
> > > > . I am R1
> > > > . I hear Hellos from {R2, R3, R7, R11} . If I am DRB, the 
> > > > pseudonode name will be R1.59 . My priority for the set 
> of VLANs 
> > > > {A, D, W} is 7 . My priority for the set of VLANs {B, 
> C, F, G, H} 
> > > > is 3
> > > >
> > > > c) If R1 becomes DRB for at least one of the VLANs on 
> the cloud, 
> > > > then R1 announces (in R1's LSP) connectivity to 
> pseudonode R1.59, 
> > > > together with a flag saying "I am DRB for this 
> pseudonode". Also, 
> > > > in R1's LSP on behalf of pseudonode R1.59, R1 announces 
> the ID of 
> > > > the root bridge on the primary spanning tree instance for that 
> > > > layer 2 cloud, along with the set of VLANs for
> > which
> > > > R1 is DRB on that cloud.
> > > >
> > > > d) If R2 thinks itself is DRB for VLAN A on a port with root
> bridge
> > > r11,
> > > > and R2 sees an LSP for R1.59 that has the same root bridge and
> VLAN
> > A
> > > > listed as one of the VLANs, this indicates that VLAN 1 on that
> layer
> > > > 2 cloud is partitioned. So one of R1 or R2 should stop 
> forwarding 
> > > > data to/from that cloud for VLAN A. Use ID as a tie 
> breaker, so if 
> > > > R2's IS-IS system ID is lower than R1's, then R2 stops
> forwarding
> > > > VLAN A
> > > > traffic to and from the port that has root bridge r11.
> > > > This is the behavior that will occur if VLAN 1 on that port is 
> > > > actually partitioned. If VLAN 1 is *not* partitioned, 
> then R1 and
> R2
> > > > would
> > > > have seen each other's Hellos and not both think they 
> are DRB for
> > VLAN
> > > A
> > > > (or
> > > > any other VLAN).
> > > >
> > > > e) This proposal supports multiple DRBs on a cloud for load
> > splitting
> > > > based on VLANs, since the RBridges can have different 
> priorities 
> > > > for different VLANs. It still requires only sending one Hello,
> > tagged
> > > > with VLAN 1. R2 should
> > > > not panic if R2 notices that R1.59 has the same root 
> bridge as on 
> > > > a port on which R2 is DRB, if R1.59's listed set of 
> VLANs does not 
> > > > include any VLANs for which R2 is DRB on the link with 
> that root 
> > > > bridge. If there is only partial overlap of VLAN IDs, say the 
> > > > overlap is VLANs {D, F, and H}, then (the loser based on ID 
> > > > tie-breaker) will stop forwarding
> > traffic
> > > > to/from that link that is tagged with VLANs D, F, or H.
> > > >
> > > > f) If some VLAN, say VLAN C, is actually partitioned, then the 
> > > > result of this is that some VLAN C endnodes on that 
> layer 2 cloud 
> > > > will be orphaned. We will choose NOT to solve that.
> > > >
> > > > g) To avoid temporary loops when VLAN 1 is partitioned, 
> for each 
> > > > other RBridge RB1, RB2 sets an (internal) flag "OK to 
> decapsulate 
> > > > from", provided that RB2 has an LSP from RB1 and all pseudonodes
> > > > RB1 claims to be attached to. If RB2 receives a frame 
> from ingress
> > > > RB1 and this flag is NOT true, then RB2 will refuse to 
> decapsulate 
> > > > the packet onto any ports. (regardless of VLAN and regardless of
> > > whether
> > > > the frame is multidestination or unicast).
> > > >
> > > >
> > > > Radia
> > > >
> > > > _______________________________________________
> > > > 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 nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l79Mxwxo022542 for <[e-mail]>; Thu, 9 Aug 2007 15:59:58 -0700 (PDT)
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, 9 Aug 2007 15:59:02 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos taggedwithallthe VLAN tags
Thread-Index: AcfVZps1BZNs/e+/T7aePZVYAElOwgAGmAGAACX5VLAAPTY/gABPmHwgAJoqbHAACKtGUA==
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: "Silvano Gai" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l79Mxwxo022542
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos taggedwithallthe VLAN tags
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, 09 Aug 2007 23:00:05 -0000
Status: RO
Content-Length: 13998

Donald,

I never asked to send 4094 Hellos on every port.

If you read IEEE 802.1Q-2005, A.12 Implementation parameters, you will
see that you can specify the VLAN design parameters for a Bridge.

If you read 5.3 VLAN-aware Bridge requirements you see that only one
VLAN is required to be supported for compliance.

An RBridge should do exactly the same, specify these parameters and send
by default an Hello for each supported VLAN (see item IMP-4), since
per-VLAN is the only robust solution that works in any configuration.

I am OK with an option to enable the single-VLAN, and this may work well
in network that are appropriately designed, but I am pretty sure that
there are corner cases in which it does not work.

If in this second case you want to have different RBridge implementation
parameters (e.g. more VLANs supported) I am OK.

Cheers

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Thursday, August 09, 2007 12:52 PM
> To: [e-mail]
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
> taggedwithallthe VLAN tags
> 
> Hi Silvano,
> 
> Defaulting to having to send 4094 Hellos on every port seems like an
> excessive burden for low end and middle range Rbridges, for software
> implementations, unmanaged Rbridges, etc. On the other hand, in high
end
> Rbridges, where this would not be much of a burden, you generally
> already have a lot of configuration going on. In fact, you don't have
a
> problem that needs to be solved with these thousands of Hellos per
port
> unless you have complex legacy configured 802.1Q bridged LANs in the
> picture, which I would think almost entirely occurs at the high end.
> 
> While I certainly don't think the interests of high end Rbridges
should
> be ignored, I also don't think other use scenarios should be ignored.
> 
> Low end and mid-range Rbridges, where sending large numbers of Hellos
> would be the most burdensome, are the Rbridges most likely to be
> unmanaged or minimally managed, and in these cases the networks are
> likely to be fairly simple, without discontinuous legacy bridge VLANs.
> High end Rbridges, where sending large number of Hellos would be less
> burdensome, are the Rbridges very likely to be heavily managed and
> configured, so it does not seem to me that it should be that much of a
> problem for those network manages to configure them to do multiple
> Hellos. Also these high end Rbridges are more likely to be connected
to
> complex discontinuous VLAN legacy bridged LANs where the multiple
Hellos
> might actually be needed.
> 
> Furthermore, the desired end state is that there aren't any legacy
802.1
> Q bridges in the network and it seems very wasteful, in that end
state,
> to have to keep configuring Rbridges just to turn off multiple Hellos.
> 
> Based on the above, my conclusion is that the zero configuration
default
> should be to send a single Hello.
> 
> As I've described before, I tend to think this Hello should by default
> be sent with maximum priority 7 but no VLAN ID (i.e., the VLAN ID
field
> should be zero) and thus the technically correct description of the
zero
> configuration default Rbridge Hello frames is that they are "priority
> tagged" with priority 7.
> 
> Donald
> 
> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]]
> Sent: Monday, August 06, 2007 1:08 PM
> To: Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> withallthe VLAN tags
> 
> Donald,
> 
> I am OK with this change as long as the default is to run one DRB
> election per VLAN, since this is the most robust scheme.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eastlake III Donald-LDE008
> > Sent: Saturday, August 04, 2007 8:58 PM
> > To: [e-mail]
> > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> > withallthe VLAN tags
> >
> > Silvano,
> >
> > I think that the provisions in the draft should be changed. At a
> > minimum, it seems useful when someone is doing a DRB election on one
> > VLAN intending to produce results that apply to multiple VLANs that
> the
> > Hellos list the VLANs and be able to specify different priorities
for
> > them so the elections are not all required to come out the same. And
> > some additional logic to handle partitions seems reasonable.
> >
> > Donald
> >
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Friday, August 03, 2007 5:59 PM
> > To: Eastlake III Donald-LDE008; [e-mail]
> > Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> > withall the VLAN tags
> >
> > Donald,
> >
> > I am OK with the text in -05, I thought that Radia wanted to change
> it.
> >
> > As far as I am not prevented from running one DRB per VLAN, I don't
> care
> > too much which is the default.
> >
> > I don't want TRILL to mandate implementing a single DRB election and
> > additional tests that don't cover all the cases.
> >
> > Let's keep it simple. The current text is fine.
> >
> > -- Silvano
> >
> > > -----Original Message-----
> > > From: [e-mail]
[mailto:[e-mail]]
> > On
> > > Behalf Of Eastlake III Donald-LDE008
> > > Sent: Friday, August 03, 2007 1:37 PM
> > > To: [e-mail]
> > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
tagged
> > > withall the VLAN tags
> > >
> > > So why should the default be to tag Hellos with any VLAN ID? It
> seems
> > to
> > > me that there are two cases.
> > >
> > > If you know, via configuration or otherwise, that there are no
> > > intervening legacy bridges (doesn't particularly matter if its
> > > point-to-point between two Rbridges or a multiaccess link with
> several
> > > Rbridges as long as there are no bridges in the way), then all
TRILL
> > > IS-IS and TRILL data frames should be untagged.
> > >
> > > If there are or might be intervening bridges, then I would think
the
> > > default should be for Hellos to be priority tagged with priority
7.
> > This
> > > means the tag has the null VLAN ID zero, that is, it does not
> specify
> > > any VLAN. If it turns out there actually aren't any bridges, this
> > works
> > > fine. If the link is actually a bridged LAN, the requirement is
then
> > > that the bridge ports that the Rbridges are connected to be
> configured
> > > to be the same VLAN, whatever that is, and that that VLAN be
> connected
> > > through that particular bridged LAN. If these bridge ports are
> default
> > > configured, this means the TRILL IS-IS Hello frames will acquire
> VLAN
> > 1
> > > tagging on bridged LAN ingress and have that tag stripped on
bridged
> > LAN
> > > egress and you would want VLAN 1 to be well connected through the
> > > bridged LAN. If, for some reason, VLAN 1 is inconvenient for the
> > network
> > > operator to use in the particular bridged LAN in question, the
> network
> > > operator would be free to configure the bridge ports so that the
> TRILL
> > > frames get tagged with whatever VLAN is more convenient for them
to
> > use
> > > to provide connectivity. It could still be possible to configure
> > > Rbridges, on a per port basis, to tag outgoing TRILL frames with
> some
> > > specific VLAN ID if that is more convenient.
> > >
> > > I would like to point out that, while the proposal from Radia
below
> is
> > > much more detailed and better worked out and while the related
> > > provisions in the current protocol draft are much more vague,
> > > nevertheless, the current protocol draft approximately corresponds
> to
> > > this proposal. In particular, due to previous concerns about
> multiple
> > > Hellos, among other things the protocol draft (-05) says:
> > >
> > > Section 2, Page 7:
> > >    If a link is actually a bridged LAN configured for VLANs, it is
> > >    possible that the link might be partitioned with respect to
some
> > >    VLANs.  The default is to run a single DRB election on a link,
> with
> > >    the IS-IS Hellos either with no VLAN tag (the default), or with
> the
> > >    VLAN tag specifying the default VLAN for the link. If the
RBridge
> > is
> > >    configured to support a set of k VLANs on the link, then the
> > RBridge
> > >    runs the IS-IS DRB election up to k times, each instance tagged
> > with
> > >    one of the VLANs in that set of VLANs depending on its
> > configuration.
> > >    Therefore there might be multiple DRBs on the link, but at most
> one
> > >    on that link per VLAN. By configuration, the DRB for some VLANs
> may
> > >    be set by copying the DRB status in the relevant RBridges from
a
> > >    different VLAN rather than by election.
> > >
> > > So, arguably, the single Hello proposal below is approximately
like
> > > using the current vague provisions in the protocol configured to
> only
> > > Hello on VLAN 1 and applying the result to all VLANs. The main
> > > difference is the proposal provides the per VLAN priorities in the
> > Hello
> > > so you don't need this stuff about copying DRB status but can
> > > independently determine it for different VLANs without a per VLAN
> > > Hello...
> > >
> > > Donald
> > >
> > > -----Original Message-----
> > > From: [e-mail]
[mailto:[e-mail]]
> > On
> > > Behalf Of Radia Perlman
> > > Sent: Thursday, August 02, 2007 8:23 PM
> > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
tagged
> > > with allthe VLAN tags
> > >
> > > ...
> > >
> > > But at this point let's close this issue, which is basically to
> adopt
> > > Anoop's
> > > proposal of only sending IS-IS Hellos tagged with VLAN 1,
> > > plus my addendum to avoid temporary loops when VLAN 1 is
partitioned
> > by
> > > having RB2 refuse to decapsulate packets onto a port from ingress
> > > RBridge RB1 unless
> > > RB2 has received LSPs from RB1 and all pseudonodes that RB1 is DRB
> > for.
> > >
> > > *************
> > > To review it:
> > >
> > > a) declare that bridges must be configured
> > > so that VLAN 1 (default VLAN) must not be
> > > partitioned on a layer 2 cloud. We will detect the
misconfiguration
> > > if it occurs (see d)) so that we do not have loops, but if VLAN 1
> > > is partitioned parts of the layer 2 cloud might wind up orphaned
> > > from the rest of the campus.
> > >
> > > b) Send IS-IS Hellos tagged with VLAN 1, containing the following:
> > >
> > > . I am R1
> > > . I hear Hellos from {R2, R3, R7, R11}
> > > . If I am DRB, the pseudonode name will be R1.59
> > > . My priority for the set of VLANs {A, D, W} is 7
> > > . My priority for the set of VLANs {B, C, F, G, H} is 3
> > >
> > > c) If R1 becomes DRB for at least one of the VLANs on the cloud,
> > > then R1 announces (in R1's LSP)
> > > connectivity to pseudonode R1.59, together with
> > > a flag saying "I am DRB for this pseudonode". Also, in R1's LSP on
> > > behalf of pseudonode R1.59, R1 announces
> > > the ID of the root bridge on the primary spanning tree
> > > instance for that layer 2 cloud, along with the set of VLANs for
> which
> > > R1 is DRB on that cloud.
> > >
> > > d) If R2 thinks itself is DRB for VLAN A on a port with root
bridge
> > r11,
> > > and R2 sees an LSP for R1.59 that has the same root bridge and
VLAN
> A
> > > listed as one of the VLANs, this indicates that VLAN 1 on that
layer
> > > 2 cloud is partitioned. So one of R1 or R2 should stop forwarding
> > > data to/from that cloud for VLAN A. Use ID as a tie breaker, so
> > > if R2's IS-IS system ID is lower than R1's, then R2 stops
forwarding
> > > VLAN A
> > > traffic to and from the port that has root bridge r11.
> > > This is the behavior that will occur if VLAN 1 on that port is
> > > actually partitioned. If VLAN 1 is *not* partitioned, then R1 and
R2
> > > would
> > > have seen each other's Hellos and not both think they are DRB for
> VLAN
> > A
> > > (or
> > > any other VLAN).
> > >
> > > e) This proposal supports multiple DRBs on a cloud for load
> splitting
> > > based on VLANs, since the RBridges can have different priorities
> > > for different VLANs. It still requires only sending one Hello,
> tagged
> > > with VLAN 1. R2 should
> > > not panic if R2 notices that R1.59 has the same root bridge as on
> > > a port on which R2 is DRB, if R1.59's listed set of VLANs does not
> > > include any VLANs for which R2 is DRB on the link with
> > > that root bridge. If there is only partial overlap
> > > of VLAN IDs, say the overlap is VLANs {D, F, and H},
> > > then (the loser based on ID tie-breaker) will stop forwarding
> traffic
> > > to/from that link that is tagged with VLANs D, F, or H.
> > >
> > > f) If some VLAN, say VLAN C, is actually partitioned, then the
> > > result of this is that some VLAN C endnodes on that layer 2 cloud
> > > will be orphaned. We will choose NOT to solve that.
> > >
> > > g) To avoid temporary loops when VLAN 1 is partitioned, for each
> > > other RBridge RB1, RB2 sets an (internal) flag "OK to decapsulate
> > > from", provided that RB2 has an LSP from RB1 and all pseudonodes
> > > RB1 claims to be attached to. If RB2 receives a frame from ingress
> > > RB1 and this flag is NOT true, then RB2 will refuse to decapsulate
> > > the packet onto any ports. (regardless of VLAN and regardless of
> > whether
> > > the frame is multidestination or unicast).
> > >
> > >
> > > Radia
> > >
> > > _______________________________________________
> > > 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 sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l79MSOrA010215 for <[e-mail]>; Thu, 9 Aug 2007 15:28:24 -0700 (PDT)
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Aug 2007 15:28:24 -0700
X-IronPort-AV: i="4.19,243,1183359600";  d="scan'208"; a="197491789:sNHT73004121"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l79MSNKB014557;  Thu, 9 Aug 2007 15:28:23 -0700
Received: from [10.21.113.176] (sjc-vpn2-432.cisco.com [10.21.113.176]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l79MSNVp009693; Thu, 9 Aug 2007 22:28:23 GMT
Message-ID: <[e-mail]>
Date: Thu, 09 Aug 2007 15:28:23 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.5 (X11/20070716)
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]><[e-mail]><[e-mail]><[e-mail]><[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14398; t=1186698503; x=1187562503; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Avoiding=20sending=20multiple=20IS-IS=20H ellos=20tagged=09withallthe=0A=20VLAN=20tags |Sender:=20; bh=C3vmdded3Cb835IZ75g7BJkBRbfA9KX5orguigYlS2A=; b=n7BH749Ur3ln59GzaLHeZHV7PpjtIyoXkdOaN0tvUlJKkfWh+2KyFovJruH5uAPgd4iQ0pSV iA28jv2hzNmQIHJ+nWUqIVSJnJ3dNwWJbCDLkreq1xW4x3sHEe2xSy3E;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged	withallthe VLAN tags
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, 09 Aug 2007 22:28:39 -0000
Status: RO
Content-Length: 13975

I would like to add that as the "send only 1 Hello" proposal currently 
stands, it is possible that there can be duplicate frames for a 
transient period while the network quiesces. I believe there are many 
apps that work in existing L2 networks under the assumption that no 
duplicates will be seen and so can fail in mysterious ways when this 
happens. And detecting this as the cause will be incredibly hard. So 
saying "just enable per-active-VLAN Hellos when there is a problem" 
doesn't bite.

I'd like RBridges to be robust by default,

Dinesh
Eastlake III Donald-LDE008 wrote:
> Hi Silvano,
>
> Defaulting to having to send 4094 Hellos on every port seems like an
> excessive burden for low end and middle range Rbridges, for software
> implementations, unmanaged Rbridges, etc. On the other hand, in high end
> Rbridges, where this would not be much of a burden, you generally
> already have a lot of configuration going on. In fact, you don't have a
> problem that needs to be solved with these thousands of Hellos per port
> unless you have complex legacy configured 802.1Q bridged LANs in the
> picture, which I would think almost entirely occurs at the high end.
>
> While I certainly don't think the interests of high end Rbridges should
> be ignored, I also don't think other use scenarios should be ignored.
>
> Low end and mid-range Rbridges, where sending large numbers of Hellos
> would be the most burdensome, are the Rbridges most likely to be
> unmanaged or minimally managed, and in these cases the networks are
> likely to be fairly simple, without discontinuous legacy bridge VLANs.
> High end Rbridges, where sending large number of Hellos would be less
> burdensome, are the Rbridges very likely to be heavily managed and
> configured, so it does not seem to me that it should be that much of a
> problem for those network manages to configure them to do multiple
> Hellos. Also these high end Rbridges are more likely to be connected to
> complex discontinuous VLAN legacy bridged LANs where the multiple Hellos
> might actually be needed.
>
> Furthermore, the desired end state is that there aren't any legacy 802.1
> Q bridges in the network and it seems very wasteful, in that end state,
> to have to keep configuring Rbridges just to turn off multiple Hellos.
>
> Based on the above, my conclusion is that the zero configuration default
> should be to send a single Hello.
>
> As I've described before, I tend to think this Hello should by default
> be sent with maximum priority 7 but no VLAN ID (i.e., the VLAN ID field
> should be zero) and thus the technically correct description of the zero
> configuration default Rbridge Hello frames is that they are "priority
> tagged" with priority 7.
>
> Donald
>
> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Monday, August 06, 2007 1:08 PM
> To: Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> withallthe VLAN tags
>
> Donald,
>
> I am OK with this change as long as the default is to run one DRB
> election per VLAN, since this is the most robust scheme.
>
> -- Silvano
>
>   
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>>     
> On
>   
>> Behalf Of Eastlake III Donald-LDE008
>> Sent: Saturday, August 04, 2007 8:58 PM
>> To: [e-mail]
>> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
>> withallthe VLAN tags
>>
>> Silvano,
>>
>> I think that the provisions in the draft should be changed. At a
>> minimum, it seems useful when someone is doing a DRB election on one
>> VLAN intending to produce results that apply to multiple VLANs that
>>     
> the
>   
>> Hellos list the VLANs and be able to specify different priorities for
>> them so the elections are not all required to come out the same. And
>> some additional logic to handle partitions seems reasonable.
>>
>> Donald
>>
>> -----Original Message-----
>> From: Silvano Gai [mailto:[e-mail]]
>> Sent: Friday, August 03, 2007 5:59 PM
>> To: Eastlake III Donald-LDE008; [e-mail]
>> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
>> withall the VLAN tags
>>
>> Donald,
>>
>> I am OK with the text in -05, I thought that Radia wanted to change
>>     
> it.
>   
>> As far as I am not prevented from running one DRB per VLAN, I don't
>>     
> care
>   
>> too much which is the default.
>>
>> I don't want TRILL to mandate implementing a single DRB election and
>> additional tests that don't cover all the cases.
>>
>> Let's keep it simple. The current text is fine.
>>
>> -- Silvano
>>
>>     
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]
>>>       
>> On
>>     
>>> Behalf Of Eastlake III Donald-LDE008
>>> Sent: Friday, August 03, 2007 1:37 PM
>>> To: [e-mail]
>>> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
>>> withall the VLAN tags
>>>
>>> So why should the default be to tag Hellos with any VLAN ID? It
>>>       
> seems
>   
>> to
>>     
>>> me that there are two cases.
>>>
>>> If you know, via configuration or otherwise, that there are no
>>> intervening legacy bridges (doesn't particularly matter if its
>>> point-to-point between two Rbridges or a multiaccess link with
>>>       
> several
>   
>>> Rbridges as long as there are no bridges in the way), then all TRILL
>>> IS-IS and TRILL data frames should be untagged.
>>>
>>> If there are or might be intervening bridges, then I would think the
>>> default should be for Hellos to be priority tagged with priority 7.
>>>       
>> This
>>     
>>> means the tag has the null VLAN ID zero, that is, it does not
>>>       
> specify
>   
>>> any VLAN. If it turns out there actually aren't any bridges, this
>>>       
>> works
>>     
>>> fine. If the link is actually a bridged LAN, the requirement is then
>>> that the bridge ports that the Rbridges are connected to be
>>>       
> configured
>   
>>> to be the same VLAN, whatever that is, and that that VLAN be
>>>       
> connected
>   
>>> through that particular bridged LAN. If these bridge ports are
>>>       
> default
>   
>>> configured, this means the TRILL IS-IS Hello frames will acquire
>>>       
> VLAN
>   
>> 1
>>     
>>> tagging on bridged LAN ingress and have that tag stripped on bridged
>>>       
>> LAN
>>     
>>> egress and you would want VLAN 1 to be well connected through the
>>> bridged LAN. If, for some reason, VLAN 1 is inconvenient for the
>>>       
>> network
>>     
>>> operator to use in the particular bridged LAN in question, the
>>>       
> network
>   
>>> operator would be free to configure the bridge ports so that the
>>>       
> TRILL
>   
>>> frames get tagged with whatever VLAN is more convenient for them to
>>>       
>> use
>>     
>>> to provide connectivity. It could still be possible to configure
>>> Rbridges, on a per port basis, to tag outgoing TRILL frames with
>>>       
> some
>   
>>> specific VLAN ID if that is more convenient.
>>>
>>> I would like to point out that, while the proposal from Radia below
>>>       
> is
>   
>>> much more detailed and better worked out and while the related
>>> provisions in the current protocol draft are much more vague,
>>> nevertheless, the current protocol draft approximately corresponds
>>>       
> to
>   
>>> this proposal. In particular, due to previous concerns about
>>>       
> multiple
>   
>>> Hellos, among other things the protocol draft (-05) says:
>>>
>>> Section 2, Page 7:
>>>    If a link is actually a bridged LAN configured for VLANs, it is
>>>    possible that the link might be partitioned with respect to some
>>>    VLANs.  The default is to run a single DRB election on a link,
>>>       
> with
>   
>>>    the IS-IS Hellos either with no VLAN tag (the default), or with
>>>       
> the
>   
>>>    VLAN tag specifying the default VLAN for the link. If the RBridge
>>>       
>> is
>>     
>>>    configured to support a set of k VLANs on the link, then the
>>>       
>> RBridge
>>     
>>>    runs the IS-IS DRB election up to k times, each instance tagged
>>>       
>> with
>>     
>>>    one of the VLANs in that set of VLANs depending on its
>>>       
>> configuration.
>>     
>>>    Therefore there might be multiple DRBs on the link, but at most
>>>       
> one
>   
>>>    on that link per VLAN. By configuration, the DRB for some VLANs
>>>       
> may
>   
>>>    be set by copying the DRB status in the relevant RBridges from a
>>>    different VLAN rather than by election.
>>>
>>> So, arguably, the single Hello proposal below is approximately like
>>> using the current vague provisions in the protocol configured to
>>>       
> only
>   
>>> Hello on VLAN 1 and applying the result to all VLANs. The main
>>> difference is the proposal provides the per VLAN priorities in the
>>>       
>> Hello
>>     
>>> so you don't need this stuff about copying DRB status but can
>>> independently determine it for different VLANs without a per VLAN
>>> Hello...
>>>
>>> Donald
>>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]
>>>       
>> On
>>     
>>> Behalf Of Radia Perlman
>>> Sent: Thursday, August 02, 2007 8:23 PM
>>> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
>>> with allthe VLAN tags
>>>
>>> ...
>>>
>>> But at this point let's close this issue, which is basically to
>>>       
> adopt
>   
>>> Anoop's
>>> proposal of only sending IS-IS Hellos tagged with VLAN 1,
>>> plus my addendum to avoid temporary loops when VLAN 1 is partitioned
>>>       
>> by
>>     
>>> having RB2 refuse to decapsulate packets onto a port from ingress
>>> RBridge RB1 unless
>>> RB2 has received LSPs from RB1 and all pseudonodes that RB1 is DRB
>>>       
>> for.
>>     
>>> *************
>>> To review it:
>>>
>>> a) declare that bridges must be configured
>>> so that VLAN 1 (default VLAN) must not be
>>> partitioned on a layer 2 cloud. We will detect the misconfiguration
>>> if it occurs (see d)) so that we do not have loops, but if VLAN 1
>>> is partitioned parts of the layer 2 cloud might wind up orphaned
>>> from the rest of the campus.
>>>
>>> b) Send IS-IS Hellos tagged with VLAN 1, containing the following:
>>>
>>> . I am R1
>>> . I hear Hellos from {R2, R3, R7, R11}
>>> . If I am DRB, the pseudonode name will be R1.59
>>> . My priority for the set of VLANs {A, D, W} is 7
>>> . My priority for the set of VLANs {B, C, F, G, H} is 3
>>>
>>> c) If R1 becomes DRB for at least one of the VLANs on the cloud,
>>> then R1 announces (in R1's LSP)
>>> connectivity to pseudonode R1.59, together with
>>> a flag saying "I am DRB for this pseudonode". Also, in R1's LSP on
>>> behalf of pseudonode R1.59, R1 announces
>>> the ID of the root bridge on the primary spanning tree
>>> instance for that layer 2 cloud, along with the set of VLANs for
>>>       
> which
>   
>>> R1 is DRB on that cloud.
>>>
>>> d) If R2 thinks itself is DRB for VLAN A on a port with root bridge
>>>       
>> r11,
>>     
>>> and R2 sees an LSP for R1.59 that has the same root bridge and VLAN
>>>       
> A
>   
>>> listed as one of the VLANs, this indicates that VLAN 1 on that layer
>>> 2 cloud is partitioned. So one of R1 or R2 should stop forwarding
>>> data to/from that cloud for VLAN A. Use ID as a tie breaker, so
>>> if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding
>>> VLAN A
>>> traffic to and from the port that has root bridge r11.
>>> This is the behavior that will occur if VLAN 1 on that port is
>>> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2
>>> would
>>> have seen each other's Hellos and not both think they are DRB for
>>>       
> VLAN
>   
>> A
>>     
>>> (or
>>> any other VLAN).
>>>
>>> e) This proposal supports multiple DRBs on a cloud for load
>>>       
> splitting
>   
>>> based on VLANs, since the RBridges can have different priorities
>>> for different VLANs. It still requires only sending one Hello,
>>>       
> tagged
>   
>>> with VLAN 1. R2 should
>>> not panic if R2 notices that R1.59 has the same root bridge as on
>>> a port on which R2 is DRB, if R1.59's listed set of VLANs does not
>>> include any VLANs for which R2 is DRB on the link with
>>> that root bridge. If there is only partial overlap
>>> of VLAN IDs, say the overlap is VLANs {D, F, and H},
>>> then (the loser based on ID tie-breaker) will stop forwarding
>>>       
> traffic
>   
>>> to/from that link that is tagged with VLANs D, F, or H.
>>>
>>> f) If some VLAN, say VLAN C, is actually partitioned, then the
>>> result of this is that some VLAN C endnodes on that layer 2 cloud
>>> will be orphaned. We will choose NOT to solve that.
>>>
>>> g) To avoid temporary loops when VLAN 1 is partitioned, for each
>>> other RBridge RB1, RB2 sets an (internal) flag "OK to decapsulate
>>> from", provided that RB2 has an LSP from RB1 and all pseudonodes
>>> RB1 claims to be attached to. If RB2 receives a frame from ingress
>>> RB1 and this flag is NOT true, then RB2 will refuse to decapsulate
>>> the packet onto any ports. (regardless of VLAN and regardless of
>>>       
>> whether
>>     
>>> the frame is multidestination or unicast).
>>>
>>>
>>> Radia
>>>
>>> _______________________________________________
>>> 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
>
>   

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


Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l79MEBDi004716 for <[e-mail]>; Thu, 9 Aug 2007 15:14:12 -0700 (PDT)
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 09 Aug 2007 15:14:02 -0700
X-IronPort-AV: i="4.19,243,1183359600";  d="scan'208"; a="197484707:sNHT32918118966"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l79ME2nr007292;  Thu, 9 Aug 2007 15:14:02 -0700
Received: from [10.21.113.176] (sjc-vpn2-432.cisco.com [10.21.113.176]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l79ME1Vp029240; Thu, 9 Aug 2007 22:14:01 GMT
Message-ID: <[e-mail]>
Date: Thu, 09 Aug 2007 15:14:01 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.5 (X11/20070716)
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]><[e-mail]><[e-mail]><[e-mail]><[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14458; t=1186697642; x=1187561642; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Avoiding=20sending=20multiple=20IS-IS=20H ellos=20tagged=09withallthe=0A=20VLAN=20tags |Sender:=20; bh=fANKNJmCqIjZXr73B+tcCwTS9V3TN7uwSIMAp/ncR6I=; b=1m3Phv8tDz7vQ3cJj9szqNgxdqPxrt7BlMBrnWWDEW+Cyv5bzHqNy6jAHpBTBbwMaP3I2pqK w3stIyeAawJAMo4Hs6Fkmi8XyA1UBjUkf6HGQHVduqkzXSFqOyaAEz18;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged	withallthe VLAN tags
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, 09 Aug 2007 22:14:50 -0000
Status: RO
Content-Length: 14033

That is not what Silvano and I (or at least I) have been advocating. We 
send as many Hellos as active VLANs i.e. configured VLANs on the port. 
In 802.1Q switches (or at least the ones that I'm aware of), by default 
only VLAN 1 is enabled. You must configure additional VLANs.

Low end switches typically support fewer active VLANs. Many high-end 
switches also certify less than 4K VLANs. So, the low cost switch 
argument doesn't make sense to me.

I want correct behavior by default, even with misconfiguration. If 
someone wants to turn off that, an additional supported option is fine 
with me.

Dinesh
Eastlake III Donald-LDE008 wrote:
> Hi Silvano,
>
> Defaulting to having to send 4094 Hellos on every port seems like an
> excessive burden for low end and middle range Rbridges, for software
> implementations, unmanaged Rbridges, etc. On the other hand, in high end
> Rbridges, where this would not be much of a burden, you generally
> already have a lot of configuration going on. In fact, you don't have a
> problem that needs to be solved with these thousands of Hellos per port
> unless you have complex legacy configured 802.1Q bridged LANs in the
> picture, which I would think almost entirely occurs at the high end.
>
> While I certainly don't think the interests of high end Rbridges should
> be ignored, I also don't think other use scenarios should be ignored.
>
> Low end and mid-range Rbridges, where sending large numbers of Hellos
> would be the most burdensome, are the Rbridges most likely to be
> unmanaged or minimally managed, and in these cases the networks are
> likely to be fairly simple, without discontinuous legacy bridge VLANs.
> High end Rbridges, where sending large number of Hellos would be less
> burdensome, are the Rbridges very likely to be heavily managed and
> configured, so it does not seem to me that it should be that much of a
> problem for those network manages to configure them to do multiple
> Hellos. Also these high end Rbridges are more likely to be connected to
> complex discontinuous VLAN legacy bridged LANs where the multiple Hellos
> might actually be needed.
>
> Furthermore, the desired end state is that there aren't any legacy 802.1
> Q bridges in the network and it seems very wasteful, in that end state,
> to have to keep configuring Rbridges just to turn off multiple Hellos.
>
> Based on the above, my conclusion is that the zero configuration default
> should be to send a single Hello.
>
> As I've described before, I tend to think this Hello should by default
> be sent with maximum priority 7 but no VLAN ID (i.e., the VLAN ID field
> should be zero) and thus the technically correct description of the zero
> configuration default Rbridge Hello frames is that they are "priority
> tagged" with priority 7.
>
> Donald
>
> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Monday, August 06, 2007 1:08 PM
> To: Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> withallthe VLAN tags
>
> Donald,
>
> I am OK with this change as long as the default is to run one DRB
> election per VLAN, since this is the most robust scheme.
>
> -- Silvano
>
>   
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>>     
> On
>   
>> Behalf Of Eastlake III Donald-LDE008
>> Sent: Saturday, August 04, 2007 8:58 PM
>> To: [e-mail]
>> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
>> withallthe VLAN tags
>>
>> Silvano,
>>
>> I think that the provisions in the draft should be changed. At a
>> minimum, it seems useful when someone is doing a DRB election on one
>> VLAN intending to produce results that apply to multiple VLANs that
>>     
> the
>   
>> Hellos list the VLANs and be able to specify different priorities for
>> them so the elections are not all required to come out the same. And
>> some additional logic to handle partitions seems reasonable.
>>
>> Donald
>>
>> -----Original Message-----
>> From: Silvano Gai [mailto:[e-mail]]
>> Sent: Friday, August 03, 2007 5:59 PM
>> To: Eastlake III Donald-LDE008; [e-mail]
>> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
>> withall the VLAN tags
>>
>> Donald,
>>
>> I am OK with the text in -05, I thought that Radia wanted to change
>>     
> it.
>   
>> As far as I am not prevented from running one DRB per VLAN, I don't
>>     
> care
>   
>> too much which is the default.
>>
>> I don't want TRILL to mandate implementing a single DRB election and
>> additional tests that don't cover all the cases.
>>
>> Let's keep it simple. The current text is fine.
>>
>> -- Silvano
>>
>>     
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]
>>>       
>> On
>>     
>>> Behalf Of Eastlake III Donald-LDE008
>>> Sent: Friday, August 03, 2007 1:37 PM
>>> To: [e-mail]
>>> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
>>> withall the VLAN tags
>>>
>>> So why should the default be to tag Hellos with any VLAN ID? It
>>>       
> seems
>   
>> to
>>     
>>> me that there are two cases.
>>>
>>> If you know, via configuration or otherwise, that there are no
>>> intervening legacy bridges (doesn't particularly matter if its
>>> point-to-point between two Rbridges or a multiaccess link with
>>>       
> several
>   
>>> Rbridges as long as there are no bridges in the way), then all TRILL
>>> IS-IS and TRILL data frames should be untagged.
>>>
>>> If there are or might be intervening bridges, then I would think the
>>> default should be for Hellos to be priority tagged with priority 7.
>>>       
>> This
>>     
>>> means the tag has the null VLAN ID zero, that is, it does not
>>>       
> specify
>   
>>> any VLAN. If it turns out there actually aren't any bridges, this
>>>       
>> works
>>     
>>> fine. If the link is actually a bridged LAN, the requirement is then
>>> that the bridge ports that the Rbridges are connected to be
>>>       
> configured
>   
>>> to be the same VLAN, whatever that is, and that that VLAN be
>>>       
> connected
>   
>>> through that particular bridged LAN. If these bridge ports are
>>>       
> default
>   
>>> configured, this means the TRILL IS-IS Hello frames will acquire
>>>       
> VLAN
>   
>> 1
>>     
>>> tagging on bridged LAN ingress and have that tag stripped on bridged
>>>       
>> LAN
>>     
>>> egress and you would want VLAN 1 to be well connected through the
>>> bridged LAN. If, for some reason, VLAN 1 is inconvenient for the
>>>       
>> network
>>     
>>> operator to use in the particular bridged LAN in question, the
>>>       
> network
>   
>>> operator would be free to configure the bridge ports so that the
>>>       
> TRILL
>   
>>> frames get tagged with whatever VLAN is more convenient for them to
>>>       
>> use
>>     
>>> to provide connectivity. It could still be possible to configure
>>> Rbridges, on a per port basis, to tag outgoing TRILL frames with
>>>       
> some
>   
>>> specific VLAN ID if that is more convenient.
>>>
>>> I would like to point out that, while the proposal from Radia below
>>>       
> is
>   
>>> much more detailed and better worked out and while the related
>>> provisions in the current protocol draft are much more vague,
>>> nevertheless, the current protocol draft approximately corresponds
>>>       
> to
>   
>>> this proposal. In particular, due to previous concerns about
>>>       
> multiple
>   
>>> Hellos, among other things the protocol draft (-05) says:
>>>
>>> Section 2, Page 7:
>>>    If a link is actually a bridged LAN configured for VLANs, it is
>>>    possible that the link might be partitioned with respect to some
>>>    VLANs.  The default is to run a single DRB election on a link,
>>>       
> with
>   
>>>    the IS-IS Hellos either with no VLAN tag (the default), or with
>>>       
> the
>   
>>>    VLAN tag specifying the default VLAN for the link. If the RBridge
>>>       
>> is
>>     
>>>    configured to support a set of k VLANs on the link, then the
>>>       
>> RBridge
>>     
>>>    runs the IS-IS DRB election up to k times, each instance tagged
>>>       
>> with
>>     
>>>    one of the VLANs in that set of VLANs depending on its
>>>       
>> configuration.
>>     
>>>    Therefore there might be multiple DRBs on the link, but at most
>>>       
> one
>   
>>>    on that link per VLAN. By configuration, the DRB for some VLANs
>>>       
> may
>   
>>>    be set by copying the DRB status in the relevant RBridges from a
>>>    different VLAN rather than by election.
>>>
>>> So, arguably, the single Hello proposal below is approximately like
>>> using the current vague provisions in the protocol configured to
>>>       
> only
>   
>>> Hello on VLAN 1 and applying the result to all VLANs. The main
>>> difference is the proposal provides the per VLAN priorities in the
>>>       
>> Hello
>>     
>>> so you don't need this stuff about copying DRB status but can
>>> independently determine it for different VLANs without a per VLAN
>>> Hello...
>>>
>>> Donald
>>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]
>>>       
>> On
>>     
>>> Behalf Of Radia Perlman
>>> Sent: Thursday, August 02, 2007 8:23 PM
>>> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
>>> with allthe VLAN tags
>>>
>>> ...
>>>
>>> But at this point let's close this issue, which is basically to
>>>       
> adopt
>   
>>> Anoop's
>>> proposal of only sending IS-IS Hellos tagged with VLAN 1,
>>> plus my addendum to avoid temporary loops when VLAN 1 is partitioned
>>>       
>> by
>>     
>>> having RB2 refuse to decapsulate packets onto a port from ingress
>>> RBridge RB1 unless
>>> RB2 has received LSPs from RB1 and all pseudonodes that RB1 is DRB
>>>       
>> for.
>>     
>>> *************
>>> To review it:
>>>
>>> a) declare that bridges must be configured
>>> so that VLAN 1 (default VLAN) must not be
>>> partitioned on a layer 2 cloud. We will detect the misconfiguration
>>> if it occurs (see d)) so that we do not have loops, but if VLAN 1
>>> is partitioned parts of the layer 2 cloud might wind up orphaned
>>> from the rest of the campus.
>>>
>>> b) Send IS-IS Hellos tagged with VLAN 1, containing the following:
>>>
>>> . I am R1
>>> . I hear Hellos from {R2, R3, R7, R11}
>>> . If I am DRB, the pseudonode name will be R1.59
>>> . My priority for the set of VLANs {A, D, W} is 7
>>> . My priority for the set of VLANs {B, C, F, G, H} is 3
>>>
>>> c) If R1 becomes DRB for at least one of the VLANs on the cloud,
>>> then R1 announces (in R1's LSP)
>>> connectivity to pseudonode R1.59, together with
>>> a flag saying "I am DRB for this pseudonode". Also, in R1's LSP on
>>> behalf of pseudonode R1.59, R1 announces
>>> the ID of the root bridge on the primary spanning tree
>>> instance for that layer 2 cloud, along with the set of VLANs for
>>>       
> which
>   
>>> R1 is DRB on that cloud.
>>>
>>> d) If R2 thinks itself is DRB for VLAN A on a port with root bridge
>>>       
>> r11,
>>     
>>> and R2 sees an LSP for R1.59 that has the same root bridge and VLAN
>>>       
> A
>   
>>> listed as one of the VLANs, this indicates that VLAN 1 on that layer
>>> 2 cloud is partitioned. So one of R1 or R2 should stop forwarding
>>> data to/from that cloud for VLAN A. Use ID as a tie breaker, so
>>> if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding
>>> VLAN A
>>> traffic to and from the port that has root bridge r11.
>>> This is the behavior that will occur if VLAN 1 on that port is
>>> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2
>>> would
>>> have seen each other's Hellos and not both think they are DRB for
>>>       
> VLAN
>   
>> A
>>     
>>> (or
>>> any other VLAN).
>>>
>>> e) This proposal supports multiple DRBs on a cloud for load
>>>       
> splitting
>   
>>> based on VLANs, since the RBridges can have different priorities
>>> for different VLANs. It still requires only sending one Hello,
>>>       
> tagged
>   
>>> with VLAN 1. R2 should
>>> not panic if R2 notices that R1.59 has the same root bridge as on
>>> a port on which R2 is DRB, if R1.59's listed set of VLANs does not
>>> include any VLANs for which R2 is DRB on the link with
>>> that root bridge. If there is only partial overlap
>>> of VLAN IDs, say the overlap is VLANs {D, F, and H},
>>> then (the loser based on ID tie-breaker) will stop forwarding
>>>       
> traffic
>   
>>> to/from that link that is tagged with VLANs D, F, or H.
>>>
>>> f) If some VLAN, say VLAN C, is actually partitioned, then the
>>> result of this is that some VLAN C endnodes on that layer 2 cloud
>>> will be orphaned. We will choose NOT to solve that.
>>>
>>> g) To avoid temporary loops when VLAN 1 is partitioned, for each
>>> other RBridge RB1, RB2 sets an (internal) flag "OK to decapsulate
>>> from", provided that RB2 has an LSP from RB1 and all pseudonodes
>>> RB1 claims to be attached to. If RB2 receives a frame from ingress
>>> RB1 and this flag is NOT true, then RB2 will refuse to decapsulate
>>> the packet onto any ports. (regardless of VLAN and regardless of
>>>       
>> whether
>>     
>>> the frame is multidestination or unicast).
>>>
>>>
>>> Radia
>>>
>>> _______________________________________________
>>> 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
>
>   

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


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 l79KgCvK029197 for <[e-mail]>; Thu, 9 Aug 2007 13:42:13 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-9.tower-128.messagelabs.com!1186692132!16413142!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.10]
Received: (qmail 10644 invoked from network); 9 Aug 2007 20:42:12 -0000
Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-9.tower-128.messagelabs.com with SMTP; 9 Aug 2007 20:42:12 -0000
Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l79Kg3P0011674 for <[e-mail]>; Thu, 9 Aug 2007 13:42:03 -0700 (MST)
Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l79Kg2Ym012214 for <[e-mail]>; Thu, 9 Aug 2007 15:42:02 -0500 (CDT)
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 l79Kg0Jr012176 for <[e-mail]>; Thu, 9 Aug 2007 15:42:01 -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: Thu, 9 Aug 2007 16:41:59 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ISO 10589 available for free download
thread-index: AcfaxbvTXsTVtbS4SJ6dxmQwlzX6Jw==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Vontu: Pass
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 l79KgCvK029197
Subject: [rbridge] ISO 10589 available for free download
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, 09 Aug 2007 20:42:39 -0000
Status: RO
Content-Length: 411

Perhaps this is well known but I just noticed that the latest ISO/IEC
standard for IS-IS is available for free download from
http://webstore.ansi.org/FindStandards.aspx?SearchString=10589&SearchOpt
ion=1&PageNum=0

Thanks,
Donald

====================================================
 Donald E. Eastlake 3rd      [phone] (work)
 111 Locke Drive
 Marlborough, MA 01752 USA
 [e-mail]



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 l79JqM9h008413 for <[e-mail]>; Thu, 9 Aug 2007 12:52:22 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-119.messagelabs.com!1186689139!25652996!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 742 invoked from network); 9 Aug 2007 19:52:19 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-119.messagelabs.com with SMTP; 9 Aug 2007 19:52:19 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l79JqFBB005480 for <[e-mail]>; Thu, 9 Aug 2007 12:52:19 -0700 (MST)
Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l79JqEE1024171 for <[e-mail]>; Thu, 9 Aug 2007 14:52:15 -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 l79JqECi024160 for <[e-mail]>; Thu, 9 Aug 2007 14:52:14 -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: Thu, 9 Aug 2007 15:52:12 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags
thread-index: AcfVZps1BZNs/e+/T7aePZVYAElOwgAGmAGAACX5VLAAPTY/gABPmHwgAJoqbHA=
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: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Vontu: Pass
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 l79JqM9h008413
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags
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, 09 Aug 2007 19:53:12 -0000
Status: RO
Content-Length: 12080

Hi Silvano,

Defaulting to having to send 4094 Hellos on every port seems like an
excessive burden for low end and middle range Rbridges, for software
implementations, unmanaged Rbridges, etc. On the other hand, in high end
Rbridges, where this would not be much of a burden, you generally
already have a lot of configuration going on. In fact, you don't have a
problem that needs to be solved with these thousands of Hellos per port
unless you have complex legacy configured 802.1Q bridged LANs in the
picture, which I would think almost entirely occurs at the high end.

While I certainly don't think the interests of high end Rbridges should
be ignored, I also don't think other use scenarios should be ignored.

Low end and mid-range Rbridges, where sending large numbers of Hellos
would be the most burdensome, are the Rbridges most likely to be
unmanaged or minimally managed, and in these cases the networks are
likely to be fairly simple, without discontinuous legacy bridge VLANs.
High end Rbridges, where sending large number of Hellos would be less
burdensome, are the Rbridges very likely to be heavily managed and
configured, so it does not seem to me that it should be that much of a
problem for those network manages to configure them to do multiple
Hellos. Also these high end Rbridges are more likely to be connected to
complex discontinuous VLAN legacy bridged LANs where the multiple Hellos
might actually be needed.

Furthermore, the desired end state is that there aren't any legacy 802.1
Q bridges in the network and it seems very wasteful, in that end state,
to have to keep configuring Rbridges just to turn off multiple Hellos.

Based on the above, my conclusion is that the zero configuration default
should be to send a single Hello.

As I've described before, I tend to think this Hello should by default
be sent with maximum priority 7 but no VLAN ID (i.e., the VLAN ID field
should be zero) and thus the technically correct description of the zero
configuration default Rbridge Hello frames is that they are "priority
tagged" with priority 7.

Donald

-----Original Message-----
From: Silvano Gai [mailto:[e-mail]] 
Sent: Monday, August 06, 2007 1:08 PM
To: Eastlake III Donald-LDE008; [e-mail]
Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
withallthe VLAN tags

Donald,

I am OK with this change as long as the default is to run one DRB
election per VLAN, since this is the most robust scheme.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Saturday, August 04, 2007 8:58 PM
> To: [e-mail]
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> withallthe VLAN tags
> 
> Silvano,
> 
> I think that the provisions in the draft should be changed. At a
> minimum, it seems useful when someone is doing a DRB election on one
> VLAN intending to produce results that apply to multiple VLANs that
the
> Hellos list the VLANs and be able to specify different priorities for
> them so the elections are not all required to come out the same. And
> some additional logic to handle partitions seems reasonable.
> 
> Donald
> 
> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]]
> Sent: Friday, August 03, 2007 5:59 PM
> To: Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> withall the VLAN tags
> 
> Donald,
> 
> I am OK with the text in -05, I thought that Radia wanted to change
it.
> 
> As far as I am not prevented from running one DRB per VLAN, I don't
care
> too much which is the default.
> 
> I don't want TRILL to mandate implementing a single DRB election and
> additional tests that don't cover all the cases.
> 
> Let's keep it simple. The current text is fine.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eastlake III Donald-LDE008
> > Sent: Friday, August 03, 2007 1:37 PM
> > To: [e-mail]
> > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> > withall the VLAN tags
> >
> > So why should the default be to tag Hellos with any VLAN ID? It
seems
> to
> > me that there are two cases.
> >
> > If you know, via configuration or otherwise, that there are no
> > intervening legacy bridges (doesn't particularly matter if its
> > point-to-point between two Rbridges or a multiaccess link with
several
> > Rbridges as long as there are no bridges in the way), then all TRILL
> > IS-IS and TRILL data frames should be untagged.
> >
> > If there are or might be intervening bridges, then I would think the
> > default should be for Hellos to be priority tagged with priority 7.
> This
> > means the tag has the null VLAN ID zero, that is, it does not
specify
> > any VLAN. If it turns out there actually aren't any bridges, this
> works
> > fine. If the link is actually a bridged LAN, the requirement is then
> > that the bridge ports that the Rbridges are connected to be
configured
> > to be the same VLAN, whatever that is, and that that VLAN be
connected
> > through that particular bridged LAN. If these bridge ports are
default
> > configured, this means the TRILL IS-IS Hello frames will acquire
VLAN
> 1
> > tagging on bridged LAN ingress and have that tag stripped on bridged
> LAN
> > egress and you would want VLAN 1 to be well connected through the
> > bridged LAN. If, for some reason, VLAN 1 is inconvenient for the
> network
> > operator to use in the particular bridged LAN in question, the
network
> > operator would be free to configure the bridge ports so that the
TRILL
> > frames get tagged with whatever VLAN is more convenient for them to
> use
> > to provide connectivity. It could still be possible to configure
> > Rbridges, on a per port basis, to tag outgoing TRILL frames with
some
> > specific VLAN ID if that is more convenient.
> >
> > I would like to point out that, while the proposal from Radia below
is
> > much more detailed and better worked out and while the related
> > provisions in the current protocol draft are much more vague,
> > nevertheless, the current protocol draft approximately corresponds
to
> > this proposal. In particular, due to previous concerns about
multiple
> > Hellos, among other things the protocol draft (-05) says:
> >
> > Section 2, Page 7:
> >    If a link is actually a bridged LAN configured for VLANs, it is
> >    possible that the link might be partitioned with respect to some
> >    VLANs.  The default is to run a single DRB election on a link,
with
> >    the IS-IS Hellos either with no VLAN tag (the default), or with
the
> >    VLAN tag specifying the default VLAN for the link. If the RBridge
> is
> >    configured to support a set of k VLANs on the link, then the
> RBridge
> >    runs the IS-IS DRB election up to k times, each instance tagged
> with
> >    one of the VLANs in that set of VLANs depending on its
> configuration.
> >    Therefore there might be multiple DRBs on the link, but at most
one
> >    on that link per VLAN. By configuration, the DRB for some VLANs
may
> >    be set by copying the DRB status in the relevant RBridges from a
> >    different VLAN rather than by election.
> >
> > So, arguably, the single Hello proposal below is approximately like
> > using the current vague provisions in the protocol configured to
only
> > Hello on VLAN 1 and applying the result to all VLANs. The main
> > difference is the proposal provides the per VLAN priorities in the
> Hello
> > so you don't need this stuff about copying DRB status but can
> > independently determine it for different VLANs without a per VLAN
> > Hello...
> >
> > Donald
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Radia Perlman
> > Sent: Thursday, August 02, 2007 8:23 PM
> > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> > with allthe VLAN tags
> >
> > ...
> >
> > But at this point let's close this issue, which is basically to
adopt
> > Anoop's
> > proposal of only sending IS-IS Hellos tagged with VLAN 1,
> > plus my addendum to avoid temporary loops when VLAN 1 is partitioned
> by
> > having RB2 refuse to decapsulate packets onto a port from ingress
> > RBridge RB1 unless
> > RB2 has received LSPs from RB1 and all pseudonodes that RB1 is DRB
> for.
> >
> > *************
> > To review it:
> >
> > a) declare that bridges must be configured
> > so that VLAN 1 (default VLAN) must not be
> > partitioned on a layer 2 cloud. We will detect the misconfiguration
> > if it occurs (see d)) so that we do not have loops, but if VLAN 1
> > is partitioned parts of the layer 2 cloud might wind up orphaned
> > from the rest of the campus.
> >
> > b) Send IS-IS Hellos tagged with VLAN 1, containing the following:
> >
> > . I am R1
> > . I hear Hellos from {R2, R3, R7, R11}
> > . If I am DRB, the pseudonode name will be R1.59
> > . My priority for the set of VLANs {A, D, W} is 7
> > . My priority for the set of VLANs {B, C, F, G, H} is 3
> >
> > c) If R1 becomes DRB for at least one of the VLANs on the cloud,
> > then R1 announces (in R1's LSP)
> > connectivity to pseudonode R1.59, together with
> > a flag saying "I am DRB for this pseudonode". Also, in R1's LSP on
> > behalf of pseudonode R1.59, R1 announces
> > the ID of the root bridge on the primary spanning tree
> > instance for that layer 2 cloud, along with the set of VLANs for
which
> > R1 is DRB on that cloud.
> >
> > d) If R2 thinks itself is DRB for VLAN A on a port with root bridge
> r11,
> > and R2 sees an LSP for R1.59 that has the same root bridge and VLAN
A
> > listed as one of the VLANs, this indicates that VLAN 1 on that layer
> > 2 cloud is partitioned. So one of R1 or R2 should stop forwarding
> > data to/from that cloud for VLAN A. Use ID as a tie breaker, so
> > if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding
> > VLAN A
> > traffic to and from the port that has root bridge r11.
> > This is the behavior that will occur if VLAN 1 on that port is
> > actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2
> > would
> > have seen each other's Hellos and not both think they are DRB for
VLAN
> A
> > (or
> > any other VLAN).
> >
> > e) This proposal supports multiple DRBs on a cloud for load
splitting
> > based on VLANs, since the RBridges can have different priorities
> > for different VLANs. It still requires only sending one Hello,
tagged
> > with VLAN 1. R2 should
> > not panic if R2 notices that R1.59 has the same root bridge as on
> > a port on which R2 is DRB, if R1.59's listed set of VLANs does not
> > include any VLANs for which R2 is DRB on the link with
> > that root bridge. If there is only partial overlap
> > of VLAN IDs, say the overlap is VLANs {D, F, and H},
> > then (the loser based on ID tie-breaker) will stop forwarding
traffic
> > to/from that link that is tagged with VLANs D, F, or H.
> >
> > f) If some VLAN, say VLAN C, is actually partitioned, then the
> > result of this is that some VLAN C endnodes on that layer 2 cloud
> > will be orphaned. We will choose NOT to solve that.
> >
> > g) To avoid temporary loops when VLAN 1 is partitioned, for each
> > other RBridge RB1, RB2 sets an (internal) flag "OK to decapsulate
> > from", provided that RB2 has an LSP from RB1 and all pseudonodes
> > RB1 claims to be attached to. If RB2 receives a frame from ingress
> > RB1 and this flag is NOT true, then RB2 will refuse to decapsulate
> > the packet onto any ports. (regardless of VLAN and regardless of
> whether
> > the frame is multidestination or unicast).
> >
> >
> > Radia
> >
> > _______________________________________________
> > 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 mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l76HlejO014260 for <[e-mail]>; Mon, 6 Aug 2007 10:47:40 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 06 Aug 2007 10:47:25 -0700 (PDT)
Received: from [129.150.16.134] ([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, 06 Aug 2007 10:47:25 -0700 (PDT)
Date: Mon, 06 Aug 2007 10:48:23 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Dinesh G Dutt <[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 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all	the VLAN tags
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, 06 Aug 2007 17:48:22 -0000
Status: RO
Content-Length: 11781

There was also the rule I threw in later about RB1 not decapsulating 
anything from
RBridge RB2 unless RB1 has an LSP from RB2, and all LSPs from all the 
pseudonodes
that RB2 claims (in RB2's LSP) to be DRB for.

That way RB1, when in doubt (i.e., doesn't yet have the relevant LSPs) 
will not
forward onto a port.

If RB1 *does* have RB2's LSP (which tells RB1 which pseudonodes RB2 is 
DRB for),
and has all those pseudonode LSPs (so it can check to see what the root 
RBridge is),
then RB1 can safely forward onto a port P if the root bridge for port P 
is *not* included
in any of the pseudonodes that RB2 is DRB for.

Radia




Dinesh G Dutt wrote:
> Radia,
>
> I don't believe what you suggested below works including what you 
> detailed later. The problem is that when Rb1 and Rb2 both think that 
> they're DRBs on VLAN A but cannot communicate oN VLAN 1, they may have 
> synchronized their LSP databases with their neighbors, but it doesn't 
> fix the problem because the information of the other DRB hasn't yet 
> reached the neighbor.
>
> I think at this point, I'm leaning towards saying that the default 
> SHOULD be to support per-VLAN DRB election, but provide the option to 
> do DRB only on a single VLAN, VLAN 1. Allowing which VLAN to carry out 
> the DRB on is another potential misconfiguration and so I'm worried 
> about this knob, though I won't protest providing it.
>
> Doing it this way solves Anoop's problem for the cases he's worried 
> about, but makes the network robust by default.
>
> Dinesh
> Radia Perlman wrote:
>> Yes, Dinesh, in your example if there are temporarily k RBridges on 
>> the same layer 2 cloud
>> that all think they are DRB, you might multiply by k, each packet 
>> going off the cloud.
>>
>> However, this is not as disastrous as a loop.
>>
>> We can avoid that though by saying that you shouldn't start 
>> encapsulating or decapsulating
>> data off the link until you've synchronized LSP datases with each of 
>> your RBridge neighbors.
>> IS-IS exchanges LSP database information (a "complete sequence 
>> numbers packet") when
>> a link comes up. I think we should throw that rule in as well.
>>
>> Radia
>>
>>
>>
>>
>> Dinesh G Dutt wrote:
>>> Radia,
>>>
>>> I thought about this solution but think that it still doesn't fix 
>>> the problem of duplicates. If both R1 and R2 think that they're DRB 
>>> for VLAN A, when they both receive a frame on VLAN A from  the 
>>> 802.1D cloud (unknown unicast for example), they both think that 
>>> they can forward it onto the TRILL network. The destination host 
>>> will now receive duplicate frames till one of them stops being DRB.
>>>
>>> Am I mistaken ?
>>>
>>> Dinesh
>>> Radia Perlman wrote:
>>>  
>>>> Dinesh,
>>>>
>>>> I think you are right that there can be a temporary loop due to a 
>>>> partitioned VLAN 1.
>>>> And I think we can make it sufficiently unlikely to occur with a 
>>>> suggestion I'll make
>>>> after I explain the problem.
>>>>
>>>> The temporary loop would be if R1 and R2, on the same layer 2 
>>>> cloud, have
>>>> connectivity through VLAN A but not VLAN 1. So there would be two 
>>>> DRBs, on
>>>> both VLAN A and VLAN 1. There would be two pseudonodes, say R1.79 
>>>> and R2.62,
>>>> and both would claim to be connected to both VLAN A and VLAN 1, and 
>>>> both
>>>> would claim the same root bridge, say 5134.
>>>>
>>>> A multicast tagged with VLAN 1 would not be too much of a problem 
>>>> because anything
>>>> R1 decapsulates onto that VLAN-1-partitioned cloud would not make 
>>>> it through
>>>> the partitioned cloud to R2. But since we are not running the DRB 
>>>> election tagged
>>>> with VLAN A, R1 and R2 do not realize that they can talk via VLAN A.
>>>>
>>>> Therefore, a VLAN A-tagged packet would get picked up by both R1 
>>>> and R2,
>>>> and both would assume they are DRB.
>>>> Also, if R1 receives a (inner header) VLAN-A tagged frame
>>>> from the campus, R1 will decapsulate it onto the layer 2 cloud as a 
>>>> VLAN-A
>>>> tagged packet, and R2 will see it
>>>> and re-encapsulate it onto the campus, and R1 would see it again 
>>>> and decapsulate it, etc.
>>>>
>>>> This loop will eventually be fixed when R1 sees the LSP from 
>>>> pseudonode  R2.62 indicating
>>>> that the root bridge is 5134, since R1 will also think that the 
>>>> cloud that R1 is DRB for has
>>>> root bridge 5134.
>>>>
>>>> So here's a possible fix:
>>>>
>>>> R1 does not decapsulate a multidestination packet with ingress 
>>>> RBridge R2 unless R1
>>>> has an LSP from R2, and has LSPs from all pseudonodes that R2 
>>>> claims (in R2's
>>>> LSP) to be DRB for. Note that I'm suggesting adding another flag in 
>>>> the neighbor
>>>> list in R2's LSP saying "not only am I attached to this pseudonode, 
>>>> but I am
>>>> DRB for it".
>>>>
>>>> If R1 has all the pseudonode LSPs for which R2 is DRB, R1 can see 
>>>> if the root bridge
>>>> listed is the same as the one for the link on which R2 would like 
>>>> to decapsulate, and if it is,
>>>> then don't decapsulate.
>>>>
>>>> We were already saying that if R1 notices that R2.79 has the same 
>>>> root bridge as
>>>> a link R1 wants to be DRB for that one of R1 or R2 would lose, 
>>>> based on a tie-breaker
>>>> based on ID, and stop forwarding traffic to/from the link. What I'm 
>>>> suggesting is that
>>>> you also don't forward multidestination traffic to/from a link if 
>>>> you don't yet have all
>>>> the associated LSP information from the ingress RBridge that can 
>>>> assure you there
>>>> isn't a common root bridge.
>>>>
>>>> Radia
>>>>
>>>>
>>>>
>>>>
>>>> Dinesh G Dutt wrote:
>>>>   
>>>>> OK, based on emails from James Carlson and Radia, I went back and 
>>>>> thought about my reasons for objecting to the suggested proposal. 
>>>>> I also spoke to some field engineers to validate my understanding 
>>>>> of what I thought the issues were.
>>>>>
>>>>> There are two issues that we're dealing with here:
>>>>> - Simplifying DRB election to conduct it only on VLAN 1
>>>>> - Merging partitioned VLANs.
>>>>>
>>>>> I'd like to separate the two issues. Let me discuss only the first 
>>>>> issue, the simplified DRB election in this email. I'll send out a 
>>>>> separate email on the other issue.
>>>>>
>>>>> Assuming VLAN 1 exists everywhere is an acceptable alternative. I 
>>>>> was informed that even with STP, customers enable VLAN 1 and allow 
>>>>> only control traffic on it and not data traffic. If we have VLAN 1 
>>>>> present as a common configuration, then running DRB only on VLAN 1 
>>>>> and following Radia's proposal (or fixing it to work) seems 
>>>>> acceptable, except for one caveat.
>>>>>
>>>>> However, in the event of a misconfiguration and VLAN 1 not being 
>>>>> present, while the scheme proposed partitions the network and 
>>>>> prevents loops, it seems to me that there is a period during which 
>>>>> temporary loops can happen and duplicate frames are delivered by 
>>>>> two DRBs. This seems unacceptable to me from a customer point of 
>>>>> view. If we can fix this temporary loop (or someone can explain to 
>>>>> me why there are no temporary loops), I'd be willing to support 
>>>>> this proposal.
>>>>>
>>>>> BTW, GVTP/MMRP or equivalent is very much not enabled in >80-90% 
>>>>> of customer networks and so we cannot assume or mandate their 
>>>>> being there.
>>>>>
>>>>> Dinesh
>>>>> Radia Perlman wrote:
>>>>>     
>>>>>> I had a conversation with Anoop, and he is (quite understandably)
>>>>>> uneasy about sending IS-IS Hellos tagged with every VLAN. So he
>>>>>> made the following suggestion, which I think makes sense.
>>>>>>
>>>>>> a) declare that bridges must be configured
>>>>>> so that VLAN 1 (default VLAN) must not be
>>>>>> partitioned on a layer 2 cloud. We will detect the misconfiguration
>>>>>> if it occurs (see d)) so that we at least do not have loops, but 
>>>>>> TRILL will not
>>>>>> stand on its head to support what will be declared a gross 
>>>>>> misconfiguration.
>>>>>>
>>>>>> b) Run the IS-IS election tagged with VLAN 1. Each RBridge has
>>>>>> the following information in its IS-IS Hello:
>>>>>>
>>>>>> . I am R1
>>>>>> . I hear Hellos from {R2, R3, R7, R11}
>>>>>> . If I am DRB, the pseudonode name will be R1.59
>>>>>> . My priority for the set of VLANs {A, D, W} is 7
>>>>>> . My priority for the set of VLANs {B, C, F, G, H} is 3
>>>>>>
>>>>>> c) If R1 becomes DRB for at least one of the VLANs on the cloud,
>>>>>> then R1 announces, in R1's LSP on behalf of pseudonode R1.59,
>>>>>> the ID of the root bridge on the primary spanning tree
>>>>>> instance for that layer 2 cloud, along with the set of VLANs for 
>>>>>> which
>>>>>> R1 is DRB on that cloud.
>>>>>>
>>>>>> Note: The current draft spec isn't clear what information R1 
>>>>>> reports in the pseudonode
>>>>>> LSP and what it reports in its own LSP.
>>>>>> I'm suggesting reporting the bridge ID and
>>>>>> set of VLANs in the pseudonode LSP.
>>>>>>
>>>>>> d) If R2 thinks itself is DRB for VLAN A on a port with root 
>>>>>> bridge r11,
>>>>>> and R2 sees an LSP for R1.59 that has the same root bridge and 
>>>>>> VLAN A
>>>>>> listed as one of the VLANs, this indicates that VLAN 1 on that layer
>>>>>> 2 cloud is partitioned. So one of R1 or R2 should stop forwarding
>>>>>> data to/from that cloud for VLAN A. Use ID as a tie breaker, so
>>>>>> if R2's IS-IS system ID is lower than R1's, then R2 stops 
>>>>>> forwarding VLAN A
>>>>>> traffic to and from the port that has root bridge r11.
>>>>>> This is the behavior that will occur if VLAN 1 on that port is
>>>>>> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and 
>>>>>> R2 would
>>>>>> have seen each other's Hellos and not both think they are DRB for 
>>>>>> VLAN A (or
>>>>>> any other VLAN).
>>>>>>
>>>>>> e) This proposal supports multiple DRBs on a cloud for load 
>>>>>> splitting
>>>>>> based on VLANs, since the RBridges can have different priorities
>>>>>> for different VLANs. It still requires only sending one Hello, 
>>>>>> tagged
>>>>>> with VLAN 1. R2 should
>>>>>> not panic if R2 notices that R1.59 has the same root bridge as on
>>>>>> a port on which R2 is DRB, if R1.59's listed set of VLANs does not
>>>>>> include any VLANs for which R2 is DRB on the link with
>>>>>> that root bridge. If there is only partial overlap
>>>>>> of VLAN IDs, say the overlap is VLANs {D, F, and H},
>>>>>> then (the loser based on ID tie-breaker) will stop forwarding 
>>>>>> traffic
>>>>>> to/from that link that is tagged with VLANs D, F, or H.
>>>>>>
>>>>>> f) If some VLAN, say VLAN C, is actually partitioned, then the
>>>>>> result of this is that some VLAN C endnodes on that layer 2 cloud
>>>>>> will be orphaned. We will choose NOT to solve that.
>>>>>>
>>>>>>
>>>>>> The result of this proposal is that
>>>>>> RBridges will only need to send IS-IS Hellos tagged
>>>>>> with VLAN 1, and the only thing it does NOT solve (over
>>>>>> the current proposal of sending Hellos with every possible VLAN 
>>>>>> tag on
>>>>>> each port) is that sometimes endnodes might get orphaned if you have
>>>>>> a partitioned VLAN.
>>>>>>
>>>>>>
>>>>>> We *could* in that case, if someone *actually wanted* to have VLAN A
>>>>>> partitioned on that cloud, configure the RBridges on that layer 2
>>>>>> cloud to explicitly run a different election
>>>>>> for VLAN A (and note in the pseudonode LSP that VLAN A had
>>>>>> an explicit election tagged with VLAN A so that if there were
>>>>>> two DRBs they wouldn't panic). But I'd prefer not solving this 
>>>>>> case and
>>>>>> keeping it simpler (and safer).
>>>>>>
>>>>>> Radia
>>>>>> _______________________________________________
>>>>>> 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 l76HYiVL010331 for <[e-mail]>; Mon, 6 Aug 2007 10:34:45 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-6.tower-128.messagelabs.com!1186421683!23659421!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 23105 invoked from network); 6 Aug 2007 17:34:43 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 6 Aug 2007 17:34:43 -0000
Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l76HYgoS024156 for <[e-mail]>; Mon, 6 Aug 2007 10:34:42 -0700 (MST)
Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l76HYfwZ021190 for <[e-mail]>; Mon, 6 Aug 2007 12:34: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 l76HYevM021172 for <[e-mail]>; Mon, 6 Aug 2007 12:34: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: Mon, 6 Aug 2007 13:34:39 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged	withallthe VLAN tags
thread-index: AcfYS6NGIBEPMpEKTOuUf79aM+n5nAAAez6Q
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]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Dale W. Carder" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
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 l76HYiVL010331
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged	withallthe VLAN tags
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, 06 Aug 2007 17:35:08 -0000
Status: RO
Content-Length: 2905

That was exactly my suggestion. The right way to look at this is to say
that

(1) the Hello is, by default, send to "VLAN 1" with priority 7
(2) the default port VLAN ID for Rbridge ports is 1
(3) the egress processing in the general case is to suppress the VLAN ID
if it matches the port VLAN ID at the egress port

Thus, by default, the VLAN ID will be suppressed in the outer VLAN tag
on TRILL IS-IS frames and they are sent priority tagged with priority 7,
that is, sent with a VLAN tag that says priority 7 and has the VLAN ID
field set to zero. (It says "general case" above because, for example,
if you know it is a point-to-point link between Rbridges, there is no
reason to have any outer VLAN tag.)

A TRILL data frame being sent on VLAN 1 through an Rbridge port with
default port configuration would also have the same thing happen. So it
would end up being send priority tagged with whatever its priority was
except that if the priority was the default value zero, the VLAN tag
could be omitted entirely.

Thanks,
Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Dale W. Carder
Sent: Monday, August 06, 2007 11:49 AM
To: Anoop Ghanwani
Cc: [e-mail]; Radia Perlman
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
withallthe VLAN tags


On Aug 3, 2007, at 12:07 PM, Anoop Ghanwani wrote:
>> Large core switches running rapid-STP can send a BPDU every 2
>> seconds across around 10,000 instances (m vlans * n ports) today.
>> These switches are also usually sending out (LLDP or CDP) and
>> UDLD frames on every port, too.
>
> This is completely wrong!  RSTP is not VLAN aware.
> MSTP is, but it is limited to 64 instances.  This
> is quite a different number than the 10000 that you
> quote.

I was referring in this case to a proprietary implementation,
but my point is that it seems possible that it can be done.

I am not saying that sending hellos on every vlan is a great
idea, but I just wanted to show that I believe it is feasible
based on deployments I have seen that are running protocols
that do send hellos or similar on every vlan today.

>> Perhaps a compromise would be to use vlan 1 as the default, but a
>> TRILL implementation MAY allow this to be configurable by the
>> administrator.
>
> I agree.  As also pointed out by Arien Vijn, we could
> select any VLAN as the "default RBridge VLAN", but we do
> need one.

I don't think there is any easy solution.

Could the default be to use vlan 1 *untagged*?  This would
allow an rbridge to be plugged in almost anywhere.  If a
network operator wanted to change the vlan number she could
do it on her existing bridged lan.

Is there a more formal name for the "default RBridge VLAN"?

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



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l76H8XEM001385 for <[e-mail]>; Mon, 6 Aug 2007 10:08:33 -0700 (PDT)
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, 6 Aug 2007 10:07:45 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags
Thread-Index: AcfVZps1BZNs/e+/T7aePZVYAElOwgAGmAGAACX5VLAAPTY/gABPmHwg
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]>
From: "Silvano Gai" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l76H8XEM001385
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags
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, 06 Aug 2007 17:09:08 -0000
Status: RO
Content-Length: 9741

Donald,

I am OK with this change as long as the default is to run one DRB
election per VLAN, since this is the most robust scheme.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Saturday, August 04, 2007 8:58 PM
> To: [e-mail]
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> withallthe VLAN tags
> 
> Silvano,
> 
> I think that the provisions in the draft should be changed. At a
> minimum, it seems useful when someone is doing a DRB election on one
> VLAN intending to produce results that apply to multiple VLANs that
the
> Hellos list the VLANs and be able to specify different priorities for
> them so the elections are not all required to come out the same. And
> some additional logic to handle partitions seems reasonable.
> 
> Donald
> 
> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]]
> Sent: Friday, August 03, 2007 5:59 PM
> To: Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> withall the VLAN tags
> 
> Donald,
> 
> I am OK with the text in -05, I thought that Radia wanted to change
it.
> 
> As far as I am not prevented from running one DRB per VLAN, I don't
care
> too much which is the default.
> 
> I don't want TRILL to mandate implementing a single DRB election and
> additional tests that don't cover all the cases.
> 
> Let's keep it simple. The current text is fine.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eastlake III Donald-LDE008
> > Sent: Friday, August 03, 2007 1:37 PM
> > To: [e-mail]
> > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> > withall the VLAN tags
> >
> > So why should the default be to tag Hellos with any VLAN ID? It
seems
> to
> > me that there are two cases.
> >
> > If you know, via configuration or otherwise, that there are no
> > intervening legacy bridges (doesn't particularly matter if its
> > point-to-point between two Rbridges or a multiaccess link with
several
> > Rbridges as long as there are no bridges in the way), then all TRILL
> > IS-IS and TRILL data frames should be untagged.
> >
> > If there are or might be intervening bridges, then I would think the
> > default should be for Hellos to be priority tagged with priority 7.
> This
> > means the tag has the null VLAN ID zero, that is, it does not
specify
> > any VLAN. If it turns out there actually aren't any bridges, this
> works
> > fine. If the link is actually a bridged LAN, the requirement is then
> > that the bridge ports that the Rbridges are connected to be
configured
> > to be the same VLAN, whatever that is, and that that VLAN be
connected
> > through that particular bridged LAN. If these bridge ports are
default
> > configured, this means the TRILL IS-IS Hello frames will acquire
VLAN
> 1
> > tagging on bridged LAN ingress and have that tag stripped on bridged
> LAN
> > egress and you would want VLAN 1 to be well connected through the
> > bridged LAN. If, for some reason, VLAN 1 is inconvenient for the
> network
> > operator to use in the particular bridged LAN in question, the
network
> > operator would be free to configure the bridge ports so that the
TRILL
> > frames get tagged with whatever VLAN is more convenient for them to
> use
> > to provide connectivity. It could still be possible to configure
> > Rbridges, on a per port basis, to tag outgoing TRILL frames with
some
> > specific VLAN ID if that is more convenient.
> >
> > I would like to point out that, while the proposal from Radia below
is
> > much more detailed and better worked out and while the related
> > provisions in the current protocol draft are much more vague,
> > nevertheless, the current protocol draft approximately corresponds
to
> > this proposal. In particular, due to previous concerns about
multiple
> > Hellos, among other things the protocol draft (-05) says:
> >
> > Section 2, Page 7:
> >    If a link is actually a bridged LAN configured for VLANs, it is
> >    possible that the link might be partitioned with respect to some
> >    VLANs.  The default is to run a single DRB election on a link,
with
> >    the IS-IS Hellos either with no VLAN tag (the default), or with
the
> >    VLAN tag specifying the default VLAN for the link. If the RBridge
> is
> >    configured to support a set of k VLANs on the link, then the
> RBridge
> >    runs the IS-IS DRB election up to k times, each instance tagged
> with
> >    one of the VLANs in that set of VLANs depending on its
> configuration.
> >    Therefore there might be multiple DRBs on the link, but at most
one
> >    on that link per VLAN. By configuration, the DRB for some VLANs
may
> >    be set by copying the DRB status in the relevant RBridges from a
> >    different VLAN rather than by election.
> >
> > So, arguably, the single Hello proposal below is approximately like
> > using the current vague provisions in the protocol configured to
only
> > Hello on VLAN 1 and applying the result to all VLANs. The main
> > difference is the proposal provides the per VLAN priorities in the
> Hello
> > so you don't need this stuff about copying DRB status but can
> > independently determine it for different VLANs without a per VLAN
> > Hello...
> >
> > Donald
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Radia Perlman
> > Sent: Thursday, August 02, 2007 8:23 PM
> > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> > with allthe VLAN tags
> >
> > ...
> >
> > But at this point let's close this issue, which is basically to
adopt
> > Anoop's
> > proposal of only sending IS-IS Hellos tagged with VLAN 1,
> > plus my addendum to avoid temporary loops when VLAN 1 is partitioned
> by
> > having RB2 refuse to decapsulate packets onto a port from ingress
> > RBridge RB1 unless
> > RB2 has received LSPs from RB1 and all pseudonodes that RB1 is DRB
> for.
> >
> > *************
> > To review it:
> >
> > a) declare that bridges must be configured
> > so that VLAN 1 (default VLAN) must not be
> > partitioned on a layer 2 cloud. We will detect the misconfiguration
> > if it occurs (see d)) so that we do not have loops, but if VLAN 1
> > is partitioned parts of the layer 2 cloud might wind up orphaned
> > from the rest of the campus.
> >
> > b) Send IS-IS Hellos tagged with VLAN 1, containing the following:
> >
> > . I am R1
> > . I hear Hellos from {R2, R3, R7, R11}
> > . If I am DRB, the pseudonode name will be R1.59
> > . My priority for the set of VLANs {A, D, W} is 7
> > . My priority for the set of VLANs {B, C, F, G, H} is 3
> >
> > c) If R1 becomes DRB for at least one of the VLANs on the cloud,
> > then R1 announces (in R1's LSP)
> > connectivity to pseudonode R1.59, together with
> > a flag saying "I am DRB for this pseudonode". Also, in R1's LSP on
> > behalf of pseudonode R1.59, R1 announces
> > the ID of the root bridge on the primary spanning tree
> > instance for that layer 2 cloud, along with the set of VLANs for
which
> > R1 is DRB on that cloud.
> >
> > d) If R2 thinks itself is DRB for VLAN A on a port with root bridge
> r11,
> > and R2 sees an LSP for R1.59 that has the same root bridge and VLAN
A
> > listed as one of the VLANs, this indicates that VLAN 1 on that layer
> > 2 cloud is partitioned. So one of R1 or R2 should stop forwarding
> > data to/from that cloud for VLAN A. Use ID as a tie breaker, so
> > if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding
> > VLAN A
> > traffic to and from the port that has root bridge r11.
> > This is the behavior that will occur if VLAN 1 on that port is
> > actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2
> > would
> > have seen each other's Hellos and not both think they are DRB for
VLAN
> A
> > (or
> > any other VLAN).
> >
> > e) This proposal supports multiple DRBs on a cloud for load
splitting
> > based on VLANs, since the RBridges can have different priorities
> > for different VLANs. It still requires only sending one Hello,
tagged
> > with VLAN 1. R2 should
> > not panic if R2 notices that R1.59 has the same root bridge as on
> > a port on which R2 is DRB, if R1.59's listed set of VLANs does not
> > include any VLANs for which R2 is DRB on the link with
> > that root bridge. If there is only partial overlap
> > of VLAN IDs, say the overlap is VLANs {D, F, and H},
> > then (the loser based on ID tie-breaker) will stop forwarding
traffic
> > to/from that link that is tagged with VLANs D, F, or H.
> >
> > f) If some VLAN, say VLAN C, is actually partitioned, then the
> > result of this is that some VLAN C endnodes on that layer 2 cloud
> > will be orphaned. We will choose NOT to solve that.
> >
> > g) To avoid temporary loops when VLAN 1 is partitioned, for each
> > other RBridge RB1, RB2 sets an (internal) flag "OK to decapsulate
> > from", provided that RB2 has an LSP from RB1 and all pseudonodes
> > RB1 claims to be attached to. If RB2 receives a frame from ingress
> > RB1 and this flag is NOT true, then RB2 will refuse to decapsulate
> > the packet onto any ports. (regardless of VLAN and regardless of
> whether
> > the frame is multidestination or unicast).
> >
> >
> > Radia
> >
> > _______________________________________________
> > 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 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 l76H3tML029975 for <[e-mail]>; Mon, 6 Aug 2007 10:03:56 -0700 (PDT)
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 06 Aug 2007 10:03:31 -0700
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CACPxtkarR7MV/2dsb2JhbAA
X-IronPort-AV: i="4.19,225,1183359600";  d="scan'208"; a="510692089:sNHT8505874330"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l76H3Ubk021101;  Mon, 6 Aug 2007 10:03:30 -0700
Received: from [10.21.113.79] (sjc-vpn2-335.cisco.com [10.21.113.79]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l76H3TiF008111; Mon, 6 Aug 2007 17:03:30 GMT
Message-ID: <[e-mail]>
Date: Mon, 06 Aug 2007 10:03:29 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.5 (X11/20070716)
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]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11225; t=1186419810; x=1187283810; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Avoiding=20sending=20multiple=20IS-IS=20H ellos=20tagged=20with=0A=20all=09the=20VLAN=20tags |Sender:=20; bh=CY+RBsbkO/wQCEEmMHZI88VZiCtnlf8ioupMDRhor5M=; b=aJG15eTCeJKXfTjqIHfa1JsGf3bCzzxoDkPZUbY5K+3MerEmxgMjCI/xzU5bosbC+HN+Qp+X 8CXEXLANHcysxQyUR/GlVvNSzgi59+VPG28G0WNTZoswdcBwVlyhW9pnDBntee5jQkS6B8TPb8 wQbYsOlEZGfWkQJGHhZW00FbM=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all	the VLAN tags
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, 06 Aug 2007 17:04:12 -0000
Status: RO
Content-Length: 10956

Radia,

I don't believe what you suggested below works including what you 
detailed later. The problem is that when Rb1 and Rb2 both think that 
they're DRBs on VLAN A but cannot communicate oN VLAN 1, they may have 
synchronized their LSP databases with their neighbors, but it doesn't 
fix the problem because the information of the other DRB hasn't yet 
reached the neighbor.

I think at this point, I'm leaning towards saying that the default 
SHOULD be to support per-VLAN DRB election, but provide the option to do 
DRB only on a single VLAN, VLAN 1. Allowing which VLAN to carry out the 
DRB on is another potential misconfiguration and so I'm worried about 
this knob, though I won't protest providing it.

Doing it this way solves Anoop's problem for the cases he's worried 
about, but makes the network robust by default.

Dinesh
Radia Perlman wrote:
> Yes, Dinesh, in your example if there are temporarily k RBridges on 
> the same layer 2 cloud
> that all think they are DRB, you might multiply by k, each packet 
> going off the cloud.
>
> However, this is not as disastrous as a loop.
>
> We can avoid that though by saying that you shouldn't start 
> encapsulating or decapsulating
> data off the link until you've synchronized LSP datases with each of 
> your RBridge neighbors.
> IS-IS exchanges LSP database information (a "complete sequence numbers 
> packet") when
> a link comes up. I think we should throw that rule in as well.
>
> Radia
>
>
>
>
> Dinesh G Dutt wrote:
>> Radia,
>>
>> I thought about this solution but think that it still doesn't fix the 
>> problem of duplicates. If both R1 and R2 think that they're DRB for 
>> VLAN A, when they both receive a frame on VLAN A from  the 802.1D 
>> cloud (unknown unicast for example), they both think that they can 
>> forward it onto the TRILL network. The destination host will now 
>> receive duplicate frames till one of them stops being DRB.
>>
>> Am I mistaken ?
>>
>> Dinesh
>> Radia Perlman wrote:
>>  
>>> Dinesh,
>>>
>>> I think you are right that there can be a temporary loop due to a 
>>> partitioned VLAN 1.
>>> And I think we can make it sufficiently unlikely to occur with a 
>>> suggestion I'll make
>>> after I explain the problem.
>>>
>>> The temporary loop would be if R1 and R2, on the same layer 2 cloud, 
>>> have
>>> connectivity through VLAN A but not VLAN 1. So there would be two 
>>> DRBs, on
>>> both VLAN A and VLAN 1. There would be two pseudonodes, say R1.79 
>>> and R2.62,
>>> and both would claim to be connected to both VLAN A and VLAN 1, and 
>>> both
>>> would claim the same root bridge, say 5134.
>>>
>>> A multicast tagged with VLAN 1 would not be too much of a problem 
>>> because anything
>>> R1 decapsulates onto that VLAN-1-partitioned cloud would not make it 
>>> through
>>> the partitioned cloud to R2. But since we are not running the DRB 
>>> election tagged
>>> with VLAN A, R1 and R2 do not realize that they can talk via VLAN A.
>>>
>>> Therefore, a VLAN A-tagged packet would get picked up by both R1 and 
>>> R2,
>>> and both would assume they are DRB.
>>> Also, if R1 receives a (inner header) VLAN-A tagged frame
>>> from the campus, R1 will decapsulate it onto the layer 2 cloud as a 
>>> VLAN-A
>>> tagged packet, and R2 will see it
>>> and re-encapsulate it onto the campus, and R1 would see it again and 
>>> decapsulate it, etc.
>>>
>>> This loop will eventually be fixed when R1 sees the LSP from 
>>> pseudonode  R2.62 indicating
>>> that the root bridge is 5134, since R1 will also think that the 
>>> cloud that R1 is DRB for has
>>> root bridge 5134.
>>>
>>> So here's a possible fix:
>>>
>>> R1 does not decapsulate a multidestination packet with ingress 
>>> RBridge R2 unless R1
>>> has an LSP from R2, and has LSPs from all pseudonodes that R2 claims 
>>> (in R2's
>>> LSP) to be DRB for. Note that I'm suggesting adding another flag in 
>>> the neighbor
>>> list in R2's LSP saying "not only am I attached to this pseudonode, 
>>> but I am
>>> DRB for it".
>>>
>>> If R1 has all the pseudonode LSPs for which R2 is DRB, R1 can see if 
>>> the root bridge
>>> listed is the same as the one for the link on which R2 would like to 
>>> decapsulate, and if it is,
>>> then don't decapsulate.
>>>
>>> We were already saying that if R1 notices that R2.79 has the same 
>>> root bridge as
>>> a link R1 wants to be DRB for that one of R1 or R2 would lose, based 
>>> on a tie-breaker
>>> based on ID, and stop forwarding traffic to/from the link. What I'm 
>>> suggesting is that
>>> you also don't forward multidestination traffic to/from a link if 
>>> you don't yet have all
>>> the associated LSP information from the ingress RBridge that can 
>>> assure you there
>>> isn't a common root bridge.
>>>
>>> Radia
>>>
>>>
>>>
>>>
>>> Dinesh G Dutt wrote:
>>>    
>>>> OK, based on emails from James Carlson and Radia, I went back and 
>>>> thought about my reasons for objecting to the suggested proposal. I 
>>>> also spoke to some field engineers to validate my understanding of 
>>>> what I thought the issues were.
>>>>
>>>> There are two issues that we're dealing with here:
>>>> - Simplifying DRB election to conduct it only on VLAN 1
>>>> - Merging partitioned VLANs.
>>>>
>>>> I'd like to separate the two issues. Let me discuss only the first 
>>>> issue, the simplified DRB election in this email. I'll send out a 
>>>> separate email on the other issue.
>>>>
>>>> Assuming VLAN 1 exists everywhere is an acceptable alternative. I 
>>>> was informed that even with STP, customers enable VLAN 1 and allow 
>>>> only control traffic on it and not data traffic. If we have VLAN 1 
>>>> present as a common configuration, then running DRB only on VLAN 1 
>>>> and following Radia's proposal (or fixing it to work) seems 
>>>> acceptable, except for one caveat.
>>>>
>>>> However, in the event of a misconfiguration and VLAN 1 not being 
>>>> present, while the scheme proposed partitions the network and 
>>>> prevents loops, it seems to me that there is a period during which 
>>>> temporary loops can happen and duplicate frames are delivered by 
>>>> two DRBs. This seems unacceptable to me from a customer point of 
>>>> view. If we can fix this temporary loop (or someone can explain to 
>>>> me why there are no temporary loops), I'd be willing to support 
>>>> this proposal.
>>>>
>>>> BTW, GVTP/MMRP or equivalent is very much not enabled in >80-90% of 
>>>> customer networks and so we cannot assume or mandate their being 
>>>> there.
>>>>
>>>> Dinesh
>>>> Radia Perlman wrote:
>>>>      
>>>>> I had a conversation with Anoop, and he is (quite understandably)
>>>>> uneasy about sending IS-IS Hellos tagged with every VLAN. So he
>>>>> made the following suggestion, which I think makes sense.
>>>>>
>>>>> a) declare that bridges must be configured
>>>>> so that VLAN 1 (default VLAN) must not be
>>>>> partitioned on a layer 2 cloud. We will detect the misconfiguration
>>>>> if it occurs (see d)) so that we at least do not have loops, but 
>>>>> TRILL will not
>>>>> stand on its head to support what will be declared a gross 
>>>>> misconfiguration.
>>>>>
>>>>> b) Run the IS-IS election tagged with VLAN 1. Each RBridge has
>>>>> the following information in its IS-IS Hello:
>>>>>
>>>>> . I am R1
>>>>> . I hear Hellos from {R2, R3, R7, R11}
>>>>> . If I am DRB, the pseudonode name will be R1.59
>>>>> . My priority for the set of VLANs {A, D, W} is 7
>>>>> . My priority for the set of VLANs {B, C, F, G, H} is 3
>>>>>
>>>>> c) If R1 becomes DRB for at least one of the VLANs on the cloud,
>>>>> then R1 announces, in R1's LSP on behalf of pseudonode R1.59,
>>>>> the ID of the root bridge on the primary spanning tree
>>>>> instance for that layer 2 cloud, along with the set of VLANs for 
>>>>> which
>>>>> R1 is DRB on that cloud.
>>>>>
>>>>> Note: The current draft spec isn't clear what information R1 
>>>>> reports in the pseudonode
>>>>> LSP and what it reports in its own LSP.
>>>>> I'm suggesting reporting the bridge ID and
>>>>> set of VLANs in the pseudonode LSP.
>>>>>
>>>>> d) If R2 thinks itself is DRB for VLAN A on a port with root 
>>>>> bridge r11,
>>>>> and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A
>>>>> listed as one of the VLANs, this indicates that VLAN 1 on that layer
>>>>> 2 cloud is partitioned. So one of R1 or R2 should stop forwarding
>>>>> data to/from that cloud for VLAN A. Use ID as a tie breaker, so
>>>>> if R2's IS-IS system ID is lower than R1's, then R2 stops 
>>>>> forwarding VLAN A
>>>>> traffic to and from the port that has root bridge r11.
>>>>> This is the behavior that will occur if VLAN 1 on that port is
>>>>> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and 
>>>>> R2 would
>>>>> have seen each other's Hellos and not both think they are DRB for 
>>>>> VLAN A (or
>>>>> any other VLAN).
>>>>>
>>>>> e) This proposal supports multiple DRBs on a cloud for load splitting
>>>>> based on VLANs, since the RBridges can have different priorities
>>>>> for different VLANs. It still requires only sending one Hello, tagged
>>>>> with VLAN 1. R2 should
>>>>> not panic if R2 notices that R1.59 has the same root bridge as on
>>>>> a port on which R2 is DRB, if R1.59's listed set of VLANs does not
>>>>> include any VLANs for which R2 is DRB on the link with
>>>>> that root bridge. If there is only partial overlap
>>>>> of VLAN IDs, say the overlap is VLANs {D, F, and H},
>>>>> then (the loser based on ID tie-breaker) will stop forwarding traffic
>>>>> to/from that link that is tagged with VLANs D, F, or H.
>>>>>
>>>>> f) If some VLAN, say VLAN C, is actually partitioned, then the
>>>>> result of this is that some VLAN C endnodes on that layer 2 cloud
>>>>> will be orphaned. We will choose NOT to solve that.
>>>>>
>>>>>
>>>>> The result of this proposal is that
>>>>> RBridges will only need to send IS-IS Hellos tagged
>>>>> with VLAN 1, and the only thing it does NOT solve (over
>>>>> the current proposal of sending Hellos with every possible VLAN 
>>>>> tag on
>>>>> each port) is that sometimes endnodes might get orphaned if you have
>>>>> a partitioned VLAN.
>>>>>
>>>>>
>>>>> We *could* in that case, if someone *actually wanted* to have VLAN A
>>>>> partitioned on that cloud, configure the RBridges on that layer 2
>>>>> cloud to explicitly run a different election
>>>>> for VLAN A (and note in the pseudonode LSP that VLAN A had
>>>>> an explicit election tagged with VLAN A so that if there were
>>>>> two DRBs they wouldn't panic). But I'd prefer not solving this 
>>>>> case and
>>>>> keeping it simpler (and safer).
>>>>>
>>>>> Radia
>>>>> _______________________________________________
>>>>> 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


Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l76GnGb6025467 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Mon, 6 Aug 2007 09:49:16 -0700 (PDT)
Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> for [e-mail]; Mon, 06 Aug 2007 10:49:10 -0500 (CDT)
Received: from [144.92.67.161] (ricotta.doit.wisc.edu [144.92.67.161]) by smtpauth2.wiscmail.wisc.edu (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Mon, 06 Aug 2007 10:49:08 -0500 (CDT)
Date: Mon, 06 Aug 2007 10:48:53 -0500
From: "Dale W. Carder" <[e-mail]>
In-reply-to: <[e-mail]>
To: Anoop Ghanwani <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.3)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-Spam-Report: AuthenticatedSender=yes, SenderIP=144.92.67.161
X-Spam-PmxInfo: Server=avs-12, Version=5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.6.82822, SenderIP=144.92.67.161
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged	withallthe VLAN tags
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, 06 Aug 2007 16:49:31 -0000
Status: RO
Content-Length: 1419

On Aug 3, 2007, at 12:07 PM, Anoop Ghanwani wrote:
>> Large core switches running rapid-STP can send a BPDU every 2
>> seconds across around 10,000 instances (m vlans * n ports) today.
>> These switches are also usually sending out (LLDP or CDP) and
>> UDLD frames on every port, too.
>
> This is completely wrong!  RSTP is not VLAN aware.
> MSTP is, but it is limited to 64 instances.  This
> is quite a different number than the 10000 that you
> quote.

I was referring in this case to a proprietary implementation,
but my point is that it seems possible that it can be done.

I am not saying that sending hellos on every vlan is a great
idea, but I just wanted to show that I believe it is feasible
based on deployments I have seen that are running protocols
that do send hellos or similar on every vlan today.

>> Perhaps a compromise would be to use vlan 1 as the default, but a
>> TRILL implementation MAY allow this to be configurable by the
>> administrator.
>
> I agree.  As also pointed out by Arien Vijn, we could
> select any VLAN as the "default RBridge VLAN", but we do
> need one.

I don't think there is any easy solution.

Could the default be to use vlan 1 *untagged*?  This would
allow an rbridge to be plugged in almost anywhere.  If a
network operator wanted to change the vlan number she could
do it on her existing bridged lan.

Is there a more formal name for the "default RBridge VLAN"?

Dale


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 l753w5wc005501 for <[e-mail]>; Sat, 4 Aug 2007 20:58:05 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-10.tower-119.messagelabs.com!1186286283!23089297!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [144.189.100.103]
Received: (qmail 16453 invoked from network); 5 Aug 2007 03:58:04 -0000
Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-10.tower-119.messagelabs.com with SMTP; 5 Aug 2007 03:58:04 -0000
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l753w3sR014674 for <[e-mail]>; Sat, 4 Aug 2007 20:58:03 -0700 (MST)
Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l753w2Rl025439 for <[e-mail]>; Sat, 4 Aug 2007 22:58:03 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l753w1KK025421 for <[e-mail]>; Sat, 4 Aug 2007 22:58:01 -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, 4 Aug 2007 23:57:58 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withall the VLAN tags
thread-index: AcfVZps1BZNs/e+/T7aePZVYAElOwgAGmAGAACX5VLAAPTY/gA==
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Vontu: Pass
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 l753w5wc005501
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withall the VLAN tags
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: Sun, 05 Aug 2007 03:58:32 -0000
Status: RO
Content-Length: 8747

Silvano,

I think that the provisions in the draft should be changed. At a
minimum, it seems useful when someone is doing a DRB election on one
VLAN intending to produce results that apply to multiple VLANs that the
Hellos list the VLANs and be able to specify different priorities for
them so the elections are not all required to come out the same. And
some additional logic to handle partitions seems reasonable.

Donald

-----Original Message-----
From: Silvano Gai [mailto:[e-mail]] 
Sent: Friday, August 03, 2007 5:59 PM
To: Eastlake III Donald-LDE008; [e-mail]
Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
withall the VLAN tags

Donald,

I am OK with the text in -05, I thought that Radia wanted to change it.

As far as I am not prevented from running one DRB per VLAN, I don't care
too much which is the default.

I don't want TRILL to mandate implementing a single DRB election and
additional tests that don't cover all the cases.

Let's keep it simple. The current text is fine.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Friday, August 03, 2007 1:37 PM
> To: [e-mail]
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> withall the VLAN tags
> 
> So why should the default be to tag Hellos with any VLAN ID? It seems
to
> me that there are two cases.
> 
> If you know, via configuration or otherwise, that there are no
> intervening legacy bridges (doesn't particularly matter if its
> point-to-point between two Rbridges or a multiaccess link with several
> Rbridges as long as there are no bridges in the way), then all TRILL
> IS-IS and TRILL data frames should be untagged.
> 
> If there are or might be intervening bridges, then I would think the
> default should be for Hellos to be priority tagged with priority 7.
This
> means the tag has the null VLAN ID zero, that is, it does not specify
> any VLAN. If it turns out there actually aren't any bridges, this
works
> fine. If the link is actually a bridged LAN, the requirement is then
> that the bridge ports that the Rbridges are connected to be configured
> to be the same VLAN, whatever that is, and that that VLAN be connected
> through that particular bridged LAN. If these bridge ports are default
> configured, this means the TRILL IS-IS Hello frames will acquire VLAN
1
> tagging on bridged LAN ingress and have that tag stripped on bridged
LAN
> egress and you would want VLAN 1 to be well connected through the
> bridged LAN. If, for some reason, VLAN 1 is inconvenient for the
network
> operator to use in the particular bridged LAN in question, the network
> operator would be free to configure the bridge ports so that the TRILL
> frames get tagged with whatever VLAN is more convenient for them to
use
> to provide connectivity. It could still be possible to configure
> Rbridges, on a per port basis, to tag outgoing TRILL frames with some
> specific VLAN ID if that is more convenient.
> 
> I would like to point out that, while the proposal from Radia below is
> much more detailed and better worked out and while the related
> provisions in the current protocol draft are much more vague,
> nevertheless, the current protocol draft approximately corresponds to
> this proposal. In particular, due to previous concerns about multiple
> Hellos, among other things the protocol draft (-05) says:
> 
> Section 2, Page 7:
>    If a link is actually a bridged LAN configured for VLANs, it is
>    possible that the link might be partitioned with respect to some
>    VLANs.  The default is to run a single DRB election on a link, with
>    the IS-IS Hellos either with no VLAN tag (the default), or with the
>    VLAN tag specifying the default VLAN for the link. If the RBridge
is
>    configured to support a set of k VLANs on the link, then the
RBridge
>    runs the IS-IS DRB election up to k times, each instance tagged
with
>    one of the VLANs in that set of VLANs depending on its
configuration.
>    Therefore there might be multiple DRBs on the link, but at most one
>    on that link per VLAN. By configuration, the DRB for some VLANs may
>    be set by copying the DRB status in the relevant RBridges from a
>    different VLAN rather than by election.
> 
> So, arguably, the single Hello proposal below is approximately like
> using the current vague provisions in the protocol configured to only
> Hello on VLAN 1 and applying the result to all VLANs. The main
> difference is the proposal provides the per VLAN priorities in the
Hello
> so you don't need this stuff about copying DRB status but can
> independently determine it for different VLANs without a per VLAN
> Hello...
> 
> Donald
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Radia Perlman
> Sent: Thursday, August 02, 2007 8:23 PM
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> with allthe VLAN tags
> 
> ...
> 
> But at this point let's close this issue, which is basically to adopt
> Anoop's
> proposal of only sending IS-IS Hellos tagged with VLAN 1,
> plus my addendum to avoid temporary loops when VLAN 1 is partitioned
by
> having RB2 refuse to decapsulate packets onto a port from ingress
> RBridge RB1 unless
> RB2 has received LSPs from RB1 and all pseudonodes that RB1 is DRB
for.
> 
> *************
> To review it:
> 
> a) declare that bridges must be configured
> so that VLAN 1 (default VLAN) must not be
> partitioned on a layer 2 cloud. We will detect the misconfiguration
> if it occurs (see d)) so that we do not have loops, but if VLAN 1
> is partitioned parts of the layer 2 cloud might wind up orphaned
> from the rest of the campus.
> 
> b) Send IS-IS Hellos tagged with VLAN 1, containing the following:
> 
> . I am R1
> . I hear Hellos from {R2, R3, R7, R11}
> . If I am DRB, the pseudonode name will be R1.59
> . My priority for the set of VLANs {A, D, W} is 7
> . My priority for the set of VLANs {B, C, F, G, H} is 3
> 
> c) If R1 becomes DRB for at least one of the VLANs on the cloud,
> then R1 announces (in R1's LSP)
> connectivity to pseudonode R1.59, together with
> a flag saying "I am DRB for this pseudonode". Also, in R1's LSP on
> behalf of pseudonode R1.59, R1 announces
> the ID of the root bridge on the primary spanning tree
> instance for that layer 2 cloud, along with the set of VLANs for which
> R1 is DRB on that cloud.
> 
> d) If R2 thinks itself is DRB for VLAN A on a port with root bridge
r11,
> and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A
> listed as one of the VLANs, this indicates that VLAN 1 on that layer
> 2 cloud is partitioned. So one of R1 or R2 should stop forwarding
> data to/from that cloud for VLAN A. Use ID as a tie breaker, so
> if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding
> VLAN A
> traffic to and from the port that has root bridge r11.
> This is the behavior that will occur if VLAN 1 on that port is
> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2
> would
> have seen each other's Hellos and not both think they are DRB for VLAN
A
> (or
> any other VLAN).
> 
> e) This proposal supports multiple DRBs on a cloud for load splitting
> based on VLANs, since the RBridges can have different priorities
> for different VLANs. It still requires only sending one Hello, tagged
> with VLAN 1. R2 should
> not panic if R2 notices that R1.59 has the same root bridge as on
> a port on which R2 is DRB, if R1.59's listed set of VLANs does not
> include any VLANs for which R2 is DRB on the link with
> that root bridge. If there is only partial overlap
> of VLAN IDs, say the overlap is VLANs {D, F, and H},
> then (the loser based on ID tie-breaker) will stop forwarding traffic
> to/from that link that is tagged with VLANs D, F, or H.
> 
> f) If some VLAN, say VLAN C, is actually partitioned, then the
> result of this is that some VLAN C endnodes on that layer 2 cloud
> will be orphaned. We will choose NOT to solve that.
> 
> g) To avoid temporary loops when VLAN 1 is partitioned, for each
> other RBridge RB1, RB2 sets an (internal) flag "OK to decapsulate
> from", provided that RB2 has an LSP from RB1 and all pseudonodes
> RB1 claims to be attached to. If RB2 receives a frame from ingress
> RB1 and this flag is NOT true, then RB2 will refuse to decapsulate
> the packet onto any ports. (regardless of VLAN and regardless of
whether
> the frame is multidestination or unicast).
> 
> 
> Radia
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l73Lxi1U012551 for <[e-mail]>; Fri, 3 Aug 2007 14:59:44 -0700 (PDT)
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: Fri, 3 Aug 2007 14:59:04 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withall the VLAN tags
Thread-Index: AcfVZps1BZNs/e+/T7aePZVYAElOwgAGmAGAACX5VLA=
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l73Lxi1U012551
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withall the VLAN tags
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, 03 Aug 2007 22:00:05 -0000
Status: RO
Content-Length: 8065

Donald,

I am OK with the text in -05, I thought that Radia wanted to change it.

As far as I am not prevented from running one DRB per VLAN, I don't care
too much which is the default.

I don't want TRILL to mandate implementing a single DRB election and
additional tests that don't cover all the cases.

Let's keep it simple. The current text is fine.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Friday, August 03, 2007 1:37 PM
> To: [e-mail]
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> withall the VLAN tags
> 
> So why should the default be to tag Hellos with any VLAN ID? It seems
to
> me that there are two cases.
> 
> If you know, via configuration or otherwise, that there are no
> intervening legacy bridges (doesn't particularly matter if its
> point-to-point between two Rbridges or a multiaccess link with several
> Rbridges as long as there are no bridges in the way), then all TRILL
> IS-IS and TRILL data frames should be untagged.
> 
> If there are or might be intervening bridges, then I would think the
> default should be for Hellos to be priority tagged with priority 7.
This
> means the tag has the null VLAN ID zero, that is, it does not specify
> any VLAN. If it turns out there actually aren't any bridges, this
works
> fine. If the link is actually a bridged LAN, the requirement is then
> that the bridge ports that the Rbridges are connected to be configured
> to be the same VLAN, whatever that is, and that that VLAN be connected
> through that particular bridged LAN. If these bridge ports are default
> configured, this means the TRILL IS-IS Hello frames will acquire VLAN
1
> tagging on bridged LAN ingress and have that tag stripped on bridged
LAN
> egress and you would want VLAN 1 to be well connected through the
> bridged LAN. If, for some reason, VLAN 1 is inconvenient for the
network
> operator to use in the particular bridged LAN in question, the network
> operator would be free to configure the bridge ports so that the TRILL
> frames get tagged with whatever VLAN is more convenient for them to
use
> to provide connectivity. It could still be possible to configure
> Rbridges, on a per port basis, to tag outgoing TRILL frames with some
> specific VLAN ID if that is more convenient.
> 
> I would like to point out that, while the proposal from Radia below is
> much more detailed and better worked out and while the related
> provisions in the current protocol draft are much more vague,
> nevertheless, the current protocol draft approximately corresponds to
> this proposal. In particular, due to previous concerns about multiple
> Hellos, among other things the protocol draft (-05) says:
> 
> Section 2, Page 7:
>    If a link is actually a bridged LAN configured for VLANs, it is
>    possible that the link might be partitioned with respect to some
>    VLANs.  The default is to run a single DRB election on a link, with
>    the IS-IS Hellos either with no VLAN tag (the default), or with the
>    VLAN tag specifying the default VLAN for the link. If the RBridge
is
>    configured to support a set of k VLANs on the link, then the
RBridge
>    runs the IS-IS DRB election up to k times, each instance tagged
with
>    one of the VLANs in that set of VLANs depending on its
configuration.
>    Therefore there might be multiple DRBs on the link, but at most one
>    on that link per VLAN. By configuration, the DRB for some VLANs may
>    be set by copying the DRB status in the relevant RBridges from a
>    different VLAN rather than by election.
> 
> So, arguably, the single Hello proposal below is approximately like
> using the current vague provisions in the protocol configured to only
> Hello on VLAN 1 and applying the result to all VLANs. The main
> difference is the proposal provides the per VLAN priorities in the
Hello
> so you don't need this stuff about copying DRB status but can
> independently determine it for different VLANs without a per VLAN
> Hello...
> 
> Donald
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Radia Perlman
> Sent: Thursday, August 02, 2007 8:23 PM
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> with allthe VLAN tags
> 
> ...
> 
> But at this point let's close this issue, which is basically to adopt
> Anoop's
> proposal of only sending IS-IS Hellos tagged with VLAN 1,
> plus my addendum to avoid temporary loops when VLAN 1 is partitioned
by
> having RB2 refuse to decapsulate packets onto a port from ingress
> RBridge RB1 unless
> RB2 has received LSPs from RB1 and all pseudonodes that RB1 is DRB
for.
> 
> *************
> To review it:
> 
> a) declare that bridges must be configured
> so that VLAN 1 (default VLAN) must not be
> partitioned on a layer 2 cloud. We will detect the misconfiguration
> if it occurs (see d)) so that we do not have loops, but if VLAN 1
> is partitioned parts of the layer 2 cloud might wind up orphaned
> from the rest of the campus.
> 
> b) Send IS-IS Hellos tagged with VLAN 1, containing the following:
> 
> . I am R1
> . I hear Hellos from {R2, R3, R7, R11}
> . If I am DRB, the pseudonode name will be R1.59
> . My priority for the set of VLANs {A, D, W} is 7
> . My priority for the set of VLANs {B, C, F, G, H} is 3
> 
> c) If R1 becomes DRB for at least one of the VLANs on the cloud,
> then R1 announces (in R1's LSP)
> connectivity to pseudonode R1.59, together with
> a flag saying "I am DRB for this pseudonode". Also, in R1's LSP on
> behalf of pseudonode R1.59, R1 announces
> the ID of the root bridge on the primary spanning tree
> instance for that layer 2 cloud, along with the set of VLANs for which
> R1 is DRB on that cloud.
> 
> d) If R2 thinks itself is DRB for VLAN A on a port with root bridge
r11,
> and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A
> listed as one of the VLANs, this indicates that VLAN 1 on that layer
> 2 cloud is partitioned. So one of R1 or R2 should stop forwarding
> data to/from that cloud for VLAN A. Use ID as a tie breaker, so
> if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding
> VLAN A
> traffic to and from the port that has root bridge r11.
> This is the behavior that will occur if VLAN 1 on that port is
> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2
> would
> have seen each other's Hellos and not both think they are DRB for VLAN
A
> (or
> any other VLAN).
> 
> e) This proposal supports multiple DRBs on a cloud for load splitting
> based on VLANs, since the RBridges can have different priorities
> for different VLANs. It still requires only sending one Hello, tagged
> with VLAN 1. R2 should
> not panic if R2 notices that R1.59 has the same root bridge as on
> a port on which R2 is DRB, if R1.59's listed set of VLANs does not
> include any VLANs for which R2 is DRB on the link with
> that root bridge. If there is only partial overlap
> of VLAN IDs, say the overlap is VLANs {D, F, and H},
> then (the loser based on ID tie-breaker) will stop forwarding traffic
> to/from that link that is tagged with VLANs D, F, or H.
> 
> f) If some VLAN, say VLAN C, is actually partitioned, then the
> result of this is that some VLAN C endnodes on that layer 2 cloud
> will be orphaned. We will choose NOT to solve that.
> 
> g) To avoid temporary loops when VLAN 1 is partitioned, for each
> other RBridge RB1, RB2 sets an (internal) flag "OK to decapsulate
> from", provided that RB2 has an LSP from RB1 and all pseudonodes
> RB1 claims to be attached to. If RB2 receives a frame from ingress
> RB1 and this flag is NOT true, then RB2 will refuse to decapsulate
> the packet onto any ports. (regardless of VLAN and regardless of
whether
> the frame is multidestination or unicast).
> 
> 
> Radia
> 
> _______________________________________________
> 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 l73Kacmr016408 for <[e-mail]>; Fri, 3 Aug 2007 13:36:38 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-14.tower-128.messagelabs.com!1186173396!14261966!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 12924 invoked from network); 3 Aug 2007 20:36:36 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-128.messagelabs.com with SMTP; 3 Aug 2007 20:36:36 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l73Kaao5006515 for <[e-mail]>; Fri, 3 Aug 2007 13:36:36 -0700 (MST)
Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l73KaaV2012939 for <[e-mail]>; Fri, 3 Aug 2007 15:36:36 -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 l73KaZGh012927 for <[e-mail]>; Fri, 3 Aug 2007 15:36:35 -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: Fri, 3 Aug 2007 16:36:45 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
thread-index: AcfVZps1BZNs/e+/T7aePZVYAElOwgAGmAGA
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Vontu: Pass
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 l73Kacmr016408
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
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, 03 Aug 2007 20:37:13 -0000
Status: RO
Content-Length: 6956

So why should the default be to tag Hellos with any VLAN ID? It seems to
me that there are two cases.

If you know, via configuration or otherwise, that there are no
intervening legacy bridges (doesn't particularly matter if its
point-to-point between two Rbridges or a multiaccess link with several
Rbridges as long as there are no bridges in the way), then all TRILL
IS-IS and TRILL data frames should be untagged.

If there are or might be intervening bridges, then I would think the
default should be for Hellos to be priority tagged with priority 7. This
means the tag has the null VLAN ID zero, that is, it does not specify
any VLAN. If it turns out there actually aren't any bridges, this works
fine. If the link is actually a bridged LAN, the requirement is then
that the bridge ports that the Rbridges are connected to be configured
to be the same VLAN, whatever that is, and that that VLAN be connected
through that particular bridged LAN. If these bridge ports are default
configured, this means the TRILL IS-IS Hello frames will acquire VLAN 1
tagging on bridged LAN ingress and have that tag stripped on bridged LAN
egress and you would want VLAN 1 to be well connected through the
bridged LAN. If, for some reason, VLAN 1 is inconvenient for the network
operator to use in the particular bridged LAN in question, the network
operator would be free to configure the bridge ports so that the TRILL
frames get tagged with whatever VLAN is more convenient for them to use
to provide connectivity. It could still be possible to configure
Rbridges, on a per port basis, to tag outgoing TRILL frames with some
specific VLAN ID if that is more convenient.

I would like to point out that, while the proposal from Radia below is
much more detailed and better worked out and while the related
provisions in the current protocol draft are much more vague,
nevertheless, the current protocol draft approximately corresponds to
this proposal. In particular, due to previous concerns about multiple
Hellos, among other things the protocol draft (-05) says:

Section 2, Page 7:
   If a link is actually a bridged LAN configured for VLANs, it is
   possible that the link might be partitioned with respect to some
   VLANs.  The default is to run a single DRB election on a link, with
   the IS-IS Hellos either with no VLAN tag (the default), or with the
   VLAN tag specifying the default VLAN for the link. If the RBridge is
   configured to support a set of k VLANs on the link, then the RBridge
   runs the IS-IS DRB election up to k times, each instance tagged with
   one of the VLANs in that set of VLANs depending on its configuration.
   Therefore there might be multiple DRBs on the link, but at most one
   on that link per VLAN. By configuration, the DRB for some VLANs may
   be set by copying the DRB status in the relevant RBridges from a
   different VLAN rather than by election.

So, arguably, the single Hello proposal below is approximately like
using the current vague provisions in the protocol configured to only
Hello on VLAN 1 and applying the result to all VLANs. The main
difference is the proposal provides the per VLAN priorities in the Hello
so you don't need this stuff about copying DRB status but can
independently determine it for different VLANs without a per VLAN
Hello...

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Thursday, August 02, 2007 8:23 PM
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
with allthe VLAN tags

...

But at this point let's close this issue, which is basically to adopt 
Anoop's
proposal of only sending IS-IS Hellos tagged with VLAN 1,
plus my addendum to avoid temporary loops when VLAN 1 is partitioned by
having RB2 refuse to decapsulate packets onto a port from ingress 
RBridge RB1 unless
RB2 has received LSPs from RB1 and all pseudonodes that RB1 is DRB for.

*************
To review it:

a) declare that bridges must be configured
so that VLAN 1 (default VLAN) must not be
partitioned on a layer 2 cloud. We will detect the misconfiguration
if it occurs (see d)) so that we do not have loops, but if VLAN 1
is partitioned parts of the layer 2 cloud might wind up orphaned
from the rest of the campus.

b) Send IS-IS Hellos tagged with VLAN 1, containing the following:

. I am R1
. I hear Hellos from {R2, R3, R7, R11}
. If I am DRB, the pseudonode name will be R1.59
. My priority for the set of VLANs {A, D, W} is 7
. My priority for the set of VLANs {B, C, F, G, H} is 3

c) If R1 becomes DRB for at least one of the VLANs on the cloud,
then R1 announces (in R1's LSP)
connectivity to pseudonode R1.59, together with
a flag saying "I am DRB for this pseudonode". Also, in R1's LSP on
behalf of pseudonode R1.59, R1 announces
the ID of the root bridge on the primary spanning tree
instance for that layer 2 cloud, along with the set of VLANs for which
R1 is DRB on that cloud.

d) If R2 thinks itself is DRB for VLAN A on a port with root bridge r11,
and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A
listed as one of the VLANs, this indicates that VLAN 1 on that layer
2 cloud is partitioned. So one of R1 or R2 should stop forwarding
data to/from that cloud for VLAN A. Use ID as a tie breaker, so
if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding
VLAN A
traffic to and from the port that has root bridge r11.
This is the behavior that will occur if VLAN 1 on that port is
actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2
would
have seen each other's Hellos and not both think they are DRB for VLAN A
(or
any other VLAN).

e) This proposal supports multiple DRBs on a cloud for load splitting
based on VLANs, since the RBridges can have different priorities
for different VLANs. It still requires only sending one Hello, tagged
with VLAN 1. R2 should
not panic if R2 notices that R1.59 has the same root bridge as on
a port on which R2 is DRB, if R1.59's listed set of VLANs does not
include any VLANs for which R2 is DRB on the link with
that root bridge. If there is only partial overlap
of VLAN IDs, say the overlap is VLANs {D, F, and H},
then (the loser based on ID tie-breaker) will stop forwarding traffic
to/from that link that is tagged with VLANs D, F, or H.

f) If some VLAN, say VLAN C, is actually partitioned, then the
result of this is that some VLAN C endnodes on that layer 2 cloud
will be orphaned. We will choose NOT to solve that.

g) To avoid temporary loops when VLAN 1 is partitioned, for each
other RBridge RB1, RB2 sets an (internal) flag "OK to decapsulate
from", provided that RB2 has an LSP from RB1 and all pseudonodes
RB1 claims to be attached to. If RB2 receives a frame from ingress
RB1 and this flag is NOT true, then RB2 will refuse to decapsulate
the packet onto any ports. (regardless of VLAN and regardless of whether
the frame is multidestination or unicast).


Radia



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 l73H8had012366 for <[e-mail]>; Fri, 3 Aug 2007 10:08:43 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 03 Aug 2007 10:08:23 -0700
X-IronPort-AV: i="4.19,218,1183359600";  d="scan'208"; a="16114547:sNHT53432546391"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 9C36423836C; Fri,  3 Aug 2007 10:08:23 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 3 Aug 2007 10:08:23 -0700
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: Fri, 3 Aug 2007 10:07:24 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged	withallthe VLAN tags
Thread-Index: AcfVgLFjEN8dtXDkQmubZfYES0PYTgAbjIcQ
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: "Dale W. Carder" <[e-mail]>
X-OriginalArrivalTime: 03 Aug 2007 17:08:23.0654 (UTC) FILETIME=[E654E860:01C7D5F0]
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 l73H8had012366
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged	withallthe VLAN tags
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, 03 Aug 2007 17:08:56 -0000
Status: RO
Content-Length: 4129

 

> -----Original Message-----
> From: Dale W. Carder [mailto:[e-mail]] 
> Sent: Thursday, August 02, 2007 8:45 PM
> To: Anoop Ghanwani
> Cc: Silvano Gai; Radia Perlman; [e-mail]
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos 
> tagged withallthe VLAN tags
> 
> 
> On Aug 2, 2007, at 8:18 PM, Anoop Ghanwani wrote:
> > There are typically a lot of VLANs at the edge
> > and only a few in the core.  Today, a typically
> > enterprise could have 100's (may be a couple of
> > 1000) VLANs configured on a typical bridge.
> 
> The capabilities of typical small edge switches (the 48 port
> kind) seem to max out at about 16-128 vlans total, and may have
> other limitations if the switch is maintaining STP for each vlan.
> This edge limitation is one of the reasons an enterprise partitions
> vlans.
> 
> Larger, "core" switches have enough capability to run up to 4096
> vlans at a time.
> 
> Another issue causing vlans to be partitioned is because some
> bridges only support vlan numbers < 1024 and there simply is a need
> for vlan number reuse throughout the enterprise.

Just to make it clear, we're talking about VLAN reuse
within a single bridged LAN as opposed to VLAN reuse
LANs that are isolated by routers.  I don't see how that
can be common.  It would be a configuration nightmare
to administer and also to debug.

> Vlans are also partitioned is because flooding unknown unicast
> frames takes up unnecessary bandwidth on 802.1q links, and can fill
> up mac address tables on less-capable switches.  When there are
> situations like arp storms (no network is ever loop free),
> partitioning vlan usage is even more of an issue.
> 
> > But, we don't enable routing protocols on those
> > VLANs because that's just the edge.  Once in the
> > core, there are typically only a handful of VLANs
> > on which routing protocols are enabled.
> <chop>
> >   We don't
> > have experience sending hellos on so many VLANs
> > and so many ports.
> 
> I disagree with this argument.  Many enterprises and carriers
> deploy multiple routers on each edge subnet for redundancy.  To
> do this, VRRP or HSRP sends out hellos per vlan.  If they are
> running multicast routing, PIM sends out hellos per vlan also.
> Some places even tune these hellos to very aggressive settings
> such as 1 per second or less.

Most folks don't enable routing/VRRP on all VLANs.
Many switches that are capable of having 4K VLANs
configured are not capable of even having IP configured
on all 4K VLANs let alone turning on VRRP.

> Large core switches running rapid-STP can send a BPDU every 2
> seconds across around 10,000 instances (m vlans * n ports) today.
> These switches are also usually sending out (LLDP or CDP) and
> UDLD frames on every port, too.

This is completely wrong!  RSTP is not VLAN aware.
MSTP is, but it is limited to 64 instances.  This 
is quite a different number than the 10000 that you
quote.

> > Unlike a router, an RBridge
> > has to start sending hellos on all its ports as soon
> > as it comes up.  I don't think things can be
> > made to work if we have to send these hellos
> > for every VLAN configured on a port.
> 
> Again, big switches have been doing this for a while for rapid-STP.
> Routers with large numbers of vlans (sub-interfaces) are also doing
> this today.
> 
> The larger issue I see with Radia's proposal is simply the choice
> of vlan #1.  It could be a poor choice in large enterprises because
> of scalability concerns and also compatability with existing
> implementations.  As a few others have brought up, many deployments
> (including mine) have disabled vlan 1 altogether.
> 
> One of these issues is that vlan 1 is often untagged on 802.1q trunk
> links.  As a security precaution, it is common to disable vlan 1
> across switches to prevent malicious vlan-hopping.
> 
> Perhaps a compromise would be to use vlan 1 as the default, but a
> TRILL implementation MAY allow this to be configurable by the
> administrator.

I agree.  As also pointed out by Arien Vijn, we could
select any VLAN as the "default RBridge VLAN", but we do
need one.

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 l735cBfN001877 for <[e-mail]>; Thu, 2 Aug 2007 22:38:12 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 02 Aug 2007 22:38:11 -0700 (PDT)
Received: from [129.150.16.21] ([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]; Thu, 02 Aug 2007 22:38:09 -0700 (PDT)
Date: Thu, 02 Aug 2007 22:39:06 -0700
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]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged	withallthe VLAN tags
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, 03 Aug 2007 05:38:46 -0000
Status: RO
Content-Length: 2749

Rereading what I wrote, I'd be surprised if anyone actually understood 
what I was
saying from what I wrote, so let me explain again.

Let's say you have 5 RBridges, RBa, RBb, RBc, RBd, and RBe. RBa 
transmits Hellos
with tag VLAN A, RBb tags its hellos with VLAN B, and so forth.

If RBa *only* sends things on the link tagged with VLAN A, it can still 
tell if
it has an adjacency to, say, RBc, which only transmits Hellos tagged with
VLAN C, because the IS-IS Hello includes the list of
RBridges that the transmitting RBridge has heard Hellos from.

So even if RBc always talks to RBa using VLAN C, and RBa always talks to RBc
using VLAN A, things will work. RBa knows it will work because RBc indicates
in its Hello, that it heard a Hello from RBa.

Not sure if that's any clearer, but at least I get credit for trying. 
Maybe partial credit?

Radia


Radia Perlman wrote:
> Dale,
>
> I certainly don't care which VLAN we choose. There should be a default 
> one, and
> we should also allow an implementation to be configurable to set it to
> a different VLAN tag, or even a set of VLAN tags (in which case the RBridge
> would issue multiple IS-IS Hellos, one with each configured VLAN tag).
>
> If RBa receives an IS-IS Hello, it should accept it regardless of what 
> VLAN it is
> tagged with. If RBa transmits IS-IS Hellos tagged with VLAN A, and RBb 
> transmits
> IS-IS Hellos tagged with VLAN B, and RBC, .... etc. Then RBa will assume it
> has an adjacency with RBc if "RBa" appears in RBc's IS-IS Hello (as 
> someone that
> RBc has seen Hellos from). And RBa would use VLAN tag A when talking across
> the link to any RBridge that RBa has an adjacency with. This may be a 
> bit confusing
> to understand but I don't think there's a problem with it.
>
> So...what do you think the default VLAN tag should be for sending IS-IS 
> Hellos?
>
> Radia
>
>
>
> Dale W. Carder wrote:
>   
>> The larger issue I see with Radia's proposal is simply the choice
>> of vlan #1.  It could be a poor choice in large enterprises because
>> of scalability concerns and also compatability with existing
>> implementations.  As a few others have brought up, many deployments
>> (including mine) have disabled vlan 1 altogether.
>>
>> One of these issues is that vlan 1 is often untagged on 802.1q trunk
>> links.  As a security precaution, it is common to disable vlan 1
>> across switches to prevent malicious vlan-hopping.
>>
>> Perhaps a compromise would be to use vlan 1 as the default, but a
>> TRILL implementation MAY allow this to be configurable by the
>> administrator.
>>
>> Dale
>>     
>
> _______________________________________________
> 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 l734ZefU015019 for <[e-mail]>; Thu, 2 Aug 2007 21:35:40 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 02 Aug 2007 21:35:40 -0700 (PDT)
Received: from [129.150.16.21] ([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]; Thu, 02 Aug 2007 21:35:38 -0700 (PDT)
Date: Thu, 02 Aug 2007 21:36:36 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Dale W. Carder" <[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]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged	withallthe VLAN tags
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, 03 Aug 2007 04:36:05 -0000
Status: RO
Content-Length: 1643

Dale,

I certainly don't care which VLAN we choose. There should be a default 
one, and
we should also allow an implementation to be configurable to set it to
a different VLAN tag, or even a set of VLAN tags (in which case the RBridge
would issue multiple IS-IS Hellos, one with each configured VLAN tag).

If RBa receives an IS-IS Hello, it should accept it regardless of what 
VLAN it is
tagged with. If RBa transmits IS-IS Hellos tagged with VLAN A, and RBb 
transmits
IS-IS Hellos tagged with VLAN B, and RBC, .... etc. Then RBa will assume it
has an adjacency with RBc if "RBa" appears in RBc's IS-IS Hello (as 
someone that
RBc has seen Hellos from). And RBa would use VLAN tag A when talking across
the link to any RBridge that RBa has an adjacency with. This may be a 
bit confusing
to understand but I don't think there's a problem with it.

So...what do you think the default VLAN tag should be for sending IS-IS 
Hellos?

Radia



Dale W. Carder wrote:
>
> The larger issue I see with Radia's proposal is simply the choice
> of vlan #1.  It could be a poor choice in large enterprises because
> of scalability concerns and also compatability with existing
> implementations.  As a few others have brought up, many deployments
> (including mine) have disabled vlan 1 altogether.
>
> One of these issues is that vlan 1 is often untagged on 802.1q trunk
> links.  As a security precaution, it is common to disable vlan 1
> across switches to prevent malicious vlan-hopping.
>
> Perhaps a compromise would be to use vlan 1 as the default, but a
> TRILL implementation MAY allow this to be configurable by the
> administrator.
>
> Dale



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 l734IVDj010288 for <[e-mail]>; Thu, 2 Aug 2007 21:18:31 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 02 Aug 2007 21:18:29 -0700 (PDT)
Received: from [129.150.16.21] ([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]; Thu, 02 Aug 2007 21:18:29 -0700 (PDT)
Date: Thu, 02 Aug 2007 21:19:22 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Dinesh G Dutt <[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 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all	the VLAN tags
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, 03 Aug 2007 04:18:59 -0000
Status: RO
Content-Length: 9661

Yes, Dinesh, in your example if there are temporarily k RBridges on the 
same layer 2 cloud
that all think they are DRB, you might multiply by k, each packet going 
off the cloud.

However, this is not as disastrous as a loop.

We can avoid that though by saying that you shouldn't start 
encapsulating or decapsulating
data off the link until you've synchronized LSP datases with each of 
your RBridge neighbors.
IS-IS exchanges LSP database information (a "complete sequence numbers 
packet") when
a link comes up. I think we should throw that rule in as well.

Radia




Dinesh G Dutt wrote:
> Radia,
>
> I thought about this solution but think that it still doesn't fix the 
> problem of duplicates. If both R1 and R2 think that they're DRB for VLAN 
> A, when they both receive a frame on VLAN A from  the 802.1D cloud 
> (unknown unicast for example), they both think that they can forward it 
> onto the TRILL network. The destination host will now receive duplicate 
> frames till one of them stops being DRB.
>
> Am I mistaken ?
>
> Dinesh
> Radia Perlman wrote:
>   
>> Dinesh,
>>
>> I think you are right that there can be a temporary loop due to a 
>> partitioned VLAN 1.
>> And I think we can make it sufficiently unlikely to occur with a 
>> suggestion I'll make
>> after I explain the problem.
>>
>> The temporary loop would be if R1 and R2, on the same layer 2 cloud, have
>> connectivity through VLAN A but not VLAN 1. So there would be two 
>> DRBs, on
>> both VLAN A and VLAN 1. There would be two pseudonodes, say R1.79 and 
>> R2.62,
>> and both would claim to be connected to both VLAN A and VLAN 1, and both
>> would claim the same root bridge, say 5134.
>>
>> A multicast tagged with VLAN 1 would not be too much of a problem 
>> because anything
>> R1 decapsulates onto that VLAN-1-partitioned cloud would not make it 
>> through
>> the partitioned cloud to R2. But since we are not running the DRB 
>> election tagged
>> with VLAN A, R1 and R2 do not realize that they can talk via VLAN A.
>>
>> Therefore, a VLAN A-tagged packet would get picked up by both R1 and R2,
>> and both would assume they are DRB.
>> Also, if R1 receives a (inner header) VLAN-A tagged frame
>> from the campus, R1 will decapsulate it onto the layer 2 cloud as a 
>> VLAN-A
>> tagged packet, and R2 will see it
>> and re-encapsulate it onto the campus, and R1 would see it again and 
>> decapsulate it, etc.
>>
>> This loop will eventually be fixed when R1 sees the LSP from 
>> pseudonode  R2.62 indicating
>> that the root bridge is 5134, since R1 will also think that the cloud 
>> that R1 is DRB for has
>> root bridge 5134.
>>
>> So here's a possible fix:
>>
>> R1 does not decapsulate a multidestination packet with ingress RBridge 
>> R2 unless R1
>> has an LSP from R2, and has LSPs from all pseudonodes that R2 claims 
>> (in R2's
>> LSP) to be DRB for. Note that I'm suggesting adding another flag in 
>> the neighbor
>> list in R2's LSP saying "not only am I attached to this pseudonode, 
>> but I am
>> DRB for it".
>>
>> If R1 has all the pseudonode LSPs for which R2 is DRB, R1 can see if 
>> the root bridge
>> listed is the same as the one for the link on which R2 would like to 
>> decapsulate, and if it is,
>> then don't decapsulate.
>>
>> We were already saying that if R1 notices that R2.79 has the same root 
>> bridge as
>> a link R1 wants to be DRB for that one of R1 or R2 would lose, based 
>> on a tie-breaker
>> based on ID, and stop forwarding traffic to/from the link. What I'm 
>> suggesting is that
>> you also don't forward multidestination traffic to/from a link if you 
>> don't yet have all
>> the associated LSP information from the ingress RBridge that can 
>> assure you there
>> isn't a common root bridge.
>>
>> Radia
>>
>>
>>
>>
>> Dinesh G Dutt wrote:
>>     
>>> OK, based on emails from James Carlson and Radia, I went back and 
>>> thought about my reasons for objecting to the suggested proposal. I 
>>> also spoke to some field engineers to validate my understanding of 
>>> what I thought the issues were.
>>>
>>> There are two issues that we're dealing with here:
>>> - Simplifying DRB election to conduct it only on VLAN 1
>>> - Merging partitioned VLANs.
>>>
>>> I'd like to separate the two issues. Let me discuss only the first 
>>> issue, the simplified DRB election in this email. I'll send out a 
>>> separate email on the other issue.
>>>
>>> Assuming VLAN 1 exists everywhere is an acceptable alternative. I was 
>>> informed that even with STP, customers enable VLAN 1 and allow only 
>>> control traffic on it and not data traffic. If we have VLAN 1 present 
>>> as a common configuration, then running DRB only on VLAN 1 and 
>>> following Radia's proposal (or fixing it to work) seems acceptable, 
>>> except for one caveat.
>>>
>>> However, in the event of a misconfiguration and VLAN 1 not being 
>>> present, while the scheme proposed partitions the network and 
>>> prevents loops, it seems to me that there is a period during which 
>>> temporary loops can happen and duplicate frames are delivered by two 
>>> DRBs. This seems unacceptable to me from a customer point of view. If 
>>> we can fix this temporary loop (or someone can explain to me why 
>>> there are no temporary loops), I'd be willing to support this proposal.
>>>
>>> BTW, GVTP/MMRP or equivalent is very much not enabled in >80-90% of 
>>> customer networks and so we cannot assume or mandate their being there.
>>>
>>> Dinesh
>>> Radia Perlman wrote:
>>>       
>>>> I had a conversation with Anoop, and he is (quite understandably)
>>>> uneasy about sending IS-IS Hellos tagged with every VLAN. So he
>>>> made the following suggestion, which I think makes sense.
>>>>
>>>> a) declare that bridges must be configured
>>>> so that VLAN 1 (default VLAN) must not be
>>>> partitioned on a layer 2 cloud. We will detect the misconfiguration
>>>> if it occurs (see d)) so that we at least do not have loops, but 
>>>> TRILL will not
>>>> stand on its head to support what will be declared a gross 
>>>> misconfiguration.
>>>>
>>>> b) Run the IS-IS election tagged with VLAN 1. Each RBridge has
>>>> the following information in its IS-IS Hello:
>>>>
>>>> . I am R1
>>>> . I hear Hellos from {R2, R3, R7, R11}
>>>> . If I am DRB, the pseudonode name will be R1.59
>>>> . My priority for the set of VLANs {A, D, W} is 7
>>>> . My priority for the set of VLANs {B, C, F, G, H} is 3
>>>>
>>>> c) If R1 becomes DRB for at least one of the VLANs on the cloud,
>>>> then R1 announces, in R1's LSP on behalf of pseudonode R1.59,
>>>> the ID of the root bridge on the primary spanning tree
>>>> instance for that layer 2 cloud, along with the set of VLANs for which
>>>> R1 is DRB on that cloud.
>>>>
>>>> Note: The current draft spec isn't clear what information R1 reports 
>>>> in the pseudonode
>>>> LSP and what it reports in its own LSP.
>>>> I'm suggesting reporting the bridge ID and
>>>> set of VLANs in the pseudonode LSP.
>>>>
>>>> d) If R2 thinks itself is DRB for VLAN A on a port with root bridge 
>>>> r11,
>>>> and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A
>>>> listed as one of the VLANs, this indicates that VLAN 1 on that layer
>>>> 2 cloud is partitioned. So one of R1 or R2 should stop forwarding
>>>> data to/from that cloud for VLAN A. Use ID as a tie breaker, so
>>>> if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding 
>>>> VLAN A
>>>> traffic to and from the port that has root bridge r11.
>>>> This is the behavior that will occur if VLAN 1 on that port is
>>>> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 
>>>> would
>>>> have seen each other's Hellos and not both think they are DRB for 
>>>> VLAN A (or
>>>> any other VLAN).
>>>>
>>>> e) This proposal supports multiple DRBs on a cloud for load splitting
>>>> based on VLANs, since the RBridges can have different priorities
>>>> for different VLANs. It still requires only sending one Hello, tagged
>>>> with VLAN 1. R2 should
>>>> not panic if R2 notices that R1.59 has the same root bridge as on
>>>> a port on which R2 is DRB, if R1.59's listed set of VLANs does not
>>>> include any VLANs for which R2 is DRB on the link with
>>>> that root bridge. If there is only partial overlap
>>>> of VLAN IDs, say the overlap is VLANs {D, F, and H},
>>>> then (the loser based on ID tie-breaker) will stop forwarding traffic
>>>> to/from that link that is tagged with VLANs D, F, or H.
>>>>
>>>> f) If some VLAN, say VLAN C, is actually partitioned, then the
>>>> result of this is that some VLAN C endnodes on that layer 2 cloud
>>>> will be orphaned. We will choose NOT to solve that.
>>>>
>>>>
>>>> The result of this proposal is that
>>>> RBridges will only need to send IS-IS Hellos tagged
>>>> with VLAN 1, and the only thing it does NOT solve (over
>>>> the current proposal of sending Hellos with every possible VLAN tag on
>>>> each port) is that sometimes endnodes might get orphaned if you have
>>>> a partitioned VLAN.
>>>>
>>>>
>>>> We *could* in that case, if someone *actually wanted* to have VLAN A
>>>> partitioned on that cloud, configure the RBridges on that layer 2
>>>> cloud to explicitly run a different election
>>>> for VLAN A (and note in the pseudonode LSP that VLAN A had
>>>> an explicit election tagged with VLAN A so that if there were
>>>> two DRBs they wouldn't panic). But I'd prefer not solving this case and
>>>> keeping it simpler (and safer).
>>>>
>>>> Radia
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> [e-mail]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>
>>>>   
>>>>         
>
>   



Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l733ipot019274 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Thu, 2 Aug 2007 20:44:52 -0700 (PDT)
Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> for [e-mail]; Thu, 02 Aug 2007 22:44:51 -0500 (CDT)
Received: from [192.168.1.102] (mdsnwikwbas08-pool6-a4.mdsnwikw.tds.net [69.129.197.4]) by smtpauth1.wiscmail.wisc.edu (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Thu, 02 Aug 2007 22:44:50 -0500 (CDT)
Date: Thu, 02 Aug 2007 22:44:59 -0500
From: "Dale W. Carder" <[e-mail]>
In-reply-to: <[e-mail]>
To: Anoop Ghanwani <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.2)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-Spam-Report: AuthenticatedSender=yes, SenderIP=192.168.1.102
X-Spam-PmxInfo: Server=avs-9, Version=5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.2.203127, SenderIP=192.168.1.102
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged	withallthe VLAN tags
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, 03 Aug 2007 03:45:03 -0000
Status: RO
Content-Length: 2972

Comments inline:

On Aug 2, 2007, at 8:18 PM, Anoop Ghanwani wrote:
> There are typically a lot of VLANs at the edge
> and only a few in the core.  Today, a typically
> enterprise could have 100's (may be a couple of
> 1000) VLANs configured on a typical bridge.

The capabilities of typical small edge switches (the 48 port
kind) seem to max out at about 16-128 vlans total, and may have
other limitations if the switch is maintaining STP for each vlan.
This edge limitation is one of the reasons an enterprise partitions
vlans.

Larger, "core" switches have enough capability to run up to 4096
vlans at a time.

Another issue causing vlans to be partitioned is because some
bridges only support vlan numbers < 1024 and there simply is a need
for vlan number reuse throughout the enterprise.

Vlans are also partitioned is because flooding unknown unicast
frames takes up unnecessary bandwidth on 802.1q links, and can fill
up mac address tables on less-capable switches.  When there are
situations like arp storms (no network is ever loop free),
partitioning vlan usage is even more of an issue.

> But, we don't enable routing protocols on those
> VLANs because that's just the edge.  Once in the
> core, there are typically only a handful of VLANs
> on which routing protocols are enabled.
<chop>
>   We don't
> have experience sending hellos on so many VLANs
> and so many ports.

I disagree with this argument.  Many enterprises and carriers
deploy multiple routers on each edge subnet for redundancy.  To
do this, VRRP or HSRP sends out hellos per vlan.  If they are
running multicast routing, PIM sends out hellos per vlan also.
Some places even tune these hellos to very aggressive settings
such as 1 per second or less.

Large core switches running rapid-STP can send a BPDU every 2
seconds across around 10,000 instances (m vlans * n ports) today.
These switches are also usually sending out (LLDP or CDP) and
UDLD frames on every port, too.

> Unlike a router, an RBridge
> has to start sending hellos on all its ports as soon
> as it comes up.  I don't think things can be
> made to work if we have to send these hellos
> for every VLAN configured on a port.

Again, big switches have been doing this for a while for rapid-STP.
Routers with large numbers of vlans (sub-interfaces) are also doing
this today.

The larger issue I see with Radia's proposal is simply the choice
of vlan #1.  It could be a poor choice in large enterprises because
of scalability concerns and also compatability with existing
implementations.  As a few others have brought up, many deployments
(including mine) have disabled vlan 1 altogether.

One of these issues is that vlan 1 is often untagged on 802.1q trunk
links.  As a security precaution, it is common to disable vlan 1
across switches to prevent malicious vlan-hopping.

Perhaps a compromise would be to use vlan 1 as the default, but a
TRILL implementation MAY allow this to be configurable by the
administrator.

Dale


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 l731JjGf029754 for <[e-mail]>; Thu, 2 Aug 2007 18:19:49 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 02 Aug 2007 18:19:45 -0700
X-IronPort-AV: i="4.19,215,1183359600";  d="scan'208"; a="16081767:sNHT21676683"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id C62EB2383A1; Thu,  2 Aug 2007 18:19:45 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 2 Aug 2007 18:19:46 -0700
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, 2 Aug 2007 18:18:48 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags
Thread-Index: AcfT25KJ6pLzlruYS9GOuHcm7Xsd/wBdN5vQAAYka3A=
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 03 Aug 2007 01:19:46.0167 (UTC) FILETIME=[60DDA070:01C7D56C]
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 l731JjGf029754
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags
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, 03 Aug 2007 01:20:18 -0000
Status: RO
Content-Length: 9023

Silvano,

There are typically a lot of VLANs at the edge
and only a few in the core.  Today, a typically
enterprise could have 100's (may be a couple of
1000) VLANs configured on a typical bridge.  
But, we don't enable routing protocols on those 
VLANs because that's just the edge.  Once in the 
core, there are typically only a handful of VLANs
on which routing protocols are enabled.  We don't
have experience sending hellos on so many VLANs
and so many ports.  Unlike a router, an RBridge
has to start sending hellos on all its ports as soon
as it comes up.  I don't think things can be
made to work if we have to send these hellos
for every VLAN configured on a port.

I understand that in the ideal case we'd like to
work with any arbitrary configuration.

However, I don't understand how per-VLAN hellos would
keep things working correctly.  If I have a partitioned
VLAN and, as a result, have 2 RBridges that become DRBs
for that VLAN, and if there exists some other
path between these RBridges (via TRILL), then 
these two partitioned sections will now function
as a single partition for that VLAN (via the 
RBridges).  So how have I simplified the network
managers job?  He would still have to change
his/her VLAN configuration if he/she intends
to keep the two partitions disconnected even
after introducing the RBridges.

Anoop

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Silvano Gai
> Sent: Thursday, August 02, 2007 3:09 PM
> To: Radia Perlman
> Cc: [e-mail]
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos 
> tagged withallthe VLAN tags
> 
> Radia,
> 
> One of the goal of TRILL is plug and play.
> 
> To most people this means "no configuration", to me it means 
> that I should be able to replace a bridge with an RBridge in 
> an existing network, configure the RBridge like the replaced 
> bridge and continue to work.
> 
> I DON'T want to ask the network manager to change its VLAN 
> management scheme and as a result its IP subnet management 
> scheme to be able to deploy RBridges.
> 
> If I ask a network manager to do so, he/she will probably 
> choose to use an IP routed backbone, defeating the original 
> goal of TRILL.
> 
> WE MUST be able to drop RBridges in existing networks without 
> asking for global reconfigurations.
> 
> I say all this because we shouldn't  care "what problem 
> customers are trying to solve with partitioned VLANs", we 
> know they exists and we don't want to ask customers to design 
> from scratch to be able to use RBridges.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: Radia Perlman [mailto:[e-mail]]
> > Sent: Tuesday, July 31, 2007 6:32 PM
> > To: Silvano Gai
> > Cc: Dinesh G Dutt; [e-mail]
> > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> with
> > allthe VLAN tags
> > 
> > Silvano....I still don't know what problem customers are trying to
> solve
> > with partitioned VLANs.
> > If it's that they want more than 4000 VLANs, then the design we had 
> > (before Anoop's suggestion) also won't help them with that.
> > If it is an important problem to use more than 4000 VLANs, we could 
> > (by extending the size of the VLAN tag within a TRILL campus) solve 
> > that problem in a much more robust, easily understandable way than 
> > configuring interswitch ports to block some VLANs. And I 
> absolutely do 
> > not understand any
> other
> > problems
> > that might be solved with intentionally partitioning VLANs, 
> and it's 
> > impossible to design something without understand the problem that 
> > needs to be solved.
> > 
> > We do have to carefully consider what "breaks"  (in the proposal we 
> > are currently considering) if a customer does actually configure 
> > bridges in some layer 2 cloud so that VLAN 1 is partitioned.
> > I believe the only consequence of a customer configuring bridges so 
> > that VLAN 1 is partitioned in some layer 2 cloud  is that
> core
> > RBridges that might have connectivity to each other through 
> some VLAN 
> > other than VLAN 1 will not realize they are adjacent, and will 
> > therefore not form IS-IS adjacencies, which means fewer 
> > RBridge-RBridge links in the core than there might
> actually
> > be. This might
> > actually cause the campus to get partitioned (since the only 
> > connectivity between RBridges will be using VLAN 1, and if all the 
> > links in the cut set require an outer tag of other than 1 
> in order for 
> > RBridges to talk, these links won't be found or used). It 
> might cause 
> > less good paths. However, it will *not* cause loops, 
> because if there 
> > is no connectivity for flooding of LSPs, data also won't 
> flow in the 
> > core.
> > 
> > The advantage of this proposal is simplicity and scalability -- only
> one
> > Hello per port.
> > 
> > As I said, I cannot understand what functionality is lost if all
> switch
> > ports within a layer 2
> > cloud must be configured to pass VLAN 1, and until we do understand
> some
> > important hardship that this rule imposes, I'd say this (Anoop's
> proposal)
> > is obviously the right thing to do.
> > 
> > Radia
> > 
> > 
> > Silvano Gai wrote:
> > > Radia,
> > >
> > > We are describing to you how VLANs are deployed today in 
> Enterprise 
> > > networks. You may say that "you don't like it", we may agree with
> you,
> > > but this does not change how they are deployed.
> > >
> > > For RBridges to be successful they need to be able to 
> replace core 
> > > bridges without messing up the existing network configurations.
> > >
> > > Today most customers do not deploy VLANs end-to-end and they do
> reuse
> > > VLANs number in different part of the enterprise. If RBridges are
> not
> > > capable of supporting this, they are not attractive.
> > >
> > > Remember that the #1 customer requirement we have for TRILL is:
> "replace
> > > core bridges with RBridges to enable Equal Cost Multi 
> Path, all the
> rest
> > > MUST remain the same".
> > >
> > > GVRP is not deployed; I am not sure which customers Anoop is
> referring
> > > to.
> > >
> > > -- Silvano
> > >
> > >
> > >> -----Original Message-----
> > >> From: Radia Perlman [mailto:[e-mail]]
> > >> Sent: Tuesday, July 31, 2007 11:19 AM
> > >> To: Dinesh G Dutt
> > >> Cc: Silvano Gai; [e-mail]
> > >> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
> tagged
> > >>
> > > with
> > >
> > >> allthe VLAN tags
> > >>
> > >> I don't understand that problem. What you're describing 
> might argue
> > >>
> > > for
> > >
> > >> bridges using a unique
> > >> spanning tree per VLAN in order to optimize traffic flow for that
> > >>
> > > VLAN,
> > >
> > >> but I don't
> > >> see what it has to do with wanting to partition VLANs.
> > >>
> > >> Radia
> > >>
> > >>
> > >> Dinesh G Dutt wrote:
> > >>
> > >>> Radia Perlman wrote:
> > >>>
> > >>>> I'd like to understand what problem customers are attempting to
> > >>>>
> > > solve
> > >
> > >>>> with
> > >>>> partitioned VLANs, and what hardship it would present 
> to require
> at
> > >>>> least one of the
> > >>>>
> > >>>>
> > >>> The primary problem with having a VLAN everywhere is 
> that the root
> > >>>
> > > of
> > >
> > >>> the spanning tree moves around leading to non-optimal forwarding
> in
> > >>> enterprise networks. Enterprise networks are carefully 
> engineered 
> > >>> networks and in the event of failure, they want to localize the 
> > >>> effects as much as possible. So, they want each VLAN to be
> localized
> > >>> and roots where they want it to be. Having a common 
> VLAN messes up 
> > >>> that arrangement. Also, VLAN 1 is the default VLAN when a switch
> > >>>
> > > comes
> > >
> > >>> up and there is typically lots of customer data on it.
> > >>>
> > >>>> VLANs to *not* be partitioned. With TRILL, if a customer
> eventually
> > >>>> replaces
> > >>>> all bridges, the customer will not be able to partition VLANs
> > >>>>
> > > anymore.
> > >
> > >>> As I raised it in the meeting, this is a side-effect 
> that has not
> > >>>
> > > been
> > >
> > >>> considered before and needs to be carefully thought through. I
> don't
> > >>> think many people are aware of this issue with TRILL 
> that doesn't 
> > >>> exist with 802.1Q bridges today.
> > >>>
> > >>>> Also, from
> > >>>> what Anoop was explaining to me, the GVRP protocol would
> > >>>>
> > > automatically
> > >
> > >>>> configure the switch-to-switch links to join all the 
> islands of 
> > >>>> VLANs. So it would seem as though it can't be that fatal to 
> > >>>> solving customer
> problems
> > >>>>
> > > to
> > >
> > >>>> require
> > >>>> *one* VLAN on a layer 2 cloud to not be partitioned.
> > >>>>
> > >>>>
> > >>> GVRP is not deployed by a significant majority of customers.
> > >>>
> > >>> Dinesh
> > >>>
> > >>>
> > >
> > >
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l73177jg022393 for <[e-mail]>; Thu, 2 Aug 2007 18:07:07 -0700 (PDT)
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 02 Aug 2007 18:07:07 -0700
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAJIcskarR7PE/2dsb2JhbAA
X-IronPort-AV: i="4.19,215,1183359600";  d="scan'208"; a="193466538:sNHT35446203"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l73176Mu008765;  Thu, 2 Aug 2007 18:07:06 -0700
Received: from [10.21.71.194] ([10.21.71.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l73176ja000634; Fri, 3 Aug 2007 01:07:06 GMT
Message-ID: <[e-mail]>
Date: Thu, 02 Aug 2007 18:07:06 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.5 (X11/20070716)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9165; t=1186103226; x=1186967226; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Avoiding=20sending=20multiple=20IS-IS=20H ellos=20tagged=20with=0A=20all=09the=20VLAN=20tags |Sender:=20; bh=tJUuEPcEWrmKaMBRluMOIC2dnwmutNOL0ZFZFhv7L+Y=; b=BTodZiHh1Zj9J/9HnhgIR4PqOPzHSxbaCMCh+RjlSvMxd94y1JGuElg4FsXcynr+UwXxRDc0 rz8JwUwC95LcTspWItoImr/OiDUMdO74tYHKjIxZXrfLDBm5DkOKRy9f;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all	the VLAN tags
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, 03 Aug 2007 01:07:39 -0000
Status: RO
Content-Length: 8949

Radia,

I thought about this solution but think that it still doesn't fix the 
problem of duplicates. If both R1 and R2 think that they're DRB for VLAN 
A, when they both receive a frame on VLAN A from  the 802.1D cloud 
(unknown unicast for example), they both think that they can forward it 
onto the TRILL network. The destination host will now receive duplicate 
frames till one of them stops being DRB.

Am I mistaken ?

Dinesh
Radia Perlman wrote:
> Dinesh,
>
> I think you are right that there can be a temporary loop due to a 
> partitioned VLAN 1.
> And I think we can make it sufficiently unlikely to occur with a 
> suggestion I'll make
> after I explain the problem.
>
> The temporary loop would be if R1 and R2, on the same layer 2 cloud, have
> connectivity through VLAN A but not VLAN 1. So there would be two 
> DRBs, on
> both VLAN A and VLAN 1. There would be two pseudonodes, say R1.79 and 
> R2.62,
> and both would claim to be connected to both VLAN A and VLAN 1, and both
> would claim the same root bridge, say 5134.
>
> A multicast tagged with VLAN 1 would not be too much of a problem 
> because anything
> R1 decapsulates onto that VLAN-1-partitioned cloud would not make it 
> through
> the partitioned cloud to R2. But since we are not running the DRB 
> election tagged
> with VLAN A, R1 and R2 do not realize that they can talk via VLAN A.
>
> Therefore, a VLAN A-tagged packet would get picked up by both R1 and R2,
> and both would assume they are DRB.
> Also, if R1 receives a (inner header) VLAN-A tagged frame
> from the campus, R1 will decapsulate it onto the layer 2 cloud as a 
> VLAN-A
> tagged packet, and R2 will see it
> and re-encapsulate it onto the campus, and R1 would see it again and 
> decapsulate it, etc.
>
> This loop will eventually be fixed when R1 sees the LSP from 
> pseudonode  R2.62 indicating
> that the root bridge is 5134, since R1 will also think that the cloud 
> that R1 is DRB for has
> root bridge 5134.
>
> So here's a possible fix:
>
> R1 does not decapsulate a multidestination packet with ingress RBridge 
> R2 unless R1
> has an LSP from R2, and has LSPs from all pseudonodes that R2 claims 
> (in R2's
> LSP) to be DRB for. Note that I'm suggesting adding another flag in 
> the neighbor
> list in R2's LSP saying "not only am I attached to this pseudonode, 
> but I am
> DRB for it".
>
> If R1 has all the pseudonode LSPs for which R2 is DRB, R1 can see if 
> the root bridge
> listed is the same as the one for the link on which R2 would like to 
> decapsulate, and if it is,
> then don't decapsulate.
>
> We were already saying that if R1 notices that R2.79 has the same root 
> bridge as
> a link R1 wants to be DRB for that one of R1 or R2 would lose, based 
> on a tie-breaker
> based on ID, and stop forwarding traffic to/from the link. What I'm 
> suggesting is that
> you also don't forward multidestination traffic to/from a link if you 
> don't yet have all
> the associated LSP information from the ingress RBridge that can 
> assure you there
> isn't a common root bridge.
>
> Radia
>
>
>
>
> Dinesh G Dutt wrote:
>> OK, based on emails from James Carlson and Radia, I went back and 
>> thought about my reasons for objecting to the suggested proposal. I 
>> also spoke to some field engineers to validate my understanding of 
>> what I thought the issues were.
>>
>> There are two issues that we're dealing with here:
>> - Simplifying DRB election to conduct it only on VLAN 1
>> - Merging partitioned VLANs.
>>
>> I'd like to separate the two issues. Let me discuss only the first 
>> issue, the simplified DRB election in this email. I'll send out a 
>> separate email on the other issue.
>>
>> Assuming VLAN 1 exists everywhere is an acceptable alternative. I was 
>> informed that even with STP, customers enable VLAN 1 and allow only 
>> control traffic on it and not data traffic. If we have VLAN 1 present 
>> as a common configuration, then running DRB only on VLAN 1 and 
>> following Radia's proposal (or fixing it to work) seems acceptable, 
>> except for one caveat.
>>
>> However, in the event of a misconfiguration and VLAN 1 not being 
>> present, while the scheme proposed partitions the network and 
>> prevents loops, it seems to me that there is a period during which 
>> temporary loops can happen and duplicate frames are delivered by two 
>> DRBs. This seems unacceptable to me from a customer point of view. If 
>> we can fix this temporary loop (or someone can explain to me why 
>> there are no temporary loops), I'd be willing to support this proposal.
>>
>> BTW, GVTP/MMRP or equivalent is very much not enabled in >80-90% of 
>> customer networks and so we cannot assume or mandate their being there.
>>
>> Dinesh
>> Radia Perlman wrote:
>>> I had a conversation with Anoop, and he is (quite understandably)
>>> uneasy about sending IS-IS Hellos tagged with every VLAN. So he
>>> made the following suggestion, which I think makes sense.
>>>
>>> a) declare that bridges must be configured
>>> so that VLAN 1 (default VLAN) must not be
>>> partitioned on a layer 2 cloud. We will detect the misconfiguration
>>> if it occurs (see d)) so that we at least do not have loops, but 
>>> TRILL will not
>>> stand on its head to support what will be declared a gross 
>>> misconfiguration.
>>>
>>> b) Run the IS-IS election tagged with VLAN 1. Each RBridge has
>>> the following information in its IS-IS Hello:
>>>
>>> . I am R1
>>> . I hear Hellos from {R2, R3, R7, R11}
>>> . If I am DRB, the pseudonode name will be R1.59
>>> . My priority for the set of VLANs {A, D, W} is 7
>>> . My priority for the set of VLANs {B, C, F, G, H} is 3
>>>
>>> c) If R1 becomes DRB for at least one of the VLANs on the cloud,
>>> then R1 announces, in R1's LSP on behalf of pseudonode R1.59,
>>> the ID of the root bridge on the primary spanning tree
>>> instance for that layer 2 cloud, along with the set of VLANs for which
>>> R1 is DRB on that cloud.
>>>
>>> Note: The current draft spec isn't clear what information R1 reports 
>>> in the pseudonode
>>> LSP and what it reports in its own LSP.
>>> I'm suggesting reporting the bridge ID and
>>> set of VLANs in the pseudonode LSP.
>>>
>>> d) If R2 thinks itself is DRB for VLAN A on a port with root bridge 
>>> r11,
>>> and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A
>>> listed as one of the VLANs, this indicates that VLAN 1 on that layer
>>> 2 cloud is partitioned. So one of R1 or R2 should stop forwarding
>>> data to/from that cloud for VLAN A. Use ID as a tie breaker, so
>>> if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding 
>>> VLAN A
>>> traffic to and from the port that has root bridge r11.
>>> This is the behavior that will occur if VLAN 1 on that port is
>>> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 
>>> would
>>> have seen each other's Hellos and not both think they are DRB for 
>>> VLAN A (or
>>> any other VLAN).
>>>
>>> e) This proposal supports multiple DRBs on a cloud for load splitting
>>> based on VLANs, since the RBridges can have different priorities
>>> for different VLANs. It still requires only sending one Hello, tagged
>>> with VLAN 1. R2 should
>>> not panic if R2 notices that R1.59 has the same root bridge as on
>>> a port on which R2 is DRB, if R1.59's listed set of VLANs does not
>>> include any VLANs for which R2 is DRB on the link with
>>> that root bridge. If there is only partial overlap
>>> of VLAN IDs, say the overlap is VLANs {D, F, and H},
>>> then (the loser based on ID tie-breaker) will stop forwarding traffic
>>> to/from that link that is tagged with VLANs D, F, or H.
>>>
>>> f) If some VLAN, say VLAN C, is actually partitioned, then the
>>> result of this is that some VLAN C endnodes on that layer 2 cloud
>>> will be orphaned. We will choose NOT to solve that.
>>>
>>>
>>> The result of this proposal is that
>>> RBridges will only need to send IS-IS Hellos tagged
>>> with VLAN 1, and the only thing it does NOT solve (over
>>> the current proposal of sending Hellos with every possible VLAN tag on
>>> each port) is that sometimes endnodes might get orphaned if you have
>>> a partitioned VLAN.
>>>
>>>
>>> We *could* in that case, if someone *actually wanted* to have VLAN A
>>> partitioned on that cloud, configure the RBridges on that layer 2
>>> cloud to explicitly run a different election
>>> for VLAN A (and note in the pseudonode LSP that VLAN A had
>>> an explicit election tagged with VLAN A so that if there were
>>> two DRBs they wouldn't panic). But I'd prefer not solving this case and
>>> keeping it simpler (and safer).
>>>
>>> Radia
>>> _______________________________________________
>>> 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


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 l730MfRS027026 for <[e-mail]>; Thu, 2 Aug 2007 17:22:41 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 02 Aug 2007 17:22:29 -0700 (PDT)
Received: from [129.150.16.21] ([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]; Thu, 02 Aug 2007 17:22:29 -0700 (PDT)
Date: Thu, 02 Aug 2007 17:23:26 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Silvano Gai <[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 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags
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, 03 Aug 2007 00:23:07 -0000
Status: RO
Content-Length: 11378

Silvano,

I strongly believe that one can't design something reasonable without 
understanding the problem
you're trying to solve. But at this point, whether or not it is useful 
to understand the problem
being solved is not useful to debate (though the last chapter of my book 
has a great
anecdote about why it is desirable to know what problem you're solving 
:-) ).

But at this point let's close this issue, which is basically to adopt 
Anoop's
proposal of only sending IS-IS Hellos tagged with VLAN 1,
plus my addendum to avoid temporary loops when VLAN 1 is partitioned by
having RB2 refuse to decapsulate packets onto a port from ingress 
RBridge RB1 unless
RB2 has received LSPs from RB1 and all pseudonodes that RB1 is DRB for.

*************
To review it:

a) declare that bridges must be configured
so that VLAN 1 (default VLAN) must not be
partitioned on a layer 2 cloud. We will detect the misconfiguration
if it occurs (see d)) so that we do not have loops, but if VLAN 1
is partitioned parts of the layer 2 cloud might wind up orphaned
from the rest of the campus.

b) Send IS-IS Hellos tagged with VLAN 1, containing the following:

. I am R1
. I hear Hellos from {R2, R3, R7, R11}
. If I am DRB, the pseudonode name will be R1.59
. My priority for the set of VLANs {A, D, W} is 7
. My priority for the set of VLANs {B, C, F, G, H} is 3

c) If R1 becomes DRB for at least one of the VLANs on the cloud,
then R1 announces (in R1's LSP)
connectivity to pseudonode R1.59, together with
a flag saying "I am DRB for this pseudonode". Also, in R1's LSP on behalf of pseudonode R1.59, R1 announces
the ID of the root bridge on the primary spanning tree
instance for that layer 2 cloud, along with the set of VLANs for which
R1 is DRB on that cloud.

d) If R2 thinks itself is DRB for VLAN A on a port with root bridge r11,
and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A
listed as one of the VLANs, this indicates that VLAN 1 on that layer
2 cloud is partitioned. So one of R1 or R2 should stop forwarding
data to/from that cloud for VLAN A. Use ID as a tie breaker, so
if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding VLAN A
traffic to and from the port that has root bridge r11.
This is the behavior that will occur if VLAN 1 on that port is
actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 would
have seen each other's Hellos and not both think they are DRB for VLAN A (or
any other VLAN).

e) This proposal supports multiple DRBs on a cloud for load splitting
based on VLANs, since the RBridges can have different priorities
for different VLANs. It still requires only sending one Hello, tagged
with VLAN 1. R2 should
not panic if R2 notices that R1.59 has the same root bridge as on
a port on which R2 is DRB, if R1.59's listed set of VLANs does not
include any VLANs for which R2 is DRB on the link with
that root bridge. If there is only partial overlap
of VLAN IDs, say the overlap is VLANs {D, F, and H},
then (the loser based on ID tie-breaker) will stop forwarding traffic
to/from that link that is tagged with VLANs D, F, or H.

f) If some VLAN, say VLAN C, is actually partitioned, then the
result of this is that some VLAN C endnodes on that layer 2 cloud
will be orphaned. We will choose NOT to solve that.

g) To avoid temporary loops when VLAN 1 is partitioned, for each
other RBridge RB1, RB2 sets an (internal) flag "OK to decapsulate
from", provided that RB2 has an LSP from RB1 and all pseudonodes
RB1 claims to be attached to. If RB2 receives a frame from ingress
RB1 and this flag is NOT true, then RB2 will refuse to decapsulate
the packet onto any ports. (regardless of VLAN and regardless of whether
the frame is multidestination or unicast).


Radia



Silvano Gai wrote:
> Radia,
>
> One of the goal of TRILL is plug and play.
>
> To most people this means "no configuration", to me it means that I
> should be able to replace a bridge with an RBridge in an existing
> network, configure the RBridge like the replaced bridge and continue to
> work.
>
> I DON'T want to ask the network manager to change its VLAN management
> scheme and as a result its IP subnet management scheme to be able to
> deploy RBridges.
>
> If I ask a network manager to do so, he/she will probably choose to use
> an IP routed backbone, defeating the original goal of TRILL.
>
> WE MUST be able to drop RBridges in existing networks without asking for
> global reconfigurations.
>
> I say all this because we shouldn't  care "what problem customers are
> trying to solve with partitioned VLANs", we know they exists and we
> don't want to ask customers to design from scratch to be able to use
> RBridges.
>
> -- Silvano
>
>   
>> -----Original Message-----
>> From: Radia Perlman [mailto:[e-mail]]
>> Sent: Tuesday, July 31, 2007 6:32 PM
>> To: Silvano Gai
>> Cc: Dinesh G Dutt; [e-mail]
>> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
>>     
> with
>   
>> allthe VLAN tags
>>
>> Silvano....I still don't know what problem customers are trying to
>>     
> solve
>   
>> with partitioned VLANs.
>> If it's that they want more than 4000 VLANs, then the design we had
>> (before
>> Anoop's suggestion) also won't help them with that.
>> If it is an important problem to use more than 4000 VLANs,
>> we could (by extending the size of the VLAN tag within a TRILL campus)
>> solve that
>> problem in a much more robust, easily understandable way than
>> configuring interswitch
>> ports to block some VLANs. And I absolutely do not understand any
>>     
> other
>   
>> problems
>> that might be solved with intentionally partitioning VLANs, and it's
>> impossible to design
>> something without understand the problem that needs to be solved.
>>
>> We do have to carefully consider what "breaks"  (in the
>> proposal we are currently considering) if a customer does actually
>> configure
>> bridges in some layer 2 cloud so that VLAN 1 is partitioned.
>> I believe the only consequence of a customer configuring
>> bridges so that VLAN 1 is partitioned in some layer 2 cloud  is that
>>     
> core
>   
>> RBridges that might have connectivity to each
>> other through some VLAN other than
>> VLAN 1 will not realize they are adjacent, and will therefore not form
>> IS-IS adjacencies, which
>> means fewer RBridge-RBridge links in the core than there might
>>     
> actually
>   
>> be. This might
>> actually cause the campus to get partitioned (since the only
>> connectivity between RBridges
>> will be using VLAN 1, and if all the links in the cut set require an
>> outer tag of other
>> than 1 in order for RBridges to talk, these links won't be found or
>> used). It might cause less good paths. However, it will *not* cause
>> loops, because if
>> there is no connectivity for flooding of LSPs, data also won't flow in
>> the core.
>>
>> The advantage of this proposal is simplicity and scalability -- only
>>     
> one
>   
>> Hello per port.
>>
>> As I said, I cannot understand what functionality is lost if all
>>     
> switch
>   
>> ports within a layer 2
>> cloud must be configured to pass VLAN 1, and until we do understand
>>     
> some
>   
>> important hardship that this rule imposes, I'd say this (Anoop's
>>     
> proposal)
>   
>> is obviously the right thing to do.
>>
>> Radia
>>
>>
>> Silvano Gai wrote:
>>     
>>> Radia,
>>>
>>> We are describing to you how VLANs are deployed today in Enterprise
>>> networks. You may say that "you don't like it", we may agree with
>>>       
> you,
>   
>>> but this does not change how they are deployed.
>>>
>>> For RBridges to be successful they need to be able to replace core
>>> bridges without messing up the existing network configurations.
>>>
>>> Today most customers do not deploy VLANs end-to-end and they do
>>>       
> reuse
>   
>>> VLANs number in different part of the enterprise. If RBridges are
>>>       
> not
>   
>>> capable of supporting this, they are not attractive.
>>>
>>> Remember that the #1 customer requirement we have for TRILL is:
>>>       
> "replace
>   
>>> core bridges with RBridges to enable Equal Cost Multi Path, all the
>>>       
> rest
>   
>>> MUST remain the same".
>>>
>>> GVRP is not deployed; I am not sure which customers Anoop is
>>>       
> referring
>   
>>> to.
>>>
>>> -- Silvano
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From: Radia Perlman [mailto:[e-mail]]
>>>> Sent: Tuesday, July 31, 2007 11:19 AM
>>>> To: Dinesh G Dutt
>>>> Cc: Silvano Gai; [e-mail]
>>>> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
>>>>         
> tagged
>   
>>> with
>>>
>>>       
>>>> allthe VLAN tags
>>>>
>>>> I don't understand that problem. What you're describing might argue
>>>>
>>>>         
>>> for
>>>
>>>       
>>>> bridges using a unique
>>>> spanning tree per VLAN in order to optimize traffic flow for that
>>>>
>>>>         
>>> VLAN,
>>>
>>>       
>>>> but I don't
>>>> see what it has to do with wanting to partition VLANs.
>>>>
>>>> Radia
>>>>
>>>>
>>>> Dinesh G Dutt wrote:
>>>>
>>>>         
>>>>> Radia Perlman wrote:
>>>>>
>>>>>           
>>>>>> I'd like to understand what problem customers are attempting to
>>>>>>
>>>>>>             
>>> solve
>>>
>>>       
>>>>>> with
>>>>>> partitioned VLANs, and what hardship it would present to require
>>>>>>             
> at
>   
>>>>>> least one of the
>>>>>>
>>>>>>
>>>>>>             
>>>>> The primary problem with having a VLAN everywhere is that the root
>>>>>
>>>>>           
>>> of
>>>
>>>       
>>>>> the spanning tree moves around leading to non-optimal forwarding
>>>>>           
> in
>   
>>>>> enterprise networks. Enterprise networks are carefully engineered
>>>>> networks and in the event of failure, they want to localize the
>>>>> effects as much as possible. So, they want each VLAN to be
>>>>>           
> localized
>   
>>>>> and roots where they want it to be. Having a common VLAN messes up
>>>>> that arrangement. Also, VLAN 1 is the default VLAN when a switch
>>>>>
>>>>>           
>>> comes
>>>
>>>       
>>>>> up and there is typically lots of customer data on it.
>>>>>
>>>>>           
>>>>>> VLANs to *not* be partitioned. With TRILL, if a customer
>>>>>>             
> eventually
>   
>>>>>> replaces
>>>>>> all bridges, the customer will not be able to partition VLANs
>>>>>>
>>>>>>             
>>> anymore.
>>>
>>>       
>>>>> As I raised it in the meeting, this is a side-effect that has not
>>>>>
>>>>>           
>>> been
>>>
>>>       
>>>>> considered before and needs to be carefully thought through. I
>>>>>           
> don't
>   
>>>>> think many people are aware of this issue with TRILL that doesn't
>>>>> exist with 802.1Q bridges today.
>>>>>
>>>>>           
>>>>>> Also, from
>>>>>> what Anoop was explaining to me, the GVRP protocol would
>>>>>>
>>>>>>             
>>> automatically
>>>
>>>       
>>>>>> configure the switch-to-switch links to join all the islands of
>>>>>> VLANs. So it would
>>>>>> seem as though it can't be that fatal to solving customer
>>>>>>             
> problems
>   
>>> to
>>>
>>>       
>>>>>> require
>>>>>> *one* VLAN on a layer 2 cloud to not be partitioned.
>>>>>>
>>>>>>
>>>>>>             
>>>>> GVRP is not deployed by a significant majority of customers.
>>>>>
>>>>> Dinesh
>>>>>
>>>>>
>>>>>           
>>>       
>
>   



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l72M9nrI006357 for <[e-mail]>; Thu, 2 Aug 2007 15:09:49 -0700 (PDT)
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, 2 Aug 2007 15:09:09 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags
Thread-Index: AcfT25KJ6pLzlruYS9GOuHcm7Xsd/wBdN5vQ
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l72M9nrI006357
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags
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, 02 Aug 2007 22:09:53 -0000
Status: RO
Content-Length: 6702

Radia,

One of the goal of TRILL is plug and play.

To most people this means "no configuration", to me it means that I
should be able to replace a bridge with an RBridge in an existing
network, configure the RBridge like the replaced bridge and continue to
work.

I DON'T want to ask the network manager to change its VLAN management
scheme and as a result its IP subnet management scheme to be able to
deploy RBridges.

If I ask a network manager to do so, he/she will probably choose to use
an IP routed backbone, defeating the original goal of TRILL.

WE MUST be able to drop RBridges in existing networks without asking for
global reconfigurations.

I say all this because we shouldn't  care "what problem customers are
trying to solve with partitioned VLANs", we know they exists and we
don't want to ask customers to design from scratch to be able to use
RBridges.

-- Silvano

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]]
> Sent: Tuesday, July 31, 2007 6:32 PM
> To: Silvano Gai
> Cc: Dinesh G Dutt; [e-mail]
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
with
> allthe VLAN tags
> 
> Silvano....I still don't know what problem customers are trying to
solve
> with partitioned VLANs.
> If it's that they want more than 4000 VLANs, then the design we had
> (before
> Anoop's suggestion) also won't help them with that.
> If it is an important problem to use more than 4000 VLANs,
> we could (by extending the size of the VLAN tag within a TRILL campus)
> solve that
> problem in a much more robust, easily understandable way than
> configuring interswitch
> ports to block some VLANs. And I absolutely do not understand any
other
> problems
> that might be solved with intentionally partitioning VLANs, and it's
> impossible to design
> something without understand the problem that needs to be solved.
> 
> We do have to carefully consider what "breaks"  (in the
> proposal we are currently considering) if a customer does actually
> configure
> bridges in some layer 2 cloud so that VLAN 1 is partitioned.
> I believe the only consequence of a customer configuring
> bridges so that VLAN 1 is partitioned in some layer 2 cloud  is that
core
> RBridges that might have connectivity to each
> other through some VLAN other than
> VLAN 1 will not realize they are adjacent, and will therefore not form
> IS-IS adjacencies, which
> means fewer RBridge-RBridge links in the core than there might
actually
> be. This might
> actually cause the campus to get partitioned (since the only
> connectivity between RBridges
> will be using VLAN 1, and if all the links in the cut set require an
> outer tag of other
> than 1 in order for RBridges to talk, these links won't be found or
> used). It might cause less good paths. However, it will *not* cause
> loops, because if
> there is no connectivity for flooding of LSPs, data also won't flow in
> the core.
> 
> The advantage of this proposal is simplicity and scalability -- only
one
> Hello per port.
> 
> As I said, I cannot understand what functionality is lost if all
switch
> ports within a layer 2
> cloud must be configured to pass VLAN 1, and until we do understand
some
> important hardship that this rule imposes, I'd say this (Anoop's
proposal)
> is obviously the right thing to do.
> 
> Radia
> 
> 
> Silvano Gai wrote:
> > Radia,
> >
> > We are describing to you how VLANs are deployed today in Enterprise
> > networks. You may say that "you don't like it", we may agree with
you,
> > but this does not change how they are deployed.
> >
> > For RBridges to be successful they need to be able to replace core
> > bridges without messing up the existing network configurations.
> >
> > Today most customers do not deploy VLANs end-to-end and they do
reuse
> > VLANs number in different part of the enterprise. If RBridges are
not
> > capable of supporting this, they are not attractive.
> >
> > Remember that the #1 customer requirement we have for TRILL is:
"replace
> > core bridges with RBridges to enable Equal Cost Multi Path, all the
rest
> > MUST remain the same".
> >
> > GVRP is not deployed; I am not sure which customers Anoop is
referring
> > to.
> >
> > -- Silvano
> >
> >
> >> -----Original Message-----
> >> From: Radia Perlman [mailto:[e-mail]]
> >> Sent: Tuesday, July 31, 2007 11:19 AM
> >> To: Dinesh G Dutt
> >> Cc: Silvano Gai; [e-mail]
> >> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
tagged
> >>
> > with
> >
> >> allthe VLAN tags
> >>
> >> I don't understand that problem. What you're describing might argue
> >>
> > for
> >
> >> bridges using a unique
> >> spanning tree per VLAN in order to optimize traffic flow for that
> >>
> > VLAN,
> >
> >> but I don't
> >> see what it has to do with wanting to partition VLANs.
> >>
> >> Radia
> >>
> >>
> >> Dinesh G Dutt wrote:
> >>
> >>> Radia Perlman wrote:
> >>>
> >>>> I'd like to understand what problem customers are attempting to
> >>>>
> > solve
> >
> >>>> with
> >>>> partitioned VLANs, and what hardship it would present to require
at
> >>>> least one of the
> >>>>
> >>>>
> >>> The primary problem with having a VLAN everywhere is that the root
> >>>
> > of
> >
> >>> the spanning tree moves around leading to non-optimal forwarding
in
> >>> enterprise networks. Enterprise networks are carefully engineered
> >>> networks and in the event of failure, they want to localize the
> >>> effects as much as possible. So, they want each VLAN to be
localized
> >>> and roots where they want it to be. Having a common VLAN messes up
> >>> that arrangement. Also, VLAN 1 is the default VLAN when a switch
> >>>
> > comes
> >
> >>> up and there is typically lots of customer data on it.
> >>>
> >>>> VLANs to *not* be partitioned. With TRILL, if a customer
eventually
> >>>> replaces
> >>>> all bridges, the customer will not be able to partition VLANs
> >>>>
> > anymore.
> >
> >>> As I raised it in the meeting, this is a side-effect that has not
> >>>
> > been
> >
> >>> considered before and needs to be carefully thought through. I
don't
> >>> think many people are aware of this issue with TRILL that doesn't
> >>> exist with 802.1Q bridges today.
> >>>
> >>>> Also, from
> >>>> what Anoop was explaining to me, the GVRP protocol would
> >>>>
> > automatically
> >
> >>>> configure the switch-to-switch links to join all the islands of
> >>>> VLANs. So it would
> >>>> seem as though it can't be that fatal to solving customer
problems
> >>>>
> > to
> >
> >>>> require
> >>>> *one* VLAN on a layer 2 cloud to not be partitioned.
> >>>>
> >>>>
> >>> GVRP is not deployed by a significant majority of customers.
> >>>
> >>> Dinesh
> >>>
> >>>
> >
> >




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 l72M3XD3001716 for <[e-mail]>; Thu, 2 Aug 2007 15:03:33 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 02 Aug 2007 15:03:33 -0700
X-IronPort-AV: i="4.19,215,1183359600";  d="scan'208"; a="16074932:sNHT20317710"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id A65A02383A1; Thu,  2 Aug 2007 15:03:33 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 2 Aug 2007 15:03:33 -0700
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, 2 Aug 2007 15:02:36 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags
Thread-Index: AcfTnxBPB6IinTA1Rn2EB0hT3jqOnwAGzGMgAAL1NjAAYo1GYAAAFyLA
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Radia Perlman" <[e-mail]>, "Dinesh G Dutt" <[e-mail]>
X-OriginalArrivalTime: 02 Aug 2007 22:03:33.0903 (UTC) FILETIME=[F80CB1F0:01C7D550]
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 l72M3XD3001716
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags
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, 02 Aug 2007 22:03:57 -0000
Status: RO
Content-Length: 5939

Silvano,

I don't think I ever suggested using GVRP to solve
our problem.  All I was saying is that the fact 
that something like GVRP exists, means that 
802.1Q wasn't designed to handle partitioned
VLANs as the norm.

Anoop 

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Thursday, August 02, 2007 3:00 PM
> To: Anoop Ghanwani; Radia Perlman; Dinesh G Dutt
> Cc: [e-mail]
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos 
> tagged withallthe VLAN tags
> 
> 
> Anoop,
> 
> Inline, 
> 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Tuesday, July 31, 2007 4:06 PM
> > To: Silvano Gai; Radia Perlman; Dinesh G Dutt
> > Cc: [e-mail]
> > Subject: RE: [rbridge] Avoiding sending multiple IS-IS 
> Hellos tagged 
> > withallthe VLAN tags
> > 
> > 
> > Hi Silvano,
> > 
> > Believe it or not there are customers out there that use 
> GVRP.  They 
> > might not be a majority, but they do exist.
> > 
> 
> You are making my point: "we cannot rely on GVRP to have a solution"
> 
> -- Silvano
> 
> > As far as I'm aware, it is _not_ very common
> > for customers to be reusing VLAN IDs within the
> > enterprise.  If they do reuse them, they are in
> > physically separate portions of the network that
> > are interconnected by routers.  That's the normal
> > tiered architecture that one tends to see in
> > enterprises.
> > 
> > I have never come across a customer that uses
> > partitioned VLANs the way you mention, so I find
> > it hard to believe they are common.  There's always
> > the oddball, strange architecture out there.
> > Do we really need to force everyone to send per-VLAN
> > hellos to deal with that?  We can always design to
> > make that type of configuration work, but we should
> > optimize for the common case.
> > 
> > Anoop
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Silvano Gai
> > > Sent: Tuesday, July 31, 2007 2:40 PM
> > > To: Radia Perlman; Dinesh G Dutt
> > > Cc: [e-mail]
> > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
> > > tagged withallthe VLAN tags
> > >
> > >
> > > Radia,
> > >
> > > We are describing to you how VLANs are deployed today in
> > > Enterprise networks. You may say that "you don't like it", we
> > > may agree with you, but this does not change how they are 
> deployed.
> > >
> > > For RBridges to be successful they need to be able to replace
> > > core bridges without messing up the existing network 
> configurations.
> > >
> > > Today most customers do not deploy VLANs end-to-end and they
> > > do reuse VLANs number in different part of the enterprise. If
> > > RBridges are not capable of supporting this, they are not
> attractive.
> > >
> > > Remember that the #1 customer requirement we have for TRILL
> > > is: "replace core bridges with RBridges to enable Equal Cost
> > > Multi Path, all the rest MUST remain the same".
> > >
> > > GVRP is not deployed; I am not sure which customers Anoop is
> > > referring to.
> > >
> > > -- Silvano
> > >
> > > > -----Original Message-----
> > > > From: Radia Perlman [mailto:[e-mail]]
> > > > Sent: Tuesday, July 31, 2007 11:19 AM
> > > > To: Dinesh G Dutt
> > > > Cc: Silvano Gai; [e-mail]
> > > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
> tagged
> > > with
> > > > allthe VLAN tags
> > > >
> > > > I don't understand that problem. What you're describing might
> argue
> > > for
> > > > bridges using a unique
> > > > spanning tree per VLAN in order to optimize traffic 
> flow for that
> > > VLAN,
> > > > but I don't
> > > > see what it has to do with wanting to partition VLANs.
> > > >
> > > > Radia
> > > >
> > > >
> > > > Dinesh G Dutt wrote:
> > > > > Radia Perlman wrote:
> > > > >> I'd like to understand what problem customers are 
> attempting to
> > > solve
> > > > >> with
> > > > >> partitioned VLANs, and what hardship it would present to
> > > require at
> > > > >> least one of the
> > > > >>
> > > > > The primary problem with having a VLAN everywhere is that the
> root
> > > of
> > > > > the spanning tree moves around leading to non-optimal
> > > forwarding in
> > > > > enterprise networks. Enterprise networks are carefully
> engineered
> > > > > networks and in the event of failure, they want to 
> localize the
> > > > > effects as much as possible. So, they want each VLAN to
> > > be localized
> > > > > and roots where they want it to be. Having a common VLAN
> > > messes up
> > > > > that arrangement. Also, VLAN 1 is the default VLAN 
> when a switch
> > > comes
> > > > > up and there is typically lots of customer data on it.
> > > > >> VLANs to *not* be partitioned. With TRILL, if a customer
> > > eventually
> > > > >> replaces all bridges, the customer will not be able to
> partition
> > > > >> VLANs
> > > anymore.
> > > > > As I raised it in the meeting, this is a side-effect that has
> not
> > > been
> > > > > considered before and needs to be carefully thought
> > > through. I don't
> > > > > think many people are aware of this issue with TRILL that
> doesn't
> > > > > exist with 802.1Q bridges today.
> > > > >> Also, from
> > > > >> what Anoop was explaining to me, the GVRP protocol would
> > > automatically
> > > > >> configure the switch-to-switch links to join all the 
> islands of
> > > > >> VLANs. So it would seem as though it can't be that fatal
> > > to solving
> > > > >> customer problems
> > > to
> > > > >> require
> > > > >> *one* VLAN on a layer 2 cloud to not be partitioned.
> > > > >>
> > > > > GVRP is not deployed by a significant majority of customers.
> > > > >
> > > > > Dinesh
> > > > >
> > >
> > >
> > > _______________________________________________
> > > rbridge mailing list
> > > [e-mail]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> 



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l72M0MFl029983 for <[e-mail]>; Thu, 2 Aug 2007 15:00:22 -0700 (PDT)
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, 2 Aug 2007 14:59:42 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags
Thread-Index: AcfTnxBPB6IinTA1Rn2EB0hT3jqOnwAGzGMgAAL1NjAAYo1GYA==
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Radia Perlman" <[e-mail]>, "Dinesh G Dutt" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l72M0MFl029983
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags
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, 02 Aug 2007 22:00:59 -0000
Status: RO
Content-Length: 5068

Anoop,

Inline, 

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Tuesday, July 31, 2007 4:06 PM
> To: Silvano Gai; Radia Perlman; Dinesh G Dutt
> Cc: [e-mail]
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> withallthe VLAN tags
> 
> 
> Hi Silvano,
> 
> Believe it or not there are customers out there that
> use GVRP.  They might not be a majority, but they
> do exist.
> 

You are making my point: "we cannot rely on GVRP to have a solution"

-- Silvano

> As far as I'm aware, it is _not_ very common
> for customers to be reusing VLAN IDs within the
> enterprise.  If they do reuse them, they are in
> physically separate portions of the network that
> are interconnected by routers.  That's the normal
> tiered architecture that one tends to see in
> enterprises.
> 
> I have never come across a customer that uses
> partitioned VLANs the way you mention, so I find
> it hard to believe they are common.  There's always
> the oddball, strange architecture out there.
> Do we really need to force everyone to send per-VLAN
> hellos to deal with that?  We can always design to
> make that type of configuration work, but we should
> optimize for the common case.
> 
> Anoop
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Silvano Gai
> > Sent: Tuesday, July 31, 2007 2:40 PM
> > To: Radia Perlman; Dinesh G Dutt
> > Cc: [e-mail]
> > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
> > tagged withallthe VLAN tags
> >
> >
> > Radia,
> >
> > We are describing to you how VLANs are deployed today in
> > Enterprise networks. You may say that "you don't like it", we
> > may agree with you, but this does not change how they are deployed.
> >
> > For RBridges to be successful they need to be able to replace
> > core bridges without messing up the existing network configurations.
> >
> > Today most customers do not deploy VLANs end-to-end and they
> > do reuse VLANs number in different part of the enterprise. If
> > RBridges are not capable of supporting this, they are not
attractive.
> >
> > Remember that the #1 customer requirement we have for TRILL
> > is: "replace core bridges with RBridges to enable Equal Cost
> > Multi Path, all the rest MUST remain the same".
> >
> > GVRP is not deployed; I am not sure which customers Anoop is
> > referring to.
> >
> > -- Silvano
> >
> > > -----Original Message-----
> > > From: Radia Perlman [mailto:[e-mail]]
> > > Sent: Tuesday, July 31, 2007 11:19 AM
> > > To: Dinesh G Dutt
> > > Cc: Silvano Gai; [e-mail]
> > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
tagged
> > with
> > > allthe VLAN tags
> > >
> > > I don't understand that problem. What you're describing might
argue
> > for
> > > bridges using a unique
> > > spanning tree per VLAN in order to optimize traffic flow for that
> > VLAN,
> > > but I don't
> > > see what it has to do with wanting to partition VLANs.
> > >
> > > Radia
> > >
> > >
> > > Dinesh G Dutt wrote:
> > > > Radia Perlman wrote:
> > > >> I'd like to understand what problem customers are attempting to
> > solve
> > > >> with
> > > >> partitioned VLANs, and what hardship it would present to
> > require at
> > > >> least one of the
> > > >>
> > > > The primary problem with having a VLAN everywhere is that the
root
> > of
> > > > the spanning tree moves around leading to non-optimal
> > forwarding in
> > > > enterprise networks. Enterprise networks are carefully
engineered
> > > > networks and in the event of failure, they want to localize the
> > > > effects as much as possible. So, they want each VLAN to
> > be localized
> > > > and roots where they want it to be. Having a common VLAN
> > messes up
> > > > that arrangement. Also, VLAN 1 is the default VLAN when a switch
> > comes
> > > > up and there is typically lots of customer data on it.
> > > >> VLANs to *not* be partitioned. With TRILL, if a customer
> > eventually
> > > >> replaces all bridges, the customer will not be able to
partition
> > > >> VLANs
> > anymore.
> > > > As I raised it in the meeting, this is a side-effect that has
not
> > been
> > > > considered before and needs to be carefully thought
> > through. I don't
> > > > think many people are aware of this issue with TRILL that
doesn't
> > > > exist with 802.1Q bridges today.
> > > >> Also, from
> > > >> what Anoop was explaining to me, the GVRP protocol would
> > automatically
> > > >> configure the switch-to-switch links to join all the islands of
> > > >> VLANs. So it would seem as though it can't be that fatal
> > to solving
> > > >> customer problems
> > to
> > > >> require
> > > >> *one* VLAN on a layer 2 cloud to not be partitioned.
> > > >>
> > > > GVRP is not deployed by a significant majority of customers.
> > > >
> > > > Dinesh
> > > >
> >
> >
> > _______________________________________________
> > 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 l71LakEV014379 for <[e-mail]>; Wed, 1 Aug 2007 14:36:46 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 01 Aug 2007 14:36:42 -0700 (PDT)
Received: from [129.150.16.21] ([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, 01 Aug 2007 14:36:42 -0700 (PDT)
Date: Wed, 01 Aug 2007 14:37:38 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Dinesh G Dutt <[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 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all	the VLAN tags
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, 01 Aug 2007 21:37:52 -0000
Status: RO
Content-Length: 8082

Dinesh,

I think you are right that there can be a temporary loop due to a 
partitioned VLAN 1.
And I think we can make it sufficiently unlikely to occur with a 
suggestion I'll make
after I explain the problem.

The temporary loop would be if R1 and R2, on the same layer 2 cloud, have
connectivity through VLAN A but not VLAN 1. So there would be two DRBs, on
both VLAN A and VLAN 1. There would be two pseudonodes, say R1.79 and R2.62,
and both would claim to be connected to both VLAN A and VLAN 1, and both
would claim the same root bridge, say 5134.

A multicast tagged with VLAN 1 would not be too much of a problem 
because anything
R1 decapsulates onto that VLAN-1-partitioned cloud would not make it through
the partitioned cloud to R2. But since we are not running the DRB 
election tagged
with VLAN A, R1 and R2 do not realize that they can talk via VLAN A.

Therefore, a VLAN A-tagged packet would get picked up by both R1 and R2,
and both would assume they are DRB.
Also, if R1 receives a (inner header) VLAN-A tagged frame
from the campus, R1 will decapsulate it onto the layer 2 cloud as a VLAN-A
tagged packet, and R2 will see it
and re-encapsulate it onto the campus, and R1 would see it again and 
decapsulate it, etc.

This loop will eventually be fixed when R1 sees the LSP from pseudonode  
R2.62 indicating
that the root bridge is 5134, since R1 will also think that the cloud 
that R1 is DRB for has
root bridge 5134.

So here's a possible fix:

R1 does not decapsulate a multidestination packet with ingress RBridge 
R2 unless R1
has an LSP from R2, and has LSPs from all pseudonodes that R2 claims (in 
R2's
LSP) to be DRB for. Note that I'm suggesting adding another flag in the 
neighbor
list in R2's LSP saying "not only am I attached to this pseudonode, but I am
DRB for it".

If R1 has all the pseudonode LSPs for which R2 is DRB, R1 can see if the 
root bridge
listed is the same as the one for the link on which R2 would like to 
decapsulate, and if it is,
then don't decapsulate.

We were already saying that if R1 notices that R2.79 has the same root 
bridge as
a link R1 wants to be DRB for that one of R1 or R2 would lose, based on 
a tie-breaker
based on ID, and stop forwarding traffic to/from the link. What I'm 
suggesting is that
you also don't forward multidestination traffic to/from a link if you 
don't yet have all
the associated LSP information from the ingress RBridge that can assure 
you there
isn't a common root bridge.

Radia




Dinesh G Dutt wrote:
> OK, based on emails from James Carlson and Radia, I went back and 
> thought about my reasons for objecting to the suggested proposal. I 
> also spoke to some field engineers to validate my understanding of 
> what I thought the issues were.
>
> There are two issues that we're dealing with here:
> - Simplifying DRB election to conduct it only on VLAN 1
> - Merging partitioned VLANs.
>
> I'd like to separate the two issues. Let me discuss only the first 
> issue, the simplified DRB election in this email. I'll send out a 
> separate email on the other issue.
>
> Assuming VLAN 1 exists everywhere is an acceptable alternative. I was 
> informed that even with STP, customers enable VLAN 1 and allow only 
> control traffic on it and not data traffic. If we have VLAN 1 present 
> as a common configuration, then running DRB only on VLAN 1 and 
> following Radia's proposal (or fixing it to work) seems acceptable, 
> except for one caveat.
>
> However, in the event of a misconfiguration and VLAN 1 not being 
> present, while the scheme proposed partitions the network and prevents 
> loops, it seems to me that there is a period during which temporary 
> loops can happen and duplicate frames are delivered by two DRBs. This 
> seems unacceptable to me from a customer point of view. If we can fix 
> this temporary loop (or someone can explain to me why there are no 
> temporary loops), I'd be willing to support this proposal.
>
> BTW, GVTP/MMRP or equivalent is very much not enabled in >80-90% of 
> customer networks and so we cannot assume or mandate their being there.
>
> Dinesh
> Radia Perlman wrote:
>> I had a conversation with Anoop, and he is (quite understandably)
>> uneasy about sending IS-IS Hellos tagged with every VLAN. So he
>> made the following suggestion, which I think makes sense.
>>
>> a) declare that bridges must be configured
>> so that VLAN 1 (default VLAN) must not be
>> partitioned on a layer 2 cloud. We will detect the misconfiguration
>> if it occurs (see d)) so that we at least do not have loops, but 
>> TRILL will not
>> stand on its head to support what will be declared a gross 
>> misconfiguration.
>>
>> b) Run the IS-IS election tagged with VLAN 1. Each RBridge has
>> the following information in its IS-IS Hello:
>>
>> . I am R1
>> . I hear Hellos from {R2, R3, R7, R11}
>> . If I am DRB, the pseudonode name will be R1.59
>> . My priority for the set of VLANs {A, D, W} is 7
>> . My priority for the set of VLANs {B, C, F, G, H} is 3
>>
>> c) If R1 becomes DRB for at least one of the VLANs on the cloud,
>> then R1 announces, in R1's LSP on behalf of pseudonode R1.59,
>> the ID of the root bridge on the primary spanning tree
>> instance for that layer 2 cloud, along with the set of VLANs for which
>> R1 is DRB on that cloud.
>>
>> Note: The current draft spec isn't clear what information R1 reports 
>> in the pseudonode
>> LSP and what it reports in its own LSP.
>> I'm suggesting reporting the bridge ID and
>> set of VLANs in the pseudonode LSP.
>>
>> d) If R2 thinks itself is DRB for VLAN A on a port with root bridge r11,
>> and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A
>> listed as one of the VLANs, this indicates that VLAN 1 on that layer
>> 2 cloud is partitioned. So one of R1 or R2 should stop forwarding
>> data to/from that cloud for VLAN A. Use ID as a tie breaker, so
>> if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding 
>> VLAN A
>> traffic to and from the port that has root bridge r11.
>> This is the behavior that will occur if VLAN 1 on that port is
>> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 
>> would
>> have seen each other's Hellos and not both think they are DRB for 
>> VLAN A (or
>> any other VLAN).
>>
>> e) This proposal supports multiple DRBs on a cloud for load splitting
>> based on VLANs, since the RBridges can have different priorities
>> for different VLANs. It still requires only sending one Hello, tagged
>> with VLAN 1. R2 should
>> not panic if R2 notices that R1.59 has the same root bridge as on
>> a port on which R2 is DRB, if R1.59's listed set of VLANs does not
>> include any VLANs for which R2 is DRB on the link with
>> that root bridge. If there is only partial overlap
>> of VLAN IDs, say the overlap is VLANs {D, F, and H},
>> then (the loser based on ID tie-breaker) will stop forwarding traffic
>> to/from that link that is tagged with VLANs D, F, or H.
>>
>> f) If some VLAN, say VLAN C, is actually partitioned, then the
>> result of this is that some VLAN C endnodes on that layer 2 cloud
>> will be orphaned. We will choose NOT to solve that.
>>
>>
>> The result of this proposal is that
>> RBridges will only need to send IS-IS Hellos tagged
>> with VLAN 1, and the only thing it does NOT solve (over
>> the current proposal of sending Hellos with every possible VLAN tag on
>> each port) is that sometimes endnodes might get orphaned if you have
>> a partitioned VLAN.
>>
>>
>> We *could* in that case, if someone *actually wanted* to have VLAN A
>> partitioned on that cloud, configure the RBridges on that layer 2
>> cloud to explicitly run a different election
>> for VLAN A (and note in the pseudonode LSP that VLAN A had
>> an explicit election tagged with VLAN A so that if there were
>> two DRBs they wouldn't panic). But I'd prefer not solving this case and
>> keeping it simpler (and safer).
>>
>> Radia
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>   
>



Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l71HhnZj018957 for <[e-mail]>; Wed, 1 Aug 2007 10:43:50 -0700 (PDT)
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 01 Aug 2007 10:43:49 -0700
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAIpisEarR7PD/2dsb2JhbAA
X-IronPort-AV: i="4.19,209,1183359600";  d="scan'208"; a="192576252:sNHT35679222"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l71HhnTG005083;  Wed, 1 Aug 2007 10:43:49 -0700
Received: from [171.71.49.94] (dhcp-171-71-49-94.cisco.com [171.71.49.94]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l71HhlA0011183; Wed, 1 Aug 2007 17:43:47 GMT
Message-ID: <[e-mail]>
Date: Wed, 01 Aug 2007 10:43:47 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.5 (X11/20070716)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5679; t=1185990229; x=1186854229; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Avoiding=20sending=20multiple=20IS-IS=20H ellos=20tagged=20with=0A=20all=09the=20VLAN=20tags |Sender:=20; bh=Y+5p+8W3NpOtA8VAdPfVBNb56UcM+K/FpA3r+nNzdL0=; b=MrPbVoa5+ECLBupOUsh5fcyQJefTNbddbjPsDTa1W/ZennYO+i6ANS9tgBLtwCr4FJcHsYK0 XyzcbWCIwQIEfPUj6cu7uHtqE/3UGVaRL1UyMVB6Nj05DWyxBdoleuBE;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all	the VLAN tags
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, 01 Aug 2007 17:44:43 -0000
Status: RO
Content-Length: 5558

OK, based on emails from James Carlson and Radia, I went back and 
thought about my reasons for objecting to the suggested proposal. I also 
spoke to some field engineers to validate my understanding of what I 
thought the issues were.

There are two issues that we're dealing with here:
- Simplifying DRB election to conduct it only on VLAN 1
- Merging partitioned VLANs.

I'd like to separate the two issues. Let me discuss only the first 
issue, the simplified DRB election in this email. I'll send out a 
separate email on the other issue.

Assuming VLAN 1 exists everywhere is an acceptable alternative. I was 
informed that even with STP, customers enable VLAN 1 and allow only 
control traffic on it and not data traffic. If we have VLAN 1 present as 
a common configuration, then running DRB only on VLAN 1 and following 
Radia's proposal (or fixing it to work) seems acceptable, except for one 
caveat.

However, in the event of a misconfiguration and VLAN 1 not being 
present, while the scheme proposed partitions the network and prevents 
loops, it seems to me that there is a period during which temporary 
loops can happen and duplicate frames are delivered by two DRBs. This 
seems unacceptable to me from a customer point of view. If we can fix 
this temporary loop (or someone can explain to me why there are no 
temporary loops), I'd be willing to support this proposal.

BTW, GVTP/MMRP or equivalent is very much not enabled in >80-90% of 
customer networks and so we cannot assume or mandate their being there.

Dinesh
Radia Perlman wrote:
> I had a conversation with Anoop, and he is (quite understandably)
> uneasy about sending IS-IS Hellos tagged with every VLAN. So he
> made the following suggestion, which I think makes sense.
>
> a) declare that bridges must be configured
> so that VLAN 1 (default VLAN) must not be
> partitioned on a layer 2 cloud. We will detect the misconfiguration
> if it occurs (see d)) so that we at least do not have loops, but TRILL 
> will not
> stand on its head to support what will be declared a gross misconfiguration.
>
> b) Run the IS-IS election tagged with VLAN 1. Each RBridge has
> the following information in its IS-IS Hello:
>
> . I am R1
> . I hear Hellos from {R2, R3, R7, R11}
> . If I am DRB, the pseudonode name will be R1.59
> . My priority for the set of VLANs {A, D, W} is 7
> . My priority for the set of VLANs {B, C, F, G, H} is 3
>
> c) If R1 becomes DRB for at least one of the VLANs on the cloud,
> then R1 announces, in R1's LSP on behalf of pseudonode R1.59,
> the ID of the root bridge on the primary spanning tree
> instance for that layer 2 cloud, along with the set of VLANs for which
> R1 is DRB on that cloud.
>
> Note: The current draft spec isn't clear what information R1 reports in 
> the pseudonode
> LSP and what it reports in its own LSP.
> I'm suggesting reporting the bridge ID and
> set of VLANs in the pseudonode LSP.
>
> d) If R2 thinks itself is DRB for VLAN A on a port with root bridge r11,
> and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A
> listed as one of the VLANs, this indicates that VLAN 1 on that layer
> 2 cloud is partitioned. So one of R1 or R2 should stop forwarding
> data to/from that cloud for VLAN A. Use ID as a tie breaker, so
> if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding VLAN A
> traffic to and from the port that has root bridge r11.
> This is the behavior that will occur if VLAN 1 on that port is
> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 would
> have seen each other's Hellos and not both think they are DRB for VLAN A (or
> any other VLAN).
>
> e) This proposal supports multiple DRBs on a cloud for load splitting
> based on VLANs, since the RBridges can have different priorities
> for different VLANs. It still requires only sending one Hello, tagged
> with VLAN 1. R2 should
> not panic if R2 notices that R1.59 has the same root bridge as on
> a port on which R2 is DRB, if R1.59's listed set of VLANs does not
> include any VLANs for which R2 is DRB on the link with
> that root bridge. If there is only partial overlap
> of VLAN IDs, say the overlap is VLANs {D, F, and H},
> then (the loser based on ID tie-breaker) will stop forwarding traffic
> to/from that link that is tagged with VLANs D, F, or H.
>
> f) If some VLAN, say VLAN C, is actually partitioned, then the
> result of this is that some VLAN C endnodes on that layer 2 cloud
> will be orphaned. We will choose NOT to solve that.
>
>
> The result of this proposal is that
> RBridges will only need to send IS-IS Hellos tagged
> with VLAN 1, and the only thing it does NOT solve (over
> the current proposal of sending Hellos with every possible VLAN tag on
> each port) is that sometimes endnodes might get orphaned if you have
> a partitioned VLAN.
>
>
> We *could* in that case, if someone *actually wanted* to have VLAN A
> partitioned on that cloud, configure the RBridges on that layer 2
> cloud to explicitly run a different election
> for VLAN A (and note in the pseudonode LSP that VLAN A had
> an explicit election tagged with VLAN A so that if there were
> two DRBs they wouldn't panic). But I'd prefer not solving this case and
> keeping it simpler (and safer).
>
> Radia
> _______________________________________________
> 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