[rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?

[Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)]

OK.

Well, based on the email with this subject, the working group seems
pretty happy with the solution where both TRILL encapsulated data and
TRILL IS-IS frames are indicated by the TRILL Ethertype and header with
one of the current two reserved bits used to distinguish these cases.

But, to allow for the possibility of learning end nodes via IS-IS, I
think we need to provide for a per VLAN TRILL IS-IS message. The
proposal seems to be that, if a Q-tag is present, then it is per VLAN,
otherwise it is a core TRILL IS-IS message.

So a per VLAN multicast TRILL IS-IS message would look like

Outer.DA - 6 bytes (All-Rbridges)
Outer.SA - 6 bytes (this hop SA)
TRILL-Ethertype - 2 bytes (tbd)
TRILL Header - 6 bytes (with "control message" and multi-destination
bits on)
Inner.DA - 6 bytes (All-Rbridges)
Inner.SA - 6 bytes (original SA)
Q-Ethertype - 2 bytes
Q-tag value - 2 bytes
Length - 2 bytes
IS-IS DSAP - 1 byte (0xFE)
IS-IS SSAP - 1 byte (0xFE)
CTL - 1 byte (0x03)
IS-IS payload - variable

A core TRILL IS-IS message would be the same but without the inner
Q-tag. (Also, for a core IS-IS message, the inner and outer SA would
always be the same.)

If the IS-IS message was unicast core, the outer and inner DA addresses
would be the unicast destination, there would be no inner Q-tag, and the
multi-destination bit would be off.

If the IS-IS message was unicast per VLAN, the outer DA would the "this
hop" DA, the inner DA would be the original DA, the Q-tab would be
present, and the multi-destination bit would be off.

In the TRILL header, for the per VLAN case, the Hop Count seems
meaningful. But the ingress and egress RBridge nicknames are not used
and, in fact, you need to send IS-IS Hellos before nicknames may have
been established. Basically, the TRILL data frame needs six addresses,
one pair each for the end stations, the ingress/egress Rbridges, and the
per hop Rbridges. But IS-IS control messages are only ever from one
Rbridge to another, so they only need four addresses in the per VLAN
case (and really only two addresses in the core case since they go only
one hop).

So it seems to me that the alternatives are to either
	(1) Leave the nickname fields unset or set to zero on
transmission and ignored on receipt or
	(2) Maybe add one of the reserved bits to the Version field and
re-name it "Variation" or something and have the 6 byte "Data" variation
as currently specified and the "IS-IS" variation which is just 2 bytes
because it does not have the nickname fields.

Thanks,
Donald

-----Original Message-----
From: Silvano Gai [mailto:sgai at nuovasystems.com] 
Sent: Wednesday, May 30, 2007 2:25 PM
To: Erik Nordmark
Cc: Radia Perlman; Eastlake III Donald-LDE008; Rbridge at postel.org
Subject: RE: [rbridge] How is an IS-IS packet differentiated from layer
3 IS-IS, and TRILL-encapsulated data packets?

Erik,

You are correct, I oversimplified the explanation, but the conclusion
still holds

-- Silvano

> -----Original Message-----
> From: Erik Nordmark [mailto:erik.nordmark at sun.com]
> Sent: Wednesday, May 30, 2007 11:02 AM
> To: Silvano Gai
> Cc: Radia Perlman; Eastlake III Donald-LDE008; Rbridge at postel.org
> Subject: Re: [rbridge] How is an IS-IS packet differentiated from
layer 3
> IS-IS, and TRILL-encapsulated data packets?
> 
> Silvano Gai wrote:
> 
> > The advantage of using a reserved bit is that the frame with
Ethertype =
> TRILL already go through DR blocked ports. The non-TRILL IS-IS frames
will
> have Ethertype = ISIS and will be dropped by DR blocked ports.
> 
> I don't know if this matters, but AFAIK (and after checking RFC 1142),
> there is no Ethertype for IS-IS. Instead IS-IS uses a 802.3 header
(i.e.
> a length field instead of an Ethertype field) followed by 3 bytes of
LLC
> header with the SAP 0xFE. Thus the 3 bytes after the length field is
03
> FE FE.
> 
>     Erik
> 




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 l4V2RDLN012183 for <[e-mail]>; Wed, 30 May 2007 19:27:13 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-14.tower-119.messagelabs.com!1180578432!22019545!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 27636 invoked from network); 31 May 2007 02:27:12 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with SMTP; 31 May 2007 02:27:12 -0000
Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4V2RBLm014301 for <[e-mail]>; Wed, 30 May 2007 19:27:11 -0700 (MST)
Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l4V2RA4o016286 for <[e-mail]>; Wed, 30 May 2007 21:27:11 -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 l4V2R96S016266 for <[e-mail]>; Wed, 30 May 2007 21:27:10 -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, 30 May 2007 22:25:31 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?
thread-index: Acei5NFuSBAvz1zmSiiKz+cpdkJSRwAAs+vQAAscLiA=
References: <[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 l4V2RDLN012183
Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?
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, 31 May 2007 02:27:37 -0000
Status: RO
Content-Length: 3848

OK.

Well, based on the email with this subject, the working group seems
pretty happy with the solution where both TRILL encapsulated data and
TRILL IS-IS frames are indicated by the TRILL Ethertype and header with
one of the current two reserved bits used to distinguish these cases.

But, to allow for the possibility of learning end nodes via IS-IS, I
think we need to provide for a per VLAN TRILL IS-IS message. The
proposal seems to be that, if a Q-tag is present, then it is per VLAN,
otherwise it is a core TRILL IS-IS message.

So a per VLAN multicast TRILL IS-IS message would look like

Outer.DA - 6 bytes (All-Rbridges)
Outer.SA - 6 bytes (this hop SA)
TRILL-Ethertype - 2 bytes (tbd)
TRILL Header - 6 bytes (with "control message" and multi-destination
bits on)
Inner.DA - 6 bytes (All-Rbridges)
Inner.SA - 6 bytes (original SA)
Q-Ethertype - 2 bytes
Q-tag value - 2 bytes
Length - 2 bytes
IS-IS DSAP - 1 byte (0xFE)
IS-IS SSAP - 1 byte (0xFE)
CTL - 1 byte (0x03)
IS-IS payload - variable

A core TRILL IS-IS message would be the same but without the inner
Q-tag. (Also, for a core IS-IS message, the inner and outer SA would
always be the same.)

If the IS-IS message was unicast core, the outer and inner DA addresses
would be the unicast destination, there would be no inner Q-tag, and the
multi-destination bit would be off.

If the IS-IS message was unicast per VLAN, the outer DA would the "this
hop" DA, the inner DA would be the original DA, the Q-tab would be
present, and the multi-destination bit would be off.

In the TRILL header, for the per VLAN case, the Hop Count seems
meaningful. But the ingress and egress RBridge nicknames are not used
and, in fact, you need to send IS-IS Hellos before nicknames may have
been established. Basically, the TRILL data frame needs six addresses,
one pair each for the end stations, the ingress/egress Rbridges, and the
per hop Rbridges. But IS-IS control messages are only ever from one
Rbridge to another, so they only need four addresses in the per VLAN
case (and really only two addresses in the core case since they go only
one hop).

So it seems to me that the alternatives are to either
	(1) Leave the nickname fields unset or set to zero on
transmission and ignored on receipt or
	(2) Maybe add one of the reserved bits to the Version field and
re-name it "Variation" or something and have the 6 byte "Data" variation
as currently specified and the "IS-IS" variation which is just 2 bytes
because it does not have the nickname fields.

Thanks,
Donald

-----Original Message-----
From: Silvano Gai [mailto:[e-mail]] 
Sent: Wednesday, May 30, 2007 2:25 PM
To: Erik Nordmark
Cc: Radia Perlman; Eastlake III Donald-LDE008; [e-mail]
Subject: RE: [rbridge] How is an IS-IS packet differentiated from layer
3 IS-IS, and TRILL-encapsulated data packets?

Erik,

You are correct, I oversimplified the explanation, but the conclusion
still holds

-- Silvano

> -----Original Message-----
> From: Erik Nordmark [mailto:[e-mail]]
> Sent: Wednesday, May 30, 2007 11:02 AM
> To: Silvano Gai
> Cc: Radia Perlman; Eastlake III Donald-LDE008; [e-mail]
> Subject: Re: [rbridge] How is an IS-IS packet differentiated from
layer 3
> IS-IS, and TRILL-encapsulated data packets?
> 
> Silvano Gai wrote:
> 
> > The advantage of using a reserved bit is that the frame with
Ethertype =
> TRILL already go through DR blocked ports. The non-TRILL IS-IS frames
will
> have Ethertype = ISIS and will be dropped by DR blocked ports.
> 
> I don't know if this matters, but AFAIK (and after checking RFC 1142),
> there is no Ethertype for IS-IS. Instead IS-IS uses a 802.3 header
(i.e.
> a length field instead of an Ethertype field) followed by 3 bytes of
LLC
> header with the SAP 0xFE. Thus the 3 bytes after the length field is
03
> FE FE.
> 
>     Erik
> 




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 l4UIP2xf004066 for <[e-mail]>; Wed, 30 May 2007 11:25:05 -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: Wed, 30 May 2007 11:24:54 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?
Thread-Index: Acei5NFuSBAvz1zmSiiKz+cpdkJSRwAAs+vQ
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Erik Nordmark" <[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 l4UIP2xf004066
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?
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, 30 May 2007 18:25:27 -0000
Status: RO
Content-Length: 1007

Erik,

You are correct, I oversimplified the explanation, but the conclusion
still holds

-- Silvano

> -----Original Message-----
> From: Erik Nordmark [mailto:[e-mail]]
> Sent: Wednesday, May 30, 2007 11:02 AM
> To: Silvano Gai
> Cc: Radia Perlman; Eastlake III Donald-LDE008; [e-mail]
> Subject: Re: [rbridge] How is an IS-IS packet differentiated from
layer 3
> IS-IS, and TRILL-encapsulated data packets?
> 
> Silvano Gai wrote:
> 
> > The advantage of using a reserved bit is that the frame with
Ethertype =
> TRILL already go through DR blocked ports. The non-TRILL IS-IS frames
will
> have Ethertype = ISIS and will be dropped by DR blocked ports.
> 
> I don't know if this matters, but AFAIK (and after checking RFC 1142),
> there is no Ethertype for IS-IS. Instead IS-IS uses a 802.3 header
(i.e.
> a length field instead of an Ethertype field) followed by 3 bytes of
LLC
> header with the SAP 0xFE. Thus the 3 bytes after the length field is
03
> FE FE.
> 
>     Erik
> 




Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l4UI1wFe020810 for <[e-mail]>; Wed, 30 May 2007 11:01:58 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.226.130]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4UI1vQJ025986; Wed, 30 May 2007 18:01:57 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 l4UI1qDM470123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 May 2007 11:01:53 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 30 May 2007 11:01:51 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 2.0b2 (X11/20070326)
MIME-Version: 1.0
To: Silvano Gai <[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
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] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?
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, 30 May 2007 18:02:24 -0000
Status: RO
Content-Length: 546

Silvano Gai wrote:

> The advantage of using a reserved bit is that the frame with Ethertype = TRILL already go through DR blocked ports. The non-TRILL IS-IS frames will have Ethertype = ISIS and will be dropped by DR blocked ports.

I don't know if this matters, but AFAIK (and after checking RFC 1142), 
there is no Ethertype for IS-IS. Instead IS-IS uses a 802.3 header (i.e. 
a length field instead of an Ethertype field) followed by 3 bytes of LLC 
header with the SAP 0xFE. Thus the 3 bytes after the length field is 03 
FE FE.

    Erik




Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l4MAOmgA004741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 22 May 2007 03:24:48 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l4MAP2RR016961; Tue, 22 May 2007 05:25:02 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 22 May 2007 05:24:46 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 22 May 2007 05:24:39 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Learning endnode locations (was something like "encoding IS-IS encapsulation")
Thread-Index: AcecK6xPI7KvDBpnQ8245541dmUW0QALQ75A
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 22 May 2007 10:24:46.0858 (UTC) FILETIME=[6BD756A0:01C79C5B]
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 l4MAOmgA004741
Cc: [e-mail]
Subject: Re: [rbridge] Learning endnode locations (was something like "encoding IS-IS encapsulation")
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, 22 May 2007 10:25:34 -0000
Status: RO
Content-Length: 3632

Radia,

	See in-line below...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]] 
> Sent: Tuesday, May 22, 2007 12:43 AM
> To: Eric Gray (LO/EUS)
> Cc: Silvano Gai; [e-mail]
> Subject: Re: [rbridge] Learning endnode locations (was 
> something like "encoding IS-IS encapsulation")
> Importance: High
> 
> A subtle difference:
> 
> Eric Gray (LO/EUS) wrote:
> > 	I would qualify this somewhat differently: I would say
> > "MUST be capable of MAC learning via data-frame examination
> > and MAY be configurable for learning from IS-IS advertisement
> > - either in addition to MAC learning, or in lieu of it.  The
> > default configuration is with MAC learning from data frames 
> > in operation (enabled)."
> >   
> The problem with being able to turn off learning from data 
> packets is if not all MAC addresses are advertised, then that
> RBridge will always flood those MAC addresses.

That would be why it would have to be a common configuration 
across devices deployed in a single campus.

Note that this would - in my suggested modification - have
required explicit configuration of devices to turn off the
capability.  That SHOULD only happen if a network operator
has reason to believe it will work.

> 
> How about that any MAC addresses learned through 
> advertisements always take precedence
> over any learned through data packets?

I really do have issues with trying to be clever like this.

If - as I suggested - it is desirable to not learn from the
data frames, why go through the motions?

My concern is that - the way Silvano and yourself have put
it prior to my suggestion - it would be arguable that an
implementation that is configurable not to learn from data
frames would be non-compliant.  And that is rediculous, of
course.

If you want the default behavior to be to learn from data
frames, then that is what you specify.  You don't say that
is what you MUST do, you simply say that that is the default
learning mode and it MUST be supported as such in compliant
implementations.

> 
> You said:
>  >>The reason I would characterize it this way is that it
>  >>MAY be the case that there are applications for which learning
>  >>from data frames MUST be disabled.
> 
> What kind of application would be really bad to learn from 
> data packets, or are you  talking about the security aspect
> of not letting a rogue endnode confuse RBridges about
> the location of a duly enrolled endnode, that authenticated 
> to an RBridge? 

You know, if I knew this I could probably retire.  But my
crystal ball is a little murky when it comes to trying to
figure out why people do the things they do.

The fact is that it is possible to turn off MAC learning in 
many 802.1D compliant bridges.  I see little point in being
more restrictive here than is the case generally with 802.1D
bridging.

> If the latter, then it seems like saying that if you learn
> the location of endnode E from IS-IS, you do not change your
> mind about where E is based on data packets should answer
> that concern, right?

Maybe.  But if you're planning to ignore what you might learn
from data frames, then why MUST you do that sort of learning?

You're right, this is a subtle difference, but you're in the
business of defining what makes a compliant implementation.  I
am merely stating that saying that implementations MUST do it
(as opposed to MUST support it as a default mode) is more than
you need to say in order to achieve interoperability - hence,
it is also more than you SHOULD specify for compliance.

> 
> 
> 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 l4M4gtLJ008016 for <[e-mail]>; Mon, 21 May 2007 21:42:55 -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, 21 May 2007 21:42:50 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.18.69]) 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, 21 May 2007 21:42:50 -0700 (PDT)
Date: Mon, 21 May 2007 21:43:23 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Eric Gray (LO/EUS)" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Learning endnode locations (was something like "encoding IS-IS encapsulation")
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, 22 May 2007 04:43:08 -0000
Status: RO
Content-Length: 1321

A subtle difference:

Eric Gray (LO/EUS) wrote:
> 	I would qualify this somewhat differently: I would say
> "MUST be capable of MAC learning via data-frame examination
> and MAY be configurable for learning from IS-IS advertisement
> - either in addition to MAC learning, or in lieu of it.  The
> default configuration is with MAC learning from data frames 
> in operation (enabled)."
>   
The problem with being able to turn off learning from data packets is if 
not all MAC addresses
are advertised, then that RBridge will always flood those MAC addresses.

How about that any MAC addresses learned through advertisements always 
take precedence
over any learned through data packets?

You said:
 >>The reason I would characterize it this way is that it
 >>MAY be the case that there are applications for which learning
 >>from data frames MUST be disabled.

What kind of application would be really bad to learn from data packets, 
or are you
talking about the security aspect of not letting a rogue endnode confuse 
RBridges about
the location of a duly enrolled endnode, that authenticated to an 
RBridge? If the latter,
then it seems like saying that if you learn the location of endnode E 
from IS-IS, you
do not change your mind about where E is based on data packets should answer
that concern, right?


Radia




Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l4M3WCSp019289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 21 May 2007 20:32:12 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l4M3WNkg007461; Mon, 21 May 2007 22:32:23 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 21 May 2007 22:32:08 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 21 May 2007 22:32:02 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Learning endnode locations (was something like "encoding IS-IS encapsulation")
Thread-Index: Acebz/JnT8VuknP9Q4CU4cFcamnKJgAHQnHgAAzyezA=
References: <[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 22 May 2007 03:32:08.0490 (UTC) FILETIME=[C6B430A0:01C79C21]
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 l4M3WCSp019289
Cc: [e-mail]
Subject: Re: [rbridge] Learning endnode locations (was something like "encoding IS-IS encapsulation")
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, 22 May 2007 03:32:40 -0000
Status: RO
Content-Length: 10792

Silvano,

	I would qualify this somewhat differently: I would say
"MUST be capable of MAC learning via data-frame examination
and MAY be configurable for learning from IS-IS advertisement
- either in addition to MAC learning, or in lieu of it.  The
default configuration is with MAC learning from data frames 
in operation (enabled)."

	The reason I would characterize it this way is that it
MAY be the case that there are applications for which learning
from data frames MUST be disabled.  Clearly this will not work
for bridges that only have this capability, but that would be
the choice a buyer makes...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Monday, May 21, 2007 5:16 PM
> To: Radia Perlman; Eric Gray (LO/EUS)
> Cc: [e-mail]
> Subject: RE: [rbridge] Learning endnode locations (was 
> something like "encoding IS-IS encapsulation")
> Importance: High
> 
> I am in favor of "RBridge MUST learn from data frame and MAY 
> learn from
> IS-IS". I propose to defer the "MAY learn from IS-IS" part to 
> a separate
> draft, when we have some implementation experience.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Radia Perlman
> > Sent: Monday, May 21, 2007 10:39 AM
> > To: Eric Gray (LO/EUS)
> > Cc: [e-mail]
> > Subject: [rbridge] Learning endnode locations (was something like
> > "encoding IS-IS encapsulation")
> > 
> > (Changing the subject line when answering Eric because Eric was
> > asking about something very different -- a major
> > change we've been assuming we
> > should be making and I want to make sure that the WG has a chance to
> > really understand what's going on and debate it). The 
> original subject
> > line
> > was about the bit twiddling encoding issue of whether we should use
> > a reserved bit, or a reserved nickname value, or whatever, 
> to signal,
> in
> > the TRILL
> > header, that the enclosed frame is a TRILL IS-IS frame. But 
> I'm again
> > reminding
> > people that we are proposing to change the preferred method of
> learning
> > endnodes
> > from explicit advertisement in IS-IS to learning from decapsulated
> data
> > packets.)
> > 
> > This issue really has nothing to do with VLANs, and so my 
> referring to
> it
> > as
> > "getting rid of the per-VLAN instance of IS-IS" is definitely
> confusing.
> > Sorry about that.
> > It was the per-VLAN instance of IS-IS link state packets in which
> > attached endnodes
> > were announced, which is why I was referring to the issue 
> as "getting
> > rid of the
> > per-VLAN instance of IS-IS".
> > 
> > So now that I've finished apologizing for confusing people, let me
> again
> > summarize
> > the pros and cons of how to learn endnode membership.
> > 
> > 1) if all RBridges advertise endnode membership with IS-IS, then it
> works
> > if
> > some RBridges learn from IS-IS and others learn from decapsulating
> data
> > packets
> > 2) if all RBridges learn from decapsulating data packets, then it
> works if
> > some RBridges choose to advertise some (or all) attached 
> endnodes with
> > IS-IS,
> > and some RBridges choose to listen to those advertisements.
> > 
> > What does not work is if some RBridges want to *only* learn 
> from IS-IS
> > advertisements,
> > and other RBridges do not advertise via IS-IS.
> > 
> > What are the arguments on each side?
> > 
> > a) IS-IS advertising takes bandwidth, but cuts down on unnecessary
> > flooding
> > b) learning from data is more scalable in terms of
> > memory at an RBridge because an RBridge RB1 only has to keep
> > track of the distant endnodes that are currently talking to endnodes
> on
> > RB1's links.
> > c) In some cases the Designated RBridge is very sure which endnodes
> are
> > attached,
> > because of an explicit layer 2 enrollment protocol, possibly even
> > cryptographically
> > authenticated. It is easier to secure this sort of 
> learning, since the
> > IS-IS announcement
> > can also be cryptographically authenticated, than receipt of a data
> > packet with
> > a given source address, since a rogue endnode can easily 
> send packets
> with
> > any source address
> > d) Learning from IS-IS has more of a "layer 3" flavor, so would be
> more
> > the
> > kind of thing layer 3 type people would design. Learning from data
> > packets has
> > more of a "layer 2" flavor. The only technical reason this is
> relevant,
> > I think, is
> > that some layer 3 devices may not be easily able to learn from the
> data
> > path.
> > e) Black holes might persist longer, if a distant RBridge, RB1 is
> confused
> > about the location of endnode E (perhaps because E moved). Which is
> why
> > I'd
> > like to also add an error message where the named egress 
> RBridge RB2)
> > can complain
> > to RB1 (which selected RB2 as egress for endnode E), that E is not
> > actually attached
> > to RB2, so RB1 should take (RB2, E) out of its cache.
> > f) The spec is simpler to understand, especially for "layer 2 type
> > people", if we
> > don't talk about the per-VLAN instance of endnode advertising.
> > 
> > My real opinion here is that either way is acceptable (learning from
> > IS-IS, or learning
> > from decapsulating data packets). Assuming we are making 
> learning from
> > data MUST,
> > then I'd like to also keep advertising endnodes via IS-IS a MAY, and
> > have it used for
> > definitively enrolled endnodes. And I'd like to add a "I'm not the
> right
> > egress RBridge for E"
> > message.
> > 
> > But what I don't want is to lose months agonizing over this 
> decision.
> We
> > should pick
> > one way and go with it. (where "one way" is which learning 
> method is a
> > MUST). It would
> > be great if there were some researchers who could give us some real
> > quantitative method
> > for making this decision. But beyond that, I'd go with whatever is
> most
> > convenient for
> > the people who are actually going to implement this.
> > 
> > So...now's the time to speak up.
> > 
> > Radia
> > 
> > 
> > 
> > 
> > Eric Gray (LO/EUS) wrote:
> > > Radia,
> > >
> > > 	I am not sure how you would specify behaviors that are based
> > > on the assumption that RBridges are specified for a single VLAN -
> > > with separate RBridge instances being used for separate VLANs - if
> > > (as you suggest) there are not separate IS-IS instances per-VLAN.
> > >
> > > 	How does that work?
> > >
> > > Thanks!
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >
> > >
> > >> -----Original Message-----
> > >> From: [e-mail]
> > >> [mailto:[e-mail]] On Behalf Of Radia Perlman
> > >> Sent: Saturday, May 19, 2007 12:08 AM
> > >> To: [e-mail]
> > >> Subject: [rbridge] How is an IS-IS packet differentiated from
> > >> layer 3 IS-IS, and TRILL-encapsulated data packets?
> > >>
> > >> Now that I'm editing the spec to be real specific here, I
> > >> need a sanity
> > >> check, or
> > >> advice from implementers about what would be most convenient for
> them.
> > >>
> > >> My assumption is that we are removing the per-VLAN instance of
> IS-IS
> > >> (which could
> > >> be added later on, for the purpose of distributing endnode
> > >> information
> > >> that is more
> > >> securely learned, say through a cryptographically
> > >> authenticated layer 2
> > >> enrollment
> > >> protocol). But we are requiring RBridges to learn 
> (ingress RBridge,
> > >> source MAC address)
> > >> from packets they are decapsulating onto their link.
> > >>
> > >> So we just have the core instance of IS-IS. We have to make
> > >> sure layer 3
> > >> IS-IS
> > >> packets (which might also be flowing across the campus
> > >> between routers)
> > >> don't
> > >> get confused with TRILL IS-IS. We also have to have 
> RBridges easily
> > >> distinguish
> > >> TRILL IS-IS Hellos and LSPs from ordinary encapsulated data
> packets.
> > >>
> > >> When a router generates an IS-IS packet, the destination
> > >> address will be
> > >> "all-level1-routers"
> > >> or "all-level-2 routers", or perhaps, a specific router (for
> > >> instance,
> > >> to send a PSNP).
> > >> The way this is recognized as an IS-IS packet is due to the
> > >> EThertype=IS-IS.
> > >>
> > >> RBridge, I believe, should not treat IS-IS packets
> > >> differently from any
> > >> other "data"
> > >> packets. If it's addressed to "all-level1-routers" or
> > >> "all-level2-routers" it would be
> > >> treated like any other multidestination packet, encapsulated,
> > >> and sent
> > >> along a distribution
> > >> tree. If it's unicast, it is treated like any other 
> unicast packet
> by
> > >> RBridges, assuming
> > >> the layer 2 address specified in the destination is known to
> > >> the ingress
> > >> RBridge.
> > >>
> > >> The question is---how are TRILL IS-IS packets encoded?
> > >>
> > >> Could we get a second Ethertype for this? I'm assuming not...
> > >>
> > >> I'm assuming we just have a single Ethertype for
> > >> "TRILL-encapsulated".
> > >> So we have
> > >> to use that.
> > >>
> > >> We could use a different multicast destination address for
> > >> "all-RBridges-for-IS-IS" vs
> > >> "all-RBridges" that is used for multicast data.
> > >>
> > >> Or we could have a bit in the TRILL header saying "this is an
> > >> IS-IS packet".
> > >>
> > >> We could in theory not use the TRILL header for IS-IS
> > >> packets, since in
> > >> theory
> > >> IS-IS does not need to be encapsulated (for layer 3 IS-IS it runs
> > >> directly over layer 2).
> > >> But then we'd need a separate Ethertype.
> > >>
> > >> So...if we are going to use the TRILL header, then how do we not
> get
> > >> confused
> > >> between TRILL IS-IS and layer 3 IS-IS?
> > >>
> > >> I guess we could assume that it's enough to have TRILL IS-IS
> > >> use "0" as
> > >> the area
> > >> address, and use IS-IS as the Ethertype in the inner header. For
> > >> TRILL-encapsulated
> > >> packets, we actually could choose some weirdo Ethertype (like
> > >> 0) in the
> > >> inner header.
> > >> But we still need to differentiate TRILL IS-IS from layer 3
> > >> IS-IS on the
> > >> first hop.
> > >>
> > >> This is probably something I should ask the IS-IS WG, since it
> really
> > >> depends on
> > >> idiosyncracies of the current IS-IS implementations.
> > >>
> > >> 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 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 l4LLGWu9002320 for <[e-mail]>; Mon, 21 May 2007 14:16: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, 21 May 2007 14:16:29 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Learning endnode locations (was something like "encoding IS-IS encapsulation")
Thread-Index: Acebz/JnT8VuknP9Q4CU4cFcamnKJgAHQnHg
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Eric Gray \(LO/EUS\)" <[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 l4LLGWu9002320
Cc: [e-mail]
Subject: Re: [rbridge] Learning endnode locations (was something like "encoding IS-IS encapsulation")
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, 21 May 2007 21:17:11 -0000
Status: RO
Content-Length: 9192

I am in favor of "RBridge MUST learn from data frame and MAY learn from
IS-IS". I propose to defer the "MAY learn from IS-IS" part to a separate
draft, when we have some implementation experience.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Radia Perlman
> Sent: Monday, May 21, 2007 10:39 AM
> To: Eric Gray (LO/EUS)
> Cc: [e-mail]
> Subject: [rbridge] Learning endnode locations (was something like
> "encoding IS-IS encapsulation")
> 
> (Changing the subject line when answering Eric because Eric was
> asking about something very different -- a major
> change we've been assuming we
> should be making and I want to make sure that the WG has a chance to
> really understand what's going on and debate it). The original subject
> line
> was about the bit twiddling encoding issue of whether we should use
> a reserved bit, or a reserved nickname value, or whatever, to signal,
in
> the TRILL
> header, that the enclosed frame is a TRILL IS-IS frame. But I'm again
> reminding
> people that we are proposing to change the preferred method of
learning
> endnodes
> from explicit advertisement in IS-IS to learning from decapsulated
data
> packets.)
> 
> This issue really has nothing to do with VLANs, and so my referring to
it
> as
> "getting rid of the per-VLAN instance of IS-IS" is definitely
confusing.
> Sorry about that.
> It was the per-VLAN instance of IS-IS link state packets in which
> attached endnodes
> were announced, which is why I was referring to the issue as "getting
> rid of the
> per-VLAN instance of IS-IS".
> 
> So now that I've finished apologizing for confusing people, let me
again
> summarize
> the pros and cons of how to learn endnode membership.
> 
> 1) if all RBridges advertise endnode membership with IS-IS, then it
works
> if
> some RBridges learn from IS-IS and others learn from decapsulating
data
> packets
> 2) if all RBridges learn from decapsulating data packets, then it
works if
> some RBridges choose to advertise some (or all) attached endnodes with
> IS-IS,
> and some RBridges choose to listen to those advertisements.
> 
> What does not work is if some RBridges want to *only* learn from IS-IS
> advertisements,
> and other RBridges do not advertise via IS-IS.
> 
> What are the arguments on each side?
> 
> a) IS-IS advertising takes bandwidth, but cuts down on unnecessary
> flooding
> b) learning from data is more scalable in terms of
> memory at an RBridge because an RBridge RB1 only has to keep
> track of the distant endnodes that are currently talking to endnodes
on
> RB1's links.
> c) In some cases the Designated RBridge is very sure which endnodes
are
> attached,
> because of an explicit layer 2 enrollment protocol, possibly even
> cryptographically
> authenticated. It is easier to secure this sort of learning, since the
> IS-IS announcement
> can also be cryptographically authenticated, than receipt of a data
> packet with
> a given source address, since a rogue endnode can easily send packets
with
> any source address
> d) Learning from IS-IS has more of a "layer 3" flavor, so would be
more
> the
> kind of thing layer 3 type people would design. Learning from data
> packets has
> more of a "layer 2" flavor. The only technical reason this is
relevant,
> I think, is
> that some layer 3 devices may not be easily able to learn from the
data
> path.
> e) Black holes might persist longer, if a distant RBridge, RB1 is
confused
> about the location of endnode E (perhaps because E moved). Which is
why
> I'd
> like to also add an error message where the named egress RBridge RB2)
> can complain
> to RB1 (which selected RB2 as egress for endnode E), that E is not
> actually attached
> to RB2, so RB1 should take (RB2, E) out of its cache.
> f) The spec is simpler to understand, especially for "layer 2 type
> people", if we
> don't talk about the per-VLAN instance of endnode advertising.
> 
> My real opinion here is that either way is acceptable (learning from
> IS-IS, or learning
> from decapsulating data packets). Assuming we are making learning from
> data MUST,
> then I'd like to also keep advertising endnodes via IS-IS a MAY, and
> have it used for
> definitively enrolled endnodes. And I'd like to add a "I'm not the
right
> egress RBridge for E"
> message.
> 
> But what I don't want is to lose months agonizing over this decision.
We
> should pick
> one way and go with it. (where "one way" is which learning method is a
> MUST). It would
> be great if there were some researchers who could give us some real
> quantitative method
> for making this decision. But beyond that, I'd go with whatever is
most
> convenient for
> the people who are actually going to implement this.
> 
> So...now's the time to speak up.
> 
> Radia
> 
> 
> 
> 
> Eric Gray (LO/EUS) wrote:
> > Radia,
> >
> > 	I am not sure how you would specify behaviors that are based
> > on the assumption that RBridges are specified for a single VLAN -
> > with separate RBridge instances being used for separate VLANs - if
> > (as you suggest) there are not separate IS-IS instances per-VLAN.
> >
> > 	How does that work?
> >
> > Thanks!
> >
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> >
> >
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of Radia Perlman
> >> Sent: Saturday, May 19, 2007 12:08 AM
> >> To: [e-mail]
> >> Subject: [rbridge] How is an IS-IS packet differentiated from
> >> layer 3 IS-IS, and TRILL-encapsulated data packets?
> >>
> >> Now that I'm editing the spec to be real specific here, I
> >> need a sanity
> >> check, or
> >> advice from implementers about what would be most convenient for
them.
> >>
> >> My assumption is that we are removing the per-VLAN instance of
IS-IS
> >> (which could
> >> be added later on, for the purpose of distributing endnode
> >> information
> >> that is more
> >> securely learned, say through a cryptographically
> >> authenticated layer 2
> >> enrollment
> >> protocol). But we are requiring RBridges to learn (ingress RBridge,
> >> source MAC address)
> >> from packets they are decapsulating onto their link.
> >>
> >> So we just have the core instance of IS-IS. We have to make
> >> sure layer 3
> >> IS-IS
> >> packets (which might also be flowing across the campus
> >> between routers)
> >> don't
> >> get confused with TRILL IS-IS. We also have to have RBridges easily
> >> distinguish
> >> TRILL IS-IS Hellos and LSPs from ordinary encapsulated data
packets.
> >>
> >> When a router generates an IS-IS packet, the destination
> >> address will be
> >> "all-level1-routers"
> >> or "all-level-2 routers", or perhaps, a specific router (for
> >> instance,
> >> to send a PSNP).
> >> The way this is recognized as an IS-IS packet is due to the
> >> EThertype=IS-IS.
> >>
> >> RBridge, I believe, should not treat IS-IS packets
> >> differently from any
> >> other "data"
> >> packets. If it's addressed to "all-level1-routers" or
> >> "all-level2-routers" it would be
> >> treated like any other multidestination packet, encapsulated,
> >> and sent
> >> along a distribution
> >> tree. If it's unicast, it is treated like any other unicast packet
by
> >> RBridges, assuming
> >> the layer 2 address specified in the destination is known to
> >> the ingress
> >> RBridge.
> >>
> >> The question is---how are TRILL IS-IS packets encoded?
> >>
> >> Could we get a second Ethertype for this? I'm assuming not...
> >>
> >> I'm assuming we just have a single Ethertype for
> >> "TRILL-encapsulated".
> >> So we have
> >> to use that.
> >>
> >> We could use a different multicast destination address for
> >> "all-RBridges-for-IS-IS" vs
> >> "all-RBridges" that is used for multicast data.
> >>
> >> Or we could have a bit in the TRILL header saying "this is an
> >> IS-IS packet".
> >>
> >> We could in theory not use the TRILL header for IS-IS
> >> packets, since in
> >> theory
> >> IS-IS does not need to be encapsulated (for layer 3 IS-IS it runs
> >> directly over layer 2).
> >> But then we'd need a separate Ethertype.
> >>
> >> So...if we are going to use the TRILL header, then how do we not
get
> >> confused
> >> between TRILL IS-IS and layer 3 IS-IS?
> >>
> >> I guess we could assume that it's enough to have TRILL IS-IS
> >> use "0" as
> >> the area
> >> address, and use IS-IS as the Ethertype in the inner header. For
> >> TRILL-encapsulated
> >> packets, we actually could choose some weirdo Ethertype (like
> >> 0) in the
> >> inner header.
> >> But we still need to differentiate TRILL IS-IS from layer 3
> >> IS-IS on the
> >> first hop.
> >>
> >> This is probably something I should ask the IS-IS WG, since it
really
> >> depends on
> >> idiosyncracies of the current IS-IS implementations.
> >>
> >> 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 l4LHcnPh029535 for <[e-mail]>; Mon, 21 May 2007 10:38:49 -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, 21 May 2007 10:38:35 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.16.160]) 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, 21 May 2007 10:38:35 -0700 (PDT)
Date: Mon, 21 May 2007 10:39:07 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Eric Gray (LO/EUS)" <[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.10 (Windows/20070221)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: [rbridge] Learning endnode locations (was something like "encoding IS-IS encapsulation")
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, 21 May 2007 17:39:30 -0000
Status: RO
Content-Length: 8110

(Changing the subject line when answering Eric because Eric was
asking about something very different -- a major
change we've been assuming we
should be making and I want to make sure that the WG has a chance to
really understand what's going on and debate it). The original subject line
was about the bit twiddling encoding issue of whether we should use
a reserved bit, or a reserved nickname value, or whatever, to signal, in 
the TRILL
header, that the enclosed frame is a TRILL IS-IS frame. But I'm again 
reminding
people that we are proposing to change the preferred method of learning 
endnodes
from explicit advertisement in IS-IS to learning from decapsulated data 
packets.)

This issue really has nothing to do with VLANs, and so my referring to it as
"getting rid of the per-VLAN instance of IS-IS" is definitely confusing. 
Sorry about that.
It was the per-VLAN instance of IS-IS link state packets in which 
attached endnodes
were announced, which is why I was referring to the issue as "getting 
rid of the
per-VLAN instance of IS-IS".

So now that I've finished apologizing for confusing people, let me again 
summarize
the pros and cons of how to learn endnode membership.

1) if all RBridges advertise endnode membership with IS-IS, then it works if
some RBridges learn from IS-IS and others learn from decapsulating data 
packets
2) if all RBridges learn from decapsulating data packets, then it works if
some RBridges choose to advertise some (or all) attached endnodes with 
IS-IS,
and some RBridges choose to listen to those advertisements.

What does not work is if some RBridges want to *only* learn from IS-IS 
advertisements,
and other RBridges do not advertise via IS-IS.

What are the arguments on each side?

a) IS-IS advertising takes bandwidth, but cuts down on unnecessary flooding
b) learning from data is more scalable in terms of
memory at an RBridge because an RBridge RB1 only has to keep
track of the distant endnodes that are currently talking to endnodes on 
RB1's links.
c) In some cases the Designated RBridge is very sure which endnodes are 
attached,
because of an explicit layer 2 enrollment protocol, possibly even 
cryptographically
authenticated. It is easier to secure this sort of learning, since the 
IS-IS announcement
can also be cryptographically authenticated, than receipt of a data 
packet with
a given source address, since a rogue endnode can easily send packets with
any source address
d) Learning from IS-IS has more of a "layer 3" flavor, so would be more the
kind of thing layer 3 type people would design. Learning from data 
packets has
more of a "layer 2" flavor. The only technical reason this is relevant, 
I think, is
that some layer 3 devices may not be easily able to learn from the data 
path.
e) Black holes might persist longer, if a distant RBridge, RB1 is confused
about the location of endnode E (perhaps because E moved). Which is why I'd
like to also add an error message where the named egress RBridge RB2) 
can complain
to RB1 (which selected RB2 as egress for endnode E), that E is not 
actually attached
to RB2, so RB1 should take (RB2, E) out of its cache.
f) The spec is simpler to understand, especially for "layer 2 type 
people", if we
don't talk about the per-VLAN instance of endnode advertising.

My real opinion here is that either way is acceptable (learning from 
IS-IS, or learning
from decapsulating data packets). Assuming we are making learning from 
data MUST,
then I'd like to also keep advertising endnodes via IS-IS a MAY, and 
have it used for
definitively enrolled endnodes. And I'd like to add a "I'm not the right 
egress RBridge for E"
message.

But what I don't want is to lose months agonizing over this decision. We 
should pick
one way and go with it. (where "one way" is which learning method is a 
MUST). It would
be great if there were some researchers who could give us some real 
quantitative method
for making this decision. But beyond that, I'd go with whatever is most 
convenient for
the people who are actually going to implement this.

So...now's the time to speak up.

Radia




Eric Gray (LO/EUS) wrote:
> Radia,
>
> 	I am not sure how you would specify behaviors that are based
> on the assumption that RBridges are specified for a single VLAN -
> with separate RBridge instances being used for separate VLANs - if
> (as you suggest) there are not separate IS-IS instances per-VLAN.
>
> 	How does that work?
>
> Thanks!
>
> --
> Eric Gray
> Principal Engineer
> Ericsson  
>
>   
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Radia Perlman
>> Sent: Saturday, May 19, 2007 12:08 AM
>> To: [e-mail]
>> Subject: [rbridge] How is an IS-IS packet differentiated from 
>> layer 3 IS-IS, and TRILL-encapsulated data packets?
>>
>> Now that I'm editing the spec to be real specific here, I 
>> need a sanity 
>> check, or
>> advice from implementers about what would be most convenient for them.
>>
>> My assumption is that we are removing the per-VLAN instance of IS-IS 
>> (which could
>> be added later on, for the purpose of distributing endnode 
>> information 
>> that is more
>> securely learned, say through a cryptographically 
>> authenticated layer 2 
>> enrollment
>> protocol). But we are requiring RBridges to learn (ingress RBridge, 
>> source MAC address)
>> from packets they are decapsulating onto their link.
>>
>> So we just have the core instance of IS-IS. We have to make 
>> sure layer 3 
>> IS-IS
>> packets (which might also be flowing across the campus 
>> between routers) 
>> don't
>> get confused with TRILL IS-IS. We also have to have RBridges easily 
>> distinguish
>> TRILL IS-IS Hellos and LSPs from ordinary encapsulated data packets.
>>
>> When a router generates an IS-IS packet, the destination 
>> address will be 
>> "all-level1-routers"
>> or "all-level-2 routers", or perhaps, a specific router (for 
>> instance, 
>> to send a PSNP).
>> The way this is recognized as an IS-IS packet is due to the 
>> EThertype=IS-IS.
>>
>> RBridge, I believe, should not treat IS-IS packets 
>> differently from any 
>> other "data"
>> packets. If it's addressed to "all-level1-routers" or 
>> "all-level2-routers" it would be
>> treated like any other multidestination packet, encapsulated, 
>> and sent 
>> along a distribution
>> tree. If it's unicast, it is treated like any other unicast packet by 
>> RBridges, assuming
>> the layer 2 address specified in the destination is known to 
>> the ingress 
>> RBridge.
>>
>> The question is---how are TRILL IS-IS packets encoded?
>>
>> Could we get a second Ethertype for this? I'm assuming not...
>>
>> I'm assuming we just have a single Ethertype for 
>> "TRILL-encapsulated". 
>> So we have
>> to use that.
>>
>> We could use a different multicast destination address for 
>> "all-RBridges-for-IS-IS" vs
>> "all-RBridges" that is used for multicast data.
>>
>> Or we could have a bit in the TRILL header saying "this is an 
>> IS-IS packet".
>>
>> We could in theory not use the TRILL header for IS-IS 
>> packets, since in 
>> theory
>> IS-IS does not need to be encapsulated (for layer 3 IS-IS it runs 
>> directly over layer 2).
>> But then we'd need a separate Ethertype.
>>
>> So...if we are going to use the TRILL header, then how do we not get 
>> confused
>> between TRILL IS-IS and layer 3 IS-IS?
>>
>> I guess we could assume that it's enough to have TRILL IS-IS 
>> use "0" as 
>> the area
>> address, and use IS-IS as the Ethertype in the inner header. For 
>> TRILL-encapsulated
>> packets, we actually could choose some weirdo Ethertype (like 
>> 0) in the 
>> inner header.
>> But we still need to differentiate TRILL IS-IS from layer 3 
>> IS-IS on the 
>> first hop.
>>
>> This is probably something I should ask the IS-IS WG, since it really 
>> depends on
>> idiosyncracies of the current IS-IS implementations.
>>
>> Radia
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>     



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l4LAMaku029614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 21 May 2007 03:22:36 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l4LAOLpi028252; Mon, 21 May 2007 05:24:22 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 21 May 2007 05:22:35 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 21 May 2007 05:22:30 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?
Thread-Index: AceZzFWRdouBYO95StyHzc6sm2WWDwBxJh8g
References: <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 21 May 2007 10:22:35.0178 (UTC) FILETIME=[F2F0D0A0:01C79B91]
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 l4LAMaku029614
Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?
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, 21 May 2007 10:23:12 -0000
Status: RO
Content-Length: 3850

Radia,

	I am not sure how you would specify behaviors that are based
on the assumption that RBridges are specified for a single VLAN -
with separate RBridge instances being used for separate VLANs - if
(as you suggest) there are not separate IS-IS instances per-VLAN.

	How does that work?

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Radia Perlman
> Sent: Saturday, May 19, 2007 12:08 AM
> To: [e-mail]
> Subject: [rbridge] How is an IS-IS packet differentiated from 
> layer 3 IS-IS, and TRILL-encapsulated data packets?
> 
> Now that I'm editing the spec to be real specific here, I 
> need a sanity 
> check, or
> advice from implementers about what would be most convenient for them.
> 
> My assumption is that we are removing the per-VLAN instance of IS-IS 
> (which could
> be added later on, for the purpose of distributing endnode 
> information 
> that is more
> securely learned, say through a cryptographically 
> authenticated layer 2 
> enrollment
> protocol). But we are requiring RBridges to learn (ingress RBridge, 
> source MAC address)
> from packets they are decapsulating onto their link.
> 
> So we just have the core instance of IS-IS. We have to make 
> sure layer 3 
> IS-IS
> packets (which might also be flowing across the campus 
> between routers) 
> don't
> get confused with TRILL IS-IS. We also have to have RBridges easily 
> distinguish
> TRILL IS-IS Hellos and LSPs from ordinary encapsulated data packets.
> 
> When a router generates an IS-IS packet, the destination 
> address will be 
> "all-level1-routers"
> or "all-level-2 routers", or perhaps, a specific router (for 
> instance, 
> to send a PSNP).
> The way this is recognized as an IS-IS packet is due to the 
> EThertype=IS-IS.
> 
> RBridge, I believe, should not treat IS-IS packets 
> differently from any 
> other "data"
> packets. If it's addressed to "all-level1-routers" or 
> "all-level2-routers" it would be
> treated like any other multidestination packet, encapsulated, 
> and sent 
> along a distribution
> tree. If it's unicast, it is treated like any other unicast packet by 
> RBridges, assuming
> the layer 2 address specified in the destination is known to 
> the ingress 
> RBridge.
> 
> The question is---how are TRILL IS-IS packets encoded?
> 
> Could we get a second Ethertype for this? I'm assuming not...
> 
> I'm assuming we just have a single Ethertype for 
> "TRILL-encapsulated". 
> So we have
> to use that.
> 
> We could use a different multicast destination address for 
> "all-RBridges-for-IS-IS" vs
> "all-RBridges" that is used for multicast data.
> 
> Or we could have a bit in the TRILL header saying "this is an 
> IS-IS packet".
> 
> We could in theory not use the TRILL header for IS-IS 
> packets, since in 
> theory
> IS-IS does not need to be encapsulated (for layer 3 IS-IS it runs 
> directly over layer 2).
> But then we'd need a separate Ethertype.
> 
> So...if we are going to use the TRILL header, then how do we not get 
> confused
> between TRILL IS-IS and layer 3 IS-IS?
> 
> I guess we could assume that it's enough to have TRILL IS-IS 
> use "0" as 
> the area
> address, and use IS-IS as the Ethertype in the inner header. For 
> TRILL-encapsulated
> packets, we actually could choose some weirdo Ethertype (like 
> 0) in the 
> inner header.
> But we still need to differentiate TRILL IS-IS from layer 3 
> IS-IS on the 
> first hop.
> 
> This is probably something I should ask the IS-IS WG, since it really 
> depends on
> idiosyncracies of the current IS-IS implementations.
> 
> 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 l4KG4a7c005926 for <[e-mail]>; Sun, 20 May 2007 09:04:36 -0700 (PDT)
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_01C79AF8.B6E4687D"
Date: Sun, 20 May 2007 09:05:41 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?
Thread-Index: AceapqV8sgiku+7xSZqSXXLlx0sSTgASTepV
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "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] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?
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, 20 May 2007 16:04:45 -0000
Status: RO
Content-Length: 24847

This is a multi-part message in MIME format.

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

Radia, Donald,
=20
from an implementation perspective the less fields you have to test, the =
easier it is.=20
=20
The main problem is to be able to determine in HW, at the port level, if =
a frame must be forwarded, dropped or redirected to the RBridge CPU.
=20
In bridges it is very easy, BPDUs have a reserved MAC address, bridge =
ports have few registers that can be loaded with MAC addresses that =
allows frame to go through blocked port (remember that BPDUs MUST be =
received even if the port is blocked).
=20
In RBridges a port may be DR blocked. On a DR blocked port we must still =
receive BPDUs, RBridge IS-IS frames and TRILL encapsulated frames, but =
we must drop data frames including IS-IS frames used by non-TRILL =
protocols.
=20
Distinguishing IS-IS used for TRILL from IS-IS used for other protocols =
is the tricky part.
=20
Donald suggest using a reserved MAC addess, that would be ideal from an =
implementation perspective, but Radia replies that a PSNP (partial =
sequence number PDU) may be unicast.
=20
If a MAC address does not work, the next field is the Ethertype. We =
already know that we will have a pushback in having two Ethertypes for =
TRILL, so Radia suggests using a single Ethertype and extending it with =
a rreserved bit. This can be done, as it is also possible to use version =
0 for IS-IS and version 1 for TRILL.
=20
I am against redefining the meaning of nicknames or of other fields, =
since it makes the test much more complex.
=20
The advantage of using a reserved bit is that the frame with Ethertype =
=3D TRILL already go through DR blocked ports. The non-TRILL IS-IS =
frames will have Ethertype =3D ISIS and will be dropped by DR blocked =
ports.
=20
All this considered, I am sligtly in favour of using the reserved bit as =
proposed by Radia.
=20
-- Silvano
=20
=20
________________________________

From: [e-mail] on behalf of Radia Perlman
Sent: Sat 5/19/2007 11:11 PM
To: Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer =
3 IS-IS, and TRILL-encapsulated data packets?



Right (what Donald said below).

To summarize -- if we TRILL-encapsulate IS-IS packets, then we have to =
be
able to notice, based on the TRILL header, that this is a TRILL IS-IS
packet (rather than
an encapsulated layer 3 IS-IS packet).

We might avoid TRILL-encapsulating an IS-IS packet by
using a new multicast address and using the IS-IS Ethertype, but I'm
nervous it might confuse some layer 3 IS-IS implementations. I'm also
worried
that occasionally an IS-IS packet would not be multicast (for instance,
a PSNP
might be unicast).

I'm also worried about the per-VLAN instance of IS-IS. Even if we don't
make advertising endnodes via IS-IS a MUST, or even if we don't mention =
it
in the first version of the protocol, I'd like to be able to add
advertisement of
"particularly well-learned" endnode addresses via a per-VLAN instance of
IS-IS at
some point in the future, and make the advertisements, as well as the
learning
from them, be a MAY or SHOULD.

So...if we TRILL-encapsulate (in order to use the TRILL Ethertype),
basically all
the fields in the TRILL header are useless. So, we could use a reserved
bit in
the TRILL header to say this
is IS-IS. Or we could reserve a value of nickname (say, nickname=3D0), =
and
define
IS-IS to use ingress and egress nickname both=3D0.

Once we find a way to differentiate a TRILL-encapsulated TRILL-IS-IS =
from
a TRILL-encapsulated layer 3 IS-IS packet, doing the per-VLAN one won't =
be
hard. We'd just add a VLAN tag in the "right place".

So---if these are the alternatives, what do people prefer?
TRILL-encapsulate IS-IS packets, using Ethertype=3DIS-IS in
the inner frame, differentiating TRILL IS-IS from a
TRILL-encapsulated layer 3 IS-IS using either:

a) a reserved bit in the TRILL header
b) reserved nickname values (say ingress nickname =3D 0)

Radia




Eastlake III Donald-LDE008 wrote:
> Hi Radia,
>
> This proposal seems fine but a few comments, in somewhat miscellaneous
> order:
>
> I believe that multicast addresses are cheap and, if we wanted to, we
> could get any reasonable number; however, multicast frames don't seem =
to
> me to be the problem. If you receive a frame sent to All Rbridges,
> according to the current protocol draft, it can only have one of two
> Ethertypes, TRILL or IS-IS. And if that Ethertype is IS-IS, then it is
> an IS-IS packet for the TRILL core IS-IS instance. (The qualification
> "core" no longer being necessary with the per-VLAN IS-IS instances
> dropped.)
>
> Layer 3 IS-IS multicast messages would always be sent to a multicast
> address different from All Rbridges.
>
> So it is only unicast IS-IS messages that would be a problem if an
> Rbridge had difficulty telling whether they were for layer-3 or for
> Rbridge IS-IS.
>
> I believe Ethertypes are a much more scarce resource and it is best to
> stick with one, as your proposal does.
>
> A TRILL header with one of the currently reserved bits set would
> certainly serve to mark unicast IS-IS packet intended for TRILL and
> could also be included in the multicast case for greater uniformity =
and
> added protection against some layer 3 IS-IS router deciding to process
> the frame despite its multicast address. However, most of the fields =
in
> such a TRILL header are or might be unused. The Rbridges might not yet
> have selected nicknames and in any case the nicknames would not be
> useful, the hop count is not useful, etc.
>
> Thanks,
> Donald
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] =
On
> Behalf Of Radia Perlman
> Sent: Saturday, May 19, 2007 12:23 AM
> To: Radia Perlman
> Cc: [e-mail]
> Subject: Re: [rbridge] How is an IS-IS packet differentiated from =
layer
> 3 IS-IS, and TRILL-encapsulated data packets?
>
> OK. Here's my proposal.
>
> TRILL IS-IS will always be encapsulated in a TRILL header.
> That means the outer Ethertype is always=3D"TRILL" for TRILL IS-IS =
packets
> (whether they are LSPs, Hellos, or SNPs).
>
> I propose using a bit in the TRILL header (that would have been
> "reserved"
> to mean "this is a TRILL IS-IS packet".
>
> Is this OK?
>
> Radia
>
>
> Radia Perlman wrote:
> =20
>> Now that I'm editing the spec to be real specific here, I need a
>> sanity check, or
>> advice from implementers about what would be most convenient for =
them.
>>
>> My assumption is that we are removing the per-VLAN instance of IS-IS
>> (which could
>> be added later on, for the purpose of distributing endnode =
information
>>   =20
>
> =20
>> that is more
>> securely learned, say through a cryptographically authenticated layer
>> 2 enrollment
>> protocol). But we are requiring RBridges to learn (ingress RBridge,
>> source MAC address)
>> from packets they are decapsulating onto their link.
>>
>> So we just have the core instance of IS-IS. We have to make sure =
layer
>>   =20
>
> =20
>> 3 IS-IS
>> packets (which might also be flowing across the campus between
>> routers) don't
>> get confused with TRILL IS-IS. We also have to have RBridges easily
>> distinguish
>> TRILL IS-IS Hellos and LSPs from ordinary encapsulated data packets.
>>
>> When a router generates an IS-IS packet, the destination address will
>> be "all-level1-routers"
>> or "all-level-2 routers", or perhaps, a specific router (for =
instance,
>>   =20
>
> =20
>> to send a PSNP).
>> The way this is recognized as an IS-IS packet is due to the
>> EThertype=3DIS-IS.
>>
>> RBridge, I believe, should not treat IS-IS packets differently from
>> any other "data"
>> packets. If it's addressed to "all-level1-routers" or
>> "all-level2-routers" it would be
>> treated like any other multidestination packet, encapsulated, and =
sent
>>   =20
>
> =20
>> along a distribution
>> tree. If it's unicast, it is treated like any other unicast packet by
>> RBridges, assuming
>> the layer 2 address specified in the destination is known to the
>> ingress RBridge.
>>
>> The question is---how are TRILL IS-IS packets encoded?
>>
>> Could we get a second Ethertype for this? I'm assuming not...
>>
>> I'm assuming we just have a single Ethertype for =
"TRILL-encapsulated".
>>   =20
>
> =20
>> So we have
>> to use that.
>>
>> We could use a different multicast destination address for
>> "all-RBridges-for-IS-IS" vs
>> "all-RBridges" that is used for multicast data.
>>
>> Or we could have a bit in the TRILL header saying "this is an IS-IS
>> packet".
>>
>> We could in theory not use the TRILL header for IS-IS packets, since
>> in theory
>> IS-IS does not need to be encapsulated (for layer 3 IS-IS it runs
>> directly over layer 2).
>> But then we'd need a separate Ethertype.
>>
>> So...if we are going to use the TRILL header, then how do we not get
>> confused
>> between TRILL IS-IS and layer 3 IS-IS?
>>
>> I guess we could assume that it's enough to have TRILL IS-IS use "0"
>> as the area
>> address, and use IS-IS as the Ethertype in the inner header. For
>> TRILL-encapsulated
>> packets, we actually could choose some weirdo Ethertype (like 0) in
>> the inner header.
>> But we still need to differentiate TRILL IS-IS from layer 3 IS-IS on
>> the first hop.
>>
>> This is probably something I should ask the IS-IS WG, since it really
>> depends on
>> idiosyncracies of the current IS-IS implementations.
>>
>> Radia
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>   =20
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> =20

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



------_=_NextPart_001_01C79AF8.B6E4687D
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 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7651.59">=0A=
<TITLE>Re: [rbridge] How is an IS-IS packet differentiated from layer 3 =
IS-IS, and TRILL-encapsulated data packets?</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText20832 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Radia, =
Donald,</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>from an implementation =
perspective the less =0A=
fields you have to test, the easier it is. </FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>The main problem is to be =
able to determine =0A=
in HW, at the port level, if a frame must be forwarded, dropped or =
redirected to =0A=
the RBridge CPU.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>In bridges it&nbsp;is very =
easy, BPDUs have =0A=
a reserved MAC address, bridge ports&nbsp;have few registers that can be =
loaded =0A=
with MAC addresses that allows frame to go through blocked port =
(remember that =0A=
BPDUs MUST be received even if the port is blocked).</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>In RBridges a port may be DR =
blocked. On a =0A=
DR blocked port we must still receive BPDUs, RBridge IS-IS frames and =
TRILL =0A=
encapsulated frames, but we must drop data frames including IS-IS frames =
used by =0A=
non-TRILL protocols.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Distinguishing IS-IS used for =
TRILL from =0A=
IS-IS used for other protocols is the tricky part.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Donald suggest using a =
reserved MAC addess, =0A=
that would be ideal from an implementation perspective, </FONT><FONT =
face=3DArial =0A=
size=3D2>but Radia replies that a PSNP (<FONT face=3DVerdana>partial =
sequence number =0A=
PDU) may be unicast.</FONT></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DVerdana size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DVerdana size=3D2>If a MAC address does not =
work, the next =0A=
field is the Ethertype. We already know that we will have a pushback in =
having =0A=
two Ethertypes for TRILL, so Radia suggests using a single Ethertype and =0A=
extending it with a rreserved bit. This can be done, as it is also =
possible to =0A=
use version 0 for IS-IS and version 1 for TRILL.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DVerdana size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DVerdana size=3D2>I am against redefining the =
meaning of =0A=
nicknames or of other fields, since it makes the test much more =0A=
complex.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DVerdana size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DVerdana size=3D2>The advantage of using a =
reserved bit is =0A=
that the frame with Ethertype =3D TRILL&nbsp;already go through DR =
blocked ports. =0A=
The non-TRILL IS-IS frames will have Ethertype =3D ISIS and will be =
dropped by DR =0A=
blocked ports.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DVerdana size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DVerdana size=3D2>All this considered, I am =
sligtly in =0A=
favour of using the reserved bit as proposed by Radia.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DVerdana size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DVerdana size=3D2>-- Silvano</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DVerdana size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DVerdana size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] on =
behalf of =0A=
Radia Perlman<BR><B>Sent:</B> Sat 5/19/2007 11:11 PM<BR><B>To:</B> =
Eastlake III =0A=
Donald-LDE008<BR><B>Cc:</B> [e-mail]<BR><B>Subject:</B> Re: =
[rbridge] =0A=
How is an IS-IS packet differentiated from layer 3 IS-IS, and =
TRILL-encapsulated =0A=
data packets?<BR></FONT><BR></DIV></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>Right (what Donald said below).<BR><BR>To summarize -- =
if we =0A=
TRILL-encapsulate IS-IS packets, then we have to be<BR>able to notice, =
based on =0A=
the TRILL header, that this is a TRILL IS-IS<BR>packet (rather =
than<BR>an =0A=
encapsulated layer 3 IS-IS packet).<BR><BR>We might avoid =
TRILL-encapsulating an =0A=
IS-IS packet by<BR>using a new multicast address and using the IS-IS =
Ethertype, =0A=
but I'm<BR>nervous it might confuse some layer 3 IS-IS implementations. =
I'm =0A=
also<BR>worried<BR>that occasionally an IS-IS packet would not be =
multicast (for =0A=
instance,<BR>a PSNP<BR>might be unicast).<BR><BR>I'm also worried about =
the =0A=
per-VLAN instance of IS-IS. Even if we don't<BR>make advertising =
endnodes via =0A=
IS-IS a MUST, or even if we don't mention it<BR>in the first version of =
the =0A=
protocol, I'd like to be able to add<BR>advertisement =
of<BR>"particularly =0A=
well-learned" endnode addresses via a per-VLAN instance of<BR>IS-IS =
at<BR>some =0A=
point in the future, and make the advertisements, as well as =0A=
the<BR>learning<BR>from them, be a MAY or SHOULD.<BR><BR>So...if we =0A=
TRILL-encapsulate (in order to use the TRILL Ethertype),<BR>basically =
all<BR>the =0A=
fields in the TRILL header are useless. So, we could use a =
reserved<BR>bit =0A=
in<BR>the TRILL header to say this<BR>is IS-IS. Or we could reserve a =
value of =0A=
nickname (say, nickname=3D0), and<BR>define<BR>IS-IS to use ingress and =
egress =0A=
nickname both=3D0.<BR><BR>Once we find a way to differentiate a =
TRILL-encapsulated =0A=
TRILL-IS-IS from<BR>a TRILL-encapsulated layer 3 IS-IS packet, doing the =0A=
per-VLAN one won't be<BR>hard. We'd just add a VLAN tag in the "right =0A=
place".<BR><BR>So---if these are the alternatives, what do people =0A=
prefer?<BR>TRILL-encapsulate IS-IS packets, using Ethertype=3DIS-IS =
in<BR>the =0A=
inner frame, differentiating TRILL IS-IS from a<BR>TRILL-encapsulated =
layer 3 =0A=
IS-IS using either:<BR><BR>a) a reserved bit in the TRILL header<BR>b) =
reserved =0A=
nickname values (say ingress nickname =3D =0A=
0)<BR><BR>Radia<BR><BR><BR><BR><BR>Eastlake III Donald-LDE008 =
wrote:<BR>&gt; Hi =0A=
Radia,<BR>&gt;<BR>&gt; This proposal seems fine but a few comments, in =
somewhat =0A=
miscellaneous<BR>&gt; order:<BR>&gt;<BR>&gt; I believe that multicast =
addresses =0A=
are cheap and, if we wanted to, we<BR>&gt; could get any reasonable =
number; =0A=
however, multicast frames don't seem to<BR>&gt; me to be the problem. If =
you =0A=
receive a frame sent to All Rbridges,<BR>&gt; according to the current =
protocol =0A=
draft, it can only have one of two<BR>&gt; Ethertypes, TRILL or IS-IS. =
And if =0A=
that Ethertype is IS-IS, then it is<BR>&gt; an IS-IS packet for the =
TRILL core =0A=
IS-IS instance. (The qualification<BR>&gt; "core" no longer being =
necessary with =0A=
the per-VLAN IS-IS instances<BR>&gt; dropped.)<BR>&gt;<BR>&gt; Layer 3 =
IS-IS =0A=
multicast messages would always be sent to a multicast<BR>&gt; address =
different =0A=
from All Rbridges.<BR>&gt;<BR>&gt; So it is only unicast IS-IS messages =
that =0A=
would be a problem if an<BR>&gt; Rbridge had difficulty telling whether =
they =0A=
were for layer-3 or for<BR>&gt; Rbridge IS-IS.<BR>&gt;<BR>&gt; I believe =0A=
Ethertypes are a much more scarce resource and it is best to<BR>&gt; =
stick with =0A=
one, as your proposal does.<BR>&gt;<BR>&gt; A TRILL header with one of =
the =0A=
currently reserved bits set would<BR>&gt; certainly serve to mark =
unicast IS-IS =0A=
packet intended for TRILL and<BR>&gt; could also be included in the =
multicast =0A=
case for greater uniformity and<BR>&gt; added protection against some =
layer 3 =0A=
IS-IS router deciding to process<BR>&gt; the frame despite its multicast =0A=
address. However, most of the fields in<BR>&gt; such a TRILL header are =
or might =0A=
be unused. The Rbridges might not yet<BR>&gt; have selected nicknames =
and in any =0A=
case the nicknames would not be<BR>&gt; useful, the hop count is not =
useful, =0A=
etc.<BR>&gt;<BR>&gt; Thanks,<BR>&gt; Donald<BR>&gt;<BR>&gt; =
-----Original =0A=
Message-----<BR>&gt; From: [e-mail] [<A =0A=
href=3D"mailto:[e-mail]">mailto:rbridge-bounces@postel.=
org</A>] =0A=
On<BR>&gt; Behalf Of Radia Perlman<BR>&gt; Sent: Saturday, May 19, 2007 =
12:23 =0A=
AM<BR>&gt; To: Radia Perlman<BR>&gt; Cc: [e-mail]<BR>&gt; =
Subject: Re: =0A=
[rbridge] How is an IS-IS packet differentiated from layer<BR>&gt; 3 =
IS-IS, and =0A=
TRILL-encapsulated data packets?<BR>&gt;<BR>&gt; OK. Here's my =0A=
proposal.<BR>&gt;<BR>&gt; TRILL IS-IS will always be encapsulated in a =
TRILL =0A=
header.<BR>&gt; That means the outer Ethertype is always=3D"TRILL" for =
TRILL IS-IS =0A=
packets<BR>&gt; (whether they are LSPs, Hellos, or =
SNPs).<BR>&gt;<BR>&gt; I =0A=
propose using a bit in the TRILL header (that would have been<BR>&gt; =0A=
"reserved"<BR>&gt; to mean "this is a TRILL IS-IS =
packet".<BR>&gt;<BR>&gt; Is =0A=
this OK?<BR>&gt;<BR>&gt; Radia<BR>&gt;<BR>&gt;<BR>&gt; Radia Perlman =0A=
wrote:<BR>&gt;&nbsp;&nbsp;<BR>&gt;&gt; Now that I'm editing the spec to =
be real =0A=
specific here, I need a<BR>&gt;&gt; sanity check, or<BR>&gt;&gt; advice =
from =0A=
implementers about what would be most convenient for =0A=
them.<BR>&gt;&gt;<BR>&gt;&gt; My assumption is that we are removing the =
per-VLAN =0A=
instance of IS-IS<BR>&gt;&gt; (which could<BR>&gt;&gt; be added later =
on, for =0A=
the purpose of distributing endnode =0A=
information<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;<BR>&gt;&nbsp;&nbs=
p;<BR>&gt;&gt; =0A=
that is more<BR>&gt;&gt; securely learned, say through a =
cryptographically =0A=
authenticated layer<BR>&gt;&gt; 2 enrollment<BR>&gt;&gt; protocol). But =
we are =0A=
requiring RBridges to learn (ingress RBridge,<BR>&gt;&gt; source MAC =0A=
address)<BR>&gt;&gt; from packets they are decapsulating onto their =0A=
link.<BR>&gt;&gt;<BR>&gt;&gt; So we just have the core instance of =
IS-IS. We =0A=
have to make sure =0A=
layer<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;<BR>&gt;&nbsp;&nbsp;<BR>=
&gt;&gt; =0A=
3 IS-IS<BR>&gt;&gt; packets (which might also be flowing across the =
campus =0A=
between<BR>&gt;&gt; routers) don't<BR>&gt;&gt; get confused with TRILL =
IS-IS. We =0A=
also have to have RBridges easily<BR>&gt;&gt; distinguish<BR>&gt;&gt; =
TRILL =0A=
IS-IS Hellos and LSPs from ordinary encapsulated data =0A=
packets.<BR>&gt;&gt;<BR>&gt;&gt; When a router generates an IS-IS =
packet, the =0A=
destination address will<BR>&gt;&gt; be "all-level1-routers"<BR>&gt;&gt; =
or =0A=
"all-level-2 routers", or perhaps, a specific router (for =0A=
instance,<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;<BR>&gt;&nbsp;&nbsp;=
<BR>&gt;&gt; =0A=
to send a PSNP).<BR>&gt;&gt; The way this is recognized as an IS-IS =
packet is =0A=
due to the<BR>&gt;&gt; EThertype=3DIS-IS.<BR>&gt;&gt;<BR>&gt;&gt; =
RBridge, I =0A=
believe, should not treat IS-IS packets differently from<BR>&gt;&gt; any =
other =0A=
"data"<BR>&gt;&gt; packets. If it's addressed to "all-level1-routers" =0A=
or<BR>&gt;&gt; "all-level2-routers" it would be<BR>&gt;&gt; treated like =
any =0A=
other multidestination packet, encapsulated, and =0A=
sent<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;<BR>&gt;&nbsp;&nbsp;<BR>&=
gt;&gt; =0A=
along a distribution<BR>&gt;&gt; tree. If it's unicast, it is treated =
like any =0A=
other unicast packet by<BR>&gt;&gt; RBridges, assuming<BR>&gt;&gt; the =
layer 2 =0A=
address specified in the destination is known to the<BR>&gt;&gt; ingress =0A=
RBridge.<BR>&gt;&gt;<BR>&gt;&gt; The question is---how are TRILL IS-IS =
packets =0A=
encoded?<BR>&gt;&gt;<BR>&gt;&gt; Could we get a second Ethertype for =
this? I'm =0A=
assuming not...<BR>&gt;&gt;<BR>&gt;&gt; I'm assuming we just have a =
single =0A=
Ethertype for =0A=
"TRILL-encapsulated".<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;<BR>&gt;=
&nbsp;&nbsp;<BR>&gt;&gt; =0A=
So we have<BR>&gt;&gt; to use that.<BR>&gt;&gt;<BR>&gt;&gt; We could use =
a =0A=
different multicast destination address for<BR>&gt;&gt; =
"all-RBridges-for-IS-IS" =0A=
vs<BR>&gt;&gt; "all-RBridges" that is used for multicast =0A=
data.<BR>&gt;&gt;<BR>&gt;&gt; Or we could have a bit in the TRILL header =
saying =0A=
"this is an IS-IS<BR>&gt;&gt; packet".<BR>&gt;&gt;<BR>&gt;&gt; We could =
in =0A=
theory not use the TRILL header for IS-IS packets, since<BR>&gt;&gt; in =0A=
theory<BR>&gt;&gt; IS-IS does not need to be encapsulated (for layer 3 =
IS-IS it =0A=
runs<BR>&gt;&gt; directly over layer 2).<BR>&gt;&gt; But then we'd need =
a =0A=
separate Ethertype.<BR>&gt;&gt;<BR>&gt;&gt; So...if we are going to use =
the =0A=
TRILL header, then how do we not get<BR>&gt;&gt; confused<BR>&gt;&gt; =
between =0A=
TRILL IS-IS and layer 3 IS-IS?<BR>&gt;&gt;<BR>&gt;&gt; I guess we could =
assume =0A=
that it's enough to have TRILL IS-IS use "0"<BR>&gt;&gt; as the =
area<BR>&gt;&gt; =0A=
address, and use IS-IS as the Ethertype in the inner header. =
For<BR>&gt;&gt; =0A=
TRILL-encapsulated<BR>&gt;&gt; packets, we actually could choose some =
weirdo =0A=
Ethertype (like 0) in<BR>&gt;&gt; the inner header.<BR>&gt;&gt; But we =
still =0A=
need to differentiate TRILL IS-IS from layer 3 IS-IS on<BR>&gt;&gt; the =
first =0A=
hop.<BR>&gt;&gt;<BR>&gt;&gt; This is probably something I should ask the =
IS-IS =0A=
WG, since it really<BR>&gt;&gt; depends on<BR>&gt;&gt; idiosyncracies of =
the =0A=
current IS-IS implementations.<BR>&gt;&gt;<BR>&gt;&gt; =0A=
Radia<BR>&gt;&gt;<BR>&gt;&gt;<BR>&gt;&gt;<BR>&gt;&gt;<BR>&gt;&gt;<BR>&gt;=
&gt;<BR>&gt;&gt;<BR>&gt;&gt;<BR>&gt;&gt;<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nb=
sp;<BR>&gt;<BR>&gt; =0A=
_______________________________________________<BR>&gt; rbridge mailing =0A=
list<BR>&gt; [e-mail]<BR>&gt; <A =0A=
href=3D"http://mailman.postel.org/mailman/listinfo/rbridge">http://mailma=
n.postel.org/mailman/listinfo/rbridge</A><BR>&gt;&nbsp;&nbsp;<BR><BR>____=
___________________________________________<BR>rbridge =0A=
mailing list<BR>[e-mail]<BR><A =0A=
href=3D"http://mailman.postel.org/mailman/listinfo/rbridge">http://mailma=
n.postel.org/mailman/listinfo/rbridge</A><BR></FONT></P></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C79AF8.B6E4687D--


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 l4K6AejH007994 for <[e-mail]>; Sat, 19 May 2007 23:10: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]; Sat, 19 May 2007 23:10:34 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.16.160]) 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, 19 May 2007 23:10:34 -0700 (PDT)
Date: Sat, 19 May 2007 23:11:07 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Eastlake III Donald-LDE008 <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?
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, 20 May 2007 06:11:12 -0000
Status: RO
Content-Length: 7432

Right (what Donald said below).

To summarize -- if we TRILL-encapsulate IS-IS packets, then we have to be
able to notice, based on the TRILL header, that this is a TRILL IS-IS 
packet (rather than
an encapsulated layer 3 IS-IS packet).

We might avoid TRILL-encapsulating an IS-IS packet by
using a new multicast address and using the IS-IS Ethertype, but I'm
nervous it might confuse some layer 3 IS-IS implementations. I'm also 
worried
that occasionally an IS-IS packet would not be multicast (for instance, 
a PSNP
might be unicast).

I'm also worried about the per-VLAN instance of IS-IS. Even if we don't
make advertising endnodes via IS-IS a MUST, or even if we don't mention it
in the first version of the protocol, I'd like to be able to add 
advertisement of
"particularly well-learned" endnode addresses via a per-VLAN instance of 
IS-IS at
some point in the future, and make the advertisements, as well as the 
learning
from them, be a MAY or SHOULD.

So...if we TRILL-encapsulate (in order to use the TRILL Ethertype), 
basically all
the fields in the TRILL header are useless. So, we could use a reserved 
bit in
the TRILL header to say this
is IS-IS. Or we could reserve a value of nickname (say, nickname=0), and 
define
IS-IS to use ingress and egress nickname both=0.

Once we find a way to differentiate a TRILL-encapsulated TRILL-IS-IS from
a TRILL-encapsulated layer 3 IS-IS packet, doing the per-VLAN one won't be
hard. We'd just add a VLAN tag in the "right place".

So---if these are the alternatives, what do people prefer?
TRILL-encapsulate IS-IS packets, using Ethertype=IS-IS in
the inner frame, differentiating TRILL IS-IS from a
TRILL-encapsulated layer 3 IS-IS using either:

a) a reserved bit in the TRILL header
b) reserved nickname values (say ingress nickname = 0)

Radia




Eastlake III Donald-LDE008 wrote:
> Hi Radia,
>
> This proposal seems fine but a few comments, in somewhat miscellaneous
> order:
>
> I believe that multicast addresses are cheap and, if we wanted to, we
> could get any reasonable number; however, multicast frames don't seem to
> me to be the problem. If you receive a frame sent to All Rbridges,
> according to the current protocol draft, it can only have one of two
> Ethertypes, TRILL or IS-IS. And if that Ethertype is IS-IS, then it is
> an IS-IS packet for the TRILL core IS-IS instance. (The qualification
> "core" no longer being necessary with the per-VLAN IS-IS instances
> dropped.)
>
> Layer 3 IS-IS multicast messages would always be sent to a multicast
> address different from All Rbridges.
>
> So it is only unicast IS-IS messages that would be a problem if an
> Rbridge had difficulty telling whether they were for layer-3 or for
> Rbridge IS-IS.
>
> I believe Ethertypes are a much more scarce resource and it is best to
> stick with one, as your proposal does.
>
> A TRILL header with one of the currently reserved bits set would
> certainly serve to mark unicast IS-IS packet intended for TRILL and
> could also be included in the multicast case for greater uniformity and
> added protection against some layer 3 IS-IS router deciding to process
> the frame despite its multicast address. However, most of the fields in
> such a TRILL header are or might be unused. The Rbridges might not yet
> have selected nicknames and in any case the nicknames would not be
> useful, the hop count is not useful, etc.
>
> Thanks,
> Donald
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Radia Perlman
> Sent: Saturday, May 19, 2007 12:23 AM
> To: Radia Perlman
> Cc: [e-mail]
> Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer
> 3 IS-IS, and TRILL-encapsulated data packets?
>
> OK. Here's my proposal.
>
> TRILL IS-IS will always be encapsulated in a TRILL header.
> That means the outer Ethertype is always="TRILL" for TRILL IS-IS packets
> (whether they are LSPs, Hellos, or SNPs).
>
> I propose using a bit in the TRILL header (that would have been
> "reserved"
> to mean "this is a TRILL IS-IS packet".
>
> Is this OK?
>
> Radia
>
>
> Radia Perlman wrote:
>   
>> Now that I'm editing the spec to be real specific here, I need a 
>> sanity check, or
>> advice from implementers about what would be most convenient for them.
>>
>> My assumption is that we are removing the per-VLAN instance of IS-IS 
>> (which could
>> be added later on, for the purpose of distributing endnode information
>>     
>
>   
>> that is more
>> securely learned, say through a cryptographically authenticated layer 
>> 2 enrollment
>> protocol). But we are requiring RBridges to learn (ingress RBridge, 
>> source MAC address)
>> from packets they are decapsulating onto their link.
>>
>> So we just have the core instance of IS-IS. We have to make sure layer
>>     
>
>   
>> 3 IS-IS
>> packets (which might also be flowing across the campus between 
>> routers) don't
>> get confused with TRILL IS-IS. We also have to have RBridges easily 
>> distinguish
>> TRILL IS-IS Hellos and LSPs from ordinary encapsulated data packets.
>>
>> When a router generates an IS-IS packet, the destination address will 
>> be "all-level1-routers"
>> or "all-level-2 routers", or perhaps, a specific router (for instance,
>>     
>
>   
>> to send a PSNP).
>> The way this is recognized as an IS-IS packet is due to the 
>> EThertype=IS-IS.
>>
>> RBridge, I believe, should not treat IS-IS packets differently from 
>> any other "data"
>> packets. If it's addressed to "all-level1-routers" or 
>> "all-level2-routers" it would be
>> treated like any other multidestination packet, encapsulated, and sent
>>     
>
>   
>> along a distribution
>> tree. If it's unicast, it is treated like any other unicast packet by 
>> RBridges, assuming
>> the layer 2 address specified in the destination is known to the 
>> ingress RBridge.
>>
>> The question is---how are TRILL IS-IS packets encoded?
>>
>> Could we get a second Ethertype for this? I'm assuming not...
>>
>> I'm assuming we just have a single Ethertype for "TRILL-encapsulated".
>>     
>
>   
>> So we have
>> to use that.
>>
>> We could use a different multicast destination address for 
>> "all-RBridges-for-IS-IS" vs
>> "all-RBridges" that is used for multicast data.
>>
>> Or we could have a bit in the TRILL header saying "this is an IS-IS 
>> packet".
>>
>> We could in theory not use the TRILL header for IS-IS packets, since 
>> in theory
>> IS-IS does not need to be encapsulated (for layer 3 IS-IS it runs 
>> directly over layer 2).
>> But then we'd need a separate Ethertype.
>>
>> So...if we are going to use the TRILL header, then how do we not get 
>> confused
>> between TRILL IS-IS and layer 3 IS-IS?
>>
>> I guess we could assume that it's enough to have TRILL IS-IS use "0" 
>> as the area
>> address, and use IS-IS as the Ethertype in the inner header. For 
>> TRILL-encapsulated
>> packets, we actually could choose some weirdo Ethertype (like 0) in 
>> the inner header.
>> But we still need to differentiate TRILL IS-IS from layer 3 IS-IS on 
>> the first hop.
>>
>> This is probably something I should ask the IS-IS WG, since it really 
>> depends on
>> idiosyncracies of the current IS-IS implementations.
>>
>> Radia
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   



Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l4K29V53025476 for <[e-mail]>; Sat, 19 May 2007 19:09:31 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-15.tower-153.messagelabs.com!1179626970!1709646!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 6987 invoked from network); 20 May 2007 02:09:30 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-153.messagelabs.com with SMTP; 20 May 2007 02:09:30 -0000
Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4K29U0E004244 for <[e-mail]>; Sat, 19 May 2007 19:09:30 -0700 (MST)
Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l4K29TaR008748 for <[e-mail]>; Sat, 19 May 2007 21:09:29 -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 l4K29S6i008738 for <[e-mail]>; Sat, 19 May 2007 21:09:28 -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, 19 May 2007 22:09:25 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?
thread-index: AceZ1CUzhLzM1nLZSZK/y31swCMb4gAZMYPg
References: <[e-mail]> <[e-mail]>
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 l4K29V53025476
Cc: [e-mail]
Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?
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, 20 May 2007 02:09:51 -0000
Status: RO
Content-Length: 5294

Hi Radia,

This proposal seems fine but a few comments, in somewhat miscellaneous
order:

I believe that multicast addresses are cheap and, if we wanted to, we
could get any reasonable number; however, multicast frames don't seem to
me to be the problem. If you receive a frame sent to All Rbridges,
according to the current protocol draft, it can only have one of two
Ethertypes, TRILL or IS-IS. And if that Ethertype is IS-IS, then it is
an IS-IS packet for the TRILL core IS-IS instance. (The qualification
"core" no longer being necessary with the per-VLAN IS-IS instances
dropped.)

Layer 3 IS-IS multicast messages would always be sent to a multicast
address different from All Rbridges.

So it is only unicast IS-IS messages that would be a problem if an
Rbridge had difficulty telling whether they were for layer-3 or for
Rbridge IS-IS.

I believe Ethertypes are a much more scarce resource and it is best to
stick with one, as your proposal does.

A TRILL header with one of the currently reserved bits set would
certainly serve to mark unicast IS-IS packet intended for TRILL and
could also be included in the multicast case for greater uniformity and
added protection against some layer 3 IS-IS router deciding to process
the frame despite its multicast address. However, most of the fields in
such a TRILL header are or might be unused. The Rbridges might not yet
have selected nicknames and in any case the nicknames would not be
useful, the hop count is not useful, etc.

Thanks,
Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Saturday, May 19, 2007 12:23 AM
To: Radia Perlman
Cc: [e-mail]
Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer
3 IS-IS, and TRILL-encapsulated data packets?

OK. Here's my proposal.

TRILL IS-IS will always be encapsulated in a TRILL header.
That means the outer Ethertype is always="TRILL" for TRILL IS-IS packets
(whether they are LSPs, Hellos, or SNPs).

I propose using a bit in the TRILL header (that would have been
"reserved"
to mean "this is a TRILL IS-IS packet".

Is this OK?

Radia


Radia Perlman wrote:
> Now that I'm editing the spec to be real specific here, I need a 
> sanity check, or
> advice from implementers about what would be most convenient for them.
>
> My assumption is that we are removing the per-VLAN instance of IS-IS 
> (which could
> be added later on, for the purpose of distributing endnode information

> that is more
> securely learned, say through a cryptographically authenticated layer 
> 2 enrollment
> protocol). But we are requiring RBridges to learn (ingress RBridge, 
> source MAC address)
> from packets they are decapsulating onto their link.
>
> So we just have the core instance of IS-IS. We have to make sure layer

> 3 IS-IS
> packets (which might also be flowing across the campus between 
> routers) don't
> get confused with TRILL IS-IS. We also have to have RBridges easily 
> distinguish
> TRILL IS-IS Hellos and LSPs from ordinary encapsulated data packets.
>
> When a router generates an IS-IS packet, the destination address will 
> be "all-level1-routers"
> or "all-level-2 routers", or perhaps, a specific router (for instance,

> to send a PSNP).
> The way this is recognized as an IS-IS packet is due to the 
> EThertype=IS-IS.
>
> RBridge, I believe, should not treat IS-IS packets differently from 
> any other "data"
> packets. If it's addressed to "all-level1-routers" or 
> "all-level2-routers" it would be
> treated like any other multidestination packet, encapsulated, and sent

> along a distribution
> tree. If it's unicast, it is treated like any other unicast packet by 
> RBridges, assuming
> the layer 2 address specified in the destination is known to the 
> ingress RBridge.
>
> The question is---how are TRILL IS-IS packets encoded?
>
> Could we get a second Ethertype for this? I'm assuming not...
>
> I'm assuming we just have a single Ethertype for "TRILL-encapsulated".

> So we have
> to use that.
>
> We could use a different multicast destination address for 
> "all-RBridges-for-IS-IS" vs
> "all-RBridges" that is used for multicast data.
>
> Or we could have a bit in the TRILL header saying "this is an IS-IS 
> packet".
>
> We could in theory not use the TRILL header for IS-IS packets, since 
> in theory
> IS-IS does not need to be encapsulated (for layer 3 IS-IS it runs 
> directly over layer 2).
> But then we'd need a separate Ethertype.
>
> So...if we are going to use the TRILL header, then how do we not get 
> confused
> between TRILL IS-IS and layer 3 IS-IS?
>
> I guess we could assume that it's enough to have TRILL IS-IS use "0" 
> as the area
> address, and use IS-IS as the Ethertype in the inner header. For 
> TRILL-encapsulated
> packets, we actually could choose some weirdo Ethertype (like 0) in 
> the inner header.
> But we still need to differentiate TRILL IS-IS from layer 3 IS-IS on 
> the first hop.
>
> This is probably something I should ask the IS-IS WG, since it really 
> depends on
> idiosyncracies of the current IS-IS implementations.
>
> Radia
>
>
>
>
>
>
>
>
>

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



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l4J4M2bl005346 for <[e-mail]>; Fri, 18 May 2007 21:22:02 -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]; Fri, 18 May 2007 21:22:02 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.16.160]) 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]; Fri, 18 May 2007 21:22:01 -0700 (PDT)
Date: Fri, 18 May 2007 21:22:33 -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]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?
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, 19 May 2007 04:22:28 -0000
Status: RO
Content-Length: 3333

OK. Here's my proposal.

TRILL IS-IS will always be encapsulated in a TRILL header.
That means the outer Ethertype is always="TRILL" for TRILL IS-IS packets
(whether they are LSPs, Hellos, or SNPs).

I propose using a bit in the TRILL header (that would have been "reserved"
to mean "this is a TRILL IS-IS packet".

Is this OK?

Radia




Radia Perlman wrote:
> Now that I'm editing the spec to be real specific here, I need a 
> sanity check, or
> advice from implementers about what would be most convenient for them.
>
> My assumption is that we are removing the per-VLAN instance of IS-IS 
> (which could
> be added later on, for the purpose of distributing endnode information 
> that is more
> securely learned, say through a cryptographically authenticated layer 
> 2 enrollment
> protocol). But we are requiring RBridges to learn (ingress RBridge, 
> source MAC address)
> from packets they are decapsulating onto their link.
>
> So we just have the core instance of IS-IS. We have to make sure layer 
> 3 IS-IS
> packets (which might also be flowing across the campus between 
> routers) don't
> get confused with TRILL IS-IS. We also have to have RBridges easily 
> distinguish
> TRILL IS-IS Hellos and LSPs from ordinary encapsulated data packets.
>
> When a router generates an IS-IS packet, the destination address will 
> be "all-level1-routers"
> or "all-level-2 routers", or perhaps, a specific router (for instance, 
> to send a PSNP).
> The way this is recognized as an IS-IS packet is due to the 
> EThertype=IS-IS.
>
> RBridge, I believe, should not treat IS-IS packets differently from 
> any other "data"
> packets. If it's addressed to "all-level1-routers" or 
> "all-level2-routers" it would be
> treated like any other multidestination packet, encapsulated, and sent 
> along a distribution
> tree. If it's unicast, it is treated like any other unicast packet by 
> RBridges, assuming
> the layer 2 address specified in the destination is known to the 
> ingress RBridge.
>
> The question is---how are TRILL IS-IS packets encoded?
>
> Could we get a second Ethertype for this? I'm assuming not...
>
> I'm assuming we just have a single Ethertype for "TRILL-encapsulated". 
> So we have
> to use that.
>
> We could use a different multicast destination address for 
> "all-RBridges-for-IS-IS" vs
> "all-RBridges" that is used for multicast data.
>
> Or we could have a bit in the TRILL header saying "this is an IS-IS 
> packet".
>
> We could in theory not use the TRILL header for IS-IS packets, since 
> in theory
> IS-IS does not need to be encapsulated (for layer 3 IS-IS it runs 
> directly over layer 2).
> But then we'd need a separate Ethertype.
>
> So...if we are going to use the TRILL header, then how do we not get 
> confused
> between TRILL IS-IS and layer 3 IS-IS?
>
> I guess we could assume that it's enough to have TRILL IS-IS use "0" 
> as the area
> address, and use IS-IS as the Ethertype in the inner header. For 
> TRILL-encapsulated
> packets, we actually could choose some weirdo Ethertype (like 0) in 
> the inner header.
> But we still need to differentiate TRILL IS-IS from layer 3 IS-IS on 
> the first hop.
>
> This is probably something I should ask the IS-IS WG, since it really 
> depends on
> idiosyncracies of the current IS-IS implementations.
>
> 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 l4J47GQD002139 for <[e-mail]>; Fri, 18 May 2007 21:07:16 -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]; Fri, 18 May 2007 21:07:02 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.16.160]) 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]; Fri, 18 May 2007 21:07:01 -0700 (PDT)
Date: Fri, 18 May 2007 21:07:34 -0700
From: Radia Perlman <[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
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?
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, 19 May 2007 04:07:24 -0000
Status: RO
Content-Length: 2816

Now that I'm editing the spec to be real specific here, I need a sanity 
check, or
advice from implementers about what would be most convenient for them.

My assumption is that we are removing the per-VLAN instance of IS-IS 
(which could
be added later on, for the purpose of distributing endnode information 
that is more
securely learned, say through a cryptographically authenticated layer 2 
enrollment
protocol). But we are requiring RBridges to learn (ingress RBridge, 
source MAC address)
from packets they are decapsulating onto their link.

So we just have the core instance of IS-IS. We have to make sure layer 3 
IS-IS
packets (which might also be flowing across the campus between routers) 
don't
get confused with TRILL IS-IS. We also have to have RBridges easily 
distinguish
TRILL IS-IS Hellos and LSPs from ordinary encapsulated data packets.

When a router generates an IS-IS packet, the destination address will be 
"all-level1-routers"
or "all-level-2 routers", or perhaps, a specific router (for instance, 
to send a PSNP).
The way this is recognized as an IS-IS packet is due to the EThertype=IS-IS.

RBridge, I believe, should not treat IS-IS packets differently from any 
other "data"
packets. If it's addressed to "all-level1-routers" or 
"all-level2-routers" it would be
treated like any other multidestination packet, encapsulated, and sent 
along a distribution
tree. If it's unicast, it is treated like any other unicast packet by 
RBridges, assuming
the layer 2 address specified in the destination is known to the ingress 
RBridge.

The question is---how are TRILL IS-IS packets encoded?

Could we get a second Ethertype for this? I'm assuming not...

I'm assuming we just have a single Ethertype for "TRILL-encapsulated". 
So we have
to use that.

We could use a different multicast destination address for 
"all-RBridges-for-IS-IS" vs
"all-RBridges" that is used for multicast data.

Or we could have a bit in the TRILL header saying "this is an IS-IS packet".

We could in theory not use the TRILL header for IS-IS packets, since in 
theory
IS-IS does not need to be encapsulated (for layer 3 IS-IS it runs 
directly over layer 2).
But then we'd need a separate Ethertype.

So...if we are going to use the TRILL header, then how do we not get 
confused
between TRILL IS-IS and layer 3 IS-IS?

I guess we could assume that it's enough to have TRILL IS-IS use "0" as 
the area
address, and use IS-IS as the Ethertype in the inner header. For 
TRILL-encapsulated
packets, we actually could choose some weirdo Ethertype (like 0) in the 
inner header.
But we still need to differentiate TRILL IS-IS from layer 3 IS-IS on the 
first hop.

This is probably something I should ask the IS-IS WG, since it really 
depends on
idiosyncracies of the current IS-IS implementations.

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 l4HKF6G0019813 for <[e-mail]>; Thu, 17 May 2007 13:15:06 -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, 17 May 2007 13:15:04 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] All Rbridges Multicast Address
Thread-Index: AceYtMAIPiFnuKPTQZC2AIT9eNT0YAAC0MYw
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "J. R. Rivers" <[e-mail]>
To: "Dino Farinacci" <[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 l4HKF6G0019813
Subject: Re: [rbridge] All Rbridges Multicast Address
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, 17 May 2007 20:15:29 -0000
Status: RO
Content-Length: 1813

I second that opinion.

JR
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Dino Farinacci
> Sent: Thursday, May 17, 2007 11:29 AM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: Re: [rbridge] All Rbridges Multicast Address
> 
> > Since we are an IETF Working group, it seems to me that we should  
> > apply
> > to IANA rather than to the IEEE for the All-Rbridges multicast  
> > address.
> > In fact, they are so plentiful that, as was discussed in the working
> > group earlier
> > (http://www3.ietf.org/proceedings/06jul/slides/trill-4/sld1.htm), I
> > can't see much reason not to apply for the next available 
> block of 16
> > addresses, probably 0x01005E900000 through 0x01005E90000F, 
> where ...0
> > would be the All-Rbridges multicast and the remaining 15 would be
> > reserved for future Rbridge use.
> 
> FYI, 0x00005e is the OUI used for *IPv4* multicast addresses (ala  
> 0x01005e). The IETF also has 0x233300 for IPv6 multicast addresses  
> (ala 0x333300).
> 
> It is of my opinion that any TRILL protocols that run right over an  
> ethertype should not use the above OUI-based multicast addresses.  
> That is, get an OUI from IEEE. Because right now IS-IS uses OUI  
> 0x0180c2 which is not IETF assigned.
> 
> And what's even more important, there may be assumptions in many  
> implementations that if a MAC begins with 0x01005c, the enclosing  
> packet is an IP packet. What comes to mind is IGMP-snooping 
> switches.  
> So let's just avoid this conflict or it will cause a lot of pain for  
> vendors and users of such equipment.
> 
> Dino
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l4HJSADD003518 for <[e-mail]>; Thu, 17 May 2007 12:28:10 -0700 (PDT)
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 6622541; Thu, 17 May 2007 15:28:09 -0400
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks <[e-mail]>
Date: Thu, 17 May 2007 15:28:00 -0400
To: Dino Farinacci <[e-mail]>
X-Mailer: Apple Mail (2.752.3)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] All Rbridges Multicast Address
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, 17 May 2007 19:28:25 -0000
Status: RO
Content-Length: 2164

On May 17, 2007, at 2:28 PM, Dino Farinacci wrote:

>> Since we are an IETF Working group, it seems to me that we should
>> apply
>> to IANA rather than to the IEEE for the All-Rbridges multicast
>> address.
>> In fact, they are so plentiful that, as was discussed in the working
>> group earlier
>> (http://www3.ietf.org/proceedings/06jul/slides/trill-4/sld1.htm), I
>> can't see much reason not to apply for the next available block of 16
>> addresses, probably 0x01005E900000 through 0x01005E90000F, where ...0
>> would be the All-Rbridges multicast and the remaining 15 would be
>> reserved for future Rbridge use.
>
> FYI, 0x00005e is the OUI used for *IPv4* multicast addresses (ala
> 0x01005e). The IETF also has 0x233300 for IPv6 multicast addresses
> (ala 0x333300).
>

For 0x00005e 1/2 of the addresses (where the next bit is a "zero")  
were assigned
by Jon Postal to multicast, and the others (where the next bit is a  
"one") were
used for another project. I believe that this "other project" is long  
irrelevant, but
I have no idea who would release it, whether it is still being used,  
or whether NIC
cards etc. would reject it. If this was going to go forward, this  
would have to be done.


> It is of my opinion that any TRILL protocols that run right over an
> ethertype should not use the above OUI-based multicast addresses.
> That is, get an OUI from IEEE. Because right now IS-IS uses OUI
> 0x0180c2 which is not IETF assigned.
>
> And what's even more important, there may be assumptions in many
> implementations that if a MAC begins with 0x01005c, the enclosing

e not c

> packet is an IP packet. What comes to mind is IGMP-snooping switches.
> So let's just avoid this conflict or it will cause a lot of pain for
> vendors and users of such equipment.
>

I would agree. You could be setting yourself up for years of pain and  
frustration (people
will not go out and replace / upgrade thousands of IGMP-snooping  
switches just because you asked
them too).

> Dino

Regards
Marshall

> _______________________________________________
> 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 l4HISgNc015622 for <[e-mail]>; Thu, 17 May 2007 11:28:42 -0700 (PDT)
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 17 May 2007 11:28:42 -0700
X-IronPort-AV: i="4.14,549,1170662400";  d="scan'208"; a="150554903:sNHT42933753"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4HISgBW003762;  Thu, 17 May 2007 11:28:42 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4HISg20023524; Thu, 17 May 2007 18:28:42 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 17 May 2007 11:28:41 -0700
Received: from [172.28.177.74] ([10.82.210.57]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 17 May 2007 11:28:41 -0700
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Dino Farinacci <[e-mail]>
Date: Thu, 17 May 2007 11:28:31 -0700
To: Eastlake III Donald-LDE008 <[e-mail]>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 17 May 2007 18:28:41.0623 (UTC) FILETIME=[31D82270:01C798B1]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1306; t=1179426522; x=1180290522; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dino=20Farinacci=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20All=20Rbridges=20Multicast=20Address |Sender:=20; bh=A+SZ75G9Qn4MYwyGVqOYf05nPDtKsqBC87OI6clF0nU=; b=I7cU1JGdIyk6OFSaPYPvgWLIX/VGSzI5mNim6yBZZvQDtpmdoTb5y72t8ApYpDZBlN7iQKGD Hs5QZcI9YfngkPXGxfZKfAM1/c/oimc4r6sfgfzKVqknD72b4T5E4n6S;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass (si g 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] All Rbridges Multicast Address
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, 17 May 2007 18:28:54 -0000
Status: RO
Content-Length: 1278

> Since we are an IETF Working group, it seems to me that we should  
> apply
> to IANA rather than to the IEEE for the All-Rbridges multicast  
> address.
> In fact, they are so plentiful that, as was discussed in the working
> group earlier
> (http://www3.ietf.org/proceedings/06jul/slides/trill-4/sld1.htm), I
> can't see much reason not to apply for the next available block of 16
> addresses, probably 0x01005E900000 through 0x01005E90000F, where ...0
> would be the All-Rbridges multicast and the remaining 15 would be
> reserved for future Rbridge use.

FYI, 0x00005e is the OUI used for *IPv4* multicast addresses (ala  
0x01005e). The IETF also has 0x233300 for IPv6 multicast addresses  
(ala 0x333300).

It is of my opinion that any TRILL protocols that run right over an  
ethertype should not use the above OUI-based multicast addresses.  
That is, get an OUI from IEEE. Because right now IS-IS uses OUI  
0x0180c2 which is not IETF assigned.

And what's even more important, there may be assumptions in many  
implementations that if a MAC begins with 0x01005c, the enclosing  
packet is an IP packet. What comes to mind is IGMP-snooping switches.  
So let's just avoid this conflict or it will cause a lot of pain for  
vendors and users of such equipment.

Dino


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 l4HErEjx016033 for <[e-mail]>; Thu, 17 May 2007 07:53:15 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-5.tower-119.messagelabs.com!1179413593!16275454!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 20995 invoked from network); 17 May 2007 14:53:13 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-119.messagelabs.com with SMTP; 17 May 2007 14:53:13 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4HErDLI009886 for <[e-mail]>; Thu, 17 May 2007 07:53:13 -0700 (MST)
Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l4HErDIR002736 for <[e-mail]>; Thu, 17 May 2007 09:53:13 -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 l4HErCnX002726 for <[e-mail]>; Thu, 17 May 2007 09:53:12 -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, 17 May 2007 10:53:12 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: All Rbridges Multicast Address
thread-index: AceUFWVh/C6Yb207Ta+9meTZUTXwywEerEdw
References: <[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 l4HErEjx016033
Subject: [rbridge] All Rbridges Multicast Address
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, 17 May 2007 14:53:20 -0000
Status: RO
Content-Length: 1329

I have been looking further into getting a multicast address for TRILL.
It appears that IANA/IETF owns OUI 0x00005E and thus has 2**24 multicast
and 2*24 unicast addresses for allocation.

All the multicast addresses from 0x01005E000000 to 0x01005E7FFFFF (1/2
of them) have been allocated for IP address derived multicast addresses
[RFC1112]. There is also a draft currently in the MPLS working group
[draft-ietf-mpls-multicast-encaps-04.txt] which requests the allocation
of all multicast addresses from 0x01005E800000 to 0x01005E8FFFFF, or
1/16th of all multicast addresses, for use in connection with MPLS.

This still leaves a huge number of multicast addresses (all of
0x01005E900000 to 0x01005EFFFFFF) available for allocation by IANA.

Since we are an IETF Working group, it seems to me that we should apply
to IANA rather than to the IEEE for the All-Rbridges multicast address.
In fact, they are so plentiful that, as was discussed in the working
group earlier
(http://www3.ietf.org/proceedings/06jul/slides/trill-4/sld1.htm), I
can't see much reason not to apply for the next available block of 16
addresses, probably 0x01005E900000 through 0x01005E90000F, where ...0
would be the All-Rbridges multicast and the remaining 15 would be
reserved for future Rbridge use.

Is there any objection to this?

Thanks,
Donald





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 l4FNvxGo019281 for <[e-mail]>; Tue, 15 May 2007 16:57:59 -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, 15 May 2007 16:57:45 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.16.160]) 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, 15 May 2007 16:57:45 -0700 (PDT)
Date: Tue, 15 May 2007 16:58:18 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Eastlake III Donald-LDE008 <[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]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Rbridge port security
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, 15 May 2007 23:58:20 -0000
Status: RO
Content-Length: 1344

Hmm. I must have not noticed Caitlin's suggestion. I think it's a good 
idea to discard
TRILL-encapsulated frames on links for which you do not have any IS-IS 
ajacency.

I assume this is specific to a VLAN: In other words, if R1 and R2 have a 
VLAN-A
tagged adjacency on
R1's port p,  but R1 has no VLAN B IS-IS adjacency on port p, and
R1 receives a VLAN-B tagged encapsulated packet on port p, R1 should 
drop it, even
though R1 *does* have a VLAN-A tagged IS-IS adjacency on that port.

Radia


Eastlake III Donald-LDE008 wrote:
> In connection with the topics in this thread:
>
> I've looked at IS-IS security some more and the more recent versions of
> it seem to provide strong protection against forged IS-IS hellos or
> other control traffic. This generally seems to be an existing and better
> way of handling this problem than my original suggestion of "turning
> off" IS-IS on a port.
>
> Caitlin's suggestion that TRILL encapsulated frames be ignored when
> received on ports on which there is not an Rbridge adjacency is a good
> one and it could be expanded a little to also drop such frames if their
> source MAC address isn't that of a known Rbridge.
>
> Thanks,
> Donald
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l4E4NXqx010441 for <[e-mail]>; Sun, 13 May 2007 21:23:33 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-13.tower-119.messagelabs.com!1179116611!28085452!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [144.189.100.102]
Received: (qmail 20327 invoked from network); 14 May 2007 04:23:32 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-13.tower-119.messagelabs.com with SMTP; 14 May 2007 04:23:32 -0000
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l4E4NVd9021158 for <[e-mail]>; Sun, 13 May 2007 21:23:31 -0700 (MST)
Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l4E4NUeZ007364 for <[e-mail]>; Sun, 13 May 2007 23:23:31 -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 l4E4NTu8007354 for <[e-mail]>; Sun, 13 May 2007 23:23:30 -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, 14 May 2007 00:23:28 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RE: [rbridge] Rbridge port security
thread-index: AceV357usx8lCp5vQAip9w9ZFH2wRQ==
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 l4E4NXqx010441
Subject: Re: [rbridge] Rbridge port security
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, 14 May 2007 04:23:38 -0000
Status: RO
Content-Length: 630

In connection with the topics in this thread:

I've looked at IS-IS security some more and the more recent versions of
it seem to provide strong protection against forged IS-IS hellos or
other control traffic. This generally seems to be an existing and better
way of handling this problem than my original suggestion of "turning
off" IS-IS on a port.

Caitlin's suggestion that TRILL encapsulated frames be ignored when
received on ports on which there is not an Rbridge adjacency is a good
one and it could be expanded a little to also drop such frames if their
source MAC address isn't that of a known Rbridge.

Thanks,
Donald



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l4AJI1Y6025256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 10 May 2007 12:18:01 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l4AJHhG8001513; Thu, 10 May 2007 14:17:43 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 10 May 2007 14:17:59 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 10 May 2007 14:17:59 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Per-VLAN DRB elections?
Thread-Index: AceSPJEoOjP7TikDTnyvikryCGz+hAA1nC+QAAPe6FA=
References: <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 10 May 2007 19:17:59.0331 (UTC) FILETIME=[EBE24F30:01C79337]
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 l4AJI1Y6025256
Cc: [e-mail]
Subject: Re: [rbridge] Per-VLAN DRB elections?
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, 10 May 2007 19:18:27 -0000
Status: RO
Content-Length: 5608

Donald,

	While I agree that symmetric mappings will prevent confusion 
of the type that Radia seems to be concerned about, it is (I believe)
generally felt to be a bad idea to have such mappings within a single
administrative domain.

	As I understand it, the issue is that there are other mechanisms
that are (or may be) aware of VLAN tags as they are locally used and
these mechansism will require "re-mapping" as well.

	Hence, while I am unsure of Radia's reasoning, I am okay with
her
conclusion that it is a really bad idea within an RBridge campus.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Thursday, May 10, 2007 11:20 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [rbridge] Per-VLAN DRB elections?
> 
> Hi Radia,
> 
> I don't completely understand your proposal point (d) where you say it
> is fatal if VLAN tags are mapped between each other inside a bridged
> LAN. Assuming the mapping in symmetric, wouldn't Hellos also 
> get mapped
> between VLANs so the two DRs you suggest would see each other and you
> would only end up with only one DR?
> 
> Donald
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On
> Behalf Of [e-mail]
> Sent: Wednesday, May 09, 2007 9:12 AM
> To: [e-mail]
> Subject: [rbridge] Per-VLAN DRB elections?
> 
> I think we haven't discussed this one on the list yet.
> 
> Bridges can be configured to not forward certain VLANs on 
> certain links.
> So, a "level 2 cloud" (a bunch of links connected with bridges) can be
> partitioned
> with respect to various VLANs. So, for instance, RBridges R1 
> and R2 can
> be
> neighbors on a cloud with respect to VLAN A, but not with VLAN B. In
> other
> words, a packet tagged with "VLAN A" will get from R1 to R2, but one
> tagged
> with "VLAN B" will not...even if both R1 and R2 think they 
> are connected
> to VLAN B.
> 
> Oh...this is somewhat related to listening instead of participating in
> the bridge spanning tree, which I will clarify in a separate thread.
> 
> 
> Some issues with bridges not forwarding all VLANs:
> 
> a) If the IS-IS DRB (Designated RBridge)
> election messages are tagged with VLAN B, then we will wind up
> with two DRBs for the link (scary)
> 
> b) if R1 is selected DRB for the link, it may not be able to serve all
> endnodes (since
> R1 might not be able to reach certain endnodes on some VLANs
> 
> c) in theory, DRB election should be separately carried out for each
> possible VLAN tag
> (4000 of them). That would be too much.
> 
> d) there was a suggestion that it might be a feature to allow load
> sharing off a layer 2
> cloud by having separate DRBs for different VLANs
> 
> So...here's a first strawman proposal, partially based on my memory of
> hallway conversations:
> 
> a) for the zero configuration case, assume that without configuration,
> the DRB election
> is carried out once, tagged with VLAN 1. Whoever gets elected 
> DRB in the
> DRB election
> tagged with VLAN 1 is DRB for all VLANs on that link.
> 
> b) RBridges may be configured with other VLAN tags to also, 
> on the same
> port, participate
> in an IS-IS election with. DRB priority may be configured to be
> different for different VLANs, so
> R1 might be configured, on port a, to participate in a DRB 
> election for
> VLAN A with priority 7,
> and VLAN B with priority 9
> 
> c) In the core instance of IS-IS, R1 announces not just which VLANs it
> is attached to, but
> the Root bridge ID for that VLAN. That way, if R1 finds out (by seeing
> R2's link state packets)
> that R2 claims to be DRB for VLAN A, with root bridge 89, and 
> R1 thinks
> that it is DRB for VLAN A,
> root bridge 89, then one of them should back off (using system ID as a
> tie breaker), where
> "back off" means "stop acting as DRB", i.e., don't
> encapsulate/decapsulate data packets
> to/from that port with respect to that VLAN
> 
> d) it is absolutely gross misconfiguration, and a disaster, if within
> the layer 2 cloud, a VLAN tag
> can turn into another VLAN tag, because this could cause R1, 
> who is DRB
> for
> that link for VLAN A, to decapsulate a frame onto the link, 
> which might
> pop out to
> R2, who is DRB for that link for VLAN B, to see the packet as "VLAN B"
> 
> I *think* my proposal above has the following properties:
> 
> 1) if a link is genuinely partitioned with respect to VLAN A, 
> then there
> will be two DRBs elected
> for that link, and all endnodes on that link in VLAN A will 
> be reachable
> via one or the other
> DRBs, and no link will be formed
> 
> 2) as long as a VLAN tag can't get converted to another VLAN 
> tag within
> the layer 2
> cloud there will not be loops formed by having two DRBs on the same
> layer 2 cloud
> 
> 3) we can do load sharing (R1 will be DRB for VLAN A and R2 
> will be for
> VLAN B)
> 
> 4) if R1 and R2 wind up both elected as DRB for VLAN A and 
> VLAN A is not
> actually
> partitioned (but R1 can't reach R2), then they'll discover 
> this through
> the core instance
> IS-IS announcements
> 
> 5) the common case can still be zero configuration
> 
> Comments?
> 
> 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 mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l4AFK7xB023291 for <[e-mail]>; Thu, 10 May 2007 08:20:07 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-119.messagelabs.com!1178810399!20384107!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 16728 invoked from network); 10 May 2007 15:19:59 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-119.messagelabs.com with SMTP; 10 May 2007 15:19:59 -0000
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4AFJxVA007335 for <[e-mail]>; Thu, 10 May 2007 08:19:59 -0700 (MST)
Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l4AFJwa6012946 for <[e-mail]>; Thu, 10 May 2007 10:19:58 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l4AFJvcY012936 for <[e-mail]>; Thu, 10 May 2007 10:19:58 -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, 10 May 2007 11:19:56 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Per-VLAN DRB elections?
thread-index: AceSPJEoOjP7TikDTnyvikryCGz+hAA1nC+Q
References: <[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 l4AFK7xB023291
Cc: [e-mail]
Subject: Re: [rbridge] Per-VLAN DRB elections?
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, 10 May 2007 15:20:20 -0000
Status: RO
Content-Length: 4263

Hi Radia,

I don't completely understand your proposal point (d) where you say it
is fatal if VLAN tags are mapped between each other inside a bridged
LAN. Assuming the mapping in symmetric, wouldn't Hellos also get mapped
between VLANs so the two DRs you suggest would see each other and you
would only end up with only one DR?

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: Wednesday, May 09, 2007 9:12 AM
To: [e-mail]
Subject: [rbridge] Per-VLAN DRB elections?

I think we haven't discussed this one on the list yet.

Bridges can be configured to not forward certain VLANs on certain links.
So, a "level 2 cloud" (a bunch of links connected with bridges) can be
partitioned
with respect to various VLANs. So, for instance, RBridges R1 and R2 can
be
neighbors on a cloud with respect to VLAN A, but not with VLAN B. In
other
words, a packet tagged with "VLAN A" will get from R1 to R2, but one
tagged
with "VLAN B" will not...even if both R1 and R2 think they are connected
to VLAN B.

Oh...this is somewhat related to listening instead of participating in
the bridge spanning tree, which I will clarify in a separate thread.


Some issues with bridges not forwarding all VLANs:

a) If the IS-IS DRB (Designated RBridge)
election messages are tagged with VLAN B, then we will wind up
with two DRBs for the link (scary)

b) if R1 is selected DRB for the link, it may not be able to serve all
endnodes (since
R1 might not be able to reach certain endnodes on some VLANs

c) in theory, DRB election should be separately carried out for each
possible VLAN tag
(4000 of them). That would be too much.

d) there was a suggestion that it might be a feature to allow load
sharing off a layer 2
cloud by having separate DRBs for different VLANs

So...here's a first strawman proposal, partially based on my memory of
hallway conversations:

a) for the zero configuration case, assume that without configuration,
the DRB election
is carried out once, tagged with VLAN 1. Whoever gets elected DRB in the
DRB election
tagged with VLAN 1 is DRB for all VLANs on that link.

b) RBridges may be configured with other VLAN tags to also, on the same
port, participate
in an IS-IS election with. DRB priority may be configured to be
different for different VLANs, so
R1 might be configured, on port a, to participate in a DRB election for
VLAN A with priority 7,
and VLAN B with priority 9

c) In the core instance of IS-IS, R1 announces not just which VLANs it
is attached to, but
the Root bridge ID for that VLAN. That way, if R1 finds out (by seeing
R2's link state packets)
that R2 claims to be DRB for VLAN A, with root bridge 89, and R1 thinks
that it is DRB for VLAN A,
root bridge 89, then one of them should back off (using system ID as a
tie breaker), where
"back off" means "stop acting as DRB", i.e., don't
encapsulate/decapsulate data packets
to/from that port with respect to that VLAN

d) it is absolutely gross misconfiguration, and a disaster, if within
the layer 2 cloud, a VLAN tag
can turn into another VLAN tag, because this could cause R1, who is DRB
for
that link for VLAN A, to decapsulate a frame onto the link, which might
pop out to
R2, who is DRB for that link for VLAN B, to see the packet as "VLAN B"

I *think* my proposal above has the following properties:

1) if a link is genuinely partitioned with respect to VLAN A, then there
will be two DRBs elected
for that link, and all endnodes on that link in VLAN A will be reachable
via one or the other
DRBs, and no link will be formed

2) as long as a VLAN tag can't get converted to another VLAN tag within
the layer 2
cloud there will not be loops formed by having two DRBs on the same
layer 2 cloud

3) we can do load sharing (R1 will be DRB for VLAN A and R2 will be for
VLAN B)

4) if R1 and R2 wind up both elected as DRB for VLAN A and VLAN A is not
actually
partitioned (but R1 can't reach R2), then they'll discover this through
the core instance
IS-IS announcements

5) the common case can still be zero configuration

Comments?

Radia



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



Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l4ADaik5025335 for <[e-mail]>; Thu, 10 May 2007 06:36:44 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-14.tower-153.messagelabs.com!1178804203!9490088!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [144.189.100.105]
Received: (qmail 21831 invoked from network); 10 May 2007 13:36:43 -0000
Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-14.tower-153.messagelabs.com with SMTP; 10 May 2007 13:36:43 -0000
Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l4ADadkG014211 for <[e-mail]>; Thu, 10 May 2007 06:36:43 -0700 (MST)
Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l4ADac9L008006 for <[e-mail]>; Thu, 10 May 2007 08:36:39 -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 l4ADab5W007998 for <[e-mail]>; Thu, 10 May 2007 08:36:37 -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, 10 May 2007 09:36:35 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: TRILL Header Extensions
thread-index: AceTCDqXWcupe+VfRL+9nozYS6ORCA==
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 l4ADaik5025335
Subject: [rbridge] TRILL Header Extensions
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, 10 May 2007 13:37:16 -0000
Status: RO
Content-Length: 180

We have determined that the working group consensus is the "Solution 1"
format to provide for space for extensions/options as part of the TRILL
Header.

Donald and Erik
Co-chairs



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 l4A3Zkxt014725 for <[e-mail]>; Wed, 9 May 2007 20:35:46 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-9.tower-153.messagelabs.com!1178768145!6557842!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.9]
Received: (qmail 25991 invoked from network); 10 May 2007 03:35:45 -0000
Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-9.tower-153.messagelabs.com with SMTP; 10 May 2007 03:35:45 -0000
Received: from az33exr02.mot.com ([10.64.251.232]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l4A3ZiHr002004 for <[e-mail]>; Wed, 9 May 2007 22:35:44 -0500 (CDT)
Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l4A3Zhkb017479 for <[e-mail]>; Wed, 9 May 2007 22:35:43 -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 l4A3Zg7l017457 for <[e-mail]>; Wed, 9 May 2007 22:35:42 -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, 9 May 2007 23:35:37 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ARP/ND Optimization
thread-index: AceStEYH5aUFS8mpTQyvnZefM7DJBw==
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 l4A3Zkxt014725
Subject: [rbridge] ARP/ND Optimization
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, 10 May 2007 03:36:00 -0000
Status: RO
Content-Length: 218

Hi,

We have determined that the working group consensus is to consider TRILL
ARP/ND optimization optional, remove it from the main protocol
specification, and place it in a separate draft.

Donald and Erik
Co-chairs



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 l49LBBXc020732 for <[e-mail]>; Wed, 9 May 2007 14:11:12 -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: Wed, 9 May 2007 14:11:06 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Per-VLAN DRB elections?
Thread-Index: AceSPQHdQApQW2S6Tfmoxu+dK8y8PwAFGwfgAAGC9qAAA+K4sAAEP2uQAAF4s4A=
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>, "Eric Gray \(LO/EUS\)" <[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 l49LBBXc020732
Cc: [e-mail]
Subject: Re: [rbridge] Per-VLAN DRB elections?
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, 09 May 2007 21:11:22 -0000
Status: RO
Content-Length: 2187

Caitlin,

> -----Original Message-----
> From: Caitlin Bestler [mailto:[e-mail]]
> Sent: Wednesday, May 09, 2007 1:30 PM
> To: Silvano Gai; Eric Gray (LO/EUS); [e-mail]
> Cc: [e-mail]
> Subject: RE: [rbridge] Per-VLAN DRB elections?
> 
> Silvano Gai wrote:
> > Caitlin,
> >
> 
> >>
> >> I agree with your approach, but differ on one very specific point.
> >> The one aspect of this model that I think is unacceptable is that
it
> >> *requires* the RBridge to represent each VLAN instance separately.
> >> As covered on prior threads this is not always desirable. But once
> >> you allow RBridges that wish to support these features to do so (by
> >> allowing them to publish 'VLAN Group' information) then the rest of
> >> the interactions can indeed follow the simple model of thinking one
> >> VLAN at a time.
> >
> > There is no externally visible VLAN grouping information in
> > legacy bridges and I am against having any externally visible
> > VLAN grouping information in RBridges.
> >
> > The fact that internally RBridges may group VLANs is an
> > implementation detail, exactly like in legacy bridges.
> >
> 
> An RBridge that does support VLAN Grouping is not required to
> do anything with this information. It is clearly of value and
> leads to simpler configuration for RBridges that do support
> VLAN Grouping. I don't see the value in excluding information
> that has no real cost to other RBridges from the exchanged
> information. We are talking about one extra VLAN-ID in the
> per-VLAN instance (an optional VLAN ID of the master group).
> It is easily initialized to NULL, and even more easily ignored.
> 

If the VLAN grouping is FYI only, I don't have a big objection, but I
still don't understand why TRILL needs to deal with it in the basic
protocol draft. Why don't you write a separate draft that defines a
separate IS-IS TLV to carry this information?

It can still be done in the TRILL WG.

-- Silvano 

> If RBridge implementations are allowed to support VLAN Groups
> *anyway* then the benefit of having this information available
> in a standard way clearly outweighs the cost of two bytes of
> storage per instance.




Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l49KVKwC011473 for <[e-mail]>; Wed, 9 May 2007 13:31:20 -0700 (PDT)
Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Wed, 09 May 2007 13:31:13 -0700
X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 3782E2B7; Wed, 9 May 2007 13:31:13 -0700 (PDT)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id BE5D62AE; Wed, 9 May 2007 13:31:12 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FGZ35935; Wed, 9 May 2007 13:30:50 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 5426869CC1; Wed, 9 May 2007 13:30:49 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 9 May 2007 13:30:18 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] Per-VLAN DRB elections?
Thread-Index: AceSPQHdQApQW2S6Tfmoxu+dK8y8PwAFGwfgAAGC9qAAA+K4sAAEP2uQ
From: "Caitlin Bestler" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Eric Gray (LO/EUS)" <[e-mail]>, [e-mail]
X-WSS-ID: 6A5CF01B37027126842-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l49KVKwC011473
Cc: [e-mail]
Subject: Re: [rbridge] Per-VLAN DRB elections?
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, 09 May 2007 20:31:51 -0000
Status: RO
Content-Length: 1544

Silvano Gai wrote:
> Caitlin,
> 

>> 
>> I agree with your approach, but differ on one very specific point.
>> The one aspect of this model that I think is unacceptable is that it
>> *requires* the RBridge to represent each VLAN instance separately.
>> As covered on prior threads this is not always desirable. But once
>> you allow RBridges that wish to support these features to do so (by
>> allowing them to publish 'VLAN Group' information) then the rest of
>> the interactions can indeed follow the simple model of thinking one
>> VLAN at a time.
> 
> There is no externally visible VLAN grouping information in
> legacy bridges and I am against having any externally visible
> VLAN grouping information in RBridges.
> 
> The fact that internally RBridges may group VLANs is an
> implementation detail, exactly like in legacy bridges.
> 

An RBridge that does support VLAN Grouping is not required to
do anything with this information. It is clearly of value and
leads to simpler configuration for RBridges that do support
VLAN Grouping. I don't see the value in excluding information
that has no real cost to other RBridges from the exchanged
information. We are talking about one extra VLAN-ID in the
per-VLAN instance (an optional VLAN ID of the master group).
It is easily initialized to NULL, and even more easily ignored.

If RBridge implementations are allowed to support VLAN Groups
*anyway* then the benefit of having this information available
in a standard way clearly outweighs the cost of two bytes of
storage per instance.




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 l49IPgsh012960 for <[e-mail]>; Wed, 9 May 2007 11:25:42 -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: Wed, 9 May 2007 11:25:39 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Per-VLAN DRB elections?
Thread-Index: AceSPQHdQApQW2S6Tfmoxu+dK8y8PwAFGwfgAAGC9qAAA+K4sA==
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>, "Eric Gray \(LO/EUS\)" <[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 l49IPgsh012960
Cc: [e-mail]
Subject: Re: [rbridge] Per-VLAN DRB elections?
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, 09 May 2007 18:26:19 -0000
Status: RO
Content-Length: 3233

Caitlin,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Caitlin Bestler
> Sent: Wednesday, May 09, 2007 9:40 AM
> To: Eric Gray (LO/EUS); [e-mail]
> Cc: [e-mail]
> Subject: Re: [rbridge] Per-VLAN DRB elections?
> 
> [e-mail] wrote:
> > Radia,
> >
> > 	This gets back to "what is the logical model for
> > RBridge interactions with VLANs."
> >
> > 	If - as Joe has suggested at least once - the logical
> > model for an RBridge (instance) is specific to a single VLAN,
> > then this becomes very straight-forward.  All of the RBridges
> > in a single logical campus are necessarily in the same VLAN.
> >
> > 	There may be no VLANs - equating to a single logical
> > VLAN consisting of the untagged (default) VLAN.
> >
> > 	There may actually be an overlay of any number (up to
> > 4K) of VLANs that use a deployment of RBridge devices, where
> > each device has at least one RBridge logical instance for any
> > VLAN in which it is configured to participate.
> >
> > 	The elegance of this logical model is that there is L2
> > connectivity between only those RBridge instances that are
> > configured to participate in a common VLAN.  Hence, there is
> > a DRB election process that only includes RBridges that are
> > in the same VLAN, on any shared connectivity link.
> >
> > 	The advantage of this elegance is that it allows us to
> > define actual protocol interactions exactly as if there is
> > only one VLAN (which may be the default, unconfigured and
> > untagged VLAN).  It then is up to the implementers to "do the
> > right thing" as far as implementing 802.1Q correctly.
> >
> > 	This - in my opinion - is the way things should be
> > done, and I am curious as to who finds this model to be
unacceptable,
> > and why...
> >
> >
> 
> I agree with your approach, but differ on one very specific point.
> The one aspect of this model that I think is unacceptable is that
> it *requires* the RBridge to represent each VLAN instance separately.
> As covered on prior threads this is not always desirable. But once
> you allow RBridges that wish to support these features to do so
> (by allowing them to publish 'VLAN Group' information) then the
> rest of the interactions can indeed follow the simple model of
> thinking one VLAN at a time.

There is no externally visible VLAN grouping information in legacy
bridges and I am against having any externally visible VLAN grouping
information in RBridges.

The fact that internally RBridges may group VLANs is an implementation
detail, exactly like in legacy bridges.

-- Silvano

> 
> So taken as an absolute I do find exception to the model you propose,
> but I believe it is an exception that is more of an asterisk than a
> serious problem. If others have problems with the "per VLAN" approach
> I'd encourage them to do something similar that allows the feature
> they are considering while allowing RBridges not involved with that
> feature to keep the simple model of thinking about each VLAN
separately.
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l49HM7TV028232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 9 May 2007 10:22:07 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l49HLlwF015051; Wed, 9 May 2007 12:21:47 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 9 May 2007 12:22:06 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 May 2007 12:22:04 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Per-VLAN DRB elections?
Thread-Index: AceSPQHdQApQW2S6Tfmoxu+dK8y8PwAFGwfgAAJIiiAAAM9cUA==
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 09 May 2007 17:22:06.0114 (UTC) FILETIME=[9107D820:01C7925E]
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 l49HM7TV028232
Cc: [e-mail]
Subject: Re: [rbridge] Per-VLAN DRB elections?
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, 09 May 2007 17:22:16 -0000
Status: RO
Content-Length: 8234

Radia,

	To add to what Silvano is saying, if the logical model is 
that RBridge interactions are only defined for a single VLAN, 
then it naturally follows that a DRB election will be for a 
single VLAN.

	The "instancing" implication implied by this logical model
means that an RBridge device may have more complicated things to
do, but the definition of those things is "compartmented" - i.e.
- there are clear distinctions between L2 routing (TRILL), L3 
routing and 802.1Q bridging.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Wednesday, May 09, 2007 1:00 PM
> To: Eric Gray (LO/EUS); [e-mail]
> Cc: [e-mail]
> Subject: RE: [rbridge] Per-VLAN DRB elections?
> Importance: High
> 
> 
> The DR election MUST be per VLAN. There is no other way.
> 
> Given any two RBridges they may be connected on some VLANs and not on
> others.
> 
> Let's suppose that RB1 and RB2 are connected on VLAN 1 and 
> not on VLAN2.
> 
> One of the two needs to be elected as DR on VLAN1 and the 
> other will be
> blocked, but both will be DR on VLAN 2. See drawing below.
> 
> +---------+        +----------+
> |  RB1    |--------|  RB2     |
> +---------+        +----------+
>      | p1                |p2
> +---------+        +----------+
> |   B1    |--------|   B2     |
> +---------+    x   +----------+
> 
> All links are in VLAN 1 and 2 except link x that is only in VLAN 1.
> On P1 RB1 is blocked on 1 and forwarding on 2.
> On P2 RB2 is forwarding on both.
> 
> -- Silvano
> 
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eric Gray (LO/EUS)
> > Sent: Wednesday, May 09, 2007 9:07 AM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [rbridge] Per-VLAN DRB elections?
> > 
> > Radia,
> > 
> > 	This gets back to "what is the logical model for RBridge
> > interactions with VLANs."
> > 
> > 	If - as Joe has suggested at least once - the logical
> > model for an RBridge (instance) is specific to a single VLAN,
> > then this becomes very straight-forward.  All of the RBridges
> > in a single logical campus are necessarily in the same VLAN.
> > 
> > 	There may be no VLANs - equating to a single logical
> > VLAN consisting of the untagged (default) VLAN.
> > 
> > 	There may actually be an overlay of any number (up to
> > 4K) of VLANs that use a deployment of RBridge devices, where
> > each device has at least one RBridge logical instance for any
> > VLAN in which it is configured to participate.
> > 
> > 	The elegance of this logical model is that there is L2
> > connectivity between only those RBridge instances that are
> > configured to participate in a common VLAN.  Hence, there is
> > a DRB election process that only includes RBridges that are
> > in the same VLAN, on any shared connectivity link.
> > 
> > 	The advantage of this elegance is that it allows us to
> > define actual protocol interactions exactly as if there is
> > only one VLAN (which may be the default, unconfigured and
> > untagged VLAN).  It then is up to the implementers to "do
> > the right thing" as far as implementing 802.1Q correctly.
> > 
> > 	This - in my opinion - is the way things should be
> > done, and I am curious as to who finds this model to be
> > unacceptable, and why...
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of
> [e-mail]
> > > Sent: Wednesday, May 09, 2007 9:12 AM
> > > To: [e-mail]
> > > Subject: [rbridge] Per-VLAN DRB elections?
> > >
> > > I think we haven't discussed this one on the list yet.
> > >
> > > Bridges can be configured to not forward certain VLANs on
> > > certain links.
> > > So, a "level 2 cloud" (a bunch of links connected with
> > > bridges) can be partitioned
> > > with respect to various VLANs. So, for instance, RBridges R1
> > > and R2 can be
> > > neighbors on a cloud with respect to VLAN A, but not with
> > > VLAN B. In other
> > > words, a packet tagged with "VLAN A" will get from R1 to R2,
> > > but one tagged
> > > with "VLAN B" will not...even if both R1 and R2 think they
> > > are connected to VLAN B.
> > >
> > > Oh...this is somewhat related to listening instead of 
> participating
> in
> > > the bridge spanning tree, which I will clarify in a 
> separate thread.
> > >
> > >
> > > Some issues with bridges not forwarding all VLANs:
> > >
> > > a) If the IS-IS DRB (Designated RBridge)
> > > election messages are tagged with VLAN B, then we will wind up
> > > with two DRBs for the link (scary)
> > >
> > > b) if R1 is selected DRB for the link, it may not be able to
> > > serve all endnodes (since
> > > R1 might not be able to reach certain endnodes on some VLANs
> > >
> > > c) in theory, DRB election should be separately carried out
> > > for each possible VLAN tag
> > > (4000 of them). That would be too much.
> > >
> > > d) there was a suggestion that it might be a feature to allow
> > > load sharing off a layer 2
> > > cloud by having separate DRBs for different VLANs
> > >
> > > So...here's a first strawman proposal, partially based on my
> > > memory of hallway conversations:
> > >
> > > a) for the zero configuration case, assume that without
> > > configuration, the DRB election
> > > is carried out once, tagged with VLAN 1. Whoever gets elected
> > > DRB in the DRB election
> > > tagged with VLAN 1 is DRB for all VLANs on that link.
> > >
> > > b) RBridges may be configured with other VLAN tags to also,
> > > on the same port, participate
> > > in an IS-IS election with. DRB priority may be configured to
> > > be different for different VLANs, so
> > > R1 might be configured, on port a, to participate in a DRB
> > > election for VLAN A with priority 7,
> > > and VLAN B with priority 9
> > >
> > > c) In the core instance of IS-IS, R1 announces not just which
> > > VLANs it is attached to, but
> > > the Root bridge ID for that VLAN. That way, if R1 finds out
> > > (by seeing R2's link state packets)
> > > that R2 claims to be DRB for VLAN A, with root bridge 89, and
> > > R1 thinks that it is DRB for VLAN A,
> > > root bridge 89, then one of them should back off (using
> > > system ID as a tie breaker), where
> > > "back off" means "stop acting as DRB", i.e., don't
> > > encapsulate/decapsulate data packets
> > > to/from that port with respect to that VLAN
> > >
> > > d) it is absolutely gross misconfiguration, and a disaster,
> > > if within the layer 2 cloud, a VLAN tag
> > > can turn into another VLAN tag, because this could cause R1,
> > > who is DRB for
> > > that link for VLAN A, to decapsulate a frame onto the link,
> > > which might pop out to
> > > R2, who is DRB for that link for VLAN B, to see the 
> packet as "VLAN
> B"
> > >
> > > I *think* my proposal above has the following properties:
> > >
> > > 1) if a link is genuinely partitioned with respect to VLAN A,
> > > then there will be two DRBs elected
> > > for that link, and all endnodes on that link in VLAN A will
> > > be reachable via one or the other
> > > DRBs, and no link will be formed
> > >
> > > 2) as long as a VLAN tag can't get converted to another VLAN
> > > tag within the layer 2
> > > cloud there will not be loops formed by having two DRBs on
> > > the same layer 2 cloud
> > >
> > > 3) we can do load sharing (R1 will be DRB for VLAN A and R2
> > > will be for VLAN B)
> > >
> > > 4) if R1 and R2 wind up both elected as DRB for VLAN A and
> > > VLAN A is not actually
> > > partitioned (but R1 can't reach R2), then they'll discover
> > > this through the core instance
> > > IS-IS announcements
> > >
> > > 5) the common case can still be zero configuration
> > >
> > > Comments?
> > >
> > > 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 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 l49H0Ajb022004 for <[e-mail]>; Wed, 9 May 2007 10:00: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: Wed, 9 May 2007 10:00:07 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Per-VLAN DRB elections?
Thread-Index: AceSPQHdQApQW2S6Tfmoxu+dK8y8PwAFGwfgAAJIiiA=
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[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 l49H0Ajb022004
Cc: [e-mail]
Subject: Re: [rbridge] Per-VLAN DRB elections?
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, 09 May 2007 17:00:17 -0000
Status: RO
Content-Length: 7018

The DR election MUST be per VLAN. There is no other way.

Given any two RBridges they may be connected on some VLANs and not on
others.

Let's suppose that RB1 and RB2 are connected on VLAN 1 and not on VLAN2.

One of the two needs to be elected as DR on VLAN1 and the other will be
blocked, but both will be DR on VLAN 2. See drawing below.

+---------+        +----------+
|  RB1    |--------|  RB2     |
+---------+        +----------+
     | p1                |p2
+---------+        +----------+
|   B1    |--------|   B2     |
+---------+    x   +----------+

All links are in VLAN 1 and 2 except link x that is only in VLAN 1.
On P1 RB1 is blocked on 1 and forwarding on 2.
On P2 RB2 is forwarding on both.

-- Silvano




> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Wednesday, May 09, 2007 9:07 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [rbridge] Per-VLAN DRB elections?
> 
> Radia,
> 
> 	This gets back to "what is the logical model for RBridge
> interactions with VLANs."
> 
> 	If - as Joe has suggested at least once - the logical
> model for an RBridge (instance) is specific to a single VLAN,
> then this becomes very straight-forward.  All of the RBridges
> in a single logical campus are necessarily in the same VLAN.
> 
> 	There may be no VLANs - equating to a single logical
> VLAN consisting of the untagged (default) VLAN.
> 
> 	There may actually be an overlay of any number (up to
> 4K) of VLANs that use a deployment of RBridge devices, where
> each device has at least one RBridge logical instance for any
> VLAN in which it is configured to participate.
> 
> 	The elegance of this logical model is that there is L2
> connectivity between only those RBridge instances that are
> configured to participate in a common VLAN.  Hence, there is
> a DRB election process that only includes RBridges that are
> in the same VLAN, on any shared connectivity link.
> 
> 	The advantage of this elegance is that it allows us to
> define actual protocol interactions exactly as if there is
> only one VLAN (which may be the default, unconfigured and
> untagged VLAN).  It then is up to the implementers to "do
> the right thing" as far as implementing 802.1Q correctly.
> 
> 	This - in my opinion - is the way things should be
> done, and I am curious as to who finds this model to be
> unacceptable, and why...
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of
[e-mail]
> > Sent: Wednesday, May 09, 2007 9:12 AM
> > To: [e-mail]
> > Subject: [rbridge] Per-VLAN DRB elections?
> >
> > I think we haven't discussed this one on the list yet.
> >
> > Bridges can be configured to not forward certain VLANs on
> > certain links.
> > So, a "level 2 cloud" (a bunch of links connected with
> > bridges) can be partitioned
> > with respect to various VLANs. So, for instance, RBridges R1
> > and R2 can be
> > neighbors on a cloud with respect to VLAN A, but not with
> > VLAN B. In other
> > words, a packet tagged with "VLAN A" will get from R1 to R2,
> > but one tagged
> > with "VLAN B" will not...even if both R1 and R2 think they
> > are connected to VLAN B.
> >
> > Oh...this is somewhat related to listening instead of participating
in
> > the bridge spanning tree, which I will clarify in a separate thread.
> >
> >
> > Some issues with bridges not forwarding all VLANs:
> >
> > a) If the IS-IS DRB (Designated RBridge)
> > election messages are tagged with VLAN B, then we will wind up
> > with two DRBs for the link (scary)
> >
> > b) if R1 is selected DRB for the link, it may not be able to
> > serve all endnodes (since
> > R1 might not be able to reach certain endnodes on some VLANs
> >
> > c) in theory, DRB election should be separately carried out
> > for each possible VLAN tag
> > (4000 of them). That would be too much.
> >
> > d) there was a suggestion that it might be a feature to allow
> > load sharing off a layer 2
> > cloud by having separate DRBs for different VLANs
> >
> > So...here's a first strawman proposal, partially based on my
> > memory of hallway conversations:
> >
> > a) for the zero configuration case, assume that without
> > configuration, the DRB election
> > is carried out once, tagged with VLAN 1. Whoever gets elected
> > DRB in the DRB election
> > tagged with VLAN 1 is DRB for all VLANs on that link.
> >
> > b) RBridges may be configured with other VLAN tags to also,
> > on the same port, participate
> > in an IS-IS election with. DRB priority may be configured to
> > be different for different VLANs, so
> > R1 might be configured, on port a, to participate in a DRB
> > election for VLAN A with priority 7,
> > and VLAN B with priority 9
> >
> > c) In the core instance of IS-IS, R1 announces not just which
> > VLANs it is attached to, but
> > the Root bridge ID for that VLAN. That way, if R1 finds out
> > (by seeing R2's link state packets)
> > that R2 claims to be DRB for VLAN A, with root bridge 89, and
> > R1 thinks that it is DRB for VLAN A,
> > root bridge 89, then one of them should back off (using
> > system ID as a tie breaker), where
> > "back off" means "stop acting as DRB", i.e., don't
> > encapsulate/decapsulate data packets
> > to/from that port with respect to that VLAN
> >
> > d) it is absolutely gross misconfiguration, and a disaster,
> > if within the layer 2 cloud, a VLAN tag
> > can turn into another VLAN tag, because this could cause R1,
> > who is DRB for
> > that link for VLAN A, to decapsulate a frame onto the link,
> > which might pop out to
> > R2, who is DRB for that link for VLAN B, to see the packet as "VLAN
B"
> >
> > I *think* my proposal above has the following properties:
> >
> > 1) if a link is genuinely partitioned with respect to VLAN A,
> > then there will be two DRBs elected
> > for that link, and all endnodes on that link in VLAN A will
> > be reachable via one or the other
> > DRBs, and no link will be formed
> >
> > 2) as long as a VLAN tag can't get converted to another VLAN
> > tag within the layer 2
> > cloud there will not be loops formed by having two DRBs on
> > the same layer 2 cloud
> >
> > 3) we can do load sharing (R1 will be DRB for VLAN A and R2
> > will be for VLAN B)
> >
> > 4) if R1 and R2 wind up both elected as DRB for VLAN A and
> > VLAN A is not actually
> > partitioned (but R1 can't reach R2), then they'll discover
> > this through the core instance
> > IS-IS announcements
> >
> > 5) the common case can still be zero configuration
> >
> > Comments?
> >
> > 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 MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l49GeSfd016873 for <[e-mail]>; Wed, 9 May 2007 09:40:28 -0700 (PDT)
Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Wed, 09 May 2007 09:40:23 -0700
X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 10D142B1; Wed, 9 May 2007 09:40:23 -0700 (PDT)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id DE8AD2AF; Wed, 9 May 2007 09:40:22 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FGY96769; Wed, 9 May 2007 09:40:18 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id E0E1A69CA3; Wed, 9 May 2007 09:40:17 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 9 May 2007 09:39:47 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] Per-VLAN DRB elections?
Thread-Index: AceSPQHdQApQW2S6Tfmoxu+dK8y8PwAFGwfgAAGC9qA=
From: "Caitlin Bestler" <[e-mail]>
To: "Eric Gray (LO/EUS)" <[e-mail]>, [e-mail]
X-WSS-ID: 6A5F26FD38G26575594-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l49GeSfd016873
Cc: [e-mail]
Subject: Re: [rbridge] Per-VLAN DRB elections?
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, 09 May 2007 16:40:48 -0000
Status: RO
Content-Length: 2394

[e-mail] wrote:
> Radia,
> 
> 	This gets back to "what is the logical model for
> RBridge interactions with VLANs."
> 
> 	If - as Joe has suggested at least once - the logical
> model for an RBridge (instance) is specific to a single VLAN,
> then this becomes very straight-forward.  All of the RBridges
> in a single logical campus are necessarily in the same VLAN.
> 
> 	There may be no VLANs - equating to a single logical
> VLAN consisting of the untagged (default) VLAN.
> 
> 	There may actually be an overlay of any number (up to
> 4K) of VLANs that use a deployment of RBridge devices, where
> each device has at least one RBridge logical instance for any
> VLAN in which it is configured to participate.
> 
> 	The elegance of this logical model is that there is L2
> connectivity between only those RBridge instances that are
> configured to participate in a common VLAN.  Hence, there is
> a DRB election process that only includes RBridges that are
> in the same VLAN, on any shared connectivity link.
> 
> 	The advantage of this elegance is that it allows us to
> define actual protocol interactions exactly as if there is
> only one VLAN (which may be the default, unconfigured and
> untagged VLAN).  It then is up to the implementers to "do the
> right thing" as far as implementing 802.1Q correctly.
> 
> 	This - in my opinion - is the way things should be
> done, and I am curious as to who finds this model to be unacceptable,
> and why... 
> 
> 

I agree with your approach, but differ on one very specific point.
The one aspect of this model that I think is unacceptable is that
it *requires* the RBridge to represent each VLAN instance separately.
As covered on prior threads this is not always desirable. But once
you allow RBridges that wish to support these features to do so 
(by allowing them to publish 'VLAN Group' information) then the
rest of the interactions can indeed follow the simple model of
thinking one VLAN at a time.

So taken as an absolute I do find exception to the model you propose,
but I believe it is an exception that is more of an asterisk than a
serious problem. If others have problems with the "per VLAN" approach
I'd encourage them to do something similar that allows the feature 
they are considering while allowing RBridges not involved with that
feature to keep the simple model of thinking about each VLAN separately.





Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l49GDE5A008479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 9 May 2007 09:13:14 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l49GES4F010382; Wed, 9 May 2007 11:14:28 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 9 May 2007 11:13:14 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 May 2007 11:13:12 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] listening vs transmitting spanning tree messages
Thread-Index: AceSPmAEcqalorBwT0mhvZC73itDXQAFd3hQ
References: <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 09 May 2007 16:13:14.0015 (UTC) FILETIME=[F21B92F0:01C79254]
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 l49GDE5A008479
Cc: [e-mail]
Subject: Re: [rbridge] listening vs transmitting spanning tree messages
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, 09 May 2007 16:13:44 -0000
Status: RO
Content-Length: 3488

Radia,

	The simplest approach to correctly eliminating the 
potential for two DRBs on the same shared access link is
via the neighbor discovery and DRB election process itself.

	I prefer the approach of not participating in any STP
as the default (unconfigured) approach for a number of other
reasons.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: Wednesday, May 09, 2007 9:26 AM
> To: [e-mail]
> Subject: [rbridge] listening vs transmitting spanning tree messages
> 
> First -- I am not advocating turning the entire RBridged 
> campus into one
> giant spanning tree by *forwarding* bridge spanning tree messages
> from one RBridge port to another. Somehow each time we try to
> discuss this, some people get confused, and I don't want to
> confuse people
> 
> The current version of the protocol spec says that RBridges should
> transmit bridge spanning tree messages (BPDUs) with highest
> priority (numerically lowest) for becoming root bridge, and
> an RBridge should be DRB if and only if it becomes the root
> of the bridge spanning tree on that layer 2 cloud. Again...this
> is per port -- separate spanning tree on each port. Only if
> an RBridge has two ports on the same layer 2 cloud (where
> "layer 2 cloud" means it's connected with bridges) will
> the spanning tree on one port have anything to do with
> the spanning tree on another port.
> 
> The reason we had RBridges do that is to quickly catch the
> case where two layer 2 clouds got merged, so that we
> would very quickly stop there being two DRBs on the same cloud.
> 
> I think I still prefer this option, but an argument was made that
> it is too complex to transmit BPDUs since there are too many
> different versions of the spanning tree, and we'd have to
> specify which ones must be supported.
> 
> So an alternate proposal is that RBridges only *listen* to
> BPDUs.
> 
> Then, RBridge R1 can detect a potential merging of two layer 2
> clouds on one of its ports if the Root bridge changes.
> 
> If the Root bridge changes, then R1 would stop forwarding
> data packets to/from the link (because there might be another
> DRB) for some amount of time.
> 
> Personally, I think I prefer transmitting, rather than simply
> listening to BPDUs. The reasons:
> 
> a) I don't understand why it is more complex to transmit
> rather than listen to BPDUs. Don't we have the same
> issue with having to understand all the different versions
> of the bridge spanning tree? Aren't all of the versions
> compatible with the original spanning tree protocol
> anyway, so that a bridge with highest
> priority (numerically lowest) sending "original spanning
> tree" protocol messages will become Root even
> if other bridges are doing RSTP or MSTP or whatever? 
> 
> b) The rule "you are DRB if and only if you are the root
> of the spanning tree" is clear.
> With "do something if the bridge Root ID changes"
> I think the rules are more squishy. How long
> do you wait?
> 
> c) there might be bridge root ID changes a lot more
> often than due to layer 2 clouds merging, and in
> those cases the link will be unnecessarily
> orphaned for awhile (while the one DRB waits
> in case something is wrong).
> 
> Radia
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l49G72TO006885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 9 May 2007 09:07:03 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l49G6gaL001539; Wed, 9 May 2007 11:06:43 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 9 May 2007 11:07:02 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 May 2007 11:07:00 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Per-VLAN DRB elections?
Thread-Index: AceSPQHdQApQW2S6Tfmoxu+dK8y8PwAFGwfg
References: <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 09 May 2007 16:07:02.0059 (UTC) FILETIME=[146797B0:01C79254]
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 l49G72TO006885
Cc: [e-mail]
Subject: Re: [rbridge] Per-VLAN DRB elections?
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, 09 May 2007 16:07:15 -0000
Status: RO
Content-Length: 5610

Radia,

	This gets back to "what is the logical model for RBridge
interactions with VLANs."

	If - as Joe has suggested at least once - the logical
model for an RBridge (instance) is specific to a single VLAN,
then this becomes very straight-forward.  All of the RBridges
in a single logical campus are necessarily in the same VLAN.

	There may be no VLANs - equating to a single logical
VLAN consisting of the untagged (default) VLAN.

	There may actually be an overlay of any number (up to
4K) of VLANs that use a deployment of RBridge devices, where
each device has at least one RBridge logical instance for any
VLAN in which it is configured to participate.

	The elegance of this logical model is that there is L2
connectivity between only those RBridge instances that are
configured to participate in a common VLAN.  Hence, there is
a DRB election process that only includes RBridges that are
in the same VLAN, on any shared connectivity link.

	The advantage of this elegance is that it allows us to 
define actual protocol interactions exactly as if there is 
only one VLAN (which may be the default, unconfigured and
untagged VLAN).  It then is up to the implementers to "do
the right thing" as far as implementing 802.1Q correctly.

	This - in my opinion - is the way things should be
done, and I am curious as to who finds this model to be
unacceptable, and why...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: Wednesday, May 09, 2007 9:12 AM
> To: [e-mail]
> Subject: [rbridge] Per-VLAN DRB elections?
> 
> I think we haven't discussed this one on the list yet.
> 
> Bridges can be configured to not forward certain VLANs on 
> certain links.
> So, a "level 2 cloud" (a bunch of links connected with 
> bridges) can be partitioned
> with respect to various VLANs. So, for instance, RBridges R1 
> and R2 can be
> neighbors on a cloud with respect to VLAN A, but not with 
> VLAN B. In other
> words, a packet tagged with "VLAN A" will get from R1 to R2, 
> but one tagged
> with "VLAN B" will not...even if both R1 and R2 think they 
> are connected to VLAN B.
> 
> Oh...this is somewhat related to listening instead of participating in
> the bridge spanning tree, which I will clarify in a separate thread.
> 
> 
> Some issues with bridges not forwarding all VLANs:
> 
> a) If the IS-IS DRB (Designated RBridge)
> election messages are tagged with VLAN B, then we will wind up
> with two DRBs for the link (scary)
> 
> b) if R1 is selected DRB for the link, it may not be able to 
> serve all endnodes (since
> R1 might not be able to reach certain endnodes on some VLANs
> 
> c) in theory, DRB election should be separately carried out 
> for each possible VLAN tag
> (4000 of them). That would be too much.
> 
> d) there was a suggestion that it might be a feature to allow 
> load sharing off a layer 2
> cloud by having separate DRBs for different VLANs
> 
> So...here's a first strawman proposal, partially based on my 
> memory of hallway conversations:
> 
> a) for the zero configuration case, assume that without 
> configuration, the DRB election
> is carried out once, tagged with VLAN 1. Whoever gets elected 
> DRB in the DRB election
> tagged with VLAN 1 is DRB for all VLANs on that link.
> 
> b) RBridges may be configured with other VLAN tags to also, 
> on the same port, participate
> in an IS-IS election with. DRB priority may be configured to 
> be different for different VLANs, so
> R1 might be configured, on port a, to participate in a DRB 
> election for VLAN A with priority 7,
> and VLAN B with priority 9
> 
> c) In the core instance of IS-IS, R1 announces not just which 
> VLANs it is attached to, but
> the Root bridge ID for that VLAN. That way, if R1 finds out 
> (by seeing R2's link state packets)
> that R2 claims to be DRB for VLAN A, with root bridge 89, and 
> R1 thinks that it is DRB for VLAN A,
> root bridge 89, then one of them should back off (using 
> system ID as a tie breaker), where
> "back off" means "stop acting as DRB", i.e., don't 
> encapsulate/decapsulate data packets
> to/from that port with respect to that VLAN
> 
> d) it is absolutely gross misconfiguration, and a disaster, 
> if within the layer 2 cloud, a VLAN tag
> can turn into another VLAN tag, because this could cause R1, 
> who is DRB for
> that link for VLAN A, to decapsulate a frame onto the link, 
> which might pop out to
> R2, who is DRB for that link for VLAN B, to see the packet as "VLAN B"
> 
> I *think* my proposal above has the following properties:
> 
> 1) if a link is genuinely partitioned with respect to VLAN A, 
> then there will be two DRBs elected
> for that link, and all endnodes on that link in VLAN A will 
> be reachable via one or the other
> DRBs, and no link will be formed
> 
> 2) as long as a VLAN tag can't get converted to another VLAN 
> tag within the layer 2
> cloud there will not be loops formed by having two DRBs on 
> the same layer 2 cloud
> 
> 3) we can do load sharing (R1 will be DRB for VLAN A and R2 
> will be for VLAN B)
> 
> 4) if R1 and R2 wind up both elected as DRB for VLAN A and 
> VLAN A is not actually
> partitioned (but R1 can't reach R2), then they'll discover 
> this through the core instance
> IS-IS announcements
> 
> 5) the common case can still be zero configuration
> 
> Comments?
> 
> Radia
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l49Fd3KF029100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 9 May 2007 08:39:03 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l49FeFqh002439; Wed, 9 May 2007 10:40:15 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 9 May 2007 10:39:00 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 May 2007 10:38:59 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
Thread-Index: AceRINZgS3tsWg2LSLCtLi2zwv8JAgABrSywABMZjWAADqqQoAAGeftgAB2FhZAAAxFyIAABPUKw
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 09 May 2007 15:39:00.0611 (UTC) FILETIME=[2A2EFD30:01C79250]
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 l49Fd3KF029100
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 09 May 2007 15:39:18 -0000
Status: RO
Content-Length: 5911

Donald,

	In the sense that you use, this makes sense - except that
the semantic problem still exists.  You are describing a context
for forwarding, not a forwarding device.

	In other words, you are describing "core" forwarding, and
not "core" RBridges.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Wednesday, May 09, 2007 11:11 AM
> To: [e-mail]
> Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> 
> I do not believe Silvano's use of "core" has anything at all 
> to do with
> topology. By "core" I believe he meant the Rbridges and the 
> encapsulated
> tunnels between them. Everything else is "edge" whether it is a simple
> point-to-point physical link from one Rbridge to one end station or a
> bridged LAN with many Rbridges attached. I think a clean distinction
> between "core" and "edge" in this specific sense can always be made.
> 
> Someone doing some ECMP thing outside this core is outside our scope.
> 
> Donald
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Wednesday, May 09, 2007 9:50 AM
> To: Anoop Ghanwani; Silvano Gai; Radia Perlman
> Cc: [e-mail]
> Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> 
> I agree with Anoop.  The assumption that someone might only do 
> ECMP in the core is simply that - as assumption.  Further - as 
> Anoop directly states - the assumption that topology can be 
> cleanly segregated into "core" and "edge" is also JUST an 
> assumption.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]] 
> > Sent: Tuesday, May 08, 2007 7:29 PM
> > To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman
> > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > Importance: High
> > 
> > 
> > That's assumes that one restricts the topology
> > to a clean edge-core-edge design where bridges
> > are present only at the edges (if at all).  
> > 
> > The general case where you have a random mix
> > of bridges and rbridges is where the problem lies.
> > 
> > Anoop 
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]] 
> > > Sent: Tuesday, May 08, 2007 1:23 PM
> > > To: Eric Gray (LO/EUS); Radia Perlman; Anoop Ghanwani
> > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > 
> > > 
> > > We do ECMP only in the core, but we don't learn in the core, 
> > > so I don't see the problem.
> > > 
> > > -- Silvano
> > > 
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > Sent: Tuesday, May 08, 2007 8:23 AM
> > > > To: Silvano Gai; Radia Perlman; Anoop Ghanwani
> > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > > 
> > > > Silvano,
> > > > 
> > > > 	The possibility of frame re-ordering using ECMP 
> is not the only 
> > > > concern.  A more significant issue is that schemes that 
> exist for 
> > > > trying to avoid re-ordering may not guarantee symmetric frame 
> > > > delivery.
> > > > 
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson
> > > > 
> > > > > -----Original Message-----
> > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > Sent: Tuesday, May 08, 2007 12:18 AM
> > > > > To: Radia Perlman; Anoop Ghanwani
> > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; 
> > > > > [e-mail]
> > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > > >
> > > > >
> > > > > The protocol specs states:
> > > > >
> > > > >    The main idea is to have RBridges run a link state 
> protocol 
> > > > > amongst
> > > > >    themselves. This enables them to have enough 
> information to 
> > > > > compute
> > > > >    pairwise optimal paths for unicast, and to calculate 
> > > distribution
> > > > >    trees for delivery of frames either to unknown 
> > destinations, or
> > > to
> > > > >    multicast/broadcast groups.
> > > > >
> > > > >    ECMP (Equal Cost MultiPath) may be supported, but it may
> > > introduce
> > > > >    frame reordering.
> > > > >
> > > > >
> > > > > I think this is correct.
> > > > >
> > > > > -- Silvano
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Radia Perlman [mailto:[e-mail]]
> > > > > > Sent: Monday, May 07, 2007 8:28 PM
> > > > > > To: Anoop Ghanwani
> > > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin 
> Bestler; Silvano
> > > Gai;
> > > > > > [e-mail]
> > > > > > Subject: Re: [rbridge] Two "shared VLAN" 
> alternative proposals
> > > > > >
> > > > > > Which draft says that multipathing (allowing more than 
> > > one path to
> > > a
> > > > > > destination)
> > > > > > is a nongoal? The architecture document, problem 
> statement, or
> > > > > protocol
> > > > > > spec?
> > > > > >
> > > > > > Radia
> > > > > >
> > > > > >
> > > > > > Anoop Ghanwani wrote:
> > > > > > >
> > > > > > > According to Radia's response, she thinks 
> > > multipathing is being 
> > > > > > > addressed and yet the draft explicitly  mentions it as a 
> > > > > > > non-goal so there seems to be a bit of a disconnect.
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > 
> > 
> 
> _______________________________________________
> 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 mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l49FB0Fq022584 for <[e-mail]>; Wed, 9 May 2007 08:11:00 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-9.tower-153.messagelabs.com!1178723459!6521089!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 8528 invoked from network); 9 May 2007 15:10:59 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-153.messagelabs.com with SMTP; 9 May 2007 15:10:59 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l49FAwKr020976 for <[e-mail]>; Wed, 9 May 2007 08:10:58 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l49FAwxk012103 for <[e-mail]>; Wed, 9 May 2007 10:10:58 -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 l49FAv6I012088 for <[e-mail]>; Wed, 9 May 2007 10:10:57 -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, 9 May 2007 11:10:56 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
thread-index: AceRINZgS3tsWg2LSLCtLi2zwv8JAgABrSywABMZjWAADqqQoAAGeftgAB2FhZAAAxFyIA==
References: <[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 l49FB0Fq022584
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 09 May 2007 15:11:20 -0000
Status: RO
Content-Length: 4852

I do not believe Silvano's use of "core" has anything at all to do with
topology. By "core" I believe he meant the Rbridges and the encapsulated
tunnels between them. Everything else is "edge" whether it is a simple
point-to-point physical link from one Rbridge to one end station or a
bridged LAN with many Rbridges attached. I think a clean distinction
between "core" and "edge" in this specific sense can always be made.

Someone doing some ECMP thing outside this core is outside our scope.

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Eric Gray (LO/EUS)
Sent: Wednesday, May 09, 2007 9:50 AM
To: Anoop Ghanwani; Silvano Gai; Radia Perlman
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals

I agree with Anoop.  The assumption that someone might only do 
ECMP in the core is simply that - as assumption.  Further - as 
Anoop directly states - the assumption that topology can be 
cleanly segregated into "core" and "edge" is also JUST an 
assumption.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Tuesday, May 08, 2007 7:29 PM
> To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman
> Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> Importance: High
> 
> 
> That's assumes that one restricts the topology
> to a clean edge-core-edge design where bridges
> are present only at the edges (if at all).  
> 
> The general case where you have a random mix
> of bridges and rbridges is where the problem lies.
> 
> Anoop 
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]] 
> > Sent: Tuesday, May 08, 2007 1:23 PM
> > To: Eric Gray (LO/EUS); Radia Perlman; Anoop Ghanwani
> > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > 
> > 
> > We do ECMP only in the core, but we don't learn in the core, 
> > so I don't see the problem.
> > 
> > -- Silvano
> > 
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > Sent: Tuesday, May 08, 2007 8:23 AM
> > > To: Silvano Gai; Radia Perlman; Anoop Ghanwani
> > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > 
> > > Silvano,
> > > 
> > > 	The possibility of frame re-ordering using ECMP is not the only 
> > > concern.  A more significant issue is that schemes that exist for 
> > > trying to avoid re-ordering may not guarantee symmetric frame 
> > > delivery.
> > > 
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > > 
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Tuesday, May 08, 2007 12:18 AM
> > > > To: Radia Perlman; Anoop Ghanwani
> > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; 
> > > > [e-mail]
> > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > >
> > > >
> > > > The protocol specs states:
> > > >
> > > >    The main idea is to have RBridges run a link state protocol 
> > > > amongst
> > > >    themselves. This enables them to have enough information to 
> > > > compute
> > > >    pairwise optimal paths for unicast, and to calculate 
> > distribution
> > > >    trees for delivery of frames either to unknown 
> destinations, or
> > to
> > > >    multicast/broadcast groups.
> > > >
> > > >    ECMP (Equal Cost MultiPath) may be supported, but it may
> > introduce
> > > >    frame reordering.
> > > >
> > > >
> > > > I think this is correct.
> > > >
> > > > -- Silvano
> > > >
> > > > > -----Original Message-----
> > > > > From: Radia Perlman [mailto:[e-mail]]
> > > > > Sent: Monday, May 07, 2007 8:28 PM
> > > > > To: Anoop Ghanwani
> > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; Silvano
> > Gai;
> > > > > [e-mail]
> > > > > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> > > > >
> > > > > Which draft says that multipathing (allowing more than 
> > one path to
> > a
> > > > > destination)
> > > > > is a nongoal? The architecture document, problem statement, or
> > > > protocol
> > > > > spec?
> > > > >
> > > > > Radia
> > > > >
> > > > >
> > > > > Anoop Ghanwani wrote:
> > > > > >
> > > > > > According to Radia's response, she thinks 
> > multipathing is being 
> > > > > > addressed and yet the draft explicitly  mentions it as a 
> > > > > > non-goal so there seems to be a bit of a disconnect.
> > > > > >
> > > > > >
> > > >
> > > >
> > 
> 

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



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l49EjbWw016117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 9 May 2007 07:45:37 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l49EjFjE019175; Wed, 9 May 2007 09:45:15 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 9 May 2007 09:45:35 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 May 2007 09:45:33 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
Thread-Index: AceRINZgS3tsWg2LSLCtLi2zwv8JAgABrSywABMZjWAADqqQoAAGeftgAB2FhZAAAQS6gAAAQL/AAADYgtAAAFJgUA==
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 09 May 2007 14:45:35.0127 (UTC) FILETIME=[B390F270:01C79248]
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 l49EjbWw016117
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 09 May 2007 14:45:42 -0000
Status: RO
Content-Length: 8218

Silvano,

	Like I said, the statement may be removed from the 
RR draft as far as I am concerned.  If that is what the
WG wants to do, and it is okay with the IESG document
shepherd, then I can certainly make that change.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Wednesday, May 09, 2007 10:38 AM
> To: Eric Gray (LO/EUS); Anoop Ghanwani; Radia Perlman
> Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> Importance: High
> 
> Eric,
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > Sent: Wednesday, May 09, 2007 7:23 AM
> > To: Silvano Gai; Anoop Ghanwani; Radia Perlman
> > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > 
> > Silvano,
> > 
> > 	So, you're assuming multi-pathing (lets ignore the
> > "equal cost" part of this, for now) by selecting more
> 
> It is equal cost because IS-IS is limited to equal cost. If we were
> using EIGRP we can also support Non Equal Cost Multi Path.
> 
> > than one "tunnel" at the ingress RBridge as alternative
> > forwarding paths.
> > 
> > 	This protects legacy bridges (somewhat) because
> > the only MAC learning that applies is the learning of
> > RBridge MAC addresses, and you're further assuming that
> > there will necessarily be enough reverse-path traffic
> > between any pair of RBridges to ensure that the legacy
> > bridges do not age out RBridge MAC addresses.
> 
> There are for sure the IS-IS messages, they are enough to reach this
> goal.
> 
> > 
> > 	These are reasonable assumptions, but they are
> > still assumptions.
> > 
> > 	However, this is not ECMP as might be typically
> > applied with shortest path routing (where an equal cost
> > path may exist between any router in the routing domain
> > and a specific destination network). 
> 
> This was just to simplify the explanation; of course an equal 
> cost path
> may exist between any RBridge in the RBridge domain.
> 
>  Which goes back
> > to why this was stated as a "non-goal" in the RR draft.
> 
> For us it is the ONLY goal
> 
> -- Silvano
> 
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Wednesday, May 09, 2007 10:06 AM
> > > To: Eric Gray (LO/EUS); Anoop Ghanwani; Radia Perlman
> > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > Importance: High
> > >
> > >
> > > Eric,
> > >
> > > In a TRILL domain you can do ECMP,
> > > outside no, since there is Spanning Tree.
> > >
> > > It is that simple.
> > >
> > > -- Silvano
> > >
> > > P.S. I am VERY familiar with the application Anoop is looking at.
> > >
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > Sent: Wednesday, May 09, 2007 6:50 AM
> > > > To: Anoop Ghanwani; Silvano Gai; Radia Perlman
> > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > >
> > > > I agree with Anoop.  The assumption that someone might only do
> > > > ECMP in the core is simply that - as assumption.  Further - as
> > > > Anoop directly states - the assumption that topology can be
> > > > cleanly segregated into "core" and "edge" is also JUST an
> > > > assumption.
> > > >
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson
> > > >
> > > > > -----Original Message-----
> > > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > > Sent: Tuesday, May 08, 2007 7:29 PM
> > > > > To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman
> > > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > > > Importance: High
> > > > >
> > > > >
> > > > > That's assumes that one restricts the topology
> > > > > to a clean edge-core-edge design where bridges
> > > > > are present only at the edges (if at all).
> > > > >
> > > > > The general case where you have a random mix
> > > > > of bridges and rbridges is where the problem lies.
> > > > >
> > > > > Anoop
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > > Sent: Tuesday, May 08, 2007 1:23 PM
> > > > > > To: Eric Gray (LO/EUS); Radia Perlman; Anoop Ghanwani
> > > > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > > > Subject: RE: [rbridge] Two "shared VLAN" 
> alternative proposals
> > > > > >
> > > > > >
> > > > > > We do ECMP only in the core, but we don't learn in the core,
> > > > > > so I don't see the problem.
> > > > > >
> > > > > > -- Silvano
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > > > Sent: Tuesday, May 08, 2007 8:23 AM
> > > > > > > To: Silvano Gai; Radia Perlman; Anoop Ghanwani
> > > > > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative
> proposals
> > > > > > >
> > > > > > > Silvano,
> > > > > > >
> > > > > > > 	The possibility of frame re-ordering using ECMP is not
> > > the
> > > > only
> > > > > > > concern.  A more significant issue is that schemes that
> exist
> > > for
> > > > > > > trying to avoid re-ordering may not guarantee symmetric
> frame
> > > > > > > delivery.
> > > > > > >
> > > > > > > --
> > > > > > > Eric Gray
> > > > > > > Principal Engineer
> > > > > > > Ericsson
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > > > > Sent: Tuesday, May 08, 2007 12:18 AM
> > > > > > > > To: Radia Perlman; Anoop Ghanwani
> > > > > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
> > > > > > > > [e-mail]
> > > > > > > > Subject: RE: [rbridge] Two "shared VLAN"
> > > alternative proposals
> > > > > > > >
> > > > > > > >
> > > > > > > > The protocol specs states:
> > > > > > > >
> > > > > > > >    The main idea is to have RBridges run a link
> > > state protocol
> > > > > > > > amongst
> > > > > > > >    themselves. This enables them to have enough
> > > information to
> > > > > > > > compute
> > > > > > > >    pairwise optimal paths for unicast, and to calculate
> > > > > > distribution
> > > > > > > >    trees for delivery of frames either to unknown
> > > > > destinations, or
> > > > > > to
> > > > > > > >    multicast/broadcast groups.
> > > > > > > >
> > > > > > > >    ECMP (Equal Cost MultiPath) may be supported, but it
> may
> > > > > > introduce
> > > > > > > >    frame reordering.
> > > > > > > >
> > > > > > > >
> > > > > > > > I think this is correct.
> > > > > > > >
> > > > > > > > -- Silvano
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Radia Perlman [mailto:[e-mail]]
> > > > > > > > > Sent: Monday, May 07, 2007 8:28 PM
> > > > > > > > > To: Anoop Ghanwani
> > > > > > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
> > > Silvano
> > > > > > Gai;
> > > > > > > > > [e-mail]
> > > > > > > > > Subject: Re: [rbridge] Two "shared VLAN" alternative
> > > proposals
> > > > > > > > >
> > > > > > > > > Which draft says that multipathing (allowing more than
> > > > > > one path to
> > > > > > a
> > > > > > > > > destination)
> > > > > > > > > is a nongoal? The architecture document, problem
> > > statement,
> > > or
> > > > > > > > protocol
> > > > > > > > > spec?
> > > > > > > > >
> > > > > > > > > Radia
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Anoop Ghanwani wrote:
> > > > > > > > > >
> > > > > > > > > > According to Radia's response, she thinks
> > > > > > multipathing is being
> > > > > > > > > > addressed and yet the draft explicitly  
> mentions it as
> a
> > > > > > > > > > non-goal so there seems to be a bit of a disconnect.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > >
> 



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 l49Ec1AL014103 for <[e-mail]>; Wed, 9 May 2007 07:38:01 -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: Wed, 9 May 2007 07:37:58 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
Thread-Index: AceRINZgS3tsWg2LSLCtLi2zwv8JAgABrSywABMZjWAADqqQoAAGeftgAB2FhZAAAQS6gAAAQL/AAADYgtA=
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[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 l49Ec1AL014103
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 09 May 2007 14:38:16 -0000
Status: RO
Content-Length: 7174

Eric,

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> Sent: Wednesday, May 09, 2007 7:23 AM
> To: Silvano Gai; Anoop Ghanwani; Radia Perlman
> Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> 
> Silvano,
> 
> 	So, you're assuming multi-pathing (lets ignore the
> "equal cost" part of this, for now) by selecting more

It is equal cost because IS-IS is limited to equal cost. If we were
using EIGRP we can also support Non Equal Cost Multi Path.

> than one "tunnel" at the ingress RBridge as alternative
> forwarding paths.
> 
> 	This protects legacy bridges (somewhat) because
> the only MAC learning that applies is the learning of
> RBridge MAC addresses, and you're further assuming that
> there will necessarily be enough reverse-path traffic
> between any pair of RBridges to ensure that the legacy
> bridges do not age out RBridge MAC addresses.

There are for sure the IS-IS messages, they are enough to reach this
goal.

> 
> 	These are reasonable assumptions, but they are
> still assumptions.
> 
> 	However, this is not ECMP as might be typically
> applied with shortest path routing (where an equal cost
> path may exist between any router in the routing domain
> and a specific destination network). 

This was just to simplify the explanation; of course an equal cost path
may exist between any RBridge in the RBridge domain.

 Which goes back
> to why this was stated as a "non-goal" in the RR draft.

For us it is the ONLY goal

-- Silvano

> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Wednesday, May 09, 2007 10:06 AM
> > To: Eric Gray (LO/EUS); Anoop Ghanwani; Radia Perlman
> > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > Importance: High
> >
> >
> > Eric,
> >
> > In a TRILL domain you can do ECMP,
> > outside no, since there is Spanning Tree.
> >
> > It is that simple.
> >
> > -- Silvano
> >
> > P.S. I am VERY familiar with the application Anoop is looking at.
> >
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > Sent: Wednesday, May 09, 2007 6:50 AM
> > > To: Anoop Ghanwani; Silvano Gai; Radia Perlman
> > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > >
> > > I agree with Anoop.  The assumption that someone might only do
> > > ECMP in the core is simply that - as assumption.  Further - as
> > > Anoop directly states - the assumption that topology can be
> > > cleanly segregated into "core" and "edge" is also JUST an
> > > assumption.
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >
> > > > -----Original Message-----
> > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > Sent: Tuesday, May 08, 2007 7:29 PM
> > > > To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman
> > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > > Importance: High
> > > >
> > > >
> > > > That's assumes that one restricts the topology
> > > > to a clean edge-core-edge design where bridges
> > > > are present only at the edges (if at all).
> > > >
> > > > The general case where you have a random mix
> > > > of bridges and rbridges is where the problem lies.
> > > >
> > > > Anoop
> > > >
> > > > > -----Original Message-----
> > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > Sent: Tuesday, May 08, 2007 1:23 PM
> > > > > To: Eric Gray (LO/EUS); Radia Perlman; Anoop Ghanwani
> > > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > > >
> > > > >
> > > > > We do ECMP only in the core, but we don't learn in the core,
> > > > > so I don't see the problem.
> > > > >
> > > > > -- Silvano
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > > Sent: Tuesday, May 08, 2007 8:23 AM
> > > > > > To: Silvano Gai; Radia Perlman; Anoop Ghanwani
> > > > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative
proposals
> > > > > >
> > > > > > Silvano,
> > > > > >
> > > > > > 	The possibility of frame re-ordering using ECMP is not
> > the
> > > only
> > > > > > concern.  A more significant issue is that schemes that
exist
> > for
> > > > > > trying to avoid re-ordering may not guarantee symmetric
frame
> > > > > > delivery.
> > > > > >
> > > > > > --
> > > > > > Eric Gray
> > > > > > Principal Engineer
> > > > > > Ericsson
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > > > Sent: Tuesday, May 08, 2007 12:18 AM
> > > > > > > To: Radia Perlman; Anoop Ghanwani
> > > > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
> > > > > > > [e-mail]
> > > > > > > Subject: RE: [rbridge] Two "shared VLAN"
> > alternative proposals
> > > > > > >
> > > > > > >
> > > > > > > The protocol specs states:
> > > > > > >
> > > > > > >    The main idea is to have RBridges run a link
> > state protocol
> > > > > > > amongst
> > > > > > >    themselves. This enables them to have enough
> > information to
> > > > > > > compute
> > > > > > >    pairwise optimal paths for unicast, and to calculate
> > > > > distribution
> > > > > > >    trees for delivery of frames either to unknown
> > > > destinations, or
> > > > > to
> > > > > > >    multicast/broadcast groups.
> > > > > > >
> > > > > > >    ECMP (Equal Cost MultiPath) may be supported, but it
may
> > > > > introduce
> > > > > > >    frame reordering.
> > > > > > >
> > > > > > >
> > > > > > > I think this is correct.
> > > > > > >
> > > > > > > -- Silvano
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Radia Perlman [mailto:[e-mail]]
> > > > > > > > Sent: Monday, May 07, 2007 8:28 PM
> > > > > > > > To: Anoop Ghanwani
> > > > > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
> > Silvano
> > > > > Gai;
> > > > > > > > [e-mail]
> > > > > > > > Subject: Re: [rbridge] Two "shared VLAN" alternative
> > proposals
> > > > > > > >
> > > > > > > > Which draft says that multipathing (allowing more than
> > > > > one path to
> > > > > a
> > > > > > > > destination)
> > > > > > > > is a nongoal? The architecture document, problem
> > statement,
> > or
> > > > > > > protocol
> > > > > > > > spec?
> > > > > > > >
> > > > > > > > Radia
> > > > > > > >
> > > > > > > >
> > > > > > > > Anoop Ghanwani wrote:
> > > > > > > > >
> > > > > > > > > According to Radia's response, she thinks
> > > > > multipathing is being
> > > > > > > > > addressed and yet the draft explicitly  mentions it as
a
> > > > > > > > > non-goal so there seems to be a bit of a disconnect.
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > >
> >



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 l49EXrSM012917 for <[e-mail]>; Wed, 9 May 2007 07:33:53 -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: Wed, 9 May 2007 07:33:50 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
Thread-Index: AceRINZgS3tsWg2LSLCtLi2zwv8JAgABrSywABMZjWAADqqQoAAGeftgAB2FhZAAAQS6gAAAvk2gAABYU2A=
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[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 l49EXrSM012917
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 09 May 2007 14:34:13 -0000
Status: RO
Content-Length: 6135

Not for the same VLAN

-- Silvano

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> Sent: Wednesday, May 09, 2007 7:26 AM
> To: Silvano Gai; Anoop Ghanwani; Radia Perlman
> Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> 
> Silvano,
> 
> 	One thing you might want to realize is that you can do
> an ECMP like function in an 802.1Q-based network using MSTP.
> Hence, the use of STP - alone - is not a deciding criteria.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Wednesday, May 09, 2007 10:06 AM
> > To: Eric Gray (LO/EUS); Anoop Ghanwani; Radia Perlman
> > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > Importance: High
> >
> >
> > Eric,
> >
> > In a TRILL domain you can do ECMP,
> > outside no, since there is Spanning Tree.
> >
> > It is that simple.
> >
> > -- Silvano
> >
> > P.S. I am VERY familiar with the application Anoop is looking at.
> >
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > Sent: Wednesday, May 09, 2007 6:50 AM
> > > To: Anoop Ghanwani; Silvano Gai; Radia Perlman
> > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > >
> > > I agree with Anoop.  The assumption that someone might only do
> > > ECMP in the core is simply that - as assumption.  Further - as
> > > Anoop directly states - the assumption that topology can be
> > > cleanly segregated into "core" and "edge" is also JUST an
> > > assumption.
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >
> > > > -----Original Message-----
> > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > Sent: Tuesday, May 08, 2007 7:29 PM
> > > > To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman
> > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > > Importance: High
> > > >
> > > >
> > > > That's assumes that one restricts the topology
> > > > to a clean edge-core-edge design where bridges
> > > > are present only at the edges (if at all).
> > > >
> > > > The general case where you have a random mix
> > > > of bridges and rbridges is where the problem lies.
> > > >
> > > > Anoop
> > > >
> > > > > -----Original Message-----
> > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > Sent: Tuesday, May 08, 2007 1:23 PM
> > > > > To: Eric Gray (LO/EUS); Radia Perlman; Anoop Ghanwani
> > > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > > >
> > > > >
> > > > > We do ECMP only in the core, but we don't learn in the core,
> > > > > so I don't see the problem.
> > > > >
> > > > > -- Silvano
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > > Sent: Tuesday, May 08, 2007 8:23 AM
> > > > > > To: Silvano Gai; Radia Perlman; Anoop Ghanwani
> > > > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative
proposals
> > > > > >
> > > > > > Silvano,
> > > > > >
> > > > > > 	The possibility of frame re-ordering using ECMP is not
> > the
> > > only
> > > > > > concern.  A more significant issue is that schemes that
exist
> > for
> > > > > > trying to avoid re-ordering may not guarantee symmetric
frame
> > > > > > delivery.
> > > > > >
> > > > > > --
> > > > > > Eric Gray
> > > > > > Principal Engineer
> > > > > > Ericsson
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > > > Sent: Tuesday, May 08, 2007 12:18 AM
> > > > > > > To: Radia Perlman; Anoop Ghanwani
> > > > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
> > > > > > > [e-mail]
> > > > > > > Subject: RE: [rbridge] Two "shared VLAN"
> > alternative proposals
> > > > > > >
> > > > > > >
> > > > > > > The protocol specs states:
> > > > > > >
> > > > > > >    The main idea is to have RBridges run a link
> > state protocol
> > > > > > > amongst
> > > > > > >    themselves. This enables them to have enough
> > information to
> > > > > > > compute
> > > > > > >    pairwise optimal paths for unicast, and to calculate
> > > > > distribution
> > > > > > >    trees for delivery of frames either to unknown
> > > > destinations, or
> > > > > to
> > > > > > >    multicast/broadcast groups.
> > > > > > >
> > > > > > >    ECMP (Equal Cost MultiPath) may be supported, but it
may
> > > > > introduce
> > > > > > >    frame reordering.
> > > > > > >
> > > > > > >
> > > > > > > I think this is correct.
> > > > > > >
> > > > > > > -- Silvano
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Radia Perlman [mailto:[e-mail]]
> > > > > > > > Sent: Monday, May 07, 2007 8:28 PM
> > > > > > > > To: Anoop Ghanwani
> > > > > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
> > Silvano
> > > > > Gai;
> > > > > > > > [e-mail]
> > > > > > > > Subject: Re: [rbridge] Two "shared VLAN" alternative
> > proposals
> > > > > > > >
> > > > > > > > Which draft says that multipathing (allowing more than
> > > > > one path to
> > > > > a
> > > > > > > > destination)
> > > > > > > > is a nongoal? The architecture document, problem
> > statement,
> > or
> > > > > > > protocol
> > > > > > > > spec?
> > > > > > > >
> > > > > > > > Radia
> > > > > > > >
> > > > > > > >
> > > > > > > > Anoop Ghanwani wrote:
> > > > > > > > >
> > > > > > > > > According to Radia's response, she thinks
> > > > > multipathing is being
> > > > > > > > > addressed and yet the draft explicitly  mentions it as
a
> > > > > > > > > non-goal so there seems to be a bit of a disconnect.
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > >
> >



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l49EPsUM011237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 9 May 2007 07:25:55 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l49EPXDe015161; Wed, 9 May 2007 09:25:33 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 9 May 2007 09:25:52 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 May 2007 09:25:50 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
Thread-Index: AceRINZgS3tsWg2LSLCtLi2zwv8JAgABrSywABMZjWAADqqQoAAGeftgAB2FhZAAAQS6gAAAvk2g
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 09 May 2007 14:25:52.0885 (UTC) FILETIME=[F2E52250:01C79245]
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 l49EPsUM011237
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 09 May 2007 14:26:16 -0000
Status: RO
Content-Length: 5471

Silvano,

	One thing you might want to realize is that you can do
an ECMP like function in an 802.1Q-based network using MSTP.
Hence, the use of STP - alone - is not a deciding criteria.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Wednesday, May 09, 2007 10:06 AM
> To: Eric Gray (LO/EUS); Anoop Ghanwani; Radia Perlman
> Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> Importance: High
> 
> 
> Eric,
> 
> In a TRILL domain you can do ECMP,
> outside no, since there is Spanning Tree.
> 
> It is that simple.
> 
> -- Silvano
> 
> P.S. I am VERY familiar with the application Anoop is looking at.
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > Sent: Wednesday, May 09, 2007 6:50 AM
> > To: Anoop Ghanwani; Silvano Gai; Radia Perlman
> > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > 
> > I agree with Anoop.  The assumption that someone might only do
> > ECMP in the core is simply that - as assumption.  Further - as
> > Anoop directly states - the assumption that topology can be
> > cleanly segregated into "core" and "edge" is also JUST an
> > assumption.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > Sent: Tuesday, May 08, 2007 7:29 PM
> > > To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman
> > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > Importance: High
> > >
> > >
> > > That's assumes that one restricts the topology
> > > to a clean edge-core-edge design where bridges
> > > are present only at the edges (if at all).
> > >
> > > The general case where you have a random mix
> > > of bridges and rbridges is where the problem lies.
> > >
> > > Anoop
> > >
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Tuesday, May 08, 2007 1:23 PM
> > > > To: Eric Gray (LO/EUS); Radia Perlman; Anoop Ghanwani
> > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > >
> > > >
> > > > We do ECMP only in the core, but we don't learn in the core,
> > > > so I don't see the problem.
> > > >
> > > > -- Silvano
> > > >
> > > > > -----Original Message-----
> > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > Sent: Tuesday, May 08, 2007 8:23 AM
> > > > > To: Silvano Gai; Radia Perlman; Anoop Ghanwani
> > > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > > >
> > > > > Silvano,
> > > > >
> > > > > 	The possibility of frame re-ordering using ECMP is not
> the
> > only
> > > > > concern.  A more significant issue is that schemes that exist
> for
> > > > > trying to avoid re-ordering may not guarantee symmetric frame
> > > > > delivery.
> > > > >
> > > > > --
> > > > > Eric Gray
> > > > > Principal Engineer
> > > > > Ericsson
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > > Sent: Tuesday, May 08, 2007 12:18 AM
> > > > > > To: Radia Perlman; Anoop Ghanwani
> > > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
> > > > > > [e-mail]
> > > > > > Subject: RE: [rbridge] Two "shared VLAN" 
> alternative proposals
> > > > > >
> > > > > >
> > > > > > The protocol specs states:
> > > > > >
> > > > > >    The main idea is to have RBridges run a link 
> state protocol
> > > > > > amongst
> > > > > >    themselves. This enables them to have enough 
> information to
> > > > > > compute
> > > > > >    pairwise optimal paths for unicast, and to calculate
> > > > distribution
> > > > > >    trees for delivery of frames either to unknown
> > > destinations, or
> > > > to
> > > > > >    multicast/broadcast groups.
> > > > > >
> > > > > >    ECMP (Equal Cost MultiPath) may be supported, but it may
> > > > introduce
> > > > > >    frame reordering.
> > > > > >
> > > > > >
> > > > > > I think this is correct.
> > > > > >
> > > > > > -- Silvano
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Radia Perlman [mailto:[e-mail]]
> > > > > > > Sent: Monday, May 07, 2007 8:28 PM
> > > > > > > To: Anoop Ghanwani
> > > > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
> Silvano
> > > > Gai;
> > > > > > > [e-mail]
> > > > > > > Subject: Re: [rbridge] Two "shared VLAN" alternative
> proposals
> > > > > > >
> > > > > > > Which draft says that multipathing (allowing more than
> > > > one path to
> > > > a
> > > > > > > destination)
> > > > > > > is a nongoal? The architecture document, problem 
> statement,
> or
> > > > > > protocol
> > > > > > > spec?
> > > > > > >
> > > > > > > Radia
> > > > > > >
> > > > > > >
> > > > > > > Anoop Ghanwani wrote:
> > > > > > > >
> > > > > > > > According to Radia's response, she thinks
> > > > multipathing is being
> > > > > > > > addressed and yet the draft explicitly  mentions it as a
> > > > > > > > non-goal so there seems to be a bit of a disconnect.
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > >
> > >
> 



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l49EMe3L010273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 9 May 2007 07:22:41 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l49EMGu1014424; Wed, 9 May 2007 09:22:19 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 9 May 2007 09:22:37 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 May 2007 09:22:35 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
Thread-Index: AceRINZgS3tsWg2LSLCtLi2zwv8JAgABrSywABMZjWAADqqQoAAGeftgAB2FhZAAAQS6gAAAQL/A
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 09 May 2007 14:22:37.0120 (UTC) FILETIME=[7E35C400:01C79245]
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 l49EMe3L010273
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 09 May 2007 14:23:09 -0000
Status: RO
Content-Length: 6133

Silvano,

	So, you're assuming multi-pathing (lets ignore the
"equal cost" part of this, for now) by selecting more
than one "tunnel" at the ingress RBridge as alternative
forwarding paths.

	This protects legacy bridges (somewhat) because
the only MAC learning that applies is the learning of
RBridge MAC addresses, and you're further assuming that
there will necessarily be enough reverse-path traffic
between any pair of RBridges to ensure that the legacy
bridges do not age out RBridge MAC addresses.

	These are reasonable assumptions, but they are 
still assumptions.

	However, this is not ECMP as might be typically 
applied with shortest path routing (where an equal cost 
path may exist between any router in the routing domain 
and a specific destination network).  Which goes back
to why this was stated as a "non-goal" in the RR draft.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Wednesday, May 09, 2007 10:06 AM
> To: Eric Gray (LO/EUS); Anoop Ghanwani; Radia Perlman
> Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> Importance: High
> 
> 
> Eric,
> 
> In a TRILL domain you can do ECMP,
> outside no, since there is Spanning Tree.
> 
> It is that simple.
> 
> -- Silvano
> 
> P.S. I am VERY familiar with the application Anoop is looking at.
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > Sent: Wednesday, May 09, 2007 6:50 AM
> > To: Anoop Ghanwani; Silvano Gai; Radia Perlman
> > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > 
> > I agree with Anoop.  The assumption that someone might only do
> > ECMP in the core is simply that - as assumption.  Further - as
> > Anoop directly states - the assumption that topology can be
> > cleanly segregated into "core" and "edge" is also JUST an
> > assumption.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > Sent: Tuesday, May 08, 2007 7:29 PM
> > > To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman
> > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > Importance: High
> > >
> > >
> > > That's assumes that one restricts the topology
> > > to a clean edge-core-edge design where bridges
> > > are present only at the edges (if at all).
> > >
> > > The general case where you have a random mix
> > > of bridges and rbridges is where the problem lies.
> > >
> > > Anoop
> > >
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Tuesday, May 08, 2007 1:23 PM
> > > > To: Eric Gray (LO/EUS); Radia Perlman; Anoop Ghanwani
> > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > >
> > > >
> > > > We do ECMP only in the core, but we don't learn in the core,
> > > > so I don't see the problem.
> > > >
> > > > -- Silvano
> > > >
> > > > > -----Original Message-----
> > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > Sent: Tuesday, May 08, 2007 8:23 AM
> > > > > To: Silvano Gai; Radia Perlman; Anoop Ghanwani
> > > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > > >
> > > > > Silvano,
> > > > >
> > > > > 	The possibility of frame re-ordering using ECMP is not
> the
> > only
> > > > > concern.  A more significant issue is that schemes that exist
> for
> > > > > trying to avoid re-ordering may not guarantee symmetric frame
> > > > > delivery.
> > > > >
> > > > > --
> > > > > Eric Gray
> > > > > Principal Engineer
> > > > > Ericsson
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > > Sent: Tuesday, May 08, 2007 12:18 AM
> > > > > > To: Radia Perlman; Anoop Ghanwani
> > > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
> > > > > > [e-mail]
> > > > > > Subject: RE: [rbridge] Two "shared VLAN" 
> alternative proposals
> > > > > >
> > > > > >
> > > > > > The protocol specs states:
> > > > > >
> > > > > >    The main idea is to have RBridges run a link 
> state protocol
> > > > > > amongst
> > > > > >    themselves. This enables them to have enough 
> information to
> > > > > > compute
> > > > > >    pairwise optimal paths for unicast, and to calculate
> > > > distribution
> > > > > >    trees for delivery of frames either to unknown
> > > destinations, or
> > > > to
> > > > > >    multicast/broadcast groups.
> > > > > >
> > > > > >    ECMP (Equal Cost MultiPath) may be supported, but it may
> > > > introduce
> > > > > >    frame reordering.
> > > > > >
> > > > > >
> > > > > > I think this is correct.
> > > > > >
> > > > > > -- Silvano
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Radia Perlman [mailto:[e-mail]]
> > > > > > > Sent: Monday, May 07, 2007 8:28 PM
> > > > > > > To: Anoop Ghanwani
> > > > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
> Silvano
> > > > Gai;
> > > > > > > [e-mail]
> > > > > > > Subject: Re: [rbridge] Two "shared VLAN" alternative
> proposals
> > > > > > >
> > > > > > > Which draft says that multipathing (allowing more than
> > > > one path to
> > > > a
> > > > > > > destination)
> > > > > > > is a nongoal? The architecture document, problem 
> statement,
> or
> > > > > > protocol
> > > > > > > spec?
> > > > > > >
> > > > > > > Radia
> > > > > > >
> > > > > > >
> > > > > > > Anoop Ghanwani wrote:
> > > > > > > >
> > > > > > > > According to Radia's response, she thinks
> > > > multipathing is being
> > > > > > > > addressed and yet the draft explicitly  mentions it as a
> > > > > > > > non-goal so there seems to be a bit of a disconnect.
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > >
> > >
> 



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 l49E5Xj3006230 for <[e-mail]>; Wed, 9 May 2007 07:05: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: Wed, 9 May 2007 07:05:30 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
Thread-Index: AceRINZgS3tsWg2LSLCtLi2zwv8JAgABrSywABMZjWAADqqQoAAGeftgAB2FhZAAAQS6gA==
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[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 l49E5Xj3006230
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 09 May 2007 14:06:15 -0000
Status: RO
Content-Length: 4605

Eric,

In a TRILL domain you can do ECMP,
outside no, since there is Spanning Tree.

It is that simple.

-- Silvano

P.S. I am VERY familiar with the application Anoop is looking at.

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> Sent: Wednesday, May 09, 2007 6:50 AM
> To: Anoop Ghanwani; Silvano Gai; Radia Perlman
> Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> 
> I agree with Anoop.  The assumption that someone might only do
> ECMP in the core is simply that - as assumption.  Further - as
> Anoop directly states - the assumption that topology can be
> cleanly segregated into "core" and "edge" is also JUST an
> assumption.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Tuesday, May 08, 2007 7:29 PM
> > To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman
> > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > Importance: High
> >
> >
> > That's assumes that one restricts the topology
> > to a clean edge-core-edge design where bridges
> > are present only at the edges (if at all).
> >
> > The general case where you have a random mix
> > of bridges and rbridges is where the problem lies.
> >
> > Anoop
> >
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Tuesday, May 08, 2007 1:23 PM
> > > To: Eric Gray (LO/EUS); Radia Perlman; Anoop Ghanwani
> > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > >
> > >
> > > We do ECMP only in the core, but we don't learn in the core,
> > > so I don't see the problem.
> > >
> > > -- Silvano
> > >
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > Sent: Tuesday, May 08, 2007 8:23 AM
> > > > To: Silvano Gai; Radia Perlman; Anoop Ghanwani
> > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > >
> > > > Silvano,
> > > >
> > > > 	The possibility of frame re-ordering using ECMP is not
the
> only
> > > > concern.  A more significant issue is that schemes that exist
for
> > > > trying to avoid re-ordering may not guarantee symmetric frame
> > > > delivery.
> > > >
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson
> > > >
> > > > > -----Original Message-----
> > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > Sent: Tuesday, May 08, 2007 12:18 AM
> > > > > To: Radia Perlman; Anoop Ghanwani
> > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
> > > > > [e-mail]
> > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > > >
> > > > >
> > > > > The protocol specs states:
> > > > >
> > > > >    The main idea is to have RBridges run a link state protocol
> > > > > amongst
> > > > >    themselves. This enables them to have enough information to
> > > > > compute
> > > > >    pairwise optimal paths for unicast, and to calculate
> > > distribution
> > > > >    trees for delivery of frames either to unknown
> > destinations, or
> > > to
> > > > >    multicast/broadcast groups.
> > > > >
> > > > >    ECMP (Equal Cost MultiPath) may be supported, but it may
> > > introduce
> > > > >    frame reordering.
> > > > >
> > > > >
> > > > > I think this is correct.
> > > > >
> > > > > -- Silvano
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Radia Perlman [mailto:[e-mail]]
> > > > > > Sent: Monday, May 07, 2007 8:28 PM
> > > > > > To: Anoop Ghanwani
> > > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
Silvano
> > > Gai;
> > > > > > [e-mail]
> > > > > > Subject: Re: [rbridge] Two "shared VLAN" alternative
proposals
> > > > > >
> > > > > > Which draft says that multipathing (allowing more than
> > > one path to
> > > a
> > > > > > destination)
> > > > > > is a nongoal? The architecture document, problem statement,
or
> > > > > protocol
> > > > > > spec?
> > > > > >
> > > > > > Radia
> > > > > >
> > > > > >
> > > > > > Anoop Ghanwani wrote:
> > > > > > >
> > > > > > > According to Radia's response, she thinks
> > > multipathing is being
> > > > > > > addressed and yet the draft explicitly  mentions it as a
> > > > > > > non-goal so there seems to be a bit of a disconnect.
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> >



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l49Do1M7002664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 9 May 2007 06:50:02 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l49Dndt8007665; Wed, 9 May 2007 08:49:39 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 9 May 2007 08:49:58 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 May 2007 08:49:59 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
Thread-Index: AceRINZgS3tsWg2LSLCtLi2zwv8JAgABrSywABMZjWAADqqQoAAGeftgAB2FhZA=
References: <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Silvano Gai" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 09 May 2007 13:49:58.0711 (UTC) FILETIME=[EEE84470:01C79240]
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 l49Do1M7002664
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 09 May 2007 13:50:16 -0000
Status: RO
Content-Length: 3908

I agree with Anoop.  The assumption that someone might only do 
ECMP in the core is simply that - as assumption.  Further - as 
Anoop directly states - the assumption that topology can be 
cleanly segregated into "core" and "edge" is also JUST an 
assumption.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Tuesday, May 08, 2007 7:29 PM
> To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman
> Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> Importance: High
> 
> 
> That's assumes that one restricts the topology
> to a clean edge-core-edge design where bridges
> are present only at the edges (if at all).  
> 
> The general case where you have a random mix
> of bridges and rbridges is where the problem lies.
> 
> Anoop 
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]] 
> > Sent: Tuesday, May 08, 2007 1:23 PM
> > To: Eric Gray (LO/EUS); Radia Perlman; Anoop Ghanwani
> > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > 
> > 
> > We do ECMP only in the core, but we don't learn in the core, 
> > so I don't see the problem.
> > 
> > -- Silvano
> > 
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > Sent: Tuesday, May 08, 2007 8:23 AM
> > > To: Silvano Gai; Radia Perlman; Anoop Ghanwani
> > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > 
> > > Silvano,
> > > 
> > > 	The possibility of frame re-ordering using ECMP is not the only 
> > > concern.  A more significant issue is that schemes that exist for 
> > > trying to avoid re-ordering may not guarantee symmetric frame 
> > > delivery.
> > > 
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > > 
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Tuesday, May 08, 2007 12:18 AM
> > > > To: Radia Perlman; Anoop Ghanwani
> > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; 
> > > > [e-mail]
> > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > >
> > > >
> > > > The protocol specs states:
> > > >
> > > >    The main idea is to have RBridges run a link state protocol 
> > > > amongst
> > > >    themselves. This enables them to have enough information to 
> > > > compute
> > > >    pairwise optimal paths for unicast, and to calculate 
> > distribution
> > > >    trees for delivery of frames either to unknown 
> destinations, or
> > to
> > > >    multicast/broadcast groups.
> > > >
> > > >    ECMP (Equal Cost MultiPath) may be supported, but it may
> > introduce
> > > >    frame reordering.
> > > >
> > > >
> > > > I think this is correct.
> > > >
> > > > -- Silvano
> > > >
> > > > > -----Original Message-----
> > > > > From: Radia Perlman [mailto:[e-mail]]
> > > > > Sent: Monday, May 07, 2007 8:28 PM
> > > > > To: Anoop Ghanwani
> > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; Silvano
> > Gai;
> > > > > [e-mail]
> > > > > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> > > > >
> > > > > Which draft says that multipathing (allowing more than 
> > one path to
> > a
> > > > > destination)
> > > > > is a nongoal? The architecture document, problem statement, or
> > > > protocol
> > > > > spec?
> > > > >
> > > > > Radia
> > > > >
> > > > >
> > > > > Anoop Ghanwani wrote:
> > > > > >
> > > > > > According to Radia's response, she thinks 
> > multipathing is being 
> > > > > > addressed and yet the draft explicitly  mentions it as a 
> > > > > > non-goal so there seems to be a bit of a disconnect.
> > > > > >
> > > > > >
> > > >
> > > >
> > 
> 



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 l49DQQJR026162 for <[e-mail]>; Wed, 9 May 2007 06:26:26 -0700 (PDT)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 09 May 2007 06:26:26 -0700 (PDT)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 09 May 2007 06:26:26 -0700 (PDT)
Received: from [152.70.2.164] (Forwarded-For: [12.174.94.138]) by mail-srv.sfvic.sunlabs.com (mshttpd); Wed, 09 May 2007 06:26:26 -0700
Date: Wed, 09 May 2007 06:26:26 -0700
From: [e-mail]
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] listening vs transmitting spanning tree messages
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, 09 May 2007 13:26:50 -0000
Status: RO
Content-Length: 2583

First -- I am not advocating turning the entire RBridged campus into one
giant spanning tree by *forwarding* bridge spanning tree messages
from one RBridge port to another. Somehow each time we try to
discuss this, some people get confused, and I don't want to
confuse people

The current version of the protocol spec says that RBridges should
transmit bridge spanning tree messages (BPDUs) with highest
priority (numerically lowest) for becoming root bridge, and
an RBridge should be DRB if and only if it becomes the root
of the bridge spanning tree on that layer 2 cloud. Again...this
is per port -- separate spanning tree on each port. Only if
an RBridge has two ports on the same layer 2 cloud (where
"layer 2 cloud" means it's connected with bridges) will
the spanning tree on one port have anything to do with
the spanning tree on another port.

The reason we had RBridges do that is to quickly catch the
case where two layer 2 clouds got merged, so that we
would very quickly stop there being two DRBs on the same cloud.

I think I still prefer this option, but an argument was made that
it is too complex to transmit BPDUs since there are too many
different versions of the spanning tree, and we'd have to
specify which ones must be supported.

So an alternate proposal is that RBridges only *listen* to
BPDUs.

Then, RBridge R1 can detect a potential merging of two layer 2
clouds on one of its ports if the Root bridge changes.

If the Root bridge changes, then R1 would stop forwarding
data packets to/from the link (because there might be another
DRB) for some amount of time.

Personally, I think I prefer transmitting, rather than simply
listening to BPDUs. The reasons:

a) I don't understand why it is more complex to transmit
rather than listen to BPDUs. Don't we have the same
issue with having to understand all the different versions
of the bridge spanning tree? Aren't all of the versions
compatible with the original spanning tree protocol
anyway, so that a bridge with highest
priority (numerically lowest) sending "original spanning
tree" protocol messages will become Root even
if other bridges are doing RSTP or MSTP or whatever? 

b) The rule "you are DRB if and only if you are the root
of the spanning tree" is clear.
With "do something if the bridge Root ID changes"
I think the rules are more squishy. How long
do you wait?

c) there might be bridge root ID changes a lot more
often than due to layer 2 clouds merging, and in
those cases the link will be unnecessarily
orphaned for awhile (while the one DRB waits
in case something is wrong).

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 l49DCKjC022797 for <[e-mail]>; Wed, 9 May 2007 06:12:21 -0700 (PDT)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 09 May 2007 06:12:18 -0700 (PDT)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 09 May 2007 06:12:18 -0700 (PDT)
Received: from [152.70.2.164] (Forwarded-For: [12.174.94.138]) by mail-srv.sfvic.sunlabs.com (mshttpd); Wed, 09 May 2007 06:12:18 -0700
Date: Wed, 09 May 2007 06:12:18 -0700
From: [e-mail]
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Per-VLAN DRB elections?
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, 09 May 2007 13:12:38 -0000
Status: RO
Content-Length: 3549

I think we haven't discussed this one on the list yet.

Bridges can be configured to not forward certain VLANs on certain links.
So, a "level 2 cloud" (a bunch of links connected with bridges) can be partitioned
with respect to various VLANs. So, for instance, RBridges R1 and R2 can be
neighbors on a cloud with respect to VLAN A, but not with VLAN B. In other
words, a packet tagged with "VLAN A" will get from R1 to R2, but one tagged
with "VLAN B" will not...even if both R1 and R2 think they are connected to VLAN B.

Oh...this is somewhat related to listening instead of participating in
the bridge spanning tree, which I will clarify in a separate thread.


Some issues with bridges not forwarding all VLANs:

a) If the IS-IS DRB (Designated RBridge)
election messages are tagged with VLAN B, then we will wind up
with two DRBs for the link (scary)

b) if R1 is selected DRB for the link, it may not be able to serve all endnodes (since
R1 might not be able to reach certain endnodes on some VLANs

c) in theory, DRB election should be separately carried out for each possible VLAN tag
(4000 of them). That would be too much.

d) there was a suggestion that it might be a feature to allow load sharing off a layer 2
cloud by having separate DRBs for different VLANs

So...here's a first strawman proposal, partially based on my memory of hallway conversations:

a) for the zero configuration case, assume that without configuration, the DRB election
is carried out once, tagged with VLAN 1. Whoever gets elected DRB in the DRB election
tagged with VLAN 1 is DRB for all VLANs on that link.

b) RBridges may be configured with other VLAN tags to also, on the same port, participate
in an IS-IS election with. DRB priority may be configured to be different for different VLANs, so
R1 might be configured, on port a, to participate in a DRB election for VLAN A with priority 7,
and VLAN B with priority 9

c) In the core instance of IS-IS, R1 announces not just which VLANs it is attached to, but
the Root bridge ID for that VLAN. That way, if R1 finds out (by seeing R2's link state packets)
that R2 claims to be DRB for VLAN A, with root bridge 89, and R1 thinks that it is DRB for VLAN A,
root bridge 89, then one of them should back off (using system ID as a tie breaker), where
"back off" means "stop acting as DRB", i.e., don't encapsulate/decapsulate data packets
to/from that port with respect to that VLAN

d) it is absolutely gross misconfiguration, and a disaster, if within the layer 2 cloud, a VLAN tag
can turn into another VLAN tag, because this could cause R1, who is DRB for
that link for VLAN A, to decapsulate a frame onto the link, which might pop out to
R2, who is DRB for that link for VLAN B, to see the packet as "VLAN B"

I *think* my proposal above has the following properties:

1) if a link is genuinely partitioned with respect to VLAN A, then there will be two DRBs elected
for that link, and all endnodes on that link in VLAN A will be reachable via one or the other
DRBs, and no link will be formed

2) as long as a VLAN tag can't get converted to another VLAN tag within the layer 2
cloud there will not be loops formed by having two DRBs on the same layer 2 cloud

3) we can do load sharing (R1 will be DRB for VLAN A and R2 will be for VLAN B)

4) if R1 and R2 wind up both elected as DRB for VLAN A and VLAN A is not actually
partitioned (but R1 can't reach R2), then they'll discover this through the core instance
IS-IS announcements

5) the common case can still be zero configuration

Comments?

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 l495JXC2015803 for <[e-mail]>; Tue, 8 May 2007 22:19:33 -0700 (PDT)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 08 May 2007 22:19:32 -0700 (PDT)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 08 May 2007 22:19:32 -0700 (PDT)
Received: from [152.70.2.164] (Forwarded-For: [12.174.94.138]) by mail-srv.sfvic.sunlabs.com (mshttpd); Tue, 08 May 2007 22:19:32 -0700
Date: Tue, 08 May 2007 22:19:32 -0700
From: [e-mail]
To: Silvano Gai <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 09 May 2007 05:20:00 -0000
Status: RO
Content-Length: 4177

Yes- I should have read all the messages before responding. Silvano's
response (below) is exactly what I said, but I used more words.

Radia



----- Original Message -----
From: Silvano Gai <[e-mail]>
Date: Tuesday, May 8, 2007 6:57 pm
Subject: RE: [rbridge] Two "shared VLAN" alternative proposals

> I don't think so, the inner MAC is not learnt by bridges if the 
> frame is
> TRILL encapsulated
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: Anoop Ghanwani [[e-mail]]
> > Sent: Tuesday, May 08, 2007 4:29 PM
> > To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman
> > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > 
> > 
> > That's assumes that one restricts the topology
> > to a clean edge-core-edge design where bridges
> > are present only at the edges (if at all).
> > 
> > The general case where you have a random mix
> > of bridges and rbridges is where the problem lies.
> > 
> > Anoop
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [[e-mail]]
> > > Sent: Tuesday, May 08, 2007 1:23 PM
> > > To: Eric Gray (LO/EUS); Radia Perlman; Anoop Ghanwani
> > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > >
> > >
> > > We do ECMP only in the core, but we don't learn in the core,
> > > so I don't see the problem.
> > >
> > > -- Silvano
> > >
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [[e-mail]]
> > > > Sent: Tuesday, May 08, 2007 8:23 AM
> > > > To: Silvano Gai; Radia Perlman; Anoop Ghanwani
> > > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > >
> > > > Silvano,
> > > >
> > > > 	The possibility of frame re-ordering using ECMP is not the only
> > > > concern.  A more significant issue is that schemes that exist 
> for> > > trying to avoid re-ordering may not guarantee symmetric frame
> > > > delivery.
> > > >
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson
> > > >
> > > > > -----Original Message-----
> > > > > From: Silvano Gai [[e-mail]]
> > > > > Sent: Tuesday, May 08, 2007 12:18 AM
> > > > > To: Radia Perlman; Anoop Ghanwani
> > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
> > > > > [e-mail]
> > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > > >
> > > > >
> > > > > The protocol specs states:
> > > > >
> > > > >    The main idea is to have RBridges run a link state protocol
> > > > > amongst
> > > > >    themselves. This enables them to have enough information to
> > > > > compute
> > > > >    pairwise optimal paths for unicast, and to calculate
> > > distribution
> > > > >    trees for delivery of frames either to unknown 
> destinations,or
> > > to
> > > > >    multicast/broadcast groups.
> > > > >
> > > > >    ECMP (Equal Cost MultiPath) may be supported, but it may
> > > introduce
> > > > >    frame reordering.
> > > > >
> > > > >
> > > > > I think this is correct.
> > > > >
> > > > > -- Silvano
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Radia Perlman [[e-mail]]
> > > > > > Sent: Monday, May 07, 2007 8:28 PM
> > > > > > To: Anoop Ghanwani
> > > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; 
> Silvano> > Gai;
> > > > > > [e-mail]
> > > > > > Subject: Re: [rbridge] Two "shared VLAN" alternative 
> proposals> > > > >
> > > > > > Which draft says that multipathing (allowing more than
> > > one path to
> > > a
> > > > > > destination)
> > > > > > is a nongoal? The architecture document, problem 
> statement, or
> > > > > protocol
> > > > > > spec?
> > > > > >
> > > > > > Radia
> > > > > >
> > > > > >
> > > > > > Anoop Ghanwani wrote:
> > > > > > >
> > > > > > > According to Radia's response, she thinks
> > > multipathing is being
> > > > > > > addressed and yet the draft explicitly  mentions it as a
> > > > > > > non-goal so there seems to be a bit of a disconnect.
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> 



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 l495IC7D015606 for <[e-mail]>; Tue, 8 May 2007 22:18:12 -0700 (PDT)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 08 May 2007 22:18:12 -0700 (PDT)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 08 May 2007 22:18:12 -0700 (PDT)
Received: from [152.70.2.164] (Forwarded-For: [12.174.94.138]) by mail-srv.sfvic.sunlabs.com (mshttpd); Tue, 08 May 2007 22:18:12 -0700
Date: Tue, 08 May 2007 22:18:12 -0700
From: [e-mail]
To: Anoop Ghanwani <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 09 May 2007 05:18:26 -0000
Status: RO
Content-Length: 804

----- Original Message -----
From: Anoop Ghanwani <[e-mail]>

> 
> That's assumes that one restricts the topology
> to a clean edge-core-edge design where bridges
> are present only at the edges (if at all).  
> 
> The general case where you have a random mix
> of bridges and rbridges is where the problem lies.
> 
> Anoop 

No I don't think that's a problem either, because if there were bridges between two RBridges
R1 and R2, when R1 transmits into the "layer 2 cloud" (a bunch of
links connected by bridges) that connects R1 and R2, the header
that bridges between R1 and R2
would see would be source=R1 and destination=R2 (the "outer header"), so having packets from
an ultimate source S in the inner frame that appear from multiple directions won't confuse
the inner bridges.

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 l495CnGb014520 for <[e-mail]>; Tue, 8 May 2007 22:12:50 -0700 (PDT)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 08 May 2007 22:12:45 -0700 (PDT)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 08 May 2007 22:12:44 -0700 (PDT)
Received: from [152.70.2.164] (Forwarded-For: [12.174.94.138]) by mail-srv.sfvic.sunlabs.com (mshttpd); Tue, 08 May 2007 22:12:44 -0700
Date: Tue, 08 May 2007 22:12:44 -0700
From: [e-mail]
To: Anoop Ghanwani <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 09 May 2007 05:12:58 -0000
Status: RO
Content-Length: 1672

Thanks Anoop -- I didn't notice that sentence in the requirements document.
I think it should just be removed. That sentence is:

>>  However, support for multi-pathing is potentially problematic and is 
>>   assumed - in this document - to be a non-goal.  Multi-path forwarding
>>  has the potential to confound the bridge learning process.

>From what I think multipathing is -- being able to use multiple paths within the core between the
ingress RBridge and egress RBridge -- it has nothing to do with the bridge learning process.
And RBridges specifically want to multipath both unicast and multicast, so at any rate, it
certainly seems like we should remove that sentence.

Radia

----- Original Message -----
From: Anoop Ghanwani <[e-mail]>
Date: Tuesday, May 8, 2007 9:14 am
Subject: RE: [rbridge] Two "shared VLAN" alternative proposals

> 
> Section 4.1 of the requirements doc. 
> 
> > -----Original Message-----
> > From: Radia Perlman [[e-mail]] 
> > Sent: Monday, May 07, 2007 8:28 PM
> > To: Anoop Ghanwani
> > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; 
> > Silvano Gai; [e-mail]
> > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> > 
> > Which draft says that multipathing (allowing more than one path 
> to a
> > destination)
> > is a nongoal? The architecture document, problem statement, 
> > or protocol spec?
> > 
> > Radia
> > 
> > 
> > Anoop Ghanwani wrote:
> > >
> > > According to Radia's response, she thinks multipathing is being 
> > > addressed and yet the draft explicitly  mentions it as a 
> > non-goal so 
> > > there seems to be a bit of a disconnect.
> > >
> > >   
> > 
> 



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 l491vwMa009783 for <[e-mail]>; Tue, 8 May 2007 18:57: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: Tue, 8 May 2007 18:57:54 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
Thread-Index: AceRINZgS3tsWg2LSLCtLi2zwv8JAgABrSywABMZjWAADqqQoAAGeftgAAUz2bA=
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Eric Gray \(LO/EUS\)" <[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 l491vwMa009783
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 09 May 2007 01:58:23 -0000
Status: RO
Content-Length: 3657

I don't think so, the inner MAC is not learnt by bridges if the frame is
TRILL encapsulated

-- Silvano

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Tuesday, May 08, 2007 4:29 PM
> To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman
> Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> 
> 
> That's assumes that one restricts the topology
> to a clean edge-core-edge design where bridges
> are present only at the edges (if at all).
> 
> The general case where you have a random mix
> of bridges and rbridges is where the problem lies.
> 
> Anoop
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Tuesday, May 08, 2007 1:23 PM
> > To: Eric Gray (LO/EUS); Radia Perlman; Anoop Ghanwani
> > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> >
> >
> > We do ECMP only in the core, but we don't learn in the core,
> > so I don't see the problem.
> >
> > -- Silvano
> >
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > Sent: Tuesday, May 08, 2007 8:23 AM
> > > To: Silvano Gai; Radia Perlman; Anoop Ghanwani
> > > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > >
> > > Silvano,
> > >
> > > 	The possibility of frame re-ordering using ECMP is not the only
> > > concern.  A more significant issue is that schemes that exist for
> > > trying to avoid re-ordering may not guarantee symmetric frame
> > > delivery.
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Tuesday, May 08, 2007 12:18 AM
> > > > To: Radia Perlman; Anoop Ghanwani
> > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
> > > > [e-mail]
> > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > >
> > > >
> > > > The protocol specs states:
> > > >
> > > >    The main idea is to have RBridges run a link state protocol
> > > > amongst
> > > >    themselves. This enables them to have enough information to
> > > > compute
> > > >    pairwise optimal paths for unicast, and to calculate
> > distribution
> > > >    trees for delivery of frames either to unknown destinations,
or
> > to
> > > >    multicast/broadcast groups.
> > > >
> > > >    ECMP (Equal Cost MultiPath) may be supported, but it may
> > introduce
> > > >    frame reordering.
> > > >
> > > >
> > > > I think this is correct.
> > > >
> > > > -- Silvano
> > > >
> > > > > -----Original Message-----
> > > > > From: Radia Perlman [mailto:[e-mail]]
> > > > > Sent: Monday, May 07, 2007 8:28 PM
> > > > > To: Anoop Ghanwani
> > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; Silvano
> > Gai;
> > > > > [e-mail]
> > > > > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> > > > >
> > > > > Which draft says that multipathing (allowing more than
> > one path to
> > a
> > > > > destination)
> > > > > is a nongoal? The architecture document, problem statement, or
> > > > protocol
> > > > > spec?
> > > > >
> > > > > Radia
> > > > >
> > > > >
> > > > > Anoop Ghanwani wrote:
> > > > > >
> > > > > > According to Radia's response, she thinks
> > multipathing is being
> > > > > > addressed and yet the draft explicitly  mentions it as a
> > > > > > non-goal so there seems to be a bit of a disconnect.
> > > > > >
> > > > > >
> > > >
> > > >
> >



Received: from mx20.brocade.com ([66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l48NUce1010492 for <[e-mail]>; Tue, 8 May 2007 16:30:38 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 08 May 2007 16:30:37 -0700
X-IronPort-AV: i="4.14,507,1170662400"; d="scan'208"; a="9513987:sNHT16271157"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 7152D23836D; Tue,  8 May 2007 16:29:10 -0700 (PDT)
Received: from hq-exch-1.corp.brocade.com ([10.3.8.21]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 8 May 2007 16:30:37 -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: Tue, 8 May 2007 16:29:19 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
Thread-Index: AceRINZgS3tsWg2LSLCtLi2zwv8JAgABrSywABMZjWAADqqQoAAGeftg
From: "Anoop Ghanwani" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Eric Gray (LO/EUS)" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 08 May 2007 23:30:37.0759 (UTC) FILETIME=[E22F5CF0:01C791C8]
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 l48NUce1010492
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 08 May 2007 23:30:50 -0000
Status: RO
Content-Length: 3077

That's assumes that one restricts the topology
to a clean edge-core-edge design where bridges
are present only at the edges (if at all).  

The general case where you have a random mix
of bridges and rbridges is where the problem lies.

Anoop 

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Tuesday, May 08, 2007 1:23 PM
> To: Eric Gray (LO/EUS); Radia Perlman; Anoop Ghanwani
> Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> 
> 
> We do ECMP only in the core, but we don't learn in the core, 
> so I don't see the problem.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > Sent: Tuesday, May 08, 2007 8:23 AM
> > To: Silvano Gai; Radia Perlman; Anoop Ghanwani
> > Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > 
> > Silvano,
> > 
> > 	The possibility of frame re-ordering using ECMP is not the only 
> > concern.  A more significant issue is that schemes that exist for 
> > trying to avoid re-ordering may not guarantee symmetric frame 
> > delivery.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Tuesday, May 08, 2007 12:18 AM
> > > To: Radia Perlman; Anoop Ghanwani
> > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; 
> > > [e-mail]
> > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > >
> > >
> > > The protocol specs states:
> > >
> > >    The main idea is to have RBridges run a link state protocol 
> > > amongst
> > >    themselves. This enables them to have enough information to 
> > > compute
> > >    pairwise optimal paths for unicast, and to calculate 
> distribution
> > >    trees for delivery of frames either to unknown destinations, or
> to
> > >    multicast/broadcast groups.
> > >
> > >    ECMP (Equal Cost MultiPath) may be supported, but it may
> introduce
> > >    frame reordering.
> > >
> > >
> > > I think this is correct.
> > >
> > > -- Silvano
> > >
> > > > -----Original Message-----
> > > > From: Radia Perlman [mailto:[e-mail]]
> > > > Sent: Monday, May 07, 2007 8:28 PM
> > > > To: Anoop Ghanwani
> > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; Silvano
> Gai;
> > > > [e-mail]
> > > > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> > > >
> > > > Which draft says that multipathing (allowing more than 
> one path to
> a
> > > > destination)
> > > > is a nongoal? The architecture document, problem statement, or
> > > protocol
> > > > spec?
> > > >
> > > > Radia
> > > >
> > > >
> > > > Anoop Ghanwani wrote:
> > > > >
> > > > > According to Radia's response, she thinks 
> multipathing is being 
> > > > > addressed and yet the draft explicitly  mentions it as a 
> > > > > non-goal so there seems to be a bit of a disconnect.
> > > > >
> > > > >
> > >
> > >
> 



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 l48KNJYE023306 for <[e-mail]>; Tue, 8 May 2007 13:23:19 -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: Tue, 8 May 2007 13:23:16 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
Thread-Index: AceRINZgS3tsWg2LSLCtLi2zwv8JAgABrSywABMZjWAADqqQoA==
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[e-mail]>, "Radia Perlman" <[e-mail]>, "Anoop Ghanwani" <[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 l48KNJYE023306
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 08 May 2007 20:23:46 -0000
Status: RO
Content-Length: 2347

We do ECMP only in the core, but we don't learn in the core, so I don't
see the problem.

-- Silvano

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> Sent: Tuesday, May 08, 2007 8:23 AM
> To: Silvano Gai; Radia Perlman; Anoop Ghanwani
> Cc: J. R. Rivers; Caitlin Bestler; [e-mail]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> 
> Silvano,
> 
> 	The possibility of frame re-ordering using ECMP is not
> the only concern.  A more significant issue is that schemes
> that exist for trying to avoid re-ordering may not guarantee
> symmetric frame delivery.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Tuesday, May 08, 2007 12:18 AM
> > To: Radia Perlman; Anoop Ghanwani
> > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
> > [e-mail]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> >
> >
> > The protocol specs states:
> >
> >    The main idea is to have RBridges run a link state
> > protocol amongst
> >    themselves. This enables them to have enough information
> > to compute
> >    pairwise optimal paths for unicast, and to calculate distribution
> >    trees for delivery of frames either to unknown destinations, or
to
> >    multicast/broadcast groups.
> >
> >    ECMP (Equal Cost MultiPath) may be supported, but it may
introduce
> >    frame reordering.
> >
> >
> > I think this is correct.
> >
> > -- Silvano
> >
> > > -----Original Message-----
> > > From: Radia Perlman [mailto:[e-mail]]
> > > Sent: Monday, May 07, 2007 8:28 PM
> > > To: Anoop Ghanwani
> > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; Silvano
Gai;
> > > [e-mail]
> > > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> > >
> > > Which draft says that multipathing (allowing more than one path to
a
> > > destination)
> > > is a nongoal? The architecture document, problem statement, or
> > protocol
> > > spec?
> > >
> > > Radia
> > >
> > >
> > > Anoop Ghanwani wrote:
> > > >
> > > > According to Radia's response, she thinks multipathing
> > > > is being addressed and yet the draft explicitly  mentions
> > > > it as a non-goal so there seems to be a bit of a disconnect.
> > > >
> > > >
> >
> >



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l48H7KjG027387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 8 May 2007 10:07:20 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l48H8TeJ002338; Tue, 8 May 2007 12:08:30 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 8 May 2007 12:07:17 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 8 May 2007 12:07:16 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
Thread-Index: AceRIMHse2TQOTobSN6K3zfi0YKuHAAayz0gAACFA+A=
References: <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 08 May 2007 17:07:17.0546 (UTC) FILETIME=[54FD60A0:01C79193]
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 l48H7KjG027387
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 08 May 2007 17:07:59 -0000
Status: RO
Content-Length: 2353

Anoop,

	I suspect that the statement to which you refer (in the
section on interactions between routing and bridging) could be
removed without loss of content.

	It is intended to address the issue of explicitly using
any ECMP support provided by - or using - any existing routing
protocols.  I doubt that it is really necessary to explicitly
say that.

	Since maintaining symmetric routing is a non-goal in an
IP routing protocol, and maintaining symmetric forwarding is a
very important requirement for support of bridge learning, it
is intended to say that support for ECMP in any candidate RP
is not a goal (or crtieria) that would be used to select it for
use by TRILL.

	I have to say that the tendency to think of the routing
requirements draft as if it was somehow imposing requirements 
on TRILL (as opposed to stating TRILL's requirements of routing)
is a recurring problem.  The fact that the only thing we are
producing that is like a "TRILL requirements" document is the 
"Problem Statement and Applicability" draft, is not helping to
make this less confusing.  People see the term "Requirements"
in the RR draft and say "ahh, here's where TRILL requirements
are defined..."

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Tuesday, May 08, 2007 12:15 PM
> To: Radia Perlman
> Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; 
> Silvano Gai; [e-mail]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> 
> 
> Section 4.1 of the requirements doc. 
> 
> > -----Original Message-----
> > From: Radia Perlman [mailto:[e-mail]] 
> > Sent: Monday, May 07, 2007 8:28 PM
> > To: Anoop Ghanwani
> > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; 
> > Silvano Gai; [e-mail]
> > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> > 
> > Which draft says that multipathing (allowing more than one path to a
> > destination)
> > is a nongoal? The architecture document, problem statement, 
> > or protocol spec?
> > 
> > Radia
> > 
> > 
> > Anoop Ghanwani wrote:
> > >
> > > According to Radia's response, she thinks multipathing is being 
> > > addressed and yet the draft explicitly  mentions it as a 
> > non-goal so 
> > > there seems to be a bit of a disconnect.
> > >
> > >   
> > 
> 



Received: from mx10.brocade.com ([66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l48GFpQl011281 for <[e-mail]>; Tue, 8 May 2007 09:15:51 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 08 May 2007 09:15:49 -0700
X-IronPort-AV: i="4.14,506,1170662400";  d="scan'208"; a="10791585:sNHT14981848"
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 0DE0923836D; Tue,  8 May 2007 09:14:22 -0700 (PDT)
Received: from hq-exch-1.corp.brocade.com ([10.3.8.21]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 8 May 2007 09:15: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: Tue, 8 May 2007 09:14:31 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
Thread-Index: AceRIMHse2TQOTobSN6K3zfi0YKuHAAayz0g
From: "Anoop Ghanwani" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 08 May 2007 16:15:48.0205 (UTC) FILETIME=[239959D0:01C7918C]
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 l48GFpQl011281
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 08 May 2007 16:16:08 -0000
Status: RO
Content-Length: 761

Section 4.1 of the requirements doc. 

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]] 
> Sent: Monday, May 07, 2007 8:28 PM
> To: Anoop Ghanwani
> Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; 
> Silvano Gai; [e-mail]
> Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> 
> Which draft says that multipathing (allowing more than one path to a
> destination)
> is a nongoal? The architecture document, problem statement, 
> or protocol spec?
> 
> Radia
> 
> 
> Anoop Ghanwani wrote:
> >
> > According to Radia's response, she thinks multipathing is being 
> > addressed and yet the draft explicitly  mentions it as a 
> non-goal so 
> > there seems to be a bit of a disconnect.
> >
> >   
> 



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l48FNE4R027769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 8 May 2007 08:23:15 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l48FON3t011063; Tue, 8 May 2007 10:24:23 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 8 May 2007 10:23:11 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 8 May 2007 10:23:07 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
Thread-Index: AceRINZgS3tsWg2LSLCtLi2zwv8JAgABrSywABMZjWA=
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Radia Perlman" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>
X-OriginalArrivalTime: 08 May 2007 15:23:11.0032 (UTC) FILETIME=[C9C6FB80:01C79184]
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 l48FNE4R027769
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 08 May 2007 15:23:39 -0000
Status: RO
Content-Length: 1843

Silvano,

	The possibility of frame re-ordering using ECMP is not
the only concern.  A more significant issue is that schemes
that exist for trying to avoid re-ordering may not guarantee 
symmetric frame delivery.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Tuesday, May 08, 2007 12:18 AM
> To: Radia Perlman; Anoop Ghanwani
> Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; 
> [e-mail]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> 
> 
> The protocol specs states:
> 
>    The main idea is to have RBridges run a link state 
> protocol amongst 
>    themselves. This enables them to have enough information 
> to compute 
>    pairwise optimal paths for unicast, and to calculate distribution 
>    trees for delivery of frames either to unknown destinations, or to 
>    multicast/broadcast groups. 
> 
>    ECMP (Equal Cost MultiPath) may be supported, but it may introduce 
>    frame reordering. 
> 
> 
> I think this is correct.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: Radia Perlman [mailto:[e-mail]]
> > Sent: Monday, May 07, 2007 8:28 PM
> > To: Anoop Ghanwani
> > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; Silvano Gai;
> > [e-mail]
> > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> > 
> > Which draft says that multipathing (allowing more than one path to a
> > destination)
> > is a nongoal? The architecture document, problem statement, or
> protocol
> > spec?
> > 
> > Radia
> > 
> > 
> > Anoop Ghanwani wrote:
> > >
> > > According to Radia's response, she thinks multipathing
> > > is being addressed and yet the draft explicitly  mentions
> > > it as a non-goal so there seems to be a bit of a disconnect.
> > >
> > >
> 
> 



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 l484Hbqi019110 for <[e-mail]>; Mon, 7 May 2007 21:17:37 -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, 7 May 2007 21:17:33 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
Thread-Index: AceRINZgS3tsWg2LSLCtLi2zwv8JAgABrSyw
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Anoop Ghanwani" <[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 l484Hbqi019110
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 08 May 2007 04:17:51 -0000
Status: RO
Content-Length: 1188

The protocol specs states:

   The main idea is to have RBridges run a link state protocol amongst 
   themselves. This enables them to have enough information to compute 
   pairwise optimal paths for unicast, and to calculate distribution 
   trees for delivery of frames either to unknown destinations, or to 
   multicast/broadcast groups. 

   ECMP (Equal Cost MultiPath) may be supported, but it may introduce 
   frame reordering. 


I think this is correct.

-- Silvano

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]]
> Sent: Monday, May 07, 2007 8:28 PM
> To: Anoop Ghanwani
> Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler; Silvano Gai;
> [e-mail]
> Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> 
> Which draft says that multipathing (allowing more than one path to a
> destination)
> is a nongoal? The architecture document, problem statement, or
protocol
> spec?
> 
> Radia
> 
> 
> Anoop Ghanwani wrote:
> >
> > According to Radia's response, she thinks multipathing
> > is being addressed and yet the draft explicitly  mentions
> > it as a non-goal so there seems to be a bit of a disconnect.
> >
> >




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 l483RHsu007783 for <[e-mail]>; Mon, 7 May 2007 20:27:17 -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, 07 May 2007 20:27:03 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.16.161]) 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, 07 May 2007 20:27:03 -0700 (PDT)
Date: Mon, 07 May 2007 20:27:34 -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]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 08 May 2007 03:27:47 -0000
Status: RO
Content-Length: 383

Which draft says that multipathing (allowing more than one path to a 
destination)
is a nongoal? The architecture document, problem statement, or protocol 
spec?

Radia


Anoop Ghanwani wrote:
>
> According to Radia's response, she thinks multipathing
> is being addressed and yet the draft explicitly  mentions
> it as a non-goal so there seems to be a bit of a disconnect.
>
>   



Received: from mx10.brocade.com ([66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l47IoLuE028782 for <[e-mail]>; Mon, 7 May 2007 11:50:21 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 07 May 2007 11:50:20 -0700
X-IronPort-AV: i="4.14,502,1170662400";  d="scan'208"; a="10699332:sNHT18164314"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id E6A2723836D; Mon,  7 May 2007 11:48:54 -0700 (PDT)
Received: from hq-exch-1.corp.brocade.com ([10.3.8.21]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 7 May 2007 11:50:20 -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, 7 May 2007 11:49:02 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals
Thread-Index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAFDs4AQlSv2QABs1FhACZSHt4A==
From: "Anoop Ghanwani" <[e-mail]>
To: "Eric Gray (LO/EUS)" <[e-mail]>, "J. R. Rivers" <[e-mail]>, "Caitlin Bestler" <[e-mail]>, "Silvano Gai" <[e-mail]>, "Radia Perlman" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 07 May 2007 18:50:20.0941 (UTC) FILETIME=[902AD3D0:01C790D8]
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 l47IoLuE028782
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
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, 07 May 2007 18:50:36 -0000
Status: RO
Content-Length: 3655

Eric/Radia,

Thanks for the responses.  I wouldn't even consider
the second scenario below to be multipathing.  That's
a different issue altogether.

According to Radia's response, she thinks multipathing
is being addressed and yet the draft explicitly  mentions
it as a non-goal so there seems to be a bit of a disconnect.

I think at the very least this issue ought to be clarified
further in the draft.  If there are problems with supporting
ECMP, those problems should be pointed out, so that people
understand where they can/cannot deploy ECMP.

Anoop

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> Sent: Thursday, April 26, 2007 11:26 AM
> To: Anoop Ghanwani; J. R. Rivers; Caitlin Bestler; Silvano 
> Gai; Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> 
> Anoop,
> 
> 	There are (at least) two possible interpretations of 
> what is meant by "multi-pathing."
> 
> 	One is the sort of multipathing that is roughly 
> analogous to either link-bundling (at L2) or ECMP (usually 
> for L3 routing).
> 
> 	The other is the sort that has to do with the more 
> general form of "load-sharing" - i.e. - simply trying to 
> ensure that all possible links are being used, roughly at 
> some proportional ratio relative to their capacities.  This 
> form of multi-pathing is not dependent on multiple-path use 
> for essentially the same traffic (i.e. - as defined by 
> edge-to-edge unidirectional forwarding).
> 
> 	I believe that many people (especially those who are 
> not completely up to speed on - for example - MSTP) are 
> thinking of the second form of "multi-pathing" when they 
> refer to this term.
> When using MSTP, there are no unused links and load-sharing 
> is a natural consequence of the assignment of VIDs on the 
> basis of separate spanning tree instances.
> 
> 	As you may know, there are problems that must be 
> addressed in using the first form of multi-pathing scheme if 
> we need to be able to maintain forwarding symmetry on an 
> end-point pair basis.  
> These difficulties are reduced by using a hierarchical 
> (tunneled) overlay with RBridges, but they are not eliminated...
> 
> Thanks!
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Tuesday, April 24, 2007 9:14 PM
> > To: J. R. Rivers; Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); 
> > Radia Perlman; [e-mail]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > Importance: High
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of J. R. Rivers
> > > Sent: Tuesday, April 03, 2007 3:47 PM
> > > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); 
> Radia Perlman; 
> > > [e-mail]
> > > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> > > 
> > > 
> > > I would have thought that RBridges are "better bridges" 
> > > because they allow multi-pathing at layer 2 creating 
> significantly 
> > > more available bandwidth and with a deployment cost/complexity 
> > > relatively close to
> > > 802.1 bridges.
> > 
> > Is TRILL going to solve the multipathing problem?
> > 
> > From
> > http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-r
> > eqs-02.txt
> >    However, support for multi-pathing is potentially 
> problematic and 
> > is
> >    assumed - in this document - to be a non-goal.  Multi-path 
> > forwarding
> >    has the potential to confound the bridge learning process.
> > 
> > Anoop
> > 
> 



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 l47HaMdL008040 for <[e-mail]>; Mon, 7 May 2007 10:36:22 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-14.tower-119.messagelabs.com!1178559381!20607455!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [144.189.100.101]
Received: (qmail 30541 invoked from network); 7 May 2007 17:36:21 -0000
Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-14.tower-119.messagelabs.com with SMTP; 7 May 2007 17:36:21 -0000
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l47HaKhC010929 for <[e-mail]>; Mon, 7 May 2007 10:36:20 -0700 (MST)
Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l47HaKx2024167 for <[e-mail]>; Mon, 7 May 2007 12:36:20 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l47HaIGN024146 for <[e-mail]>; Mon, 7 May 2007 12:36:19 -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, 7 May 2007 13:36:18 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header Format
thread-index: AceMOFmd34CG6+gpShO0FWctc8TnBwAJ/CIgARe0HxAAAKDwgA==
References: <[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]><461ED550.9080501@isi.!edu>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<4626E9D3.7090502@is!!	!i.e	du><34BDD2A	[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]><[e-mail]! ! .com> < 4637B1F6.304 [e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "J. R. Rivers" <[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 l47HaMdL008040
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format
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, 07 May 2007 17:36:34 -0000
Status: RO
Content-Length: 11512

I agree, although it is trivially easier to calculate the offset if the
VLAN tag information is in the TRILL Header.

I never claimed the current design wouldn't work or can't be
implemented. It just seems to me that saving 2 bytes on every frame and
speeding up cut through switching by moving the VLAN tag information at
least 14 bytes earlier in the frame are more important.

Donald

-----Original Message-----
From: J. R. Rivers [mailto:[e-mail]] 
Sent: Monday, May 07, 2007 11:51 AM
To: Eastlake III Donald-LDE008; Joe Touch
Cc: [e-mail]
Subject: RE: [rbridge] TRILL Header Format

In all fairness, the VLAN tag is at an easily calculated offset with
either proposal.

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Tuesday, May 01, 2007 7:43 PM
> To: Joe Touch
> Cc: [e-mail]
> Subject: Re: [rbridge] TRILL Header Format
> 
> Hi Joe,
> 
> I see it as exactly the other way.
> 
> Most commonly, the VLAN ID is associated with a native frame only
> because of the port it is received on, although it is 
> certainly possible
> for an end station to include one. Thus, in the most common 
> case, it is
> the current design which requires the ingress Rbridge to insert a Q/S
> tag inside the encapsulated frame, thus modifying it, and 
> similarly most
> commonly requires the egress Rbridge to remove that tag from 
> inside the
> encapsulated frame, although their can be configurations where it is
> retained.
> 
> Thus, Solution 2 would generally require *less* modification of
> encapsulated frames at ingress and egress than would Solution 1.
> 
> The above is in answer to your point on 'modification' since I believe
> Solution 2 results in less modification. I'm not sure I 
> understand your
> "parsing and debugging" point. For every Rbridge other than 
> the ingress
> Rbridge, for every frame the Rbridge has to (a) find the TRILL Header
> and (b) find the VLAN tag. It seems to me to make the parsing job
> simpler to put the VLAN tag information at a fixed location 
> in the TRILL
> Header.
> 
> Donald
> 
> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Tuesday, May 01, 2007 5:33 PM
> To: Eastlake III Donald-LDE008
> Cc: Dinesh G Dutt; Silvano Gai; [e-mail]
> Subject: Re: [rbridge] TRILL Header Format
> 
> Eastlake III Donald-LDE008 wrote:
> > Hi,
> > 
> > I agree with Dinesh's comment and would also like to say that my
> > personal preference is for Solution 2. I just don't feel there are
> > enough reserved bit available for future use in the minimal 
> Solution 1
> > and since, in the general case, every Rbridge has to look 
> at the VLAN
> > ID, putting it in a fixed place nearer the beginning of the 
> frame, as
> > done in Solution 2, seems like a good idea.
> 
> I agree in spirit, but don't agree that the inner frame should be
> modified during processing; this just complicates parsing and 
> debugging,
> and increases the potential for implementation errors.
> 
> IMO, the VLAN tags should be copied, not moved.
> 
> Joe
> 
> > Thanks,
> > Donald 
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Dinesh G Dutt
> > Sent: Monday, April 30, 2007 3:19 PM
> > To: Silvano Gai
> > Cc: [e-mail]
> > Subject: Re: [rbridge] TRILL Header Format
> > 
> > Two small corrections. In the second format, we really 
> don't need any 
> > indication of .1Q/.1S. The tag that is to be added at the 
> egress port 
> > maybe different from the tag that we received at the 
> ingress port and
> is
> > 
> > part of the port logic. For example, the frame may have 
> come in with a
> 
> > .1Q tag and may go out a port that accepts no tagging at all.
> > 
> > Given that we don't need to carry any indication of .1Q/.1S in the
> TRILL
> > 
> > header, I suggest that we also define the field "Inner 802.1Q/S tag"
> to 
> > be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator and
> call
> > 
> > it DE (drop eligibility). This way if RBridges along the way can
> choose 
> > to set the DE bit in the inner header, instead of treating it as an 
> > opaque field.
> > 
> > Dinesh
> > Silvano Gai wrote:
> >> The purpose of the following message is to converge on the final
> >> structure of the TRILL header.
> >>
> >> The format proposed in:
> >>
> >
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-p
rotocol-03
> >> .txt
> >> has been stable for a while. This message only describes the
> >> differences.
> >>
> >> At the last IETF Donald proposed to support a single 
> extension header
> >> containing multiple extensions.
> >>
> >> After some discussion two solutions seem possible. Please express
> your
> >> preference by replying to this email.
> >>
> >> -- Silvano
> >>
> >>
> >> Solution 1
> >> ==========
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>                                       | V 
> |M|RSD|EH-length| Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> Where:
> >> - RSD (2 bits) is reserved
> >> - EH-Length (5 bits) is the extension header length, expressed in
> > units
> >> of in 4 bytes words.
> >>
> >> If EH-length is zero there is no extension header;
> >> else, the extensions follow immediately after the Egress Rbridge
> >> Nickname field, and the total length of all the extensions is as
> >> indicated by the EH-length field, expressed in units of 
> 4-byte words.
> >>
> >> This solution allows 128 bytes of extensions.
> >>
> >>
> >> Solution 2
> >> ==========
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>                                       |  V  |M|S| RSD |   Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |    RSD        |   EH-length   |  Inner IEEE 802.1Q/S tag
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and
> Priority)
> >> into the TRILL header. The Inner 1Q/1S tag is no longer present in
> the
> >> inner frame.
> >>
> >> This simplifies the parsing for the core RBridges. On the 
> other hand
> > the
> >> Ingress/Egress Rbridges need to do slightly more work. 
> >>
> >> This has more reserved space. Since the inner 1Q/1S tag is removed
> > from
> >> the frame (4 bytes), it uses the same overall space of solution 1.
> >>
> >> The S bit indicates if the inner header was 1Q (S=0) or 1S (S=1).
> >>
> >> The EH-length is 8 bits, with a granularity of 2 bytes it allows up
> to
> >> 512 bytes of extensions.
> >>
> >> The Hop Count can grow to 8 bits.
> >>
> >>
> >> A word of caution
> >> =================
> >>
> >> Extensions are very appealing, but their practical deployment has
> been
> >> very limited. Often Router and Switches are not able to 
> process in HW
> >> frames with extensions and they send them to SW.
> >>
> >>
> >> Example with Solution 1
> >> ======================= 
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |               Outer Destination MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Outer Destination MAC Address | Outer Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                   Outer Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = TRILL             | V 
> |M|RSD|EH-length| Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |               Inner Destination MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Inner Destination MAC Address | InnerSource MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                    Inner Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Inner VID
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |
> > | 
> >>       |                 Original Ethernet Payload
> > | 
> >>       |
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                           New FCS
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>              TRILL Encapsulation over Ethernet with Solution 1
> >>
> >>
> >>
> >>
> >> Example with Solution 2
> >> =======================
> >>
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |               Outer Destination MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Outer Destination MAC Address | Outer Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                   Outer Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = TRILL             |  V  |M|S| RSD |   Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |    RSD        |   EH-length   |  UP |C|    Inner VID
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |               Inner Destination MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Inner Destination MAC Address | InnerSource MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                    Inner Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |
> > | 
> >>       |                 Original Ethernet Payload
> > | 
> >>       |
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                           New FCS
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>                TRILL Encapsulation over Ethernet with Solution 2
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> rbridge mailing list
> >> [e-mail]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>
> >>   
> > 
> 
> -- 
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment



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 l47GtCob019538 for <[e-mail]>; Mon, 7 May 2007 09:55:12 -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, 7 May 2007 09:55:06 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] header rough consensus
Thread-Index: AceP+zu/8qKh4iQLSReq1YrcK3vcVQAxJADw
References: <[e-mail]>
From: "J. R. Rivers" <[e-mail]>
To: "Silvano Gai" <[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 l47GtCob019538
Subject: Re: [rbridge] header rough consensus
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, 07 May 2007 16:55:32 -0000
Status: RO
Content-Length: 2001

I wanted to point out three addition things...

First, since one of TRILL's goals is L2 multi-pathing, I think we'll
find that information from layers other than L2 will be used for
distributing frames (ie. IP addresses, TCP/UDP ports, FC_IDs) as is done
for L2 port channels and IP multipathing today.  This means that
implementations will likely have to parse past the TRILL header in all
cases.

Second, care must be taken surrounding the expectations of the extension
header.  Since it's usage is undefined, there is a good chance that
implementations will evaluate/forward frames with extensions in the slow
path.  I would vote that extensions get evaluated/defined in their own
groups and get real Ethertypes.  Particularly scary is that the
extensibility in the proposal is currently 124B which is roughly twice
the size of a min sized Ethernet frame.

Lastly, TRILL frames traversing legacy L2 networks would likely travel
down a port bundle.  Since TRILL is a new Ethertype, most existing
bundle distribution systems will use a the L2 DA/SA/VLAN to select links
(they won't be able to get to higher level protocols).  We might want to
allow an RBridge to have multiple synonymous MAC addresses that can be
used as the Ethernet SA to facilitate load balancing.  The transmitting
RBridge could select a source address based on a load balancing
algorithm.

JR



> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Silvano Gai
> Sent: Sunday, May 06, 2007 9:26 AM
> To: [e-mail]
> Subject: [rbridge] header rough consensus
> 
> 
> Trying to summarize the results, my understanding is:
> 
> Solution 1
> - Silvano
> - Dino
> - Joe
> - Eric
> 
> Solution 2
> - Donald
> 
> Not sure about:
> - Dinesh
> - Radia
> 
> Am I correct?
> Did I miss anybody?
> 
> -- Silvano
> 
> _______________________________________________
> 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 l47GemiR012363 for <[e-mail]>; Mon, 7 May 2007 09:40: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: Mon, 7 May 2007 09:40:37 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] header rough consensus
Thread-Index: AceQuq7skeE74OmJS0Ke2GQpKIpiywAC7fRA
References: <[e-mail]> <[e-mail]>
From: "J. R. Rivers" <[e-mail]>
To: <[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 l47GemiR012363
Subject: Re: [rbridge] header rough consensus
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, 07 May 2007 16:40:58 -0000
Status: RO
Content-Length: 1123

 
I prefer option 1.

JR

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Dinesh G Dutt
> Sent: Monday, May 07, 2007 8:06 AM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: Re: [rbridge] header rough consensus
> 
> I waffled for a bit and ended up with I prefer solution 1,
> 
> Dinesh
> Silvano Gai wrote:
> > Trying to summarize the results, my understanding is:
> >
> > Solution 1
> > - Silvano
> > - Dino
> > - Joe
> > - Eric
> >
> > Solution 2
> > - Donald
> >
> > Not sure about:
> > - Dinesh
> > - Radia
> >
> > Am I correct?
> > Did I miss anybody?
> >
> > -- Silvano
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> >   
> 
> -- 
> We make our world significant by the courage of our questions and by 
> the depth of our answers.                               - Carl Sagan
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l47GbRv0010589 for <[e-mail]>; Mon, 7 May 2007 09:37:28 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-11.tower-119.messagelabs.com!1178555846!16229167!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 4200 invoked from network); 7 May 2007 16:37:27 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with SMTP; 7 May 2007 16:37:27 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l47GbQYN027742 for <[e-mail]>; Mon, 7 May 2007 09:37:26 -0700 (MST)
Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l47GbQaW015330 for <[e-mail]>; Mon, 7 May 2007 11:37:26 -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 l47GbPiq015325 for <[e-mail]>; Mon, 7 May 2007 11:37:26 -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, 7 May 2007 12:37:24 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: TRILL at July IETF Meeting, March Proceedings
thread-index: AceQxf22LqKxpIIPS0+7lA3SZhP/Hw==
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 l47GbRv0010589
Subject: [rbridge] TRILL at July IETF Meeting, March Proceedings
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, 07 May 2007 16:38:01 -0000
Status: RO
Content-Length: 510

Hi,

Erik Nordmark and I are considering requesting two meeting slots in
Chicago for the TRILL WG. We hope that this would enable increased
progress by the group.

The deadline for corrections to the minutes of the March meeting in
Prague is this coming Wednesday, 9 May, at 5pm eastern Us time.

Comments welcome,

Thanks,
Donald

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



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 l47Fp5ZU026346 for <[e-mail]>; Mon, 7 May 2007 08:51:05 -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, 7 May 2007 08:50:59 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header Format
Thread-Index: AceMOFmd34CG6+gpShO0FWctc8TnBwAJ/CIgARe0HxA=
References: <[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]><461ED550.9080501@isi.!edu>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<4626E9D3.7090502@is!!	!i.e	du><34BDD2A	[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]><[e-mail]! .com> <46 37B1F6.30406 [e-mail]> <[e-mail]>
From: "J. R. Rivers" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, "Joe Touch" <[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 l47Fp5ZU026346
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format
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, 07 May 2007 15:51:30 -0000
Status: RO
Content-Length: 11054

In all fairness, the VLAN tag is at an easily calculated offset with
either proposal.

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Tuesday, May 01, 2007 7:43 PM
> To: Joe Touch
> Cc: [e-mail]
> Subject: Re: [rbridge] TRILL Header Format
> 
> Hi Joe,
> 
> I see it as exactly the other way.
> 
> Most commonly, the VLAN ID is associated with a native frame only
> because of the port it is received on, although it is 
> certainly possible
> for an end station to include one. Thus, in the most common 
> case, it is
> the current design which requires the ingress Rbridge to insert a Q/S
> tag inside the encapsulated frame, thus modifying it, and 
> similarly most
> commonly requires the egress Rbridge to remove that tag from 
> inside the
> encapsulated frame, although their can be configurations where it is
> retained.
> 
> Thus, Solution 2 would generally require *less* modification of
> encapsulated frames at ingress and egress than would Solution 1.
> 
> The above is in answer to your point on 'modification' since I believe
> Solution 2 results in less modification. I'm not sure I 
> understand your
> "parsing and debugging" point. For every Rbridge other than 
> the ingress
> Rbridge, for every frame the Rbridge has to (a) find the TRILL Header
> and (b) find the VLAN tag. It seems to me to make the parsing job
> simpler to put the VLAN tag information at a fixed location 
> in the TRILL
> Header.
> 
> Donald
> 
> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Tuesday, May 01, 2007 5:33 PM
> To: Eastlake III Donald-LDE008
> Cc: Dinesh G Dutt; Silvano Gai; [e-mail]
> Subject: Re: [rbridge] TRILL Header Format
> 
> Eastlake III Donald-LDE008 wrote:
> > Hi,
> > 
> > I agree with Dinesh's comment and would also like to say that my
> > personal preference is for Solution 2. I just don't feel there are
> > enough reserved bit available for future use in the minimal 
> Solution 1
> > and since, in the general case, every Rbridge has to look 
> at the VLAN
> > ID, putting it in a fixed place nearer the beginning of the 
> frame, as
> > done in Solution 2, seems like a good idea.
> 
> I agree in spirit, but don't agree that the inner frame should be
> modified during processing; this just complicates parsing and 
> debugging,
> and increases the potential for implementation errors.
> 
> IMO, the VLAN tags should be copied, not moved.
> 
> Joe
> 
> > Thanks,
> > Donald 
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Dinesh G Dutt
> > Sent: Monday, April 30, 2007 3:19 PM
> > To: Silvano Gai
> > Cc: [e-mail]
> > Subject: Re: [rbridge] TRILL Header Format
> > 
> > Two small corrections. In the second format, we really 
> don't need any 
> > indication of .1Q/.1S. The tag that is to be added at the 
> egress port 
> > maybe different from the tag that we received at the 
> ingress port and
> is
> > 
> > part of the port logic. For example, the frame may have 
> come in with a
> 
> > .1Q tag and may go out a port that accepts no tagging at all.
> > 
> > Given that we don't need to carry any indication of .1Q/.1S in the
> TRILL
> > 
> > header, I suggest that we also define the field "Inner 802.1Q/S tag"
> to 
> > be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator and
> call
> > 
> > it DE (drop eligibility). This way if RBridges along the way can
> choose 
> > to set the DE bit in the inner header, instead of treating it as an 
> > opaque field.
> > 
> > Dinesh
> > Silvano Gai wrote:
> >> The purpose of the following message is to converge on the final
> >> structure of the TRILL header.
> >>
> >> The format proposed in:
> >>
> >
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-p
rotocol-03
> >> .txt
> >> has been stable for a while. This message only describes the
> >> differences.
> >>
> >> At the last IETF Donald proposed to support a single 
> extension header
> >> containing multiple extensions.
> >>
> >> After some discussion two solutions seem possible. Please express
> your
> >> preference by replying to this email.
> >>
> >> -- Silvano
> >>
> >>
> >> Solution 1
> >> ==========
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>                                       | V 
> |M|RSD|EH-length| Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> Where:
> >> - RSD (2 bits) is reserved
> >> - EH-Length (5 bits) is the extension header length, expressed in
> > units
> >> of in 4 bytes words.
> >>
> >> If EH-length is zero there is no extension header;
> >> else, the extensions follow immediately after the Egress Rbridge
> >> Nickname field, and the total length of all the extensions is as
> >> indicated by the EH-length field, expressed in units of 
> 4-byte words.
> >>
> >> This solution allows 128 bytes of extensions.
> >>
> >>
> >> Solution 2
> >> ==========
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>                                       |  V  |M|S| RSD |   Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |    RSD        |   EH-length   |  Inner IEEE 802.1Q/S tag
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and
> Priority)
> >> into the TRILL header. The Inner 1Q/1S tag is no longer present in
> the
> >> inner frame.
> >>
> >> This simplifies the parsing for the core RBridges. On the 
> other hand
> > the
> >> Ingress/Egress Rbridges need to do slightly more work. 
> >>
> >> This has more reserved space. Since the inner 1Q/1S tag is removed
> > from
> >> the frame (4 bytes), it uses the same overall space of solution 1.
> >>
> >> The S bit indicates if the inner header was 1Q (S=0) or 1S (S=1).
> >>
> >> The EH-length is 8 bits, with a granularity of 2 bytes it allows up
> to
> >> 512 bytes of extensions.
> >>
> >> The Hop Count can grow to 8 bits.
> >>
> >>
> >> A word of caution
> >> =================
> >>
> >> Extensions are very appealing, but their practical deployment has
> been
> >> very limited. Often Router and Switches are not able to 
> process in HW
> >> frames with extensions and they send them to SW.
> >>
> >>
> >> Example with Solution 1
> >> ======================= 
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |               Outer Destination MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Outer Destination MAC Address | Outer Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                   Outer Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = TRILL             | V 
> |M|RSD|EH-length| Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |               Inner Destination MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Inner Destination MAC Address | InnerSource MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                    Inner Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Inner VID
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |
> > | 
> >>       |                 Original Ethernet Payload
> > | 
> >>       |
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                           New FCS
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>              TRILL Encapsulation over Ethernet with Solution 1
> >>
> >>
> >>
> >>
> >> Example with Solution 2
> >> =======================
> >>
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |               Outer Destination MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Outer Destination MAC Address | Outer Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                   Outer Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = TRILL             |  V  |M|S| RSD |   Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |    RSD        |   EH-length   |  UP |C|    Inner VID
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |               Inner Destination MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Inner Destination MAC Address | InnerSource MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                    Inner Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |
> > | 
> >>       |                 Original Ethernet Payload
> > | 
> >>       |
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                           New FCS
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>                TRILL Encapsulation over Ethernet with Solution 2
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> rbridge mailing list
> >> [e-mail]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>
> >>   
> > 
> 
> -- 
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment
> 
> 
> _______________________________________________
> 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 l47F5WkU016129 for <[e-mail]>; Mon, 7 May 2007 08:05:32 -0700 (PDT)
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 07 May 2007 08:05:33 -0700
X-IronPort-AV: i="4.14,501,1170662400";  d="scan'208"; a="483983176:sNHT43794050"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l47F5WGL030335;  Mon, 7 May 2007 08:05:32 -0700
Received: from [10.21.100.20] (sjc-vpn1-1044.cisco.com [10.21.100.20]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l47F5VZT017759; Mon, 7 May 2007 15:05:31 GMT
Message-ID: <[e-mail]>
Date: Mon, 07 May 2007 08:05:30 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Silvano Gai <[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=651; t=1178550332; x=1179414332; 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]=20header=20rough=20consensus |Sender:=20; bh=eM0zXH+w5AaCSfw7IAfKL/nl+gZKey0w3x076DD2R9s=; b=ieQ6jsBNl/J62kNwt8G827egeYuWeDsus2Tt43HKn2xDxs9SH16B1GF32FFEAhnElREUN2Zc 9IM4uDJdUFjZbugAWLIgb6DKCOSTt0c50bDz8o1ZsUoj9cMYHdY3JFV9ffssi0ridIsQGytTWi bvNI62ehE2+Qm1simHjEPnSMk=;
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] header rough consensus
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, 07 May 2007 15:05:57 -0000
Status: RO
Content-Length: 617

I waffled for a bit and ended up with I prefer solution 1,

Dinesh
Silvano Gai wrote:
> Trying to summarize the results, my understanding is:
>
> Solution 1
> - Silvano
> - Dino
> - Joe
> - Eric
>
> Solution 2
> - Donald
>
> Not sure about:
> - Dinesh
> - Radia
>
> Am I correct?
> Did I miss anybody?
>
> -- Silvano
>
> _______________________________________________
> 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 mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l47EjlXt011237 for <[e-mail]>; Mon, 7 May 2007 07:45:47 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-119.messagelabs.com!1178549146!20175173!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 7037 invoked from network); 7 May 2007 14:45:46 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-119.messagelabs.com with SMTP; 7 May 2007 14:45:46 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l47EjjhP021539 for <[e-mail]>; Mon, 7 May 2007 07:45:46 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l47Ejjpm009058 for <[e-mail]>; Mon, 7 May 2007 09:45:45 -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 l47Ejiaj009047 for <[e-mail]>; Mon, 7 May 2007 09:45:44 -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, 7 May 2007 10:45:43 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] header rough consensus
thread-index: AceP+zu/8qKh4iQLSReq1YrcK3vcVQAuHrRg
References: <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, <[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 l47EjlXt011237
Subject: Re: [rbridge] header rough consensus
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, 07 May 2007 14:45:56 -0000
Status: RO
Content-Length: 1062

Hi Silvano,

It had not escaped my notice that the three other people posting an
opinion on this topic are thus far unanimously of the opposite opinion
from mine. :-) In fact, I spoke on the telephone with Erik Nordmark, my
co-chair, on this topic last Friday. We are jointly of the opinion that
there may be new arguments on this question or arguments that have not
been fully explained and we should wait some small number of days
further before making a consensus determination.

Thanks,
Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Silvano Gai
Sent: Sunday, May 06, 2007 12:26 PM
To: [e-mail]
Subject: [rbridge] header rough consensus


Trying to summarize the results, my understanding is:

Solution 1
- Silvano
- Dino
- Joe
- Eric

Solution 2
- Donald

Not sure about:
- Dinesh
- Radia

Am I correct?
Did I miss anybody?

-- Silvano

_______________________________________________
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 l47EVMhf007855 for <[e-mail]>; Mon, 7 May 2007 07:31: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: Mon, 7 May 2007 07:31:14 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Back to ND/ARP optimization
Thread-Index: AceOblafu+PL4g4qT3KM+9hk+Br5xAAD8QvwAGnH5SAABisDIAAGFgXwABZeTGA=
References: <[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]>
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 l47EVMhf007855
Cc: [e-mail]
Subject: Re: [rbridge] Back to ND/ARP optimization
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, 07 May 2007 14:31:26 -0000
Status: RO
Content-Length: 7880

Donald,

Let's consider the following RBridge

+---------------------------------------------+
| RBRIDGE                                     |
|                +--------+                   |
|                |  CPU   |                   |
|                +--------+                   |
|                    |                        |
|                +--------+                   |
|                | Fabric |                   |
|                +--------+                   |
|                 |   |   |                   |
+-----------------+---+---+-------------------+
                  |   |   |
                  A   B   C

It has three ports A, B, C, one internal fabric and one CPU.

In the following I will assume that it has won DR election on all the
ports.

WITH NO ARP/ND OPTIMIZATION
===========================
An ARP for Z is received on port A.
The fabric forwards it as a regular Broadcast (i.e. it sends it on all
the ports except the one where it came in). It goes out on B and C (but
not on A) and the CPU gets a copy. The CPU is not Z, so the ARP process
in the CPU discards it.

WITH ARP/ND OPTIMIZATION
========================
An ARP for Z is received on port A.
The fabric MUST be programmed to not forward ARP has a regular
broadcast, but to pass it to the CPU. Therefore a single copy of the ARP
frame is sent to the CPU. The CPU cannot do a simple test, as in the
previous case, but it needs to search Z in a cache (a bit more
expensive). It misses. What happens next is interesting.

You say that you want to "forwards it in native form out every other
port".

We cannot send out of port A, since we received the ARP from port A and
we MUST send it ONLY on B and C. 
Therefore the CPU must:
- not use the classical broadcast mode (otherwise A will get a copy of
the frame);
- remember in SW from which port it received the frame;
- use some fabric specific mechanism to send out the frame only on B and
C.

The mechanism I have seen used in these cases is called "port direct" or
"index direct" in which basically the CPU has a way to send out any kind
of frame on a particular port. 

If this mechanism is used, the CPU needs to replicate in SW the ARP
query.

Other mechanism can be invented and implemented in HW, but I don't think
they are worthwhile. See also the reply of Arien.

I hope it clarifies.

-- Silvano


> -----Original Message-----
> From: Eastlake III Donald-LDE008 [mailto:[e-mail]]
> Sent: Sunday, May 06, 2007 8:40 PM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: RE: [rbridge] Back to ND/ARP optimization
> 
> Silvano,
> 
> Sorry, I still don't understand this.
> 
> What does an Rbridge do if it receives a native broadcast frame with
an
> unknown Ethertype (unknown in the sense that it is not in any special
> table or comparison implemented in the Rbridge)? If the Rbridge isn't
> the DR for the port it received it on, it drops it. If it is the DR,
it
> forwards it in native form out every other port for which it is the DR
> and which is in the same VLAN. It also encapsulates it and sends it
off
> on a distribution tree pruned by VLAN.
> 
> What does an Rbridge do if it receives a native broadcast ARP frame?
If
> it isn't the DR for the port it receive it on, it drops it. Otherwise,
> it learns the IP to MAC mapping for the sender fields in the ARP frame
> and it tries to find the target IP address in its database of IP to
MAP
> mappings. If it can't find an entry for the target IP address, it then
> proceeds as in the paragraph above to flood it.
> 
> In other words, for an unknown target IP address, processing of a
> broadcast ARP frame is exactly the same as for an unknown Ethertype
> except for the learning step and the table look up attempt step. Why
> can't this be done in hardware? Even if I assume the learning and
table
> look up happen in software, if the IP address isn't found, why
couldn't
> the software just re-inject the frame into the hardware as if it had
> come in on its original receipt port with a flag saying "treat like an
> unknown Ethertype"?
> 
> Thanks,
> Donald
> 
> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]]
> Sent: Sunday, May 06, 2007 8:36 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: RE: [rbridge] Back to ND/ARP optimization
> 
> 
> Donald,
> 
> To provide a precise answer we need to consider which of the three
> schemes described in section 3.12 of
>
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03
> .txt
> the RBridge will implement.
> 
> The draft refers generically to "Some mix of these strategies".
> 
> Lacking this information, let's assume the strategy you mention.
> The flood cannot be done in HW. In fact it is mandatory to not resend
> the ARP on the port it was received to avoid frame duplication.
> 
> The flood must be implemented in SW has n-1 port transmissions; where
n
> is the number of ports.
> 
> Therefore, the CPU of a 256 port RBridge:
> - in absence of ARP/ND proxy receives 1 ARP (and the HW does the
correct
> replication)
> - with ARP/ND proxy it receives 1 ARP (and the HW does nothing)and
sends
> out 255 ARP messages. Huge overhead
> 
> -- Silvano
> 
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008
[mailto:[e-mail]]
> > Sent: Sunday, May 06, 2007 2:30 PM
> > To: Silvano Gai
> > Cc: [e-mail]
> > Subject: RE: [rbridge] Back to ND/ARP optimization
> >
> > Silvano,
> >
> > I don't understand what these Rbridge CPUs will be doing. If an
> Rbridge
> > receives a native ARP broadcast frame for an unknown IP address it
> would
> > just learn the source IP->MAC mapping and then flood the ARP
> broadcast.
> >
> > Donald
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Silvano Gai
> > Sent: Friday, May 04, 2007 3:01 PM
> > To: Arien Vijn
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: [rbridge] Back to ND/ARP optimization
> >
> > Arien
> >
> > Thanks for the real world data, which proves that ARP/ND proxy must
> not
> > be implemented on RBridges.
> >
> > In fact, since the queries toward unused addresses are dominant, the
> > ARP/ND cache will almost always miss and the RBridge CPU will be
busy
> > trying to remotely resolve queries that will never complete.
> >
> > -- Silvano
> >
> > > -----Original Message-----
> > > From: Arien Vijn [mailto:[e-mail]]
> > > Sent: Friday, May 04, 2007 10:04 AM
> > > To: Silvano Gai
> > > Cc: Arien Vijn; [e-mail]; [e-mail]
> > > Subject: Re: [rbridge] Back to ND/ARP optimization
> > >
> > > Hi,
> > >
> > > On May 3, 2007, at 10:55 PM, Silvano Gai wrote:
> > >
> > > [...]
> > >
> > > >> Does anyone have a handle on how much traffic is caused by
> ARP/ND?
> > > >>
> > > >
> > > > With an ARP cache of 30 minutes, typical in hosts today, even
with
> > > > a 100
> > > > K hosts in a VLAN we get at most 55 ARP seconds. Since not all
the
> > > > hosts
> > > > talk with each other, it is more typically like 5 ARP/sec.
> > > >
> > > > BASICALLY NOTHING.
> > >
> > > Well... that might be the case if all your hosts are actually
> > > answering. But query rates are pretty much determined by queries
for
> > > unused addresses. In other words by the query rates hosts
(routers)
> > > can achieve for addresses that are not in their caches.
> > >
> > > For what its worth. I am involved in a real network with 400+ BGP
> > > routers in one broadcast domain (/23 IPv4 subnet). The average
rate
> > > is little over 13 queries/second. That is with ARP mitigation and
> > > peak rates are much higher.
> > >
> > > -- Arien
> >
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge



Received: from betonmix.noc.ams-ix.net (betonmix.noc.ams-ix.net [193.194.136.135]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l47EMeTu005388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 7 May 2007 07:22:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id 9E47A1027AA; Mon,  7 May 2007 16:22:39 +0200 (CEST)
Received: from [192.168.1.64] (orkano.xs4all.nl [213.84.188.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id 65DEE1027A3; Mon,  7 May 2007 16:22:39 +0200 (CEST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Arien Vijn <[e-mail]>
Date: Mon, 7 May 2007 16:22:40 +0200
To: Radia Perlman <[e-mail]>
X-Mailer: Apple Mail (2.752.2)
X-Virus-Scanned: by amavisd-new at betonmix.noc.ams-ix.net
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Back to ND/ARP optimization
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, 07 May 2007 14:22:54 -0000
Status: RO
Content-Length: 2236

Hello Radia,

On May 6, 2007, at 12:10 AM, Radia Perlman wrote:

> Actually, I'm not sure that's the conclusion that Arien was making  
> (that ARP/ND
> optimization is not worth it), especially with the comment "peak  
> rates much higher".
>
> So Arien...was that actually your conclusion?

Eh... I just posted an observation that differed from the theory :)

> I think that ARP/ND optimization could be added in the future as an  
> option, or
> even that an implementation can do something about it without  
> having the spec
> saying anything about it. Which would argue for not needing it in  
> the spec now.

I agree. Please see my reply on one of your other postings on this list.

> But just want to verify what Arien's conclusion is from the data  
> presented...

My conclusion would be that you should consider that most queries are  
futile. Because in my observations, successful queries are not the  
bulk of the traffic. Hence I think that there is not much gain in  
optimising those. To me it seems hard to optimise unsuccessful  
queries. Throttling seems the only feasible way.

To give a bit more insight:

	1/ Futile ARP/ND queries are mostly due to scanners. Scanners try  
all addresses in one subnet, causing routers to query over and over  
again.

	2/ Another cause is more specific for the peering LAN I presented.  
Many operators just do not remove BGP sessions for peers that have  
left. Routers will continue to query for the lost peer.

	3/ Some systems do perform far more queries than others. As  
illustration you may want to have a quick look at this presentation  
and note some remarkable differences between vendors:

http://www.ams-ix.net/~arien/TM24-AV-ARP-V01.pdf

	4/ The peak rates I mentioned are due to the fact that the ARP  
mitigation kicks in after a while. Without mitigation, we would see a  
constant high query rate. The first version of this system was  
actually created when we saw that routers could not handle the  
increased query rate during a renumbering action.

Considering the above, I also come to the conclusion that all of this  
is a matter for end hosts (routers mostly).

Kind regards, Arien


--
Arien Vijn
Amsterdam Internet Exchange
http://www.ams-ix.net





Received: from betonmix.noc.ams-ix.net (betonmix.noc.ams-ix.net [193.194.136.135]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l47EE51x003132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 7 May 2007 07:14:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id 17AC91027AA; Mon,  7 May 2007 16:14:04 +0200 (CEST)
Received: from [192.168.1.64] (orkano.xs4all.nl [213.84.188.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id D0CA91027A3; Mon,  7 May 2007 16:14:03 +0200 (CEST)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Arien Vijn <[e-mail]>
Date: Mon, 7 May 2007 16:14:05 +0200
To: [e-mail]
X-Mailer: Apple Mail (2.752.2)
X-Virus-Scanned: by amavisd-new at betonmix.noc.ams-ix.net
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Back to ND/ARP optimization
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, 07 May 2007 14:14:28 -0000
Status: RO
Content-Length: 3111

Hello Radia,

On May 3, 2007, at 4:38 PM, [e-mail] wrote:

> Looking back on old emails, there are some people who'd like to get  
> rid of ND/ARP optimization,
> and some people pointing out that optimizing ND might not be so  
> simple (for instance, SEND).
>
> I'd be OK with removing it from the spec, or certainly making it  
> something other than a MUST, like
> perhaps MAY.
>
> But there were fields in the per-VLAN instance of IS-IS to  
> facilitate this, namely the (L3 address, L2 address).
> An RBridge *could* learn this information locally, but wouldn't  
> learn it as much. In other words, if S behind R1 sends
> an ARP request for target T behind R2, the response will be unicast  
> to S, so none of the other RBridges will
> learn where T is. Only R1. So R1 could in the future do a proxy  
> ARP. But if R2 announced (T, t) in its per-VLAN
> instance of IS-IS, then all the RBridges could learn (T,t).  
> Furthermore, if T has registered with R2 via some
> L2 enrollment protoocol, then R2 can immediately know if T is no  
> longer there and alert everyone.

This mechanism optimises successful quires, but I think that those  
are not the bulk of the ARP/ND broadcasts/multicasts.

> Does anyone have a handle on how much traffic is caused by ARP/ND?
>
> We could certainly do a compromise, like that each RBridge R1  
> SHOULD throttle ARP/ND queries, and
> not reflood a query for T if there has been more than k (some  
> parameter) queries for T in the last n seconds.

This is similar to the way we do ARP mitigation. We made a friendly  
ARP spoofer that starts spoofing replies when the queries for T reach  
a threshold and after it verified that T is indeed unreachable. It  
stops spoofing for T as soon as it detects any sign of life from T.  
It works like charm as long as ARP caches and associated hard and  
software resources can deal with all these resolved addresses.

So I think that this approach would work. It may be implemented as  
feature in (R)bridges. But I think that it is better address it at  
the source and add a (optional) back-off mechanism in ARP/ND  
implementations.

> But that doesn't even have to be in the spec.

True.

> It would be nice to know in operational networks how much traffic  
> is caused by ARP/ND queries, and how
> worried people are about a malicious endnode DOS'ing by sending  
> lots of queries. (but it could just as easily
> send other types of broadcast/multicast traffic so maybe it's not  
> worth worrying about optimization ARP/ND because
> of malicious nodes).

Run a hacker conference network and you'll know that unfriendly ARP  
spoofing is reality. Would you choose to include ARP/ND optimizations  
then you should take that into account too.

Considering the possible consequences of ARP/ND optimizations versus  
what it would gain, I would suggest not to put that in the specs from  
the start. RBridges are probably difficult enough to engineer.  
Besides, I see no reason why this could not be added later on.

Cheers, Arien


--
Arien Vijn
Amsterdam Internet Exchange
http://www.ams-ix.net





Received: from smtp2.sgsi.ucl.ac.be (smtp.dynsipr.ucl.ac.be [130.104.4.2]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l47CofqG013271 for <[e-mail]>; Mon, 7 May 2007 05:50:42 -0700 (PDT)
Received: from smtp2.sgsi.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTP id 9C6F8DB6B8; Mon,  7 May 2007 14:50:33 +0200 (CEST)
Received: from [10.100.100.175] (34-4-74-65.dataflow.static.gci.net [65.74.4.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: [e-mail]) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTP; Mon,  7 May 2007 14:50:33 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 07 May 2007 14:50:33 +0200
From: Pierre Francois <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: sachin jain <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AV-Checked: ClamAV using ClamSMTP
X-SGSI-MailScanner: Found to be clean
X-SGSI-SpamCheck: 
X-SGSI-From: [e-mail]
X-SGSI-Spam-Status: No
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], "[e-mail]" <[e-mail]>, Joe Touch <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail]
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 07 May 2007 12:51:01 -0000
Status: RO
Content-Length: 4605

Sachin,

With the rpf check, you will have transient loops and duplications,
but no deadly storms where duplicated packets re-enter the loop and 
"feed" the loop,
This is similar to what you have with pim-ssm's rpf check.


Pierre.

sachin jain wrote:
> Hi,
>   I think the RPF check can have transient loops for packets in flight 
> during topology change. It does seem to have no loop for new packets.
> Let me explain that with an example with only one distribution tree.
>
> The topologys is as follows
>   ------------------------------------
>   |                                  |
> R1 -------                         |
>   |          |                        |
>   |          R2      ------------  R3
>   |            |                        |
>   |            |                        |
>   | ------   R4   ------------------
>
> [Description : R1 is connected to every switch and R2, R3, R4 are 
> connected in a loop]
>
> There is only one distribition tree agreed upon which is rooted at R1.
>
> Suppose during a transient change the ISIS link state database at 
> different switches is such that the tree that each switch computes is 
> as follows
>
> R2: Tree is R1->R4->R2->R3
> R3: Tree is R1->R2->R3->R4
> R4: Tree is R1->R3->R4->R2
>
> Suppose there is a packet which was originated from R1 and is in 
> flight between R2 and R3 just when the topology change happened. Now 
> this packet will loop between R2, R3, R4 because for each of them it 
> is receiving on the link which passes the RPF check for source R1.
>
> Are above scenarios unlikely or acceptable?
>
> sachin
>
> On 5/3/07, *[e-mail] <mailto:[e-mail]>* < 
> [e-mail] <mailto:[e-mail]>> wrote:
>
>     Sorry Eric. There ought to be a better name for it than "the RPF
>     thing".
>     What's being talked about is what I presented at the WG, which is
>     the precomputation, for each tree, for each port, the set of
>     ingress RBridges
>     from which it would be logical to receive packets from, on that port.
>
>     To summarize "the RPF thing" (and I'd love a better name for it,
>     but maybe we
>     don't need to name it-- we can just put the algorithm in the spec)
>
>     a) Each RBridge R1 announces, in the core instance of IS-IS, the
>     set of
>     trees R1 will ever choose as distribution trees for packets that
>     R1 injects. So
>     say that R1 chooses {R1, R4, and R5}
>
>     b) Each RBridge also announces whether it wants to be the root
>     of a tree
>
>     c) Each RBridge R2 calculates a tree for each of the RBridges that
>     have say "yes"
>     for b).
>
>     d) An RBridge, say R3, calculates the tree rooted at, say, R5.
>     Let's say that
>     R3 determines that ports a, b, c, and f are in the R5-tree.
>     Then let's say that of all the RBridges, {R6 and R7} say (in a)
>     that they
>     are going to choose the R5-tree. R3 figures out which port it should
>     receive things from R6, on the R5-tree, and marks that port as
>     "ingress RBridge R6 allowed". Likewise it does that for the port
>     for which it should receive things from R7 on that tree.
>
>     e) R3 does filtering as follows: If R3 receives a multicast packet
>     marked
>     as R5-tree (egress RBridge field =R5), with ingress RBridge Rx, on
>     port p,
>     then if the ingress RBridge is not listed among the allowed
>     ingress RBridges for that port for that tree, R3 discards the packet.
>
>     Note the overhead for this is that if the average number of trees
>     each ingress
>     RBridge says they will select is 2 (I'd think most RBridges would
>     select only one
>     tree -- it would be only for RBridges that want to multipath
>     multicast that they'd
>     select more than one tree), then there are only 2*number of
>     RBridges TOTAL
>     that will get listed as legal ingress RBridges.
>
>     Radia
>
>     ----- Original Message -----
>     From: "Eric Gray (LO/EUS)" <[e-mail]
>     <mailto:[e-mail]>>
>
>     >
>     >       First, what exactly is the "Radia RPF" proposal that you
>     > mention in another thread of discussion,
>
>     _______________________________________________
>     rbridge mailing list
>     [e-mail] <mailto:[e-mail]>
>     http://mailman.postel.org/mailman/listinfo/rbridge
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l4746GNI012884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Sun, 6 May 2007 21:06:16 -0700 (PDT)
Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net [71.106.84.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l4745t21014557; Sun, 6 May 2007 21:05:56 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sun, 06 May 2007 21:05:37 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Eastlake III Donald-LDE008 <[e-mail]>
References: <[e-mail]>	<4626E9D3.7090502@is!!	! i.e	du><34BDD2A	[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]> <[e-mail]! ! .com> <	[e-mail]> <[e-mail]> <463! 80980.907	[e-mail]> <[e-mail]> <4638A77E.8! 090200@is	i.edu> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB5ADCCCC67B3A6B67A48C218"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format
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, 07 May 2007 04:06:54 -0000
Status: RO
Content-Length: 8571

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB5ADCCCC67B3A6B67A48C218
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Comments below...

Eastlake III Donald-LDE008 wrote:
> Hi Joe,
>=20
> First I want to refine an earlier statement of mine. The VLAN ID
> information isn't involved in all forwarding decisions by Rbridges. But=

> it is involved in all multi-destination forwarding decisions by Rbridge=
s
> and for unicast it is involved in all ingress and egress processing. Th=
e
> priority information, which is also in the VLAN tag information, is
> relevant to queuing at every transit Rbridge.
>=20
> See below at @@@=20
>=20
> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]=20
> Sent: Wednesday, May 02, 2007 11:00 AM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: Re: [rbridge] TRILL Header Format
>=20
> Eastlake III Donald-LDE008 wrote:
>> Hi Joe,
>>
>> I don't see any reason to assume any bridges are involved.=20
>=20
> Agreed. All functions that rbridges do that are identical to what
> bridges do should be stated as an assumption (rbridges can subsume all
> bridge functions except the rest of our discussion.
>=20
> My point is that if a bridge (in an rbridge or not) adds a VLAN tag,
> then a bridge (in an rbridge or not) nearest the destination host will
> remove that tag. Even when the tag-adding bridge is the ingress rbridge=
,
> we cannot assume in our architecture that the tag-removing bridge is th=
e
> egress rbridge; it could as easily be a bridge later in the arch.
>=20
> @@@ When you say "a bridge (in an rbridge or not)" you seem to imply
> that there is a bridge inside every rbridge.

There can be; there need not be. More specifically, conventional bridge
functions such as VLAN tagging could be supported inside an rbridge.

> That doesn't make any sense
> to me. There isn't a bridge "inside" an Rbridge. The Rbridge is an
> integrated device that is a bridge (Rbridge stands for "Routing
> Bridge"). It is a better bridge.

That would presume we subsumed the entirety of what bridges do; we have
to date focused on what has changed.

> It uses IS-IS instead of *STP. It uses
> different formats on the wire between Rbridges. It may or may not have
> various optimizations. It's not an 802.1 bridge but it is a bridge
> nevertheless.

Then there could be 802.1 bridge functions additionally supported.

> And once a frame is ingressed by an Rbridge and has a
> TRILL Header added, every bit after the TRILL Ethertype through to just=

> before the FCS is completely private to TRILL capable devices and TRILL=

> capable software.

I disagree; TRILL devices are not encryption tunneling devices. As such,
the innermost header may be utilized at any rbridge, though one would
hope neither the innermost header nor the TRILL header would be used by
non-rbridge devices.

> Nothing TRILL ignorant will be able to parse past the
> TRILL Ethertype. It seems only reasonable to format that information fo=
r
> Rbridge convenience and efficiency.

It does, but it isn't required that information inside that header be
copied; that is neither efficient nor necessarily more convenient.

> To the extent that rbridges do this function (adding VLAN tags or
> removing them), that happens to the inner header. That function has
> nothing to do with rbridges per se; it doesn't belong in the rbridge
> header. If rbridge functions need to refer to that tag, they know where=

> it would be and how to find it.

If an rbridge adds VLAN tags, it can do so in two places - the innermost
header or the outermost header; the innermost header would represent
'conventional' VLAN tagging, and the outermost would represent VLAN tags
used for intra-campus traversal.

If an rbridge supports conventional VLAN tagging (i.e., conventional
bridge capability), then the egress would NOT be the place to remove
that tag, so it would make no sense to have that tag anywhere other than
the innermost header.

> @@@ Rbridges are bridges. Your artificially carving out of the VLAN
> functionality, part of the heart of how Rbridges work, and declaring it=

> to have nothing to do with Rbridges makes no sense at all.

I disagree, as above. It is orthogonal to rbridge functionality.

> @@@ The best view of VLAN ID, the multi-destination bit, frame priority=
,
> the "egress Rbridge", ... is that these are all pieces of
> meta-information that are not part of the actual data frame. They exist=

> even when they are never encoded into a wire format.

Agreed, except for VLAN ID; that could be removed elsewhere, e.g.,
outside the campus, and as such has no business being in the TRILL header=
=2E

Keep in mind that rbridges may be a superset of bridges, but I don't
assume they replace all bridges everywhere. If there are bridges after
the egress, the VLAN tag would need to stay in place.

> @@@ In the future situation we are aiming for, the normal case will be
> that this meta-information will by synthesized when an Rbridge receives=

> a native frame. It would never be wire encoded if the frame is between
> two end stations both directly connected to that Rbridge.

Agreed. But that again presumes a world where there are no bridges in a
campus - either used for rbridge-rbridge or rbridge-endstation. I don't
agree that's to be assumed.

> If the frame
> has to be forwarded to another Rbridge, then the meta-information does
> have to be wire encoded but such inter-Rbridge frames always have a
> TRILL Header which is the obvious place for all this meta-information
> all of which will be of interest to the receiving RBridge.
>=20
>> What happens when such a message is received by a transit Rbridge?
> There
>> might be an outer 802.1AE tag or the like, which is removed and
>> processed at the port. There might be an outer VLAN tag which is
>> logically removed on receipt so frame now logically and perhaps
>> physically starts with a TRILL Ethertype. The Rbridge MUST then derive=

>> inner VLAN tag information to decide how to forward the frame. With
>> Solution 2, it is at a fixed offset from the TRILL Ethertype and close=

>> to the beginning of the frame, to speed cut through switching. With
>> Solution 1, the Rbridge has to skip over a variable amount of
> extension
>> data and extract the VLAN tag information from deeper in the frame at
> a
>> variable offset from the TRILL Ethertype.
>=20
> This argument would imply that if the rbridge were not there that a
> bridge would need to extract the VLAN tag from the inner header at a
> variable offset. Since that's already done, I see no problem.
>
> @@@ I don't understand your comment above at all. Sure, if your replace=

> all your Rbridges with 802.1Q bridges, then you have an 802.1Q bridge
> synthesizing a more limited set of meta-information. And if you have
> inter-802.1Q-bridge forwarding, then that meta-information is
> wire-encoded in the 802.1Q format of a Ethertype followed by the two
> bytes of Q/S-tag information. If you have Rbridges, then there is a
> larger set of meta-information and if you have an inter-Rbridge
> forwarding, then this larger set of meta-information is wire-encoded an=
d
> that wire-encoding is whatever we say it is. This encoding will only be=

> parsed by TRILL capable devices. It just makes no sense to me that, in
> the Rbridge case, you want to split this meta-information into two
> parts, throw away two bytes on an extra Ethertype, move the information=

> which corresponds to that in a Q/S tag at least 14 bytes deeper into th=
e
> frame to slow down cut through switching, and, in almost all cases,
> modify the frame being encapsulated by inserting this part of the meta
> information inside it.

The reason, as above, to repeat, is that I don't assume all bridges or
all rbridges; I believe a mixed deployment is not only likely in
transition, but should be supported regardless.

Joe

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


--------------enigB5ADCCCC67B3A6B67A48C218
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGPqWRE5f5cImnZrsRAsjUAJ40hOP3z3z0GMI92bKuGSLvAiqZpQCgkFH+
mZn7NqbfQdRuPMnjtC9SOD0=
=9kvZ
-----END PGP SIGNATURE-----

--------------enigB5ADCCCC67B3A6B67A48C218--



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 l473lwLc009193 for <[e-mail]>; Sun, 6 May 2007 20:47:58 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-13.tower-128.messagelabs.com!1178509677!3895989!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 24556 invoked from network); 7 May 2007 03:47:57 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 7 May 2007 03:47:57 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l473lvw2022158 for <[e-mail]>; Sun, 6 May 2007 20:47:57 -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 l473luNf019434 for <[e-mail]>; Sun, 6 May 2007 22:47:57 -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 l473luxs019427 for <[e-mail]>; Sun, 6 May 2007 22:47:56 -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: Sun, 6 May 2007 23:47:49 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header Format
thread-index: AceMyq6hkHl39gPRRAyxgUjvti/iigBMEnFg
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<4626E9D3.7090502@is!!	! i.e	du><34BDD2A	[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]> <[e-mail]! ! .com> <	[e-mail]> <[e-mail]> <463! 80980.907	[e-mail]> <[e-mail]> <4638A77E.8090200@is i.edu>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Joe Touch" <[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 l473lwLc009193
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format
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, 07 May 2007 03:48:11 -0000
Status: RO
Content-Length: 5849

Hi Joe,

First I want to refine an earlier statement of mine. The VLAN ID
information isn't involved in all forwarding decisions by Rbridges. But
it is involved in all multi-destination forwarding decisions by Rbridges
and for unicast it is involved in all ingress and egress processing. The
priority information, which is also in the VLAN tag information, is
relevant to queuing at every transit Rbridge.

See below at @@@ 

-----Original Message-----
From: Joe Touch [mailto:[e-mail]] 
Sent: Wednesday, May 02, 2007 11:00 AM
To: Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format

Eastlake III Donald-LDE008 wrote:
> Hi Joe,
> 
> I don't see any reason to assume any bridges are involved. 

Agreed. All functions that rbridges do that are identical to what
bridges do should be stated as an assumption (rbridges can subsume all
bridge functions except the rest of our discussion.

My point is that if a bridge (in an rbridge or not) adds a VLAN tag,
then a bridge (in an rbridge or not) nearest the destination host will
remove that tag. Even when the tag-adding bridge is the ingress rbridge,
we cannot assume in our architecture that the tag-removing bridge is the
egress rbridge; it could as easily be a bridge later in the arch.

@@@ When you say "a bridge (in an rbridge or not)" you seem to imply
that there is a bridge inside every rbridge. That doesn't make any sense
to me. There isn't a bridge "inside" an Rbridge. The Rbridge is an
integrated device that is a bridge (Rbridge stands for "Routing
Bridge"). It is a better bridge. It uses IS-IS instead of *STP. It uses
different formats on the wire between Rbridges. It may or may not have
various optimizations. It's not an 802.1 bridge but it is a bridge
nevertheless. And once a frame is ingressed by an Rbridge and has a
TRILL Header added, every bit after the TRILL Ethertype through to just
before the FCS is completely private to TRILL capable devices and TRILL
capable software. Nothing TRILL ignorant will be able to parse past the
TRILL Ethertype. It seems only reasonable to format that information for
Rbridge convenience and efficiency.

To the extent that rbridges do this function (adding VLAN tags or
removing them), that happens to the inner header. That function has
nothing to do with rbridges per se; it doesn't belong in the rbridge
header. If rbridge functions need to refer to that tag, they know where
it would be and how to find it.

@@@ Rbridges are bridges. Your artificially carving out of the VLAN
functionality, part of the heart of how Rbridges work, and declaring it
to have nothing to do with Rbridges makes no sense at all.

@@@ The best view of VLAN ID, the multi-destination bit, frame priority,
the "egress Rbridge", ... is that these are all pieces of
meta-information that are not part of the actual data frame. They exist
even when they are never encoded into a wire format.

@@@ In the future situation we are aiming for, the normal case will be
that this meta-information will by synthesized when an Rbridge receives
a native frame. It would never be wire encoded if the frame is between
two end stations both directly connected to that Rbridge. If the frame
has to be forwarded to another Rbridge, then the meta-information does
have to be wire encoded but such inter-Rbridge frames always have a
TRILL Header which is the obvious place for all this meta-information
all of which will be of interest to the receiving RBridge.

> What happens when such a message is received by a transit Rbridge?
There
> might be an outer 802.1AE tag or the like, which is removed and
> processed at the port. There might be an outer VLAN tag which is
> logically removed on receipt so frame now logically and perhaps
> physically starts with a TRILL Ethertype. The Rbridge MUST then derive
> inner VLAN tag information to decide how to forward the frame. With
> Solution 2, it is at a fixed offset from the TRILL Ethertype and close
> to the beginning of the frame, to speed cut through switching. With
> Solution 1, the Rbridge has to skip over a variable amount of
extension
> data and extract the VLAN tag information from deeper in the frame at
a
> variable offset from the TRILL Ethertype.

This argument would imply that if the rbridge were not there that a
bridge would need to extract the VLAN tag from the inner header at a
variable offset. Since that's already done, I see no problem.

@@@ I don't understand your comment above at all. Sure, if your replace
all your Rbridges with 802.1Q bridges, then you have an 802.1Q bridge
synthesizing a more limited set of meta-information. And if you have
inter-802.1Q-bridge forwarding, then that meta-information is
wire-encoded in the 802.1Q format of a Ethertype followed by the two
bytes of Q/S-tag information. If you have Rbridges, then there is a
larger set of meta-information and if you have an inter-Rbridge
forwarding, then this larger set of meta-information is wire-encoded and
that wire-encoding is whatever we say it is. This encoding will only be
parsed by TRILL capable devices. It just makes no sense to me that, in
the Rbridge case, you want to split this meta-information into two
parts, throw away two bytes on an extra Ethertype, move the information
which corresponds to that in a Q/S tag at least 14 bytes deeper into the
frame to slow down cut through switching, and, in almost all cases,
modify the frame being encapsulated by inserting this part of the meta
information inside it.

@@@ I never claimed the current scheme won't work. I just claim that
keeping this meta information, which generally needs to be consulted by
every transit Rbridge, together in the TRILL header is more efficient
and simpler.

@@@ Thanks,
@@@ Donald

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




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 l473eTei008030 for <[e-mail]>; Sun, 6 May 2007 20:40:29 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-10.tower-153.messagelabs.com!1178509224!4114415!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 9186 invoked from network); 7 May 2007 03:40:24 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-153.messagelabs.com with SMTP; 7 May 2007 03:40:24 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l473eKrY020746 for <[e-mail]>; Sun, 6 May 2007 20:40:24 -0700 (MST)
Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l473eJ1B015363 for <[e-mail]>; Sun, 6 May 2007 22:40:19 -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 l473eJjC015360 for <[e-mail]>; Sun, 6 May 2007 22:40:19 -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: Sun, 6 May 2007 23:40:16 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Back to ND/ARP optimization
thread-index: AceOblafu+PL4g4qT3KM+9hk+Br5xAAD8QvwAGnH5SAABisDIAAGFgXw
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Silvano Gai" <[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 l473eTei008030
Cc: [e-mail]
Subject: Re: [rbridge] Back to ND/ARP optimization
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, 07 May 2007 03:40:39 -0000
Status: RO
Content-Length: 5010

Silvano,

Sorry, I still don't understand this.

What does an Rbridge do if it receives a native broadcast frame with an
unknown Ethertype (unknown in the sense that it is not in any special
table or comparison implemented in the Rbridge)? If the Rbridge isn't
the DR for the port it received it on, it drops it. If it is the DR, it
forwards it in native form out every other port for which it is the DR
and which is in the same VLAN. It also encapsulates it and sends it off
on a distribution tree pruned by VLAN.

What does an Rbridge do if it receives a native broadcast ARP frame? If
it isn't the DR for the port it receive it on, it drops it. Otherwise,
it learns the IP to MAC mapping for the sender fields in the ARP frame
and it tries to find the target IP address in its database of IP to MAP
mappings. If it can't find an entry for the target IP address, it then
proceeds as in the paragraph above to flood it.

In other words, for an unknown target IP address, processing of a
broadcast ARP frame is exactly the same as for an unknown Ethertype
except for the learning step and the table look up attempt step. Why
can't this be done in hardware? Even if I assume the learning and table
look up happen in software, if the IP address isn't found, why couldn't
the software just re-inject the frame into the hardware as if it had
come in on its original receipt port with a flag saying "treat like an
unknown Ethertype"?

Thanks,
Donald

-----Original Message-----
From: Silvano Gai [mailto:[e-mail]] 
Sent: Sunday, May 06, 2007 8:36 PM
To: Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: RE: [rbridge] Back to ND/ARP optimization


Donald,

To provide a precise answer we need to consider which of the three
schemes described in section 3.12 of 
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03
.txt
the RBridge will implement.

The draft refers generically to "Some mix of these strategies".

Lacking this information, let's assume the strategy you mention.
The flood cannot be done in HW. In fact it is mandatory to not resend
the ARP on the port it was received to avoid frame duplication.

The flood must be implemented in SW has n-1 port transmissions; where n
is the number of ports.

Therefore, the CPU of a 256 port RBridge:
- in absence of ARP/ND proxy receives 1 ARP (and the HW does the correct
replication)
- with ARP/ND proxy it receives 1 ARP (and the HW does nothing)and sends
out 255 ARP messages. Huge overhead

-- Silvano


> -----Original Message-----
> From: Eastlake III Donald-LDE008 [mailto:[e-mail]]
> Sent: Sunday, May 06, 2007 2:30 PM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: RE: [rbridge] Back to ND/ARP optimization
> 
> Silvano,
> 
> I don't understand what these Rbridge CPUs will be doing. If an
Rbridge
> receives a native ARP broadcast frame for an unknown IP address it
would
> just learn the source IP->MAC mapping and then flood the ARP
broadcast.
> 
> Donald
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Silvano Gai
> Sent: Friday, May 04, 2007 3:01 PM
> To: Arien Vijn
> Cc: [e-mail]; [e-mail]
> Subject: Re: [rbridge] Back to ND/ARP optimization
> 
> Arien
> 
> Thanks for the real world data, which proves that ARP/ND proxy must
not
> be implemented on RBridges.
> 
> In fact, since the queries toward unused addresses are dominant, the
> ARP/ND cache will almost always miss and the RBridge CPU will be busy
> trying to remotely resolve queries that will never complete.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: Arien Vijn [mailto:[e-mail]]
> > Sent: Friday, May 04, 2007 10:04 AM
> > To: Silvano Gai
> > Cc: Arien Vijn; [e-mail]; [e-mail]
> > Subject: Re: [rbridge] Back to ND/ARP optimization
> >
> > Hi,
> >
> > On May 3, 2007, at 10:55 PM, Silvano Gai wrote:
> >
> > [...]
> >
> > >> Does anyone have a handle on how much traffic is caused by
ARP/ND?
> > >>
> > >
> > > With an ARP cache of 30 minutes, typical in hosts today, even with
> > > a 100
> > > K hosts in a VLAN we get at most 55 ARP seconds. Since not all the
> > > hosts
> > > talk with each other, it is more typically like 5 ARP/sec.
> > >
> > > BASICALLY NOTHING.
> >
> > Well... that might be the case if all your hosts are actually
> > answering. But query rates are pretty much determined by queries for
> > unused addresses. In other words by the query rates hosts (routers)
> > can achieve for addresses that are not in their caches.
> >
> > For what its worth. I am involved in a real network with 400+ BGP
> > routers in one broadcast domain (/23 IPv4 subnet). The average rate
> > is little over 13 queries/second. That is with ARP mitigation and
> > peak rates are much higher.
> >
> > -- Arien
> 
> 
> _______________________________________________
> 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 l470a0wj003118 for <[e-mail]>; Sun, 6 May 2007 17:36:01 -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, 6 May 2007 17:35:37 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Back to ND/ARP optimization
Thread-Index: AceOblafu+PL4g4qT3KM+9hk+Br5xAAD8QvwAGnH5SAABisDIA==
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[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 l470a0wj003118
Cc: [e-mail]
Subject: Re: [rbridge] Back to ND/ARP optimization
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, 07 May 2007 00:36:37 -0000
Status: RO
Content-Length: 3346

Donald,

To provide a precise answer we need to consider which of the three
schemes described in section 3.12 of 
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03
.txt
the RBridge will implement.

The draft refers generically to "Some mix of these strategies".

Lacking this information, let's assume the strategy you mention.
The flood cannot be done in HW. In fact it is mandatory to not resend
the ARP on the port it was received to avoid frame duplication.

The flood must be implemented in SW has n-1 port transmissions; where n
is the number of ports.

Therefore, the CPU of a 256 port RBridge:
- in absence of ARP/ND proxy receives 1 ARP (and the HW does the correct
replication)
- with ARP/ND proxy it receives 1 ARP (and the HW does nothing)and sends
out 255 ARP messages. Huge overhead

-- Silvano


> -----Original Message-----
> From: Eastlake III Donald-LDE008 [mailto:[e-mail]]
> Sent: Sunday, May 06, 2007 2:30 PM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: RE: [rbridge] Back to ND/ARP optimization
> 
> Silvano,
> 
> I don't understand what these Rbridge CPUs will be doing. If an
Rbridge
> receives a native ARP broadcast frame for an unknown IP address it
would
> just learn the source IP->MAC mapping and then flood the ARP
broadcast.
> 
> Donald
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Silvano Gai
> Sent: Friday, May 04, 2007 3:01 PM
> To: Arien Vijn
> Cc: [e-mail]; [e-mail]
> Subject: Re: [rbridge] Back to ND/ARP optimization
> 
> Arien
> 
> Thanks for the real world data, which proves that ARP/ND proxy must
not
> be implemented on RBridges.
> 
> In fact, since the queries toward unused addresses are dominant, the
> ARP/ND cache will almost always miss and the RBridge CPU will be busy
> trying to remotely resolve queries that will never complete.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: Arien Vijn [mailto:[e-mail]]
> > Sent: Friday, May 04, 2007 10:04 AM
> > To: Silvano Gai
> > Cc: Arien Vijn; [e-mail]; [e-mail]
> > Subject: Re: [rbridge] Back to ND/ARP optimization
> >
> > Hi,
> >
> > On May 3, 2007, at 10:55 PM, Silvano Gai wrote:
> >
> > [...]
> >
> > >> Does anyone have a handle on how much traffic is caused by
ARP/ND?
> > >>
> > >
> > > With an ARP cache of 30 minutes, typical in hosts today, even with
> > > a 100
> > > K hosts in a VLAN we get at most 55 ARP seconds. Since not all the
> > > hosts
> > > talk with each other, it is more typically like 5 ARP/sec.
> > >
> > > BASICALLY NOTHING.
> >
> > Well... that might be the case if all your hosts are actually
> > answering. But query rates are pretty much determined by queries for
> > unused addresses. In other words by the query rates hosts (routers)
> > can achieve for addresses that are not in their caches.
> >
> > For what its worth. I am involved in a real network with 400+ BGP
> > routers in one broadcast domain (/23 IPv4 subnet). The average rate
> > is little over 13 queries/second. That is with ARP mitigation and
> > peak rates are much higher.
> >
> > -- Arien
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l46LYHmZ025418 for <[e-mail]>; Sun, 6 May 2007 14:34:17 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-11.tower-119.messagelabs.com!1178487254!16178338!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.9]
Received: (qmail 26920 invoked from network); 6 May 2007 21:34:15 -0000
Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-11.tower-119.messagelabs.com with SMTP; 6 May 2007 21:34:15 -0000
Received: from az33exr03.mot.com ([10.64.251.233]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l46LYEfB025477 for <[e-mail]>; Sun, 6 May 2007 16:34:14 -0500 (CDT)
Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l46LYD9u024061 for <[e-mail]>; Sun, 6 May 2007 16:34:13 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l46LUPDb023199 for <[e-mail]>; Sun, 6 May 2007 16:30: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: Sun, 6 May 2007 17:30:21 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Back to ND/ARP optimization
thread-index: AceOblafu+PL4g4qT3KM+9hk+Br5xAAD8QvwAGnH5SA=
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Silvano Gai" <[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 l46LYHmZ025418
Cc: [e-mail]
Subject: Re: [rbridge] Back to ND/ARP optimization
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, 06 May 2007 21:34:33 -0000
Status: RO
Content-Length: 2144

Silvano,

I don't understand what these Rbridge CPUs will be doing. If an Rbridge
receives a native ARP broadcast frame for an unknown IP address it would
just learn the source IP->MAC mapping and then flood the ARP broadcast.

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Silvano Gai
Sent: Friday, May 04, 2007 3:01 PM
To: Arien Vijn
Cc: [e-mail]; [e-mail]
Subject: Re: [rbridge] Back to ND/ARP optimization

Arien

Thanks for the real world data, which proves that ARP/ND proxy must not
be implemented on RBridges.

In fact, since the queries toward unused addresses are dominant, the
ARP/ND cache will almost always miss and the RBridge CPU will be busy
trying to remotely resolve queries that will never complete.

-- Silvano

> -----Original Message-----
> From: Arien Vijn [mailto:[e-mail]]
> Sent: Friday, May 04, 2007 10:04 AM
> To: Silvano Gai
> Cc: Arien Vijn; [e-mail]; [e-mail]
> Subject: Re: [rbridge] Back to ND/ARP optimization
> 
> Hi,
> 
> On May 3, 2007, at 10:55 PM, Silvano Gai wrote:
> 
> [...]
> 
> >> Does anyone have a handle on how much traffic is caused by ARP/ND?
> >>
> >
> > With an ARP cache of 30 minutes, typical in hosts today, even with
> > a 100
> > K hosts in a VLAN we get at most 55 ARP seconds. Since not all the
> > hosts
> > talk with each other, it is more typically like 5 ARP/sec.
> >
> > BASICALLY NOTHING.
> 
> Well... that might be the case if all your hosts are actually
> answering. But query rates are pretty much determined by queries for
> unused addresses. In other words by the query rates hosts (routers)
> can achieve for addresses that are not in their caches.
> 
> For what its worth. I am involved in a real network with 400+ BGP
> routers in one broadcast domain (/23 IPv4 subnet). The average rate
> is little over 13 queries/second. That is with ARP mitigation and
> peak rates are much higher.
> 
> -- Arien


_______________________________________________
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 l46GUcOp022764 for <[e-mail]>; Sun, 6 May 2007 09:30:38 -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, 6 May 2007 09:30:34 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Back to ND/ARP optimization
Thread-Index: AcePYjXzjZVJRiAXSnae+IMrXWWExQAmTy8g
References: <[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 l46GUcOp022764
Cc: [e-mail]
Subject: Re: [rbridge] Back to ND/ARP optimization
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, 06 May 2007 16:30:57 -0000
Status: RO
Content-Length: 2909

Radia,

I agree that Arien didn't make a conclusion, and I am interested in
Arien opinion.

I read about the bursts.

I suppose that even during "the high peak rate" most of the ARPs are for
unknown destinations and this does not change my conclusions.

-- Silvano



> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]]
> Sent: Saturday, May 05, 2007 3:11 PM
> To: Silvano Gai
> Cc: Arien Vijn; [e-mail]
> Subject: Re: [rbridge] Back to ND/ARP optimization
> 
> Actually, I'm not sure that's the conclusion that Arien was making
(that
> ARP/ND
> optimization is not worth it), especially with the comment "peak rates
> much higher".
> 
> So Arien...was that actually your conclusion?
> 
> I think that ARP/ND optimization could be added in the future as an
> option, or
> even that an implementation can do something about it without having
the
> spec
> saying anything about it. Which would argue for not needing it in the
> spec now.
> 
> But just want to verify what Arien's conclusion is from the data
> presented...
> 
> Radia
> 
> 
> Silvano Gai wrote:
> > Arien
> >
> > Thanks for the real world data, which proves that ARP/ND proxy must
not
> > be implemented on RBridges.
> >
> > In fact, since the queries toward unused addresses are dominant, the
> > ARP/ND cache will almost always miss and the RBridge CPU will be
busy
> > trying to remotely resolve queries that will never complete.
> >
> > -- Silvano
> >
> >
> >> -----Original Message-----
> >> From: Arien Vijn [mailto:[e-mail]]
> >> Sent: Friday, May 04, 2007 10:04 AM
> >> To: Silvano Gai
> >> Cc: Arien Vijn; [e-mail]; [e-mail]
> >> Subject: Re: [rbridge] Back to ND/ARP optimization
> >>
> >> Hi,
> >>
> >> On May 3, 2007, at 10:55 PM, Silvano Gai wrote:
> >>
> >> [...]
> >>
> >>
> >>>> Does anyone have a handle on how much traffic is caused by
ARP/ND?
> >>>>
> >>>>
> >>> With an ARP cache of 30 minutes, typical in hosts today, even with
> >>> a 100
> >>> K hosts in a VLAN we get at most 55 ARP seconds. Since not all the
> >>> hosts
> >>> talk with each other, it is more typically like 5 ARP/sec.
> >>>
> >>> BASICALLY NOTHING.
> >>>
> >> Well... that might be the case if all your hosts are actually
> >> answering. But query rates are pretty much determined by queries
for
> >> unused addresses. In other words by the query rates hosts (routers)
> >> can achieve for addresses that are not in their caches.
> >>
> >> For what its worth. I am involved in a real network with 400+ BGP
> >> routers in one broadcast domain (/23 IPv4 subnet). The average rate
> >> is little over 13 queries/second. That is with ARP mitigation and
> >> peak rates are much higher.
> >>
> >> -- Arien
> >>
> >
> >
> > _______________________________________________
> > 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 l46GQ4lt021488 for <[e-mail]>; Sun, 6 May 2007 09:26:05 -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, 6 May 2007 09:26:00 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: header rough consensus
Thread-Index: AceP+zu/8qKh4iQLSReq1YrcK3vcVQ==
From: "Silvano Gai" <[e-mail]>
To: <[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 l46GQ4lt021488
Subject: [rbridge] header rough consensus
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, 06 May 2007 16:26:24 -0000
Status: RO
Content-Length: 200

Trying to summarize the results, my understanding is:

Solution 1
- Silvano
- Dino
- Joe
- Eric

Solution 2
- Donald

Not sure about:
- Dinesh
- Radia

Am I correct?
Did I miss anybody?

-- Silvano



Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l46EDteD025382 for <[e-mail]>; Sun, 6 May 2007 07:13:55 -0700 (PDT)
Received: by py-out-1112.google.com with SMTP id a78so971452pyh for <[e-mail]>; Sun, 06 May 2007 07:13:54 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=AFurPULesWJrPQ2XycT39m+dv1bmwVhhCO6hiVlx6CJ21VmV8kUZd47/dhsQPgdp8aLoy10ST0cOpbVTr8sl0sIjs3fdNztvHFGOVWZwMNkAldtJ76b8urs+81rK8B17VVF5pEf2L4shGCsjUBxGMve6ppnYD77f+hqRHYe4ld4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=BhjxIE5Rt2N5gASDPwSkRvUmhNKLNX0je/jcFqlMtfoMQC0l0lOZo0NLsWzt8ulWEaHqz9HZSUhHdOONrN/RVZ4ed1FTAgjuX/92BAsFQBvt71UmY+oIPW+PubJY80Ccszo22MHOuQ9apPrEUKaegft/NIquGry0/xuhBqi4MJQ=
Received: by 10.35.93.1 with SMTP id v1mr9300284pyl.1178460834662; Sun, 06 May 2007 07:13:54 -0700 (PDT)
Received: by 10.35.41.10 with HTTP; Sun, 6 May 2007 07:13:54 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sun, 6 May 2007 07:13:54 -0700
From: "sachin jain" <[e-mail]>
To: "[e-mail]" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_24524_6430547.1178460834491"
References: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 06 May 2007 14:14:53 -0000
Status: RO
Content-Length: 9438

------=_Part_24524_6430547.1178460834491
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,
  I think the RPF check can have transient loops for packets in flight
during topology change. It does seem to have no loop for new packets.
Let me explain that with an example with only one distribution tree.

The topologys is as follows
  ------------------------------------
  |                                  |
R1 -------                         |
  |          |                        |
  |          R2      ------------  R3
  |            |                        |
  |            |                        |
  | ------   R4   ------------------

[Description : R1 is connected to every switch and R2, R3, R4 are connected
in a loop]

There is only one distribition tree agreed upon which is rooted at R1.

Suppose during a transient change the ISIS link state database at different
switches is such that the tree that each switch computes is as follows

R2: Tree is R1->R4->R2->R3
R3: Tree is R1->R2->R3->R4
R4: Tree is R1->R3->R4->R2

Suppose there is a packet which was originated from R1 and is in flight
between R2 and R3 just when the topology change happened. Now this packet
will loop between R2, R3, R4 because for each of them it is receiving on the
link which passes the RPF check for source R1.

Are above scenarios unlikely or acceptable?

sachin

On 5/3/07, [e-mail] <[e-mail]> wrote:
>
> Sorry Eric. There ought to be a better name for it than "the RPF thing".
> What's being talked about is what I presented at the WG, which is
> the precomputation, for each tree, for each port, the set of ingress
> RBridges
> from which it would be logical to receive packets from, on that port.
>
> To summarize "the RPF thing" (and I'd love a better name for it, but maybe
> we
> don't need to name it-- we can just put the algorithm in the spec)
>
> a) Each RBridge R1 announces, in the core instance of IS-IS, the set of
> trees R1 will ever choose as distribution trees for packets that R1
> injects. So
> say that R1 chooses {R1, R4, and R5}
>
> b) Each RBridge also announces whether it wants to be the root
> of a tree
>
> c) Each RBridge R2 calculates a tree for each of the RBridges that have
> say "yes"
> for b).
>
> d) An RBridge, say R3, calculates the tree rooted at, say, R5. Let's say
> that
> R3 determines that ports a, b, c, and f are in the R5-tree.
> Then let's say that of all the RBridges, {R6 and R7} say (in a) that they
> are going to choose the R5-tree. R3 figures out which port it should
> receive things from R6, on the R5-tree, and marks that port as
> "ingress RBridge R6 allowed". Likewise it does that for the port
> for which it should receive things from R7 on that tree.
>
> e) R3 does filtering as follows: If R3 receives a multicast packet marked
> as R5-tree (egress RBridge field =R5), with ingress RBridge Rx, on port p,
> then if the ingress RBridge is not listed among the allowed
> ingress RBridges for that port for that tree, R3 discards the packet.
>
> Note the overhead for this is that if the average number of trees each
> ingress
> RBridge says they will select is 2 (I'd think most RBridges would select
> only one
> tree -- it would be only for RBridges that want to multipath multicast
> that they'd
> select more than one tree), then there are only 2*number of RBridges TOTAL
> that will get listed as legal ingress RBridges.
>
> Radia
>
> ----- Original Message -----
> From: "Eric Gray (LO/EUS)" <[e-mail]>
>
> >
> >       First, what exactly is the "Radia RPF" proposal that you
> > mention in another thread of discussion,
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>

------=_Part_24524_6430547.1178460834491
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,<br>&nbsp; I think the RPF check can have <span style="font-weight: bold;">transient loops for packets in flight during topology change.</span> It does seem to have no loop for new packets. <br>Let me explain that with an example with only one distribution tree. 
<br><br>The topologys is as follows<br>&nbsp; ------------------------------------<br>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>R1 -------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp; | &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp; | &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R2 &nbsp;&nbsp;&nbsp;&nbsp; ------------&nbsp; R3 
<br>&nbsp; | &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp; | &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp; | ------ &nbsp; R4&nbsp;&nbsp; ------------------<br><br>[Description : R1 is connected to every switch and R2, R3, R4 are connected in a loop] 
<br><br>There is only one distribition tree agreed upon which is rooted at R1. <br><br>Suppose during a transient change the ISIS link state database at different switches is such that the tree that each switch computes is as follows
<br><br>R2: Tree is R1-&gt;R4-&gt;R2-&gt;R3<br>R3: Tree is R1-&gt;R2-&gt;R3-&gt;R4<br>R4: Tree is R1-&gt;R3-&gt;R4-&gt;R2<br><br>Suppose there is a packet which was originated from R1 and is in flight between R2 and R3 just when the topology change happened. Now this packet will loop between R2, R3, R4 because for each of them it is receiving on the link which passes the RPF check for source R1. 
<br><br>Are above scenarios unlikely or acceptable? <br><br>sachin <br><br><div><span class="gmail_quote">On 5/3/07, <b class="gmail_sendername"><a href="mailto:[e-mail]">[e-mail]</a></b> &lt;<a href="mailto:[e-mail]">
[e-mail]</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Sorry Eric. There ought to be a better name for it than &quot;the RPF thing&quot;.
<br>What&#39;s being talked about is what I presented at the WG, which is<br>the precomputation, for each tree, for each port, the set of ingress RBridges<br>from which it would be logical to receive packets from, on that port.
<br><br>To summarize &quot;the RPF thing&quot; (and I&#39;d love a better name for it, but maybe we<br>don&#39;t need to name it-- we can just put the algorithm in the spec)<br><br>a) Each RBridge R1 announces, in the core instance of IS-IS, the set of
<br>trees R1 will ever choose as distribution trees for packets that R1 injects. So<br>say that R1 chooses {R1, R4, and R5}<br><br>b) Each RBridge also announces whether it wants to be the root<br>of a tree<br><br>c) Each RBridge R2 calculates a tree for each of the RBridges that have say &quot;yes&quot;
<br>for b).<br><br>d) An RBridge, say R3, calculates the tree rooted at, say, R5. Let&#39;s say that<br>R3 determines that ports a, b, c, and f are in the R5-tree.<br>Then let&#39;s say that of all the RBridges, {R6 and R7} say (in a) that they
<br>are going to choose the R5-tree. R3 figures out which port it should<br>receive things from R6, on the R5-tree, and marks that port as<br>&quot;ingress RBridge R6 allowed&quot;. Likewise it does that for the port<br>for which it should receive things from R7 on that tree.
<br><br>e) R3 does filtering as follows: If R3 receives a multicast packet marked<br>as R5-tree (egress RBridge field =R5), with ingress RBridge Rx, on port p,<br>then if the ingress RBridge is not listed among the allowed
<br>ingress RBridges for that port for that tree, R3 discards the packet.<br><br>Note the overhead for this is that if the average number of trees each ingress<br>RBridge says they will select is 2 (I&#39;d think most RBridges would select only one
<br>tree -- it would be only for RBridges that want to multipath multicast that they&#39;d<br>select more than one tree), then there are only 2*number of RBridges TOTAL<br>that will get listed as legal ingress RBridges.<br>
<br>Radia<br><br>----- Original Message -----<br>From: &quot;Eric Gray (LO/EUS)&quot; &lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt;<br><br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; First, what exactly is the &quot;Radia RPF&quot; proposal that you
<br>&gt; mention in another thread of discussion,<br><br>_______________________________________________<br>rbridge mailing list<br><a href="mailto:[e-mail]">[e-mail]</a><br><a href="http://mailman.postel.org/mailman/listinfo/rbridge">
http://mailman.postel.org/mailman/listinfo/rbridge</a><br></blockquote></div><br>

------=_Part_24524_6430547.1178460834491--


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 l45MA7ZH006369 for <[e-mail]>; Sat, 5 May 2007 15:10:08 -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, 05 May 2007 15:10:03 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.16.161]) 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, 05 May 2007 15:10:03 -0700 (PDT)
Date: Sat, 05 May 2007 15:10:35 -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]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Back to ND/ARP optimization
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, 05 May 2007 22:10:26 -0000
Status: RO
Content-Length: 2292

Actually, I'm not sure that's the conclusion that Arien was making (that 
ARP/ND
optimization is not worth it), especially with the comment "peak rates 
much higher".

So Arien...was that actually your conclusion?

I think that ARP/ND optimization could be added in the future as an 
option, or
even that an implementation can do something about it without having the 
spec
saying anything about it. Which would argue for not needing it in the 
spec now.

But just want to verify what Arien's conclusion is from the data 
presented...

Radia


Silvano Gai wrote:
> Arien
>
> Thanks for the real world data, which proves that ARP/ND proxy must not
> be implemented on RBridges.
>
> In fact, since the queries toward unused addresses are dominant, the
> ARP/ND cache will almost always miss and the RBridge CPU will be busy
> trying to remotely resolve queries that will never complete.
>
> -- Silvano
>
>   
>> -----Original Message-----
>> From: Arien Vijn [mailto:[e-mail]]
>> Sent: Friday, May 04, 2007 10:04 AM
>> To: Silvano Gai
>> Cc: Arien Vijn; [e-mail]; [e-mail]
>> Subject: Re: [rbridge] Back to ND/ARP optimization
>>
>> Hi,
>>
>> On May 3, 2007, at 10:55 PM, Silvano Gai wrote:
>>
>> [...]
>>
>>     
>>>> Does anyone have a handle on how much traffic is caused by ARP/ND?
>>>>
>>>>         
>>> With an ARP cache of 30 minutes, typical in hosts today, even with
>>> a 100
>>> K hosts in a VLAN we get at most 55 ARP seconds. Since not all the
>>> hosts
>>> talk with each other, it is more typically like 5 ARP/sec.
>>>
>>> BASICALLY NOTHING.
>>>       
>> Well... that might be the case if all your hosts are actually
>> answering. But query rates are pretty much determined by queries for
>> unused addresses. In other words by the query rates hosts (routers)
>> can achieve for addresses that are not in their caches.
>>
>> For what its worth. I am involved in a real network with 400+ BGP
>> routers in one broadcast domain (/23 IPv4 subnet). The average rate
>> is little over 13 queries/second. That is with ARP mitigation and
>> peak rates are much higher.
>>
>> -- Arien
>>     
>
>
> _______________________________________________
> 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 l44J0jWN024958 for <[e-mail]>; Fri, 4 May 2007 12:00:45 -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, 4 May 2007 12:00:39 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Back to ND/ARP optimization
Thread-Index: AceOblafu+PL4g4qT3KM+9hk+Br5xAAD8Qvw
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Arien Vijn" <[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 l44J0jWN024958
Cc: [e-mail], [e-mail]
Subject: Re: [rbridge] Back to ND/ARP optimization
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, 04 May 2007 19:01:13 -0000
Status: RO
Content-Length: 1499

Arien

Thanks for the real world data, which proves that ARP/ND proxy must not
be implemented on RBridges.

In fact, since the queries toward unused addresses are dominant, the
ARP/ND cache will almost always miss and the RBridge CPU will be busy
trying to remotely resolve queries that will never complete.

-- Silvano

> -----Original Message-----
> From: Arien Vijn [mailto:[e-mail]]
> Sent: Friday, May 04, 2007 10:04 AM
> To: Silvano Gai
> Cc: Arien Vijn; [e-mail]; [e-mail]
> Subject: Re: [rbridge] Back to ND/ARP optimization
> 
> Hi,
> 
> On May 3, 2007, at 10:55 PM, Silvano Gai wrote:
> 
> [...]
> 
> >> Does anyone have a handle on how much traffic is caused by ARP/ND?
> >>
> >
> > With an ARP cache of 30 minutes, typical in hosts today, even with
> > a 100
> > K hosts in a VLAN we get at most 55 ARP seconds. Since not all the
> > hosts
> > talk with each other, it is more typically like 5 ARP/sec.
> >
> > BASICALLY NOTHING.
> 
> Well... that might be the case if all your hosts are actually
> answering. But query rates are pretty much determined by queries for
> unused addresses. In other words by the query rates hosts (routers)
> can achieve for addresses that are not in their caches.
> 
> For what its worth. I am involved in a real network with 400+ BGP
> routers in one broadcast domain (/23 IPv4 subnet). The average rate
> is little over 13 queries/second. That is with ARP mitigation and
> peak rates are much higher.
> 
> -- Arien




Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l44IYSAI018800 for <[e-mail]>; Fri, 4 May 2007 11:34:28 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.68.36]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l44IYPQp009257; Fri, 4 May 2007 18:34:25 GMT
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44IYLPn131314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2007 11:34:21 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 04 May 2007 11:34:21 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 2.0b2 (X11/20070326)
MIME-Version: 1.0
To: "Eric Gray (LO/EUS)" <[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]> <463AB88E.8010803@isi!.eedu> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>, Joe Touch <[e-mail]>
Subject: Re: [rbridge] Emerging consensus to use STP for non-unicast? (was -	Setting initial "hop count" value)
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, 04 May 2007 18:34:42 -0000
Status: RO
Content-Length: 1876

Eric Gray (LO/EUS) wrote:
> TRILL-ers,
> 
> There appears to be a general acceptance of the idea of having 
> bi-directional trees used for distribution of multi-destination 
> frame traffic, at this point.
> 
> This means that there is necessarily a departure from the unicast
> forwarding scheme (based on SPF using IS-IS) for non-unicast and
> unknown unicast frame forwarding.
> 
> For reasons that have been beaten to death on this list, that is
> not necessarily a BAD THING.
> 
> Given this general trend, I agree with Joe that using existing STP 
> algorithms to establish these bi-directional trees is far better
> than starting from scratch with something else - however clever
> that something else may be.
> 
> The same arguments that hold for using IS-IS (as opposed to just
> starting with IS-IS and building something new, or developing an
> entirely new SPF routing algorithm), should hold for creation of 
> bi-directional L2 distribution trees as well.

 From what I can see there is no emerging consensus to do such a radical 
change, and it seems to be a complete departure from the TRILL charter 
which starts with 'using an existing link-state routing protocol 
technology.'

While layering or reusing 802.1D might be interesting to explore, I 
suspect there are some hard design issues (whether there is a single STP 
instance across the whole network, or a separate STP instance that just 
include the RBridge overlay.)
In any case, had we proposed that as the TRILL charter when TRILL 
started I am pretty sure the IESG would have just told us to go work in 
IEEE 802.

    Erik

> Note that while STP and RSTP would create a single spanning tree
> for all RBridges in the scope of a single VLAN, MSTP may be used
> to create multiple spanning trees - thereby effectively providing
> for the "multi-pathing" of multi-destination frames.
> 
> Thanks!



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 l44HYIG7004927 for <[e-mail]>; Fri, 4 May 2007 10:34:18 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-2.tower-153.messagelabs.com!1178300057!4811638!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 11268 invoked from network); 4 May 2007 17:34:17 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-153.messagelabs.com with SMTP; 4 May 2007 17:34:17 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l44HYDNS020858 for <[e-mail]>; Fri, 4 May 2007 10:34:17 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l44HYCrZ015556 for <[e-mail]>; Fri, 4 May 2007 12:34:13 -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 l44HYCxF015546 for <[e-mail]>; Fri, 4 May 2007 12:34:12 -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, 4 May 2007 13:34:07 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Optional configuration of RBridge nickname
thread-index: AceNjy2slc+yzQ1FT7a8Uy8jG2bI2wAACwFQABkVlHAAGlAfgAAFWkww
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[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 l44HYIG7004927
Cc: [e-mail]
Subject: Re: [rbridge] Optional configuration of RBridge nickname
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, 04 May 2007 17:34:42 -0000
Status: RO
Content-Length: 668

OK,  Sorry,
Donald 

-----Original Message-----
From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
Sent: Friday, May 04, 2007 11:04 AM
To: Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: RE: [rbridge] Optional configuration of RBridge nickname

Donald,

	Not sure how, but you've missed my MAIN POINT, and
completely misunderstood everything else I said.

	I object to the use of priority, not - as you have
apparently misunderstood me to have said - to configuration
of nicknames.

	That said, I have no way to respond to your questions
as they appear to be addressing something I have not said.

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  



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 l44HXTSR004748 for <[e-mail]>; Fri, 4 May 2007 10:33:30 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-2.tower-153.messagelabs.com!1178300008!4811571!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [144.189.100.105]
Received: (qmail 10533 invoked from network); 4 May 2007 17:33:28 -0000
Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-2.tower-153.messagelabs.com with SMTP; 4 May 2007 17:33:28 -0000
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l44HXShI016147 for <[e-mail]>; Fri, 4 May 2007 10:33:28 -0700 (MST)
Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l44HXRaP027999 for <[e-mail]>; Fri, 4 May 2007 12:33:28 -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 l44HXQYc027983 for <[e-mail]>; Fri, 4 May 2007 12:33: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: Fri, 4 May 2007 13:33:24 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternativeproposals)
thread-index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAWBesAAdIqaAAAGwMUAAATFVQAAAMH6gAAAPqTAAAZl3AAACGTQgANrO6FA=
References: <[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 l44HXTSR004748
Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternativeproposals)
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, 04 May 2007 17:34:27 -0000
Status: RO
Content-Length: 10194

(I started this message a while ago but hadn't sent it...)

Three points on ARP/ND that I don't think had been mentioned, the first
two possibly in favor of optimization, the 3rd against for ND:

(1) There are networks where peripheral traffic is more expensive than
core traffic. Assume wired infrastructure between the Rbridges but radio
links, where bandwidth is expensive, between them and end stations.
Further, assuming that most of the traffic is local to the network,
perhaps voice, and stations arrive/leave at a substantial pace, such a
first responders at an emergency incident scene. Is flooding all ARPs so
they are radio broadcast really the right thing to do?

(2) An optional Rbridge extension to optimize out the inner MAC
addresses for IP traffic can be done for broadcast and IP derived
multicast without any ARP/ND information but would require such
information for the unicast case.

(3) ND is extensible and more complex than ARP so, even setting aside
secure ND, it would be more complex to proxy than ARP.

Thanks,
Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Silvano Gai
Sent: Wednesday, April 04, 2007 12:30 PM
To: J. R. Rivers; Eric Gray (LO/EUS); Caitlin Bestler; Radia Perlman;
[e-mail]
Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN"
alternativeproposals)


Let me try to summarize what I learnt from the replies to my message. 

ARP/ND optimization:
1) it is not justified by a bandwidth issue;
2) it is not justified by a latency issue;
3) may help reduce the problem with the broadcast storm, but the problem
is really IP multicast. Solution like the one proposed by Radia at the
last IETF address both IP multicast and ARP; therefore there is no need
for a special ARP/ND solution;
4) it introduces corner cases.

Why do we want to do ARP/ND optimization in the first version of TRILL?

I restate my proposal: let's drop it by the first version of TRILL and
deal with it later, in a separate document.

-- Silvano

> -----Original Message-----
> From: J. R. Rivers
> Sent: Wednesday, April 04, 2007 8:26 AM
> To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia Perlman;
> [e-mail]
> Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative
> proposals)
> 
> 
> Sorry I must have mis-stated my point.  It seems that if ARP is the
bulk
> of your multicast traffic, then optimizing it doesn't seem like much
> return-on-investment.  If other multicast comprises the bulk, then
> optimizing ARP doesn't seem to provide much return-on-investment.
> 
> JR
> 
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > Sent: Wednesday, April 04, 2007 7:38 AM
> > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia
> > Perlman; [e-mail]
> > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> > alternative proposals)
> >
> > It doesn't.  However, you mentioned IP multicast as another area of
> > concern...
> >
> > Thanks!
> >
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> >
> > > -----Original Message-----
> > > From: J. R. Rivers [mailto:[e-mail]]
> > > Sent: Wednesday, April 04, 2007 10:36 AM
> > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia
> > > Perlman; [e-mail]
> > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> > > alternative proposals)
> > > Importance: High
> > >
> > >
> > > Why does ARP/ND equate to IP multicast optimization?
> > >
> > > JR
> > >
> > >
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > Sent: Wednesday, April 04, 2007 7:34 AM
> > > > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia
> > > > Perlman; [e-mail]
> > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> > > > alternative proposals)
> > > >
> > > > JR,
> > > >
> > > > 	I agree.  However, I believe we (as a working group)
have
> > > > already
> > > > agreed that the IP multicast optimization is essential.
> > > > Also, it is my
> > > > point (and it is certainly arguable) that perhaps TRILL
> > > should not be
> > > > targeting the general applications of L2 where other forms
> > > > of L2 bcast
> > > > are likely to be a significant factor - but should instead
> > > > focus on the
> > > > applications of L2 specific to IP only (or IP dominant)
networks.
> > > >
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson
> > > >
> > > > > -----Original Message-----
> > > > > From: J. R. Rivers [mailto:[e-mail]]
> > > > > Sent: Wednesday, April 04, 2007 9:58 AM
> > > > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia
> > > > > Perlman; [e-mail]
> > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> > > > > alternative proposals)
> > > > > Importance: High
> > > > >
> > > > >
> > > > > It seems that if ARP is the bulk of your
> > > > broadcast/multicast, then you
> > > > > don't really need a very efficient broadcast/multicast
> > > > > mechanism.  Some
> > > > > networks can be characterized as you've stated;
> > however, there are
> > > > > others that use L2/IP multicast in a substantial fashion.
> > > > >
> > > > > JR
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > > Sent: Wednesday, April 04, 2007 6:14 AM
> > > > > > To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia
> > > > > > Perlman; [e-mail]
> > > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> > > > > > alternative proposals)
> > > > > >
> > > > > > Silvano,
> > > > > >
> > > > > > 	Where IP (v4 or v6) is the exclusive higher
> > > layer in a specific
> > > > > > network deployment, it is likely that ARP is one of the
> > > > most common
> > > > > > forms of broadcast traffic that may occur.  As we've
> > > > > > previously agreed
> > > > > > that broadcast traffic is of particular concern in TRILL,
the
> > > > > > potential
> > > > > > to drastically reduce (or possibly eliminate) common
> > > > > broadcast traffic
> > > > > > should be considered a worth-while objective.
> > > > > >
> > > > > > --
> > > > > > Eric Gray
> > > > > > Principal Engineer
> > > > > > Ericsson
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > > > Sent: Tuesday, April 03, 2007 7:22 PM
> > > > > > > To: Caitlin Bestler; J. R. Rivers; Eric Gray
> > (LO/EUS); Radia
> > > > > > > Perlman; [e-mail]
> > > > > > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> > > > > > > alternative proposals)
> > > > > > > Importance: High
> > > > > > >
> > > > > > >
> > > > > > > Do we have any quantitatively data about the need of
> > > > ARP/ND proxy?
> > > > > > >
> > > > > > > With an ARP cache of 30 minutes, typical in hosts
> > today, even
> > > > > > > with a 100
> > > > > > > K hosts in a VLAN we get at most 55 ARP seconds. Since not
> > > > > > > all the hosts
> > > > > > > talk with each other, it is more typically like 5 ARP/sec.
> > > > > > >
> > > > > > > The ARP/ND cache on the RBridge must be significantly
> > > > > > shorter than 30
> > > > > > > minutes to not increase the amount of obsolete
information.
> > > > > > >
> > > > > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K
hosts
> > > > > > per VLAN?
> > > > > > >
> > > > > > > Is this the big optimization for which we care to create
> > > > > > corner cases
> > > > > > > and potential incompatibilities?
> > > > > > >
> > > > > > > -- Silvano
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Caitlin Bestler [mailto:[e-mail]]
> > > > > > > > Sent: Tuesday, April 03, 2007 3:38 PM
> > > > > > > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS);
> > > > > Radia Perlman;
> > > > > > > > [e-mail]
> > > > > > > > Subject: RE: [rbridge] Two "shared VLAN"
> > > alternative proposals
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: J. R. Rivers [mailto:[e-mail]]
> > > > > > > > > Sent: Tuesday, April 03, 2007 3:31 PM
> > > > > > > > > To: Caitlin Bestler; Silvano Gai; Eric Gray
> > > (LO/EUS); Radia
> > > > > > > > > Perlman; [e-mail]
> > > > > > > > > Subject: RE: [rbridge] Two "shared VLAN"
> > > > alternative proposals
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > snip...
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > At the minimum we need to ensure that all
> > > > RBridges have the
> > > > > > > > > > information that would enable them to efficiently
and
> > > > > > > > > reliably act as
> > > > > > > > > > an ARP/ND proxy.
> > > > > > > > >
> > > > > > > > > It depends on how you define the requirements of
ARP/ND
> > > > > > > > > proxy.  I have seen this general mechanism used in
many
> > > > > > > > > contexts... only one of which is covered by an IETF
RFC
> > > > > > > > > (AFAIK).  Bridges in their basic definition don't
> > > > have ARP/ND
> > > > > > > > > proxy.  Only bridges that subsume some type of
> > IP related
> > > > > > > > > functionality contain these.
> > > > > > > > >
> > > > > > > > > If an RBridge "looks and smells" like a bridge,
> > > > then there is
> > > > > > > > > natural traffic separation between VLANs, and
> > this allows
> > > > > > > > > systems companies to view RBridges as "better
bridges".
> > > > > > > > >
> > > > > > > > > JR
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > The reason RBridges are "better bridges" is that they
> > > > > > > > deal with the issues of large subnets far better than
> > > > > > > > bridges do.
> > > > > > > >
> > > > > > > > Efficient distribution of ARP/ND information is also
> > > > > > > > an issue where a "better bridge" is needed to scale
> > > > > > > > to larger subnets efficiently.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >

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



Received: from betonmix.noc.ams-ix.net (betonmix.noc.ams-ix.net [193.194.136.135]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l44H4Kd8027166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 4 May 2007 10:04:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id DCE5F1027A9; Fri,  4 May 2007 19:04:19 +0200 (CEST)
Received: from [193.194.136.182] (hoefnix.noc.ams-ix.net [193.194.136.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id B4C561027A4; Fri,  4 May 2007 19:04:19 +0200 (CEST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Arien Vijn <[e-mail]>
Date: Fri, 4 May 2007 19:04:18 +0200
To: Silvano Gai <[e-mail]>
X-Mailer: Apple Mail (2.752.2)
X-Virus-Scanned: by amavisd-new at betonmix.noc.ams-ix.net
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: [rbridge] Back to ND/ARP optimization
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, 04 May 2007 17:04:41 -0000
Status: RO
Content-Length: 886

Hi,

On May 3, 2007, at 10:55 PM, Silvano Gai wrote:

[...]

>> Does anyone have a handle on how much traffic is caused by ARP/ND?
>>
>
> With an ARP cache of 30 minutes, typical in hosts today, even with  
> a 100
> K hosts in a VLAN we get at most 55 ARP seconds. Since not all the  
> hosts
> talk with each other, it is more typically like 5 ARP/sec.
>
> BASICALLY NOTHING.

Well... that might be the case if all your hosts are actually  
answering. But query rates are pretty much determined by queries for  
unused addresses. In other words by the query rates hosts (routers)  
can achieve for addresses that are not in their caches.

For what its worth. I am involved in a real network with 400+ BGP  
routers in one broadcast domain (/23 IPv4 subnet). The average rate  
is little over 13 queries/second. That is with ARP mitigation and  
peak rates are much higher.

-- Arien



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 l44GAsxQ010277 for <[e-mail]>; Fri, 4 May 2007 09:10:54 -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, 4 May 2007 09:10:51 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Emerging consensus to use STP for non-unicast? (was - Setting initial "hop count" value)
Thread-Index: AceOBgWw+zV6e7s0REuZR9X02KWsOwAUwOWAAANLCdA=
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]> <463AB88E.8010803@isi! .edu> < [e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[e-mail]>, "Joe Touch" <[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 l44GAsxQ010277
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Emerging consensus to use STP for non-unicast? (was - Setting initial "hop count" value)
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, 04 May 2007 16:11:08 -0000
Status: RO
Content-Length: 3569

Eric,

This is a departure of the current consensus as CLEARLY described in:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03
.txt

3.4.1. Distribution Tree Calculation 

   RBridges do not use the spanning tree protocol to calculate 
   distribution trees. Instead, distribution trees are calculated based 
   on the link state information, selecting a particular RBridge as the 
   root.  

I oppose using the Spanning Tree Protocol. 
With your proposal RBridge users will have to understand and manage
IS-IS and the Spanning Tree Protocol.

-- Silvano



> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> Sent: Friday, May 04, 2007 8:00 AM
> To: Joe Touch; Silvano Gai
> Cc: Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Emerging consensus to use STP for non-unicast?
(was
> - Setting initial "hop count" value)
> 
> TRILL-ers,
> 
> There appears to be a general acceptance of the idea of having
> bi-directional trees used for distribution of multi-destination
> frame traffic, at this point.
> 
> This means that there is necessarily a departure from the unicast
> forwarding scheme (based on SPF using IS-IS) for non-unicast and
> unknown unicast frame forwarding.
> 
> For reasons that have been beaten to death on this list, that is
> not necessarily a BAD THING.
> 
> Given this general trend, I agree with Joe that using existing STP
> algorithms to establish these bi-directional trees is far better
> than starting from scratch with something else - however clever
> that something else may be.
> 
> The same arguments that hold for using IS-IS (as opposed to just
> starting with IS-IS and building something new, or developing an
> entirely new SPF routing algorithm), should hold for creation of
> bi-directional L2 distribution trees as well.
> 
> Note that while STP and RSTP would create a single spanning tree
> for all RBridges in the scope of a single VLAN, MSTP may be used
> to create multiple spanning trees - thereby effectively providing
> for the "multi-pathing" of multi-destination frames.
> 
> Thanks!
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Joe Touch [mailto:[e-mail]]
> > Sent: Friday, May 04, 2007 12:38 AM
> > To: Silvano Gai
> > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > Subject: Re: [rbridge] Setting initial "hop count" value
> >
> > * PGP Signed: 05/04/2007 at 06:37:34 AM
> >
> >
> > Silvano Gai wrote:
> > > Joe
> > ...
> > > My message had ten points. You summarized in two, for example, you
> > > complete missed that multicast traffic can be filtered
> > while broadcast
> > > traffic must be received.
> >
> > That's an endpoint issue, not an L2 forwarding issue.
> >
> > >> Otherwise, you didn't explain why we can't just use what
> > already works
> > >> in the Internet.
> > >
> > > I am getting tired of this argument, write a concrete
> > proposal, don't
> > > just say "use what already works in the Internet."
> >
> > I did - I proposed existing ST for multicast/broadcast only. You
> > continue to want to propose something new.
> >
> > > If the Internet has already solved all the issues, why do
> > we need TRILL?
> >
> > I already answered that as well. Let me be more clear:
> >
> > "We do NOT need TRILL to fix anything in either broadcast or
> > multicast".
> >
> > Joe
> >
> > --
> > ----------------------------------------
> > Joe Touch
> > Sr. Network Engineer, USAF TSAT Space Segment
> >
> > * Joe Touch <[e-mail]>
> > * 0x89A766BB
> >
> >



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l44F49wk022464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 4 May 2007 08:04:09 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l44F4nQ7008541; Fri, 4 May 2007 10:05:07 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 4 May 2007 10:03:55 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 4 May 2007 10:03:54 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Optional configuration of RBridge nickname
Thread-Index: AceNjy2slc+yzQ1FT7a8Uy8jG2bI2wAACwFQABkVlHAAGlAfgA==
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 04 May 2007 15:03:55.0551 (UTC) FILETIME=[6F6792F0:01C78E5D]
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 l44F49wk022464
Cc: [e-mail]
Subject: Re: [rbridge] Optional configuration of RBridge nickname
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, 04 May 2007 15:04:35 -0000
Status: RO
Content-Length: 15598

Donald,

	Not sure how, but you've missed my MAIN POINT, and
completely misunderstood everything else I said.

	I object to the use of priority, not - as you have
apparently misunderstood me to have said - to configuration
of nicknames.

	That said, I have no way to respond to your questions
as they appear to be addressing something I have not said.

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Friday, May 04, 2007 10:34 AM
> To: Eric Gray (LO/EUS)
> Cc: [e-mail]
> Subject: RE: [rbridge] Optional configuration of RBridge nickname
> Importance: High
> 
> Hi Eric,
> 
> There are some things you seem to say that I don't understand.
> 
> (1) You seem to say that the nickname configuration feature, as
> originally described, makes it much easier to attack the network by
> causing what might be called "nickname churn". But it seems to me as
> easy with the pure negotiation model for someone who was going to do
> that to just hack an RBridge to assert the highest possible 
> priority ID
> and to repeated asset nicknames which other, lower priority Rbridges,
> have so as to force them to change. So how does the nickname
> configuration feature make such disruption that much easier?
> 
> (2) You seem to say that the nickname feature is very complex. But I
> just don't see that. With the existing negotiation, you are 
> doing a six
> byte unsigned integer compare to get relative priority. With the
> nickname configuration feature you are doing a seven byte unsigned
> integer compare and adding something like a couple of MIB 
> variables into
> the Rbridge MIB you already have to have. How is that so complex? 
> 
> (3) On the tied conflict issue, you seem to say that adding 
> the nickname
> configuration feature somehow changes things. But as far as I see
> whether you have all configured names or all negotiated names or a
> mixture you can always end up with some sort of tie as long 
> as you have
> a malicious RBridge. How is a tie for highest priority between two
> configured nodes which claim to have the same nickname, same 
> configured
> priority and ID any different from a tie between two negotiating nodes
> which claim to have the same nickname and same ID/priority?
> 
> Donald
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Thursday, May 03, 2007 10:37 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [rbridge] Optional configuration of RBridge nickname
> 
> Radia,
> 
> 	You're implying what is essentially "new information" to
> me.  Are you suggesting that different portions of the same L2
> domain may be under separate administrative management domains?
> 
> 	That seems a little strange for a network in which at
> least one of the administrators is concerned about dynamic 
> behavior in the network.
> 
> 	If so, then how do we address the issue with contention
> if more than one administrator wants to use a specific nickname
> and so more than one sets the priority to the highest possible
> value for the same configured nickname?
> 
> 	Also, how do you propose to address the general problem
> where two devices are configured with the same nickname but at
> different priorities?  Does the one with the lower priority
> fall back to negotiation?  If so, what effect does this have 
> on network stability if the device with the higher priority 
> starts to behave erratically?
> 
> 	We need to consider potential _additional_ complexity
> that might arise in _normal_ operation before we deliberately 
> set out to get fancy.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] 
> > Sent: Thursday, May 03, 2007 10:27 AM
> > To: Eric Gray (LO/EUS)
> > Cc: Silvano Gai; [e-mail]
> > Subject: Re: [rbridge] Optional configuration of RBridge nickname
> > Importance: High
> > 
> > I think it is perfectly reasonable to have some RBridges 
> > configured with nicknames, and others not.
> > For example, some RBridges might be hosting more critical 
> > parts of the network. Or just that people in
> > charge of different parts of the net might have more energy 
> > for configuring nicknames.
> > 
> > I can also imagine people wanting priority for nickname.
> > 
> > Radia
> > 
> > ----- Original Message -----
> > From: "Eric Gray (LO/EUS)" <[e-mail]>
> > Date: Thursday, May 3, 2007 6:24 am
> > Subject: Re: [rbridge] Optional configuration of RBridge nickname
> > 
> > > Silvano,
> > > 
> > > 	I believe that it is easily arguable that having a network
> > > in which some devices are configured not to negotiate, while the
> > > rest are not so configured (and default to negotiation) MUST be 
> > > considered a configuration error.  In many ways, this SHOULD be 
> > > considered the same sort of error as might occur if two devices 
> > > were configured with the same value.
> > > 
> > > 	One mitigating factor for this particular configuration 
> > > error is that one very likely way in which it would occur - i.e.
> > > - as a result of powering up an unconfigured device, is a "safe"
> > > operation if the (default) negotiation scheme favors the "status
> > > quo" assignment (as I believe we all have agreed it MUST).
> > > 
> > > 	Another likely pair of scenarios are as follows:
> > > 
> > > A) one in which a new device is added to an existing deployment 
> > >   where the existing devices are using negotiation and the new 
> > >   device is configured with a value that just happens to be the
> > >   same as one that an existing device has negotiated 
> > > 
> > >   - is clearly analogous to -
> > > 
> > > B) one in which a new device is added to an existing deployment
> > >   where the existing devices are configured with values (and
> > >   not using negotiation) and the new device is configured with
> > >   the same value as one that has previously been configured 
> > >   for an existing device.
> > > 
> > > 	I am reasonably confident that these SHOULD be viewed as
> > > simple configuration errors in both cases.
> > > 
> > > 	I suggest that it follows from this line of reasoning that
> > > it MUST always be possible to create a conflict situation as a 
> > > result of configuration errors.  Hence it should also follow that
> > > a simpler approach is more desirable than a more complicated one.
> > > 
> > > 	As the saying goes, let's apply the KISS principle and do
> > > what makes the most direct sense in terms of the goal we want to
> > > achieve.
> > > 
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson  
> > > 
> > > > -----Original Message-----
> > > > From: Silvano Gai [[e-mail]] 
> > > > Sent: Wednesday, May 02, 2007 7:50 PM
> > > > To: Eric Gray (LO/EUS); Radia Perlman
> > > > Cc: [e-mail]
> > > > Subject: RE: [rbridge] Optional configuration of 
> RBridge nickname
> > > > Importance: High
> > > > 
> > > > 
> > > > Eric, 
> > > > 
> > > > I think you are reading it correctly and having an 
> > implementation to
> > > > support a way to shut nickname-negotiation off is what we need.
> > > > 
> > > > The problem is that after I have manually configured a nickname 
> > > on an
> > > > RBridge I need to be sure that no other RBridge in the network 
> > > selects> it.
> > > > 
> > > > I also need to take into account that due to a mistake I can 
> > > manually> config the same nickname on two RBridges.
> > > > 
> > > > One thing after the other we ended up with Radia 
> proposal, but if 
> > > you> have a better one, we are happy to listen.
> > > > 
> > > > Cheers
> > > > 
> > > > -- Silvano
> > > > 
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Eric Gray (LO/EUS) [[e-mail]]
> > > > > Sent: Wednesday, May 02, 2007 10:17 AM
> > > > > To: Silvano Gai; Radia Perlman
> > > > > Cc: [e-mail]
> > > > > Subject: RE: [rbridge] Optional configuration of 
> > RBridge nickname
> > > > > 
> > > > > Silvano,
> > > > > 
> > > > > 	Perhaps I am reading your requirement incorrectly,
> > > > > but it sounds to me that it could be as easily addressed
> > > > > by requiring that implementations support a way to shut
> > > > > nickname-negotiation off.
> > > > > 
> > > > > 	Consider simply having a pair of management objects
> > > > > - one to disable auto-nickname negotiation, and another
> > > > > (which must be assigned a value if the first is disabled)
> > > > > that contains the configured nickname.
> > > > > 
> > > > > 	In my opinion, that would be a much more acceptable
> > > > > approach - especially in comparison with using priority
> > > > > as a mechanism for varying the outcome of auto-negotiation
> > > > > without actually turning it off.
> > > > > 
> > > > > --
> > > > > Eric Gray
> > > > > Principal Engineer
> > > > > Ericsson
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Silvano Gai [[e-mail]]
> > > > > > Sent: Wednesday, May 02, 2007 12:06 PM
> > > > > > To: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > > > Subject: RE: [rbridge] Optional configuration of RBridge 
> > > nickname> > > Importance: High
> > > > > >
> > > > > >
> > > > > > Eric,
> > > > > >
> > > > > > There is a strong requirement in Enterprise to disable any 
> > > form of
> > > > > > autoconfiguration. I requested Radia to support a way to 
> > > manually> > > configure Nicknames. I am not asking this being the 
> > > default,> > > but it must
> > > > > > be supported.
> > > > > >
> > > > > > The solution that Radia has put together is satisfactory 
> > > > for me. If
> > > > I
> > > > > > want to manually configure a nickname I will do it 
> and set the
> > > > highest
> > > > > > priority.
> > > > > >
> > > > > > Lacking a secure authentication scheme the network can be 
> > > attacked> by
> > > > > > any PC in a much easier way.
> > > > > >
> > > > > > --Silvano
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [e-mail]
> > > > [[e-mail]]
> > > > > > On
> > > > > > > Behalf Of Eric Gray (LO/EUS)
> > > > > > > Sent: Wednesday, May 02, 2007 3:31 AM
> > > > > > > To: Radia Perlman; [e-mail]
> > > > > > > Subject: Re: [rbridge] Optional configuration of 
> > > > RBridge nickname
> > > > > > >
> > > > > > > Radia,
> > > > > > >
> > > > > > > 	I would object strenuously to the use of a priority
> > > > > > > value in resolving the "ownership" of a nickname.
> > > > > > >
> > > > > > > 	The over-riding priority has to be determined in a
> > > > > > > way that ensures the existing network continues to work
> > > > > > > if a new device is inserted (i.e. - it would be best if
> > > > > > > any device were going to fail, it should be the one that
> > > > > > > has just been added).
> > > > > > >
> > > > > > > 	Adding "priority" would allow any device to assert
> > > > > > > a high priority ownership of any nickname currently in
> > > > > > > use, which would then make it trivially easy to stage a
> > > > > > > network disabling attack.
> > > > > > >
> > > > > > > 	Having it be so easy to attack the network, would
> > > > > > > necessitate mandatory defenses, almost certainly meaning
> > > > > > > that configuration would be required - possibly excepting
> > > > > > > the option of having the very highest priority value be
> > > > > > > the default assumed when no configuration is done at any
> > > > > > > RBridge.
> > > > > > >
> > > > > > > 	In either case (configuration absolutely required,
> > > > > > > or default highest priority with no configuration) would
> > > > > > > defeat your purpose.
> > > > > > >
> > > > > > > --
> > > > > > > Eric Gray
> > > > > > > Principal Engineer
> > > > > > > Ericsson
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: [e-mail]
> > > > > > > > [[e-mail]] On Behalf Of Radia Perlman
> > > > > > > > Sent: Wednesday, May 02, 2007 12:26 AM
> > > > > > > > To: [e-mail]
> > > > > > > > Subject: [rbridge] Optional configuration of RBridge 
> > > nickname> > > > >
> > > > > > > > Someone suggested that it would be useful to allow
> > > > > > configuration of
> > > > > > > > nicknames, so
> > > > > > > > that nicknames can be more stable, and there would be no
> > > > > > worry of an
> > > > > > > > RBridge coming
> > > > > > > > up and usurping a nickname from someone else. I'd like:
> > > > > > > > a) for it to remain possible to be zero 
> configuration (as 
> > > in,> not
> > > > > > > > necessary to configure
> > > > > > > > a nickname
> > > > > > > > b) allow a mixture of configured and unconfigured 
> > nicknames
> > > > > > > > c) work even with misconfiguration (configuring 
> > two RBridges
> > > > with
> > > > > > the
> > > > > > > > same nickname)
> > > > > > > > d) never allow an unconfigured nickname to accidentally 
> > > usurp> > > > > a nickname
> > > > > > > > from
> > > > > > > > a ocnfigured RBridge
> > > > > > > >
> > > > > > > > So I'm proposing the following:
> > > > > > > >
> > > > > > > > a) allow configuration of a nickname value
> > > > > > > > b) have a "priority" value for owning a nickname
> > > > > > > > that can also be configured, which I'd propose would 
> > > > be an 8-bit
> > > > > > byte,
> > > > > > > > where only the bottom 7 bits can be configured
> > > > > > > > c) the 8th bit of the priority byte (the most 
> significant
> > > > > > > > bit) indicates
> > > > > > > > whether
> > > > > > > > the nickname was configured or not
> > > > > > > > d) the default is priority=0 for RBridges that 
> > have not been
> > > > > > > > configured with
> > > > > > > > a nickname value, and priority=128 (top bit 1, rest 0) 
> > > for an
> > > > > > > > RBridge that
> > > > > > > > has been configured with a nickname
> > > > > > > > e) other values of nickname priority might be 
> useful. For
> > > > > > > > instance, an
> > > > > > > > RBridge
> > > > > > > > implementation might increment the nickname value 
> > after it's
> > > > held
> > > > > > the
> > > > > > > > nickname
> > > > > > > > for some amount of time (say 10 minutes). Or 
> someone might
> > > > > > > > want to configure
> > > > > > > > some RBridges to have a more stable nickname (by giving
> > > > > > them higher
> > > > > > > > priority).
> > > > > > > > f) Basically, the (nickname priority | system ID) is 
> > > > like the DR
> > > > > > > > priority in IS-IS,
> > > > > > > > where the DR election is based on (priority | system ID)
> > > > > > > >
> > > > > > > > Anyone object to this?
> > > > > > > >
> > > > > > > > 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 imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l44Exnf4021763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 4 May 2007 07:59:49 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l44ExEol015346; Fri, 4 May 2007 09:59:14 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 4 May 2007 09:59:47 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 4 May 2007 09:59:46 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Emerging consensus to use STP for non-unicast? (was - Setting initial "hop count" value)
Thread-Index: AceOBgWw+zV6e7s0REuZR9X02KWsOwAUwOWA
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]> <463AB88E.8010803@isi! .edu>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Joe Touch" <[e-mail]>, "Silvano Gai" <[e-mail]>
X-OriginalArrivalTime: 04 May 2007 14:59:47.0493 (UTC) FILETIME=[DB8CED50:01C78E5C]
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 l44Exnf4021763
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Emerging consensus to use STP for non-unicast? (was - Setting initial "hop count" value)
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, 04 May 2007 15:00:03 -0000
Status: RO
Content-Length: 2532

TRILL-ers,

There appears to be a general acceptance of the idea of having 
bi-directional trees used for distribution of multi-destination 
frame traffic, at this point.

This means that there is necessarily a departure from the unicast
forwarding scheme (based on SPF using IS-IS) for non-unicast and
unknown unicast frame forwarding.

For reasons that have been beaten to death on this list, that is
not necessarily a BAD THING.

Given this general trend, I agree with Joe that using existing STP 
algorithms to establish these bi-directional trees is far better
than starting from scratch with something else - however clever
that something else may be.

The same arguments that hold for using IS-IS (as opposed to just
starting with IS-IS and building something new, or developing an
entirely new SPF routing algorithm), should hold for creation of 
bi-directional L2 distribution trees as well.

Note that while STP and RSTP would create a single spanning tree
for all RBridges in the scope of a single VLAN, MSTP may be used
to create multiple spanning trees - thereby effectively providing
for the "multi-pathing" of multi-destination frames.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Friday, May 04, 2007 12:38 AM
> To: Silvano Gai
> Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> Subject: Re: [rbridge] Setting initial "hop count" value
> 
> * PGP Signed: 05/04/2007 at 06:37:34 AM
> 
> 
> Silvano Gai wrote:
> > Joe
> ...
> > My message had ten points. You summarized in two, for example, you
> > complete missed that multicast traffic can be filtered 
> while broadcast
> > traffic must be received. 
> 
> That's an endpoint issue, not an L2 forwarding issue.
> 
> >> Otherwise, you didn't explain why we can't just use what 
> already works
> >> in the Internet.
> > 
> > I am getting tired of this argument, write a concrete 
> proposal, don't
> > just say "use what already works in the Internet."
> 
> I did - I proposed existing ST for multicast/broadcast only. You
> continue to want to propose something new.
> 
> > If the Internet has already solved all the issues, why do 
> we need TRILL?
> 
> I already answered that as well. Let me be more clear:
> 
> "We do NOT need TRILL to fix anything in either broadcast or 
> multicast".
> 
> Joe
> 
> -- 
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment
> 
> * Joe Touch <[e-mail]>
> * 0x89A766BB
> 
> 



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 l44EYY81014687 for <[e-mail]>; Fri, 4 May 2007 07:34:34 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-13.tower-153.messagelabs.com!1178289263!9081242!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [144.189.100.102]
Received: (qmail 30864 invoked from network); 4 May 2007 14:34:23 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-13.tower-153.messagelabs.com with SMTP; 4 May 2007 14:34:23 -0000
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l44EYNZa022808 for <[e-mail]>; Fri, 4 May 2007 07:34:23 -0700 (MST)
Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l44EYM7t007885 for <[e-mail]>; Fri, 4 May 2007 09:34:23 -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 l44EYLVe007867 for <[e-mail]>; Fri, 4 May 2007 09:34:22 -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, 4 May 2007 10:34:19 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Optional configuration of RBridge nickname
thread-index: AceNjy2slc+yzQ1FT7a8Uy8jG2bI2wAACwFQABkVlHA=
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[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 l44EYY81014687
Cc: [e-mail]
Subject: Re: [rbridge] Optional configuration of RBridge nickname
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, 04 May 2007 14:35:07 -0000
Status: RO
Content-Length: 14124

Hi Eric,

There are some things you seem to say that I don't understand.

(1) You seem to say that the nickname configuration feature, as
originally described, makes it much easier to attack the network by
causing what might be called "nickname churn". But it seems to me as
easy with the pure negotiation model for someone who was going to do
that to just hack an RBridge to assert the highest possible priority ID
and to repeated asset nicknames which other, lower priority Rbridges,
have so as to force them to change. So how does the nickname
configuration feature make such disruption that much easier?

(2) You seem to say that the nickname feature is very complex. But I
just don't see that. With the existing negotiation, you are doing a six
byte unsigned integer compare to get relative priority. With the
nickname configuration feature you are doing a seven byte unsigned
integer compare and adding something like a couple of MIB variables into
the Rbridge MIB you already have to have. How is that so complex? 

(3) On the tied conflict issue, you seem to say that adding the nickname
configuration feature somehow changes things. But as far as I see
whether you have all configured names or all negotiated names or a
mixture you can always end up with some sort of tie as long as you have
a malicious RBridge. How is a tie for highest priority between two
configured nodes which claim to have the same nickname, same configured
priority and ID any different from a tie between two negotiating nodes
which claim to have the same nickname and same ID/priority?

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Eric Gray (LO/EUS)
Sent: Thursday, May 03, 2007 10:37 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Optional configuration of RBridge nickname

Radia,

	You're implying what is essentially "new information" to
me.  Are you suggesting that different portions of the same L2
domain may be under separate administrative management domains?

	That seems a little strange for a network in which at
least one of the administrators is concerned about dynamic 
behavior in the network.

	If so, then how do we address the issue with contention
if more than one administrator wants to use a specific nickname
and so more than one sets the priority to the highest possible
value for the same configured nickname?

	Also, how do you propose to address the general problem
where two devices are configured with the same nickname but at
different priorities?  Does the one with the lower priority
fall back to negotiation?  If so, what effect does this have 
on network stability if the device with the higher priority 
starts to behave erratically?

	We need to consider potential _additional_ complexity
that might arise in _normal_ operation before we deliberately 
set out to get fancy.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Thursday, May 03, 2007 10:27 AM
> To: Eric Gray (LO/EUS)
> Cc: Silvano Gai; [e-mail]
> Subject: Re: [rbridge] Optional configuration of RBridge nickname
> Importance: High
> 
> I think it is perfectly reasonable to have some RBridges 
> configured with nicknames, and others not.
> For example, some RBridges might be hosting more critical 
> parts of the network. Or just that people in
> charge of different parts of the net might have more energy 
> for configuring nicknames.
> 
> I can also imagine people wanting priority for nickname.
> 
> Radia
> 
> ----- Original Message -----
> From: "Eric Gray (LO/EUS)" <[e-mail]>
> Date: Thursday, May 3, 2007 6:24 am
> Subject: Re: [rbridge] Optional configuration of RBridge nickname
> 
> > Silvano,
> > 
> > 	I believe that it is easily arguable that having a network
> > in which some devices are configured not to negotiate, while the
> > rest are not so configured (and default to negotiation) MUST be 
> > considered a configuration error.  In many ways, this SHOULD be 
> > considered the same sort of error as might occur if two devices 
> > were configured with the same value.
> > 
> > 	One mitigating factor for this particular configuration 
> > error is that one very likely way in which it would occur - i.e.
> > - as a result of powering up an unconfigured device, is a "safe"
> > operation if the (default) negotiation scheme favors the "status
> > quo" assignment (as I believe we all have agreed it MUST).
> > 
> > 	Another likely pair of scenarios are as follows:
> > 
> > A) one in which a new device is added to an existing deployment 
> >   where the existing devices are using negotiation and the new 
> >   device is configured with a value that just happens to be the
> >   same as one that an existing device has negotiated 
> > 
> >   - is clearly analogous to -
> > 
> > B) one in which a new device is added to an existing deployment
> >   where the existing devices are configured with values (and
> >   not using negotiation) and the new device is configured with
> >   the same value as one that has previously been configured 
> >   for an existing device.
> > 
> > 	I am reasonably confident that these SHOULD be viewed as
> > simple configuration errors in both cases.
> > 
> > 	I suggest that it follows from this line of reasoning that
> > it MUST always be possible to create a conflict situation as a 
> > result of configuration errors.  Hence it should also follow that
> > a simpler approach is more desirable than a more complicated one.
> > 
> > 	As the saying goes, let's apply the KISS principle and do
> > what makes the most direct sense in terms of the goal we want to
> > achieve.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson  
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [[e-mail]] 
> > > Sent: Wednesday, May 02, 2007 7:50 PM
> > > To: Eric Gray (LO/EUS); Radia Perlman
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] Optional configuration of RBridge nickname
> > > Importance: High
> > > 
> > > 
> > > Eric, 
> > > 
> > > I think you are reading it correctly and having an 
> implementation to
> > > support a way to shut nickname-negotiation off is what we need.
> > > 
> > > The problem is that after I have manually configured a nickname 
> > on an
> > > RBridge I need to be sure that no other RBridge in the network 
> > selects> it.
> > > 
> > > I also need to take into account that due to a mistake I can 
> > manually> config the same nickname on two RBridges.
> > > 
> > > One thing after the other we ended up with Radia proposal, but if 
> > you> have a better one, we are happy to listen.
> > > 
> > > Cheers
> > > 
> > > -- Silvano
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [[e-mail]]
> > > > Sent: Wednesday, May 02, 2007 10:17 AM
> > > > To: Silvano Gai; Radia Perlman
> > > > Cc: [e-mail]
> > > > Subject: RE: [rbridge] Optional configuration of 
> RBridge nickname
> > > > 
> > > > Silvano,
> > > > 
> > > > 	Perhaps I am reading your requirement incorrectly,
> > > > but it sounds to me that it could be as easily addressed
> > > > by requiring that implementations support a way to shut
> > > > nickname-negotiation off.
> > > > 
> > > > 	Consider simply having a pair of management objects
> > > > - one to disable auto-nickname negotiation, and another
> > > > (which must be assigned a value if the first is disabled)
> > > > that contains the configured nickname.
> > > > 
> > > > 	In my opinion, that would be a much more acceptable
> > > > approach - especially in comparison with using priority
> > > > as a mechanism for varying the outcome of auto-negotiation
> > > > without actually turning it off.
> > > > 
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson
> > > > 
> > > > > -----Original Message-----
> > > > > From: Silvano Gai [[e-mail]]
> > > > > Sent: Wednesday, May 02, 2007 12:06 PM
> > > > > To: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > > Subject: RE: [rbridge] Optional configuration of RBridge 
> > nickname> > > Importance: High
> > > > >
> > > > >
> > > > > Eric,
> > > > >
> > > > > There is a strong requirement in Enterprise to disable any 
> > form of
> > > > > autoconfiguration. I requested Radia to support a way to 
> > manually> > > configure Nicknames. I am not asking this being the 
> > default,> > > but it must
> > > > > be supported.
> > > > >
> > > > > The solution that Radia has put together is satisfactory 
> > > for me. If
> > > I
> > > > > want to manually configure a nickname I will do it and set the
> > > highest
> > > > > priority.
> > > > >
> > > > > Lacking a secure authentication scheme the network can be 
> > attacked> by
> > > > > any PC in a much easier way.
> > > > >
> > > > > --Silvano
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail]
> > > [[e-mail]]
> > > > > On
> > > > > > Behalf Of Eric Gray (LO/EUS)
> > > > > > Sent: Wednesday, May 02, 2007 3:31 AM
> > > > > > To: Radia Perlman; [e-mail]
> > > > > > Subject: Re: [rbridge] Optional configuration of 
> > > RBridge nickname
> > > > > >
> > > > > > Radia,
> > > > > >
> > > > > > 	I would object strenuously to the use of a priority
> > > > > > value in resolving the "ownership" of a nickname.
> > > > > >
> > > > > > 	The over-riding priority has to be determined in a
> > > > > > way that ensures the existing network continues to work
> > > > > > if a new device is inserted (i.e. - it would be best if
> > > > > > any device were going to fail, it should be the one that
> > > > > > has just been added).
> > > > > >
> > > > > > 	Adding "priority" would allow any device to assert
> > > > > > a high priority ownership of any nickname currently in
> > > > > > use, which would then make it trivially easy to stage a
> > > > > > network disabling attack.
> > > > > >
> > > > > > 	Having it be so easy to attack the network, would
> > > > > > necessitate mandatory defenses, almost certainly meaning
> > > > > > that configuration would be required - possibly excepting
> > > > > > the option of having the very highest priority value be
> > > > > > the default assumed when no configuration is done at any
> > > > > > RBridge.
> > > > > >
> > > > > > 	In either case (configuration absolutely required,
> > > > > > or default highest priority with no configuration) would
> > > > > > defeat your purpose.
> > > > > >
> > > > > > --
> > > > > > Eric Gray
> > > > > > Principal Engineer
> > > > > > Ericsson
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [e-mail]
> > > > > > > [[e-mail]] On Behalf Of Radia Perlman
> > > > > > > Sent: Wednesday, May 02, 2007 12:26 AM
> > > > > > > To: [e-mail]
> > > > > > > Subject: [rbridge] Optional configuration of RBridge 
> > nickname> > > > >
> > > > > > > Someone suggested that it would be useful to allow
> > > > > configuration of
> > > > > > > nicknames, so
> > > > > > > that nicknames can be more stable, and there would be no
> > > > > worry of an
> > > > > > > RBridge coming
> > > > > > > up and usurping a nickname from someone else. I'd like:
> > > > > > > a) for it to remain possible to be zero configuration (as 
> > in,> not
> > > > > > > necessary to configure
> > > > > > > a nickname
> > > > > > > b) allow a mixture of configured and unconfigured 
> nicknames
> > > > > > > c) work even with misconfiguration (configuring 
> two RBridges
> > > with
> > > > > the
> > > > > > > same nickname)
> > > > > > > d) never allow an unconfigured nickname to accidentally 
> > usurp> > > > > a nickname
> > > > > > > from
> > > > > > > a ocnfigured RBridge
> > > > > > >
> > > > > > > So I'm proposing the following:
> > > > > > >
> > > > > > > a) allow configuration of a nickname value
> > > > > > > b) have a "priority" value for owning a nickname
> > > > > > > that can also be configured, which I'd propose would 
> > > be an 8-bit
> > > > > byte,
> > > > > > > where only the bottom 7 bits can be configured
> > > > > > > c) the 8th bit of the priority byte (the most significant
> > > > > > > bit) indicates
> > > > > > > whether
> > > > > > > the nickname was configured or not
> > > > > > > d) the default is priority=0 for RBridges that 
> have not been
> > > > > > > configured with
> > > > > > > a nickname value, and priority=128 (top bit 1, rest 0) 
> > for an
> > > > > > > RBridge that
> > > > > > > has been configured with a nickname
> > > > > > > e) other values of nickname priority might be useful. For
> > > > > > > instance, an
> > > > > > > RBridge
> > > > > > > implementation might increment the nickname value 
> after it's
> > > held
> > > > > the
> > > > > > > nickname
> > > > > > > for some amount of time (say 10 minutes). Or someone might
> > > > > > > want to configure
> > > > > > > some RBridges to have a more stable nickname (by giving
> > > > > them higher
> > > > > > > priority).
> > > > > > > f) Basically, the (nickname priority | system ID) is 
> > > like the DR
> > > > > > > priority in IS-IS,
> > > > > > > where the DR election is based on (priority | system ID)
> > > > > > >
> > > > > > > Anyone object to this?
> > > > > > >
> > > > > > > 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 vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l444c47U011916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 21:38:04 -0700 (PDT)
Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net [71.106.84.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l444bpKX018317; Thu, 3 May 2007 21:37:52 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 03 May 2007 21:37:34 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Silvano Gai <[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]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB524203DE65F468EF18440A2"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 04 May 2007 04:38:22 -0000
Status: RO
Content-Length: 1616

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB524203DE65F468EF18440A2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Silvano Gai wrote:
> Joe
=2E..
> My message had ten points. You summarized in two, for example, you
> complete missed that multicast traffic can be filtered while broadcast
> traffic must be received.=20

That's an endpoint issue, not an L2 forwarding issue.

>> Otherwise, you didn't explain why we can't just use what already works=

>> in the Internet.
>=20
> I am getting tired of this argument, write a concrete proposal, don't
> just say "use what already works in the Internet."

I did - I proposed existing ST for multicast/broadcast only. You
continue to want to propose something new.

> If the Internet has already solved all the issues, why do we need TRILL=
?

I already answered that as well. Let me be more clear:

"We do NOT need TRILL to fix anything in either broadcast or multicast".

Joe

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


--------------enigB524203DE65F468EF18440A2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOriOE5f5cImnZrsRAv7LAKD1HCnnbLqo9DSgE9W0MDV9ibykTwCgolyO
NAvaXMudnDN3xzh75lijqp0=
=m+s6
-----END PGP SIGNATURE-----

--------------enigB524203DE65F468EF18440A2--



Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l443XlZc028834 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 20:33:48 -0700 (PDT)
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l443XYb15128; Fri, 4 May 2007 03:33:34 GMT
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, 3 May 2007 23:33:33 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value - suggested name for "the RPF thing"
Thread-Index: AceN8VRgWh7TNPUPRzGDw4I0ccGlWAAC02tw
References: <[e-mail]>
From: "Peter Ashwood-Smith" <[e-mail]>
To: <[e-mail]>, "Eric Gray \(LO/EUS\)" <[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 l443XlZc028834
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value - suggested name for "the RPF thing"
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, 04 May 2007 03:34:15 -0000
Status: RO
Content-Length: 2774

I suggest "the RPF thing" be called RPFC "Reverse Path Forwarding
Check".

Peter

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: Thursday, May 03, 2007 9:57 PM
> To: Eric Gray (LO/EUS)
> Cc: [e-mail]; Joe Touch
> Subject: Re: [rbridge] Setting initial "hop count" value
> 
> Sorry Eric. There ought to be a better name for it than "the 
> RPF thing".
> What's being talked about is what I presented at the WG, 
> which is the precomputation, for each tree, for each port, 
> the set of ingress RBridges from which it would be logical to 
> receive packets from, on that port.
> 
> To summarize "the RPF thing" (and I'd love a better name for 
> it, but maybe we don't need to name it-- we can just put the 
> algorithm in the spec)
> 
> a) Each RBridge R1 announces, in the core instance of IS-IS, 
> the set of trees R1 will ever choose as distribution trees 
> for packets that R1 injects. So say that R1 chooses {R1, R4, and R5}
> 
> b) Each RBridge also announces whether it wants to be the 
> root of a tree
> 
> c) Each RBridge R2 calculates a tree for each of the RBridges 
> that have say "yes"
> for b).
> 
> d) An RBridge, say R3, calculates the tree rooted at, say, 
> R5. Let's say that
> R3 determines that ports a, b, c, and f are in the R5-tree.
> Then let's say that of all the RBridges, {R6 and R7} say (in 
> a) that they are going to choose the R5-tree. R3 figures out 
> which port it should receive things from R6, on the R5-tree, 
> and marks that port as "ingress RBridge R6 allowed". Likewise 
> it does that for the port for which it should receive things 
> from R7 on that tree.
> 
> e) R3 does filtering as follows: If R3 receives a multicast 
> packet marked as R5-tree (egress RBridge field =R5), with 
> ingress RBridge Rx, on port p, then if the ingress RBridge is 
> not listed among the allowed ingress RBridges for that port 
> for that tree, R3 discards the packet.
> 
> Note the overhead for this is that if the average number of 
> trees each ingress RBridge says they will select is 2 (I'd 
> think most RBridges would select only one tree -- it would be 
> only for RBridges that want to multipath multicast that 
> they'd select more than one tree), then there are only 
> 2*number of RBridges TOTAL that will get listed as legal 
> ingress RBridges.
> 
> Radia
> 
> ----- Original Message -----
> From: "Eric Gray (LO/EUS)" <[e-mail]>
> 
> > 
> > 	First, what exactly is the "Radia RPF" proposal that 
> you mention in 
> > another thread of discussion,
> 
> _______________________________________________
> 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 l441vNdY010645 for <[e-mail]>; Thu, 3 May 2007 18:57:24 -0700 (PDT)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 03 May 2007 18:57:23 -0700 (PDT)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 03 May 2007 18:57:22 -0700 (PDT)
Received: from [152.70.2.164] (Forwarded-For: [66.195.71.171]) by mail-srv.sfvic.sunlabs.com (mshttpd); Thu, 03 May 2007 18:57:22 -0700
Date: Thu, 03 May 2007 18:57:22 -0700
From: [e-mail]
To: "Eric Gray (LO/EUS)" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 04 May 2007 01:57:42 -0000
Status: RO
Content-Length: 2100

Sorry Eric. There ought to be a better name for it than "the RPF thing".
What's being talked about is what I presented at the WG, which is
the precomputation, for each tree, for each port, the set of ingress RBridges
from which it would be logical to receive packets from, on that port.

To summarize "the RPF thing" (and I'd love a better name for it, but maybe we
don't need to name it-- we can just put the algorithm in the spec)

a) Each RBridge R1 announces, in the core instance of IS-IS, the set of
trees R1 will ever choose as distribution trees for packets that R1 injects. So
say that R1 chooses {R1, R4, and R5}

b) Each RBridge also announces whether it wants to be the root
of a tree

c) Each RBridge R2 calculates a tree for each of the RBridges that have say "yes"
for b).

d) An RBridge, say R3, calculates the tree rooted at, say, R5. Let's say that
R3 determines that ports a, b, c, and f are in the R5-tree.
Then let's say that of all the RBridges, {R6 and R7} say (in a) that they
are going to choose the R5-tree. R3 figures out which port it should
receive things from R6, on the R5-tree, and marks that port as
"ingress RBridge R6 allowed". Likewise it does that for the port
for which it should receive things from R7 on that tree.

e) R3 does filtering as follows: If R3 receives a multicast packet marked
as R5-tree (egress RBridge field =R5), with ingress RBridge Rx, on port p,
then if the ingress RBridge is not listed among the allowed
ingress RBridges for that port for that tree, R3 discards the packet.

Note the overhead for this is that if the average number of trees each ingress
RBridge says they will select is 2 (I'd think most RBridges would select only one
tree -- it would be only for RBridges that want to multipath multicast that they'd
select more than one tree), then there are only 2*number of RBridges TOTAL
that will get listed as legal ingress RBridges.

Radia

----- Original Message -----
From: "Eric Gray (LO/EUS)" <[e-mail]>

> 
> 	First, what exactly is the "Radia RPF" proposal that you
> mention in another thread of discussion,



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 l441hNV8008047 for <[e-mail]>; Thu, 3 May 2007 18:43:23 -0700 (PDT)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 03 May 2007 18:43:23 -0700 (PDT)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 03 May 2007 18:43:23 -0700 (PDT)
Received: from [152.70.2.164] (Forwarded-For: [66.195.71.171]) by mail-srv.sfvic.sunlabs.com (mshttpd); Thu, 03 May 2007 18:43:23 -0700
Date: Thu, 03 May 2007 18:43:23 -0700
From: [e-mail]
To: "Eric Gray (LO/EUS)" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Optional configuration of RBridge nickname
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, 04 May 2007 01:43:45 -0000
Status: RO
Content-Length: 1132

Yes. If two RBridges are configured with the same nickname, the loser has
to fall back on negotiation ("loser" based on priority concatenated with ID).

You might want to log an error "Hey! I was configured with nickname 75 but
someone else is also configured with it". But other than that, it's straightforward
what the algorithm in all those cases is.

Radia



----- Original Message -----
From: "Eric Gray (LO/EUS)" <[e-mail]>
Date: Thursday, May 3, 2007 7:37 am
Subject: RE: [rbridge] Optional configuration of RBridge nickname

\
> 	If so, then how do we address the issue with contention
> if more than one administrator wants to use a specific nickname
> and so more than one sets the priority to the highest possible
> value for the same configured nickname?
> 
> 	Also, how do you propose to address the general problem
> where two devices are configured with the same nickname but at
> different priorities?  Does the one with the lower priority
> fall back to negotiation?  If so, what effect does this have 
> on network stability if the device with the higher priority 
> starts to behave erratically?




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 l440LNvA022003 for <[e-mail]>; Thu, 3 May 2007 17:21:23 -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, 3 May 2007 17:21:19 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceN2I2qKO28r7+KQXOsvaOQxgaUowACJ+9Q
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: "Silvano Gai" <[e-mail]>
To: "Joe Touch" <[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 l440LNvA022003
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 04 May 2007 00:21:40 -0000
Status: RO
Content-Length: 1440

Joe

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Thursday, May 03, 2007 4:11 PM
> To: Silvano Gai
> Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> Subject: Re: [rbridge] Setting initial "hop count" value
> 
> 
> 
> Silvano Gai wrote:
> ...
> >> As to multicast, I don't see why Internet versions of this aren't
> >> sufficient as well.
> >
> > Please see my post of yesterday where I explained the differences.
> 
> You explained that routers do not propagate broadcast, but even a
> radius-based TTL can overwhelm the system if there's a loop anyway.
> 
> You explained that we need different queues for broadcast and/or
> multicast to avoid interference with routing protocols, which is
> probably judicious anyway, and is already the case in L2 (e.g.,
> broadcast vs. BPDU queues, as you note).
> 

My message had ten points. You summarized in two, for example, you
complete missed that multicast traffic can be filtered while broadcast
traffic must be received. 

> Otherwise, you didn't explain why we can't just use what already works
> in the Internet.
> 

I am getting tired of this argument, write a concrete proposal, don't
just say "use what already works in the Internet."

If the Internet has already solved all the issues, why do we need TRILL?

-- Silvano


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




Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43NCDoF005846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 16:12:13 -0700 (PDT)
Received: from [127.0.0.1] (112.sub-75-215-214.myvzw.com [75.215.214.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l43NBl1A021740; Thu, 3 May 2007 16:11:50 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 03 May 2007 16:11:25 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Silvano Gai <[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]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6C70E6F0C0F8099DBB43B52D"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 23:12:44 -0000
Status: RO
Content-Length: 1467

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6C70E6F0C0F8099DBB43B52D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Silvano Gai wrote:
=2E..
>> As to multicast, I don't see why Internet versions of this aren't
>> sufficient as well.=20
>=20
> Please see my post of yesterday where I explained the differences.

You explained that routers do not propagate broadcast, but even a
radius-based TTL can overwhelm the system if there's a loop anyway.

You explained that we need different queues for broadcast and/or
multicast to avoid interference with routing protocols, which is
probably judicious anyway, and is already the case in L2 (e.g.,
broadcast vs. BPDU queues, as you note).

Otherwise, you didn't explain why we can't just use what already works
in the Internet.

Joe

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


--------------enig6C70E6F0C0F8099DBB43B52D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOmwdE5f5cImnZrsRAr1uAJ4/OuARk4hYG3HhXh6Zs4CXZrpr3wCdGtdU
JuGfoxHf/GgikTB+pTCtn8E=
=VvJz
-----END PGP SIGNATURE-----

--------------enig6C70E6F0C0F8099DBB43B52D--



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 l43MTLdZ025258 for <[e-mail]>; Thu, 3 May 2007 15:29:21 -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, 3 May 2007 15:29:15 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNzo33XkyZByZNS+OFrQE3HS+wygAA9Q+Q
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: "Silvano Gai" <[e-mail]>
To: "Joe Touch" <[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 l43MTLdZ025258
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 22:29:40 -0000
Status: RO
Content-Length: 1477

Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Thursday, May 03, 2007 3:00 PM
> To: Silvano Gai
> Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> Subject: Re: [rbridge] Setting initial "hop count" value
> 
> 
> 
> Silvano Gai wrote:
> ...
> > If you have a bunch of distribution trees computed by the Spanning
Tree
> > Protocol let's just use them also for unicast traffic. We put a tag
in
> > the frame to select the distribution tree and we are done.
> >
> > This completely solves the limitation you mention with respect to
> > unicast traffic.
> >
> > Why do we need IS-IS?
> 
> The point of TRILL was to apply Internet routing to L2. IS-IS is an
> example of Internet routing (do we NEED IS-IS? or is it just a
> convenient version of Internet routing that can support L2 tags; I
think
> the latter is more relevant).
> 
> As to multicast, I don't see why Internet versions of this aren't
> sufficient as well. 

Please see my post of yesterday where I explained the differences.

-- Silvano


Internet TTLs aren't the primary means by which
> storms are avoided, and shouldn't be here either. However, IF such
> storms are that much of a concern, then for the multicast traffic (of
> which broadcast is a degenerate case anyway), then using a ST seems
like
> a fine way to apply existing technology.
> 
> Joe
> 
> --
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment




Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43M2mYu018292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 15:02:48 -0700 (PDT)
Received: from [127.0.0.1] (112.sub-75-215-214.myvzw.com [75.215.214.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l43M2M3j007826; Thu, 3 May 2007 15:02:26 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 03 May 2007 15:02:00 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: "Eric Gray (LO/EUS)" <[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]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4DB6DC34FE9C8180A92B627B"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 22:03:07 -0000
Status: RO
Content-Length: 1393

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4DB6DC34FE9C8180A92B627B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Eric Gray (LO/EUS) wrote:
> Silvano,
>=20
> 	Of course customer requirements are important, but see my
> reply on another thread.  Basically, the customer will ask for=20
> a certain behavior out of the technology - not a specific choice
> for the technology itself.

Eric is more generous than I w.r.t. customers. IMO, they don't even know
what behavior they want most of the time either.

We (the IETF) build what we think is useful, *whether or not* the
customer wants it. The customer doesn't want congestion control - at
least they don't want it to apply to *their* traffic.

Joe

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


--------------enig4DB6DC34FE9C8180A92B627B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOlvZE5f5cImnZrsRAqkaAJ9YpN5xYMoPxvVe3JMq1ADJuj4QUgCgtcL/
uToRjdomixsZAeMYAuwlzKo=
=ncxc
-----END PGP SIGNATURE-----

--------------enig4DB6DC34FE9C8180A92B627B--



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43M0ciU017987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 15:00:38 -0700 (PDT)
Received: from [127.0.0.1] (112.sub-75-215-214.myvzw.com [75.215.214.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l43M02iw007406; Thu, 3 May 2007 15:00:07 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 03 May 2007 14:59:43 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Silvano Gai <[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]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig65479F8C1ADB062CF655B31F"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 22:01:15 -0000
Status: RO
Content-Length: 1790

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig65479F8C1ADB062CF655B31F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Silvano Gai wrote:
=2E..
> If you have a bunch of distribution trees computed by the Spanning Tree=

> Protocol let's just use them also for unicast traffic. We put a tag in
> the frame to select the distribution tree and we are done.
>=20
> This completely solves the limitation you mention with respect to
> unicast traffic.
>=20
> Why do we need IS-IS?

The point of TRILL was to apply Internet routing to L2. IS-IS is an
example of Internet routing (do we NEED IS-IS? or is it just a
convenient version of Internet routing that can support L2 tags; I think
the latter is more relevant).

As to multicast, I don't see why Internet versions of this aren't
sufficient as well. Internet TTLs aren't the primary means by which
storms are avoided, and shouldn't be here either. However, IF such
storms are that much of a concern, then for the multicast traffic (of
which broadcast is a degenerate case anyway), then using a ST seems like
a fine way to apply existing technology.

Joe

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


--------------enig65479F8C1ADB062CF655B31F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOltPE5f5cImnZrsRAiaSAKDapDWBzjAwftDK3i+7KIhvsjcLlQCeJrqw
ZUolZk+gnjfWTRWwtUNBakU=
=0/gJ
-----END PGP SIGNATURE-----

--------------enig65479F8C1ADB062CF655B31F--



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43LsmB1016824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 14:54:49 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l43Ltkdn032172; Thu, 3 May 2007 16:55:46 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 3 May 2007 16:53:46 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 3 May 2007 16:53:42 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNx1osKI8WvKxmQeqAstl1bV7jhQAAch0AAADzusA=
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: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Joe Touch" <[e-mail]>
X-OriginalArrivalTime: 03 May 2007 21:53:46.0655 (UTC) FILETIME=[866E82F0:01C78DCD]
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 l43LsmB1016824
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 21:55:17 -0000
Status: RO
Content-Length: 2990

Silvano,

	Of course customer requirements are important, but see my
reply on another thread.  Basically, the customer will ask for 
a certain behavior out of the technology - not a specific choice
for the technology itself.

	Naturally, there will be customers with requirements they
base on "belief systems" and imperfect knowledge of the how a
specific technology works (and - more importantly - sometimes 
doesn't work).  As Joe was saying (I think) that is a customer
management issue, not a technology one...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Thursday, May 03, 2007 5:27 PM
> To: Joe Touch
> Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Setting initial "hop count" value
> 
> 
> Joe,
> 
> I understand IETF enough ;-) I never said that I was speaking as a
> company.
> I still believe customer requirements are important.
> 
> More inline:
> 
> > -----Original Message-----
> > From: Joe Touch [mailto:[e-mail]]
> > Sent: Thursday, May 03, 2007 2:08 PM
> > To: Silvano Gai
> > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > Subject: Re: [rbridge] Setting initial "hop count" value
> > 
> > 
> > 
> > Silvano Gai wrote:
> > > Eric,
> > >
> > > 1) There is no doubt that a solution based on some 
> variation of the
> > > Spanning Tree Protocol may be used to compute bidirectional
> distribution
> > > trees.
> > >
> > > 2) There is no doubt that such a solution will have no transient
> loops
> > > and will not need "the RADIA RPF" proposal.
> > >
> > > THIS SOLUTION WILL NOT SATTISFY THE STRONG CUSTOMER DEMAND TO
> ELIMINATE
> > > SPANNING TREE.
> > 
> > TRILL isn't designed to get rid of spanning tree necessarily. It's
> > designed to overcome the limitations of ST w.r.t. unicast traffic.
> > 
> 
> If you have a bunch of distribution trees computed by the 
> Spanning Tree
> Protocol let's just use them also for unicast traffic. We put a tag in
> the frame to select the distribution tree and we are done.
> 
> This completely solves the limitation you mention with respect to
> unicast traffic.
> 
> Why do we need IS-IS?
> 
> Don't tell me is a customer need ;-)
> 
> -- Silvano
> 
> 
> > There's no point in overcoming ST w.r.t. multicast/broadcast per se.
> As
> > Eric noted, if getting rid of ST forces a new solution just for the
> sake
> > of avoiding ST (i.e., marketing), it's not a useful 
> position to take.
> > 
> > ...
> > > Due to the customer requirements I am against running the Spanning
> Tree
> > > Protocol in TRILL to compute distribution trees.
> > 
> > Responding to customers is what companies do; here in the IETF, we
> > believe in rough consensus and running code, and people speak as
> > individuals, not on behalf of companies or customers ;-)
> > 
> > Joe
> > 
> > --
> > ----------------------------------------
> > Joe Touch
> > Sr. Network Engineer, USAF TSAT Space Segment
> 
> 



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43Lmavb015368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 14:48:36 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l43LltLZ008568; Thu, 3 May 2007 16:47:55 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 3 May 2007 16:48:30 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 3 May 2007 16:48:25 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNE7n/0RQ0UyQ3SXm+IM/xanRYBgAACbpQAB+brMAAAE5RYAAALQrgAAEI26AAAPew0AAI4tzgAALk6uA=
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Joe Touch" <[e-mail]>
X-OriginalArrivalTime: 03 May 2007 21:48:30.0237 (UTC) FILETIME=[C9D4F4D0:01C78DCC]
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 l43Lmavb015368
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 21:49:17 -0000
Status: RO
Content-Length: 12572

Silvano,

	I am certain I've had this discussion before, but - like 
the other one - possibly not on the list.

	So, I will repeat what I found out in earlier discussion.

	There is a definite advantage to using IS-IS for unicast
forwarding.  That can be independent of how forwarding is done
for the multi-destination distribution tree.  Of course, it is
a different question whether or not it is a good idea for unicast
and multi-destination traffic to use divergent paths - but that
question exists as soon as you allow that multi-destination data
traffic might be sent via a distribution tree not rooted at the 
ingress.

	Note that you've apparently broadened the requirement of
customers (who typically don't make staements about technology
preference, preferring to state requirements in terms of the
the desirable behavior they are looking for).  I doubt that a
customer is telling you that they won't accept a solution that
is based on using spanning tree for a relatively insignificant
portion of the offered traffic load, as long as they get a
solution that makes efficient use of link resources generally.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Thursday, May 03, 2007 4:49 PM
> To: Eric Gray (LO/EUS); Joe Touch
> Cc: Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Setting initial "hop count" value
> Importance: High
> 
> 
> Eric,
> 
> 1) There is no doubt that a solution based on some variation of the
> Spanning Tree Protocol may be used to compute bidirectional 
> distribution
> trees.
> 
> 2) There is no doubt that such a solution will have no transient loops
> and will not need "the RADIA RPF" proposal.
> 
> THIS SOLUTION WILL NOT SATTISFY THE STRONG CUSTOMER DEMAND TO 
> ELIMINATE
> SPANNING TREE.
> 
> If we go that path, it is also clear that there is no need 
> for IS-IS at
> all. We just have a set of distributions trees, we can stick an
> additional 1Q tag in the frame doing the function of tree selector and
> we achieve shortest path, and equal and unequal cost multipath. Do you
> agree that there will be no advantage in running the core instance of
> ISIS?
> 
> Due to the customer requirements I am against running the 
> Spanning Tree
> Protocol in TRILL to compute distribution trees.
> 
> -- Silvano
> 
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > Sent: Thursday, May 03, 2007 9:27 AM
> > To: Silvano Gai; Joe Touch
> > Cc: Radia Perlman; [e-mail]
> > Subject: RE: [rbridge] Setting initial "hop count" value
> > 
> > Silvano,
> > 
> > 	I did some looking, and you are correct.  I mentioned it to
> > Radia in an off-line discussion on November 1st of last year, in
> > response to her proposal to make distribution trees bi-directional.
> > The discussion was not meant to be off-line, but Radia had excluded
> > the list in one of her replies.
> > 
> > 	I extracted that part of the conversation below.
> > 
> > 	Even assuming this was not publicly mentioned previously,
> > is there a flaw in the argument I made to you just now?
> > 
> > 	Possibly I made the mistake of thinking that - because the
> > argument is inescapably obvious to me - then it must be equally
> > obvious to the rest of the working group.
> > 
> > 	It is worth noting that several of the replies on that thread
> > ("Compromise proposal---allowing tradeoff between computation and
> > optimality of delivery") seemed (to me, at least) to assume the use
> > of STP.
> > 
> > On November 1st, at 3:35 P.M. (EST), Radia Perlman said:
> > --> I'm talking about a bidirectional tree. Just like with the
> > --> spanning tree computed by legacy bridges, packets don't
> > --> traverse links twice. A particular bridge B has a root
> > --> port and other ports for which it is DB.
> > --> On the ports for which B is DB, B sends the frame and it
> > --> travels further from the root on those paths.
> > --> It's only on the root port that the frame travels towards
> > --> the root, and then when the root receives the frame, it
> > --> only sends the frame onto other ports (not the one it got
> > --> it from).
> > 
> > To which I responded (at 4:43 P.M. of the same day):
> > ->	Is this not a fundamental departure from how Ingress RBridge
> > -> Trees are expected to work?  My understanding was that an IRT
> > -> is uni-directional.
> > ->
> > ->	Also, how does this work in the broadcast/multicast case -
> > -> unless we are in fact using STP (or a variation of STP)?  If
> > -> the tree is bi-directional, how does a node on the tree know
> > -> how to forward flooded traffic without potentially producing
> > -> a storm?
> > ->
> > ->	If we are in fact using a variation of STP to set up the
> > -> shared IRT, how does this differ from existing proposals in
> > -> the IEEE?
> > 
> > I never received a reply to this note, but Radia did later reply
> > to Donald Eastlake on the same subject (including the list - see
> > her post on Sat 11/4/2006 6:23 PM, EST).
> > 
> > 
> > 
> > 
> > Thanks!
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Thursday, May 03, 2007 11:36 AM
> > > To: Eric Gray (LO/EUS); Joe Touch
> > > Cc: Radia Perlman; [e-mail]
> > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > Importance: High
> > >
> > > Eric,
> > >
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > Sent: Thursday, May 03, 2007 8:16 AM
> > > > To: Silvano Gai; Joe Touch
> > > > Cc: Radia Perlman; [e-mail]
> > > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > >
> > > > Silvano,
> > > >
> > > > 	That was true, right up until the proposal was 
> made to make
> > > > the trees bi-directional.  That - in turn was 
> necessitated by the
> > > > proposal to allow some edge RBridges to opt-out of 
> sourcing their
> > > > own distribution trees.  At that point, more than a few people
> > > > started to think that we were then abandoning the use of SPF for
> > > > the multi-destination case.
> > > >
> > >
> > > During that discussion I never read anybody proposing to use the
> > > Spanning Tree Protocol.
> > >
> > > -- Silvano
> > >
> > > > 	The rationale for thinking that is really quite obvious.
> > > >
> > > > 	Note that - if you assume a tree computed with 
> X as root,
> > > > spanning tree protocol effectively sets up a tree with X as root
> > > > and shortest paths computed from X to all leaf bridges.
> > > >
> > > > 	If you assume a bi-directional tree computed 
> with X as root
> > > > - even if computed explicitly using SPF routing - that 
> tree is the
> > > > shortest path from one leaf to another only by a happy 
> accident in
> > > > some cases and NOT at all in all other cases.
> > > >
> > > > 	If using a bi-directional spanning tree means 
> essentially
> > > > abandoning SPF routing, then the advantage you might hope to get
> > > > from not using (M/R)STP vanishes in a puff of smoke in 
> comparison
> > > > with the cost we can expect to pay to develop an 
> alternative, and
> > > > (eventually) make it work.
> > > >
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson
> > > >
> > > > > -----Original Message-----
> > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > Sent: Thursday, May 03, 2007 11:03 AM
> > > > > To: Eric Gray (LO/EUS); Joe Touch
> > > > > Cc: Radia Perlman; [e-mail]
> > > > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > > > Importance: High
> > > > >
> > > > >
> > > > > Eric,
> > > > >
> > > > > From when I joined this WG all the base protocol drafts
> > > have always
> > > > > assumed that TRILL was using IS-IS to compute what we now call
> > > > > "Distribution Trees". We changed the names from "source
> > > > > routed tree" to
> > > > > "distribution tree" and the number of these trees, but
> > > never the way
> > > > > they were computed.
> > > > >
> > > > > -- Silvano
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > > Sent: Thursday, May 03, 2007 7:54 AM
> > > > > > To: Silvano Gai; Joe Touch
> > > > > > Cc: Radia Perlman; [e-mail]
> > > > > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > > > >
> > > > > > Silvano,
> > > > > >
> > > > > > 	Same question applies here.  It's one thing to
> > > say that we
> > > > > > don't run STP in the conventional bridging sense.  We don't
> run
> > > > > > IS-IS in the conventional IP (or OSI) routing sense, either.
> It
> > > > > > is quite another to say that we don't use an 
> existing spanning
> > > > > > tree protocol (perhaps with different BPDUs - e.g. - RBPDUs)
> and
> > > > > > gain all of the advantages of existing implementation, and
> field
> > > > > > deployment experience associated with it.
> > > > > >
> > > > > > 	Are you (and probably Joe) saying that we want to invent
> > > > > > something new here?
> > > > > >
> > > > > > --
> > > > > > Eric Gray
> > > > > > Principal Engineer
> > > > > > Ericsson
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > > > Sent: Wednesday, May 02, 2007 7:47 PM
> > > > > > > To: Joe Touch
> > > > > > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > > > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > > > > >
> > > > > > > Joe
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Joe Touch [mailto:[e-mail]]
> > > > > > > > Sent: Wednesday, May 02, 2007 4:43 PM
> > > > > > > > To: Silvano Gai
> > > > > > > > Cc: Eric Gray (LO/EUS); Radia Perlman; 
> [e-mail]
> > > > > > > > Subject: Re: [rbridge] Setting initial "hop count" value
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Silvano Gai wrote:
> > > > > > > > > Joe,
> > > > > > > > ...
> > > > > > > > >>> Loops are much more dangerous at layer 2 than at
> > > > > layer 3. I am
> > > > > > > > >>> sympathetic with Radia that anything we can do to
> > > > > > > mitigate them is
> > > > > > > > > good.
> > > > > > > > >> This is why we ought to be using a spanning tree
> > > for those,
> > > > > > > > >
> > > > > > > > > You are not claiming that we need to run the Spanning
> > > > > > > Tree Protocol,
> > > > > > > > > correct?
> > > > > > > >
> > > > > > > > No; I was claiming that there's a legitimate reason to
> > > > > still have
> > > > > a
> > > > > > > > spanning tree inside the campus.
> > > > > > > >
> > > > > > >
> > > > > > > Agreed, we are in synch.
> > > > > > >
> > > > > > > > > and let that
> > > > > > > > >> tree be suboptimal and/or converge via means that
> > > > > avoid looping
> > > > > > > > >> transients.
> > > > > > > > >
> > > > > > > > > This is not easy. Radia RPF proposal seems a 
> good start,
> > > > > > > but it is:
> > > > > > > > > - not agreed yet
> > > > > > > > > - Unproven
> > > > > > > > >
> > > > > > > > > It is pretty straightforward to use Radia RPF proposal
> to
> > > > > > > reduce the
> > > > > > > > > probability of transient loops. If you want to
> > > > > "GUARANTEE" that
> > > > > > > there
> > > > > > > > > are no transient loops, that is a different story,
> > > > > since it has
> > > > > a
> > > > > > > > > significant state requirement that can impact low end
> > > > > > > implementation. I
> > > > > > > > > am all for it, but we need to discuss it in a separate
> > > thread.
> > > > > > > >
> > > > > > > > Agreed; I'm not convinced that such transients aren't OK
> if
> > > > > > > they exist
> > > > > > > > with conventional implementations.
> > > > > > >
> > > > > > > They don't. Today the Spanning Tree protocol 
> never generates
> > > > > > > a transient
> > > > > > > loop.
> > > > > > >
> > > > > > > -- Silvano
> > > > > > >
> > > > > > > Remember that rbridges aren't
> > > > > > > > intended to scale beyond current implementations, which
> > > > > means that
> > > > > > > > however existing implementations support spanning trees
> and
> > > deal
> > > > > (or
> > > > > > > > don't) with transient loops should map here just fine.
> > > > > > > >
> > > > > > > > Joe
> > > > > > > > --
> > > > > > > > ----------------------------------------
> > > > > > > > Joe Touch
> > > > > > > > Sr. Network Engineer, USAF TSAT Space Segment
> > > > > > >
> > > > > > >
> > > > >
> > >
> 



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 l43LRDi1011082 for <[e-mail]>; Thu, 3 May 2007 14:27:23 -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, 3 May 2007 14:27:08 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNx1osKI8WvKxmQeqAstl1bV7jhQAAch0A
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: "Silvano Gai" <[e-mail]>
To: "Joe Touch" <[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 l43LRDi1011082
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 21:27:39 -0000
Status: RO
Content-Length: 2012

Joe,

I understand IETF enough ;-) I never said that I was speaking as a
company.
I still believe customer requirements are important.

More inline:

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Thursday, May 03, 2007 2:08 PM
> To: Silvano Gai
> Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> Subject: Re: [rbridge] Setting initial "hop count" value
> 
> 
> 
> Silvano Gai wrote:
> > Eric,
> >
> > 1) There is no doubt that a solution based on some variation of the
> > Spanning Tree Protocol may be used to compute bidirectional
distribution
> > trees.
> >
> > 2) There is no doubt that such a solution will have no transient
loops
> > and will not need "the RADIA RPF" proposal.
> >
> > THIS SOLUTION WILL NOT SATTISFY THE STRONG CUSTOMER DEMAND TO
ELIMINATE
> > SPANNING TREE.
> 
> TRILL isn't designed to get rid of spanning tree necessarily. It's
> designed to overcome the limitations of ST w.r.t. unicast traffic.
> 

If you have a bunch of distribution trees computed by the Spanning Tree
Protocol let's just use them also for unicast traffic. We put a tag in
the frame to select the distribution tree and we are done.

This completely solves the limitation you mention with respect to
unicast traffic.

Why do we need IS-IS?

Don't tell me is a customer need ;-)

-- Silvano


> There's no point in overcoming ST w.r.t. multicast/broadcast per se.
As
> Eric noted, if getting rid of ST forces a new solution just for the
sake
> of avoiding ST (i.e., marketing), it's not a useful position to take.
> 
> ...
> > Due to the customer requirements I am against running the Spanning
Tree
> > Protocol in TRILL to compute distribution trees.
> 
> Responding to customers is what companies do; here in the IETF, we
> believe in rough consensus and running code, and people speak as
> individuals, not on behalf of companies or customers ;-)
> 
> Joe
> 
> --
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment




Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43L95gQ006678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 14:09:05 -0700 (PDT)
Received: from [127.0.0.1] (112.sub-75-215-214.myvzw.com [75.215.214.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l43L8mPs027062; Thu, 3 May 2007 14:08:50 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 03 May 2007 14:08:29 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA3F7561574F35295DC45FFE0"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 21:09:40 -0000
Status: RO
Content-Length: 1898

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA3F7561574F35295DC45FFE0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Silvano Gai wrote:
> Eric,
>=20
> 1) There is no doubt that a solution based on some variation of the
> Spanning Tree Protocol may be used to compute bidirectional distributio=
n
> trees.
>=20
> 2) There is no doubt that such a solution will have no transient loops
> and will not need "the RADIA RPF" proposal.
>=20
> THIS SOLUTION WILL NOT SATTISFY THE STRONG CUSTOMER DEMAND TO ELIMINATE=

> SPANNING TREE.

TRILL isn't designed to get rid of spanning tree necessarily. It's
designed to overcome the limitations of ST w.r.t. unicast traffic.

There's no point in overcoming ST w.r.t. multicast/broadcast per se. As
Eric noted, if getting rid of ST forces a new solution just for the sake
of avoiding ST (i.e., marketing), it's not a useful position to take.

=2E..
> Due to the customer requirements I am against running the Spanning Tree=

> Protocol in TRILL to compute distribution trees.

Responding to customers is what companies do; here in the IETF, we
believe in rough consensus and running code, and people speak as
individuals, not on behalf of companies or customers ;-)

Joe

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


--------------enigA3F7561574F35295DC45FFE0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOk9NE5f5cImnZrsRAqj3AJwLqe5bVQuow7wQsmuSta4JqAHuewCfUGDB
ugv3rYepTlCBMGAo7ux4+jA=
=Djow
-----END PGP SIGNATURE-----

--------------enigA3F7561574F35295DC45FFE0--



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 l43KtvAq003918 for <[e-mail]>; Thu, 3 May 2007 13:55:57 -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, 3 May 2007 13:55:52 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Back to ND/ARP optimization
Thread-Index: AceNlAJKrkidjsV4S7GXrdVJ8QHK8wAMNvOg
References: <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: <[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 l43KtvAq003918
Subject: Re: [rbridge] Back to ND/ARP optimization
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, 03 May 2007 20:56:05 -0000
Status: RO
Content-Length: 2607

Radia,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of [e-mail]
> Sent: Thursday, May 03, 2007 7:38 AM
> To: [e-mail]
> Subject: [rbridge] Back to ND/ARP optimization
> 
> Looking back on old emails, there are some people who'd like to get
rid of
> ND/ARP optimization,
> and some people pointing out that optimizing ND might not be so simple
> (for instance, SEND).
> 
> I'd be OK with removing it from the spec, or certainly making it
something
> other than a MUST, like
> perhaps MAY.
> 
> But there were fields in the per-VLAN instance of IS-IS to facilitate
> this, namely the (L3 address, L2 address).
> An RBridge *could* learn this information locally, but wouldn't learn
it
> as much. In other words, if S behind R1 sends
> an ARP request for target T behind R2, the response will be unicast to
S,
> so none of the other RBridges will
> learn where T is. Only R1. So R1 could in the future do a proxy ARP.
But
> if R2 announced (T, t) in its per-VLAN
> instance of IS-IS, then all the RBridges could learn (T,t).
Furthermore,
> if T has registered with R2 via some
> L2 enrollment protoocol, then R2 can immediately know if T is no
longer
> there and alert everyone.
> 
> Does anyone have a handle on how much traffic is caused by ARP/ND?
> 

With an ARP cache of 30 minutes, typical in hosts today, even with a 100
K hosts in a VLAN we get at most 55 ARP seconds. Since not all the hosts
talk with each other, it is more typically like 5 ARP/sec.

BASICALLY NOTHING.



> We could certainly do a compromise, like that each RBridge R1 SHOULD
> throttle ARP/ND queries, and
> not reflood a query for T if there has been more than k (some
parameter)
> queries for T in the last n seconds.
> 
> But that doesn't even have to be in the spec.
> 

Let's get read completely of ARP/ND proxy: these are product not
standard features.

Typically products will be multilayer and will have sophisticated ARP/ND
management scheme. Standardizing it in TRILL does not make sense.

-- Silvano

> It would be nice to know in operational networks how much traffic is
> caused by ARP/ND queries, and how
> worried people are about a malicious endnode DOS'ing by sending lots
of
> queries. (but it could just as easily
> send other types of broadcast/multicast traffic so maybe it's not
worth
> worrying about optimization ARP/ND because
> of malicious nodes).
> 
> 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 l43KnTib002466 for <[e-mail]>; Thu, 3 May 2007 13:49: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, 3 May 2007 13:49:22 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNE7n/0RQ0UyQ3SXm+IM/xanRYBgAACbpQAB+brMAAAE5RYAAALQrgAAEI26AAAPew0AAI4tzg
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: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[e-mail]>, "Joe Touch" <[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 l43KnTib002466
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 20:49:46 -0000
Status: RO
Content-Length: 10483

Eric,

1) There is no doubt that a solution based on some variation of the
Spanning Tree Protocol may be used to compute bidirectional distribution
trees.

2) There is no doubt that such a solution will have no transient loops
and will not need "the RADIA RPF" proposal.

THIS SOLUTION WILL NOT SATTISFY THE STRONG CUSTOMER DEMAND TO ELIMINATE
SPANNING TREE.

If we go that path, it is also clear that there is no need for IS-IS at
all. We just have a set of distributions trees, we can stick an
additional 1Q tag in the frame doing the function of tree selector and
we achieve shortest path, and equal and unequal cost multipath. Do you
agree that there will be no advantage in running the core instance of
ISIS?

Due to the customer requirements I am against running the Spanning Tree
Protocol in TRILL to compute distribution trees.

-- Silvano


> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> Sent: Thursday, May 03, 2007 9:27 AM
> To: Silvano Gai; Joe Touch
> Cc: Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Setting initial "hop count" value
> 
> Silvano,
> 
> 	I did some looking, and you are correct.  I mentioned it to
> Radia in an off-line discussion on November 1st of last year, in
> response to her proposal to make distribution trees bi-directional.
> The discussion was not meant to be off-line, but Radia had excluded
> the list in one of her replies.
> 
> 	I extracted that part of the conversation below.
> 
> 	Even assuming this was not publicly mentioned previously,
> is there a flaw in the argument I made to you just now?
> 
> 	Possibly I made the mistake of thinking that - because the
> argument is inescapably obvious to me - then it must be equally
> obvious to the rest of the working group.
> 
> 	It is worth noting that several of the replies on that thread
> ("Compromise proposal---allowing tradeoff between computation and
> optimality of delivery") seemed (to me, at least) to assume the use
> of STP.
> 
> On November 1st, at 3:35 P.M. (EST), Radia Perlman said:
> --> I'm talking about a bidirectional tree. Just like with the
> --> spanning tree computed by legacy bridges, packets don't
> --> traverse links twice. A particular bridge B has a root
> --> port and other ports for which it is DB.
> --> On the ports for which B is DB, B sends the frame and it
> --> travels further from the root on those paths.
> --> It's only on the root port that the frame travels towards
> --> the root, and then when the root receives the frame, it
> --> only sends the frame onto other ports (not the one it got
> --> it from).
> 
> To which I responded (at 4:43 P.M. of the same day):
> ->	Is this not a fundamental departure from how Ingress RBridge
> -> Trees are expected to work?  My understanding was that an IRT
> -> is uni-directional.
> ->
> ->	Also, how does this work in the broadcast/multicast case -
> -> unless we are in fact using STP (or a variation of STP)?  If
> -> the tree is bi-directional, how does a node on the tree know
> -> how to forward flooded traffic without potentially producing
> -> a storm?
> ->
> ->	If we are in fact using a variation of STP to set up the
> -> shared IRT, how does this differ from existing proposals in
> -> the IEEE?
> 
> I never received a reply to this note, but Radia did later reply
> to Donald Eastlake on the same subject (including the list - see
> her post on Sat 11/4/2006 6:23 PM, EST).
> 
> 
> 
> 
> Thanks!
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Thursday, May 03, 2007 11:36 AM
> > To: Eric Gray (LO/EUS); Joe Touch
> > Cc: Radia Perlman; [e-mail]
> > Subject: RE: [rbridge] Setting initial "hop count" value
> > Importance: High
> >
> > Eric,
> >
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > Sent: Thursday, May 03, 2007 8:16 AM
> > > To: Silvano Gai; Joe Touch
> > > Cc: Radia Perlman; [e-mail]
> > > Subject: RE: [rbridge] Setting initial "hop count" value
> > >
> > > Silvano,
> > >
> > > 	That was true, right up until the proposal was made to make
> > > the trees bi-directional.  That - in turn was necessitated by the
> > > proposal to allow some edge RBridges to opt-out of sourcing their
> > > own distribution trees.  At that point, more than a few people
> > > started to think that we were then abandoning the use of SPF for
> > > the multi-destination case.
> > >
> >
> > During that discussion I never read anybody proposing to use the
> > Spanning Tree Protocol.
> >
> > -- Silvano
> >
> > > 	The rationale for thinking that is really quite obvious.
> > >
> > > 	Note that - if you assume a tree computed with X as root,
> > > spanning tree protocol effectively sets up a tree with X as root
> > > and shortest paths computed from X to all leaf bridges.
> > >
> > > 	If you assume a bi-directional tree computed with X as root
> > > - even if computed explicitly using SPF routing - that tree is the
> > > shortest path from one leaf to another only by a happy accident in
> > > some cases and NOT at all in all other cases.
> > >
> > > 	If using a bi-directional spanning tree means essentially
> > > abandoning SPF routing, then the advantage you might hope to get
> > > from not using (M/R)STP vanishes in a puff of smoke in comparison
> > > with the cost we can expect to pay to develop an alternative, and
> > > (eventually) make it work.
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Thursday, May 03, 2007 11:03 AM
> > > > To: Eric Gray (LO/EUS); Joe Touch
> > > > Cc: Radia Perlman; [e-mail]
> > > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > > Importance: High
> > > >
> > > >
> > > > Eric,
> > > >
> > > > From when I joined this WG all the base protocol drafts
> > have always
> > > > assumed that TRILL was using IS-IS to compute what we now call
> > > > "Distribution Trees". We changed the names from "source
> > > > routed tree" to
> > > > "distribution tree" and the number of these trees, but
> > never the way
> > > > they were computed.
> > > >
> > > > -- Silvano
> > > >
> > > > > -----Original Message-----
> > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > Sent: Thursday, May 03, 2007 7:54 AM
> > > > > To: Silvano Gai; Joe Touch
> > > > > Cc: Radia Perlman; [e-mail]
> > > > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > > >
> > > > > Silvano,
> > > > >
> > > > > 	Same question applies here.  It's one thing to
> > say that we
> > > > > don't run STP in the conventional bridging sense.  We don't
run
> > > > > IS-IS in the conventional IP (or OSI) routing sense, either.
It
> > > > > is quite another to say that we don't use an existing spanning
> > > > > tree protocol (perhaps with different BPDUs - e.g. - RBPDUs)
and
> > > > > gain all of the advantages of existing implementation, and
field
> > > > > deployment experience associated with it.
> > > > >
> > > > > 	Are you (and probably Joe) saying that we want to invent
> > > > > something new here?
> > > > >
> > > > > --
> > > > > Eric Gray
> > > > > Principal Engineer
> > > > > Ericsson
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > > Sent: Wednesday, May 02, 2007 7:47 PM
> > > > > > To: Joe Touch
> > > > > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > > > >
> > > > > > Joe
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Joe Touch [mailto:[e-mail]]
> > > > > > > Sent: Wednesday, May 02, 2007 4:43 PM
> > > > > > > To: Silvano Gai
> > > > > > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > > > > Subject: Re: [rbridge] Setting initial "hop count" value
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Silvano Gai wrote:
> > > > > > > > Joe,
> > > > > > > ...
> > > > > > > >>> Loops are much more dangerous at layer 2 than at
> > > > layer 3. I am
> > > > > > > >>> sympathetic with Radia that anything we can do to
> > > > > > mitigate them is
> > > > > > > > good.
> > > > > > > >> This is why we ought to be using a spanning tree
> > for those,
> > > > > > > >
> > > > > > > > You are not claiming that we need to run the Spanning
> > > > > > Tree Protocol,
> > > > > > > > correct?
> > > > > > >
> > > > > > > No; I was claiming that there's a legitimate reason to
> > > > still have
> > > > a
> > > > > > > spanning tree inside the campus.
> > > > > > >
> > > > > >
> > > > > > Agreed, we are in synch.
> > > > > >
> > > > > > > > and let that
> > > > > > > >> tree be suboptimal and/or converge via means that
> > > > avoid looping
> > > > > > > >> transients.
> > > > > > > >
> > > > > > > > This is not easy. Radia RPF proposal seems a good start,
> > > > > > but it is:
> > > > > > > > - not agreed yet
> > > > > > > > - Unproven
> > > > > > > >
> > > > > > > > It is pretty straightforward to use Radia RPF proposal
to
> > > > > > reduce the
> > > > > > > > probability of transient loops. If you want to
> > > > "GUARANTEE" that
> > > > > > there
> > > > > > > > are no transient loops, that is a different story,
> > > > since it has
> > > > a
> > > > > > > > significant state requirement that can impact low end
> > > > > > implementation. I
> > > > > > > > am all for it, but we need to discuss it in a separate
> > thread.
> > > > > > >
> > > > > > > Agreed; I'm not convinced that such transients aren't OK
if
> > > > > > they exist
> > > > > > > with conventional implementations.
> > > > > >
> > > > > > They don't. Today the Spanning Tree protocol never generates
> > > > > > a transient
> > > > > > loop.
> > > > > >
> > > > > > -- Silvano
> > > > > >
> > > > > > Remember that rbridges aren't
> > > > > > > intended to scale beyond current implementations, which
> > > > means that
> > > > > > > however existing implementations support spanning trees
and
> > deal
> > > > (or
> > > > > > > don't) with transient loops should map here just fine.
> > > > > > >
> > > > > > > Joe
> > > > > > > --
> > > > > > > ----------------------------------------
> > > > > > > Joe Touch
> > > > > > > Sr. Network Engineer, USAF TSAT Space Segment
> > > > > >
> > > > > >
> > > >
> >



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43IF3LP027922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 11:15:03 -0700 (PDT)
Received: from [127.0.0.1] (112.sub-75-215-214.myvzw.com [75.215.214.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l43IEYRc019410; Thu, 3 May 2007 11:14:36 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 03 May 2007 11:14:14 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCB01B38D5C4A24995B215EEB"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] What is important in RBridge version 1.0?
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, 03 May 2007 18:16:13 -0000
Status: RO
Content-Length: 5118

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCB01B38D5C4A24995B215EEB
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Silvano Gai wrote:
> Joe,
>=20
> The current draft does not define the term flow and IMHO MUST not defin=
e
> it.

Agreed; I was using it as an example of how to differentiate
interpretations of the term 'multipath' only.

> IS-IS, OSPF, FSPS, etc enable load balancing, but do not specify the
> granularity of load balancing, the number of path and the path selectio=
n
> algorithm. These are product features.

OK, so let me be specific:

TRILL v1.0 does not need to support load balancing. If we get it for
free, so be it.

TRILL v1.0 does need to allow different edge pairs to use
non-overlapping communication paths (is that "flow"-free enough)?

Joe

>=20
> Many commercial products allow to configure round robin, source only,
> source-dest pair, five tuple load balancing.
>=20
> -- Silvano
>=20
>=20
>> -----Original Message-----
>> From: Joe Touch [mailto:[e-mail]]
>> Sent: Thursday, May 03, 2007 10:12 AM
>> To: Silvano Gai
>> Cc: [e-mail]
>> Subject: Re: [rbridge] What is important in RBridge version 1.0?
>>
>>
>>
>> Silvano Gai wrote:
>>> Joe,
>>>
>>> "multipath", which, as you say, presumes multiple concurrent paths
> is
>>> the main reason for TRILL.
>> Different traffic (i.e., different flows) using different paths
>> concurrently is the main reason for TRILL.
>>
>> Multipath - as I understand how the term is typically used in the IETF=

> -
>> is a way for the same traffic (i.e., a single flow) to use multiple
>> paths concurrently. That is NOT a primary reason for TRILL, though, if=

>> ISIS provides it already that's fine. I wouldn't list it as a primary
>> issue, though.
>>
>> Besides, isn't the PAS supposed to list these (and doesn't it, to some=

>> extent?)
>>
>> Joe
>>
>>> We don't need to do anything in the standard, since ISIS allows the
>>> computation of multiple concurrent paths. It is up to the product to
>>> decide how many path they will support, exactly as it happens in
>>> routers.
>>>
>>> More inline
>>>
>>>
>>>> -----Original Message-----
>>>> From: Joe Touch [mailto:[e-mail]]
>>>> Sent: Thursday, May 03, 2007 9:02 AM
>>>> To: Silvano Gai
>>>> Cc: [e-mail]
>>>> Subject: Re: [rbridge] What is important in RBridge version 1.0?
>>>>
>>>>
>>>>
>>>> Silvano Gai wrote:
>>>>> The current discussion of TTL/broadcast storm/etc made me think
> what
>>> is
>>>>> important in TRILL version 1.0 and what can be delayed to version
>>> 2.0 or
>>>>> dealt with in separate documents.
>>>>>
>>>>> Here is my list:
>>>>>
>>>>> 1) excellent support for shortest path/multipath
>>>>>    * core instance of IS-IS
>>>>>    * nickname assignments
>>>>>    * DR election
>>>> Different paths yes, but not "multipath", which presumes multiple
>>>> concurrent paths.
>>>>
>>>>> 2) A super stable frame format, so that companies may start to
> code
>>>>> their ASIC
>>>> Always (in all versions, IMO).
>>>>
>>>>> 3) Broadcast storm suppression
>>>> Avoidance. I might include loop avoidance here.
>>>>
>>> agreed
>>>
>>>>>    * Radia RPF proposal
>>>> TTL to break forwarding loops.
>>> agreed
>>>
>>>> Existing spanning tree (as much as possible) to avoid broadcast
> loops.
>>> Are you speaking of Spanning Tree or Spanning Tree Protocol?
>>>
>>>> No *new* protocols unless absolutely necessary.
>>>>
>>>>> 4) learning from data traffic (backward learning as bridges do)
>>>>>
>>>>> 5) Spanning Tree interoperability at the edges
>>>>>    * simple form, receiving BPDUs only
>>>>>
>>>>> 6) A last call no later than the end of the year.
>>>>>
>>>>> I propose we focus our discussion on these points without which we
>>> don't
>>>>> have a viable standard.
>>>>>
>>>>>
>>>>> Let's delay/move to other documents:
>>>> Agreed on all below.
>>>>
>>> I am glad
>>>
>>> -- Silvano
>>>
>>>>> 1) ARP/ND proxy
>>>>>
>>>>> 2) per VLAN IS-IS instance
>>>>>
>>>>> 3) IGMP learning
>>>>>
>>>>> What do you think?
>>>>>
>>>>> -- Silvano
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rbridge mailing list
>>>>> [e-mail]
>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>> --
>>>> ----------------------------------------
>>>> Joe Touch
>>>> Sr. Network Engineer, USAF TSAT Space Segment
>> --
>> ----------------------------------------
>> Joe Touch
>> Sr. Network Engineer, USAF TSAT Space Segment
>=20

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


--------------enigCB01B38D5C4A24995B215EEB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOiZ2E5f5cImnZrsRAlauAKDF/uSzKB9koAfrUi3LCdWnS9072QCgsiNK
6BIgKefS9lqkidaKDAr7eOI=
=nIRM
-----END PGP SIGNATURE-----

--------------enigCB01B38D5C4A24995B215EEB--



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 l43I3WEm024643 for <[e-mail]>; Thu, 3 May 2007 11:03:32 -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, 3 May 2007 11:03:28 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] What is important in RBridge version 1.0?
Thread-Index: AceNplzpV65jcmSEQni1EAcATorurAABfQiw
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Joe Touch" <[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 l43I3WEm024643
Cc: [e-mail]
Subject: Re: [rbridge] What is important in RBridge version 1.0?
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, 03 May 2007 18:04:03 -0000
Status: RO
Content-Length: 3873

Joe,

The current draft does not define the term flow and IMHO MUST not define
it.
IS-IS, OSPF, FSPS, etc enable load balancing, but do not specify the
granularity of load balancing, the number of path and the path selection
algorithm. These are product features.

Many commercial products allow to configure round robin, source only,
source-dest pair, five tuple load balancing.

-- Silvano


> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Thursday, May 03, 2007 10:12 AM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: Re: [rbridge] What is important in RBridge version 1.0?
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> >
> > "multipath", which, as you say, presumes multiple concurrent paths
is
> > the main reason for TRILL.
> 
> Different traffic (i.e., different flows) using different paths
> concurrently is the main reason for TRILL.
> 
> Multipath - as I understand how the term is typically used in the IETF
-
> is a way for the same traffic (i.e., a single flow) to use multiple
> paths concurrently. That is NOT a primary reason for TRILL, though, if
> ISIS provides it already that's fine. I wouldn't list it as a primary
> issue, though.
> 
> Besides, isn't the PAS supposed to list these (and doesn't it, to some
> extent?)
> 
> Joe
> 
> >
> > We don't need to do anything in the standard, since ISIS allows the
> > computation of multiple concurrent paths. It is up to the product to
> > decide how many path they will support, exactly as it happens in
> > routers.
> >
> > More inline
> >
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[e-mail]]
> >> Sent: Thursday, May 03, 2007 9:02 AM
> >> To: Silvano Gai
> >> Cc: [e-mail]
> >> Subject: Re: [rbridge] What is important in RBridge version 1.0?
> >>
> >>
> >>
> >> Silvano Gai wrote:
> >>> The current discussion of TTL/broadcast storm/etc made me think
what
> > is
> >>> important in TRILL version 1.0 and what can be delayed to version
> > 2.0 or
> >>> dealt with in separate documents.
> >>>
> >>> Here is my list:
> >>>
> >>> 1) excellent support for shortest path/multipath
> >>>    * core instance of IS-IS
> >>>    * nickname assignments
> >>>    * DR election
> >> Different paths yes, but not "multipath", which presumes multiple
> >> concurrent paths.
> >>
> >>> 2) A super stable frame format, so that companies may start to
code
> >>> their ASIC
> >> Always (in all versions, IMO).
> >>
> >>> 3) Broadcast storm suppression
> >> Avoidance. I might include loop avoidance here.
> >>
> > agreed
> >
> >>>    * Radia RPF proposal
> >> TTL to break forwarding loops.
> > agreed
> >
> >> Existing spanning tree (as much as possible) to avoid broadcast
loops.
> >
> > Are you speaking of Spanning Tree or Spanning Tree Protocol?
> >
> >> No *new* protocols unless absolutely necessary.
> >>
> >>> 4) learning from data traffic (backward learning as bridges do)
> >>>
> >>> 5) Spanning Tree interoperability at the edges
> >>>    * simple form, receiving BPDUs only
> >>>
> >>> 6) A last call no later than the end of the year.
> >>>
> >>> I propose we focus our discussion on these points without which we
> > don't
> >>> have a viable standard.
> >>>
> >>>
> >>> Let's delay/move to other documents:
> >> Agreed on all below.
> >>
> > I am glad
> >
> > -- Silvano
> >
> >>> 1) ARP/ND proxy
> >>>
> >>> 2) per VLAN IS-IS instance
> >>>
> >>> 3) IGMP learning
> >>>
> >>> What do you think?
> >>>
> >>> -- Silvano
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> rbridge mailing list
> >>> [e-mail]
> >>> http://mailman.postel.org/mailman/listinfo/rbridge
> >> --
> >> ----------------------------------------
> >> Joe Touch
> >> Sr. Network Engineer, USAF TSAT Space Segment
> >
> 
> --
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment




Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43HCv5q010768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 10:12:57 -0700 (PDT)
Received: from [127.0.0.1] (112.sub-75-215-214.myvzw.com [75.215.214.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l43HCaLU005043; Thu, 3 May 2007 10:12:39 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 03 May 2007 10:12:16 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9750E9C085C8FD51B1EECB62"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] What is important in RBridge version 1.0?
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, 03 May 2007 17:13:39 -0000
Status: RO
Content-Length: 3757

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9750E9C085C8FD51B1EECB62
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Silvano Gai wrote:
> Joe,
>=20
> "multipath", which, as you say, presumes multiple concurrent paths is
> the main reason for TRILL.

Different traffic (i.e., different flows) using different paths
concurrently is the main reason for TRILL.

Multipath - as I understand how the term is typically used in the IETF -
is a way for the same traffic (i.e., a single flow) to use multiple
paths concurrently. That is NOT a primary reason for TRILL, though, if
ISIS provides it already that's fine. I wouldn't list it as a primary
issue, though.

Besides, isn't the PAS supposed to list these (and doesn't it, to some
extent?)

Joe

>=20
> We don't need to do anything in the standard, since ISIS allows the
> computation of multiple concurrent paths. It is up to the product to
> decide how many path they will support, exactly as it happens in
> routers.
>=20
> More inline
>=20
>=20
>> -----Original Message-----
>> From: Joe Touch [mailto:[e-mail]]
>> Sent: Thursday, May 03, 2007 9:02 AM
>> To: Silvano Gai
>> Cc: [e-mail]
>> Subject: Re: [rbridge] What is important in RBridge version 1.0?
>>
>>
>>
>> Silvano Gai wrote:
>>> The current discussion of TTL/broadcast storm/etc made me think what
> is
>>> important in TRILL version 1.0 and what can be delayed to version
> 2.0 or
>>> dealt with in separate documents.
>>>
>>> Here is my list:
>>>
>>> 1) excellent support for shortest path/multipath
>>>    * core instance of IS-IS
>>>    * nickname assignments
>>>    * DR election
>> Different paths yes, but not "multipath", which presumes multiple
>> concurrent paths.
>>
>>> 2) A super stable frame format, so that companies may start to code
>>> their ASIC
>> Always (in all versions, IMO).
>>
>>> 3) Broadcast storm suppression
>> Avoidance. I might include loop avoidance here.
>>
> agreed
>=20
>>>    * Radia RPF proposal
>> TTL to break forwarding loops.
> agreed
>=20
>> Existing spanning tree (as much as possible) to avoid broadcast loops.=

>=20
> Are you speaking of Spanning Tree or Spanning Tree Protocol?
>=20
>> No *new* protocols unless absolutely necessary.
>>
>>> 4) learning from data traffic (backward learning as bridges do)
>>>
>>> 5) Spanning Tree interoperability at the edges
>>>    * simple form, receiving BPDUs only
>>>
>>> 6) A last call no later than the end of the year.
>>>
>>> I propose we focus our discussion on these points without which we
> don't
>>> have a viable standard.
>>>
>>>
>>> Let's delay/move to other documents:
>> Agreed on all below.
>>
> I am glad
>=20
> -- Silvano
>=20
>>> 1) ARP/ND proxy
>>>
>>> 2) per VLAN IS-IS instance
>>>
>>> 3) IGMP learning
>>>
>>> What do you think?
>>>
>>> -- Silvano
>>>
>>>
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>> --
>> ----------------------------------------
>> Joe Touch
>> Sr. Network Engineer, USAF TSAT Space Segment
>=20

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


--------------enig9750E9C085C8FD51B1EECB62
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOhfxE5f5cImnZrsRAjInAKDHQBU515SevRwLTAUMqq+1E5muSQCfbcC3
QHwb422T8h4UbwU+Cm1Sw/Q=
=l9n8
-----END PGP SIGNATURE-----

--------------enig9750E9C085C8FD51B1EECB62--



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 l43Gti58005029 for <[e-mail]>; Thu, 3 May 2007 09:55: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: Thu, 3 May 2007 09:55:39 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] What is important in RBridge version 1.0?
Thread-Index: AceNnJwLUO8cUGp7SWqP5PzT0Zqj0QABpGWQ
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Joe Touch" <[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 l43Gti58005029
Cc: [e-mail]
Subject: Re: [rbridge] What is important in RBridge version 1.0?
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, 03 May 2007 16:55:59 -0000
Status: RO
Content-Length: 2365

Joe,

"multipath", which, as you say, presumes multiple concurrent paths is
the main reason for TRILL.

We don't need to do anything in the standard, since ISIS allows the
computation of multiple concurrent paths. It is up to the product to
decide how many path they will support, exactly as it happens in
routers.

More inline


> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Thursday, May 03, 2007 9:02 AM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: Re: [rbridge] What is important in RBridge version 1.0?
> 
> 
> 
> Silvano Gai wrote:
> > The current discussion of TTL/broadcast storm/etc made me think what
is
> > important in TRILL version 1.0 and what can be delayed to version
2.0 or
> > dealt with in separate documents.
> >
> > Here is my list:
> >
> > 1) excellent support for shortest path/multipath
> >    * core instance of IS-IS
> >    * nickname assignments
> >    * DR election
> 
> Different paths yes, but not "multipath", which presumes multiple
> concurrent paths.
> 
> > 2) A super stable frame format, so that companies may start to code
> > their ASIC
> 
> Always (in all versions, IMO).
> 
> > 3) Broadcast storm suppression
> 
> Avoidance. I might include loop avoidance here.
> 
agreed

> >    * Radia RPF proposal
> 
> TTL to break forwarding loops.
agreed

> 
> Existing spanning tree (as much as possible) to avoid broadcast loops.

Are you speaking of Spanning Tree or Spanning Tree Protocol?

> 
> No *new* protocols unless absolutely necessary.
> 
> > 4) learning from data traffic (backward learning as bridges do)
> >
> > 5) Spanning Tree interoperability at the edges
> >    * simple form, receiving BPDUs only
> >
> > 6) A last call no later than the end of the year.
> >
> > I propose we focus our discussion on these points without which we
don't
> > have a viable standard.
> >
> >
> > Let's delay/move to other documents:
> 
> Agreed on all below.
> 
I am glad

-- Silvano

> >
> > 1) ARP/ND proxy
> >
> > 2) per VLAN IS-IS instance
> >
> > 3) IGMP learning
> >
> > What do you think?
> >
> > -- Silvano
> >
> >
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> --
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment




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 l43Go8xr002848 for <[e-mail]>; Thu, 3 May 2007 09:50:08 -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, 3 May 2007 09:50:01 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNEuipY89iFdfYTeqiNXtq7pBphAAACLPQAB9m2YAAAIr04AAAPsZwAAENq9AAAKnRIAACD7dQ
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: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[e-mail]>, "Joe Touch" <[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 l43Go8xr002848
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 16:50:34 -0000
Status: RO
Content-Length: 7160

Eric,

I should have said that Radia presented it in Prague and on the mailing
list as a feature to add while going from draft 03 to draft 04

-- Silvano

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> Sent: Thursday, May 03, 2007 8:53 AM
> To: Silvano Gai; Joe Touch
> Cc: Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Setting initial "hop count" value
> 
> Silvano,
> 
> 	Sorry for the confusion, but did you not say (below)
> that it is an addendum to version -03 of the protocol draft?
> 
> Thanks!
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Thursday, May 03, 2007 11:32 AM
> > To: Eric Gray (LO/EUS); Joe Touch
> > Cc: Radia Perlman; [e-mail]
> > Subject: RE: [rbridge] Setting initial "hop count" value
> > Importance: High
> >
> >
> > The RPF proposal is NOT in the current draft, since it is not
agreed.
> >
> > -- Silvano
> >
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > Sent: Thursday, May 03, 2007 8:17 AM
> > > To: Silvano Gai; Joe Touch
> > > Cc: Radia Perlman; [e-mail]
> > > Subject: RE: [rbridge] Setting initial "hop count" value
> > >
> > > Silvano,
> > >
> > > 	What is in the current draft represents a process anomaly.
> > >
> > > 	As you said, the RPF proposal has not been agreed to, and
> > > should not - therefore - have been added to a working group draft.
> > >
> > > 	The proposal to simply use (some form of) spanning tree is
> > > not new either, particularly in relationship to multi-destination
> > > distribution.
> > >
> > > Thanks!
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Thursday, May 03, 2007 10:58 AM
> > > > To: Eric Gray (LO/EUS); Joe Touch
> > > > Cc: Radia Perlman; [e-mail]
> > > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > > Importance: High
> > > >
> > > > Eric,
> > > >
> > > > > -----Original Message-----
> > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > Sent: Thursday, May 03, 2007 7:48 AM
> > > > > To: Silvano Gai; Joe Touch
> > > > > Cc: Radia Perlman; [e-mail]
> > > > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > > >
> > > > > Silvano,
> > > > >
> > > > > 	I am clearly missing part of these discussions,
> > and I doubt
> > > > > I am alone in doing so.
> > > > >
> > > > > 	First, what exactly is the "Radia RPF" proposal that you
> > > > > mention in another thread of discussion, that you also say is
> > > > > both "unproven" and "not agreed" to, AND why would we use that
> > > > > in lieue of some form of existing spanning tree protocol for
> > > > > the multi-destination case?
> > > > >
> > > >
> > > > I have resend her proposal to the mailing list in a separate
> > > > email. You
> > > > may want to go back and read the comments of Dino and Sanjaya.
> > > >
> > > >
> > > > > 	And, second, I was under the strong impression we were
> > > > > not planning to use SPF routing for the multi-destination
case.
> > > > > Is that part of the "Radia RPF" proposal?
> > > > >
> > > >
> > > > Radia proposal is an addendum to
> > > > http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-p
> > > > rotocol-03
> > > > .txt
> > > >
> > > > That states:
> > > >
> > > > 3.4.1. Distribution Tree Calculation
> > > >
> > > >    RBridges do not use the spanning tree protocol to calculate
> > > >    distribution trees. Instead, distribution trees are
> > > > calculated based
> > > >    on the link state information, selecting a particular
> > > > RBridge as the
> > > >    root.
> > > >
> > > >    Calculation of a tree rooted at Ri is done
> > independently by each
> > > >    RBridge Rn by performing the SPF (Shortest Path First)
> > calculation
> > > >    with Ri as the root without requiring any additional
> > exchange of
> > > >    information.
> > > >
> > > >
> > > > > 	Given that (M/R)STP is a proven - loop free - technique
> > > > > for handling loop prevention in multi-destination traffic for
> > > > > L2 forwarding, AND that we're not as much concerned about the
> > > > > use of SPF routing for the multi-destination case, _why_ would
> > > > > we want to invent some other technique for setting up spanning
> > > > > trees?
> > > >
> > > > What you are proposing is different of what is in the
> > current draft.
> > > >
> > > > -- Silvano
> > > >
> > > >
> > > >
> > > > >
> > > > > Thanks!
> > > > >
> > > > > --
> > > > > Eric Gray
> > > > > Principal Engineer
> > > > > Ericsson
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > > Sent: Wednesday, May 02, 2007 7:42 PM
> > > > > > To: Joe Touch
> > > > > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > > > >
> > > > > > Joe,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Joe Touch [mailto:[e-mail]]
> > > > > > > Sent: Wednesday, May 02, 2007 4:37 PM
> > > > > > > To: Silvano Gai
> > > > > > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > > > > Subject: Re: [rbridge] Setting initial "hop count" value
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Silvano Gai wrote:
> > > > > > > > Joe,
> > > > > > > ...
> > > > > > > > It is a doomsday scenario: if you have seen a broadcast
> > storm
> > > > you
> > > > > > don't
> > > > > > > > want to see another one.
> > > > > > > >
> > > > > > > > Granted there are measure that have been put in place to
> > limit
> > > > the
> > > > > > > > possibility that this happens, for example today bridges
> > have
> > > > > > separate
> > > > > > > > queues for BPDUs, but we still need to be
> > EXTREMELY careful
> > > > > > >
> > > > > > > All great reasons for not relying on TTLs to bail you out
> > > > > > of a storm.
> > > > > > A
> > > > > > > TTL of N can result in K^N/J copies if it loops through
just
> > one
> > > > > > > replication point with K outputs with a loop length of J.
> > Given
> > > > loop
> > > > > > > lengths could be 2-3, what TTL is reasonable to prevent
> > > > this sort
> > > > of
> > > > > > > blowup that isn't going to impact the reachability
diameter?
> > > > > > >
> > > > > > > Current ethernet relies on spanning tree to avoid this;
> > > > why not -
> > > > as
> > > > > > we
> > > > > > > originally discussed - rely on spanning tree for
broadcasts
> > and
> > > > > > > multicasts and then this ceases to be an issue...?
> > > > > > >
> > > > > >
> > > > > > You miss one point.
> > > > > >
> > > > > > The Spanning Tree Protocol has an interlock mechanism that
> > > > ABSOLUTELY
> > > > > > guarantees no transient loops.
> > > > > >
> > > > > > A Spanning Tree based on an ISIS database will not have this
> > > > interlock
> > > > > > mechanism and transient loops will be possible.
> > > > > >
> > > > > > -- Silvano
> > > > > >
> > > >
> >



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43GQp7o024128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 09:26:51 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l43GQBC4028047; Thu, 3 May 2007 11:26:11 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 3 May 2007 11:26:46 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 3 May 2007 11:26:43 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNE7n/0RQ0UyQ3SXm+IM/xanRYBgAACbpQAB+brMAAAE5RYAAALQrgAAEI26AAAPew0A==
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: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Joe Touch" <[e-mail]>
X-OriginalArrivalTime: 03 May 2007 16:26:46.0571 (UTC) FILETIME=[D7F347B0:01C78D9F]
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 l43GQp7o024128
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 16:27:06 -0000
Status: RO
Content-Length: 8895

Silvano,

	I did some looking, and you are correct.  I mentioned it to
Radia in an off-line discussion on November 1st of last year, in
response to her proposal to make distribution trees bi-directional.  
The discussion was not meant to be off-line, but Radia had excluded
the list in one of her replies.

	I extracted that part of the conversation below.

	Even assuming this was not publicly mentioned previously,
is there a flaw in the argument I made to you just now?

	Possibly I made the mistake of thinking that - because the
argument is inescapably obvious to me - then it must be equally
obvious to the rest of the working group.

	It is worth noting that several of the replies on that thread
("Compromise proposal---allowing tradeoff between computation and 
optimality of delivery") seemed (to me, at least) to assume the use
of STP.

On November 1st, at 3:35 P.M. (EST), Radia Perlman said:
--> I'm talking about a bidirectional tree. Just like with the 
--> spanning tree computed by legacy bridges, packets don't 
--> traverse links twice. A particular bridge B has a root 
--> port and other ports for which it is DB.
--> On the ports for which B is DB, B sends the frame and it 
--> travels further from the root on those paths.
--> It's only on the root port that the frame travels towards 
--> the root, and then when the root receives the frame, it 
--> only sends the frame onto other ports (not the one it got
--> it from).

To which I responded (at 4:43 P.M. of the same day):
->	Is this not a fundamental departure from how Ingress RBridge
-> Trees are expected to work?  My understanding was that an IRT 
-> is uni-directional.
->
->	Also, how does this work in the broadcast/multicast case -
-> unless we are in fact using STP (or a variation of STP)?  If
-> the tree is bi-directional, how does a node on the tree know
-> how to forward flooded traffic without potentially producing
-> a storm?
->
->	If we are in fact using a variation of STP to set up the 
-> shared IRT, how does this differ from existing proposals in
-> the IEEE?

I never received a reply to this note, but Radia did later reply
to Donald Eastlake on the same subject (including the list - see
her post on Sat 11/4/2006 6:23 PM, EST).




Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Thursday, May 03, 2007 11:36 AM
> To: Eric Gray (LO/EUS); Joe Touch
> Cc: Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Setting initial "hop count" value
> Importance: High
> 
> Eric,
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > Sent: Thursday, May 03, 2007 8:16 AM
> > To: Silvano Gai; Joe Touch
> > Cc: Radia Perlman; [e-mail]
> > Subject: RE: [rbridge] Setting initial "hop count" value
> > 
> > Silvano,
> > 
> > 	That was true, right up until the proposal was made to make
> > the trees bi-directional.  That - in turn was necessitated by the
> > proposal to allow some edge RBridges to opt-out of sourcing their
> > own distribution trees.  At that point, more than a few people
> > started to think that we were then abandoning the use of SPF for
> > the multi-destination case.
> > 
> 
> During that discussion I never read anybody proposing to use the
> Spanning Tree Protocol.
> 
> -- Silvano
> 
> > 	The rationale for thinking that is really quite obvious.
> > 
> > 	Note that - if you assume a tree computed with X as root,
> > spanning tree protocol effectively sets up a tree with X as root
> > and shortest paths computed from X to all leaf bridges.
> > 
> > 	If you assume a bi-directional tree computed with X as root
> > - even if computed explicitly using SPF routing - that tree is the
> > shortest path from one leaf to another only by a happy accident in
> > some cases and NOT at all in all other cases.
> > 
> > 	If using a bi-directional spanning tree means essentially
> > abandoning SPF routing, then the advantage you might hope to get
> > from not using (M/R)STP vanishes in a puff of smoke in comparison
> > with the cost we can expect to pay to develop an alternative, and
> > (eventually) make it work.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Thursday, May 03, 2007 11:03 AM
> > > To: Eric Gray (LO/EUS); Joe Touch
> > > Cc: Radia Perlman; [e-mail]
> > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > Importance: High
> > >
> > >
> > > Eric,
> > >
> > > From when I joined this WG all the base protocol drafts 
> have always
> > > assumed that TRILL was using IS-IS to compute what we now call
> > > "Distribution Trees". We changed the names from "source
> > > routed tree" to
> > > "distribution tree" and the number of these trees, but 
> never the way
> > > they were computed.
> > >
> > > -- Silvano
> > >
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > Sent: Thursday, May 03, 2007 7:54 AM
> > > > To: Silvano Gai; Joe Touch
> > > > Cc: Radia Perlman; [e-mail]
> > > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > >
> > > > Silvano,
> > > >
> > > > 	Same question applies here.  It's one thing to 
> say that we
> > > > don't run STP in the conventional bridging sense.  We don't run
> > > > IS-IS in the conventional IP (or OSI) routing sense, either.  It
> > > > is quite another to say that we don't use an existing spanning
> > > > tree protocol (perhaps with different BPDUs - e.g. - RBPDUs) and
> > > > gain all of the advantages of existing implementation, and field
> > > > deployment experience associated with it.
> > > >
> > > > 	Are you (and probably Joe) saying that we want to invent
> > > > something new here?
> > > >
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson
> > > >
> > > > > -----Original Message-----
> > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > Sent: Wednesday, May 02, 2007 7:47 PM
> > > > > To: Joe Touch
> > > > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > > >
> > > > > Joe
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Joe Touch [mailto:[e-mail]]
> > > > > > Sent: Wednesday, May 02, 2007 4:43 PM
> > > > > > To: Silvano Gai
> > > > > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > > > Subject: Re: [rbridge] Setting initial "hop count" value
> > > > > >
> > > > > >
> > > > > >
> > > > > > Silvano Gai wrote:
> > > > > > > Joe,
> > > > > > ...
> > > > > > >>> Loops are much more dangerous at layer 2 than at
> > > layer 3. I am
> > > > > > >>> sympathetic with Radia that anything we can do to
> > > > > mitigate them is
> > > > > > > good.
> > > > > > >> This is why we ought to be using a spanning tree 
> for those,
> > > > > > >
> > > > > > > You are not claiming that we need to run the Spanning
> > > > > Tree Protocol,
> > > > > > > correct?
> > > > > >
> > > > > > No; I was claiming that there's a legitimate reason to
> > > still have
> > > a
> > > > > > spanning tree inside the campus.
> > > > > >
> > > > >
> > > > > Agreed, we are in synch.
> > > > >
> > > > > > > and let that
> > > > > > >> tree be suboptimal and/or converge via means that
> > > avoid looping
> > > > > > >> transients.
> > > > > > >
> > > > > > > This is not easy. Radia RPF proposal seems a good start,
> > > > > but it is:
> > > > > > > - not agreed yet
> > > > > > > - Unproven
> > > > > > >
> > > > > > > It is pretty straightforward to use Radia RPF proposal to
> > > > > reduce the
> > > > > > > probability of transient loops. If you want to
> > > "GUARANTEE" that
> > > > > there
> > > > > > > are no transient loops, that is a different story,
> > > since it has
> > > a
> > > > > > > significant state requirement that can impact low end
> > > > > implementation. I
> > > > > > > am all for it, but we need to discuss it in a separate
> thread.
> > > > > >
> > > > > > Agreed; I'm not convinced that such transients aren't OK if
> > > > > they exist
> > > > > > with conventional implementations.
> > > > >
> > > > > They don't. Today the Spanning Tree protocol never generates
> > > > > a transient
> > > > > loop.
> > > > >
> > > > > -- Silvano
> > > > >
> > > > > Remember that rbridges aren't
> > > > > > intended to scale beyond current implementations, which
> > > means that
> > > > > > however existing implementations support spanning trees and
> deal
> > > (or
> > > > > > don't) with transient loops should map here just fine.
> > > > > >
> > > > > > Joe
> > > > > > --
> > > > > > ----------------------------------------
> > > > > > Joe Touch
> > > > > > Sr. Network Engineer, USAF TSAT Space Segment
> > > > >
> > > > >
> > >
> 



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43G38wI015982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 09:03:08 -0700 (PDT)
Received: from [127.0.0.1] (112.sub-75-215-214.myvzw.com [75.215.214.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l43G2dDc019159; Thu, 3 May 2007 09:02:58 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 03 May 2007 09:02:20 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8F19746AA6065BF19EB8B5CF"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] What is important in RBridge version 1.0?
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, 03 May 2007 16:03:32 -0000
Status: RO
Content-Length: 2323

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig8F19746AA6065BF19EB8B5CF
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Silvano Gai wrote:
> The current discussion of TTL/broadcast storm/etc made me think what is=

> important in TRILL version 1.0 and what can be delayed to version 2.0 o=
r
> dealt with in separate documents.
>=20
> Here is my list:
>=20
> 1) excellent support for shortest path/multipath
>    * core instance of IS-IS
>    * nickname assignments
>    * DR election

Different paths yes, but not "multipath", which presumes multiple
concurrent paths.

> 2) A super stable frame format, so that companies may start to code
> their ASIC

Always (in all versions, IMO).

> 3) Broadcast storm suppression

Avoidance. I might include loop avoidance here.

>    * Radia RPF proposal

TTL to break forwarding loops.

Existing spanning tree (as much as possible) to avoid broadcast loops.

No *new* protocols unless absolutely necessary.

> 4) learning from data traffic (backward learning as bridges do)
>=20
> 5) Spanning Tree interoperability at the edges
>    * simple form, receiving BPDUs only
>=20
> 6) A last call no later than the end of the year.
>=20
> I propose we focus our discussion on these points without which we don'=
t
> have a viable standard.
>=20
>=20
> Let's delay/move to other documents:

Agreed on all below.

>=20
> 1) ARP/ND proxy
>=20
> 2) per VLAN IS-IS instance
>=20
> 3) IGMP learning
>=20
> What do you think?
>=20
> -- Silvano
>=20
>=20
>=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge

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


--------------enig8F19746AA6065BF19EB8B5CF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOgeME5f5cImnZrsRAsqJAKCCCggQ7AEynx6ohclHhYn9Ue0o7ACeJYiV
l9bXW9PdEGq/hIRcuXNDuvg=
=01P3
-----END PGP SIGNATURE-----

--------------enig8F19746AA6065BF19EB8B5CF--



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43Fr1xW012040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 08:53:01 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l43Frwl3029897; Thu, 3 May 2007 10:53:58 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 3 May 2007 10:52:59 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 3 May 2007 10:52:56 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNEuipY89iFdfYTeqiNXtq7pBphAAACLPQAB9m2YAAAIr04AAAPsZwAAENq9AAAKnRIA==
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: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Joe Touch" <[e-mail]>
X-OriginalArrivalTime: 03 May 2007 15:52:59.0269 (UTC) FILETIME=[1F958B50:01C78D9B]
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 l43Fr1xW012040
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 15:53:31 -0000
Status: RO
Content-Length: 6349

Silvano,

	Sorry for the confusion, but did you not say (below)
that it is an addendum to version -03 of the protocol draft?

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Thursday, May 03, 2007 11:32 AM
> To: Eric Gray (LO/EUS); Joe Touch
> Cc: Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Setting initial "hop count" value
> Importance: High
> 
> 
> The RPF proposal is NOT in the current draft, since it is not agreed.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > Sent: Thursday, May 03, 2007 8:17 AM
> > To: Silvano Gai; Joe Touch
> > Cc: Radia Perlman; [e-mail]
> > Subject: RE: [rbridge] Setting initial "hop count" value
> > 
> > Silvano,
> > 
> > 	What is in the current draft represents a process anomaly.
> > 
> > 	As you said, the RPF proposal has not been agreed to, and
> > should not - therefore - have been added to a working group draft.
> > 
> > 	The proposal to simply use (some form of) spanning tree is
> > not new either, particularly in relationship to multi-destination
> > distribution.
> > 
> > Thanks!
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Thursday, May 03, 2007 10:58 AM
> > > To: Eric Gray (LO/EUS); Joe Touch
> > > Cc: Radia Perlman; [e-mail]
> > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > Importance: High
> > >
> > > Eric,
> > >
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > Sent: Thursday, May 03, 2007 7:48 AM
> > > > To: Silvano Gai; Joe Touch
> > > > Cc: Radia Perlman; [e-mail]
> > > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > >
> > > > Silvano,
> > > >
> > > > 	I am clearly missing part of these discussions, 
> and I doubt
> > > > I am alone in doing so.
> > > >
> > > > 	First, what exactly is the "Radia RPF" proposal that you
> > > > mention in another thread of discussion, that you also say is
> > > > both "unproven" and "not agreed" to, AND why would we use that
> > > > in lieue of some form of existing spanning tree protocol for
> > > > the multi-destination case?
> > > >
> > >
> > > I have resend her proposal to the mailing list in a separate
> > > email. You
> > > may want to go back and read the comments of Dino and Sanjaya.
> > >
> > >
> > > > 	And, second, I was under the strong impression we were
> > > > not planning to use SPF routing for the multi-destination case.
> > > > Is that part of the "Radia RPF" proposal?
> > > >
> > >
> > > Radia proposal is an addendum to
> > > http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-p
> > > rotocol-03
> > > .txt
> > >
> > > That states:
> > >
> > > 3.4.1. Distribution Tree Calculation
> > >
> > >    RBridges do not use the spanning tree protocol to calculate
> > >    distribution trees. Instead, distribution trees are
> > > calculated based
> > >    on the link state information, selecting a particular
> > > RBridge as the
> > >    root.
> > >
> > >    Calculation of a tree rooted at Ri is done 
> independently by each
> > >    RBridge Rn by performing the SPF (Shortest Path First)
> calculation
> > >    with Ri as the root without requiring any additional 
> exchange of
> > >    information.
> > >
> > >
> > > > 	Given that (M/R)STP is a proven - loop free - technique
> > > > for handling loop prevention in multi-destination traffic for
> > > > L2 forwarding, AND that we're not as much concerned about the
> > > > use of SPF routing for the multi-destination case, _why_ would
> > > > we want to invent some other technique for setting up spanning
> > > > trees?
> > >
> > > What you are proposing is different of what is in the 
> current draft.
> > >
> > > -- Silvano
> > >
> > >
> > >
> > > >
> > > > Thanks!
> > > >
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson
> > > >
> > > > > -----Original Message-----
> > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > Sent: Wednesday, May 02, 2007 7:42 PM
> > > > > To: Joe Touch
> > > > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > > >
> > > > > Joe,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Joe Touch [mailto:[e-mail]]
> > > > > > Sent: Wednesday, May 02, 2007 4:37 PM
> > > > > > To: Silvano Gai
> > > > > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > > > Subject: Re: [rbridge] Setting initial "hop count" value
> > > > > >
> > > > > >
> > > > > >
> > > > > > Silvano Gai wrote:
> > > > > > > Joe,
> > > > > > ...
> > > > > > > It is a doomsday scenario: if you have seen a broadcast
> storm
> > > you
> > > > > don't
> > > > > > > want to see another one.
> > > > > > >
> > > > > > > Granted there are measure that have been put in place to
> limit
> > > the
> > > > > > > possibility that this happens, for example today bridges
> have
> > > > > separate
> > > > > > > queues for BPDUs, but we still need to be 
> EXTREMELY careful
> > > > > >
> > > > > > All great reasons for not relying on TTLs to bail you out
> > > > > of a storm.
> > > > > A
> > > > > > TTL of N can result in K^N/J copies if it loops through just
> one
> > > > > > replication point with K outputs with a loop length of J.
> Given
> > > loop
> > > > > > lengths could be 2-3, what TTL is reasonable to prevent
> > > this sort
> > > of
> > > > > > blowup that isn't going to impact the reachability diameter?
> > > > > >
> > > > > > Current ethernet relies on spanning tree to avoid this;
> > > why not -
> > > as
> > > > > we
> > > > > > originally discussed - rely on spanning tree for broadcasts
> and
> > > > > > multicasts and then this ceases to be an issue...?
> > > > > >
> > > > >
> > > > > You miss one point.
> > > > >
> > > > > The Spanning Tree Protocol has an interlock mechanism that
> > > ABSOLUTELY
> > > > > guarantees no transient loops.
> > > > >
> > > > > A Spanning Tree based on an ISIS database will not have this
> > > interlock
> > > > > mechanism and transient loops will be possible.
> > > > >
> > > > > -- Silvano
> > > > >
> > >
> 



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 l43FZcDx006226 for <[e-mail]>; Thu, 3 May 2007 08:35:38 -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, 3 May 2007 08:35:33 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNE7n/0RQ0UyQ3SXm+IM/xanRYBgAACbpQAB+brMAAAE5RYAAALQrgAAEI26A=
References: <[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: "Eric Gray \(LO/EUS\)" <[e-mail]>, "Joe Touch" <[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 l43FZcDx006226
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 15:35:59 -0000
Status: RO
Content-Length: 5950

Eric,

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> Sent: Thursday, May 03, 2007 8:16 AM
> To: Silvano Gai; Joe Touch
> Cc: Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Setting initial "hop count" value
> 
> Silvano,
> 
> 	That was true, right up until the proposal was made to make
> the trees bi-directional.  That - in turn was necessitated by the
> proposal to allow some edge RBridges to opt-out of sourcing their
> own distribution trees.  At that point, more than a few people
> started to think that we were then abandoning the use of SPF for
> the multi-destination case.
> 

During that discussion I never read anybody proposing to use the
Spanning Tree Protocol.

-- Silvano

> 	The rationale for thinking that is really quite obvious.
> 
> 	Note that - if you assume a tree computed with X as root,
> spanning tree protocol effectively sets up a tree with X as root
> and shortest paths computed from X to all leaf bridges.
> 
> 	If you assume a bi-directional tree computed with X as root
> - even if computed explicitly using SPF routing - that tree is the
> shortest path from one leaf to another only by a happy accident in
> some cases and NOT at all in all other cases.
> 
> 	If using a bi-directional spanning tree means essentially
> abandoning SPF routing, then the advantage you might hope to get
> from not using (M/R)STP vanishes in a puff of smoke in comparison
> with the cost we can expect to pay to develop an alternative, and
> (eventually) make it work.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Thursday, May 03, 2007 11:03 AM
> > To: Eric Gray (LO/EUS); Joe Touch
> > Cc: Radia Perlman; [e-mail]
> > Subject: RE: [rbridge] Setting initial "hop count" value
> > Importance: High
> >
> >
> > Eric,
> >
> > From when I joined this WG all the base protocol drafts have always
> > assumed that TRILL was using IS-IS to compute what we now call
> > "Distribution Trees". We changed the names from "source
> > routed tree" to
> > "distribution tree" and the number of these trees, but never the way
> > they were computed.
> >
> > -- Silvano
> >
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > Sent: Thursday, May 03, 2007 7:54 AM
> > > To: Silvano Gai; Joe Touch
> > > Cc: Radia Perlman; [e-mail]
> > > Subject: RE: [rbridge] Setting initial "hop count" value
> > >
> > > Silvano,
> > >
> > > 	Same question applies here.  It's one thing to say that we
> > > don't run STP in the conventional bridging sense.  We don't run
> > > IS-IS in the conventional IP (or OSI) routing sense, either.  It
> > > is quite another to say that we don't use an existing spanning
> > > tree protocol (perhaps with different BPDUs - e.g. - RBPDUs) and
> > > gain all of the advantages of existing implementation, and field
> > > deployment experience associated with it.
> > >
> > > 	Are you (and probably Joe) saying that we want to invent
> > > something new here?
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Wednesday, May 02, 2007 7:47 PM
> > > > To: Joe Touch
> > > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > >
> > > > Joe
> > > >
> > > > > -----Original Message-----
> > > > > From: Joe Touch [mailto:[e-mail]]
> > > > > Sent: Wednesday, May 02, 2007 4:43 PM
> > > > > To: Silvano Gai
> > > > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > > Subject: Re: [rbridge] Setting initial "hop count" value
> > > > >
> > > > >
> > > > >
> > > > > Silvano Gai wrote:
> > > > > > Joe,
> > > > > ...
> > > > > >>> Loops are much more dangerous at layer 2 than at
> > layer 3. I am
> > > > > >>> sympathetic with Radia that anything we can do to
> > > > mitigate them is
> > > > > > good.
> > > > > >> This is why we ought to be using a spanning tree for those,
> > > > > >
> > > > > > You are not claiming that we need to run the Spanning
> > > > Tree Protocol,
> > > > > > correct?
> > > > >
> > > > > No; I was claiming that there's a legitimate reason to
> > still have
> > a
> > > > > spanning tree inside the campus.
> > > > >
> > > >
> > > > Agreed, we are in synch.
> > > >
> > > > > > and let that
> > > > > >> tree be suboptimal and/or converge via means that
> > avoid looping
> > > > > >> transients.
> > > > > >
> > > > > > This is not easy. Radia RPF proposal seems a good start,
> > > > but it is:
> > > > > > - not agreed yet
> > > > > > - Unproven
> > > > > >
> > > > > > It is pretty straightforward to use Radia RPF proposal to
> > > > reduce the
> > > > > > probability of transient loops. If you want to
> > "GUARANTEE" that
> > > > there
> > > > > > are no transient loops, that is a different story,
> > since it has
> > a
> > > > > > significant state requirement that can impact low end
> > > > implementation. I
> > > > > > am all for it, but we need to discuss it in a separate
thread.
> > > > >
> > > > > Agreed; I'm not convinced that such transients aren't OK if
> > > > they exist
> > > > > with conventional implementations.
> > > >
> > > > They don't. Today the Spanning Tree protocol never generates
> > > > a transient
> > > > loop.
> > > >
> > > > -- Silvano
> > > >
> > > > Remember that rbridges aren't
> > > > > intended to scale beyond current implementations, which
> > means that
> > > > > however existing implementations support spanning trees and
deal
> > (or
> > > > > don't) with transient loops should map here just fine.
> > > > >
> > > > > Joe
> > > > > --
> > > > > ----------------------------------------
> > > > > Joe Touch
> > > > > Sr. Network Engineer, USAF TSAT Space Segment
> > > >
> > > >
> >



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 l43FVctO004938 for <[e-mail]>; Thu, 3 May 2007 08:31:38 -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, 3 May 2007 08:31:34 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNEuipY89iFdfYTeqiNXtq7pBphAAACLPQAB9m2YAAAIr04AAAPsZwAAENq9A=
References: <[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: "Eric Gray \(LO/EUS\)" <[e-mail]>, "Joe Touch" <[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 l43FVctO004938
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 15:31:58 -0000
Status: RO
Content-Length: 5508

The RPF proposal is NOT in the current draft, since it is not agreed.

-- Silvano

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> Sent: Thursday, May 03, 2007 8:17 AM
> To: Silvano Gai; Joe Touch
> Cc: Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Setting initial "hop count" value
> 
> Silvano,
> 
> 	What is in the current draft represents a process anomaly.
> 
> 	As you said, the RPF proposal has not been agreed to, and
> should not - therefore - have been added to a working group draft.
> 
> 	The proposal to simply use (some form of) spanning tree is
> not new either, particularly in relationship to multi-destination
> distribution.
> 
> Thanks!
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Thursday, May 03, 2007 10:58 AM
> > To: Eric Gray (LO/EUS); Joe Touch
> > Cc: Radia Perlman; [e-mail]
> > Subject: RE: [rbridge] Setting initial "hop count" value
> > Importance: High
> >
> > Eric,
> >
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > Sent: Thursday, May 03, 2007 7:48 AM
> > > To: Silvano Gai; Joe Touch
> > > Cc: Radia Perlman; [e-mail]
> > > Subject: RE: [rbridge] Setting initial "hop count" value
> > >
> > > Silvano,
> > >
> > > 	I am clearly missing part of these discussions, and I doubt
> > > I am alone in doing so.
> > >
> > > 	First, what exactly is the "Radia RPF" proposal that you
> > > mention in another thread of discussion, that you also say is
> > > both "unproven" and "not agreed" to, AND why would we use that
> > > in lieue of some form of existing spanning tree protocol for
> > > the multi-destination case?
> > >
> >
> > I have resend her proposal to the mailing list in a separate
> > email. You
> > may want to go back and read the comments of Dino and Sanjaya.
> >
> >
> > > 	And, second, I was under the strong impression we were
> > > not planning to use SPF routing for the multi-destination case.
> > > Is that part of the "Radia RPF" proposal?
> > >
> >
> > Radia proposal is an addendum to
> > http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-p
> > rotocol-03
> > .txt
> >
> > That states:
> >
> > 3.4.1. Distribution Tree Calculation
> >
> >    RBridges do not use the spanning tree protocol to calculate
> >    distribution trees. Instead, distribution trees are
> > calculated based
> >    on the link state information, selecting a particular
> > RBridge as the
> >    root.
> >
> >    Calculation of a tree rooted at Ri is done independently by each
> >    RBridge Rn by performing the SPF (Shortest Path First)
calculation
> >    with Ri as the root without requiring any additional exchange of
> >    information.
> >
> >
> > > 	Given that (M/R)STP is a proven - loop free - technique
> > > for handling loop prevention in multi-destination traffic for
> > > L2 forwarding, AND that we're not as much concerned about the
> > > use of SPF routing for the multi-destination case, _why_ would
> > > we want to invent some other technique for setting up spanning
> > > trees?
> >
> > What you are proposing is different of what is in the current draft.
> >
> > -- Silvano
> >
> >
> >
> > >
> > > Thanks!
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Wednesday, May 02, 2007 7:42 PM
> > > > To: Joe Touch
> > > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > Subject: RE: [rbridge] Setting initial "hop count" value
> > > >
> > > > Joe,
> > > >
> > > > > -----Original Message-----
> > > > > From: Joe Touch [mailto:[e-mail]]
> > > > > Sent: Wednesday, May 02, 2007 4:37 PM
> > > > > To: Silvano Gai
> > > > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > > Subject: Re: [rbridge] Setting initial "hop count" value
> > > > >
> > > > >
> > > > >
> > > > > Silvano Gai wrote:
> > > > > > Joe,
> > > > > ...
> > > > > > It is a doomsday scenario: if you have seen a broadcast
storm
> > you
> > > > don't
> > > > > > want to see another one.
> > > > > >
> > > > > > Granted there are measure that have been put in place to
limit
> > the
> > > > > > possibility that this happens, for example today bridges
have
> > > > separate
> > > > > > queues for BPDUs, but we still need to be EXTREMELY careful
> > > > >
> > > > > All great reasons for not relying on TTLs to bail you out
> > > > of a storm.
> > > > A
> > > > > TTL of N can result in K^N/J copies if it loops through just
one
> > > > > replication point with K outputs with a loop length of J.
Given
> > loop
> > > > > lengths could be 2-3, what TTL is reasonable to prevent
> > this sort
> > of
> > > > > blowup that isn't going to impact the reachability diameter?
> > > > >
> > > > > Current ethernet relies on spanning tree to avoid this;
> > why not -
> > as
> > > > we
> > > > > originally discussed - rely on spanning tree for broadcasts
and
> > > > > multicasts and then this ceases to be an issue...?
> > > > >
> > > >
> > > > You miss one point.
> > > >
> > > > The Spanning Tree Protocol has an interlock mechanism that
> > ABSOLUTELY
> > > > guarantees no transient loops.
> > > >
> > > > A Spanning Tree based on an ISIS database will not have this
> > interlock
> > > > mechanism and transient loops will be possible.
> > > >
> > > > -- Silvano
> > > >
> >



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43FGYKT000708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 08:16:34 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l43FHVHF022178; Thu, 3 May 2007 10:17:31 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 3 May 2007 10:16:32 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 3 May 2007 10:16:30 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNEuipY89iFdfYTeqiNXtq7pBphAAACLPQAB9m2YAAAIr04AAAPsZw
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Joe Touch" <[e-mail]>
X-OriginalArrivalTime: 03 May 2007 15:16:32.0830 (UTC) FILETIME=[085D6DE0:01C78D96]
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 l43FGYKT000708
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 15:16:58 -0000
Status: RO
Content-Length: 4882

Silvano,

	What is in the current draft represents a process anomaly.

	As you said, the RPF proposal has not been agreed to, and
should not - therefore - have been added to a working group draft.

	The proposal to simply use (some form of) spanning tree is
not new either, particularly in relationship to multi-destination
distribution.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Thursday, May 03, 2007 10:58 AM
> To: Eric Gray (LO/EUS); Joe Touch
> Cc: Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Setting initial "hop count" value
> Importance: High
> 
> Eric,
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > Sent: Thursday, May 03, 2007 7:48 AM
> > To: Silvano Gai; Joe Touch
> > Cc: Radia Perlman; [e-mail]
> > Subject: RE: [rbridge] Setting initial "hop count" value
> > 
> > Silvano,
> > 
> > 	I am clearly missing part of these discussions, and I doubt
> > I am alone in doing so.
> > 
> > 	First, what exactly is the "Radia RPF" proposal that you
> > mention in another thread of discussion, that you also say is
> > both "unproven" and "not agreed" to, AND why would we use that
> > in lieue of some form of existing spanning tree protocol for
> > the multi-destination case?
> > 
> 
> I have resend her proposal to the mailing list in a separate 
> email. You
> may want to go back and read the comments of Dino and Sanjaya.
> 
> 
> > 	And, second, I was under the strong impression we were
> > not planning to use SPF routing for the multi-destination case.
> > Is that part of the "Radia RPF" proposal?
> > 
> 
> Radia proposal is an addendum to 
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-p
> rotocol-03
> .txt
> 
> That states:
> 
> 3.4.1. Distribution Tree Calculation 
> 
>    RBridges do not use the spanning tree protocol to calculate 
>    distribution trees. Instead, distribution trees are 
> calculated based 
>    on the link state information, selecting a particular 
> RBridge as the 
>    root.  
> 
>    Calculation of a tree rooted at Ri is done independently by each 
>    RBridge Rn by performing the SPF (Shortest Path First) calculation 
>    with Ri as the root without requiring any additional exchange of 
>    information.
> 
> 
> > 	Given that (M/R)STP is a proven - loop free - technique
> > for handling loop prevention in multi-destination traffic for
> > L2 forwarding, AND that we're not as much concerned about the
> > use of SPF routing for the multi-destination case, _why_ would
> > we want to invent some other technique for setting up spanning
> > trees?
> 
> What you are proposing is different of what is in the current draft.
> 
> -- Silvano
> 
> 
> 
> > 
> > Thanks!
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Wednesday, May 02, 2007 7:42 PM
> > > To: Joe Touch
> > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > Subject: RE: [rbridge] Setting initial "hop count" value
> > >
> > > Joe,
> > >
> > > > -----Original Message-----
> > > > From: Joe Touch [mailto:[e-mail]]
> > > > Sent: Wednesday, May 02, 2007 4:37 PM
> > > > To: Silvano Gai
> > > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > Subject: Re: [rbridge] Setting initial "hop count" value
> > > >
> > > >
> > > >
> > > > Silvano Gai wrote:
> > > > > Joe,
> > > > ...
> > > > > It is a doomsday scenario: if you have seen a broadcast storm
> you
> > > don't
> > > > > want to see another one.
> > > > >
> > > > > Granted there are measure that have been put in place to limit
> the
> > > > > possibility that this happens, for example today bridges have
> > > separate
> > > > > queues for BPDUs, but we still need to be EXTREMELY careful
> > > >
> > > > All great reasons for not relying on TTLs to bail you out
> > > of a storm.
> > > A
> > > > TTL of N can result in K^N/J copies if it loops through just one
> > > > replication point with K outputs with a loop length of J. Given
> loop
> > > > lengths could be 2-3, what TTL is reasonable to prevent 
> this sort
> of
> > > > blowup that isn't going to impact the reachability diameter?
> > > >
> > > > Current ethernet relies on spanning tree to avoid this; 
> why not -
> as
> > > we
> > > > originally discussed - rely on spanning tree for broadcasts and
> > > > multicasts and then this ceases to be an issue...?
> > > >
> > >
> > > You miss one point.
> > >
> > > The Spanning Tree Protocol has an interlock mechanism that
> ABSOLUTELY
> > > guarantees no transient loops.
> > >
> > > A Spanning Tree based on an ISIS database will not have this
> interlock
> > > mechanism and transient loops will be possible.
> > >
> > > -- Silvano
> > >
> 



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43FGAaT000655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 08:16:11 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l43FH7pY022109; Thu, 3 May 2007 10:17:07 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 3 May 2007 10:16:09 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 3 May 2007 10:16:06 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNE7n/0RQ0UyQ3SXm+IM/xanRYBgAACbpQAB+brMAAAE5RYAAALQrg
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Joe Touch" <[e-mail]>
X-OriginalArrivalTime: 03 May 2007 15:16:09.0080 (UTC) FILETIME=[FA357780:01C78D95]
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 l43FGAaT000655
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 15:16:29 -0000
Status: RO
Content-Length: 5280

Silvano,

	That was true, right up until the proposal was made to make
the trees bi-directional.  That - in turn was necessitated by the
proposal to allow some edge RBridges to opt-out of sourcing their
own distribution trees.  At that point, more than a few people
started to think that we were then abandoning the use of SPF for
the multi-destination case.

	The rationale for thinking that is really quite obvious.

	Note that - if you assume a tree computed with X as root,
spanning tree protocol effectively sets up a tree with X as root 
and shortest paths computed from X to all leaf bridges.

	If you assume a bi-directional tree computed with X as root
- even if computed explicitly using SPF routing - that tree is the 
shortest path from one leaf to another only by a happy accident in 
some cases and NOT at all in all other cases.

	If using a bi-directional spanning tree means essentially
abandoning SPF routing, then the advantage you might hope to get
from not using (M/R)STP vanishes in a puff of smoke in comparison
with the cost we can expect to pay to develop an alternative, and
(eventually) make it work.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Thursday, May 03, 2007 11:03 AM
> To: Eric Gray (LO/EUS); Joe Touch
> Cc: Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Setting initial "hop count" value
> Importance: High
> 
> 
> Eric,
> 
> From when I joined this WG all the base protocol drafts have always
> assumed that TRILL was using IS-IS to compute what we now call
> "Distribution Trees". We changed the names from "source 
> routed tree" to
> "distribution tree" and the number of these trees, but never the way
> they were computed.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > Sent: Thursday, May 03, 2007 7:54 AM
> > To: Silvano Gai; Joe Touch
> > Cc: Radia Perlman; [e-mail]
> > Subject: RE: [rbridge] Setting initial "hop count" value
> > 
> > Silvano,
> > 
> > 	Same question applies here.  It's one thing to say that we
> > don't run STP in the conventional bridging sense.  We don't run
> > IS-IS in the conventional IP (or OSI) routing sense, either.  It
> > is quite another to say that we don't use an existing spanning
> > tree protocol (perhaps with different BPDUs - e.g. - RBPDUs) and
> > gain all of the advantages of existing implementation, and field
> > deployment experience associated with it.
> > 
> > 	Are you (and probably Joe) saying that we want to invent
> > something new here?
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Wednesday, May 02, 2007 7:47 PM
> > > To: Joe Touch
> > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > Subject: RE: [rbridge] Setting initial "hop count" value
> > >
> > > Joe
> > >
> > > > -----Original Message-----
> > > > From: Joe Touch [mailto:[e-mail]]
> > > > Sent: Wednesday, May 02, 2007 4:43 PM
> > > > To: Silvano Gai
> > > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > Subject: Re: [rbridge] Setting initial "hop count" value
> > > >
> > > >
> > > >
> > > > Silvano Gai wrote:
> > > > > Joe,
> > > > ...
> > > > >>> Loops are much more dangerous at layer 2 than at 
> layer 3. I am
> > > > >>> sympathetic with Radia that anything we can do to
> > > mitigate them is
> > > > > good.
> > > > >> This is why we ought to be using a spanning tree for those,
> > > > >
> > > > > You are not claiming that we need to run the Spanning
> > > Tree Protocol,
> > > > > correct?
> > > >
> > > > No; I was claiming that there's a legitimate reason to 
> still have
> a
> > > > spanning tree inside the campus.
> > > >
> > >
> > > Agreed, we are in synch.
> > >
> > > > > and let that
> > > > >> tree be suboptimal and/or converge via means that 
> avoid looping
> > > > >> transients.
> > > > >
> > > > > This is not easy. Radia RPF proposal seems a good start,
> > > but it is:
> > > > > - not agreed yet
> > > > > - Unproven
> > > > >
> > > > > It is pretty straightforward to use Radia RPF proposal to
> > > reduce the
> > > > > probability of transient loops. If you want to 
> "GUARANTEE" that
> > > there
> > > > > are no transient loops, that is a different story, 
> since it has
> a
> > > > > significant state requirement that can impact low end
> > > implementation. I
> > > > > am all for it, but we need to discuss it in a separate thread.
> > > >
> > > > Agreed; I'm not convinced that such transients aren't OK if
> > > they exist
> > > > with conventional implementations.
> > >
> > > They don't. Today the Spanning Tree protocol never generates
> > > a transient
> > > loop.
> > >
> > > -- Silvano
> > >
> > > Remember that rbridges aren't
> > > > intended to scale beyond current implementations, which 
> means that
> > > > however existing implementations support spanning trees and deal
> (or
> > > > don't) with transient loops should map here just fine.
> > > >
> > > > Joe
> > > > --
> > > > ----------------------------------------
> > > > Joe Touch
> > > > Sr. Network Engineer, USAF TSAT Space Segment
> > >
> > >
> 



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 l43F2sfB025742 for <[e-mail]>; Thu, 3 May 2007 08:02:54 -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, 3 May 2007 08:02:45 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNE7n/0RQ0UyQ3SXm+IM/xanRYBgAACbpQAB+brMAAAE5RYA==
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[e-mail]>, "Joe Touch" <[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 l43F2sfB025742
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 15:03:24 -0000
Status: RO
Content-Length: 3574

Eric,

>From when I joined this WG all the base protocol drafts have always
assumed that TRILL was using IS-IS to compute what we now call
"Distribution Trees". We changed the names from "source routed tree" to
"distribution tree" and the number of these trees, but never the way
they were computed.

-- Silvano

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> Sent: Thursday, May 03, 2007 7:54 AM
> To: Silvano Gai; Joe Touch
> Cc: Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Setting initial "hop count" value
> 
> Silvano,
> 
> 	Same question applies here.  It's one thing to say that we
> don't run STP in the conventional bridging sense.  We don't run
> IS-IS in the conventional IP (or OSI) routing sense, either.  It
> is quite another to say that we don't use an existing spanning
> tree protocol (perhaps with different BPDUs - e.g. - RBPDUs) and
> gain all of the advantages of existing implementation, and field
> deployment experience associated with it.
> 
> 	Are you (and probably Joe) saying that we want to invent
> something new here?
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Wednesday, May 02, 2007 7:47 PM
> > To: Joe Touch
> > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > Subject: RE: [rbridge] Setting initial "hop count" value
> >
> > Joe
> >
> > > -----Original Message-----
> > > From: Joe Touch [mailto:[e-mail]]
> > > Sent: Wednesday, May 02, 2007 4:43 PM
> > > To: Silvano Gai
> > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > Subject: Re: [rbridge] Setting initial "hop count" value
> > >
> > >
> > >
> > > Silvano Gai wrote:
> > > > Joe,
> > > ...
> > > >>> Loops are much more dangerous at layer 2 than at layer 3. I am
> > > >>> sympathetic with Radia that anything we can do to
> > mitigate them is
> > > > good.
> > > >> This is why we ought to be using a spanning tree for those,
> > > >
> > > > You are not claiming that we need to run the Spanning
> > Tree Protocol,
> > > > correct?
> > >
> > > No; I was claiming that there's a legitimate reason to still have
a
> > > spanning tree inside the campus.
> > >
> >
> > Agreed, we are in synch.
> >
> > > > and let that
> > > >> tree be suboptimal and/or converge via means that avoid looping
> > > >> transients.
> > > >
> > > > This is not easy. Radia RPF proposal seems a good start,
> > but it is:
> > > > - not agreed yet
> > > > - Unproven
> > > >
> > > > It is pretty straightforward to use Radia RPF proposal to
> > reduce the
> > > > probability of transient loops. If you want to "GUARANTEE" that
> > there
> > > > are no transient loops, that is a different story, since it has
a
> > > > significant state requirement that can impact low end
> > implementation. I
> > > > am all for it, but we need to discuss it in a separate thread.
> > >
> > > Agreed; I'm not convinced that such transients aren't OK if
> > they exist
> > > with conventional implementations.
> >
> > They don't. Today the Spanning Tree protocol never generates
> > a transient
> > loop.
> >
> > -- Silvano
> >
> > Remember that rbridges aren't
> > > intended to scale beyond current implementations, which means that
> > > however existing implementations support spanning trees and deal
(or
> > > don't) with transient loops should map here just fine.
> > >
> > > Joe
> > > --
> > > ----------------------------------------
> > > Joe Touch
> > > Sr. Network Engineer, USAF TSAT Space Segment
> >
> >



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 l43Ew3Hm024268 for <[e-mail]>; Thu, 3 May 2007 07:58:03 -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, 3 May 2007 07:57:56 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNEuipY89iFdfYTeqiNXtq7pBphAAACLPQAB9m2YAAAIr04A==
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[e-mail]>, "Joe Touch" <[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 l43Ew3Hm024268
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 14:58:33 -0000
Status: RO
Content-Length: 3929

Eric,

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> Sent: Thursday, May 03, 2007 7:48 AM
> To: Silvano Gai; Joe Touch
> Cc: Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Setting initial "hop count" value
> 
> Silvano,
> 
> 	I am clearly missing part of these discussions, and I doubt
> I am alone in doing so.
> 
> 	First, what exactly is the "Radia RPF" proposal that you
> mention in another thread of discussion, that you also say is
> both "unproven" and "not agreed" to, AND why would we use that
> in lieue of some form of existing spanning tree protocol for
> the multi-destination case?
> 

I have resend her proposal to the mailing list in a separate email. You
may want to go back and read the comments of Dino and Sanjaya.


> 	And, second, I was under the strong impression we were
> not planning to use SPF routing for the multi-destination case.
> Is that part of the "Radia RPF" proposal?
> 

Radia proposal is an addendum to 
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03
.txt

That states:

3.4.1. Distribution Tree Calculation 

   RBridges do not use the spanning tree protocol to calculate 
   distribution trees. Instead, distribution trees are calculated based 
   on the link state information, selecting a particular RBridge as the 
   root.  

   Calculation of a tree rooted at Ri is done independently by each 
   RBridge Rn by performing the SPF (Shortest Path First) calculation 
   with Ri as the root without requiring any additional exchange of 
   information.


> 	Given that (M/R)STP is a proven - loop free - technique
> for handling loop prevention in multi-destination traffic for
> L2 forwarding, AND that we're not as much concerned about the
> use of SPF routing for the multi-destination case, _why_ would
> we want to invent some other technique for setting up spanning
> trees?

What you are proposing is different of what is in the current draft.

-- Silvano



> 
> Thanks!
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Wednesday, May 02, 2007 7:42 PM
> > To: Joe Touch
> > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > Subject: RE: [rbridge] Setting initial "hop count" value
> >
> > Joe,
> >
> > > -----Original Message-----
> > > From: Joe Touch [mailto:[e-mail]]
> > > Sent: Wednesday, May 02, 2007 4:37 PM
> > > To: Silvano Gai
> > > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > Subject: Re: [rbridge] Setting initial "hop count" value
> > >
> > >
> > >
> > > Silvano Gai wrote:
> > > > Joe,
> > > ...
> > > > It is a doomsday scenario: if you have seen a broadcast storm
you
> > don't
> > > > want to see another one.
> > > >
> > > > Granted there are measure that have been put in place to limit
the
> > > > possibility that this happens, for example today bridges have
> > separate
> > > > queues for BPDUs, but we still need to be EXTREMELY careful
> > >
> > > All great reasons for not relying on TTLs to bail you out
> > of a storm.
> > A
> > > TTL of N can result in K^N/J copies if it loops through just one
> > > replication point with K outputs with a loop length of J. Given
loop
> > > lengths could be 2-3, what TTL is reasonable to prevent this sort
of
> > > blowup that isn't going to impact the reachability diameter?
> > >
> > > Current ethernet relies on spanning tree to avoid this; why not -
as
> > we
> > > originally discussed - rely on spanning tree for broadcasts and
> > > multicasts and then this ceases to be an issue...?
> > >
> >
> > You miss one point.
> >
> > The Spanning Tree Protocol has an interlock mechanism that
ABSOLUTELY
> > guarantees no transient loops.
> >
> > A Spanning Tree based on an ISIS database will not have this
interlock
> > mechanism and transient loops will be possible.
> >
> > -- Silvano
> >



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43EsRoT022963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 07:54:27 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l43EtO3v017620; Thu, 3 May 2007 09:55:24 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 3 May 2007 09:54:25 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 3 May 2007 09:54:23 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNE7n/0RQ0UyQ3SXm+IM/xanRYBgAACbpQAB+brMA=
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Joe Touch" <[e-mail]>
X-OriginalArrivalTime: 03 May 2007 14:54:25.0868 (UTC) FILETIME=[F16F18C0:01C78D92]
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 l43EsRoT022963
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 14:54:56 -0000
Status: RO
Content-Length: 2839

Silvano,

	Same question applies here.  It's one thing to say that we
don't run STP in the conventional bridging sense.  We don't run
IS-IS in the conventional IP (or OSI) routing sense, either.  It
is quite another to say that we don't use an existing spanning
tree protocol (perhaps with different BPDUs - e.g. - RBPDUs) and
gain all of the advantages of existing implementation, and field
deployment experience associated with it.

	Are you (and probably Joe) saying that we want to invent
something new here?

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Wednesday, May 02, 2007 7:47 PM
> To: Joe Touch
> Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Setting initial "hop count" value
> 
> Joe
> 
> > -----Original Message-----
> > From: Joe Touch [mailto:[e-mail]]
> > Sent: Wednesday, May 02, 2007 4:43 PM
> > To: Silvano Gai
> > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > Subject: Re: [rbridge] Setting initial "hop count" value
> > 
> > 
> > 
> > Silvano Gai wrote:
> > > Joe,
> > ...
> > >>> Loops are much more dangerous at layer 2 than at layer 3. I am
> > >>> sympathetic with Radia that anything we can do to 
> mitigate them is
> > > good.
> > >> This is why we ought to be using a spanning tree for those,
> > >
> > > You are not claiming that we need to run the Spanning 
> Tree Protocol,
> > > correct?
> > 
> > No; I was claiming that there's a legitimate reason to still have a
> > spanning tree inside the campus.
> > 
> 
> Agreed, we are in synch.
> 
> > > and let that
> > >> tree be suboptimal and/or converge via means that avoid looping
> > >> transients.
> > >
> > > This is not easy. Radia RPF proposal seems a good start, 
> but it is:
> > > - not agreed yet
> > > - Unproven
> > >
> > > It is pretty straightforward to use Radia RPF proposal to 
> reduce the
> > > probability of transient loops. If you want to "GUARANTEE" that
> there
> > > are no transient loops, that is a different story, since it has a
> > > significant state requirement that can impact low end
> implementation. I
> > > am all for it, but we need to discuss it in a separate thread.
> > 
> > Agreed; I'm not convinced that such transients aren't OK if 
> they exist
> > with conventional implementations. 
> 
> They don't. Today the Spanning Tree protocol never generates 
> a transient
> loop. 
> 
> -- Silvano
> 
> Remember that rbridges aren't
> > intended to scale beyond current implementations, which means that
> > however existing implementations support spanning trees and deal (or
> > don't) with transient loops should map here just fine.
> > 
> > Joe
> > --
> > ----------------------------------------
> > Joe Touch
> > Sr. Network Engineer, USAF TSAT Space Segment
> 
> 



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 l43ErLKm022698 for <[e-mail]>; Thu, 3 May 2007 07:53:21 -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, 3 May 2007 07:53:13 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] How to do RPF checks for bidirectional RBridge trees
Thread-Index: AcdhKc4k5xOrgLKST566pGKKyE1L+AsaMl+A
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[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 l43ErLKm022698
Cc: [e-mail]
Subject: [rbridge] FW: How to do RPF checks for bidirectional RBridge trees
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, 03 May 2007 14:53:27 -0000
Status: RO
Content-Length: 2245

Eric,

This is Radia RPF proposal,
It is to be used in addition to the multi-destination distribution
trees.

-- Silvano

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Wednesday, March 07, 2007 6:18 PM
To: [e-mail]
Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees

It isn't totally obvious how to do RPF (reverse path forwarding) checks 
to make multicast forwarding safer, when we're doing bidirectional trees

(ingress is R1, but R1 chooses tree root R2).

So after thinking about it, I think this is how it would work, and it
introduces a new field that would be nice to add to the core instance 
IS-IS LSP. The field is "I promise to only choose the following set of 
RBridges to be tree roots". The only reasons for R1 to choose a 
distribution tree rooted on an RBridge other than itself are:

a) R1 is configured not to ask to be a tree root (so that RBridges don't

have to calculate as many trees)

b) R1 wants to multipath multicast originating on its attached links.

The reason for having R1 preannounce is to simplify creating an RPF 
database associated with each tree.

If tree R1 is used if and only if R1 is the ingress for the data, then 
the RPF tree for tree R1 would look like this, at some RBridge R in the 
core:

for each "adjacency" (neighbor/port): one of the following: not in tree,

in-port, or out-port. The RPF check would discard any incoming data for 
tree R1 except on the in-port.

However, if R1 chooses R2 as the root of the multicast tree, then the 
RPF database associated with the tree R2, at some core RBridge R looks 
like this:

Let S be the set of RBridges that have announced, in their LSPs, that 
they might choose R2 as the tree for multicast traffic they are sourcing

into the campus.

R keeps, for tree R2, and for each adjacency, {set of RBridges that are 
plausible ingress RBridges for packets received on that adjacency}.

The set union of all of those will be S.

I hope that's correct, and that I've explained it clearly....

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 l43En7jM021391 for <[e-mail]>; Thu, 3 May 2007 07:49:07 -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, 3 May 2007 07:48:58 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: What is important in RBridge version 1.0?
Thread-Index: AceNki5h9rC9r+IETNWN0Tygn5gGkQ==
From: "Silvano Gai" <[e-mail]>
To: <[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 l43En7jM021391
Subject: [rbridge] What is important in RBridge version 1.0?
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, 03 May 2007 14:49:25 -0000
Status: RO
Content-Length: 893

The current discussion of TTL/broadcast storm/etc made me think what is
important in TRILL version 1.0 and what can be delayed to version 2.0 or
dealt with in separate documents.

Here is my list:

1) excellent support for shortest path/multipath
   * core instance of IS-IS
   * nickname assignments
   * DR election

2) A super stable frame format, so that companies may start to code
their ASIC

3) Broadcast storm suppression
   * Radia RPF proposal

4) learning from data traffic (backward learning as bridges do)

5) Spanning Tree interoperability at the edges
   * simple form, receiving BPDUs only

6) A last call no later than the end of the year.

I propose we focus our discussion on these points without which we don't
have a viable standard.


Let's delay/move to other documents:

1) ARP/ND proxy

2) per VLAN IS-IS instance

3) IGMP learning

What do you think?

-- Silvano





Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43EmMG3021225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 07:48:22 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l43EnJXk016184; Thu, 3 May 2007 09:49:19 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 3 May 2007 09:48:20 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 3 May 2007 09:48:18 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNEuipY89iFdfYTeqiNXtq7pBphAAACLPQAB9m2YA=
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Joe Touch" <[e-mail]>
X-OriginalArrivalTime: 03 May 2007 14:48:20.0506 (UTC) FILETIME=[17A947A0:01C78D92]
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 l43EmMG3021225
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 14:48:54 -0000
Status: RO
Content-Length: 2678

Silvano,

	I am clearly missing part of these discussions, and I doubt 
I am alone in doing so.

	First, what exactly is the "Radia RPF" proposal that you
mention in another thread of discussion, that you also say is 
both "unproven" and "not agreed" to, AND why would we use that
in lieue of some form of existing spanning tree protocol for
the multi-destination case?

	And, second, I was under the strong impression we were
not planning to use SPF routing for the multi-destination case.
Is that part of the "Radia RPF" proposal?

	Given that (M/R)STP is a proven - loop free - technique
for handling loop prevention in multi-destination traffic for
L2 forwarding, AND that we're not as much concerned about the
use of SPF routing for the multi-destination case, _why_ would
we want to invent some other technique for setting up spanning
trees?

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Wednesday, May 02, 2007 7:42 PM
> To: Joe Touch
> Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Setting initial "hop count" value
> 
> Joe,
> 
> > -----Original Message-----
> > From: Joe Touch [mailto:[e-mail]]
> > Sent: Wednesday, May 02, 2007 4:37 PM
> > To: Silvano Gai
> > Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > Subject: Re: [rbridge] Setting initial "hop count" value
> > 
> > 
> > 
> > Silvano Gai wrote:
> > > Joe,
> > ...
> > > It is a doomsday scenario: if you have seen a broadcast storm you
> don't
> > > want to see another one.
> > >
> > > Granted there are measure that have been put in place to limit the
> > > possibility that this happens, for example today bridges have
> separate
> > > queues for BPDUs, but we still need to be EXTREMELY careful
> > 
> > All great reasons for not relying on TTLs to bail you out 
> of a storm.
> A
> > TTL of N can result in K^N/J copies if it loops through just one
> > replication point with K outputs with a loop length of J. Given loop
> > lengths could be 2-3, what TTL is reasonable to prevent this sort of
> > blowup that isn't going to impact the reachability diameter?
> > 
> > Current ethernet relies on spanning tree to avoid this; why not - as
> we
> > originally discussed - rely on spanning tree for broadcasts and
> > multicasts and then this ceases to be an issue...?
> > 
> 
> You miss one point.
> 
> The Spanning Tree Protocol has an interlock mechanism that ABSOLUTELY
> guarantees no transient loops.
> 
> A Spanning Tree based on an ISIS database will not have this interlock
> mechanism and transient loops will be possible.
> 
> -- Silvano
> 



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 l43EcGLs018523 for <[e-mail]>; Thu, 3 May 2007 07:38:16 -0700 (PDT)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 03 May 2007 07:38:16 -0700 (PDT)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 03 May 2007 07:38:16 -0700 (PDT)
Received: from [152.70.2.164] (Forwarded-For: [66.195.71.171]) by mail-srv.sfvic.sunlabs.com (mshttpd); Thu, 03 May 2007 07:38:16 -0700
Date: Thu, 03 May 2007 07:38:16 -0700
From: [e-mail]
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Back to ND/ARP optimization
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, 03 May 2007 14:38:28 -0000
Status: RO
Content-Length: 1647

Looking back on old emails, there are some people who'd like to get rid of ND/ARP optimization,
and some people pointing out that optimizing ND might not be so simple (for instance, SEND).

I'd be OK with removing it from the spec, or certainly making it something other than a MUST, like
perhaps MAY.

But there were fields in the per-VLAN instance of IS-IS to facilitate this, namely the (L3 address, L2 address).
An RBridge *could* learn this information locally, but wouldn't learn it as much. In other words, if S behind R1 sends
an ARP request for target T behind R2, the response will be unicast to S, so none of the other RBridges will
learn where T is. Only R1. So R1 could in the future do a proxy ARP. But if R2 announced (T, t) in its per-VLAN
instance of IS-IS, then all the RBridges could learn (T,t). Furthermore, if T has registered with R2 via some
L2 enrollment protoocol, then R2 can immediately know if T is no longer there and alert everyone.

Does anyone have a handle on how much traffic is caused by ARP/ND?

We could certainly do a compromise, like that each RBridge R1 SHOULD throttle ARP/ND queries, and
not reflood a query for T if there has been more than k (some parameter) queries for T in the last n seconds.

But that doesn't even have to be in the spec.

It would be nice to know in operational networks how much traffic is caused by ARP/ND queries, and how
worried people are about a malicious endnode DOS'ing by sending lots of queries. (but it could just as easily
send other types of broadcast/multicast traffic so maybe it's not worth worrying about optimization ARP/ND because
of malicious nodes).

Radia




Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43EbHuc018228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 07:37:17 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l43EcEt0013424; Thu, 3 May 2007 09:38:14 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 3 May 2007 09:37:16 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 3 May 2007 09:37:13 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Optional configuration of RBridge nickname
Thread-Index: AceNjy2slc+yzQ1FT7a8Uy8jG2bI2wAACwFQ
References: <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 03 May 2007 14:37:16.0046 (UTC) FILETIME=[8B9CBAE0:01C78D90]
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 l43EbHuc018228
Cc: [e-mail]
Subject: Re: [rbridge] Optional configuration of RBridge nickname
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, 03 May 2007 14:37:27 -0000
Status: RO
Content-Length: 12122

Radia,

	You're implying what is essentially "new information" to
me.  Are you suggesting that different portions of the same L2
domain may be under separate administrative management domains?

	That seems a little strange for a network in which at
leats one of the administrators is concerned about dynamic 
behavior in the network.

	If so, then how do we address the issue with contention
if more than one administrator wants to use a specific nickname
and so more than one sets the priority to the highest possible
value for the same configured nickname?

	Also, how do you propose to address the general problem
where two devices are configured with the same nickname but at
different priorities?  Does the one with the lower priority
fall back to negotiation?  If so, what effect does this have 
on network stability if the device with the higher priority 
starts to behave erratically?

	We need to consider potential _additional_ complexity
that might arise in _normal_ operation before we deliberately 
set out to get fancy.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Thursday, May 03, 2007 10:27 AM
> To: Eric Gray (LO/EUS)
> Cc: Silvano Gai; [e-mail]
> Subject: Re: [rbridge] Optional configuration of RBridge nickname
> Importance: High
> 
> I think it is perfectly reasonable to have some RBridges 
> configured with nicknames, and others not.
> For example, some RBridges might be hosting more critical 
> parts of the network. Or just that people in
> charge of different parts of the net might have more energy 
> for configuring nicknames.
> 
> I can also imagine people wanting priority for nickname.
> 
> Radia
> 
> ----- Original Message -----
> From: "Eric Gray (LO/EUS)" <[e-mail]>
> Date: Thursday, May 3, 2007 6:24 am
> Subject: Re: [rbridge] Optional configuration of RBridge nickname
> 
> > Silvano,
> > 
> > 	I believe that it is easily arguable that having a network
> > in which some devices are configured not to negotiate, while the
> > rest are not so configured (and default to negotiation) MUST be 
> > considered a configuration error.  In many ways, this SHOULD be 
> > considered the same sort of error as might occur if two devices 
> > were configured with the same value.
> > 
> > 	One mitigating factor for this particular configuration 
> > error is that one very likely way in which it would occur - i.e.
> > - as a result of powering up an unconfigured device, is a "safe"
> > operation if the (default) negotiation scheme favors the "status
> > quo" assignment (as I believe we all have agreed it MUST).
> > 
> > 	Another likely pair of scenarios are as follows:
> > 
> > A) one in which a new device is added to an existing deployment 
> >   where the existing devices are using negotiation and the new 
> >   device is configured with a value that just happens to be the
> >   same as one that an existing device has negotiated 
> > 
> >   - is clearly analogous to -
> > 
> > B) one in which a new device is added to an existing deployment
> >   where the existing devices are configured with values (and
> >   not using negotiation) and the new device is configured with
> >   the same value as one that has previously been configured 
> >   for an existing device.
> > 
> > 	I am reasonably confident that these SHOULD be viewed as
> > simple configuration errors in both cases.
> > 
> > 	I suggest that it follows from this line of reasoning that
> > it MUST always be possible to create a conflict situation as a 
> > result of configuration errors.  Hence it should also follow that
> > a simpler approach is more desirable than a more complicated one.
> > 
> > 	As the saying goes, let's apply the KISS principle and do
> > what makes the most direct sense in terms of the goal we want to
> > achieve.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson  
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [[e-mail]] 
> > > Sent: Wednesday, May 02, 2007 7:50 PM
> > > To: Eric Gray (LO/EUS); Radia Perlman
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] Optional configuration of RBridge nickname
> > > Importance: High
> > > 
> > > 
> > > Eric, 
> > > 
> > > I think you are reading it correctly and having an 
> implementation to
> > > support a way to shut nickname-negotiation off is what we need.
> > > 
> > > The problem is that after I have manually configured a nickname 
> > on an
> > > RBridge I need to be sure that no other RBridge in the network 
> > selects> it.
> > > 
> > > I also need to take into account that due to a mistake I can 
> > manually> config the same nickname on two RBridges.
> > > 
> > > One thing after the other we ended up with Radia proposal, but if 
> > you> have a better one, we are happy to listen.
> > > 
> > > Cheers
> > > 
> > > -- Silvano
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [[e-mail]]
> > > > Sent: Wednesday, May 02, 2007 10:17 AM
> > > > To: Silvano Gai; Radia Perlman
> > > > Cc: [e-mail]
> > > > Subject: RE: [rbridge] Optional configuration of 
> RBridge nickname
> > > > 
> > > > Silvano,
> > > > 
> > > > 	Perhaps I am reading your requirement incorrectly,
> > > > but it sounds to me that it could be as easily addressed
> > > > by requiring that implementations support a way to shut
> > > > nickname-negotiation off.
> > > > 
> > > > 	Consider simply having a pair of management objects
> > > > - one to disable auto-nickname negotiation, and another
> > > > (which must be assigned a value if the first is disabled)
> > > > that contains the configured nickname.
> > > > 
> > > > 	In my opinion, that would be a much more acceptable
> > > > approach - especially in comparison with using priority
> > > > as a mechanism for varying the outcome of auto-negotiation
> > > > without actually turning it off.
> > > > 
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson
> > > > 
> > > > > -----Original Message-----
> > > > > From: Silvano Gai [[e-mail]]
> > > > > Sent: Wednesday, May 02, 2007 12:06 PM
> > > > > To: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > > Subject: RE: [rbridge] Optional configuration of RBridge 
> > nickname> > > Importance: High
> > > > >
> > > > >
> > > > > Eric,
> > > > >
> > > > > There is a strong requirement in Enterprise to disable any 
> > form of
> > > > > autoconfiguration. I requested Radia to support a way to 
> > manually> > > configure Nicknames. I am not asking this being the 
> > default,> > > but it must
> > > > > be supported.
> > > > >
> > > > > The solution that Radia has put together is satisfactory 
> > > for me. If
> > > I
> > > > > want to manually configure a nickname I will do it and set the
> > > highest
> > > > > priority.
> > > > >
> > > > > Lacking a secure authentication scheme the network can be 
> > attacked> by
> > > > > any PC in a much easier way.
> > > > >
> > > > > --Silvano
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail]
> > > [[e-mail]]
> > > > > On
> > > > > > Behalf Of Eric Gray (LO/EUS)
> > > > > > Sent: Wednesday, May 02, 2007 3:31 AM
> > > > > > To: Radia Perlman; [e-mail]
> > > > > > Subject: Re: [rbridge] Optional configuration of 
> > > RBridge nickname
> > > > > >
> > > > > > Radia,
> > > > > >
> > > > > > 	I would object strenuously to the use of a priority
> > > > > > value in resolving the "ownership" of a nickname.
> > > > > >
> > > > > > 	The over-riding priority has to be determined in a
> > > > > > way that ensures the existing network continues to work
> > > > > > if a new device is inserted (i.e. - it would be best if
> > > > > > any device were going to fail, it should be the one that
> > > > > > has just been added).
> > > > > >
> > > > > > 	Adding "priority" would allow any device to assert
> > > > > > a high priority ownership of any nickname currently in
> > > > > > use, which would then make it trivially easy to stage a
> > > > > > network disabling attack.
> > > > > >
> > > > > > 	Having it be so easy to attack the network, would
> > > > > > necessitate mandatory defenses, almost certainly meaning
> > > > > > that configuration would be required - possibly excepting
> > > > > > the option of having the very highest priority value be
> > > > > > the default assumed when no configuration is done at any
> > > > > > RBridge.
> > > > > >
> > > > > > 	In either case (configuration absolutely required,
> > > > > > or default highest priority with no configuration) would
> > > > > > defeat your purpose.
> > > > > >
> > > > > > --
> > > > > > Eric Gray
> > > > > > Principal Engineer
> > > > > > Ericsson
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [e-mail]
> > > > > > > [[e-mail]] On Behalf Of Radia Perlman
> > > > > > > Sent: Wednesday, May 02, 2007 12:26 AM
> > > > > > > To: [e-mail]
> > > > > > > Subject: [rbridge] Optional configuration of RBridge 
> > nickname> > > > >
> > > > > > > Someone suggested that it would be useful to allow
> > > > > configuration of
> > > > > > > nicknames, so
> > > > > > > that nicknames can be more stable, and there would be no
> > > > > worry of an
> > > > > > > RBridge coming
> > > > > > > up and usurping a nickname from someone else. I'd like:
> > > > > > > a) for it to remain possible to be zero configuration (as 
> > in,> not
> > > > > > > necessary to configure
> > > > > > > a nickname
> > > > > > > b) allow a mixture of configured and unconfigured 
> nicknames
> > > > > > > c) work even with misconfiguration (configuring 
> two RBridges
> > > with
> > > > > the
> > > > > > > same nickname)
> > > > > > > d) never allow an unconfigured nickname to accidentally 
> > usurp> > > > > a nickname
> > > > > > > from
> > > > > > > a ocnfigured RBridge
> > > > > > >
> > > > > > > So I'm proposing the following:
> > > > > > >
> > > > > > > a) allow configuration of a nickname value
> > > > > > > b) have a "priority" value for owning a nickname
> > > > > > > that can also be configured, which I'd propose would 
> > > be an 8-bit
> > > > > byte,
> > > > > > > where only the bottom 7 bits can be configured
> > > > > > > c) the 8th bit of the priority byte (the most significant
> > > > > > > bit) indicates
> > > > > > > whether
> > > > > > > the nickname was configured or not
> > > > > > > d) the default is priority=0 for RBridges that 
> have not been
> > > > > > > configured with
> > > > > > > a nickname value, and priority=128 (top bit 1, rest 0) 
> > for an
> > > > > > > RBridge that
> > > > > > > has been configured with a nickname
> > > > > > > e) other values of nickname priority might be useful. For
> > > > > > > instance, an
> > > > > > > RBridge
> > > > > > > implementation might increment the nickname value 
> after it's
> > > held
> > > > > the
> > > > > > > nickname
> > > > > > > for some amount of time (say 10 minutes). Or someone might
> > > > > > > want to configure
> > > > > > > some RBridges to have a more stable nickname (by giving
> > > > > them higher
> > > > > > > priority).
> > > > > > > f) Basically, the (nickname priority | system ID) is 
> > > like the DR
> > > > > > > priority in IS-IS,
> > > > > > > where the DR election is based on (priority | system ID)
> > > > > > >
> > > > > > > Anyone object to this?
> > > > > > >
> > > > > > > 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 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 l43EXZ8h017417 for <[e-mail]>; Thu, 3 May 2007 07:33: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: Thu, 3 May 2007 07:33:30 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNjyl7Q7MvVe/VTsqjIuzbRl31BwAAIRaw
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Joe Touch" <[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 l43EXZ8h017417
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 14:33:54 -0000
Status: RO
Content-Length: 1090

Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Thursday, May 03, 2007 7:26 AM
> To: Silvano Gai
> Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> Subject: Re: [rbridge] Setting initial "hop count" value
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> ...
> >> Current ethernet relies on spanning tree to avoid this; why not -
as
> > we
> >> originally discussed - rely on spanning tree for broadcasts and
> >> multicasts and then this ceases to be an issue...?
> >>
> >
> > You miss one point.
> >
> > The Spanning Tree Protocol has an interlock mechanism that
ABSOLUTELY
> > guarantees no transient loops.
> >
> > A Spanning Tree based on an ISIS database will not have this
interlock
> > mechanism and transient loops will be possible.
> 
> My point is that maybe this means ISIS-based spanning tree isn't
> appropriate. Multicast/broadcast cannot be effectively contained by
TTL
> alone.

You are right, IS-IS spanning tree alone is not enough, we need
something like Radia RPF proposal and it must be mandatory.

See my next email

-- Silvano



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 l43ERNaa016088 for <[e-mail]>; Thu, 3 May 2007 07:27:24 -0700 (PDT)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 03 May 2007 07:27:21 -0700 (PDT)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 03 May 2007 07:27:21 -0700 (PDT)
Received: from [152.70.2.164] (Forwarded-For: [66.195.71.171]) by mail-srv.sfvic.sunlabs.com (mshttpd); Thu, 03 May 2007 07:27:21 -0700
Date: Thu, 03 May 2007 07:27:21 -0700
From: [e-mail]
To: "Eric Gray (LO/EUS)" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Optional configuration of RBridge nickname
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, 03 May 2007 14:28:30 -0000
Status: RO
Content-Length: 10174

I think it is perfectly reasonable to have some RBridges configured with nicknames, and others not.
For example, some RBridges might be hosting more critical parts of the network. Or just that people in
charge of different parts of the net might have more energy for configuring nicknames.

I can also imagine people wanting priority for nickname.

Radia

----- Original Message -----
From: "Eric Gray (LO/EUS)" <[e-mail]>
Date: Thursday, May 3, 2007 6:24 am
Subject: Re: [rbridge] Optional configuration of RBridge nickname

> Silvano,
> 
> 	I believe that it is easily arguable that having a network
> in which some devices are configured not to negotiate, while the
> rest are not so configured (and default to negotiation) MUST be 
> considered a configuration error.  In many ways, this SHOULD be 
> considered the same sort of error as might occur if two devices 
> were configured with the same value.
> 
> 	One mitigating factor for this particular configuration 
> error is that one very likely way in which it would occur - i.e.
> - as a result of powering up an unconfigured device, is a "safe"
> operation if the (default) negotiation scheme favors the "status
> quo" assignment (as I believe we all have agreed it MUST).
> 
> 	Another likely pair of scenarios are as follows:
> 
> A) one in which a new device is added to an existing deployment 
>   where the existing devices are using negotiation and the new 
>   device is configured with a value that just happens to be the
>   same as one that an existing device has negotiated 
> 
>   - is clearly analogous to -
> 
> B) one in which a new device is added to an existing deployment
>   where the existing devices are configured with values (and
>   not using negotiation) and the new device is configured with
>   the same value as one that has previously been configured 
>   for an existing device.
> 
> 	I am reasonably confident that these SHOULD be viewed as
> simple configuration errors in both cases.
> 
> 	I suggest that it follows from this line of reasoning that
> it MUST always be possible to create a conflict situation as a 
> result of configuration errors.  Hence it should also follow that
> a simpler approach is more desirable than a more complicated one.
> 
> 	As the saying goes, let's apply the KISS principle and do
> what makes the most direct sense in terms of the goal we want to
> achieve.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: Silvano Gai [[e-mail]] 
> > Sent: Wednesday, May 02, 2007 7:50 PM
> > To: Eric Gray (LO/EUS); Radia Perlman
> > Cc: [e-mail]
> > Subject: RE: [rbridge] Optional configuration of RBridge nickname
> > Importance: High
> > 
> > 
> > Eric, 
> > 
> > I think you are reading it correctly and having an implementation to
> > support a way to shut nickname-negotiation off is what we need.
> > 
> > The problem is that after I have manually configured a nickname 
> on an
> > RBridge I need to be sure that no other RBridge in the network 
> selects> it.
> > 
> > I also need to take into account that due to a mistake I can 
> manually> config the same nickname on two RBridges.
> > 
> > One thing after the other we ended up with Radia proposal, but if 
> you> have a better one, we are happy to listen.
> > 
> > Cheers
> > 
> > -- Silvano
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [[e-mail]]
> > > Sent: Wednesday, May 02, 2007 10:17 AM
> > > To: Silvano Gai; Radia Perlman
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] Optional configuration of RBridge nickname
> > > 
> > > Silvano,
> > > 
> > > 	Perhaps I am reading your requirement incorrectly,
> > > but it sounds to me that it could be as easily addressed
> > > by requiring that implementations support a way to shut
> > > nickname-negotiation off.
> > > 
> > > 	Consider simply having a pair of management objects
> > > - one to disable auto-nickname negotiation, and another
> > > (which must be assigned a value if the first is disabled)
> > > that contains the configured nickname.
> > > 
> > > 	In my opinion, that would be a much more acceptable
> > > approach - especially in comparison with using priority
> > > as a mechanism for varying the outcome of auto-negotiation
> > > without actually turning it off.
> > > 
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > > 
> > > > -----Original Message-----
> > > > From: Silvano Gai [[e-mail]]
> > > > Sent: Wednesday, May 02, 2007 12:06 PM
> > > > To: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > Subject: RE: [rbridge] Optional configuration of RBridge 
> nickname> > > Importance: High
> > > >
> > > >
> > > > Eric,
> > > >
> > > > There is a strong requirement in Enterprise to disable any 
> form of
> > > > autoconfiguration. I requested Radia to support a way to 
> manually> > > configure Nicknames. I am not asking this being the 
> default,> > > but it must
> > > > be supported.
> > > >
> > > > The solution that Radia has put together is satisfactory 
> > for me. If
> > I
> > > > want to manually configure a nickname I will do it and set the
> > highest
> > > > priority.
> > > >
> > > > Lacking a secure authentication scheme the network can be 
> attacked> by
> > > > any PC in a much easier way.
> > > >
> > > > --Silvano
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > [[e-mail]]
> > > > On
> > > > > Behalf Of Eric Gray (LO/EUS)
> > > > > Sent: Wednesday, May 02, 2007 3:31 AM
> > > > > To: Radia Perlman; [e-mail]
> > > > > Subject: Re: [rbridge] Optional configuration of 
> > RBridge nickname
> > > > >
> > > > > Radia,
> > > > >
> > > > > 	I would object strenuously to the use of a priority
> > > > > value in resolving the "ownership" of a nickname.
> > > > >
> > > > > 	The over-riding priority has to be determined in a
> > > > > way that ensures the existing network continues to work
> > > > > if a new device is inserted (i.e. - it would be best if
> > > > > any device were going to fail, it should be the one that
> > > > > has just been added).
> > > > >
> > > > > 	Adding "priority" would allow any device to assert
> > > > > a high priority ownership of any nickname currently in
> > > > > use, which would then make it trivially easy to stage a
> > > > > network disabling attack.
> > > > >
> > > > > 	Having it be so easy to attack the network, would
> > > > > necessitate mandatory defenses, almost certainly meaning
> > > > > that configuration would be required - possibly excepting
> > > > > the option of having the very highest priority value be
> > > > > the default assumed when no configuration is done at any
> > > > > RBridge.
> > > > >
> > > > > 	In either case (configuration absolutely required,
> > > > > or default highest priority with no configuration) would
> > > > > defeat your purpose.
> > > > >
> > > > > --
> > > > > Eric Gray
> > > > > Principal Engineer
> > > > > Ericsson
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail]
> > > > > > [[e-mail]] On Behalf Of Radia Perlman
> > > > > > Sent: Wednesday, May 02, 2007 12:26 AM
> > > > > > To: [e-mail]
> > > > > > Subject: [rbridge] Optional configuration of RBridge 
> nickname> > > > >
> > > > > > Someone suggested that it would be useful to allow
> > > > configuration of
> > > > > > nicknames, so
> > > > > > that nicknames can be more stable, and there would be no
> > > > worry of an
> > > > > > RBridge coming
> > > > > > up and usurping a nickname from someone else. I'd like:
> > > > > > a) for it to remain possible to be zero configuration (as 
> in,> not
> > > > > > necessary to configure
> > > > > > a nickname
> > > > > > b) allow a mixture of configured and unconfigured nicknames
> > > > > > c) work even with misconfiguration (configuring two RBridges
> > with
> > > > the
> > > > > > same nickname)
> > > > > > d) never allow an unconfigured nickname to accidentally 
> usurp> > > > > a nickname
> > > > > > from
> > > > > > a ocnfigured RBridge
> > > > > >
> > > > > > So I'm proposing the following:
> > > > > >
> > > > > > a) allow configuration of a nickname value
> > > > > > b) have a "priority" value for owning a nickname
> > > > > > that can also be configured, which I'd propose would 
> > be an 8-bit
> > > > byte,
> > > > > > where only the bottom 7 bits can be configured
> > > > > > c) the 8th bit of the priority byte (the most significant
> > > > > > bit) indicates
> > > > > > whether
> > > > > > the nickname was configured or not
> > > > > > d) the default is priority=0 for RBridges that have not been
> > > > > > configured with
> > > > > > a nickname value, and priority=128 (top bit 1, rest 0) 
> for an
> > > > > > RBridge that
> > > > > > has been configured with a nickname
> > > > > > e) other values of nickname priority might be useful. For
> > > > > > instance, an
> > > > > > RBridge
> > > > > > implementation might increment the nickname value after it's
> > held
> > > > the
> > > > > > nickname
> > > > > > for some amount of time (say 10 minutes). Or someone might
> > > > > > want to configure
> > > > > > some RBridges to have a more stable nickname (by giving
> > > > them higher
> > > > > > priority).
> > > > > > f) Basically, the (nickname priority | system ID) is 
> > like the DR
> > > > > > priority in IS-IS,
> > > > > > where the DR election is based on (priority | system ID)
> > > > > >
> > > > > > Anyone object to this?
> > > > > >
> > > > > > 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 vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43EQqVB015900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 07:26:52 -0700 (PDT)
Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net [71.106.84.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l43EQevj026356; Thu, 3 May 2007 07:26:41 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 03 May 2007 07:26:22 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF6D578BE8ABE0D512341D92D"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 14:27:23 -0000
Status: RO
Content-Length: 1456

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF6D578BE8ABE0D512341D92D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Silvano Gai wrote:
> Joe,
=2E..
>> Current ethernet relies on spanning tree to avoid this; why not - as
> we
>> originally discussed - rely on spanning tree for broadcasts and
>> multicasts and then this ceases to be an issue...?
>>
>=20
> You miss one point.
>=20
> The Spanning Tree Protocol has an interlock mechanism that ABSOLUTELY
> guarantees no transient loops.
>=20
> A Spanning Tree based on an ISIS database will not have this interlock
> mechanism and transient loops will be possible.

My point is that maybe this means ISIS-based spanning tree isn't
appropriate. Multicast/broadcast cannot be effectively contained by TTL
alone.

Joe

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


--------------enigF6D578BE8ABE0D512341D92D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOfEOE5f5cImnZrsRAnJjAJ0Z6ccfbzejE0UGSauphE0F12lt0wCggrvi
Xn3ogI0+T7+VqMkFNrvPG08=
=eY/L
-----END PGP SIGNATURE-----

--------------enigF6D578BE8ABE0D512341D92D--



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 l43E8bs5011023 for <[e-mail]>; Thu, 3 May 2007 07:08:37 -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, 3 May 2007 07:08:32 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Optional configuration of RBridge nickname
Thread-Index: AceMc7uUR/qzTl66Sn2N6zS2CQqQvAAMCO3QAAu712AAAnk1EAANu4WgABwUPvAAAf64IA==
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[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 l43E8bs5011023
Cc: [e-mail]
Subject: Re: [rbridge] Optional configuration of RBridge nickname
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, 03 May 2007 14:08:53 -0000
Status: RO
Content-Length: 10200

Eric,

I am all in favor of KISS and I agree on your scenarios, but I am not
able to come up with a solution simpler than the one Radia proposed.

In Fibre Channel, FC-SW allowed only auto-configuration. The FCIDs
(nicknames) were selected in a way extremely similar to what TRILL
proposes. We had a strong push back from customers and we had to modify
the standard to allow manual configuration.

I just want to design it right from day 1 in TRILL

-- Silvano


> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> Sent: Thursday, May 03, 2007 6:25 AM
> To: Silvano Gai; Radia Perlman
> Cc: [e-mail]
> Subject: RE: [rbridge] Optional configuration of RBridge nickname
> 
> Silvano,
> 
> 	I believe that it is easily arguable that having a network
> in which some devices are configured not to negotiate, while the
> rest are not so configured (and default to negotiation) MUST be
> considered a configuration error.  In many ways, this SHOULD be
> considered the same sort of error as might occur if two devices
> were configured with the same value.
> 
> 	One mitigating factor for this particular configuration
> error is that one very likely way in which it would occur - i.e.
> - as a result of powering up an unconfigured device, is a "safe"
> operation if the (default) negotiation scheme favors the "status
> quo" assignment (as I believe we all have agreed it MUST).
> 
> 	Another likely pair of scenarios are as follows:
> 
> A) one in which a new device is added to an existing deployment
>    where the existing devices are using negotiation and the new
>    device is configured with a value that just happens to be the
>    same as one that an existing device has negotiated
> 
>    - is clearly analogous to -
> 
> B) one in which a new device is added to an existing deployment
>    where the existing devices are configured with values (and
>    not using negotiation) and the new device is configured with
>    the same value as one that has previously been configured
>    for an existing device.
> 
> 	I am reasonably confident that these SHOULD be viewed as
> simple configuration errors in both cases.
> 
> 	I suggest that it follows from this line of reasoning that
> it MUST always be possible to create a conflict situation as a
> result of configuration errors.  Hence it should also follow that
> a simpler approach is more desirable than a more complicated one.
> 
> 	As the saying goes, let's apply the KISS principle and do
> what makes the most direct sense in terms of the goal we want to
> achieve.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Wednesday, May 02, 2007 7:50 PM
> > To: Eric Gray (LO/EUS); Radia Perlman
> > Cc: [e-mail]
> > Subject: RE: [rbridge] Optional configuration of RBridge nickname
> > Importance: High
> >
> >
> > Eric,
> >
> > I think you are reading it correctly and having an implementation to
> > support a way to shut nickname-negotiation off is what we need.
> >
> > The problem is that after I have manually configured a nickname on
an
> > RBridge I need to be sure that no other RBridge in the network
selects
> > it.
> >
> > I also need to take into account that due to a mistake I can
manually
> > config the same nickname on two RBridges.
> >
> > One thing after the other we ended up with Radia proposal, but if
you
> > have a better one, we are happy to listen.
> >
> > Cheers
> >
> > -- Silvano
> >
> >
> >
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > Sent: Wednesday, May 02, 2007 10:17 AM
> > > To: Silvano Gai; Radia Perlman
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] Optional configuration of RBridge nickname
> > >
> > > Silvano,
> > >
> > > 	Perhaps I am reading your requirement incorrectly,
> > > but it sounds to me that it could be as easily addressed
> > > by requiring that implementations support a way to shut
> > > nickname-negotiation off.
> > >
> > > 	Consider simply having a pair of management objects
> > > - one to disable auto-nickname negotiation, and another
> > > (which must be assigned a value if the first is disabled)
> > > that contains the configured nickname.
> > >
> > > 	In my opinion, that would be a much more acceptable
> > > approach - especially in comparison with using priority
> > > as a mechanism for varying the outcome of auto-negotiation
> > > without actually turning it off.
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Wednesday, May 02, 2007 12:06 PM
> > > > To: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > > Subject: RE: [rbridge] Optional configuration of RBridge
nickname
> > > > Importance: High
> > > >
> > > >
> > > > Eric,
> > > >
> > > > There is a strong requirement in Enterprise to disable any form
of
> > > > autoconfiguration. I requested Radia to support a way to
manually
> > > > configure Nicknames. I am not asking this being the default,
> > > > but it must
> > > > be supported.
> > > >
> > > > The solution that Radia has put together is satisfactory
> > for me. If
> > I
> > > > want to manually configure a nickname I will do it and set the
> > highest
> > > > priority.
> > > >
> > > > Lacking a secure authentication scheme the network can be
attacked
> > by
> > > > any PC in a much easier way.
> > > >
> > > > --Silvano
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > [mailto:[e-mail]]
> > > > On
> > > > > Behalf Of Eric Gray (LO/EUS)
> > > > > Sent: Wednesday, May 02, 2007 3:31 AM
> > > > > To: Radia Perlman; [e-mail]
> > > > > Subject: Re: [rbridge] Optional configuration of
> > RBridge nickname
> > > > >
> > > > > Radia,
> > > > >
> > > > > 	I would object strenuously to the use of a priority
> > > > > value in resolving the "ownership" of a nickname.
> > > > >
> > > > > 	The over-riding priority has to be determined in a
> > > > > way that ensures the existing network continues to work
> > > > > if a new device is inserted (i.e. - it would be best if
> > > > > any device were going to fail, it should be the one that
> > > > > has just been added).
> > > > >
> > > > > 	Adding "priority" would allow any device to assert
> > > > > a high priority ownership of any nickname currently in
> > > > > use, which would then make it trivially easy to stage a
> > > > > network disabling attack.
> > > > >
> > > > > 	Having it be so easy to attack the network, would
> > > > > necessitate mandatory defenses, almost certainly meaning
> > > > > that configuration would be required - possibly excepting
> > > > > the option of having the very highest priority value be
> > > > > the default assumed when no configuration is done at any
> > > > > RBridge.
> > > > >
> > > > > 	In either case (configuration absolutely required,
> > > > > or default highest priority with no configuration) would
> > > > > defeat your purpose.
> > > > >
> > > > > --
> > > > > Eric Gray
> > > > > Principal Engineer
> > > > > Ericsson
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail]
> > > > > > [mailto:[e-mail]] On Behalf Of Radia
Perlman
> > > > > > Sent: Wednesday, May 02, 2007 12:26 AM
> > > > > > To: [e-mail]
> > > > > > Subject: [rbridge] Optional configuration of RBridge
nickname
> > > > > >
> > > > > > Someone suggested that it would be useful to allow
> > > > configuration of
> > > > > > nicknames, so
> > > > > > that nicknames can be more stable, and there would be no
> > > > worry of an
> > > > > > RBridge coming
> > > > > > up and usurping a nickname from someone else. I'd like:
> > > > > > a) for it to remain possible to be zero configuration (as
in,
> > not
> > > > > > necessary to configure
> > > > > > a nickname
> > > > > > b) allow a mixture of configured and unconfigured nicknames
> > > > > > c) work even with misconfiguration (configuring two RBridges
> > with
> > > > the
> > > > > > same nickname)
> > > > > > d) never allow an unconfigured nickname to accidentally
usurp
> > > > > > a nickname
> > > > > > from
> > > > > > a ocnfigured RBridge
> > > > > >
> > > > > > So I'm proposing the following:
> > > > > >
> > > > > > a) allow configuration of a nickname value
> > > > > > b) have a "priority" value for owning a nickname
> > > > > > that can also be configured, which I'd propose would
> > be an 8-bit
> > > > byte,
> > > > > > where only the bottom 7 bits can be configured
> > > > > > c) the 8th bit of the priority byte (the most significant
> > > > > > bit) indicates
> > > > > > whether
> > > > > > the nickname was configured or not
> > > > > > d) the default is priority=0 for RBridges that have not been
> > > > > > configured with
> > > > > > a nickname value, and priority=128 (top bit 1, rest 0) for
an
> > > > > > RBridge that
> > > > > > has been configured with a nickname
> > > > > > e) other values of nickname priority might be useful. For
> > > > > > instance, an
> > > > > > RBridge
> > > > > > implementation might increment the nickname value after it's
> > held
> > > > the
> > > > > > nickname
> > > > > > for some amount of time (say 10 minutes). Or someone might
> > > > > > want to configure
> > > > > > some RBridges to have a more stable nickname (by giving
> > > > them higher
> > > > > > priority).
> > > > > > f) Basically, the (nickname priority | system ID) is
> > like the DR
> > > > > > priority in IS-IS,
> > > > > > where the DR election is based on (priority | system ID)
> > > > > >
> > > > > > Anyone object to this?
> > > > > >
> > > > > > 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 imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l43DOdwv000992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 3 May 2007 06:24:39 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l43DO2bv030897; Thu, 3 May 2007 08:24:02 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 3 May 2007 08:24:37 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 3 May 2007 08:24:33 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Optional configuration of RBridge nickname
Thread-Index: AceMc7uUR/qzTl66Sn2N6zS2CQqQvAAMCO3QAAu712AAAnk1EAANu4WgABwUPvA=
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 03 May 2007 13:24:37.0797 (UTC) FILETIME=[65E4B550:01C78D86]
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 l43DOdwv000992
Cc: [e-mail]
Subject: Re: [rbridge] Optional configuration of RBridge nickname
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, 03 May 2007 13:24:56 -0000
Status: RO
Content-Length: 9007

Silvano,

	I believe that it is easily arguable that having a network
in which some devices are configured not to negotiate, while the
rest are not so configured (and default to negotiation) MUST be 
considered a configuration error.  In many ways, this SHOULD be 
considered the same sort of error as might occur if two devices 
were configured with the same value.

	One mitigating factor for this particular configuration 
error is that one very likely way in which it would occur - i.e.
- as a result of powering up an unconfigured device, is a "safe"
operation if the (default) negotiation scheme favors the "status
quo" assignment (as I believe we all have agreed it MUST).

	Another likely pair of scenarios are as follows:

A) one in which a new device is added to an existing deployment 
   where the existing devices are using negotiation and the new 
   device is configured with a value that just happens to be the
   same as one that an existing device has negotiated 

   - is clearly analogous to -

B) one in which a new device is added to an existing deployment
   where the existing devices are configured with values (and
   not using negotiation) and the new device is configured with
   the same value as one that has previously been configured 
   for an existing device.

	I am reasonably confident that these SHOULD be viewed as
simple configuration errors in both cases.

	I suggest that it follows from this line of reasoning that
it MUST always be possible to create a conflict situation as a 
result of configuration errors.  Hence it should also follow that
a simpler approach is more desirable than a more complicated one.

	As the saying goes, let's apply the KISS principle and do
what makes the most direct sense in terms of the goal we want to
achieve.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Wednesday, May 02, 2007 7:50 PM
> To: Eric Gray (LO/EUS); Radia Perlman
> Cc: [e-mail]
> Subject: RE: [rbridge] Optional configuration of RBridge nickname
> Importance: High
> 
> 
> Eric, 
> 
> I think you are reading it correctly and having an implementation to
> support a way to shut nickname-negotiation off is what we need.
> 
> The problem is that after I have manually configured a nickname on an
> RBridge I need to be sure that no other RBridge in the network selects
> it.
> 
> I also need to take into account that due to a mistake I can manually
> config the same nickname on two RBridges.
> 
> One thing after the other we ended up with Radia proposal, but if you
> have a better one, we are happy to listen.
> 
> Cheers
> 
> -- Silvano
> 
> 
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > Sent: Wednesday, May 02, 2007 10:17 AM
> > To: Silvano Gai; Radia Perlman
> > Cc: [e-mail]
> > Subject: RE: [rbridge] Optional configuration of RBridge nickname
> > 
> > Silvano,
> > 
> > 	Perhaps I am reading your requirement incorrectly,
> > but it sounds to me that it could be as easily addressed
> > by requiring that implementations support a way to shut
> > nickname-negotiation off.
> > 
> > 	Consider simply having a pair of management objects
> > - one to disable auto-nickname negotiation, and another
> > (which must be assigned a value if the first is disabled)
> > that contains the configured nickname.
> > 
> > 	In my opinion, that would be a much more acceptable
> > approach - especially in comparison with using priority
> > as a mechanism for varying the outcome of auto-negotiation
> > without actually turning it off.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Wednesday, May 02, 2007 12:06 PM
> > > To: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > > Subject: RE: [rbridge] Optional configuration of RBridge nickname
> > > Importance: High
> > >
> > >
> > > Eric,
> > >
> > > There is a strong requirement in Enterprise to disable any form of
> > > autoconfiguration. I requested Radia to support a way to manually
> > > configure Nicknames. I am not asking this being the default,
> > > but it must
> > > be supported.
> > >
> > > The solution that Radia has put together is satisfactory 
> for me. If
> I
> > > want to manually configure a nickname I will do it and set the
> highest
> > > priority.
> > >
> > > Lacking a secure authentication scheme the network can be attacked
> by
> > > any PC in a much easier way.
> > >
> > > --Silvano
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> [mailto:[e-mail]]
> > > On
> > > > Behalf Of Eric Gray (LO/EUS)
> > > > Sent: Wednesday, May 02, 2007 3:31 AM
> > > > To: Radia Perlman; [e-mail]
> > > > Subject: Re: [rbridge] Optional configuration of 
> RBridge nickname
> > > >
> > > > Radia,
> > > >
> > > > 	I would object strenuously to the use of a priority
> > > > value in resolving the "ownership" of a nickname.
> > > >
> > > > 	The over-riding priority has to be determined in a
> > > > way that ensures the existing network continues to work
> > > > if a new device is inserted (i.e. - it would be best if
> > > > any device were going to fail, it should be the one that
> > > > has just been added).
> > > >
> > > > 	Adding "priority" would allow any device to assert
> > > > a high priority ownership of any nickname currently in
> > > > use, which would then make it trivially easy to stage a
> > > > network disabling attack.
> > > >
> > > > 	Having it be so easy to attack the network, would
> > > > necessitate mandatory defenses, almost certainly meaning
> > > > that configuration would be required - possibly excepting
> > > > the option of having the very highest priority value be
> > > > the default assumed when no configuration is done at any
> > > > RBridge.
> > > >
> > > > 	In either case (configuration absolutely required,
> > > > or default highest priority with no configuration) would
> > > > defeat your purpose.
> > > >
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > > > > [mailto:[e-mail]] On Behalf Of Radia Perlman
> > > > > Sent: Wednesday, May 02, 2007 12:26 AM
> > > > > To: [e-mail]
> > > > > Subject: [rbridge] Optional configuration of RBridge nickname
> > > > >
> > > > > Someone suggested that it would be useful to allow
> > > configuration of
> > > > > nicknames, so
> > > > > that nicknames can be more stable, and there would be no
> > > worry of an
> > > > > RBridge coming
> > > > > up and usurping a nickname from someone else. I'd like:
> > > > > a) for it to remain possible to be zero configuration (as in,
> not
> > > > > necessary to configure
> > > > > a nickname
> > > > > b) allow a mixture of configured and unconfigured nicknames
> > > > > c) work even with misconfiguration (configuring two RBridges
> with
> > > the
> > > > > same nickname)
> > > > > d) never allow an unconfigured nickname to accidentally usurp
> > > > > a nickname
> > > > > from
> > > > > a ocnfigured RBridge
> > > > >
> > > > > So I'm proposing the following:
> > > > >
> > > > > a) allow configuration of a nickname value
> > > > > b) have a "priority" value for owning a nickname
> > > > > that can also be configured, which I'd propose would 
> be an 8-bit
> > > byte,
> > > > > where only the bottom 7 bits can be configured
> > > > > c) the 8th bit of the priority byte (the most significant
> > > > > bit) indicates
> > > > > whether
> > > > > the nickname was configured or not
> > > > > d) the default is priority=0 for RBridges that have not been
> > > > > configured with
> > > > > a nickname value, and priority=128 (top bit 1, rest 0) for an
> > > > > RBridge that
> > > > > has been configured with a nickname
> > > > > e) other values of nickname priority might be useful. For
> > > > > instance, an
> > > > > RBridge
> > > > > implementation might increment the nickname value after it's
> held
> > > the
> > > > > nickname
> > > > > for some amount of time (say 10 minutes). Or someone might
> > > > > want to configure
> > > > > some RBridges to have a more stable nickname (by giving
> > > them higher
> > > > > priority).
> > > > > f) Basically, the (nickname priority | system ID) is 
> like the DR
> > > > > priority in IS-IS,
> > > > > where the DR election is based on (priority | system ID)
> > > > >
> > > > > Anyone object to this?
> > > > >
> > > > > 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 smtp1.sgsi.ucl.ac.be (smtp-1.dynsipr.ucl.ac.be [130.104.4.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l430qure026425 for <[e-mail]>; Wed, 2 May 2007 17:52:57 -0700 (PDT)
Received: from smtp1.sgsi.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTP id 31C252C9C3; Thu,  3 May 2007 02:53:00 +0200 (CEST)
Received: from [192.168.1.2] (213.42-64-87.adsl-dyn.isp.belgacom.be [87.64.42.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: [e-mail]) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTP; Thu,  3 May 2007 02:53:00 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 03 May 2007 02:52:55 +0200
From: Pierre Francois <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[e-mail]> <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AV-Checked: ClamAV using ClamSMTP
X-SGSI-MailScanner: Found to be clean
X-SGSI-SpamCheck: 
X-SGSI-From: [e-mail]
X-SGSI-Spam-Status: No
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>, Joe Touch <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail]
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 May 2007 00:53:03 -0000
Status: RO
Content-Length: 3047

Silvano,

You can expand ofib to avoid loop storms in multicast.
Very roughly, the idea is that you (a node) update the incoming 
interface that suceeds the rpf check for a given S,G after the ones that 
are below you in the initial S,G tree.
In other words, you order the transition of nodes in the tree from the 
leaves towards the root.

Sorry to be so short, but I've got a ph. thesis to submit by tomorrow ;-)

Cheers,
Pierre.


Silvano Gai wrote:
> We discussed that possibility, but unfortunately
> draft-ietf-rtgwg-ordered-fib-00 does not apply to multicast
>
> -- Silvano
>
>   
>> -----Original Message-----
>> From: Pierre Francois [mailto:[e-mail]]
>> Sent: Wednesday, May 02, 2007 5:02 PM
>> To: Silvano Gai
>> Cc: Joe Touch; [e-mail]; Radia Perlman
>> Subject: Re: [rbridge] Setting initial "hop count" value
>>
>>
>> All,
>>
>> Use draft-ietf-rtgwg-ordered-fib-00.
>>
>> Just kidding ;-)
>>
>> Pierre.
>>
>> Silvano Gai wrote:
>>     
>>> Joe,
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From: Joe Touch [mailto:[e-mail]]
>>>> Sent: Wednesday, May 02, 2007 4:37 PM
>>>> To: Silvano Gai
>>>> Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
>>>> Subject: Re: [rbridge] Setting initial "hop count" value
>>>>
>>>>
>>>>
>>>> Silvano Gai wrote:
>>>>
>>>>         
>>>>> Joe,
>>>>>
>>>>>           
>>>> ...
>>>>
>>>>         
>>>>> It is a doomsday scenario: if you have seen a broadcast storm you
>>>>>
>>>>>           
>>> don't
>>>
>>>       
>>>>> want to see another one.
>>>>>
>>>>> Granted there are measure that have been put in place to limit the
>>>>> possibility that this happens, for example today bridges have
>>>>>
>>>>>           
>>> separate
>>>
>>>       
>>>>> queues for BPDUs, but we still need to be EXTREMELY careful
>>>>>
>>>>>           
>>>> All great reasons for not relying on TTLs to bail you out of a
>>>>         
> storm.
>   
>>> A
>>>
>>>       
>>>> TTL of N can result in K^N/J copies if it loops through just one
>>>> replication point with K outputs with a loop length of J. Given
>>>>         
> loop
>   
>>>> lengths could be 2-3, what TTL is reasonable to prevent this sort
>>>>         
> of
>   
>>>> blowup that isn't going to impact the reachability diameter?
>>>>
>>>> Current ethernet relies on spanning tree to avoid this; why not -
>>>>         
> as
>   
>>> we
>>>
>>>       
>>>> originally discussed - rely on spanning tree for broadcasts and
>>>> multicasts and then this ceases to be an issue...?
>>>>
>>>>
>>>>         
>>> You miss one point.
>>>
>>> The Spanning Tree Protocol has an interlock mechanism that
>>>       
> ABSOLUTELY
>   
>>> guarantees no transient loops.
>>>
>>> A Spanning Tree based on an ISIS database will not have this
>>>       
> interlock
>   
>>> mechanism and transient loops will be possible.
>>>
>>> -- Silvano
>>>
>>> _______________________________________________
>>> 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 l430X2gU022323 for <[e-mail]>; Wed, 2 May 2007 17:33:02 -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: Wed, 2 May 2007 17:32:56 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNFkcQwBZNr7wSRq2yJT0lKUGXIAABDSaQ
References: <[e-mail]> <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: <[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 l430X2gU022323
Cc: [e-mail], Radia Perlman <[e-mail]>, Joe Touch <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 03 May 2007 00:33:36 -0000
Status: RO
Content-Length: 2272

We discussed that possibility, but unfortunately
draft-ietf-rtgwg-ordered-fib-00 does not apply to multicast

-- Silvano

> -----Original Message-----
> From: Pierre Francois [mailto:[e-mail]]
> Sent: Wednesday, May 02, 2007 5:02 PM
> To: Silvano Gai
> Cc: Joe Touch; [e-mail]; Radia Perlman
> Subject: Re: [rbridge] Setting initial "hop count" value
> 
> 
> All,
> 
> Use draft-ietf-rtgwg-ordered-fib-00.
> 
> Just kidding ;-)
> 
> Pierre.
> 
> Silvano Gai wrote:
> > Joe,
> >
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[e-mail]]
> >> Sent: Wednesday, May 02, 2007 4:37 PM
> >> To: Silvano Gai
> >> Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> >> Subject: Re: [rbridge] Setting initial "hop count" value
> >>
> >>
> >>
> >> Silvano Gai wrote:
> >>
> >>> Joe,
> >>>
> >> ...
> >>
> >>> It is a doomsday scenario: if you have seen a broadcast storm you
> >>>
> > don't
> >
> >>> want to see another one.
> >>>
> >>> Granted there are measure that have been put in place to limit the
> >>> possibility that this happens, for example today bridges have
> >>>
> > separate
> >
> >>> queues for BPDUs, but we still need to be EXTREMELY careful
> >>>
> >> All great reasons for not relying on TTLs to bail you out of a
storm.
> >>
> > A
> >
> >> TTL of N can result in K^N/J copies if it loops through just one
> >> replication point with K outputs with a loop length of J. Given
loop
> >> lengths could be 2-3, what TTL is reasonable to prevent this sort
of
> >> blowup that isn't going to impact the reachability diameter?
> >>
> >> Current ethernet relies on spanning tree to avoid this; why not -
as
> >>
> > we
> >
> >> originally discussed - rely on spanning tree for broadcasts and
> >> multicasts and then this ceases to be an issue...?
> >>
> >>
> >
> > You miss one point.
> >
> > The Spanning Tree Protocol has an interlock mechanism that
ABSOLUTELY
> > guarantees no transient loops.
> >
> > A Spanning Tree based on an ISIS database will not have this
interlock
> > mechanism and transient loops will be possible.
> >
> > -- Silvano
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> >




Received: from smtp1.sgsi.ucl.ac.be (smtp-1.dynsipr.ucl.ac.be [130.104.4.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l4301XV4015755 for <[e-mail]>; Wed, 2 May 2007 17:01:34 -0700 (PDT)
Received: from smtp1.sgsi.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTP id 88D122C9DC; Thu,  3 May 2007 02:01:36 +0200 (CEST)
Received: from [192.168.1.2] (213.42-64-87.adsl-dyn.isp.belgacom.be [87.64.42.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: [e-mail]) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTP; Thu,  3 May 2007 02:01:36 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 03 May 2007 02:01:31 +0200
From: Pierre Francois <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[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
X-AV-Checked: ClamAV using ClamSMTP
X-SGSI-MailScanner: Found to be clean
X-SGSI-SpamCheck: 
X-SGSI-From: [e-mail]
X-SGSI-Spam-Status: No
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>, Joe Touch <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail]
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 May 2007 00:02:03 -0000
Status: RO
Content-Length: 1817

All,

Use draft-ietf-rtgwg-ordered-fib-00.

Just kidding ;-)

Pierre.

Silvano Gai wrote:
> Joe,
>
>   
>> -----Original Message-----
>> From: Joe Touch [mailto:[e-mail]]
>> Sent: Wednesday, May 02, 2007 4:37 PM
>> To: Silvano Gai
>> Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
>> Subject: Re: [rbridge] Setting initial "hop count" value
>>
>>
>>
>> Silvano Gai wrote:
>>     
>>> Joe,
>>>       
>> ...
>>     
>>> It is a doomsday scenario: if you have seen a broadcast storm you
>>>       
> don't
>   
>>> want to see another one.
>>>
>>> Granted there are measure that have been put in place to limit the
>>> possibility that this happens, for example today bridges have
>>>       
> separate
>   
>>> queues for BPDUs, but we still need to be EXTREMELY careful
>>>       
>> All great reasons for not relying on TTLs to bail you out of a storm.
>>     
> A
>   
>> TTL of N can result in K^N/J copies if it loops through just one
>> replication point with K outputs with a loop length of J. Given loop
>> lengths could be 2-3, what TTL is reasonable to prevent this sort of
>> blowup that isn't going to impact the reachability diameter?
>>
>> Current ethernet relies on spanning tree to avoid this; why not - as
>>     
> we
>   
>> originally discussed - rely on spanning tree for broadcasts and
>> multicasts and then this ceases to be an issue...?
>>
>>     
>
> You miss one point.
>
> The Spanning Tree Protocol has an interlock mechanism that ABSOLUTELY
> guarantees no transient loops.
>
> A Spanning Tree based on an ISIS database will not have this interlock
> mechanism and transient loops will be possible.
>
> -- Silvano
>
> _______________________________________________
> 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 l42NoKBe013151 for <[e-mail]>; Wed, 2 May 2007 16:50:20 -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: Wed, 2 May 2007 16:50:12 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Optional configuration of RBridge nickname
Thread-Index: AceMc7uUR/qzTl66Sn2N6zS2CQqQvAAMCO3QAAu712AAAnk1EAANu4Wg
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[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 l42NoKBe013151
Cc: [e-mail]
Subject: Re: [rbridge] Optional configuration of RBridge nickname
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, 02 May 2007 23:50:37 -0000
Status: RO
Content-Length: 6496

Eric, 

I think you are reading it correctly and having an implementation to
support a way to shut nickname-negotiation off is what we need.

The problem is that after I have manually configured a nickname on an
RBridge I need to be sure that no other RBridge in the network selects
it.

I also need to take into account that due to a mistake I can manually
config the same nickname on two RBridges.

One thing after the other we ended up with Radia proposal, but if you
have a better one, we are happy to listen.

Cheers

-- Silvano



> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> Sent: Wednesday, May 02, 2007 10:17 AM
> To: Silvano Gai; Radia Perlman
> Cc: [e-mail]
> Subject: RE: [rbridge] Optional configuration of RBridge nickname
> 
> Silvano,
> 
> 	Perhaps I am reading your requirement incorrectly,
> but it sounds to me that it could be as easily addressed
> by requiring that implementations support a way to shut
> nickname-negotiation off.
> 
> 	Consider simply having a pair of management objects
> - one to disable auto-nickname negotiation, and another
> (which must be assigned a value if the first is disabled)
> that contains the configured nickname.
> 
> 	In my opinion, that would be a much more acceptable
> approach - especially in comparison with using priority
> as a mechanism for varying the outcome of auto-negotiation
> without actually turning it off.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Wednesday, May 02, 2007 12:06 PM
> > To: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> > Subject: RE: [rbridge] Optional configuration of RBridge nickname
> > Importance: High
> >
> >
> > Eric,
> >
> > There is a strong requirement in Enterprise to disable any form of
> > autoconfiguration. I requested Radia to support a way to manually
> > configure Nicknames. I am not asking this being the default,
> > but it must
> > be supported.
> >
> > The solution that Radia has put together is satisfactory for me. If
I
> > want to manually configure a nickname I will do it and set the
highest
> > priority.
> >
> > Lacking a secure authentication scheme the network can be attacked
by
> > any PC in a much easier way.
> >
> > --Silvano
> >
> > > -----Original Message-----
> > > From: [e-mail]
[mailto:[e-mail]]
> > On
> > > Behalf Of Eric Gray (LO/EUS)
> > > Sent: Wednesday, May 02, 2007 3:31 AM
> > > To: Radia Perlman; [e-mail]
> > > Subject: Re: [rbridge] Optional configuration of RBridge nickname
> > >
> > > Radia,
> > >
> > > 	I would object strenuously to the use of a priority
> > > value in resolving the "ownership" of a nickname.
> > >
> > > 	The over-riding priority has to be determined in a
> > > way that ensures the existing network continues to work
> > > if a new device is inserted (i.e. - it would be best if
> > > any device were going to fail, it should be the one that
> > > has just been added).
> > >
> > > 	Adding "priority" would allow any device to assert
> > > a high priority ownership of any nickname currently in
> > > use, which would then make it trivially easy to stage a
> > > network disabling attack.
> > >
> > > 	Having it be so easy to attack the network, would
> > > necessitate mandatory defenses, almost certainly meaning
> > > that configuration would be required - possibly excepting
> > > the option of having the very highest priority value be
> > > the default assumed when no configuration is done at any
> > > RBridge.
> > >
> > > 	In either case (configuration absolutely required,
> > > or default highest priority with no configuration) would
> > > defeat your purpose.
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of Radia Perlman
> > > > Sent: Wednesday, May 02, 2007 12:26 AM
> > > > To: [e-mail]
> > > > Subject: [rbridge] Optional configuration of RBridge nickname
> > > >
> > > > Someone suggested that it would be useful to allow
> > configuration of
> > > > nicknames, so
> > > > that nicknames can be more stable, and there would be no
> > worry of an
> > > > RBridge coming
> > > > up and usurping a nickname from someone else. I'd like:
> > > > a) for it to remain possible to be zero configuration (as in,
not
> > > > necessary to configure
> > > > a nickname
> > > > b) allow a mixture of configured and unconfigured nicknames
> > > > c) work even with misconfiguration (configuring two RBridges
with
> > the
> > > > same nickname)
> > > > d) never allow an unconfigured nickname to accidentally usurp
> > > > a nickname
> > > > from
> > > > a ocnfigured RBridge
> > > >
> > > > So I'm proposing the following:
> > > >
> > > > a) allow configuration of a nickname value
> > > > b) have a "priority" value for owning a nickname
> > > > that can also be configured, which I'd propose would be an 8-bit
> > byte,
> > > > where only the bottom 7 bits can be configured
> > > > c) the 8th bit of the priority byte (the most significant
> > > > bit) indicates
> > > > whether
> > > > the nickname was configured or not
> > > > d) the default is priority=0 for RBridges that have not been
> > > > configured with
> > > > a nickname value, and priority=128 (top bit 1, rest 0) for an
> > > > RBridge that
> > > > has been configured with a nickname
> > > > e) other values of nickname priority might be useful. For
> > > > instance, an
> > > > RBridge
> > > > implementation might increment the nickname value after it's
held
> > the
> > > > nickname
> > > > for some amount of time (say 10 minutes). Or someone might
> > > > want to configure
> > > > some RBridges to have a more stable nickname (by giving
> > them higher
> > > > priority).
> > > > f) Basically, the (nickname priority | system ID) is like the DR
> > > > priority in IS-IS,
> > > > where the DR election is based on (priority | system ID)
> > > >
> > > > Anyone object to this?
> > > >
> > > > 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 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 l42Nkent012007 for <[e-mail]>; Wed, 2 May 2007 16:46:40 -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: Wed, 2 May 2007 16:46:33 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNE7n/0RQ0UyQ3SXm+IM/xanRYBgAACbpQ
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Joe Touch" <[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 l42Nkent012007
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 23:47:02 -0000
Status: RO
Content-Length: 1875

Joe

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Wednesday, May 02, 2007 4:43 PM
> To: Silvano Gai
> Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> Subject: Re: [rbridge] Setting initial "hop count" value
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> ...
> >>> Loops are much more dangerous at layer 2 than at layer 3. I am
> >>> sympathetic with Radia that anything we can do to mitigate them is
> > good.
> >> This is why we ought to be using a spanning tree for those,
> >
> > You are not claiming that we need to run the Spanning Tree Protocol,
> > correct?
> 
> No; I was claiming that there's a legitimate reason to still have a
> spanning tree inside the campus.
> 

Agreed, we are in synch.

> > and let that
> >> tree be suboptimal and/or converge via means that avoid looping
> >> transients.
> >
> > This is not easy. Radia RPF proposal seems a good start, but it is:
> > - not agreed yet
> > - Unproven
> >
> > It is pretty straightforward to use Radia RPF proposal to reduce the
> > probability of transient loops. If you want to "GUARANTEE" that
there
> > are no transient loops, that is a different story, since it has a
> > significant state requirement that can impact low end
implementation. I
> > am all for it, but we need to discuss it in a separate thread.
> 
> Agreed; I'm not convinced that such transients aren't OK if they exist
> with conventional implementations. 

They don't. Today the Spanning Tree protocol never generates a transient
loop. 

-- Silvano

Remember that rbridges aren't
> intended to scale beyond current implementations, which means that
> however existing implementations support spanning trees and deal (or
> don't) with transient loops should map here just fine.
> 
> Joe
> --
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment




Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42NhIFM011163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 16:43:18 -0700 (PDT)
Received: from [127.0.0.1] (25.sub-75-215-133.myvzw.com [75.215.133.25]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l42Ngs0g008361; Wed, 2 May 2007 16:43:02 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 02 May 2007 16:42:31 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig27B86727AD39F0A8196F1EEB"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 23:43:32 -0000
Status: RO
Content-Length: 2138

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig27B86727AD39F0A8196F1EEB
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Silvano Gai wrote:
> Joe,
=2E..
>>> Loops are much more dangerous at layer 2 than at layer 3. I am
>>> sympathetic with Radia that anything we can do to mitigate them is
> good.
>> This is why we ought to be using a spanning tree for those,=20
>=20
> You are not claiming that we need to run the Spanning Tree Protocol,
> correct?

No; I was claiming that there's a legitimate reason to still have a
spanning tree inside the campus.

> and let that
>> tree be suboptimal and/or converge via means that avoid looping
>> transients.=20
>=20
> This is not easy. Radia RPF proposal seems a good start, but it is:
> - not agreed yet
> - Unproven
>=20
> It is pretty straightforward to use Radia RPF proposal to reduce the
> probability of transient loops. If you want to "GUARANTEE" that there
> are no transient loops, that is a different story, since it has a
> significant state requirement that can impact low end implementation. I=

> am all for it, but we need to discuss it in a separate thread.

Agreed; I'm not convinced that such transients aren't OK if they exist
with conventional implementations. Remember that rbridges aren't
intended to scale beyond current implementations, which means that
however existing implementations support spanning trees and deal (or
don't) with transient loops should map here just fine.

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


--------------enig27B86727AD39F0A8196F1EEB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOSHnE5f5cImnZrsRArZ9AKDLVHnolqlTLZiTHWBVJCyBw/ba+wCfcoRU
qbqj/cGgNgrGHBXBBufHct0=
=CY+u
-----END PGP SIGNATURE-----

--------------enig27B86727AD39F0A8196F1EEB--



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 l42Ng7lN010920 for <[e-mail]>; Wed, 2 May 2007 16:42:07 -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: Wed, 2 May 2007 16:42:02 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceNEuipY89iFdfYTeqiNXtq7pBphAAACLPQ
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Joe Touch" <[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 l42Ng7lN010920
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 23:42:31 -0000
Status: RO
Content-Length: 1421

Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Wednesday, May 02, 2007 4:37 PM
> To: Silvano Gai
> Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> Subject: Re: [rbridge] Setting initial "hop count" value
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> ...
> > It is a doomsday scenario: if you have seen a broadcast storm you
don't
> > want to see another one.
> >
> > Granted there are measure that have been put in place to limit the
> > possibility that this happens, for example today bridges have
separate
> > queues for BPDUs, but we still need to be EXTREMELY careful
> 
> All great reasons for not relying on TTLs to bail you out of a storm.
A
> TTL of N can result in K^N/J copies if it loops through just one
> replication point with K outputs with a loop length of J. Given loop
> lengths could be 2-3, what TTL is reasonable to prevent this sort of
> blowup that isn't going to impact the reachability diameter?
> 
> Current ethernet relies on spanning tree to avoid this; why not - as
we
> originally discussed - rely on spanning tree for broadcasts and
> multicasts and then this ceases to be an issue...?
> 

You miss one point.

The Spanning Tree Protocol has an interlock mechanism that ABSOLUTELY
guarantees no transient loops.

A Spanning Tree based on an ISIS database will not have this interlock
mechanism and transient loops will be possible.

-- Silvano



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42NbRlE009861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 16:37:27 -0700 (PDT)
Received: from [127.0.0.1] (25.sub-75-215-133.myvzw.com [75.215.133.25]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l42Nb6D9007445; Wed, 2 May 2007 16:37:09 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 02 May 2007 16:36:48 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE733C889F8086F6A1A962E30"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 23:37:31 -0000
Status: RO
Content-Length: 1682

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE733C889F8086F6A1A962E30
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Silvano Gai wrote:
> Joe,
=2E..
> It is a doomsday scenario: if you have seen a broadcast storm you don't=

> want to see another one.
>=20
> Granted there are measure that have been put in place to limit the
> possibility that this happens, for example today bridges have separate
> queues for BPDUs, but we still need to be EXTREMELY careful

All great reasons for not relying on TTLs to bail you out of a storm. A
TTL of N can result in K^N/J copies if it loops through just one
replication point with K outputs with a loop length of J. Given loop
lengths could be 2-3, what TTL is reasonable to prevent this sort of
blowup that isn't going to impact the reachability diameter?

Current ethernet relies on spanning tree to avoid this; why not - as we
originally discussed - rely on spanning tree for broadcasts and
multicasts and then this ceases to be an issue...?

Joe

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


--------------enigE733C889F8086F6A1A962E30
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOSCQE5f5cImnZrsRApfBAKCwIT2K5xd/ZXdoHSOuT39vvJJPewCeLJ42
jyqekqLtNfIMqYo0gIKyGJQ=
=SpHd
-----END PGP SIGNATURE-----

--------------enigE733C889F8086F6A1A962E30--



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 l42Na2dF009766 for <[e-mail]>; Wed, 2 May 2007 16:36:03 -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: Wed, 2 May 2007 16:35:57 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceM/MbdBogcVYNWS8mvKMnHDEvOAwAFMiqA
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Joe Touch" <[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 l42Na2dF009766
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 23:36:29 -0000
Status: RO
Content-Length: 1324

Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Wednesday, May 02, 2007 1:58 PM
> To: Silvano Gai
> Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> Subject: Re: [rbridge] Setting initial "hop count" value
> 
> 
> 
> Silvano Gai wrote:
> > Eric,
> >
> > It is a tree only when the topology is stable; in transient is not a
> > tree. Loops happen during transition.
> >
> > Joe,
> >
> > Loops are much more dangerous at layer 2 than at layer 3. I am
> > sympathetic with Radia that anything we can do to mitigate them is
good.
> 
> This is why we ought to be using a spanning tree for those, 

You are not claiming that we need to run the Spanning Tree Protocol,
correct?

and let that
> tree be suboptimal and/or converge via means that avoid looping
> transients. 

This is not easy. Radia RPF proposal seems a good start, but it is:
- not agreed yet
- Unproven

It is pretty straightforward to use Radia RPF proposal to reduce the
probability of transient loops. If you want to "GUARANTEE" that there
are no transient loops, that is a different story, since it has a
significant state requirement that can impact low end implementation. I
am all for it, but we need to discuss it in a separate thread.

-- Silvano



It's not a good reason to over-tune TTL at L2.
> 
> Joe




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 l42NS5d1007997 for <[e-mail]>; Wed, 2 May 2007 16:28:05 -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: Wed, 2 May 2007 16:28:00 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceM/0RwtKCuJT05SDy3zxa6ucqPvgAD7IOw
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Joe Touch" <[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 l42NS5d1007997
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 23:28:29 -0000
Status: RO
Content-Length: 2519

Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Wednesday, May 02, 2007 2:16 PM
> To: Silvano Gai
> Cc: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> Subject: Re: [rbridge] Setting initial "hop count" value
> 
> 
> 
> Silvano Gai wrote:
> ...
> > Joe,
> >
> > Loops are much more dangerous at layer 2 than at layer 3. I am
> > sympathetic with Radia that anything we can do to mitigate them is
good.
> >
> > -- Silvano
> 
> I cannot understand why that would be true. Resources are more
> constrained and impact more users at L3.
> 

There are many many reasons. 

1) The problem is with all multidestination frames, but it is
particularly severe with Ethernet Broadcast. The reason is that all the
stations (switches, RBridges, routers, hosts, etc) are mandate to
receive broadcast.

ROUTERS DO NOT PROPAGATE BROADCAST AND THIS IS A HUGE DIFFERENCE BETWEEN
L2 AND L3. 

2) Loop tend to be shorter at layer 2 (few hops, let's say 4)

3) RBridge latency will probably be very low (500 ns)

4) A frame can complete a loop in 2 microseconds

5) the spikes of broadcast traffic will be very intense and will
saturate all the receiving queues of all the stations (again hosts,
RBridges ...)

6) these broadcast frames will sit in front of the IS-IS frames and
contend for CPU resources

7) the ISIS convergence time will get worst. In a limit case, ISIS will
never converge

8) Anyhow, the IS-IS converges times is probably 4 or more order of
magnitude greater than the time it takes a frame to loop.

9) I have seen network coming to a complete stop. The only way to
restart them was to power cycle.

10) As soon as the broadcast storm start, all the host crashes (due to
the broadcast in the RX queues).

It is a doomsday scenario: if you have seen a broadcast storm you don't
want to see another one.

Granted there are measure that have been put in place to limit the
possibility that this happens, for example today bridges have separate
queues for BPDUs, but we still need to be EXTREMELY careful

-- Silvano


> While mitigating loops is good, I see no reason not to apply what we
> know and have learned from L3 here, which is that TTL may matter for
> multicast scoping, but it isn't the dominant mitigation for copy
loops.
> See RFC2365, which lists many reasons for using TTL in multicast, but
> doesn't talk about copy loop (e.g., see Sec 3).
> 
> Joe
> 
> --
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment




Received: from betonmix.noc.ams-ix.net (betonmix.noc.ams-ix.net [193.194.136.135]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42MQE3Y025732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 15:26:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id 6A6EE1027A5; Thu,  3 May 2007 00:26:13 +0200 (CEST)
Received: from [192.168.1.68] (orkano.xs4all.nl [213.84.188.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id 392E11027A2; Thu,  3 May 2007 00:26:13 +0200 (CEST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Arien Vijn <[e-mail]>
Date: Thu, 3 May 2007 00:26:11 +0200
To: Joe Touch <[e-mail]>
X-Pgp-Agent: GPGMail 1.1.2 (Tiger)
X-Mailer: Apple Mail (2.752.2)
X-Virus-Scanned: by amavisd-new at betonmix.noc.ams-ix.net
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 22:26:28 -0000
Status: RO
Content-Length: 1148

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

Hello,

On May 2, 2007, at 11:16 PM, Joe Touch wrote:

> Silvano Gai wrote:
> ...
>> Joe,
>>
>> Loops are much more dangerous at layer 2 than at layer 3. I am
>> sympathetic with Radia that anything we can do to mitigate them is  
>> good.
>>
>> -- Silvano
>
> I cannot understand why that would be true. Resources are more
> constrained and impact more users at L3.

[...]

It is absolutely true for self-learning ethernet switches.

Ethernet loops cause station movements. The source mac address of a  
looped frame gets learned behind a looping port. At that moment all  
unicast traffic for that address is send into the loop. That traffic  
causes even more station movements and there you have it.

That is quiet different for layer-3 equipment were looping packets do  
not affect the state of the router(s) forwarding them.

- -- Arien


- --
Arien Vijn
Amsterdam Internet Exchange
http://www.ams-ix.net



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFGORAEfbq/zkaG+TsRAj8OAKCnLu4XvzHt8+aWmkNGqBaLXEOTngCginsh
IrzHEs8f5kVlYCWK87v44s0=
=miqU
-----END PGP SIGNATURE-----


Received: from olympic2.seas.upenn.edu (OLYMPIC2.SEAS.upenn.edu [158.130.70.164]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42MA17D021721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 15:10:02 -0700 (PDT)
Received: from olympic2.seas.upenn.edu (LOCALHOST.UPENN.EDU [127.0.0.1]) by olympic2.seas.upenn.edu (8.13.6/8.12.8) with ESMTP id l42MA1Ab005515 for <[e-mail]>; Wed, 2 May 2007 18:10:01 -0400
Received: (from httpd@localhost) by olympic2.seas.upenn.edu (8.13.6/8.13.1/Submit) id l42MA1MU005508 for [e-mail]; Wed, 2 May 2007 18:10:01 -0400
X-Authentication-Warning: olympic2.seas.upenn.edu: httpd set sender to [e-mail] using -f
Message-ID: <[e-mail]>
Date: Wed, 02 May 2007 18:10:01 -0400
From: [e-mail]
To: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.0.4)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 22:10:27 -0000
Status: RO
Content-Length: 982

Quoting Joe Touch <[e-mail]>:

>
>
> Silvano Gai wrote:
> ...
>> Joe,
>>
>> Loops are much more dangerous at layer 2 than at layer 3. I am
>> sympathetic with Radia that anything we can do to mitigate them is good.
>>
>> -- Silvano
>
> I cannot understand why that would be true. Resources are more
> constrained and impact more users at L3.

One reason I have heard is that loops are typically shorter at L2 and 
thus overwhelms the affected nodes more severely (the packet comes back 
to the node more quickly).

> While mitigating loops is good, I see no reason not to apply what we
> know and have learned from L3 here, which is that TTL may matter for
> multicast scoping, but it isn't the dominant mitigation for copy loops.
> See RFC2365, which lists many reasons for using TTL in multicast, but
> doesn't talk about copy loop (e.g., see Sec 3).
>
> Joe
>
> --
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment
>
>




Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42LGpoH008274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 14:16:51 -0700 (PDT)
Received: from [127.0.0.1] (25.sub-75-215-133.myvzw.com [75.215.133.25]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l42LGLit011076; Wed, 2 May 2007 14:16:23 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 02 May 2007 14:16:00 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9A80B1669E5D9D55F72314D4"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 21:17:31 -0000
Status: RO
Content-Length: 1446

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9A80B1669E5D9D55F72314D4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Silvano Gai wrote:
=2E..
> Joe,
>=20
> Loops are much more dangerous at layer 2 than at layer 3. I am
> sympathetic with Radia that anything we can do to mitigate them is good=
=2E
>=20
> -- Silvano

I cannot understand why that would be true. Resources are more
constrained and impact more users at L3.

While mitigating loops is good, I see no reason not to apply what we
know and have learned from L3 here, which is that TTL may matter for
multicast scoping, but it isn't the dominant mitigation for copy loops.
See RFC2365, which lists many reasons for using TTL in multicast, but
doesn't talk about copy loop (e.g., see Sec 3).

Joe

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


--------------enig9A80B1669E5D9D55F72314D4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOP+RE5f5cImnZrsRAvY0AKCiKIPHbXaiiwtu9PiwE7wp1VuAXgCg83gp
2R1JFgDBUaUFsrT35lEBvG0=
=5SHi
-----END PGP SIGNATURE-----

--------------enig9A80B1669E5D9D55F72314D4--



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42KxiK8003572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 13:59:44 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l42Kx5X6025089; Wed, 2 May 2007 15:59:05 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 2 May 2007 15:59:42 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 2 May 2007 15:59:41 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceM+2RZpjB/gzT2Tk+YT1pmWJkSbgAACzdw
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Joe Touch" <[e-mail]>
X-OriginalArrivalTime: 02 May 2007 20:59:42.0483 (UTC) FILETIME=[CE576630:01C78CFC]
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 l42KxiK8003572
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 20:59:56 -0000
Status: RO
Content-Length: 3672

Joe,

	Minimally, every replication costs at least one
hop.  Assuming the usual rule (don't forward if TTL or
hop count would be zero - or less - after decrementing),
a frame/packet would require a non-zero TTL to have any
impact on link resources.

	That aside, in a realistic scenario (where the 
link is not intended just to serve that one replication
point), a single looping stream of traffic initially
takes a very small portion of the available resources 
and only becomes significant after some multiplication
has occurred (usually more than one).

	And the fan-out is naturally restricted to the 
number of interfaces in the replicating device - i.e.
- in a practical application, at most one copy to each 
interface on which replication occurs.  Hence it is a
necessity that a full loop is traversed at least once
(and involving at least one other device) before their
is any multiplication.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Wednesday, May 02, 2007 4:49 PM
> To: Eric Gray (LO/EUS)
> Cc: Radia Perlman; [e-mail]
> Subject: Re: [rbridge] Setting initial "hop count" value
> Importance: High
> 
> * PGP Signed: 05/02/2007 at 10:48:48 PM
> 
> 
> Eric Gray (LO/EUS) wrote:
> > Joe,
> > 
> > 	How did you arrive at the conclusion that any TTL
> > greater than zero can cause duplicated packets to consume all
> > available resources?  This strikes me as an extremely suspect
> > conclusion...
> 
> Because you don't limit fanout; any TTL>0 could cause a link 
> to receive
> double the planned resources, since the packet could loop back around
> once (which is all it takes in that case).
> 
> If you do limit fanout, it needs to be a function of the 
> number of hops
> that a broadcast might take, where the largest TTL you can tolerate is
> max-BW/number-expected-hops. That could easily result in TTL<1, or at
> least a TTL<diameter, which ends up meaning your 
> multi/broadcast fails.
> 
> Joe
> 
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[e-mail]] 
> >> Sent: Wednesday, May 02, 2007 4:27 PM
> >> To: Eric Gray (LO/EUS)
> >> Cc: Radia Perlman; [e-mail]
> >> Subject: Re: [rbridge] Setting initial "hop count" value
> >> Importance: High
> >>
> >> > Old Signed: 05/02/2007 at 10:26:40 PM
> >>
> >>
> >> Eric Gray (LO/EUS) wrote:
> >>> Joe,
> >>>
> >>> 	Hop-count - like TTL - is not intended to "break loops."
> >>> It is intended to mitigate the impact of looping PDUs (frames
> >>> or packets).
> >>>
> >>> 	For this reason, setting a low value can be extremely 
> >>> useful for multicast, flooded or broadcast traffic.
> >> Any TTL > 0 can cause any duplicated packet to expand to 
> consume all
> >> resources anyway; you can't assume that the duplication cycle 
> >> is larger
> >> than 1. That's why we rely on other mechanisms to avoid copy loops,
> >> notably strict tree structures which never have looping transients.
> >>
> >> As a result, the only benefit to TTL is to prevent unicast 
> >> packets from
> >> looping in the system forever OR to constrain the reach of a packet
> >> (unicast or multi/broadcast). The former is sufficiently 
> >> accomplished by
> >> a max-ttl, and the latter should not be relevant in our system.
> >>
> >> Joe
> >>
> >> -- 
> >> ----------------------------------------
> >> Joe Touch
> >> Sr. Network Engineer, USAF TSAT Space Segment
> >>
> >> * Joe Touch <[e-mail]>
> >> * 0x89A766BB
> >>
> >>
> 
> -- 
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment
> 
> * Joe Touch <[e-mail]>
> * 0x89A766BB
> 
> 



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42Kx2Ia003484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 13:59:02 -0700 (PDT)
Received: from [127.0.0.1] (25.sub-75-215-133.myvzw.com [75.215.133.25]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l42KweOB007489; Wed, 2 May 2007 13:58:44 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 02 May 2007 13:58:23 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEC83BB0C5D11AEA09D9B6F78"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 20:59:25 -0000
Status: RO
Content-Length: 1210

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigEC83BB0C5D11AEA09D9B6F78
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Silvano Gai wrote:
> Eric,
>=20
> It is a tree only when the topology is stable; in transient is not a
> tree. Loops happen during transition.
>=20
> Joe,
>=20
> Loops are much more dangerous at layer 2 than at layer 3. I am
> sympathetic with Radia that anything we can do to mitigate them is good=
=2E

This is why we ought to be using a spanning tree for those, and let that
tree be suboptimal and/or converge via means that avoid looping
transients. It's not a good reason to over-tune TTL at L2.

Joe


--------------enigEC83BB0C5D11AEA09D9B6F78
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOPtvE5f5cImnZrsRAl83AJ4zYtzBHyP7qm1CdrNBvcQ3MOijBQCfbcQE
zExNG+vDkHrOur2gvomRQIs=
=OgIA
-----END PGP SIGNATURE-----

--------------enigEC83BB0C5D11AEA09D9B6F78--



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42KnOk7000852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 13:49:24 -0700 (PDT)
Received: from [127.0.0.1] (25.sub-75-215-133.myvzw.com [75.215.133.25]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l42Kn798005540; Wed, 2 May 2007 13:49:10 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 02 May 2007 13:48:48 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: "Eric Gray (LO/EUS)" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig173CE39AA273F195858CA1D7"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 20:49:56 -0000
Status: RO
Content-Length: 2928

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig173CE39AA273F195858CA1D7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Eric Gray (LO/EUS) wrote:
> Joe,
>=20
> 	How did you arrive at the conclusion that any TTL
> greater than zero can cause duplicated packets to consume all
> available resources?  This strikes me as an extremely suspect
> conclusion...

Because you don't limit fanout; any TTL>0 could cause a link to receive
double the planned resources, since the packet could loop back around
once (which is all it takes in that case).

If you do limit fanout, it needs to be a function of the number of hops
that a broadcast might take, where the largest TTL you can tolerate is
max-BW/number-expected-hops. That could easily result in TTL<1, or at
least a TTL<diameter, which ends up meaning your multi/broadcast fails.

Joe

>> -----Original Message-----
>> From: Joe Touch [mailto:[e-mail]]=20
>> Sent: Wednesday, May 02, 2007 4:27 PM
>> To: Eric Gray (LO/EUS)
>> Cc: Radia Perlman; [e-mail]
>> Subject: Re: [rbridge] Setting initial "hop count" value
>> Importance: High
>>
>> * PGP Signed: 05/02/2007 at 10:26:40 PM
>>
>>
>> Eric Gray (LO/EUS) wrote:
>>> Joe,
>>>
>>> 	Hop-count - like TTL - is not intended to "break loops."
>>> It is intended to mitigate the impact of looping PDUs (frames
>>> or packets).
>>>
>>> 	For this reason, setting a low value can be extremely=20
>>> useful for multicast, flooded or broadcast traffic.
>> Any TTL > 0 can cause any duplicated packet to expand to consume all
>> resources anyway; you can't assume that the duplication cycle=20
>> is larger
>> than 1. That's why we rely on other mechanisms to avoid copy loops,
>> notably strict tree structures which never have looping transients.
>>
>> As a result, the only benefit to TTL is to prevent unicast=20
>> packets from
>> looping in the system forever OR to constrain the reach of a packet
>> (unicast or multi/broadcast). The former is sufficiently=20
>> accomplished by
>> a max-ttl, and the latter should not be relevant in our system.
>>
>> Joe
>>
>> --=20
>> ----------------------------------------
>> Joe Touch
>> Sr. Network Engineer, USAF TSAT Space Segment
>>
>> * Joe Touch <[e-mail]>
>> * 0x89A766BB
>>
>>

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


--------------enig173CE39AA273F195858CA1D7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOPkwE5f5cImnZrsRArXsAJ99AltqdmbDloAIQZgxSpUkY90PCQCg8CWR
x8ctNlLo6rpQo2tX29rHY10=
=RJOo
-----END PGP SIGNATURE-----

--------------enig173CE39AA273F195858CA1D7--



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 l42KbBkx027471 for <[e-mail]>; Wed, 2 May 2007 13:37:12 -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: Wed, 2 May 2007 13:37:07 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceM8B6BJypne7HsTyK6tg+8HOoaQAAAJoJAAAImISA=
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[e-mail]>, "Joe Touch" <[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 l42KbBkx027471
Cc: [e-mail]
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 20:37:24 -0000
Status: RO
Content-Length: 2493

Eric,

It is a tree only when the topology is stable; in transient is not a
tree. Loops happen during transition.

Joe,

Loops are much more dangerous at layer 2 than at layer 3. I am
sympathetic with Radia that anything we can do to mitigate them is good.

-- Silvano


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Wednesday, May 02, 2007 12:43 PM
> To: Joe Touch; Radia Perlman
> Cc: [e-mail]
> Subject: Re: [rbridge] Setting initial "hop count" value
> 
> Joe,
> 
> 	Hop-count - like TTL - is not intended to "break loops."
> It is intended to mitigate the impact of looping PDUs (frames
> or packets).
> 
> 	For this reason, setting a low value can be extremely
> useful for multicast, flooded or broadcast traffic.  A value
> set to the greatest possible value will eventually cause all
> PDUs that are looping to be dropped, but this may be after
> the traffic has been multiplied many times.
> 
> 	However, you raise an interesting point.  As I believe
> we are currently considering it, multiple destination frames
> (multicast, flooded and broadcast) are intended to be sent on
> a tree that essentially has the properties of a spanning tree.
> That being the case, if hop-count is not intended to mitigate
> looping of multi-destination frames, then I agree with your
> point and feel that it might NOT be a good idea to contrain
> the hop-count value based on the radius of the TRILL network.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Joe Touch
> > Sent: Wednesday, May 02, 2007 3:12 PM
> > To: Radia Perlman
> > Cc: [e-mail]
> > Subject: Re: [rbridge] Setting initial "hop count" value
> >
> > * PGP Signed: 05/02/2007 at 09:11:54 PM
> > I disagree with optimizing hopcount. It's intended to break loops;
if
> > you're looping at all, you're already not optimizing. I'd leave it
at
> > the max value and allow its safety to be derived from
> > loop-breaking, not
> > optimization.
> >
> > Joe
> >
> > --
> > ----------------------------------------
> > Joe Touch
> > Sr. Network Engineer, USAF TSAT Space Segment
> >
> > * Joe Touch <[e-mail]>
> > * 0x89A766BB (L)
> >
> >
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42KVBPp025810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 13:31:11 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l42KW69D013885; Wed, 2 May 2007 15:32:06 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 2 May 2007 15:31:10 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 2 May 2007 15:31:09 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceM+EzqyoC0xeDrSFCkP9l55hmflwAADasA
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Joe Touch" <[e-mail]>
X-OriginalArrivalTime: 02 May 2007 20:31:10.0359 (UTC) FILETIME=[D1D60270:01C78CF8]
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 l42KVBPp025810
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 20:31:26 -0000
Status: RO
Content-Length: 1623

Joe,

	How did you arrive at the conclusion that any TTL
greater than zero can cause duplicated packets to consume all
available resources?  This strikes me as an extremely suspect
conclusion...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Wednesday, May 02, 2007 4:27 PM
> To: Eric Gray (LO/EUS)
> Cc: Radia Perlman; [e-mail]
> Subject: Re: [rbridge] Setting initial "hop count" value
> Importance: High
> 
> * PGP Signed: 05/02/2007 at 10:26:40 PM
> 
> 
> Eric Gray (LO/EUS) wrote:
> > Joe,
> > 
> > 	Hop-count - like TTL - is not intended to "break loops."
> > It is intended to mitigate the impact of looping PDUs (frames
> > or packets).
> > 
> > 	For this reason, setting a low value can be extremely 
> > useful for multicast, flooded or broadcast traffic.
> 
> Any TTL > 0 can cause any duplicated packet to expand to consume all
> resources anyway; you can't assume that the duplication cycle 
> is larger
> than 1. That's why we rely on other mechanisms to avoid copy loops,
> notably strict tree structures which never have looping transients.
> 
> As a result, the only benefit to TTL is to prevent unicast 
> packets from
> looping in the system forever OR to constrain the reach of a packet
> (unicast or multi/broadcast). The former is sufficiently 
> accomplished by
> a max-ttl, and the latter should not be relevant in our system.
> 
> Joe
> 
> -- 
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment
> 
> * Joe Touch <[e-mail]>
> * 0x89A766BB
> 
> 



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42KROfN024694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 13:27:24 -0700 (PDT)
Received: from [127.0.0.1] (25.sub-75-215-133.myvzw.com [75.215.133.25]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l42KR0LO001260; Wed, 2 May 2007 13:27:02 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 02 May 2007 13:26:39 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: "Eric Gray (LO/EUS)" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig886C43286C35CD16394A5952"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 20:27:54 -0000
Status: RO
Content-Length: 1665

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig886C43286C35CD16394A5952
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Eric Gray (LO/EUS) wrote:
> Joe,
>=20
> 	Hop-count - like TTL - is not intended to "break loops."
> It is intended to mitigate the impact of looping PDUs (frames
> or packets).
>=20
> 	For this reason, setting a low value can be extremely=20
> useful for multicast, flooded or broadcast traffic.

Any TTL > 0 can cause any duplicated packet to expand to consume all
resources anyway; you can't assume that the duplication cycle is larger
than 1. That's why we rely on other mechanisms to avoid copy loops,
notably strict tree structures which never have looping transients.

As a result, the only benefit to TTL is to prevent unicast packets from
looping in the system forever OR to constrain the reach of a packet
(unicast or multi/broadcast). The former is sufficiently accomplished by
a max-ttl, and the latter should not be relevant in our system.

Joe

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


--------------enig886C43286C35CD16394A5952
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOPQAE5f5cImnZrsRAj/1AJ9lBN2+OTp8F+VXRnE7M7IKDZbTbwCgwP4G
r7F9a4Lt3KH2QQjtCyhrvWM=
=Q0/9
-----END PGP SIGNATURE-----

--------------enig886C43286C35CD16394A5952--



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42Jgodw013802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 12:42:51 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l42JhfJ3005072; Wed, 2 May 2007 14:43:42 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 2 May 2007 14:42:45 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 2 May 2007 14:42:43 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceM8B6BJypne7HsTyK6tg+8HOoaQAAAJoJA
References: <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Joe Touch" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 02 May 2007 19:42:45.0432 (UTC) FILETIME=[0E5D5380:01C78CF2]
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 l42Jgodw013802
Cc: [e-mail]
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 19:44:22 -0000
Status: RO
Content-Length: 1687

Joe,

	Hop-count - like TTL - is not intended to "break loops."
It is intended to mitigate the impact of looping PDUs (frames
or packets).

	For this reason, setting a low value can be extremely 
useful for multicast, flooded or broadcast traffic.  A value
set to the greatest possible value will eventually cause all
PDUs that are looping to be dropped, but this may be after
the traffic has been multiplied many times.

	However, you raise an interesting point.  As I believe
we are currently considering it, multiple destination frames
(multicast, flooded and broadcast) are intended to be sent on
a tree that essentially has the properties of a spanning tree. 
That being the case, if hop-count is not intended to mitigate
looping of multi-destination frames, then I agree with your
point and feel that it might NOT be a good idea to contrain
the hop-count value based on the radius of the TRILL network.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Joe Touch
> Sent: Wednesday, May 02, 2007 3:12 PM
> To: Radia Perlman
> Cc: [e-mail]
> Subject: Re: [rbridge] Setting initial "hop count" value
> 
> * PGP Signed: 05/02/2007 at 09:11:54 PM
> I disagree with optimizing hopcount. It's intended to break loops; if
> you're looping at all, you're already not optimizing. I'd leave it at
> the max value and allow its safety to be derived from 
> loop-breaking, not
> optimization.
> 
> Joe
> 
> -- 
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment
> 
> * Joe Touch <[e-mail]>
> * 0x89A766BB (L)
> 
> 



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42JPFpV009360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 12:25:15 -0700 (PDT)
Received: from [127.0.0.1] (25.sub-75-215-133.myvzw.com [75.215.133.25]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l42JOr0H017463; Wed, 2 May 2007 12:24:56 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 02 May 2007 12:24:32 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: "Eric Gray (LO/EUS)" <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7EB5EBA596D882277D162A46"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 19:25:27 -0000
Status: RO
Content-Length: 5384

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7EB5EBA596D882277D162A46
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

FWIW, IMO, the TTL ought to be:

	SHOULD be max-val
	MAY be operator set, either to optimize or
		for scoping (as with IP TTL)

Note that it's not IP that generally uses scoping, but only multicast. I
don't see why IP multicast scoping maps to our situation, so I don't see
why any choice but "max-val" is appropriate.

Joe


Eric Gray (LO/EUS) wrote:
> Radia,
>=20
> 	So, it MUST be clear at this point that it would have=20
> been a BAD idea to have suggested a value for TTL in IP back
> when the initial RFC was first written.  A reasonable value
> - back then - might have been 4 or 8.  After all, 16 was=20
> thought to be the same as infinity in some routing protocols
> defined at an even later date.
>=20
> 	I agree that - at this point - we might be in a better
> position to make reasonable guesses (such as you propose),
> but we should be cautious.  The reason why I suggest this is
> that we are talking about potentially defining a default that
> MAY be set in any deployed RBridge implementation and may end
> up being unreasonable in some (possibly near-future) usage.
>=20
> 	Hence I suggest we phrase any such recommendation as=20
> carefully as possible - to allow for a subsequent discovery
> that some value outside of our recommendation is better for
> real-world deployments.
>=20
> 	Also, we should avoid being too loose in defining the
> "clever" things an implementation MAY do, in order to avoid=20
> encouraging conflicting interpretations that MAY lead to=20
> non-interoperable implementations.
>=20
> 	All of those qualifications made, I would suggest that=20
> it may be sufficient to set the hop count (at the ingress) to=20
> the distance (in hops) to the appropriate egress(es) - plus
> some increment (where the increment might be 2, for instance).
> We also then need to specify the usual behavioral requirements
> (such as that each RBridge MUST decrement the hop-count by at=20
> least one).
>=20
> 	Also, these days, it's quite common for implementations
> to be able to change things that might previously have been
> "cast in stone" using a simple firmware (or flash) upgrade. =20
>=20
> 	So, as long as we include the appropriate language in=20
> suggestions we make, it SHOULD be okay to make them.
>=20
> --
> Eric Gray
> Principal Engineer
> Ericsson =20
>=20
>> -----Original Message-----
>> From: [e-mail]=20
>> [mailto:[e-mail]] On Behalf Of Radia Perlman
>> Sent: Wednesday, May 02, 2007 12:19 PM
>> To: [e-mail]
>> Subject: [rbridge] Setting initial "hop count" value
>>
>> We didn't say what the initial value of the "hop count" field=20
>> should be.
>>
>> One tempting thing would be to set it to the computing number=20
>> of hops to
>> the egress RBridge, since the ingress RBridge knows how long=20
>> the path is=20
>> (based on
>> computation from the link state database). It would be easy for an=20
>> RBridge to
>> include not just the next hop to the egress RBridge, but the=20
>> hop count=20
>> as well,
>> so that it would know how to set the hop count field.
>>
>> However, layer 3 people these days do various clever "detour" things=20
>> when they
>> can't reach the next hop, so that packets can still get to the=20
>> destination while
>> the routing algorithm is converging. So the hop count could=20
>> need to be=20
>> more than
>> what the ingress guy thinks.
>>
>> But I think it's a good idea for multicast for the ingress RBridge to =

>> set the initial
>> hop count to be equal to the maximum length from that RBridge to any=20
>> other RBridge
>> (in the selected tree).
>>
>> We even could be clever and an RBridge in the core that is=20
>> forwarding on=20
>> various branches
>> could decrement the hop count by more if it knows that some branch of =

>> the chosen
>> distribution tree needs a smaller count in order to reach to=20
>> the ends of=20
>> that branch.
>>
>> This would make multicast even safer.
>>
>> At any rate, it's always seemed a bit weird to have a field=20
>> like "TTL"=20
>> in IP without
>> saying in the spec what to set it to. We don't have to make the=20
>> suggestion a MUST, but it would
>> be nice to give some recommendation in the TRILL spec about=20
>> what to set=20
>> it to.
>>
>> Comments?
>>
>> Radia
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge

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


--------------enig7EB5EBA596D882277D162A46
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOOVwE5f5cImnZrsRAu8cAKCoM91VR9nai8DZj3nMrv31iVp9dACfZUxx
jsK33EVVov3j/xAljcXc+g4=
=PLo5
-----END PGP SIGNATURE-----

--------------enig7EB5EBA596D882277D162A46--



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42JE1NJ006353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 12:14:01 -0700 (PDT)
Received: from [127.0.0.1] (25.sub-75-215-133.myvzw.com [75.215.133.25]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l42JDlKl014788; Wed, 2 May 2007 12:13:50 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 02 May 2007 12:13:28 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3EDF3384D8748A7C37C493AF"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 19:14:34 -0000
Status: RO
Content-Length: 3510

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3EDF3384D8748A7C37C493AF
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

PS - Bob Briscoe uses similar logic in his re-feedback concept from
Sigcomm 2005, which he discusses in his 'flow rate fairness' I-D
(briscoe-tsvarea-fair).

Interesting doesn't mean conservative or useful at this point ;-)

Joe

Silvano Gai wrote:
> Radia,
>=20
> I am sympathetic with the proposal.
>=20
> There is an interesting paper on the topic that we should all read to b=
e
> informed
>=20
> http://www.ieee802.org/1/files/public/docs2006/aq-seaman-exact-hop-coun=
t
> -1206-01.pdf
>=20
>=20
> -- Silvano
>=20
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
> On
>> Behalf Of Radia Perlman
>> Sent: Wednesday, May 02, 2007 9:19 AM
>> To: [e-mail]
>> Subject: [rbridge] Setting initial "hop count" value
>>
>> We didn't say what the initial value of the "hop count" field should
> be.
>> One tempting thing would be to set it to the computing number of hops
> to
>> the egress RBridge, since the ingress RBridge knows how long the path
> is
>> (based on
>> computation from the link state database). It would be easy for an
>> RBridge to
>> include not just the next hop to the egress RBridge, but the hop count=

>> as well,
>> so that it would know how to set the hop count field.
>>
>> However, layer 3 people these days do various clever "detour" things
>> when they
>> can't reach the next hop, so that packets can still get to the
>> destination while
>> the routing algorithm is converging. So the hop count could need to be=

>> more than
>> what the ingress guy thinks.
>>
>> But I think it's a good idea for multicast for the ingress RBridge to
>> set the initial
>> hop count to be equal to the maximum length from that RBridge to any
>> other RBridge
>> (in the selected tree).
>>
>> We even could be clever and an RBridge in the core that is forwarding
> on
>> various branches
>> could decrement the hop count by more if it knows that some branch of
>> the chosen
>> distribution tree needs a smaller count in order to reach to the ends
> of
>> that branch.
>>
>> This would make multicast even safer.
>>
>> At any rate, it's always seemed a bit weird to have a field like "TTL"=

>> in IP without
>> saying in the spec what to set it to. We don't have to make the
>> suggestion a MUST, but it would
>> be nice to give some recommendation in the TRILL spec about what to
> set
>> it to.
>>
>> Comments?
>>
>> Radia
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge

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


--------------enig3EDF3384D8748A7C37C493AF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOOLYE5f5cImnZrsRAh85AKC2lJNJXNN6+UxAxBqru93j5Bzf6ACgghq3
y60Jh+v2b60v4pCphl+r5z0=
=Ur6O
-----END PGP SIGNATURE-----

--------------enig3EDF3384D8748A7C37C493AF--



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42JCWBi006077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 12:12:32 -0700 (PDT)
Received: from [127.0.0.1] (25.sub-75-215-133.myvzw.com [75.215.133.25]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l42JCFI3014590; Wed, 2 May 2007 12:12:17 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 02 May 2007 12:11:53 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB50519C245B42D611A5EF9E9"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 19:12:52 -0000
Status: RO
Content-Length: 1038

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB50519C245B42D611A5EF9E9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I disagree with optimizing hopcount. It's intended to break loops; if
you're looping at all, you're already not optimizing. I'd leave it at
the max value and allow its safety to be derived from loop-breaking, not
optimization.

Joe

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


--------------enigB50519C245B42D611A5EF9E9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOOJ6E5f5cImnZrsRAmEhAKCYGsNukbAbS1pxcAMHWXUHAFWL1ACgpihL
WzhOHhHIzZ8TlFqXzt48hn4=
=8lhr
-----END PGP SIGNATURE-----

--------------enigB50519C245B42D611A5EF9E9--



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42HeOcS011518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 10:40:25 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l42Hdk70027666; Wed, 2 May 2007 12:39:46 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 2 May 2007 12:40:24 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 2 May 2007 12:40:23 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceM1uZL7iieSoi0QIOaeLQqAPneVQABz4NA
References: <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 02 May 2007 17:40:24.0157 (UTC) FILETIME=[F69FA8D0:01C78CE0]
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 l42HeOcS011518
Cc: [e-mail]
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 17:40:56 -0000
Status: RO
Content-Length: 3840

Radia,

	So, it MUST be clear at this point that it would have 
been a BAD idea to have suggested a value for TTL in IP back
when the initial RFC was first written.  A reasonable value
- back then - might have been 4 or 8.  After all, 16 was 
thought to be the same as infinity in some routing protocols
defined at an even later date.

	I agree that - at this point - we might be in a better
position to make reasonable guesses (such as you propose),
but we should be cautious.  The reason why I suggest this is
that we are talking about potentially defining a default that
MAY be set in any deployed RBridge implementation and may end
up being unreasonable in some (possibly near-future) usage.

	Hence I suggest we phrase any such recommendation as 
carefully as possible - to allow for a subsequent discovery
that some value outside of our recommendation is better for
real-world deployments.

	Also, we should avoid being too loose in defining the
"clever" things an implementation MAY do, in order to avoid 
encouraging conflicting interpretations that MAY lead to 
non-interoperable implementations.

	All of those qualifications made, I would suggest that 
it may be sufficient to set the hop count (at the ingress) to 
the distance (in hops) to the appropriate egress(es) - plus
some increment (where the increment might be 2, for instance).
We also then need to specify the usual behavioral requirements
(such as that each RBridge MUST decrement the hop-count by at 
least one).

	Also, these days, it's quite common for implementations
to be able to change things that might previously have been
"cast in stone" using a simple firmware (or flash) upgrade.  

	So, as long as we include the appropriate language in 
suggestions we make, it SHOULD be okay to make them.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Radia Perlman
> Sent: Wednesday, May 02, 2007 12:19 PM
> To: [e-mail]
> Subject: [rbridge] Setting initial "hop count" value
> 
> We didn't say what the initial value of the "hop count" field 
> should be.
> 
> One tempting thing would be to set it to the computing number 
> of hops to
> the egress RBridge, since the ingress RBridge knows how long 
> the path is 
> (based on
> computation from the link state database). It would be easy for an 
> RBridge to
> include not just the next hop to the egress RBridge, but the 
> hop count 
> as well,
> so that it would know how to set the hop count field.
> 
> However, layer 3 people these days do various clever "detour" things 
> when they
> can't reach the next hop, so that packets can still get to the 
> destination while
> the routing algorithm is converging. So the hop count could 
> need to be 
> more than
> what the ingress guy thinks.
> 
> But I think it's a good idea for multicast for the ingress RBridge to 
> set the initial
> hop count to be equal to the maximum length from that RBridge to any 
> other RBridge
> (in the selected tree).
> 
> We even could be clever and an RBridge in the core that is 
> forwarding on 
> various branches
> could decrement the hop count by more if it knows that some branch of 
> the chosen
> distribution tree needs a smaller count in order to reach to 
> the ends of 
> that branch.
> 
> This would make multicast even safer.
> 
> At any rate, it's always seemed a bit weird to have a field 
> like "TTL" 
> in IP without
> saying in the spec what to set it to. We don't have to make the 
> suggestion a MUST, but it would
> be nice to give some recommendation in the TRILL spec about 
> what to set 
> it to.
> 
> Comments?
> 
> Radia
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42HH3nG004476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 10:17:04 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l42HGOkT024330; Wed, 2 May 2007 12:16:24 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 2 May 2007 12:17:02 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 2 May 2007 12:17:00 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Optional configuration of RBridge nickname
Thread-Index: AceMc7uUR/qzTl66Sn2N6zS2CQqQvAAMCO3QAAu712AAAnk1EA==
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 02 May 2007 17:17:02.0529 (UTC) FILETIME=[B3303310:01C78CDD]
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 l42HH3nG004476
Cc: [e-mail]
Subject: Re: [rbridge] Optional configuration of RBridge nickname
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, 02 May 2007 17:17:22 -0000
Status: RO
Content-Length: 5409

Silvano,

	Perhaps I am reading your requirement incorrectly,
but it sounds to me that it could be as easily addressed
by requiring that implementations support a way to shut
nickname-negotiation off.

	Consider simply having a pair of management objects
- one to disable auto-nickname negotiation, and another
(which must be assigned a value if the first is disabled)
that contains the configured nickname.

	In my opinion, that would be a much more acceptable
approach - especially in comparison with using priority
as a mechanism for varying the outcome of auto-negotiation
without actually turning it off.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Wednesday, May 02, 2007 12:06 PM
> To: Eric Gray (LO/EUS); Radia Perlman; [e-mail]
> Subject: RE: [rbridge] Optional configuration of RBridge nickname
> Importance: High
> 
> 
> Eric,
> 
> There is a strong requirement in Enterprise to disable any form of
> autoconfiguration. I requested Radia to support a way to manually
> configure Nicknames. I am not asking this being the default, 
> but it must
> be supported.
> 
> The solution that Radia has put together is satisfactory for me. If I
> want to manually configure a nickname I will do it and set the highest
> priority. 
> 
> Lacking a secure authentication scheme the network can be attacked by
> any PC in a much easier way.
> 
> --Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eric Gray (LO/EUS)
> > Sent: Wednesday, May 02, 2007 3:31 AM
> > To: Radia Perlman; [e-mail]
> > Subject: Re: [rbridge] Optional configuration of RBridge nickname
> > 
> > Radia,
> > 
> > 	I would object strenuously to the use of a priority
> > value in resolving the "ownership" of a nickname.
> > 
> > 	The over-riding priority has to be determined in a
> > way that ensures the existing network continues to work
> > if a new device is inserted (i.e. - it would be best if
> > any device were going to fail, it should be the one that
> > has just been added).
> > 
> > 	Adding "priority" would allow any device to assert
> > a high priority ownership of any nickname currently in
> > use, which would then make it trivially easy to stage a
> > network disabling attack.
> > 
> > 	Having it be so easy to attack the network, would
> > necessitate mandatory defenses, almost certainly meaning
> > that configuration would be required - possibly excepting
> > the option of having the very highest priority value be
> > the default assumed when no configuration is done at any
> > RBridge.
> > 
> > 	In either case (configuration absolutely required,
> > or default highest priority with no configuration) would
> > defeat your purpose.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Radia Perlman
> > > Sent: Wednesday, May 02, 2007 12:26 AM
> > > To: [e-mail]
> > > Subject: [rbridge] Optional configuration of RBridge nickname
> > >
> > > Someone suggested that it would be useful to allow 
> configuration of
> > > nicknames, so
> > > that nicknames can be more stable, and there would be no 
> worry of an
> > > RBridge coming
> > > up and usurping a nickname from someone else. I'd like:
> > > a) for it to remain possible to be zero configuration (as in, not
> > > necessary to configure
> > > a nickname
> > > b) allow a mixture of configured and unconfigured nicknames
> > > c) work even with misconfiguration (configuring two RBridges with
> the
> > > same nickname)
> > > d) never allow an unconfigured nickname to accidentally usurp
> > > a nickname
> > > from
> > > a ocnfigured RBridge
> > >
> > > So I'm proposing the following:
> > >
> > > a) allow configuration of a nickname value
> > > b) have a "priority" value for owning a nickname
> > > that can also be configured, which I'd propose would be an 8-bit
> byte,
> > > where only the bottom 7 bits can be configured
> > > c) the 8th bit of the priority byte (the most significant
> > > bit) indicates
> > > whether
> > > the nickname was configured or not
> > > d) the default is priority=0 for RBridges that have not been
> > > configured with
> > > a nickname value, and priority=128 (top bit 1, rest 0) for an
> > > RBridge that
> > > has been configured with a nickname
> > > e) other values of nickname priority might be useful. For
> > > instance, an
> > > RBridge
> > > implementation might increment the nickname value after it's held
> the
> > > nickname
> > > for some amount of time (say 10 minutes). Or someone might
> > > want to configure
> > > some RBridges to have a more stable nickname (by giving 
> them higher
> > > priority).
> > > f) Basically, the (nickname priority | system ID) is like the DR
> > > priority in IS-IS,
> > > where the DR election is based on (priority | system ID)
> > >
> > > Anyone object to this?
> > >
> > > 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 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 l42GbJIm022573 for <[e-mail]>; Wed, 2 May 2007 09:37:19 -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: Wed, 2 May 2007 09:37:15 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Setting initial "hop count" value
Thread-Index: AceM11Y7F1gm7SdiQpeYdrSJYUmmVAAAJ/Pw
References: <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Radia Perlman" <[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 l42GbJIm022573
Subject: Re: [rbridge] Setting initial "hop count" value
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, 02 May 2007 16:37:50 -0000
Status: RO
Content-Length: 2200

Radia,

I am sympathetic with the proposal.

There is an interesting paper on the topic that we should all read to be
informed

http://www.ieee802.org/1/files/public/docs2006/aq-seaman-exact-hop-count
-1206-01.pdf


-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Radia Perlman
> Sent: Wednesday, May 02, 2007 9:19 AM
> To: [e-mail]
> Subject: [rbridge] Setting initial "hop count" value
> 
> We didn't say what the initial value of the "hop count" field should
be.
> 
> One tempting thing would be to set it to the computing number of hops
to
> the egress RBridge, since the ingress RBridge knows how long the path
is
> (based on
> computation from the link state database). It would be easy for an
> RBridge to
> include not just the next hop to the egress RBridge, but the hop count
> as well,
> so that it would know how to set the hop count field.
> 
> However, layer 3 people these days do various clever "detour" things
> when they
> can't reach the next hop, so that packets can still get to the
> destination while
> the routing algorithm is converging. So the hop count could need to be
> more than
> what the ingress guy thinks.
> 
> But I think it's a good idea for multicast for the ingress RBridge to
> set the initial
> hop count to be equal to the maximum length from that RBridge to any
> other RBridge
> (in the selected tree).
> 
> We even could be clever and an RBridge in the core that is forwarding
on
> various branches
> could decrement the hop count by more if it knows that some branch of
> the chosen
> distribution tree needs a smaller count in order to reach to the ends
of
> that branch.
> 
> This would make multicast even safer.
> 
> At any rate, it's always seemed a bit weird to have a field like "TTL"
> in IP without
> saying in the spec what to set it to. We don't have to make the
> suggestion a MUST, but it would
> be nice to give some recommendation in the TRILL spec about what to
set
> it to.
> 
> Comments?
> 
> Radia
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42GINjo016928 for <[e-mail]>; Wed, 2 May 2007 09:18:23 -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, 02 May 2007 09:18:23 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.21.34]) 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, 02 May 2007 09:18:23 -0700 (PDT)
Date: Wed, 02 May 2007 09:18:50 -0700
From: Radia Perlman <[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
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Setting initial "hop count" value
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, 02 May 2007 16:18:47 -0000
Status: RO
Content-Length: 1497

We didn't say what the initial value of the "hop count" field should be.

One tempting thing would be to set it to the computing number of hops to
the egress RBridge, since the ingress RBridge knows how long the path is 
(based on
computation from the link state database). It would be easy for an 
RBridge to
include not just the next hop to the egress RBridge, but the hop count 
as well,
so that it would know how to set the hop count field.

However, layer 3 people these days do various clever "detour" things 
when they
can't reach the next hop, so that packets can still get to the 
destination while
the routing algorithm is converging. So the hop count could need to be 
more than
what the ingress guy thinks.

But I think it's a good idea for multicast for the ingress RBridge to 
set the initial
hop count to be equal to the maximum length from that RBridge to any 
other RBridge
(in the selected tree).

We even could be clever and an RBridge in the core that is forwarding on 
various branches
could decrement the hop count by more if it knows that some branch of 
the chosen
distribution tree needs a smaller count in order to reach to the ends of 
that branch.

This would make multicast even safer.

At any rate, it's always seemed a bit weird to have a field like "TTL" 
in IP without
saying in the spec what to set it to. We don't have to make the 
suggestion a MUST, but it would
be nice to give some recommendation in the TRILL spec about what to set 
it to.

Comments?

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 l42G6Uc0013463 for <[e-mail]>; Wed, 2 May 2007 09:06:31 -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: Wed, 2 May 2007 09:06:25 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Optional configuration of RBridge nickname
Thread-Index: AceMc7uUR/qzTl66Sn2N6zS2CQqQvAAMCO3QAAu712A=
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[e-mail]>, "Radia Perlman" <[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 l42G6Uc0013463
Subject: Re: [rbridge] Optional configuration of RBridge nickname
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, 02 May 2007 16:06:57 -0000
Status: RO
Content-Length: 4219

Eric,

There is a strong requirement in Enterprise to disable any form of
autoconfiguration. I requested Radia to support a way to manually
configure Nicknames. I am not asking this being the default, but it must
be supported.

The solution that Radia has put together is satisfactory for me. If I
want to manually configure a nickname I will do it and set the highest
priority. 

Lacking a secure authentication scheme the network can be attacked by
any PC in a much easier way.

--Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Wednesday, May 02, 2007 3:31 AM
> To: Radia Perlman; [e-mail]
> Subject: Re: [rbridge] Optional configuration of RBridge nickname
> 
> Radia,
> 
> 	I would object strenuously to the use of a priority
> value in resolving the "ownership" of a nickname.
> 
> 	The over-riding priority has to be determined in a
> way that ensures the existing network continues to work
> if a new device is inserted (i.e. - it would be best if
> any device were going to fail, it should be the one that
> has just been added).
> 
> 	Adding "priority" would allow any device to assert
> a high priority ownership of any nickname currently in
> use, which would then make it trivially easy to stage a
> network disabling attack.
> 
> 	Having it be so easy to attack the network, would
> necessitate mandatory defenses, almost certainly meaning
> that configuration would be required - possibly excepting
> the option of having the very highest priority value be
> the default assumed when no configuration is done at any
> RBridge.
> 
> 	In either case (configuration absolutely required,
> or default highest priority with no configuration) would
> defeat your purpose.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Radia Perlman
> > Sent: Wednesday, May 02, 2007 12:26 AM
> > To: [e-mail]
> > Subject: [rbridge] Optional configuration of RBridge nickname
> >
> > Someone suggested that it would be useful to allow configuration of
> > nicknames, so
> > that nicknames can be more stable, and there would be no worry of an
> > RBridge coming
> > up and usurping a nickname from someone else. I'd like:
> > a) for it to remain possible to be zero configuration (as in, not
> > necessary to configure
> > a nickname
> > b) allow a mixture of configured and unconfigured nicknames
> > c) work even with misconfiguration (configuring two RBridges with
the
> > same nickname)
> > d) never allow an unconfigured nickname to accidentally usurp
> > a nickname
> > from
> > a ocnfigured RBridge
> >
> > So I'm proposing the following:
> >
> > a) allow configuration of a nickname value
> > b) have a "priority" value for owning a nickname
> > that can also be configured, which I'd propose would be an 8-bit
byte,
> > where only the bottom 7 bits can be configured
> > c) the 8th bit of the priority byte (the most significant
> > bit) indicates
> > whether
> > the nickname was configured or not
> > d) the default is priority=0 for RBridges that have not been
> > configured with
> > a nickname value, and priority=128 (top bit 1, rest 0) for an
> > RBridge that
> > has been configured with a nickname
> > e) other values of nickname priority might be useful. For
> > instance, an
> > RBridge
> > implementation might increment the nickname value after it's held
the
> > nickname
> > for some amount of time (say 10 minutes). Or someone might
> > want to configure
> > some RBridges to have a more stable nickname (by giving them higher
> > priority).
> > f) Basically, the (nickname priority | system ID) is like the DR
> > priority in IS-IS,
> > where the DR election is based on (priority | system ID)
> >
> > Anyone object to this?
> >
> > 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 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 l42Fwxot011209 for <[e-mail]>; Wed, 2 May 2007 08:59:00 -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: Wed, 2 May 2007 08:58:54 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header Format
Thread-Index: AceMOeEYDfn40BMmQ2OgfQ/Wp1jEqQAmM4zg
References: <[e-mail]>	<461ED550.9080501@isi.!edu>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<4626E9D3.7090502@is!!	! i.e	du><34BDD2A	[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]> <[e-mail]! ! .com> <	[e-mail]> <[e-mail].! com> <4 [e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Joe Touch" <[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 l42Fwxot011209
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format
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, 02 May 2007 15:59:21 -0000
Status: RO
Content-Length: 10542

Joe,

I agree with you and I am in favor of solution 1

-- Silvano

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Tuesday, May 01, 2007 2:43 PM
> To: Silvano Gai
> Cc: Eastlake III Donald-LDE008; Dinesh G Dutt; [e-mail]
> Subject: Re: [rbridge] TRILL Header Format
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> >
> > In this case you have option 1,
> > The VLAN-ID is located at an easily computable offset from the TRILL
> > header
> 
> Agreed. I'm not as concerned with the need for extra space as others;
we
> have a version field, which ought to cover future expansion if needed
> anyway.
> 
> Joe
> 
> >
> > -- Silvano
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[e-mail]]
> >> Sent: Tuesday, May 01, 2007 2:33 PM
> >> To: Eastlake III Donald-LDE008
> >> Cc: Dinesh G Dutt; Silvano Gai; [e-mail]
> >> Subject: Re: [rbridge] TRILL Header Format
> >>
> >>
> >>
> >> Eastlake III Donald-LDE008 wrote:
> >>> Hi,
> >>>
> >>> I agree with Dinesh's comment and would also like to say that my
> >>> personal preference is for Solution 2. I just don't feel there are
> >>> enough reserved bit available for future use in the minimal
Solution
> > 1
> >>> and since, in the general case, every Rbridge has to look at the
> > VLAN
> >>> ID, putting it in a fixed place nearer the beginning of the frame,
> > as
> >>> done in Solution 2, seems like a good idea.
> >> I agree in spirit, but don't agree that the inner frame should be
> >> modified during processing; this just complicates parsing and
> > debugging,
> >> and increases the potential for implementation errors.
> >>
> >> IMO, the VLAN tags should be copied, not moved.
> >>
> >> Joe
> >>
> >>> Thanks,
> >>> Donald
> >>>
> >>> -----Original Message-----
> >>> From: [e-mail]
[mailto:[e-mail]]
> > On
> >>> Behalf Of Dinesh G Dutt
> >>> Sent: Monday, April 30, 2007 3:19 PM
> >>> To: Silvano Gai
> >>> Cc: [e-mail]
> >>> Subject: Re: [rbridge] TRILL Header Format
> >>>
> >>> Two small corrections. In the second format, we really don't need
> > any
> >>> indication of .1Q/.1S. The tag that is to be added at the egress
> > port
> >>> maybe different from the tag that we received at the ingress port
> > and is
> >>> part of the port logic. For example, the frame may have come in
with
> > a
> >>> .1Q tag and may go out a port that accepts no tagging at all.
> >>>
> >>> Given that we don't need to carry any indication of .1Q/.1S in the
> > TRILL
> >>> header, I suggest that we also define the field "Inner 802.1Q/S
tag"
> > to
> >>> be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator
and
> > call
> >>> it DE (drop eligibility). This way if RBridges along the way can
> > choose
> >>> to set the DE bit in the inner header, instead of treating it as
an
> >>> opaque field.
> >>>
> >>> Dinesh
> >>> Silvano Gai wrote:
> >>>> The purpose of the following message is to converge on the final
> >>>> structure of the TRILL header.
> >>>>
> >>>> The format proposed in:
> >>>>
> >
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03
> >>>> .txt
> >>>> has been stable for a while. This message only describes the
> >>>> differences.
> >>>>
> >>>> At the last IETF Donald proposed to support a single extension
> > header
> >>>> containing multiple extensions.
> >>>>
> >>>> After some discussion two solutions seem possible. Please express
> > your
> >>>> preference by replying to this email.
> >>>>
> >>>> -- Silvano
> >>>>
> >>>>
> >>>> Solution 1
> >>>> ==========
> >>>>
> >>>>
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>                                       | V |M|RSD|EH-length| Hop
> > Count
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>> Where:
> >>>> - RSD (2 bits) is reserved
> >>>> - EH-Length (5 bits) is the extension header length, expressed in
> >>> units
> >>>> of in 4 bytes words.
> >>>>
> >>>> If EH-length is zero there is no extension header;
> >>>> else, the extensions follow immediately after the Egress Rbridge
> >>>> Nickname field, and the total length of all the extensions is as
> >>>> indicated by the EH-length field, expressed in units of 4-byte
> > words.
> >>>> This solution allows 128 bytes of extensions.
> >>>>
> >>>>
> >>>> Solution 2
> >>>> ==========
> >>>>
> >>>>
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>                                       |  V  |M|S| RSD |   Hop
Count
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |    RSD        |   EH-length   |  Inner IEEE 802.1Q/S tag
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>> This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and
> > Priority)
> >>>> into the TRILL header. The Inner 1Q/1S tag is no longer present
in
> > the
> >>>> inner frame.
> >>>>
> >>>> This simplifies the parsing for the core RBridges. On the other
> > hand
> >>> the
> >>>> Ingress/Egress Rbridges need to do slightly more work.
> >>>>
> >>>> This has more reserved space. Since the inner 1Q/1S tag is
removed
> >>> from
> >>>> the frame (4 bytes), it uses the same overall space of solution
1.
> >>>>
> >>>> The S bit indicates if the inner header was 1Q (S=0) or 1S (S=1).
> >>>>
> >>>> The EH-length is 8 bits, with a granularity of 2 bytes it allows
up
> > to
> >>>> 512 bytes of extensions.
> >>>>
> >>>> The Hop Count can grow to 8 bits.
> >>>>
> >>>>
> >>>> A word of caution
> >>>> =================
> >>>>
> >>>> Extensions are very appealing, but their practical deployment has
> > been
> >>>> very limited. Often Router and Switches are not able to process
in
> > HW
> >>>> frames with extensions and they send them to SW.
> >>>>
> >>>>
> >>>> Example with Solution 1
> >>>> =======================
> >>>>
> >>>>
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |               Outer Destination MAC Address
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       | Outer Destination MAC Address | Outer Source MAC Address
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |                   Outer Source MAC Address
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       | Ethertype = TRILL             | V |M|RSD|EH-length| Hop
> > Count
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |               Inner Destination MAC Address
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       | Inner Destination MAC Address | InnerSource MAC Address
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |                    Inner Source MAC Address
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       | Ethertype = IEEE 802.1Q       | UP  |C|   Inner VID
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |
> >>> |
> >>>>       |                 Original Ethernet Payload
> >>> |
> >>>>       |
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |                           New FCS
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>              TRILL Encapsulation over Ethernet with Solution 1
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Example with Solution 2
> >>>> =======================
> >>>>
> >>>>
> >>>>
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |               Outer Destination MAC Address
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       | Outer Destination MAC Address | Outer Source MAC Address
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |                   Outer Source MAC Address
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       | Ethertype = TRILL             |  V  |M|S| RSD |   Hop
Count
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |    RSD        |   EH-length   |  UP |C|    Inner VID
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |               Inner Destination MAC Address
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       | Inner Destination MAC Address | InnerSource MAC Address
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |                    Inner Source MAC Address
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |
> >>> |
> >>>>       |                 Original Ethernet Payload
> >>> |
> >>>>       |
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>       |                           New FCS
> >>> |
> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>                TRILL Encapsulation over Ethernet with Solution 2
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> rbridge mailing list
> >>>> [e-mail]
> >>>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>>
> >>>>
> >> --
> >> ----------------------------------------
> >> Joe Touch
> >> Sr. Network Engineer, USAF TSAT Space Segment
> >
> 
> --
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment




Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42F0mfH027315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 08:00:48 -0700 (PDT)
Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net [71.106.84.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l42F0VA0016735; Wed, 2 May 2007 08:00:32 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 02 May 2007 08:00:14 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Eastlake III Donald-LDE008 <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<4626E9D3.7090502@is!!	! i.e	du><34BDD2A	[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]> <[e-mail]! ! .com> <	[e-mail]> <[e-mail]> <463! 80980.907	[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig088A1725107B612C88A761E3"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format
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, 02 May 2007 15:01:19 -0000
Status: RO
Content-Length: 2736

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig088A1725107B612C88A761E3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Eastlake III Donald-LDE008 wrote:
> Hi Joe,
>=20
> I don't see any reason to assume any bridges are involved.=20

Agreed. All functions that rbridges do that are identical to what
bridges do should be stated as an assumption (rbridges can subsume all
bridge functions except the rest of our discussion.

My point is that if a bridge (in an rbridge or not) adds a VLAN tag,
then a bridge (in an rbridge or not) nearest the destination host will
remove that tag. Even when the tag-adding bridge is the ingress rbridge,
we cannot assume in our architecture that the tag-removing bridge is the
egress rbridge; it could as easily be a bridge later in the arch.

To the extent that rbridges do this function (adding VLAN tags or
removing them), that happens to the inner header. That function has
nothing to do with rbridges per se; it doesn't belong in the rbridge
header. If rbridge functions need to refer to that tag, they know where
it would be and how to find it.

> What happens when such a message is received by a transit Rbridge? Ther=
e
> might be an outer 802.1AE tag or the like, which is removed and
> processed at the port. There might be an outer VLAN tag which is
> logically removed on receipt so frame now logically and perhaps
> physically starts with a TRILL Ethertype. The Rbridge MUST then derive
> inner VLAN tag information to decide how to forward the frame. With
> Solution 2, it is at a fixed offset from the TRILL Ethertype and close
> to the beginning of the frame, to speed cut through switching. With
> Solution 1, the Rbridge has to skip over a variable amount of extension=

> data and extract the VLAN tag information from deeper in the frame at a=

> variable offset from the TRILL Ethertype.

This argument would imply that if the rbridge were not there that a
bridge would need to extract the VLAN tag from the inner header at a
variable offset. Since that's already done, I see no problem.

Joe

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


--------------enig088A1725107B612C88A761E3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOKd+E5f5cImnZrsRAlIlAKDypGrYTfgHvMkvXwl+s+G48r1u0gCg2owq
9Prw7LTc/2E+5322Na2YNAI=
=PXnr
-----END PGP SIGNATURE-----

--------------enig088A1725107B612C88A761E3--



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 l42EU8CB020354 for <[e-mail]>; Wed, 2 May 2007 07:30:08 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-5.tower-153.messagelabs.com!1178116206!8266894!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 17953 invoked from network); 2 May 2007 14:30:07 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with SMTP; 2 May 2007 14:30:07 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l42EU2A7015416 for <[e-mail]>; Wed, 2 May 2007 07:30:06 -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 l42EU2hb008050 for <[e-mail]>; Wed, 2 May 2007 09:30:02 -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 l42EU1l5008035 for <[e-mail]>; Wed, 2 May 2007 09:30: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: Wed, 2 May 2007 10:29:57 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header Format - Version 2
thread-index: AceMbaZiVXGHWYQURBmEK1r7JxZndgAQmxog
References: <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Joe Touch" <[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 l42EU8CB020354
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format - Version 2
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, 02 May 2007 14:30:16 -0000
Status: RO
Content-Length: 3739

As I say, I don't see any reason to assume any bridges are involved. It
is true that conventional bridges (if 802.1Q compliant) associate VLAM
tag information with a frame and, if configured to do so, emit that
information in the frame by inserted a VLAN tag. But that is not
something that "can be added to an Rbridge". It is a capability that all
Rbridges MUST have (unless we want to define separate D-Rbridges which
don't support VLANs at all and Q-Rbridges which do). And far from having
"nothing to do with rbridge transit operations", such VLAN tag
information is essential to every Rbridge forwarding decision.

Donald

-----Original Message-----
From: Joe Touch [mailto:[e-mail]] 
Sent: Tuesday, May 01, 2007 11:54 PM
To: Eastlake III Donald-LDE008
Cc: Caitlin Bestler; [e-mail]
Subject: Re: [rbridge] TRILL Header Format - Version 2

Eastlake III Donald-LDE008 wrote:
> Hi Caitlin,
> 
> I just don't see how the separation you suggest could ultimately work.
> Rbridges are replacements for Bridges and have to be able to do a
> reasonable version of everything Bridges can do with VLANs, etc. So it
> has to be possible to configure Rbridges to synthesize the VLAN tag
> information on ingress of a native frame, etc. 

Why would that not go in the innermost header? The expectation is that
the bridge closest to the host removes such tags, right? If so, then
this is a conventional bridge function that can be added to an rbridge,
but has nothing to do with the rbridge transit operation, and thus
belongs in the inner header, not the TRILL header.

Joe

> So, in any case, Rbridges
> have to be able to synthesize, transport, understand, possibly map,
and
> eventually expunge the VLAN tag information. So how can there be
"clean
> layer separation"? And, in fact, the two byte format of the VLAN tag
> information is exactly the same whether the two bytes of VLAN tag info
> are prefixed by a Q/S-tag Ethertype and inserted within the
encapsulated
> frame or carried in a two byte field of the TRILL Header.
> 
> In fact, it is not clear to me how any IEEE device can get past the
> TRILL Header, because IEEE devices will not recognize the TRILL
> Ethertype. Thus, such devices will never even see the Q/S tag
Ethertype
> that might be inserted with the VLAN tag information into the
> encapsulated frame. So I just can't see any gain in wasting those two
> bytes on that Ethertype since it is not going to help any IEEE device.
> Why not make those bytes available for reserved bits and more relaxed
> field sizes in the TRILL Header as suggested in Solution 2?
> 
> Thanks,
> Donald
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Caitlin Bestler
> Sent: Tuesday, May 01, 2007 5:26 PM
> To: Silvano Gai; [e-mail]
> Subject: Re: [rbridge] TRILL Header Format - Version 2
> 
> [e-mail] wrote:
>> Included comments from Dinesh, Donald and Dino (swap egress
>> and ingress nicknames).
>>
>> Dino is for solution 1
>> Donald is for solution 2
>>
> 
> I think keeping a clean layered separation between IEEE
> and IETF is valuable, and all ties should be broken by
> keeping IEEE defined headers intact and unmodified. I'm
> not convinced that extra reserved bits justifies breaking
> that clean layering.
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge

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




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 l42ESNEM019823 for <[e-mail]>; Wed, 2 May 2007 07:28:24 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-9.tower-119.messagelabs.com!1178116103!22481244!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.10]
Received: (qmail 20715 invoked from network); 2 May 2007 14:28:23 -0000
Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-9.tower-119.messagelabs.com with SMTP; 2 May 2007 14:28:23 -0000
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l42ESMcX016340 for <[e-mail]>; Wed, 2 May 2007 07:28:22 -0700 (MST)
Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l42ESLoB023306 for <[e-mail]>; Wed, 2 May 2007 09:28:21 -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 l42ESKr3023299 for <[e-mail]>; Wed, 2 May 2007 09:28:21 -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, 2 May 2007 10:28:16 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header Format
thread-index: AceMbITSyxoaeahNQja243rIDBZU4QAPlFIg
References: <[e-mail]>	<461ED550.9080501@isi.!edu>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<4626E9D3.7090502@is!!	! i.e	du><34BDD2A	[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]> <[e-mail]! ! .com> <	[e-mail]> <[e-mail]> <46380980.907 [e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Joe Touch" <[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 l42ESNEM019823
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format
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, 02 May 2007 14:28:47 -0000
Status: RO
Content-Length: 13451

Hi Joe,

I don't see any reason to assume any bridges are involved. To the extent
that Rbridges do what bridges do, only better, one would expect them to
replace all bridges. So in the end state, which it seems to me is what
you should optimize for, there are no bridges. Even if a bridge had
inserted a VLAN tag before the ingress Rbridge, that Rbridge might be
performing some mapping on VLAN IDs so it has to change the VLAN tag and
it might be the case the egress Rbridge has to remove the VLAN tag
anyway.

There is no suggestion that we change the two byte format for the VLAN
tag information, just change how this meta information is incorporated
in messages with a TRILL header being transmitted between Rbridges.

What happens when such a message is received by a transit Rbridge? There
might be an outer 802.1AE tag or the like, which is removed and
processed at the port. There might be an outer VLAN tag which is
logically removed on receipt so frame now logically and perhaps
physically starts with a TRILL Ethertype. The Rbridge MUST then derive
inner VLAN tag information to decide how to forward the frame. With
Solution 2, it is at a fixed offset from the TRILL Ethertype and close
to the beginning of the frame, to speed cut through switching. With
Solution 1, the Rbridge has to skip over a variable amount of extension
data and extract the VLAN tag information from deeper in the frame at a
variable offset from the TRILL Ethertype.

For a TRILL encapsulated frame between Rbridges, it seems to me that all
the meta information such as egress Rbridge, multi-destination bit, VLAN
ID, etc., should all be placed for the convenience of Rbridges. While it
is true that an egress Rbridge might have to insert a VLAN tag, most
likely all the meta information will be tossed at the egress Rbridge
which will just output an untagged native frame.

Furthermore, I don't see how debugging equipment is going to be
confused. If the debugging equipment understands the TRILL Ethertype, it
will know where the two bytes of VLAN information are and can display
them appropriately no matter what the WG decides. If it does not
understand the TRILL Ethertype, then it can look no further into the
frame since it would have no idea how long the TRILL tag is or how it is
structured.

Thanks,
Donald

-----Original Message-----
From: Joe Touch [mailto:[e-mail]] 
Sent: Tuesday, May 01, 2007 11:46 PM
To: Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format

Eastlake III Donald-LDE008 wrote:
> Hi Joe,
> 
> I see it as exactly the other way.
> 
> Most commonly, the VLAN ID is associated with a native frame only
> because of the port it is received on, although it is certainly
possible
> for an end station to include one. Thus, in the most common case, it
is
> the current design which requires the ingress Rbridge to insert a Q/S
> tag inside the encapsulated frame, thus modifying it, and similarly
most
> commonly requires the egress Rbridge to remove that tag from inside
the
> encapsulated frame, although their can be configurations where it is
> retained.
> 
> Thus, Solution 2 would generally require *less* modification of
> encapsulated frames at ingress and egress than would Solution 1.

Agreed - IF the VLAN tag is something we insert/delete, then agreed.
That presumes that the ingress rbridge is the receive port that adds the
VLAN tag.

However, I read the previous posts as "extract the VLAN from the inner
header and put it in the TRILL header. That would assume some other
bridge had inserted the VLAN tag. If that's the case, then I don't see
the utility in moving things around.

> The above is in answer to your point on 'modification' since I believe
> Solution 2 results in less modification. I'm not sure I understand
your
> "parsing and debugging" point. For every Rbridge other than the
ingress
> Rbridge, for every frame the Rbridge has to (a) find the TRILL Header
> and (b) find the VLAN tag. It seems to me to make the parsing job
> simpler to put the VLAN tag information at a fixed location in the
TRILL
> Header.

It's in a fixed location if it's in the inner header too, however if it
truly belongs to the inner header, regardless of whether we act on it in
conjunction with TRILL information, it ought to stay in the inner
header. Otherwise debugging equipment will show a false inner header
that lacks the VLAN tag it owns.

Joe

> 
> Donald
> 
> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Tuesday, May 01, 2007 5:33 PM
> To: Eastlake III Donald-LDE008
> Cc: Dinesh G Dutt; Silvano Gai; [e-mail]
> Subject: Re: [rbridge] TRILL Header Format
> 
> Eastlake III Donald-LDE008 wrote:
>> Hi,
>>
>> I agree with Dinesh's comment and would also like to say that my
>> personal preference is for Solution 2. I just don't feel there are
>> enough reserved bit available for future use in the minimal Solution
1
>> and since, in the general case, every Rbridge has to look at the VLAN
>> ID, putting it in a fixed place nearer the beginning of the frame, as
>> done in Solution 2, seems like a good idea.
> 
> I agree in spirit, but don't agree that the inner frame should be
> modified during processing; this just complicates parsing and
debugging,
> and increases the potential for implementation errors.
> 
> IMO, the VLAN tags should be copied, not moved.
> 
> Joe
> 
>> Thanks,
>> Donald 
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
> On
>> Behalf Of Dinesh G Dutt
>> Sent: Monday, April 30, 2007 3:19 PM
>> To: Silvano Gai
>> Cc: [e-mail]
>> Subject: Re: [rbridge] TRILL Header Format
>>
>> Two small corrections. In the second format, we really don't need any

>> indication of .1Q/.1S. The tag that is to be added at the egress port

>> maybe different from the tag that we received at the ingress port and
> is
>> part of the port logic. For example, the frame may have come in with
a
> 
>> .1Q tag and may go out a port that accepts no tagging at all.
>>
>> Given that we don't need to carry any indication of .1Q/.1S in the
> TRILL
>> header, I suggest that we also define the field "Inner 802.1Q/S tag"
> to 
>> be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator and
> call
>> it DE (drop eligibility). This way if RBridges along the way can
> choose 
>> to set the DE bit in the inner header, instead of treating it as an 
>> opaque field.
>>
>> Dinesh
>> Silvano Gai wrote:
>>> The purpose of the following message is to converge on the final
>>> structure of the TRILL header.
>>>
>>> The format proposed in:
>>>
>
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03
>>> .txt
>>> has been stable for a while. This message only describes the
>>> differences.
>>>
>>> At the last IETF Donald proposed to support a single extension
header
>>> containing multiple extensions.
>>>
>>> After some discussion two solutions seem possible. Please express
> your
>>> preference by replying to this email.
>>>
>>> -- Silvano
>>>
>>>
>>> Solution 1
>>> ==========
>>>
>>>
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>                                       | V |M|RSD|EH-length| Hop
Count
>> |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> Where:
>>> - RSD (2 bits) is reserved
>>> - EH-Length (5 bits) is the extension header length, expressed in
>> units
>>> of in 4 bytes words.
>>>
>>> If EH-length is zero there is no extension header;
>>> else, the extensions follow immediately after the Egress Rbridge
>>> Nickname field, and the total length of all the extensions is as
>>> indicated by the EH-length field, expressed in units of 4-byte
words.
>>>
>>> This solution allows 128 bytes of extensions.
>>>
>>>
>>> Solution 2
>>> ==========
>>>
>>>
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>                                       |  V  |M|S| RSD |   Hop Count
>> |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       |    RSD        |   EH-length   |  Inner IEEE 802.1Q/S tag
>> |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
>> |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and
> Priority)
>>> into the TRILL header. The Inner 1Q/1S tag is no longer present in
> the
>>> inner frame.
>>>
>>> This simplifies the parsing for the core RBridges. On the other hand
>> the
>>> Ingress/Egress Rbridges need to do slightly more work. 
>>>
>>> This has more reserved space. Since the inner 1Q/1S tag is removed
>> from
>>> the frame (4 bytes), it uses the same overall space of solution 1.
>>>
>>> The S bit indicates if the inner header was 1Q (S=0) or 1S (S=1).
>>>
>>> The EH-length is 8 bits, with a granularity of 2 bytes it allows up
> to
>>> 512 bytes of extensions.
>>>
>>> The Hop Count can grow to 8 bits.
>>>
>>>
>>> A word of caution
>>> =================
>>>
>>> Extensions are very appealing, but their practical deployment has
> been
>>> very limited. Often Router and Switches are not able to process in
HW
>>> frames with extensions and they send them to SW.
>>>
>>>
>>> Example with Solution 1
>>> ======================= 
>>>
>>>
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       |               Outer Destination MAC Address
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       | Outer Destination MAC Address | Outer Source MAC Address
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       |                   Outer Source MAC Address
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       | Ethertype = TRILL             | V |M|RSD|EH-length| Hop
Count
>> |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>       |               Inner Destination MAC Address
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       | Inner Destination MAC Address | InnerSource MAC Address
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       |                    Inner Source MAC Address
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       | Ethertype = IEEE 802.1Q       | UP  |C|   Inner VID
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       |
>> | 
>>>       |                 Original Ethernet Payload
>> | 
>>>       |
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       |                           New FCS
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>              TRILL Encapsulation over Ethernet with Solution 1
>>>
>>>
>>>
>>>
>>> Example with Solution 2
>>> =======================
>>>
>>>
>>>
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       |               Outer Destination MAC Address
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       | Outer Destination MAC Address | Outer Source MAC Address
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       |                   Outer Source MAC Address
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       | Ethertype = TRILL             |  V  |M|S| RSD |   Hop Count
>> |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       |    RSD        |   EH-length   |  UP |C|    Inner VID
>> |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
>> |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>       |               Inner Destination MAC Address
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       | Inner Destination MAC Address | InnerSource MAC Address
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       |                    Inner Source MAC Address
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       |
>> | 
>>>       |                 Original Ethernet Payload
>> | 
>>>       |
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>       |                           New FCS
>> | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>                TRILL Encapsulation over Ethernet with Solution 2
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>>   
> 

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




Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42AhV8n027168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 03:43:31 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l42AiO4N030981; Wed, 2 May 2007 05:44:24 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 2 May 2007 05:43:29 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 2 May 2007 05:43:01 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header Format
Thread-Index: AceMOFmd34CG6+gpShO0FWctc8TnBwAJ/CIgABB0siAAAMSUMAAAIEfw
References: <[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]><461ED550.9080501@isi.!edu>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<4626E9D3.7090502@is!!	!i.e	du><34BDD2A	[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]><[e-mail]! ! !  .com> <4637B1F6.30 [e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 02 May 2007 10:43:29.0071 (UTC) FILETIME=[B87873F0:01C78CA6]
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 l42AhV8n027168
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format
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, 02 May 2007 10:43:58 -0000
Status: RO
Content-Length: 13878

Donald,

	What you've just described sounds a lot like standard
bridging - i.e. - 802.1Q is used, but 802.3 encapsulation MAY 
be used if no VLANs are present.

	Perhaps I am missing (or misunderstanding) something?

	In the TRILL header, I would very much like to have just
one format.  What goes in the inner header may or may not be
changed in a device that has RBridging function, but should be
decided - not by the RBridging function within that device, but
- by the standard bridging function within that same device.

	In other words, by keeping to a separation of the content
of the "inner" 802 header and the content of the TRILL header,
the device implementations will be able to do the "standard
bridging" things they should do - AND - the TRILL encapsulation
independently...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Wednesday, May 02, 2007 6:35 AM
> To: Eric Gray (LO/EUS)
> Cc: [e-mail]
> Subject: RE: [rbridge] TRILL Header Format
> Importance: High
> 
> The present design defaults to always inserting four bytes of VLAN tag
> Ethertype and VLAN tag data inside the encapsulated frame although it
> does provide that they "MAY" be omitted when everything is 
> defaulting to
> VLAN 1.
> 
> Donald
> 
> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> Sent: Wednesday, May 02, 2007 6:14 AM
> To: Eastlake III Donald-LDE008; Joe Touch
> Cc: [e-mail]
> Subject: RE: [rbridge] TRILL Header Format
> 
> Donald,
> 
> 	I think you're losing sight of an important aspect of
> the proposal you're advocating - it assumes that it is okay 
> to always include space of a VLAN tag, even when one is not
> needed.  This further implies that VLAN tagging is the case
> we wish to optimize for (i.e. - the "normal" case), and that
> implies that configuration will normally be required.
> 
> 	I much prefer not to include extra space in the TRILL
> header that optimizes for the case where TRILL adds no real
> value over conventional IS-IS routing and bridging.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Eastlake III 
> > Donald-LDE008
> > Sent: Tuesday, May 01, 2007 10:43 PM
> > To: Joe Touch
> > Cc: [e-mail]
> > Subject: Re: [rbridge] TRILL Header Format
> > 
> > Hi Joe,
> > 
> > I see it as exactly the other way.
> > 
> > Most commonly, the VLAN ID is associated with a native frame only
> > because of the port it is received on, although it is 
> > certainly possible
> > for an end station to include one. Thus, in the most common 
> > case, it is
> > the current design which requires the ingress Rbridge to 
> insert a Q/S
> > tag inside the encapsulated frame, thus modifying it, and 
> > similarly most
> > commonly requires the egress Rbridge to remove that tag from 
> > inside the
> > encapsulated frame, although their can be configurations where it is
> > retained.
> > 
> > Thus, Solution 2 would generally require *less* modification of
> > encapsulated frames at ingress and egress than would Solution 1.
> > 
> > The above is in answer to your point on 'modification' 
> since I believe
> > Solution 2 results in less modification. I'm not sure I 
> > understand your
> > "parsing and debugging" point. For every Rbridge other than 
> > the ingress
> > Rbridge, for every frame the Rbridge has to (a) find the 
> TRILL Header
> > and (b) find the VLAN tag. It seems to me to make the parsing job
> > simpler to put the VLAN tag information at a fixed location 
> > in the TRILL
> > Header.
> > 
> > Donald
> > 
> > -----Original Message-----
> > From: Joe Touch [mailto:[e-mail]] 
> > Sent: Tuesday, May 01, 2007 5:33 PM
> > To: Eastlake III Donald-LDE008
> > Cc: Dinesh G Dutt; Silvano Gai; [e-mail]
> > Subject: Re: [rbridge] TRILL Header Format
> > 
> > Eastlake III Donald-LDE008 wrote:
> > > Hi,
> > > 
> > > I agree with Dinesh's comment and would also like to say that my
> > > personal preference is for Solution 2. I just don't feel there are
> > > enough reserved bit available for future use in the minimal 
> > Solution 1
> > > and since, in the general case, every Rbridge has to look 
> > at the VLAN
> > > ID, putting it in a fixed place nearer the beginning of the 
> > frame, as
> > > done in Solution 2, seems like a good idea.
> > 
> > I agree in spirit, but don't agree that the inner frame should be
> > modified during processing; this just complicates parsing and 
> > debugging,
> > and increases the potential for implementation errors.
> > 
> > IMO, the VLAN tags should be copied, not moved.
> > 
> > Joe
> > 
> > > Thanks,
> > > Donald 
> > > 
> > > -----Original Message-----
> > > From: [e-mail] 
> [mailto:[e-mail]]
> > On
> > > Behalf Of Dinesh G Dutt
> > > Sent: Monday, April 30, 2007 3:19 PM
> > > To: Silvano Gai
> > > Cc: [e-mail]
> > > Subject: Re: [rbridge] TRILL Header Format
> > > 
> > > Two small corrections. In the second format, we really 
> > don't need any 
> > > indication of .1Q/.1S. The tag that is to be added at the 
> > egress port 
> > > maybe different from the tag that we received at the 
> > ingress port and
> > is
> > > 
> > > part of the port logic. For example, the frame may have 
> > come in with a
> > 
> > > .1Q tag and may go out a port that accepts no tagging at all.
> > > 
> > > Given that we don't need to carry any indication of .1Q/.1S in the
> > TRILL
> > > 
> > > header, I suggest that we also define the field "Inner 
> 802.1Q/S tag"
> > to 
> > > be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI 
> indicator and
> > call
> > > 
> > > it DE (drop eligibility). This way if RBridges along the way can
> > choose 
> > > to set the DE bit in the inner header, instead of 
> treating it as an 
> > > opaque field.
> > > 
> > > Dinesh
> > > Silvano Gai wrote:
> > >> The purpose of the following message is to converge on the final
> > >> structure of the TRILL header.
> > >>
> > >> The format proposed in:
> > >>
> > >
> > http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-p
> > rotocol-03
> > >> .txt
> > >> has been stable for a while. This message only describes the
> > >> differences.
> > >>
> > >> At the last IETF Donald proposed to support a single 
> > extension header
> > >> containing multiple extensions.
> > >>
> > >> After some discussion two solutions seem possible. Please express
> > your
> > >> preference by replying to this email.
> > >>
> > >> -- Silvano
> > >>
> > >>
> > >> Solution 1
> > >> ==========
> > >>
> > >>
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>                                       | V 
> > |M|RSD|EH-length| Hop Count
> > > |
> > >>
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >> Where:
> > >> - RSD (2 bits) is reserved
> > >> - EH-Length (5 bits) is the extension header length, expressed in
> > > units
> > >> of in 4 bytes words.
> > >>
> > >> If EH-length is zero there is no extension header;
> > >> else, the extensions follow immediately after the Egress Rbridge
> > >> Nickname field, and the total length of all the extensions is as
> > >> indicated by the EH-length field, expressed in units of 
> > 4-byte words.
> > >>
> > >> This solution allows 128 bytes of extensions.
> > >>
> > >>
> > >> Solution 2
> > >> ==========
> > >>
> > >>
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>                                       |  V  |M|S| RSD |  
>  Hop Count
> > > |
> > >>
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       |    RSD        |   EH-length   |  Inner IEEE 802.1Q/S tag
> > > |
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > > |
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >> This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and
> > Priority)
> > >> into the TRILL header. The Inner 1Q/1S tag is no longer 
> present in
> > the
> > >> inner frame.
> > >>
> > >> This simplifies the parsing for the core RBridges. On the 
> > other hand
> > > the
> > >> Ingress/Egress Rbridges need to do slightly more work. 
> > >>
> > >> This has more reserved space. Since the inner 1Q/1S tag 
> is removed
> > > from
> > >> the frame (4 bytes), it uses the same overall space of 
> solution 1.
> > >>
> > >> The S bit indicates if the inner header was 1Q (S=0) or 1S (S=1).
> > >>
> > >> The EH-length is 8 bits, with a granularity of 2 bytes 
> it allows up
> > to
> > >> 512 bytes of extensions.
> > >>
> > >> The Hop Count can grow to 8 bits.
> > >>
> > >>
> > >> A word of caution
> > >> =================
> > >>
> > >> Extensions are very appealing, but their practical deployment has
> > been
> > >> very limited. Often Router and Switches are not able to 
> > process in HW
> > >> frames with extensions and they send them to SW.
> > >>
> > >>
> > >> Example with Solution 1
> > >> ======================= 
> > >>
> > >>
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       |               Outer Destination MAC Address
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       | Outer Destination MAC Address | Outer Source MAC Address
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       |                   Outer Source MAC Address
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       | Ethertype = TRILL             | V 
> > |M|RSD|EH-length| Hop Count
> > > |
> > >>
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >>       |               Inner Destination MAC Address
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       | Inner Destination MAC Address | InnerSource MAC Address
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       |                    Inner Source MAC Address
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Inner VID
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       |
> > > | 
> > >>       |                 Original Ethernet Payload
> > > | 
> > >>       |
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       |                           New FCS
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>              TRILL Encapsulation over Ethernet with Solution 1
> > >>
> > >>
> > >>
> > >>
> > >> Example with Solution 2
> > >> =======================
> > >>
> > >>
> > >>
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       |               Outer Destination MAC Address
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       | Outer Destination MAC Address | Outer Source MAC Address
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       |                   Outer Source MAC Address
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       | Ethertype = TRILL             |  V  |M|S| RSD |  
>  Hop Count
> > > |
> > >>
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       |    RSD        |   EH-length   |  UP |C|    Inner VID
> > > |
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > > |
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >>       |               Inner Destination MAC Address
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       | Inner Destination MAC Address | InnerSource MAC Address
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       |                    Inner Source MAC Address
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       |
> > > | 
> > >>       |                 Original Ethernet Payload
> > > | 
> > >>       |
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>       |                           New FCS
> > > | 
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > >>                TRILL Encapsulation over Ethernet with Solution 2
> > >>
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> rbridge mailing list
> > >> [e-mail]
> > >> http://mailman.postel.org/mailman/listinfo/rbridge
> > >>
> > >>   
> > > 
> > 
> > -- 
> > ----------------------------------------
> > Joe Touch
> > Sr. Network Engineer, USAF TSAT Space Segment
> > 
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l42AYvh9025527 for <[e-mail]>; Wed, 2 May 2007 03:34:57 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-4.tower-119.messagelabs.com!1178102095!20522946!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [144.189.100.105]
Received: (qmail 19581 invoked from network); 2 May 2007 10:34:56 -0000
Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-4.tower-119.messagelabs.com with SMTP; 2 May 2007 10:34:56 -0000
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l42AYtF7014611 for <[e-mail]>; Wed, 2 May 2007 03:34:55 -0700 (MST)
Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l42AYscH014644 for <[e-mail]>; Wed, 2 May 2007 05:34:55 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l42AYrTB014634 for <[e-mail]>; Wed, 2 May 2007 05:34:54 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 2 May 2007 06:34:33 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header Format
thread-index: AceMOFmd34CG6+gpShO0FWctc8TnBwAJ/CIgABB0siAAAMSUMA==
References: <[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]><461ED550.9080501@isi.!edu>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<4626E9D3.7090502@is!!	!i.e	du><34BDD2A	[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]><[e-mail]! ! .com> < 4637B1F6.304 [e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[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 l42AYvh9025527
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format
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, 02 May 2007 10:35:14 -0000
Status: RO
Content-Length: 12005

The present design defaults to always inserting four bytes of VLAN tag
Ethertype and VLAN tag data inside the encapsulated frame although it
does provide that they "MAY" be omitted when everything is defaulting to
VLAN 1.

Donald

-----Original Message-----
From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
Sent: Wednesday, May 02, 2007 6:14 AM
To: Eastlake III Donald-LDE008; Joe Touch
Cc: [e-mail]
Subject: RE: [rbridge] TRILL Header Format

Donald,

	I think you're losing sight of an important aspect of
the proposal you're advocating - it assumes that it is okay 
to always include space of a VLAN tag, even when one is not
needed.  This further implies that VLAN tagging is the case
we wish to optimize for (i.e. - the "normal" case), and that
implies that configuration will normally be required.

	I much prefer not to include extra space in the TRILL
header that optimizes for the case where TRILL adds no real
value over conventional IS-IS routing and bridging.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Tuesday, May 01, 2007 10:43 PM
> To: Joe Touch
> Cc: [e-mail]
> Subject: Re: [rbridge] TRILL Header Format
> 
> Hi Joe,
> 
> I see it as exactly the other way.
> 
> Most commonly, the VLAN ID is associated with a native frame only
> because of the port it is received on, although it is 
> certainly possible
> for an end station to include one. Thus, in the most common 
> case, it is
> the current design which requires the ingress Rbridge to insert a Q/S
> tag inside the encapsulated frame, thus modifying it, and 
> similarly most
> commonly requires the egress Rbridge to remove that tag from 
> inside the
> encapsulated frame, although their can be configurations where it is
> retained.
> 
> Thus, Solution 2 would generally require *less* modification of
> encapsulated frames at ingress and egress than would Solution 1.
> 
> The above is in answer to your point on 'modification' since I believe
> Solution 2 results in less modification. I'm not sure I 
> understand your
> "parsing and debugging" point. For every Rbridge other than 
> the ingress
> Rbridge, for every frame the Rbridge has to (a) find the TRILL Header
> and (b) find the VLAN tag. It seems to me to make the parsing job
> simpler to put the VLAN tag information at a fixed location 
> in the TRILL
> Header.
> 
> Donald
> 
> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Tuesday, May 01, 2007 5:33 PM
> To: Eastlake III Donald-LDE008
> Cc: Dinesh G Dutt; Silvano Gai; [e-mail]
> Subject: Re: [rbridge] TRILL Header Format
> 
> Eastlake III Donald-LDE008 wrote:
> > Hi,
> > 
> > I agree with Dinesh's comment and would also like to say that my
> > personal preference is for Solution 2. I just don't feel there are
> > enough reserved bit available for future use in the minimal 
> Solution 1
> > and since, in the general case, every Rbridge has to look 
> at the VLAN
> > ID, putting it in a fixed place nearer the beginning of the 
> frame, as
> > done in Solution 2, seems like a good idea.
> 
> I agree in spirit, but don't agree that the inner frame should be
> modified during processing; this just complicates parsing and 
> debugging,
> and increases the potential for implementation errors.
> 
> IMO, the VLAN tags should be copied, not moved.
> 
> Joe
> 
> > Thanks,
> > Donald 
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Dinesh G Dutt
> > Sent: Monday, April 30, 2007 3:19 PM
> > To: Silvano Gai
> > Cc: [e-mail]
> > Subject: Re: [rbridge] TRILL Header Format
> > 
> > Two small corrections. In the second format, we really 
> don't need any 
> > indication of .1Q/.1S. The tag that is to be added at the 
> egress port 
> > maybe different from the tag that we received at the 
> ingress port and
> is
> > 
> > part of the port logic. For example, the frame may have 
> come in with a
> 
> > .1Q tag and may go out a port that accepts no tagging at all.
> > 
> > Given that we don't need to carry any indication of .1Q/.1S in the
> TRILL
> > 
> > header, I suggest that we also define the field "Inner 802.1Q/S tag"
> to 
> > be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator and
> call
> > 
> > it DE (drop eligibility). This way if RBridges along the way can
> choose 
> > to set the DE bit in the inner header, instead of treating it as an 
> > opaque field.
> > 
> > Dinesh
> > Silvano Gai wrote:
> >> The purpose of the following message is to converge on the final
> >> structure of the TRILL header.
> >>
> >> The format proposed in:
> >>
> >
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-p
> rotocol-03
> >> .txt
> >> has been stable for a while. This message only describes the
> >> differences.
> >>
> >> At the last IETF Donald proposed to support a single 
> extension header
> >> containing multiple extensions.
> >>
> >> After some discussion two solutions seem possible. Please express
> your
> >> preference by replying to this email.
> >>
> >> -- Silvano
> >>
> >>
> >> Solution 1
> >> ==========
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>                                       | V 
> |M|RSD|EH-length| Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> Where:
> >> - RSD (2 bits) is reserved
> >> - EH-Length (5 bits) is the extension header length, expressed in
> > units
> >> of in 4 bytes words.
> >>
> >> If EH-length is zero there is no extension header;
> >> else, the extensions follow immediately after the Egress Rbridge
> >> Nickname field, and the total length of all the extensions is as
> >> indicated by the EH-length field, expressed in units of 
> 4-byte words.
> >>
> >> This solution allows 128 bytes of extensions.
> >>
> >>
> >> Solution 2
> >> ==========
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>                                       |  V  |M|S| RSD |   Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |    RSD        |   EH-length   |  Inner IEEE 802.1Q/S tag
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and
> Priority)
> >> into the TRILL header. The Inner 1Q/1S tag is no longer present in
> the
> >> inner frame.
> >>
> >> This simplifies the parsing for the core RBridges. On the 
> other hand
> > the
> >> Ingress/Egress Rbridges need to do slightly more work. 
> >>
> >> This has more reserved space. Since the inner 1Q/1S tag is removed
> > from
> >> the frame (4 bytes), it uses the same overall space of solution 1.
> >>
> >> The S bit indicates if the inner header was 1Q (S=0) or 1S (S=1).
> >>
> >> The EH-length is 8 bits, with a granularity of 2 bytes it allows up
> to
> >> 512 bytes of extensions.
> >>
> >> The Hop Count can grow to 8 bits.
> >>
> >>
> >> A word of caution
> >> =================
> >>
> >> Extensions are very appealing, but their practical deployment has
> been
> >> very limited. Often Router and Switches are not able to 
> process in HW
> >> frames with extensions and they send them to SW.
> >>
> >>
> >> Example with Solution 1
> >> ======================= 
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |               Outer Destination MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Outer Destination MAC Address | Outer Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                   Outer Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = TRILL             | V 
> |M|RSD|EH-length| Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |               Inner Destination MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Inner Destination MAC Address | InnerSource MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                    Inner Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Inner VID
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |
> > | 
> >>       |                 Original Ethernet Payload
> > | 
> >>       |
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                           New FCS
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>              TRILL Encapsulation over Ethernet with Solution 1
> >>
> >>
> >>
> >>
> >> Example with Solution 2
> >> =======================
> >>
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |               Outer Destination MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Outer Destination MAC Address | Outer Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                   Outer Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = TRILL             |  V  |M|S| RSD |   Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |    RSD        |   EH-length   |  UP |C|    Inner VID
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |               Inner Destination MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Inner Destination MAC Address | InnerSource MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                    Inner Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |
> > | 
> >>       |                 Original Ethernet Payload
> > | 
> >>       |
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                           New FCS
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>                TRILL Encapsulation over Ethernet with Solution 2
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> rbridge mailing list
> >> [e-mail]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>
> >>   
> > 
> 
> -- 
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42AVVBM024680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 03:31:31 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l42AWQIZ028763; Wed, 2 May 2007 05:32:26 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 2 May 2007 05:31:30 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 2 May 2007 05:31:02 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Optional configuration of RBridge nickname
Thread-Index: AceMc7uUR/qzTl66Sn2N6zS2CQqQvAAMCO3Q
References: <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 02 May 2007 10:31:30.0954 (UTC) FILETIME=[0C707EA0:01C78CA5]
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 l42AVVBM024680
Subject: Re: [rbridge] Optional configuration of RBridge nickname
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, 02 May 2007 10:31:41 -0000
Status: RO
Content-Length: 3139

Radia,

	I would object strenuously to the use of a priority
value in resolving the "ownership" of a nickname.

	The over-riding priority has to be determined in a 
way that ensures the existing network continues to work 
if a new device is inserted (i.e. - it would be best if
any device were going to fail, it should be the one that
has just been added).

	Adding "priority" would allow any device to assert
a high priority ownership of any nickname currently in 
use, which would then make it trivially easy to stage a 
network disabling attack.

	Having it be so easy to attack the network, would
necessitate mandatory defenses, almost certainly meaning
that configuration would be required - possibly excepting
the option of having the very highest priority value be 
the default assumed when no configuration is done at any
RBridge.

	In either case (configuration absolutely required,
or default highest priority with no configuration) would
defeat your purpose.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Radia Perlman
> Sent: Wednesday, May 02, 2007 12:26 AM
> To: [e-mail]
> Subject: [rbridge] Optional configuration of RBridge nickname
> 
> Someone suggested that it would be useful to allow configuration of 
> nicknames, so
> that nicknames can be more stable, and there would be no worry of an 
> RBridge coming
> up and usurping a nickname from someone else. I'd like:
> a) for it to remain possible to be zero configuration (as in, not 
> necessary to configure
> a nickname
> b) allow a mixture of configured and unconfigured nicknames
> c) work even with misconfiguration (configuring two RBridges with the 
> same nickname)
> d) never allow an unconfigured nickname to accidentally usurp 
> a nickname 
> from
> a ocnfigured RBridge
> 
> So I'm proposing the following:
> 
> a) allow configuration of a nickname value
> b) have a "priority" value for owning a nickname
> that can also be configured, which I'd propose would be an 8-bit byte,
> where only the bottom 7 bits can be configured
> c) the 8th bit of the priority byte (the most significant 
> bit) indicates 
> whether
> the nickname was configured or not
> d) the default is priority=0 for RBridges that have not been 
> configured with
> a nickname value, and priority=128 (top bit 1, rest 0) for an 
> RBridge that
> has been configured with a nickname
> e) other values of nickname priority might be useful. For 
> instance, an 
> RBridge
> implementation might increment the nickname value after it's held the 
> nickname
> for some amount of time (say 10 minutes). Or someone might 
> want to configure
> some RBridges to have a more stable nickname (by giving them higher 
> priority).
> f) Basically, the (nickname priority | system ID) is like the DR 
> priority in IS-IS,
> where the DR election is based on (priority | system ID)
> 
> Anyone object to this?
> 
> Radia
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42AIJwq022014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 03:18:19 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l42AJCot027030; Wed, 2 May 2007 05:19:12 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 2 May 2007 05:18:17 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 2 May 2007 05:17:49 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header Format - Version 2
Thread-Index: AceCN5wruuaX6T3WSK29pQEeR2PdVAAdXODQACgoHDAAOtOJ4AAICWcAAFYPHuAAaHHwIAAwvwogAQg4W+AAC3i6EAAPcOXg
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, "Caitlin Bestler" <[e-mail]>
X-OriginalArrivalTime: 02 May 2007 10:18:17.0403 (UTC) FILETIME=[337238B0:01C78CA3]
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 l42AIJwq022014
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format - Version 2
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, 02 May 2007 10:18:52 -0000
Status: RO
Content-Length: 3243

Donald,

	I agree with Caitlin and would point out that the "layer
violation" is a concern because there are other forms of ".Q"
(and ".Q-like") encapsulations out there, and we might want to
consider what the implications of the use of these other forms
of L2 encapsulation are on what should go in the fields you're
proposing we add to the TRILL header.

	If we don't add those fields, then it is not necessary to
concern ourselves with what might need to go into them...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Tuesday, May 01, 2007 11:07 PM
> To: Caitlin Bestler
> Cc: [e-mail]
> Subject: Re: [rbridge] TRILL Header Format - Version 2
> 
> Hi Caitlin,
> 
> I just don't see how the separation you suggest could ultimately work.
> Rbridges are replacements for Bridges and have to be able to do a
> reasonable version of everything Bridges can do with VLANs, etc. So it
> has to be possible to configure Rbridges to synthesize the VLAN tag
> information on ingress of a native frame, etc. So, in any 
> case, Rbridges
> have to be able to synthesize, transport, understand, 
> possibly map, and
> eventually expunge the VLAN tag information. So how can there 
> be "clean
> layer separation"? And, in fact, the two byte format of the VLAN tag
> information is exactly the same whether the two bytes of VLAN tag info
> are prefixed by a Q/S-tag Ethertype and inserted within the 
> encapsulated
> frame or carried in a two byte field of the TRILL Header.
> 
> In fact, it is not clear to me how any IEEE device can get past the
> TRILL Header, because IEEE devices will not recognize the TRILL
> Ethertype. Thus, such devices will never even see the Q/S tag 
> Ethertype
> that might be inserted with the VLAN tag information into the
> encapsulated frame. So I just can't see any gain in wasting those two
> bytes on that Ethertype since it is not going to help any IEEE device.
> Why not make those bytes available for reserved bits and more relaxed
> field sizes in the TRILL Header as suggested in Solution 2?
> 
> Thanks,
> Donald
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On
> Behalf Of Caitlin Bestler
> Sent: Tuesday, May 01, 2007 5:26 PM
> To: Silvano Gai; [e-mail]
> Subject: Re: [rbridge] TRILL Header Format - Version 2
> 
> [e-mail] wrote:
> > Included comments from Dinesh, Donald and Dino (swap egress
> > and ingress nicknames).
> > 
> > Dino is for solution 1
> > Donald is for solution 2
> > 
> 
> I think keeping a clean layered separation between IEEE
> and IETF is valuable, and all ties should be broken by
> keeping IEEE defined headers intact and unmodified. I'm
> not convinced that extra reserved bits justifies breaking
> that clean layering.
> 
> 
> 
> _______________________________________________
> 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 imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l42AEqsT021480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 2 May 2007 03:14:53 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l42AE7Cr002213; Wed, 2 May 2007 05:14:08 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 2 May 2007 05:14:46 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 2 May 2007 05:14:16 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header Format
Thread-Index: AceMOFmd34CG6+gpShO0FWctc8TnBwAJ/CIgABB0siA=
References: <[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]><461ED550.9080501@isi.!edu>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<4626E9D3.7090502@is!!	!i.e	du><34BDD2A	[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]><[e-mail]! ! .com> <46 37B1F6.30406 [e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, "Joe Touch" <[e-mail]>
X-OriginalArrivalTime: 02 May 2007 10:14:46.0609 (UTC) FILETIME=[B5CD9C10:01C78CA2]
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 l42AEqsT021480
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format
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, 02 May 2007 10:15:12 -0000
Status: RO
Content-Length: 11542

Donald,

	I think you're losing sight of an important aspect of
the proposal you're advocating - it assumes that it is okay 
to always include space of a VLAN tag, even when one is not
needed.  This further implies that VLAN tagging is the case
we wish to optimize for (i.e. - the "normal" case), and that
implies that configuration will normally be required.

	I much prefer not to include extra space in the TRILL
header that optimizes for the case where TRILL adds no real
value over conventional IS-IS routing and bridging.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Tuesday, May 01, 2007 10:43 PM
> To: Joe Touch
> Cc: [e-mail]
> Subject: Re: [rbridge] TRILL Header Format
> 
> Hi Joe,
> 
> I see it as exactly the other way.
> 
> Most commonly, the VLAN ID is associated with a native frame only
> because of the port it is received on, although it is 
> certainly possible
> for an end station to include one. Thus, in the most common 
> case, it is
> the current design which requires the ingress Rbridge to insert a Q/S
> tag inside the encapsulated frame, thus modifying it, and 
> similarly most
> commonly requires the egress Rbridge to remove that tag from 
> inside the
> encapsulated frame, although their can be configurations where it is
> retained.
> 
> Thus, Solution 2 would generally require *less* modification of
> encapsulated frames at ingress and egress than would Solution 1.
> 
> The above is in answer to your point on 'modification' since I believe
> Solution 2 results in less modification. I'm not sure I 
> understand your
> "parsing and debugging" point. For every Rbridge other than 
> the ingress
> Rbridge, for every frame the Rbridge has to (a) find the TRILL Header
> and (b) find the VLAN tag. It seems to me to make the parsing job
> simpler to put the VLAN tag information at a fixed location 
> in the TRILL
> Header.
> 
> Donald
> 
> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Tuesday, May 01, 2007 5:33 PM
> To: Eastlake III Donald-LDE008
> Cc: Dinesh G Dutt; Silvano Gai; [e-mail]
> Subject: Re: [rbridge] TRILL Header Format
> 
> Eastlake III Donald-LDE008 wrote:
> > Hi,
> > 
> > I agree with Dinesh's comment and would also like to say that my
> > personal preference is for Solution 2. I just don't feel there are
> > enough reserved bit available for future use in the minimal 
> Solution 1
> > and since, in the general case, every Rbridge has to look 
> at the VLAN
> > ID, putting it in a fixed place nearer the beginning of the 
> frame, as
> > done in Solution 2, seems like a good idea.
> 
> I agree in spirit, but don't agree that the inner frame should be
> modified during processing; this just complicates parsing and 
> debugging,
> and increases the potential for implementation errors.
> 
> IMO, the VLAN tags should be copied, not moved.
> 
> Joe
> 
> > Thanks,
> > Donald 
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Dinesh G Dutt
> > Sent: Monday, April 30, 2007 3:19 PM
> > To: Silvano Gai
> > Cc: [e-mail]
> > Subject: Re: [rbridge] TRILL Header Format
> > 
> > Two small corrections. In the second format, we really 
> don't need any 
> > indication of .1Q/.1S. The tag that is to be added at the 
> egress port 
> > maybe different from the tag that we received at the 
> ingress port and
> is
> > 
> > part of the port logic. For example, the frame may have 
> come in with a
> 
> > .1Q tag and may go out a port that accepts no tagging at all.
> > 
> > Given that we don't need to carry any indication of .1Q/.1S in the
> TRILL
> > 
> > header, I suggest that we also define the field "Inner 802.1Q/S tag"
> to 
> > be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator and
> call
> > 
> > it DE (drop eligibility). This way if RBridges along the way can
> choose 
> > to set the DE bit in the inner header, instead of treating it as an 
> > opaque field.
> > 
> > Dinesh
> > Silvano Gai wrote:
> >> The purpose of the following message is to converge on the final
> >> structure of the TRILL header.
> >>
> >> The format proposed in:
> >>
> >
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-p
> rotocol-03
> >> .txt
> >> has been stable for a while. This message only describes the
> >> differences.
> >>
> >> At the last IETF Donald proposed to support a single 
> extension header
> >> containing multiple extensions.
> >>
> >> After some discussion two solutions seem possible. Please express
> your
> >> preference by replying to this email.
> >>
> >> -- Silvano
> >>
> >>
> >> Solution 1
> >> ==========
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>                                       | V 
> |M|RSD|EH-length| Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> Where:
> >> - RSD (2 bits) is reserved
> >> - EH-Length (5 bits) is the extension header length, expressed in
> > units
> >> of in 4 bytes words.
> >>
> >> If EH-length is zero there is no extension header;
> >> else, the extensions follow immediately after the Egress Rbridge
> >> Nickname field, and the total length of all the extensions is as
> >> indicated by the EH-length field, expressed in units of 
> 4-byte words.
> >>
> >> This solution allows 128 bytes of extensions.
> >>
> >>
> >> Solution 2
> >> ==========
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>                                       |  V  |M|S| RSD |   Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |    RSD        |   EH-length   |  Inner IEEE 802.1Q/S tag
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and
> Priority)
> >> into the TRILL header. The Inner 1Q/1S tag is no longer present in
> the
> >> inner frame.
> >>
> >> This simplifies the parsing for the core RBridges. On the 
> other hand
> > the
> >> Ingress/Egress Rbridges need to do slightly more work. 
> >>
> >> This has more reserved space. Since the inner 1Q/1S tag is removed
> > from
> >> the frame (4 bytes), it uses the same overall space of solution 1.
> >>
> >> The S bit indicates if the inner header was 1Q (S=0) or 1S (S=1).
> >>
> >> The EH-length is 8 bits, with a granularity of 2 bytes it allows up
> to
> >> 512 bytes of extensions.
> >>
> >> The Hop Count can grow to 8 bits.
> >>
> >>
> >> A word of caution
> >> =================
> >>
> >> Extensions are very appealing, but their practical deployment has
> been
> >> very limited. Often Router and Switches are not able to 
> process in HW
> >> frames with extensions and they send them to SW.
> >>
> >>
> >> Example with Solution 1
> >> ======================= 
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |               Outer Destination MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Outer Destination MAC Address | Outer Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                   Outer Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = TRILL             | V 
> |M|RSD|EH-length| Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |               Inner Destination MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Inner Destination MAC Address | InnerSource MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                    Inner Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Inner VID
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |
> > | 
> >>       |                 Original Ethernet Payload
> > | 
> >>       |
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                           New FCS
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>              TRILL Encapsulation over Ethernet with Solution 1
> >>
> >>
> >>
> >>
> >> Example with Solution 2
> >> =======================
> >>
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |               Outer Destination MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Outer Destination MAC Address | Outer Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                   Outer Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Ethertype = TRILL             |  V  |M|S| RSD |   Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |    RSD        |   EH-length   |  UP |C|    Inner VID
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |               Inner Destination MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       | Inner Destination MAC Address | InnerSource MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                    Inner Source MAC Address
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |
> > | 
> >>       |                 Original Ethernet Payload
> > | 
> >>       |
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>       |                           New FCS
> > | 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >>                TRILL Encapsulation over Ethernet with Solution 2
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> rbridge mailing list
> >> [e-mail]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>
> >>   
> > 
> 
> -- 
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment
> 
> 
> _______________________________________________
> 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 l424Q2MR007916 for <[e-mail]>; Tue, 1 May 2007 21:26:02 -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, 01 May 2007 21:25:48 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.19.125]) 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, 01 May 2007 21:25:48 -0700 (PDT)
Date: Tue, 01 May 2007 21:26:16 -0700
From: Radia Perlman <[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
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Optional configuration of RBridge nickname
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, 02 May 2007 04:26:28 -0000
Status: RO
Content-Length: 1610

Someone suggested that it would be useful to allow configuration of 
nicknames, so
that nicknames can be more stable, and there would be no worry of an 
RBridge coming
up and usurping a nickname from someone else. I'd like:
a) for it to remain possible to be zero configuration (as in, not 
necessary to configure
a nickname
b) allow a mixture of configured and unconfigured nicknames
c) work even with misconfiguration (configuring two RBridges with the 
same nickname)
d) never allow an unconfigured nickname to accidentally usurp a nickname 
from
a ocnfigured RBridge

So I'm proposing the following:

a) allow configuration of a nickname value
b) have a "priority" value for owning a nickname
that can also be configured, which I'd propose would be an 8-bit byte,
where only the bottom 7 bits can be configured
c) the 8th bit of the priority byte (the most significant bit) indicates 
whether
the nickname was configured or not
d) the default is priority=0 for RBridges that have not been configured with
a nickname value, and priority=128 (top bit 1, rest 0) for an RBridge that
has been configured with a nickname
e) other values of nickname priority might be useful. For instance, an 
RBridge
implementation might increment the nickname value after it's held the 
nickname
for some amount of time (say 10 minutes). Or someone might want to configure
some RBridges to have a more stable nickname (by giving them higher 
priority).
f) Basically, the (nickname priority | system ID) is like the DR 
priority in IS-IS,
where the DR election is based on (priority | system ID)

Anyone object to this?

Radia


Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l423srWd002423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 1 May 2007 20:54:53 -0700 (PDT)
Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net [71.106.84.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l423sc9Y013090; Tue, 1 May 2007 20:54:39 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 01 May 2007 20:54:21 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Eastlake III Donald-LDE008 <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig83EEBBDDCA35CB3660CF2FB9"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format - Version 2
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, 02 May 2007 03:54:58 -0000
Status: RO
Content-Length: 3617

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig83EEBBDDCA35CB3660CF2FB9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Eastlake III Donald-LDE008 wrote:
> Hi Caitlin,
>=20
> I just don't see how the separation you suggest could ultimately work.
> Rbridges are replacements for Bridges and have to be able to do a
> reasonable version of everything Bridges can do with VLANs, etc. So it
> has to be possible to configure Rbridges to synthesize the VLAN tag
> information on ingress of a native frame, etc.=20

Why would that not go in the innermost header? The expectation is that
the bridge closest to the host removes such tags, right? If so, then
this is a conventional bridge function that can be added to an rbridge,
but has nothing to do with the rbridge transit operation, and thus
belongs in the inner header, not the TRILL header.

Joe


> So, in any case, Rbridges
> have to be able to synthesize, transport, understand, possibly map, and=

> eventually expunge the VLAN tag information. So how can there be "clean=

> layer separation"? And, in fact, the two byte format of the VLAN tag
> information is exactly the same whether the two bytes of VLAN tag info
> are prefixed by a Q/S-tag Ethertype and inserted within the encapsulate=
d
> frame or carried in a two byte field of the TRILL Header.
>=20
> In fact, it is not clear to me how any IEEE device can get past the
> TRILL Header, because IEEE devices will not recognize the TRILL
> Ethertype. Thus, such devices will never even see the Q/S tag Ethertype=

> that might be inserted with the VLAN tag information into the
> encapsulated frame. So I just can't see any gain in wasting those two
> bytes on that Ethertype since it is not going to help any IEEE device.
> Why not make those bytes available for reserved bits and more relaxed
> field sizes in the TRILL Header as suggested in Solution 2?
>=20
> Thanks,
> Donald
>=20
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On=

> Behalf Of Caitlin Bestler
> Sent: Tuesday, May 01, 2007 5:26 PM
> To: Silvano Gai; [e-mail]
> Subject: Re: [rbridge] TRILL Header Format - Version 2
>=20
> [e-mail] wrote:
>> Included comments from Dinesh, Donald and Dino (swap egress
>> and ingress nicknames).
>>
>> Dino is for solution 1
>> Donald is for solution 2
>>
>=20
> I think keeping a clean layered separation between IEEE
> and IETF is valuable, and all ties should be broken by
> keeping IEEE defined headers intact and unmodified. I'm
> not convinced that extra reserved bits justifies breaking
> that clean layering.
>=20
>=20
>=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge

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


--------------enig83EEBBDDCA35CB3660CF2FB9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOAtuE5f5cImnZrsRAq5hAKCWdkvEJmkL2H2AGmG5EfYMQpcSPgCgo29U
LXKkeTgNylCk7yC0PVSnJog=
=whZM
-----END PGP SIGNATURE-----

--------------enig83EEBBDDCA35CB3660CF2FB9--



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l423klUt000751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 1 May 2007 20:46:47 -0700 (PDT)
Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net [71.106.84.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l423kPdo011693; Tue, 1 May 2007 20:46:26 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 01 May 2007 20:46:08 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Eastlake III Donald-LDE008 <[e-mail]>
References: <[e-mail]>	<461ED550.9080501@isi.!edu>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<4626E9D3.7090502@is!!	! i.e	du><34BDD2A	[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]> <[e-mail]! ! .com> <	[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFBFA3D6310DB756933103A2C"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format
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, 02 May 2007 03:46:59 -0000
Status: RO
Content-Length: 12021

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFBFA3D6310DB756933103A2C
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Eastlake III Donald-LDE008 wrote:
> Hi Joe,
>=20
> I see it as exactly the other way.
>=20
> Most commonly, the VLAN ID is associated with a native frame only
> because of the port it is received on, although it is certainly possibl=
e
> for an end station to include one. Thus, in the most common case, it is=

> the current design which requires the ingress Rbridge to insert a Q/S
> tag inside the encapsulated frame, thus modifying it, and similarly mos=
t
> commonly requires the egress Rbridge to remove that tag from inside the=

> encapsulated frame, although their can be configurations where it is
> retained.
>=20
> Thus, Solution 2 would generally require *less* modification of
> encapsulated frames at ingress and egress than would Solution 1.

Agreed - IF the VLAN tag is something we insert/delete, then agreed.
That presumes that the ingress rbridge is the receive port that adds the
VLAN tag.

However, I read the previous posts as "extract the VLAN from the inner
header and put it in the TRILL header. That would assume some other
bridge had inserted the VLAN tag. If that's the case, then I don't see
the utility in moving things around.

> The above is in answer to your point on 'modification' since I believe
> Solution 2 results in less modification. I'm not sure I understand your=

> "parsing and debugging" point. For every Rbridge other than the ingress=

> Rbridge, for every frame the Rbridge has to (a) find the TRILL Header
> and (b) find the VLAN tag. It seems to me to make the parsing job
> simpler to put the VLAN tag information at a fixed location in the TRIL=
L
> Header.

It's in a fixed location if it's in the inner header too, however if it
truly belongs to the inner header, regardless of whether we act on it in
conjunction with TRILL information, it ought to stay in the inner
header. Otherwise debugging equipment will show a false inner header
that lacks the VLAN tag it owns.

Joe

>=20
> Donald
>=20
> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]=20
> Sent: Tuesday, May 01, 2007 5:33 PM
> To: Eastlake III Donald-LDE008
> Cc: Dinesh G Dutt; Silvano Gai; [e-mail]
> Subject: Re: [rbridge] TRILL Header Format
>=20
> Eastlake III Donald-LDE008 wrote:
>> Hi,
>>
>> I agree with Dinesh's comment and would also like to say that my
>> personal preference is for Solution 2. I just don't feel there are
>> enough reserved bit available for future use in the minimal Solution 1=

>> and since, in the general case, every Rbridge has to look at the VLAN
>> ID, putting it in a fixed place nearer the beginning of the frame, as
>> done in Solution 2, seems like a good idea.
>=20
> I agree in spirit, but don't agree that the inner frame should be
> modified during processing; this just complicates parsing and debugging=
,
> and increases the potential for implementation errors.
>=20
> IMO, the VLAN tags should be copied, not moved.
>=20
> Joe
>=20
>> Thanks,
>> Donald=20
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
> On
>> Behalf Of Dinesh G Dutt
>> Sent: Monday, April 30, 2007 3:19 PM
>> To: Silvano Gai
>> Cc: [e-mail]
>> Subject: Re: [rbridge] TRILL Header Format
>>
>> Two small corrections. In the second format, we really don't need any =

>> indication of .1Q/.1S. The tag that is to be added at the egress port =

>> maybe different from the tag that we received at the ingress port and
> is
>> part of the port logic. For example, the frame may have come in with a=

>=20
>> .1Q tag and may go out a port that accepts no tagging at all.
>>
>> Given that we don't need to carry any indication of .1Q/.1S in the
> TRILL
>> header, I suggest that we also define the field "Inner 802.1Q/S tag"
> to=20
>> be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator and
> call
>> it DE (drop eligibility). This way if RBridges along the way can
> choose=20
>> to set the DE bit in the inner header, instead of treating it as an=20
>> opaque field.
>>
>> Dinesh
>> Silvano Gai wrote:
>>> The purpose of the following message is to converge on the final
>>> structure of the TRILL header.
>>>
>>> The format proposed in:
>>>
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-0=
3
>>> .txt
>>> has been stable for a while. This message only describes the
>>> differences.
>>>
>>> At the last IETF Donald proposed to support a single extension header=

>>> containing multiple extensions.
>>>
>>> After some discussion two solutions seem possible. Please express
> your
>>> preference by replying to this email.
>>>
>>> -- Silvano
>>>
>>>
>>> Solution 1
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>>
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>                                       | V |M|RSD|EH-length| Hop Count=

>> |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> Where:
>>> - RSD (2 bits) is reserved
>>> - EH-Length (5 bits) is the extension header length, expressed in
>> units
>>> of in 4 bytes words.
>>>
>>> If EH-length is zero there is no extension header;
>>> else, the extensions follow immediately after the Egress Rbridge
>>> Nickname field, and the total length of all the extensions is as
>>> indicated by the EH-length field, expressed in units of 4-byte words.=

>>>
>>> This solution allows 128 bytes of extensions.
>>>
>>>
>>> Solution 2
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>>
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>                                       |  V  |M|S| RSD |   Hop Count
>> |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       |    RSD        |   EH-length   |  Inner IEEE 802.1Q/S tag
>> |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
>> |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and
> Priority)
>>> into the TRILL header. The Inner 1Q/1S tag is no longer present in
> the
>>> inner frame.
>>>
>>> This simplifies the parsing for the core RBridges. On the other hand
>> the
>>> Ingress/Egress Rbridges need to do slightly more work.=20
>>>
>>> This has more reserved space. Since the inner 1Q/1S tag is removed
>> from
>>> the frame (4 bytes), it uses the same overall space of solution 1.
>>>
>>> The S bit indicates if the inner header was 1Q (S=3D0) or 1S (S=3D1).=

>>>
>>> The EH-length is 8 bits, with a granularity of 2 bytes it allows up
> to
>>> 512 bytes of extensions.
>>>
>>> The Hop Count can grow to 8 bits.
>>>
>>>
>>> A word of caution
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>> Extensions are very appealing, but their practical deployment has
> been
>>> very limited. Often Router and Switches are not able to process in HW=

>>> frames with extensions and they send them to SW.
>>>
>>>
>>> Example with Solution 1
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=20
>>>
>>>
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       |               Outer Destination MAC Address
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       | Outer Destination MAC Address | Outer Source MAC Address
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       |                   Outer Source MAC Address
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       | Ethertype =3D IEEE 802.1Q       | UP  |C|   Outer VID
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       | Ethertype =3D TRILL             | V |M|RSD|EH-length| Hop Cou=
nt
>> |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>       |               Inner Destination MAC Address
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       | Inner Destination MAC Address | InnerSource MAC Address
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       |                    Inner Source MAC Address
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       | Ethertype =3D IEEE 802.1Q       | UP  |C|   Inner VID
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       |
>> |=20
>>>       |                 Original Ethernet Payload
>> |=20
>>>       |
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       |                           New FCS
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>              TRILL Encapsulation over Ethernet with Solution 1
>>>
>>>
>>>
>>>
>>> Example with Solution 2
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

>>>
>>>
>>>
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       |               Outer Destination MAC Address
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       | Outer Destination MAC Address | Outer Source MAC Address
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       |                   Outer Source MAC Address
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       | Ethertype =3D IEEE 802.1Q       | UP  |C|   Outer VID
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       | Ethertype =3D TRILL             |  V  |M|S| RSD |   Hop Count=

>> |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       |    RSD        |   EH-length   |  UP |C|    Inner VID
>> |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
>> |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>       |               Inner Destination MAC Address
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       | Inner Destination MAC Address | InnerSource MAC Address
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       |                    Inner Source MAC Address
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       |
>> |=20
>>>       |                 Original Ethernet Payload
>> |=20
>>>       |
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>       |                           New FCS
>> |=20
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>>                TRILL Encapsulation over Ethernet with Solution 2
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>>  =20
>=20

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


--------------enigFBFA3D6310DB756933103A2C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGOAmAE5f5cImnZrsRAoA8AKC6c3ItzgtLD1lExf9y+BNg98rZiACg3J2a
bigG5tQJ86M0C5Zl14nVar8=
=zj5Z
-----END PGP SIGNATURE-----

--------------enigFBFA3D6310DB756933103A2C--



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 l4237RuT023394 for <[e-mail]>; Tue, 1 May 2007 20:07:27 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-8.tower-153.messagelabs.com!1178075245!1536141!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 32103 invoked from network); 2 May 2007 03:07:26 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-153.messagelabs.com with SMTP; 2 May 2007 03:07:26 -0000
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4237PVq026421 for <[e-mail]>; Tue, 1 May 2007 20:07:25 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l4237OWZ016715 for <[e-mail]>; Tue, 1 May 2007 22:07:25 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l4237O1I016700 for <[e-mail]>; Tue, 1 May 2007 22:07:24 -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: Tue, 1 May 2007 23:07:23 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header Format - Version 2
thread-index: AceCN5wruuaX6T3WSK29pQEeR2PdVAAdXODQACgoHDAAOtOJ4AAICWcAAFYPHuAAaHHwIAAwvwogAQg4W+AAC3i6EA==
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Caitlin Bestler" <[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 l4237RuT023394
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format - Version 2
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, 02 May 2007 03:08:04 -0000
Status: RO
Content-Length: 2155

Hi Caitlin,

I just don't see how the separation you suggest could ultimately work.
Rbridges are replacements for Bridges and have to be able to do a
reasonable version of everything Bridges can do with VLANs, etc. So it
has to be possible to configure Rbridges to synthesize the VLAN tag
information on ingress of a native frame, etc. So, in any case, Rbridges
have to be able to synthesize, transport, understand, possibly map, and
eventually expunge the VLAN tag information. So how can there be "clean
layer separation"? And, in fact, the two byte format of the VLAN tag
information is exactly the same whether the two bytes of VLAN tag info
are prefixed by a Q/S-tag Ethertype and inserted within the encapsulated
frame or carried in a two byte field of the TRILL Header.

In fact, it is not clear to me how any IEEE device can get past the
TRILL Header, because IEEE devices will not recognize the TRILL
Ethertype. Thus, such devices will never even see the Q/S tag Ethertype
that might be inserted with the VLAN tag information into the
encapsulated frame. So I just can't see any gain in wasting those two
bytes on that Ethertype since it is not going to help any IEEE device.
Why not make those bytes available for reserved bits and more relaxed
field sizes in the TRILL Header as suggested in Solution 2?

Thanks,
Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Caitlin Bestler
Sent: Tuesday, May 01, 2007 5:26 PM
To: Silvano Gai; [e-mail]
Subject: Re: [rbridge] TRILL Header Format - Version 2

[e-mail] wrote:
> Included comments from Dinesh, Donald and Dino (swap egress
> and ingress nicknames).
> 
> Dino is for solution 1
> Donald is for solution 2
> 

I think keeping a clean layered separation between IEEE
and IETF is valuable, and all ties should be broken by
keeping IEEE defined headers intact and unmodified. I'm
not convinced that extra reserved bits justifies breaking
that clean layering.



_______________________________________________
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 l422gqFu017860 for <[e-mail]>; Tue, 1 May 2007 19:42:52 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-9.tower-128.messagelabs.com!1178073771!11490056!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 12069 invoked from network); 2 May 2007 02:42:51 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with SMTP; 2 May 2007 02:42:51 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l422gl1h022921 for <[e-mail]>; Tue, 1 May 2007 19:42:51 -0700 (MST)
Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l422gkHo029205 for <[e-mail]>; Tue, 1 May 2007 21:42:46 -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 l422gkJX029192 for <[e-mail]>; Tue, 1 May 2007 21:42:46 -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: Tue, 1 May 2007 22:42:44 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header Format
thread-index: AceMOFmd34CG6+gpShO0FWctc8TnBwAJ/CIg
References: <[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]><461ED550.9080501@isi.!edu>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<4626E9D3.7090502@is!!	! i.e	du><34BDD2A	[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]> <[e-mail]! .com> < [e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Joe Touch" <[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 l422gqFu017860
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format
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, 02 May 2007 02:42:56 -0000
Status: RO
Content-Length: 9882

Hi Joe,

I see it as exactly the other way.

Most commonly, the VLAN ID is associated with a native frame only
because of the port it is received on, although it is certainly possible
for an end station to include one. Thus, in the most common case, it is
the current design which requires the ingress Rbridge to insert a Q/S
tag inside the encapsulated frame, thus modifying it, and similarly most
commonly requires the egress Rbridge to remove that tag from inside the
encapsulated frame, although their can be configurations where it is
retained.

Thus, Solution 2 would generally require *less* modification of
encapsulated frames at ingress and egress than would Solution 1.

The above is in answer to your point on 'modification' since I believe
Solution 2 results in less modification. I'm not sure I understand your
"parsing and debugging" point. For every Rbridge other than the ingress
Rbridge, for every frame the Rbridge has to (a) find the TRILL Header
and (b) find the VLAN tag. It seems to me to make the parsing job
simpler to put the VLAN tag information at a fixed location in the TRILL
Header.

Donald

-----Original Message-----
From: Joe Touch [mailto:[e-mail]] 
Sent: Tuesday, May 01, 2007 5:33 PM
To: Eastlake III Donald-LDE008
Cc: Dinesh G Dutt; Silvano Gai; [e-mail]
Subject: Re: [rbridge] TRILL Header Format

Eastlake III Donald-LDE008 wrote:
> Hi,
> 
> I agree with Dinesh's comment and would also like to say that my
> personal preference is for Solution 2. I just don't feel there are
> enough reserved bit available for future use in the minimal Solution 1
> and since, in the general case, every Rbridge has to look at the VLAN
> ID, putting it in a fixed place nearer the beginning of the frame, as
> done in Solution 2, seems like a good idea.

I agree in spirit, but don't agree that the inner frame should be
modified during processing; this just complicates parsing and debugging,
and increases the potential for implementation errors.

IMO, the VLAN tags should be copied, not moved.

Joe

> Thanks,
> Donald 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Dinesh G Dutt
> Sent: Monday, April 30, 2007 3:19 PM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: Re: [rbridge] TRILL Header Format
> 
> Two small corrections. In the second format, we really don't need any 
> indication of .1Q/.1S. The tag that is to be added at the egress port 
> maybe different from the tag that we received at the ingress port and
is
> 
> part of the port logic. For example, the frame may have come in with a

> .1Q tag and may go out a port that accepts no tagging at all.
> 
> Given that we don't need to carry any indication of .1Q/.1S in the
TRILL
> 
> header, I suggest that we also define the field "Inner 802.1Q/S tag"
to 
> be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator and
call
> 
> it DE (drop eligibility). This way if RBridges along the way can
choose 
> to set the DE bit in the inner header, instead of treating it as an 
> opaque field.
> 
> Dinesh
> Silvano Gai wrote:
>> The purpose of the following message is to converge on the final
>> structure of the TRILL header.
>>
>> The format proposed in:
>>
>
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03
>> .txt
>> has been stable for a while. This message only describes the
>> differences.
>>
>> At the last IETF Donald proposed to support a single extension header
>> containing multiple extensions.
>>
>> After some discussion two solutions seem possible. Please express
your
>> preference by replying to this email.
>>
>> -- Silvano
>>
>>
>> Solution 1
>> ==========
>>
>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>                                       | V |M|RSD|EH-length| Hop Count
> |
>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> Where:
>> - RSD (2 bits) is reserved
>> - EH-Length (5 bits) is the extension header length, expressed in
> units
>> of in 4 bytes words.
>>
>> If EH-length is zero there is no extension header;
>> else, the extensions follow immediately after the Egress Rbridge
>> Nickname field, and the total length of all the extensions is as
>> indicated by the EH-length field, expressed in units of 4-byte words.
>>
>> This solution allows 128 bytes of extensions.
>>
>>
>> Solution 2
>> ==========
>>
>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>                                       |  V  |M|S| RSD |   Hop Count
> |
>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       |    RSD        |   EH-length   |  Inner IEEE 802.1Q/S tag
> |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and
Priority)
>> into the TRILL header. The Inner 1Q/1S tag is no longer present in
the
>> inner frame.
>>
>> This simplifies the parsing for the core RBridges. On the other hand
> the
>> Ingress/Egress Rbridges need to do slightly more work. 
>>
>> This has more reserved space. Since the inner 1Q/1S tag is removed
> from
>> the frame (4 bytes), it uses the same overall space of solution 1.
>>
>> The S bit indicates if the inner header was 1Q (S=0) or 1S (S=1).
>>
>> The EH-length is 8 bits, with a granularity of 2 bytes it allows up
to
>> 512 bytes of extensions.
>>
>> The Hop Count can grow to 8 bits.
>>
>>
>> A word of caution
>> =================
>>
>> Extensions are very appealing, but their practical deployment has
been
>> very limited. Often Router and Switches are not able to process in HW
>> frames with extensions and they send them to SW.
>>
>>
>> Example with Solution 1
>> ======================= 
>>
>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       |               Outer Destination MAC Address
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       | Outer Destination MAC Address | Outer Source MAC Address
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       |                   Outer Source MAC Address
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       | Ethertype = TRILL             | V |M|RSD|EH-length| Hop Count
> |
>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |               Inner Destination MAC Address
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       | Inner Destination MAC Address | InnerSource MAC Address
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       |                    Inner Source MAC Address
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       | Ethertype = IEEE 802.1Q       | UP  |C|   Inner VID
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       |
> | 
>>       |                 Original Ethernet Payload
> | 
>>       |
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       |                           New FCS
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>              TRILL Encapsulation over Ethernet with Solution 1
>>
>>
>>
>>
>> Example with Solution 2
>> =======================
>>
>>
>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       |               Outer Destination MAC Address
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       | Outer Destination MAC Address | Outer Source MAC Address
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       |                   Outer Source MAC Address
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       | Ethertype = TRILL             |  V  |M|S| RSD |   Hop Count
> |
>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       |    RSD        |   EH-length   |  UP |C|    Inner VID
> |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |               Inner Destination MAC Address
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       | Inner Destination MAC Address | InnerSource MAC Address
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       |                    Inner Source MAC Address
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       |
> | 
>>       |                 Original Ethernet Payload
> | 
>>       |
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>       |                           New FCS
> | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>                TRILL Encapsulation over Ethernet with Solution 2
>>
>>
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>   
> 

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




Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l41Lhtmn014146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 1 May 2007 14:43:56 -0700 (PDT)
Received: from [127.0.0.1] (176.sub-75-214-128.myvzw.com [75.214.128.176]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l41Lh55U002411; Tue, 1 May 2007 14:43:08 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 01 May 2007 14:42:49 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[e-mail]>	<461ED550.9080501@isi.!edu>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<4626E9D3.7090502@is!!	! i.e	du><34BDD2A	[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]> <[e-mail]! ! .com> <	[e-mail]> <[e-mail].! com>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE2446C804EB53FCE485BD2C8"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format
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, 01 May 2007 21:44:19 -0000
Status: RO
Content-Length: 10547

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE2446C804EB53FCE485BD2C8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Silvano Gai wrote:
> Joe,
>=20
> In this case you have option 1,
> The VLAN-ID is located at an easily computable offset from the TRILL
> header

Agreed. I'm not as concerned with the need for extra space as others; we
have a version field, which ought to cover future expansion if needed
anyway.

Joe

>=20
> -- Silvano
>=20
>> -----Original Message-----
>> From: Joe Touch [mailto:[e-mail]]
>> Sent: Tuesday, May 01, 2007 2:33 PM
>> To: Eastlake III Donald-LDE008
>> Cc: Dinesh G Dutt; Silvano Gai; [e-mail]
>> Subject: Re: [rbridge] TRILL Header Format
>>
>>
>>
>> Eastlake III Donald-LDE008 wrote:
>>> Hi,
>>>
>>> I agree with Dinesh's comment and would also like to say that my
>>> personal preference is for Solution 2. I just don't feel there are
>>> enough reserved bit available for future use in the minimal Solution
> 1
>>> and since, in the general case, every Rbridge has to look at the
> VLAN
>>> ID, putting it in a fixed place nearer the beginning of the frame,
> as
>>> done in Solution 2, seems like a good idea.
>> I agree in spirit, but don't agree that the inner frame should be
>> modified during processing; this just complicates parsing and
> debugging,
>> and increases the potential for implementation errors.
>>
>> IMO, the VLAN tags should be copied, not moved.
>>
>> Joe
>>
>>> Thanks,
>>> Donald
>>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]
> On
>>> Behalf Of Dinesh G Dutt
>>> Sent: Monday, April 30, 2007 3:19 PM
>>> To: Silvano Gai
>>> Cc: [e-mail]
>>> Subject: Re: [rbridge] TRILL Header Format
>>>
>>> Two small corrections. In the second format, we really don't need
> any
>>> indication of .1Q/.1S. The tag that is to be added at the egress
> port
>>> maybe different from the tag that we received at the ingress port
> and is
>>> part of the port logic. For example, the frame may have come in with
> a
>>> .1Q tag and may go out a port that accepts no tagging at all.
>>>
>>> Given that we don't need to carry any indication of .1Q/.1S in the
> TRILL
>>> header, I suggest that we also define the field "Inner 802.1Q/S tag"
> to
>>> be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator and
> call
>>> it DE (drop eligibility). This way if RBridges along the way can
> choose
>>> to set the DE bit in the inner header, instead of treating it as an
>>> opaque field.
>>>
>>> Dinesh
>>> Silvano Gai wrote:
>>>> The purpose of the following message is to converge on the final
>>>> structure of the TRILL header.
>>>>
>>>> The format proposed in:
>>>>
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-0=
3
>>>> .txt
>>>> has been stable for a while. This message only describes the
>>>> differences.
>>>>
>>>> At the last IETF Donald proposed to support a single extension
> header
>>>> containing multiple extensions.
>>>>
>>>> After some discussion two solutions seem possible. Please express
> your
>>>> preference by replying to this email.
>>>>
>>>> -- Silvano
>>>>
>>>>
>>>> Solution 1
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>
>>>>
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>                                       | V |M|RSD|EH-length| Hop
> Count
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>> Where:
>>>> - RSD (2 bits) is reserved
>>>> - EH-Length (5 bits) is the extension header length, expressed in
>>> units
>>>> of in 4 bytes words.
>>>>
>>>> If EH-length is zero there is no extension header;
>>>> else, the extensions follow immediately after the Egress Rbridge
>>>> Nickname field, and the total length of all the extensions is as
>>>> indicated by the EH-length field, expressed in units of 4-byte
> words.
>>>> This solution allows 128 bytes of extensions.
>>>>
>>>>
>>>> Solution 2
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>
>>>>
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>                                       |  V  |M|S| RSD |   Hop Count
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |    RSD        |   EH-length   |  Inner IEEE 802.1Q/S tag
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>> This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and
> Priority)
>>>> into the TRILL header. The Inner 1Q/1S tag is no longer present in
> the
>>>> inner frame.
>>>>
>>>> This simplifies the parsing for the core RBridges. On the other
> hand
>>> the
>>>> Ingress/Egress Rbridges need to do slightly more work.
>>>>
>>>> This has more reserved space. Since the inner 1Q/1S tag is removed
>>> from
>>>> the frame (4 bytes), it uses the same overall space of solution 1.
>>>>
>>>> The S bit indicates if the inner header was 1Q (S=3D0) or 1S (S=3D1)=
=2E
>>>>
>>>> The EH-length is 8 bits, with a granularity of 2 bytes it allows up
> to
>>>> 512 bytes of extensions.
>>>>
>>>> The Hop Count can grow to 8 bits.
>>>>
>>>>
>>>> A word of caution
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>
>>>> Extensions are very appealing, but their practical deployment has
> been
>>>> very limited. Often Router and Switches are not able to process in
> HW
>>>> frames with extensions and they send them to SW.
>>>>
>>>>
>>>> Example with Solution 1
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

>>>>
>>>>
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |               Outer Destination MAC Address
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       | Outer Destination MAC Address | Outer Source MAC Address
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |                   Outer Source MAC Address
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       | Ethertype =3D IEEE 802.1Q       | UP  |C|   Outer VID
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       | Ethertype =3D TRILL             | V |M|RSD|EH-length| Hop
> Count
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |               Inner Destination MAC Address
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       | Inner Destination MAC Address | InnerSource MAC Address
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |                    Inner Source MAC Address
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       | Ethertype =3D IEEE 802.1Q       | UP  |C|   Inner VID
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |
>>> |
>>>>       |                 Original Ethernet Payload
>>> |
>>>>       |
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |                           New FCS
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>              TRILL Encapsulation over Ethernet with Solution 1
>>>>
>>>>
>>>>
>>>>
>>>> Example with Solution 2
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

>>>>
>>>>
>>>>
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |               Outer Destination MAC Address
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       | Outer Destination MAC Address | Outer Source MAC Address
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |                   Outer Source MAC Address
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       | Ethertype =3D IEEE 802.1Q       | UP  |C|   Outer VID
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       | Ethertype =3D TRILL             |  V  |M|S| RSD |   Hop Coun=
t
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |    RSD        |   EH-length   |  UP |C|    Inner VID
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |               Inner Destination MAC Address
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       | Inner Destination MAC Address | InnerSource MAC Address
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |                    Inner Source MAC Address
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |
>>> |
>>>>       |                 Original Ethernet Payload
>>> |
>>>>       |
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>       |                           New FCS
>>> |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>                TRILL Encapsulation over Ethernet with Solution 2
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> [e-mail]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>
>>>>
>> --
>> ----------------------------------------
>> Joe Touch
>> Sr. Network Engineer, USAF TSAT Space Segment
>=20

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


--------------enigE2446C804EB53FCE485BD2C8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGN7RZE5f5cImnZrsRAtbIAKDJP4itOXlkn3RlSCc7uZytwxx5RwCfX7oU
RHiDzWSBW1WA2b9LFpHdn24=
=2ZMj
-----END PGP SIGNATURE-----

--------------enigE2446C804EB53FCE485BD2C8--



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 l41Lanpc012642 for <[e-mail]>; Tue, 1 May 2007 14:36: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: Tue, 1 May 2007 14:36:45 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header Format
Thread-Index: AceMOGZinB/cTjCTT1qtHhqnlbnZVQAAETWQ
References: <[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]><461ED550.9080501@isi.!edu>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<4626E9D3.7090502@is!!	! i.e	du><34BDD2A	[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]> <[e-mail]! .com> < [e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Joe Touch" <[e-mail]>, "Eastlake III Donald-LDE008" <[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 l41Lanpc012642
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format
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, 01 May 2007 21:37:19 -0000
Status: RO
Content-Length: 9330

Joe,

In this case you have option 1,
The VLAN-ID is located at an easily computable offset from the TRILL
header

-- Silvano

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Tuesday, May 01, 2007 2:33 PM
> To: Eastlake III Donald-LDE008
> Cc: Dinesh G Dutt; Silvano Gai; [e-mail]
> Subject: Re: [rbridge] TRILL Header Format
> 
> 
> 
> Eastlake III Donald-LDE008 wrote:
> > Hi,
> >
> > I agree with Dinesh's comment and would also like to say that my
> > personal preference is for Solution 2. I just don't feel there are
> > enough reserved bit available for future use in the minimal Solution
1
> > and since, in the general case, every Rbridge has to look at the
VLAN
> > ID, putting it in a fixed place nearer the beginning of the frame,
as
> > done in Solution 2, seems like a good idea.
> 
> I agree in spirit, but don't agree that the inner frame should be
> modified during processing; this just complicates parsing and
debugging,
> and increases the potential for implementation errors.
> 
> IMO, the VLAN tags should be copied, not moved.
> 
> Joe
> 
> > Thanks,
> > Donald
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
On
> > Behalf Of Dinesh G Dutt
> > Sent: Monday, April 30, 2007 3:19 PM
> > To: Silvano Gai
> > Cc: [e-mail]
> > Subject: Re: [rbridge] TRILL Header Format
> >
> > Two small corrections. In the second format, we really don't need
any
> > indication of .1Q/.1S. The tag that is to be added at the egress
port
> > maybe different from the tag that we received at the ingress port
and is
> >
> > part of the port logic. For example, the frame may have come in with
a
> > .1Q tag and may go out a port that accepts no tagging at all.
> >
> > Given that we don't need to carry any indication of .1Q/.1S in the
TRILL
> >
> > header, I suggest that we also define the field "Inner 802.1Q/S tag"
to
> > be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator and
call
> >
> > it DE (drop eligibility). This way if RBridges along the way can
choose
> > to set the DE bit in the inner header, instead of treating it as an
> > opaque field.
> >
> > Dinesh
> > Silvano Gai wrote:
> >> The purpose of the following message is to converge on the final
> >> structure of the TRILL header.
> >>
> >> The format proposed in:
> >>
> >
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03
> >> .txt
> >> has been stable for a while. This message only describes the
> >> differences.
> >>
> >> At the last IETF Donald proposed to support a single extension
header
> >> containing multiple extensions.
> >>
> >> After some discussion two solutions seem possible. Please express
your
> >> preference by replying to this email.
> >>
> >> -- Silvano
> >>
> >>
> >> Solution 1
> >> ==========
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>                                       | V |M|RSD|EH-length| Hop
Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> Where:
> >> - RSD (2 bits) is reserved
> >> - EH-Length (5 bits) is the extension header length, expressed in
> > units
> >> of in 4 bytes words.
> >>
> >> If EH-length is zero there is no extension header;
> >> else, the extensions follow immediately after the Egress Rbridge
> >> Nickname field, and the total length of all the extensions is as
> >> indicated by the EH-length field, expressed in units of 4-byte
words.
> >>
> >> This solution allows 128 bytes of extensions.
> >>
> >>
> >> Solution 2
> >> ==========
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>                                       |  V  |M|S| RSD |   Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |    RSD        |   EH-length   |  Inner IEEE 802.1Q/S tag
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and
Priority)
> >> into the TRILL header. The Inner 1Q/1S tag is no longer present in
the
> >> inner frame.
> >>
> >> This simplifies the parsing for the core RBridges. On the other
hand
> > the
> >> Ingress/Egress Rbridges need to do slightly more work.
> >>
> >> This has more reserved space. Since the inner 1Q/1S tag is removed
> > from
> >> the frame (4 bytes), it uses the same overall space of solution 1.
> >>
> >> The S bit indicates if the inner header was 1Q (S=0) or 1S (S=1).
> >>
> >> The EH-length is 8 bits, with a granularity of 2 bytes it allows up
to
> >> 512 bytes of extensions.
> >>
> >> The Hop Count can grow to 8 bits.
> >>
> >>
> >> A word of caution
> >> =================
> >>
> >> Extensions are very appealing, but their practical deployment has
been
> >> very limited. Often Router and Switches are not able to process in
HW
> >> frames with extensions and they send them to SW.
> >>
> >>
> >> Example with Solution 1
> >> =======================
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |               Outer Destination MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       | Outer Destination MAC Address | Outer Source MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |                   Outer Source MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       | Ethertype = TRILL             | V |M|RSD|EH-length| Hop
Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |               Inner Destination MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       | Inner Destination MAC Address | InnerSource MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |                    Inner Source MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Inner VID
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |
> > |
> >>       |                 Original Ethernet Payload
> > |
> >>       |
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |                           New FCS
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>              TRILL Encapsulation over Ethernet with Solution 1
> >>
> >>
> >>
> >>
> >> Example with Solution 2
> >> =======================
> >>
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |               Outer Destination MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       | Outer Destination MAC Address | Outer Source MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |                   Outer Source MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       | Ethertype = TRILL             |  V  |M|S| RSD |   Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |    RSD        |   EH-length   |  UP |C|    Inner VID
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |               Inner Destination MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       | Inner Destination MAC Address | InnerSource MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |                    Inner Source MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |
> > |
> >>       |                 Original Ethernet Payload
> > |
> >>       |
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>       |                           New FCS
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>                TRILL Encapsulation over Ethernet with Solution 2
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> rbridge mailing list
> >> [e-mail]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>
> >>
> >
> 
> --
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment




Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l41LXKOX011754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 1 May 2007 14:33:20 -0700 (PDT)
Received: from [127.0.0.1] (176.sub-75-214-128.myvzw.com [75.214.128.176]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l41LWugD000350; Tue, 1 May 2007 14:32:59 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 01 May 2007 14:32:38 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Eastlake III Donald-LDE008 <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]><461ED550.9080501@isi.!edu>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<4626E9D3.7090502@is!!	! i.e	du><34BDD2A	[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]> <[e-mail]! .com>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig143DD63A33CCAB7D677BF8C0"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format
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, 01 May 2007 21:33:59 -0000
Status: RO
Content-Length: 9587

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig143DD63A33CCAB7D677BF8C0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Eastlake III Donald-LDE008 wrote:
> Hi,
>=20
> I agree with Dinesh's comment and would also like to say that my
> personal preference is for Solution 2. I just don't feel there are
> enough reserved bit available for future use in the minimal Solution 1
> and since, in the general case, every Rbridge has to look at the VLAN
> ID, putting it in a fixed place nearer the beginning of the frame, as
> done in Solution 2, seems like a good idea.

I agree in spirit, but don't agree that the inner frame should be
modified during processing; this just complicates parsing and debugging,
and increases the potential for implementation errors.

IMO, the VLAN tags should be copied, not moved.

Joe

> Thanks,
> Donald=20
>=20
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On=

> Behalf Of Dinesh G Dutt
> Sent: Monday, April 30, 2007 3:19 PM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: Re: [rbridge] TRILL Header Format
>=20
> Two small corrections. In the second format, we really don't need any=20
> indication of .1Q/.1S. The tag that is to be added at the egress port=20
> maybe different from the tag that we received at the ingress port and i=
s
>=20
> part of the port logic. For example, the frame may have come in with a =

> .1Q tag and may go out a port that accepts no tagging at all.
>=20
> Given that we don't need to carry any indication of .1Q/.1S in the TRIL=
L
>=20
> header, I suggest that we also define the field "Inner 802.1Q/S tag" to=
=20
> be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator and cal=
l
>=20
> it DE (drop eligibility). This way if RBridges along the way can choose=
=20
> to set the DE bit in the inner header, instead of treating it as an=20
> opaque field.
>=20
> Dinesh
> Silvano Gai wrote:
>> The purpose of the following message is to converge on the final
>> structure of the TRILL header.
>>
>> The format proposed in:
>>
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-0=
3
>> .txt
>> has been stable for a while. This message only describes the
>> differences.
>>
>> At the last IETF Donald proposed to support a single extension header
>> containing multiple extensions.
>>
>> After some discussion two solutions seem possible. Please express your=

>> preference by replying to this email.
>>
>> -- Silvano
>>
>>
>> Solution 1
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>                                       | V |M|RSD|EH-length| Hop Count
> |
>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> Where:
>> - RSD (2 bits) is reserved
>> - EH-Length (5 bits) is the extension header length, expressed in
> units
>> of in 4 bytes words.
>>
>> If EH-length is zero there is no extension header;
>> else, the extensions follow immediately after the Egress Rbridge
>> Nickname field, and the total length of all the extensions is as
>> indicated by the EH-length field, expressed in units of 4-byte words.
>>
>> This solution allows 128 bytes of extensions.
>>
>>
>> Solution 2
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>                                       |  V  |M|S| RSD |   Hop Count
> |
>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       |    RSD        |   EH-length   |  Inner IEEE 802.1Q/S tag
> |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and Priority)=

>> into the TRILL header. The Inner 1Q/1S tag is no longer present in the=

>> inner frame.
>>
>> This simplifies the parsing for the core RBridges. On the other hand
> the
>> Ingress/Egress Rbridges need to do slightly more work.=20
>>
>> This has more reserved space. Since the inner 1Q/1S tag is removed
> from
>> the frame (4 bytes), it uses the same overall space of solution 1.
>>
>> The S bit indicates if the inner header was 1Q (S=3D0) or 1S (S=3D1).
>>
>> The EH-length is 8 bits, with a granularity of 2 bytes it allows up to=

>> 512 bytes of extensions.
>>
>> The Hop Count can grow to 8 bits.
>>
>>
>> A word of caution
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> Extensions are very appealing, but their practical deployment has been=

>> very limited. Often Router and Switches are not able to process in HW
>> frames with extensions and they send them to SW.
>>
>>
>> Example with Solution 1
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =

>>
>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       |               Outer Destination MAC Address
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       | Outer Destination MAC Address | Outer Source MAC Address
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       |                   Outer Source MAC Address
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       | Ethertype =3D IEEE 802.1Q       | UP  |C|   Outer VID
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       | Ethertype =3D TRILL             | V |M|RSD|EH-length| Hop Coun=
t
> |
>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |               Inner Destination MAC Address
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       | Inner Destination MAC Address | InnerSource MAC Address
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       |                    Inner Source MAC Address
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       | Ethertype =3D IEEE 802.1Q       | UP  |C|   Inner VID
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       |
> |=20
>>       |                 Original Ethernet Payload
> |=20
>>       |
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       |                           New FCS
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>              TRILL Encapsulation over Ethernet with Solution 1
>>
>>
>>
>>
>> Example with Solution 2
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>
>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       |               Outer Destination MAC Address
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       | Outer Destination MAC Address | Outer Source MAC Address
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       |                   Outer Source MAC Address
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       | Ethertype =3D IEEE 802.1Q       | UP  |C|   Outer VID
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       | Ethertype =3D TRILL             |  V  |M|S| RSD |   Hop Count
> |
>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       |    RSD        |   EH-length   |  UP |C|    Inner VID
> |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
> |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |               Inner Destination MAC Address
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       | Inner Destination MAC Address | InnerSource MAC Address
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       |                    Inner Source MAC Address
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       |
> |=20
>>       |                 Original Ethernet Payload
> |=20
>>       |
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>       |                           New FCS
> |=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>>                TRILL Encapsulation over Ethernet with Solution 2
>>
>>
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>  =20
>=20

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


--------------enig143DD63A33CCAB7D677BF8C0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGN7H2E5f5cImnZrsRAvrvAJ0aoouAvym/KxuQQaykv1umE8fRIACgyX6q
80MSU8L2to+BsbAqSnkVdU8=
=Tf85
-----END PGP SIGNATURE-----

--------------enig143DD63A33CCAB7D677BF8C0--



Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l41LQWEj010033 for <[e-mail]>; Tue, 1 May 2007 14:26:32 -0700 (PDT)
Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 01 May 2007 14:26:27 -0700
X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id D5F932AF; Tue, 1 May 2007 14:26:27 -0700 (PDT)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id BF9AA2AE; Tue, 1 May 2007 14:26:27 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FGL45017; Tue, 1 May 2007 14:26:21 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 7CA1269CB0; Tue, 1 May 2007 14:26:18 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 1 May 2007 14:25:54 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] TRILL Header Format - Version 2
Thread-Index: AceCN5wruuaX6T3WSK29pQEeR2PdVAAdXODQACgoHDAAOtOJ4AAICWcAAFYPHuAAaHHwIAAwvwogAQg4W+A=
From: "Caitlin Bestler" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, [e-mail]
X-WSS-ID: 6A296F0938G23962915-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l41LQWEj010033
Subject: Re: [rbridge] TRILL Header Format - Version 2
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, 01 May 2007 21:26:47 -0000
Status: RO
Content-Length: 430

[e-mail] wrote:
> Included comments from Dinesh, Donald and Dino (swap egress
> and ingress nicknames).
> 
> Dino is for solution 1
> Donald is for solution 2
> 

I think keeping a clean layered separation between IEEE
and IETF is valuable, and all ties should be broken by
keeping IEEE defined headers intact and unmodified. I'm
not convinced that extra reserved bits justifies breaking
that clean layering.





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 l41LEZdU006803 for <[e-mail]>; Tue, 1 May 2007 14:14:36 -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: Tue, 1 May 2007 14:14:32 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: TRILL Header Format - Version 2
Thread-Index: AceCN5wruuaX6T3WSK29pQEeR2PdVAAdXODQACgoHDAAOtOJ4AAICWcAAFYPHuAAaHHwIAAwvwog
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]> <461ED550.9080501@isi.! edu> <[e-mail]> <[e-mail]> <[e-mail]> <4626E9D3.7090502@is! ! ! i.e du> <34BDD2A [e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: <[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 l41LEZdU006803
Subject: [rbridge] TRILL Header Format - Version 2
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, 01 May 2007 21:14:50 -0000
Status: RO
Content-Length: 6543

Included comments from Dinesh, Donald and Dino (swap egress and ingress
nicknames).

Dino is for solution 1
Donald is for solution 2

No other preferences have been expressed

-- Silvano

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


Solution 1
==========

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                      | V |M|RSD|EH-length| Hop Count |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Egress RBridge Nickname      |  Ingress RBridge Nickname     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:
- RSD (2 bits) is reserved
- EH-Length (5 bits) is the extension header length, expressed in units
of in 4 bytes words.

If EH-length is zero there is no extension header;
else, the extensions follow immediately after the Egress Rbridge
Nickname field, and the total length of all the extensions is as
indicated by the EH-length field, expressed in units of 4-byte words.

This solution allows 128 bytes of extensions.


Solution 2
==========


                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                      |  V  |M|  RSD  |   Hop Count   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |    RSD        |   EH-length   |  Inner IEEE 802.1Q/S tag      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Egress RBridge Nickname      |  Ingress RBridge Nickname     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and Priority)
into the TRILL header. The Inner 1Q/1S tag is no longer present in the
inner frame.

This simplifies the parsing for the core RBridges. On the other hand the
Ingress/Egress Rbridges need to do slightly more work. 

This has more reserved space. Since the inner 1Q/1S tag is removed from
the frame (4 bytes), it uses the same overall space of solution 1.

The EH-length is 8 bits, with a granularity of 2 bytes it allows up to
512 bytes of extensions.

The Hop Count can grow to 8 bits.


A word of caution
=================

Extensions are very appealing, but their practical deployment has been
very limited. Often Router and Switches are not able to process in HW
frames with extensions and they send them to SW.


Example with Solution 1
======================= 

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |               Outer Destination MAC Address                   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Outer Destination MAC Address | Outer Source MAC Address      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                   Outer Source MAC Address                    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Ethertype = TRILL             | V |M|RSD|EH-length| Hop Count |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Egress RBridge Nickname      |  Ingress RBridge Nickname     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Inner Destination MAC Address                   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Inner Destination MAC Address | InnerSource MAC Address       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                    Inner Source MAC Address                   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Ethertype = IEEE 802.1Q       | UP  |C|   Inner VID           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      |                 Original Ethernet Payload                     | 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                           New FCS                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
             TRILL Encapsulation over Ethernet with Solution 1




Example with Solution 2
=======================


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Outer Destination MAC Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Outer Destination MAC Address | Outer Source MAC Address      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                   Outer Source MAC Address                    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Ethertype = TRILL             |  V  |M|  RSD  |   Hop Count   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |    RSD        |   EH-length   |  UP |DE|   Inner VID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Egress RBridge Nickname      |  Ingress RBridge Nickname     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Inner Destination MAC Address                   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Inner Destination MAC Address | InnerSource MAC Address       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                    Inner Source MAC Address                   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      |                 Original Ethernet Payload                     | 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                           New FCS                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
               TRILL Encapsulation over Ethernet with Solution 2






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 l41FmNXE018661 for <[e-mail]>; Tue, 1 May 2007 08:48:23 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-13.tower-119.messagelabs.com!1178034502!27386757!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 22538 invoked from network); 1 May 2007 15:48:22 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-119.messagelabs.com with SMTP; 1 May 2007 15:48:22 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l41FmInx017189 for <[e-mail]>; Tue, 1 May 2007 08:48:22 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l41FmHu7029565 for <[e-mail]>; Tue, 1 May 2007 10:48:17 -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 l41FmH4l029551 for <[e-mail]>; Tue, 1 May 2007 10:48:17 -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: Tue, 1 May 2007 11:48:14 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header Format
thread-index: AceLXt+8bNXzMRwJTcuN85aK0eyskAAqMjZw
References: <[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]><[e-mail]>	<[e-mail]><461ED550.9080501@isi.!edu>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<4626E9D3.7090502@is!! ! i.e du><34BDD2A	[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Dinesh G Dutt" <[e-mail]>, "Silvano Gai" <[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 l41FmNXE018661
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format
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, 01 May 2007 15:49:06 -0000
Status: RO
Content-Length: 8146

Hi,

I agree with Dinesh's comment and would also like to say that my
personal preference is for Solution 2. I just don't feel there are
enough reserved bit available for future use in the minimal Solution 1
and since, in the general case, every Rbridge has to look at the VLAN
ID, putting it in a fixed place nearer the beginning of the frame, as
done in Solution 2, seems like a good idea.

Thanks,
Donald 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Dinesh G Dutt
Sent: Monday, April 30, 2007 3:19 PM
To: Silvano Gai
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header Format

Two small corrections. In the second format, we really don't need any 
indication of .1Q/.1S. The tag that is to be added at the egress port 
maybe different from the tag that we received at the ingress port and is

part of the port logic. For example, the frame may have come in with a 
.1Q tag and may go out a port that accepts no tagging at all.

Given that we don't need to carry any indication of .1Q/.1S in the TRILL

header, I suggest that we also define the field "Inner 802.1Q/S tag" to 
be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator and call

it DE (drop eligibility). This way if RBridges along the way can choose 
to set the DE bit in the inner header, instead of treating it as an 
opaque field.

Dinesh
Silvano Gai wrote:
> The purpose of the following message is to converge on the final
> structure of the TRILL header.
>
> The format proposed in:
>
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03
> .txt
> has been stable for a while. This message only describes the
> differences.
>
> At the last IETF Donald proposed to support a single extension header
> containing multiple extensions.
>
> After some discussion two solutions seem possible. Please express your
> preference by replying to this email.
>
> -- Silvano
>
>
> Solution 1
> ==========
>
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>                                       | V |M|RSD|EH-length| Hop Count
|
>
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Where:
> - RSD (2 bits) is reserved
> - EH-Length (5 bits) is the extension header length, expressed in
units
> of in 4 bytes words.
>
> If EH-length is zero there is no extension header;
> else, the extensions follow immediately after the Egress Rbridge
> Nickname field, and the total length of all the extensions is as
> indicated by the EH-length field, expressed in units of 4-byte words.
>
> This solution allows 128 bytes of extensions.
>
>
> Solution 2
> ==========
>
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>                                       |  V  |M|S| RSD |   Hop Count
|
>
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |    RSD        |   EH-length   |  Inner IEEE 802.1Q/S tag
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and Priority)
> into the TRILL header. The Inner 1Q/1S tag is no longer present in the
> inner frame.
>
> This simplifies the parsing for the core RBridges. On the other hand
the
> Ingress/Egress Rbridges need to do slightly more work. 
>
> This has more reserved space. Since the inner 1Q/1S tag is removed
from
> the frame (4 bytes), it uses the same overall space of solution 1.
>
> The S bit indicates if the inner header was 1Q (S=0) or 1S (S=1).
>
> The EH-length is 8 bits, with a granularity of 2 bytes it allows up to
> 512 bytes of extensions.
>
> The Hop Count can grow to 8 bits.
>
>
> A word of caution
> =================
>
> Extensions are very appealing, but their practical deployment has been
> very limited. Often Router and Switches are not able to process in HW
> frames with extensions and they send them to SW.
>
>
> Example with Solution 1
> ======================= 
>
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |               Outer Destination MAC Address
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       | Outer Destination MAC Address | Outer Source MAC Address
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |                   Outer Source MAC Address
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       | Ethertype = TRILL             | V |M|RSD|EH-length| Hop Count
|
>
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |               Inner Destination MAC Address
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       | Inner Destination MAC Address | InnerSource MAC Address
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |                    Inner Source MAC Address
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       | Ethertype = IEEE 802.1Q       | UP  |C|   Inner VID
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |
| 
>       |                 Original Ethernet Payload
| 
>       |
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |                           New FCS
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>              TRILL Encapsulation over Ethernet with Solution 1
>
>
>
>
> Example with Solution 2
> =======================
>
>
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |               Outer Destination MAC Address
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       | Outer Destination MAC Address | Outer Source MAC Address
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |                   Outer Source MAC Address
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       | Ethertype = TRILL             |  V  |M|S| RSD |   Hop Count
|
>
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |    RSD        |   EH-length   |  UP |C|    Inner VID
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |  Ingress RBridge Nickname     |  Egress RBridge Nickname
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |               Inner Destination MAC Address
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       | Inner Destination MAC Address | InnerSource MAC Address
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |                    Inner Source MAC Address
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |
| 
>       |                 Original Ethernet Payload
| 
>       |
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |                           New FCS
| 
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>                TRILL Encapsulation over Ethernet with Solution 2
>
>
>
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan
_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge