Subject: [rbridge] Separating DRB election from encapsulator/decapsulator

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 31 Oct 2007 21:01:13 -0700

When trying to carefully write up all the rules with respect to RBridges 
and VLANs, it occurs
to me that one place in which things can be simplified is to separate 
the function of the DRB on
a layer 2 cloud from the selection of data packet 
encapsulator/decapsulator for each VLAN.

What I mean is that instead of having n different DRB elections with 
different priorities for
different, possibly overlapping sets of VLANs for that cloud, we instead 
have a single
DRB election for that cloud, and as a result, a single pseudonode
associated with the cloud that would be visible to
any RBridges not on the cloud. The DRB on a cloud has the following duties:

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

For now, does anyone see any problem with this? It's unfortunately a bit 
entwined with
the other hairy discussion going on, but I think that we're going to 
converge for that.

Radia

Date: Wed, 31 Oct 2007 21:01:13 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Separating DRB election from encapsulator/decapsulator
Status: RO
Content-Length: 1331

When trying to carefully write up all the rules with respect to RBridges 
and VLANs, it occurs
to me that one place in which things can be simplified is to separate 
the function of the DRB on
a layer 2 cloud from the selection of data packet 
encapsulator/decapsulator for each VLAN.

What I mean is that instead of having n different DRB elections with 
different priorities for
different, possibly overlapping sets of VLANs for that cloud, we instead 
have a single
DRB election for that cloud, and as a result, a single pseudonode
associated with the cloud that would be visible to
any RBridges not on the cloud. The DRB on a cloud has the following duties:

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

For now, does anyone see any problem with this? It's unfortunately a bit 
entwined with
the other hairy discussion going on, but I think that we're going to 
converge for that.

Radia

Content-class: urn:content-classes:message
Date: Wed, 31 Oct 2007 21:07:09 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] TRILL meeting in Vancouver
Status: RO
Content-Length: 912

We have succeeded in having the TRILL meeting in Vancouver moved to
Tuesday morning (at least for now).

Donald

Eastlake III Donald-LDE008 wrote:
> A draft agenda for the 70th IETF meeting in Vancouver, British
Columbia,
> has been posted a few days ahead of schedule on the www.ietf.org web
> site. It shows TRILL as being Thursday morning. However, a couple of
our
> working group draft authors have requested that we attempt to have the
> meeting move to Tuesday. Although it is not clear that we can do this,
> keeping in mind other working group and meeting space constraints (for
> example, as an Internet Area WG we can't conflict with the INTAREA
> meeting Tuesday afternoon), we plan to request such a move to Tuesday.
> 
> Thanks,
> Erik and Donald
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Date: Wed, 31 Oct 2007 14:50:36 -0700
From: Radia Perlman <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 9098

Eric....if I understand your concern...

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

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

Radia

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

Date: Wed, 31 Oct 2007 14:38:39 -0400
From: James Carlson <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 2342

Eric Gray writes:
> What we would be saying - if we specify what you suggest - is 
> that the VID cannot change in going from A to B (or B to A).

Effectively, yes.

> 	This ability to change VID values is consistent with 
> existing device capabilities.  There may be an administrative 
> domain boundary at this device, or the device may provide a
> Q-in-Q function.  If we are not saying this implementation 
> will be non-conformant, it's unreasonable to disallow this.

I think there's a distinction to draw here.

If an implementation has some sort of VLAN mapping function beyond the
typical tagged/untagged distinction, that seems fine to me.  The rule
should be written to allow such a thing, because it's trivial to show
that you could construct the same device out of a series of cascaded
devices.

That's not what I was understanding Silvano Gai to say.  Instead, I
was understanding his proposal as a sort of "pernicious bridging."

By "pernicious bridging," I mean that the RBridge detects that it has
disjoint groups of interfaces in the network that have the same VLAN
ID configured.  Based on this detection alone, it then finds shortest
paths between those locations.  Where those paths cross an interface
that doesn't support the desired VLAN ID, we simply use a different
one -- perhaps chosen at random (Silvano's slides don't describe this)
-- and drive on.

If it's based on administratively-configured mappings ("VLAN 3 can
appear on this interface using VLAN ID 7"), then it doesn't sound at
all like a problem to me, because the algorithms and administrative
entries still make sense if you change all the numbers.  If it just
"happens" by virtue of discovering disjoint VLANs, then I think it's a
problem.

> 	What I thought Donald meant by "the same" was not with
> respect to the "inner" VLAN ID - but with respect to all of
> the frames sent using a particular physical interface.  That
> would be REALLY BAD.  It would - for example - make it very
> hard to do as good a job with link utilization using RBridges
> as it is already possible to do using MSTP bridges.

Yes; that'd be bad.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Content-class: urn:content-classes:message
Date: Wed, 31 Oct 2007 12:47:47 -0500
From: "Eric Gray" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Zhi-Hern Loh" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 7327

Anoop,

	This is a generic VLAN bridging problem, commonly
dealt with using VLAN bridges today.  Clearly, it is not
the case that all VLAN bridges are required to use a 
common VLAN for frame forwarding.

	In addition, as I understand it (in part based on
James' reply), we are NOT saying that the common VLAN
you mention must be used for all frame forwarding - 
hence it is likely that the existence of a common VLAN
does not necessarily fix the problem.

	Just to be clear, if we were saying that a common
VLAN must be used for all forwarding between RBridges,
it quickly becomes obvious that load-sharing based on
VLAN separation becomes useless in practice.  If load
sharing based on VID is not useful, then MSTP already
provides L2 forwarding that makes more efficient use of
links than would be possible using RBridges (unless all
RBridge-to-RBridge connections are via P2P links).

--
Eric Gray
Principal Engineer
Ericsson  

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

Content-class: urn:content-classes:message
Date: Wed, 31 Oct 2007 10:33:07 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Zhi-Hern Loh" <[email-masked]>, "Eric Gray" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 5732

Hern,

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

Anoop 

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

Content-class: urn:content-classes:message
Date: Wed, 31 Oct 2007 12:27:18 -0500
From: "Eric Gray" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 4194

James,

	That is kind of what I though, and - IMO - it seems to 
be pointless (over) specification.  Still, it's better than
other possible interpretation for what Donald was saying (see 
toward the end, below).

	Consider this simplified representation of a (specific) 
RBridge implementation:

      _________________________ _ _
     |       ________________      |
   A |    B |                |C    | D
  ---+-[*]--+    Q-Bridge    +-[?]-+---
     |      |________________|     |
     |                             |
     |            RBridge          |
     |_________________________ _ _|

	It's important to realize that this is one potential
implementation - used as an example.

	In this example:

o	A is the port connecting this RBridge to other RBridges;
o	[*] represents the process we're defining for preparing 
	a frame to be ingressed on to, or egressed off of, the
	RBridge campus;
o	B is an internal port, connecting that function to an
	internal Q-Bridge;
o	C is an internal port connecting this same internal 
	Q-Bridge to any arbitrary set of other functions within
	the implementation - possibly including other internal 
	Q-Bridges;
o	[?] represents the arbitrary (set of) internal functions
	(again, possibly including other internal Q-Bridges)
	connecting internal port C to port D;
o	D is the port connecting this RBridge to end stations 
	external to the RBridge campus.

What we would be saying - if we specify what you suggest - is 
that the VID cannot change in going from A to B (or B to A).

	That may be a very reasonable thing to say, but we have
to be careful in saying it.  It is important NOT to be saying 
that the VID cannot change in going from A to D (or D to A).  
The externally visible behavior - for this implementation may 
include changing the VID for any specific set of frames at 'B', 
at 'C', or within the set of functions represented by '[?]'.  

	This ability to change VID values is consistent with 
existing device capabilities.  There may be an administrative 
domain boundary at this device, or the device may provide a
Q-in-Q function.  If we are not saying this implementation 
will be non-conformant, it's unreasonable to disallow this.

	What I thought Donald meant by "the same" was not with
respect to the "inner" VLAN ID - but with respect to all of
the frames sent using a particular physical interface.  That
would be REALLY BAD.  It would - for example - make it very
hard to do as good a job with link utilization using RBridges
as it is already possible to do using MSTP bridges.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]] 
> Sent: Wednesday, October 31, 2007 10:14 AM
> To: Eric Gray
> Cc: Eastlake III Donald-LDE008; Zhi-Hern Loh; Developing a 
> hybrid router/bridge.
> Subject: Re: [rbridge] RBridge: a case of study
> Importance: High
> 
> Eric Gray writes:
> > Donald,
> > 
> > 	When you say "would all have the same Outer [VID]"
> > - do you mean:
> > 
> > 1) all frames MUST have the same VID within the an RBridge 
> >    campus, 
> > 2) all frames forwarded from a (physical) port on one RBridge 
> >    to a (physical) port on another RBridge MUST have the same
> >    VID, or 
> > 3) something else?
> 
> (I'm not Donald, but ...)
> 
> My understanding was more like:
> 
>   3) Where an outer VLAN tag is present, all frames transmitted by an
>      RBridge must have the same inner and outer VLAN tag numbers.
>      Where an outer VLAN tag is not present, the implicit tag for that
>      port must match or be compatible with the inner tag.
> 
> ... which would be consistent with "traditional" bridge behavior and
> would effectively rule out the type of solution that Silvano Gai has
> been proposing.
> 
> The distinction with (2) in your list is that (2) appears to rule out
> the use of so-called "tagged" or leaf or ingress ports, forcing all
> ports to carry VLAN tags.
> 
> -- 
> James Carlson, Solaris Networking              
> <[email-masked]>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
> 

Date: Wed, 31 Oct 2007 10:17:26 -0700 (PDT)
From: Zhi-Hern Loh <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 4763

Donald,

In addition to Eric's questions, could you (or anyone else) explain what would happen in the following scenario?

Toplogy:

                RBa
                /
              VID a
               /
   RBn-link X-----VID b------RBb

Problem:

  RBn is connected to 2 VLANs on link/port X. Connectivity to RBa is via VLAN a, and connectivity to RBb is via VLAN b.

  Suppose that RBa and RBb are in the multi-destination distribution tree from RBn. For a multi-destination frame going out link/port X on RBn to RBa and RBb, what is the VID on the outer VLAN tag? Or could there be need to send 2 frames, one with VID a and another with VID b?

Thanks,
Hern
Fulcrum Microsystems

----- Original Message -----
From: "Eric Gray" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "Zhi-Hern Loh" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Sent: Wednesday, October 31, 2007 4:16:33 AM (GMT-0800) America/Los_Angeles
Subject: RE: [rbridge] RBridge: a case of study

Donald,

	When you say "would all have the same Outer [VID]"
- do you mean:

1) all frames MUST have the same VID within the an RBridge 
   campus, 
2) all frames forwarded from a (physical) port on one RBridge 
   to a (physical) port on another RBridge MUST have the same
   VID, or 
3) something else?

--
Eric Gray
Principal Engineer
Ericsson  

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

Date: Wed, 31 Oct 2007 10:14:05 -0400
From: James Carlson <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 1215

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

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

My understanding was more like:

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

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

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

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Date: Wed, 31 Oct 2007 09:01:47 -0400
From: James Carlson <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 3141

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

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

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

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

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

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

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

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Content-class: urn:content-classes:message
Date: Wed, 31 Oct 2007 05:36:12 -0700
From: "Silvano Gai" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLANtags	onRBridge-RBridgepackets?
Status: RO
Content-Length: 300

Anoop, Radia,

The problem pointed out by Anoop, i.e.

> 
> The problem with this is that there may be RB's sending
> hellos on a VLAN that other RB's don't see.  As a result
> the adjacency creation may not be correct. 

It is the key issue we need to solve: we need a ROBUST solution.

-- Silvano

Content-class: urn:content-classes:message
Date: Wed, 31 Oct 2007 06:16:33 -0500
From: "Eric Gray" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "Zhi-Hern Loh" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 3710

Donald,

	When you say "would all have the same Outer [VID]"
- do you mean:

1) all frames MUST have the same VID within the an RBridge 
   campus, 
2) all frames forwarded from a (physical) port on one RBridge 
   to a (physical) port on another RBridge MUST have the same
   VID, or 
3) something else?

--
Eric Gray
Principal Engineer
Ericsson  

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

Content-class: urn:content-classes:message
Date: Wed, 31 Oct 2007 02:32:16 -0700
From: "Silvano Gai" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 557

James,

-- snip --

> 
>   3.  Suppose we were to configure VLAN 7 within Cloud L.  Would you
>       expect H1 to be able to access nodes within the backbone Cloud G
>       at that point?  (I'm trying to figure out whether the "X" and
>       "Y" interfaces are of fundamentally different types or if the
>       RBridges are just bridges.  I suspect they're different.)
> 

I have produced an updated drawing to cover the case of "hybrid ports".

http://www.ip6.com/example-v2.ppt

In this drawing I assume that H5 is able to talk with H6.

-- Silvano

Content-class: urn:content-classes:message
Date: Wed, 31 Oct 2007 01:57:21 -0700
From: "Silvano Gai" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "James Carlson" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 797

Anoop wrote:

--- snip ---

> 
> This is where I think would help to introduce some
> additional terminology in the spec.  Just like MPLS
> LSRs have ingress, core, and egress functionality,
> I think we should have similar functions for RBridging.
> We could have access ports, trill ports and hybrid
> ports.  From access ports, we only accept non-trill
> encap'ed frames, from trill ports, we accept only
> trill-encap'ed frames, and finally, from hybrid ports
> we accept either.  Today we only allow hybrid ports
> and perhaps that's OK as a spec.
> 

I strongly second Anoop proposal of adding terminology related to
access, core, hybrid, ingress, egress, etc.

The lack of such terminology in TRILL has been cause of confusion and it
has slow down the progress of the spec.

-- Silvano

Content-class: urn:content-classes:message
Date: Wed, 31 Oct 2007 01:46:34 -0700
From: "Silvano Gai" <[email-masked]>
To: "Jian Liu" <[email-masked]>, <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 1415

inline

> -----Original Message-----
> From: Jian Liu [mailto:[email-masked]]
> Sent: Tuesday, October 30, 2007 3:28 PM
> To: Silvano Gai; [email-masked]
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] RBridge: a case of study
> 
> Silvano,
> 
> A couple of questions:
> 
> 1. In the proposed solution, what is considered in the TRILL domain?
It
> seems TRILL domain includes RBridge 1-4 and backbone cloud G, correct?

Yes, It may as well be the whole picture.

> 2. Are there regular bridges or RBridges in backbone cloud G?

All the clouds are built with regular IEEE 802.1Q bridges

-- Silvano

> 
> Regards,
> Jian
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Silvano Gai
> Sent: Tuesday, October 30, 2007 4:26 AM
> To: [email-masked]
> Cc: Developing a hybrid router/bridge.
> Subject: [rbridge] RBridge: a case of study
> 
> Radia,
> 
> I have added few slides to the example and I suggest that we use it as
a
> possible case of study for TRILL (of course, not the only one).
> 
> Let's see if the solutions we have discussed work on this example.
> 
> The complete case of study is at:
> 
> http://www.ip6.com/acme-example-v1.ppt
> 
> -- Silvano
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Wed, 31 Oct 2007 01:45:00 -0700
From: "Silvano Gai" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "James Carlson" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 3341

I agree with Anoop answers

-- Silvano

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[email-masked]]
> Sent: Tuesday, October 30, 2007 6:54 PM
> To: James Carlson; Silvano Gai
> Cc: Developing a hybrid router/bridge.; [email-masked]
> Subject: RE: [rbridge] RBridge: a case of study
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of James Carlson
> > Sent: Tuesday, October 30, 2007 2:37 PM
> > To: Silvano Gai
> > Cc: Developing a hybrid router/bridge.; [email-masked]
> > Subject: Re: [rbridge] RBridge: a case of study
> >
> > Silvano Gai writes:
> > > Radia,
> > >
> > > I have added few slides to the example and I suggest that
> > we use it as
> > > a possible case of study for TRILL (of course, not the only one).
> > >
> > > Let's see if the solutions we have discussed work on this example.
> > >
> > > The complete case of study is at:
> > >
> > > http://www.ip6.com/acme-example-v1.ppt
> >
> > I have a few narrow questions that I think might help me
> > understand this picture a bit better.  (I probably have more
> > questions once I know the narrow answers.  ;-})
> 
> Let me take a shot at answering these.
> 
> >   1.  After the proposed fix, should VLAN 3 on Cloud L be bridged
> >       together with VLAN 3 on Cloud R, even though the backbone
itself
> >       doesn't directly carry VLAN 3?  (I.e., are TRILL packets with
> >       outer VLAN ID 7 or 8 and with inner VLAN 3 present on the
> >       backbone?)
> 
> Yes, that's pretty much what ends up happening.
> We have effectively extended the bridged LAN.
> 
> >   2.  What happened to the routing that once went on?  It was
> >       previously possible to route between these VLANs, but in the
new
> >       diagram, it's not.  Is routing between these networks
> >       unimportant, or does it take place elsewhere, or must RBridges
> >       both bridge and route in this scenario?
> 
> Routing can continue to happen wherever it was happening.
> The Rbridge by itself doesn't do routing, but there's no
> reason why one cannot build a device that does bridging,
> RBridging, and routing.
> 
> >   3.  Suppose we were to configure VLAN 7 within Cloud L.  Would you
> >       expect H1 to be able to access nodes within the backbone Cloud
G
> >       at that point?  (I'm trying to figure out whether the "X" and
> >       "Y" interfaces are of fundamentally different types or if the
> >       RBridges are just bridges.  I suspect they're different.)
> 
> This is where I think would help to introduce some
> additional terminology in the spec.  Just like MPLS
> LSRs have ingress, core, and egress functionality,
> I think we should have similar functions for RBridging.
> We could have access ports, trill ports and hybrid
> ports.  From access ports, we only accept non-trill
> encap'ed frames, from trill ports, we accept only
> trill-encap'ed frames, and finally, from hybrid ports
> we accept either.  Today we only allow hybrid ports
> and perhaps that's OK as a spec.
> 
> Anyway, back to the specifics of your question: If you
> did configure VLAN 7 within cloud L, then the RBridges
> labeled "Router 1" and "Router 2" would have 2 of their
> ports configured to be on VLAN 7 and would simply bridge
> between those ports.
> 
> Anoop

Content-class: urn:content-classes:message
Date: Wed, 31 Oct 2007 00:22:15 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Zhi-Hern Loh" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 2716

Hi,

Yes, as noted in protocol draft -05, the pseudo code was unchanged from
-04 and is out of date.

As currently being discussed, the TRILL encapsulated data being
forwarded out a particular physical port would all have the same Outer
VLAN ID.

Thanks,
Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Zhi-Hern Loh
Sent: Tuesday, October 30, 2007 10:54 PM
To: Anoop Ghanwani
Cc: Developing a hybrid router/bridge.; Radia Perlman; James Carlson
Subject: Re: [rbridge] RBridge: a case of study

----- "Anoop Ghanwani" <[email-masked]> wrote:
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of James Carlson
> > Sent: Tuesday, October 30, 2007 2:37 PM
> > To: Silvano Gai
> > Cc: Developing a hybrid router/bridge.; [email-masked]
> > Subject: Re: [rbridge] RBridge: a case of study
> > 
> > Silvano Gai writes:
> > > Radia,
> > > 
> > > I have added few slides to the example and I suggest that 
> > we use it as 
> > > a possible case of study for TRILL (of course, not the only one).
> > > 
> > > Let's see if the solutions we have discussed work on this
> example.
> > > 
> > > The complete case of study is at:
> > > 
> > > http://www.ip6.com/acme-example-v1.ppt
> > 
> > I have a few narrow questions that I think might help me 
> > understand this picture a bit better.  (I probably have more 
> > questions once I know the narrow answers.  ;-})
> 
> Let me take a shot at answering these.
> 
> >   1.  After the proposed fix, should VLAN 3 on Cloud L be bridged
> >       together with VLAN 3 on Cloud R, even though the backbone
> itself
> >       doesn't directly carry VLAN 3?  (I.e., are TRILL packets with
> >       outer VLAN ID 7 or 8 and with inner VLAN 3 present on the
> >       backbone?)
> 
> Yes, that's pretty much what ends up happening.  
> We have effectively extended the bridged LAN.
> 

Anoop, I'm reading the RBridge protocol specification version 5 and it
seems to me that your comment is inconsistent with the spec. In section,
5.2.2.3, the spec says that the outer VLAN tag of TRILL data frames has
the same VID as the inner tag. Is this section going to be changed?

Futhermore, if we were to use different VIDs on outer VLAN tags then we
would need to handle the multi-destination case where one would need to
send a multi-destination frame per outer VID to communicate with the RBs
in the distribution tree which are using different VIDs. Is this
correct?

Thanks,
Hern
Fulcrum Microsystems

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

Date: Tue, 30 Oct 2007 21:12:57 -0700
From: [email-masked]
To: Zhi-Hern Loh <[email-masked]>
Priority: normal
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 1160

Thanks for pointing that out Hern. Serves me right for not reading the pseudocode part
of the spec, which got added later
for clarity.  My understanding has always been that the outer VLAN was just a way to
carry the frame across the layer 2 cloud from one RBridge to another, and would be
completely independent of the inner one.

Radia

----- Original Message -----
From: Zhi-Hern Loh <[email-masked]>
Date: Tuesday, October 30, 2007 7:53 pm
Subject: Re: [rbridge] RBridge: a case of study

> 
> Anoop, I'm reading the RBridge protocol specification version 5 and 
> it seems to me that your comment is inconsistent with the spec. In 
> section, 5.2.2.3, the spec says that the outer VLAN tag of TRILL 
> data frames has the same VID as the inner tag. Is this section 
> going to be changed?
> 
> Futhermore, if we were to use different VIDs on outer VLAN tags 
> then we would need to handle the multi-destination case where one 
> would need to send a multi-destination frame per outer VID to 
> communicate with the RBs in the distribution tree which are using 
> different VIDs. Is this correct?
> 
> Thanks,
> Hern
> Fulcrum Microsystems
> 
> 

Date: Tue, 30 Oct 2007 21:01:32 -0700
From: Dinesh G Dutt <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN	tags	onRBridge-RBridgepackets?
Status: RO
Content-Length: 2781

Radia,

I've been swamped at work and have been travelling as well. Most of my 
issues were related to sending Hello on a single VLAN only, be it VLAN 1 
or configurable. I'll get back to you in the next couple of days after I 
have caught up on the discussions,

Dinesh
Radia Perlman wrote:
> Silvano Gai wrote:
>   
>> "VLAN 1--nonconfigurable" is a non-starter for me, I hope to have
>> explained why.
>>
>> "single VLAN per layer 2 cloud" may be workable, but I need to see the
>> details of the algorithm to see if there are corner cases.
>>
>> If we can agree to concentrate our focus on a "single VLAN per layer 2
>> cloud" we have made some progress.
>>
>> -- Silvano
>>
>>   
>>     
> I can live with "single VLAN, configurable, default=1". I'd recommend 
> that regardless of
> the VLAN you are configured to send a Hello on, you accept Hellos on any 
> VLAN you
> are capable of receiving traffic on, and that each DRB tells all the 
> other RBridges on that cloud
> what VLAN to send on, so that they all wind up sending RBridge traffic 
> on the same VLAN.
>
> I think the only complexity/overhead it adds over "VLAN 1, 
> nonconfigurable is"
>
> a) something configurable to document and present in the management 
> interface (the VLAN on
> which to send Hellos)
> b) until a DRB is elected, there might be lots of RBridges transmitting 
> on different VLANs because
> each might be configured with a different VLAN
> c) if there are multiple (say k)  DRBs (because for load splitting each 
> of them is DRB for
> a different (nonoverlapping) set
> of VLANs), then there will be k times as many Hellos being sent
> d) I think there might be a slightly higher probability that there will 
> be misconfiguration such
> as telling each RBridge a different set of VLANs to talk on, but the 
> safeguards that I specified
> in previous emails (listen to BPDUs, report root bridge in pseudonode 
> LSP, don't decapsulate
> from an ingress RBridge that you haven't seen all the LSPs from, wait 
> until you've synchrornized
> LSP databases with your neighbors when you first start up) will prevent 
> loops in these cases, and
> at worst orphan parts of the layer 2 cloud from the rest of the campus.
>
> So...can everyone live with this? (Silvano -- as you said above,
> you promised to think about whether there
> were any corner cases to worry about. You also said you wanted to see 
> "the whole algorithm
> specified". I'll do that in a separate email.
>
> Radia
>
>
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> 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

Date: Tue, 30 Oct 2007 20:57:02 -0700
From: Dinesh G Dutt <[email-masked]>
To: Zhi-Hern Loh <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>, James Carlson <[email-masked]>
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 2567

The spec is a trifle out of date and will be fixed once we all agree on 
some of the outstanding issues,

Dinesh
Zhi-Hern Loh wrote:
> ----- "Anoop Ghanwani" <[email-masked]> wrote:
>   
>>> -----Original Message-----
>>> From: [email-masked] 
>>> [mailto:[email-masked]] On Behalf Of James Carlson
>>> Sent: Tuesday, October 30, 2007 2:37 PM
>>> To: Silvano Gai
>>> Cc: Developing a hybrid router/bridge.; [email-masked]
>>> Subject: Re: [rbridge] RBridge: a case of study
>>>
>>> Silvano Gai writes:
>>>       
>>>> Radia,
>>>>
>>>> I have added few slides to the example and I suggest that 
>>>>         
>>> we use it as 
>>>       
>>>> a possible case of study for TRILL (of course, not the only one).
>>>>
>>>> Let's see if the solutions we have discussed work on this
>>>>         
>> example.
>>     
>>>> The complete case of study is at:
>>>>
>>>> http://www.ip6.com/acme-example-v1.ppt
>>>>         
>>> I have a few narrow questions that I think might help me 
>>> understand this picture a bit better.  (I probably have more 
>>> questions once I know the narrow answers.  ;-})
>>>       
>> Let me take a shot at answering these.
>>
>>     
>>>   1.  After the proposed fix, should VLAN 3 on Cloud L be bridged
>>>       together with VLAN 3 on Cloud R, even though the backbone
>>>       
>> itself
>>     
>>>       doesn't directly carry VLAN 3?  (I.e., are TRILL packets with
>>>       outer VLAN ID 7 or 8 and with inner VLAN 3 present on the
>>>       backbone?)
>>>       
>> Yes, that's pretty much what ends up happening.  
>> We have effectively extended the bridged LAN.
>>
>>     
>
> Anoop, I'm reading the RBridge protocol specification version 5 and it seems to me that your comment is inconsistent with the spec. In section, 5.2.2.3, the spec says that the outer VLAN tag of TRILL data frames has the same VID as the inner tag. Is this section going to be changed?
>
> Futhermore, if we were to use different VIDs on outer VLAN tags then we would need to handle the multi-destination case where one would need to send a multi-destination frame per outer VID to communicate with the RBs in the distribution tree which are using different VIDs. Is this correct?
>
> Thanks,
> Hern
> Fulcrum Microsystems
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> 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

Date: Tue, 30 Oct 2007 19:53:58 -0700 (PDT)
From: Zhi-Hern Loh <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>, James Carlson <[email-masked]>
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 2013

----- "Anoop Ghanwani" <[email-masked]> wrote:
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of James Carlson
> > Sent: Tuesday, October 30, 2007 2:37 PM
> > To: Silvano Gai
> > Cc: Developing a hybrid router/bridge.; [email-masked]
> > Subject: Re: [rbridge] RBridge: a case of study
> > 
> > Silvano Gai writes:
> > > Radia,
> > > 
> > > I have added few slides to the example and I suggest that 
> > we use it as 
> > > a possible case of study for TRILL (of course, not the only one).
> > > 
> > > Let's see if the solutions we have discussed work on this
> example.
> > > 
> > > The complete case of study is at:
> > > 
> > > http://www.ip6.com/acme-example-v1.ppt
> > 
> > I have a few narrow questions that I think might help me 
> > understand this picture a bit better.  (I probably have more 
> > questions once I know the narrow answers.  ;-})
> 
> Let me take a shot at answering these.
> 
> >   1.  After the proposed fix, should VLAN 3 on Cloud L be bridged
> >       together with VLAN 3 on Cloud R, even though the backbone
> itself
> >       doesn't directly carry VLAN 3?  (I.e., are TRILL packets with
> >       outer VLAN ID 7 or 8 and with inner VLAN 3 present on the
> >       backbone?)
> 
> Yes, that's pretty much what ends up happening.  
> We have effectively extended the bridged LAN.
> 

Anoop, I'm reading the RBridge protocol specification version 5 and it seems to me that your comment is inconsistent with the spec. In section, 5.2.2.3, the spec says that the outer VLAN tag of TRILL data frames has the same VID as the inner tag. Is this section going to be changed?

Futhermore, if we were to use different VIDs on outer VLAN tags then we would need to handle the multi-destination case where one would need to send a multi-destination frame per outer VID to communicate with the RBs in the distribution tree which are using different VIDs. Is this correct?

Thanks,
Hern
Fulcrum Microsystems

Content-class: urn:content-classes:message
Date: Tue, 30 Oct 2007 18:54:28 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "James Carlson" <[email-masked]>, "Silvano Gai" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 2898

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James Carlson
> Sent: Tuesday, October 30, 2007 2:37 PM
> To: Silvano Gai
> Cc: Developing a hybrid router/bridge.; [email-masked]
> Subject: Re: [rbridge] RBridge: a case of study
> 
> Silvano Gai writes:
> > Radia,
> > 
> > I have added few slides to the example and I suggest that 
> we use it as 
> > a possible case of study for TRILL (of course, not the only one).
> > 
> > Let's see if the solutions we have discussed work on this example.
> > 
> > The complete case of study is at:
> > 
> > http://www.ip6.com/acme-example-v1.ppt
> 
> I have a few narrow questions that I think might help me 
> understand this picture a bit better.  (I probably have more 
> questions once I know the narrow answers.  ;-})

Let me take a shot at answering these.

>   1.  After the proposed fix, should VLAN 3 on Cloud L be bridged
>       together with VLAN 3 on Cloud R, even though the backbone itself
>       doesn't directly carry VLAN 3?  (I.e., are TRILL packets with
>       outer VLAN ID 7 or 8 and with inner VLAN 3 present on the
>       backbone?)

Yes, that's pretty much what ends up happening.  
We have effectively extended the bridged LAN.

>   2.  What happened to the routing that once went on?  It was
>       previously possible to route between these VLANs, but in the new
>       diagram, it's not.  Is routing between these networks
>       unimportant, or does it take place elsewhere, or must RBridges
>       both bridge and route in this scenario?

Routing can continue to happen wherever it was happening.
The Rbridge by itself doesn't do routing, but there's no
reason why one cannot build a device that does bridging,
RBridging, and routing.

>   3.  Suppose we were to configure VLAN 7 within Cloud L.  Would you
>       expect H1 to be able to access nodes within the backbone Cloud G
>       at that point?  (I'm trying to figure out whether the "X" and
>       "Y" interfaces are of fundamentally different types or if the
>       RBridges are just bridges.  I suspect they're different.)

This is where I think would help to introduce some
additional terminology in the spec.  Just like MPLS
LSRs have ingress, core, and egress functionality,
I think we should have similar functions for RBridging.
We could have access ports, trill ports and hybrid
ports.  From access ports, we only accept non-trill
encap'ed frames, from trill ports, we accept only
trill-encap'ed frames, and finally, from hybrid ports
we accept either.  Today we only allow hybrid ports
and perhaps that's OK as a spec.

Anyway, back to the specifics of your question: If you
did configure VLAN 7 within cloud L, then the RBridges
labeled "Router 1" and "Router 2" would have 2 of their
ports configured to be on VLAN 7 and would simply bridge
between those ports.

Anoop

Content-class: urn:content-classes:message
Date: Tue, 30 Oct 2007 18:41:15 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Silvano Gai" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLANtags	onRBridge-RBridgepackets?
Status: RO
Content-Length: 3665

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Tuesday, October 30, 2007 5:23 PM
> To: Silvano Gai
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Final outcome of outer VLANtags 
> onRBridge-RBridgepackets?
> 
> Silvano Gai wrote:
> >
> > "VLAN 1--nonconfigurable" is a non-starter for me, I hope to have 
> > explained why.
> >
> > "single VLAN per layer 2 cloud" may be workable, but I need 
> to see the 
> > details of the algorithm to see if there are corner cases.
> >
> > If we can agree to concentrate our focus on a "single VLAN 
> per layer 2 
> > cloud" we have made some progress.
> >
> > -- Silvano
> 
> I can live with "single VLAN, configurable, default=1". I'd 
> recommend that regardless of the VLAN you are configured to 
> send a Hello on, you accept Hellos on any VLAN you are 
> capable of receiving traffic on, and that each DRB tells all 
> the other RBridges on that cloud what VLAN to send on, so 
> that they all wind up sending RBridge traffic on the same VLAN.
> 
> I think the only complexity/overhead it adds over "VLAN 1, 
> nonconfigurable is"
> 
> a) something configurable to document and present in the 
> management interface (the VLAN on which to send Hellos)
> b) until a DRB is elected, there might be lots of RBridges 
> transmitting on different VLANs because each might be 
> configured with a different VLAN

The problem with this is that there may be RB's sending
hellos on a VLAN that other RB's don't see.  As a result
the adjacency creation may not be correct.  For example,
RB1 may send its hellos on VLAN 4, RB2 may send its
hellos on VLAN 5, neither RBridge is able to see the
other's hellos because of the way the bridged LAN is
configured.

I think the correct way to solve this is to say that
hellos will be sent on exactly one VLAN for any bridged
LAN - VLAN 1 would be default, but configuration is
allowed.  So in the LSP, along with things like root
bridge for the pseudonode, we advertise the "Rbridge
control VLAN" that is used.  If a conflict is detected
when an LSP is received (same root, different control
VLAN), then the RBridge with higher ID stop being a
DRB and reports a misconfiguration.

A misconfiguration could also be detected by configuring
all RBridges on the LAN to be in a maintenance association
using 802.1ag. (But that would be very configuration
intensive.  802.1ag would cause a trap to be generated
if all Rbridges don't see all the Rbridges they expect 
to see, or if they see extra ones that they haven't
been configured about.)

> c) if there are multiple (say k)  DRBs (because for load 
> splitting each of them is DRB for a different 
> (nonoverlapping) set of VLANs), then there will be k times as 
> many Hellos being sent
> d) I think there might be a slightly higher probability that 
> there will be misconfiguration such as telling each RBridge a 
> different set of VLANs to talk on, but the safeguards that I 
> specified in previous emails (listen to BPDUs, report root 
> bridge in pseudonode LSP, don't decapsulate from an ingress 
> RBridge that you haven't seen all the LSPs from, wait until 
> you've synchrornized LSP databases with your neighbors when 
> you first start up) will prevent loops in these cases, and at 
> worst orphan parts of the layer 2 cloud from the rest of the campus.
> 
> So...can everyone live with this? (Silvano -- as you said 
> above, you promised to think about whether there were any 
> corner cases to worry about. You also said you wanted to see 
> "the whole algorithm specified". I'll do that in a separate email.

Date: Tue, 30 Oct 2007 17:22:52 -0700
From: Radia Perlman <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tags	onRBridge-RBridgepackets?
Status: RO
Content-Length: 2085

Silvano Gai wrote:
>
> "VLAN 1--nonconfigurable" is a non-starter for me, I hope to have
> explained why.
>
> "single VLAN per layer 2 cloud" may be workable, but I need to see the
> details of the algorithm to see if there are corner cases.
>
> If we can agree to concentrate our focus on a "single VLAN per layer 2
> cloud" we have made some progress.
>
> -- Silvano
>
>   
I can live with "single VLAN, configurable, default=1". I'd recommend 
that regardless of
the VLAN you are configured to send a Hello on, you accept Hellos on any 
VLAN you
are capable of receiving traffic on, and that each DRB tells all the 
other RBridges on that cloud
what VLAN to send on, so that they all wind up sending RBridge traffic 
on the same VLAN.

I think the only complexity/overhead it adds over "VLAN 1, 
nonconfigurable is"

a) something configurable to document and present in the management 
interface (the VLAN on
which to send Hellos)
b) until a DRB is elected, there might be lots of RBridges transmitting 
on different VLANs because
each might be configured with a different VLAN
c) if there are multiple (say k)  DRBs (because for load splitting each 
of them is DRB for
a different (nonoverlapping) set
of VLANs), then there will be k times as many Hellos being sent
d) I think there might be a slightly higher probability that there will 
be misconfiguration such
as telling each RBridge a different set of VLANs to talk on, but the 
safeguards that I specified
in previous emails (listen to BPDUs, report root bridge in pseudonode 
LSP, don't decapsulate
from an ingress RBridge that you haven't seen all the LSPs from, wait 
until you've synchrornized
LSP databases with your neighbors when you first start up) will prevent 
loops in these cases, and
at worst orphan parts of the layer 2 cloud from the rest of the campus.

So...can everyone live with this? (Silvano -- as you said above,
you promised to think about whether there
were any corner cases to worry about. You also said you wanted to see 
"the whole algorithm
specified". I'll do that in a separate email.

Radia

Content-class: urn:content-classes:message
Date: Tue, 30 Oct 2007 15:28:27 -0700
From: "Jian Liu" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 968

Silvano,

A couple of questions:

1. In the proposed solution, what is considered in the TRILL domain? It
seems TRILL domain includes RBridge 1-4 and backbone cloud G, correct?
2. Are there regular bridges or RBridges in backbone cloud G?

Regards,
Jian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Silvano Gai
Sent: Tuesday, October 30, 2007 4:26 AM
To: [email-masked]
Cc: Developing a hybrid router/bridge.
Subject: [rbridge] RBridge: a case of study

Radia,

I have added few slides to the example and I suggest that we use it as a
possible case of study for TRILL (of course, not the only one).

Let's see if the solutions we have discussed work on this example.

The complete case of study is at:

http://www.ip6.com/acme-example-v1.ppt

-- Silvano

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

Date: Tue, 30 Oct 2007 17:37:26 -0400
From: James Carlson <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 1656

Silvano Gai writes:
> Radia,
> 
> I have added few slides to the example and I suggest that we use it as a
> possible case of study for TRILL (of course, not the only one).
> 
> Let's see if the solutions we have discussed work on this example.
> 
> The complete case of study is at:
> 
> http://www.ip6.com/acme-example-v1.ppt

I have a few narrow questions that I think might help me understand
this picture a bit better.  (I probably have more questions once I
know the narrow answers.  ;-})

  1.  After the proposed fix, should VLAN 3 on Cloud L be bridged
      together with VLAN 3 on Cloud R, even though the backbone itself
      doesn't directly carry VLAN 3?  (I.e., are TRILL packets with
      outer VLAN ID 7 or 8 and with inner VLAN 3 present on the
      backbone?)

  2.  What happened to the routing that once went on?  It was
      previously possible to route between these VLANs, but in the new
      diagram, it's not.  Is routing between these networks
      unimportant, or does it take place elsewhere, or must RBridges
      both bridge and route in this scenario?

  3.  Suppose we were to configure VLAN 7 within Cloud L.  Would you
      expect H1 to be able to access nodes within the backbone Cloud G
      at that point?  (I'm trying to figure out whether the "X" and
      "Y" interfaces are of fundamentally different types or if the
      RBridges are just bridges.  I suspect they're different.)

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Content-class: urn:content-classes:message
Date: Tue, 30 Oct 2007 04:26:22 -0700
From: "Silvano Gai" <[email-masked]>
To: <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] RBridge: a case of study
Status: RO
Content-Length: 302

Radia,

I have added few slides to the example and I suggest that we use it as a
possible case of study for TRILL (of course, not the only one).

Let's see if the solutions we have discussed work on this example.

The complete case of study is at:

http://www.ip6.com/acme-example-v1.ppt

-- Silvano

Content-class: urn:content-classes:message
Date: Tue, 30 Oct 2007 05:34:45 -0500
From: "Eric Gray" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?
Status: RO
Content-Length: 9003

Radia,

	Unfortunately, some people (myself, for instance) will be in
Paris this week for the MEF meeting.  Meeting at a time convenient
to the US west coast is difficult for people meeting in Europe.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, October 29, 2007 4:14 PM
> To: Silvano Gai
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Final outcome of outer VLAN tags 
> onRBridge-RBridgepackets?
> 
> Silvano,
> Based on your message, I think a lot of the controversy here 
> is simply miscommunication, which is actually great news.
> The VLAN number we have been talking about is solely a local 
> matter on a single layer 2 cloud. It
> is only the outer VLAN number used for RBridge-RBridge communication.
> 
> So looking at your picture, note that we have three separate 
> layer 2 clouds. Let's add "port" numbers,
> so that for each of the RBridges, their top port will be 
> called "x" and their bottom port would
> be called "y".
> 
> Let's call the clouds "G" for the top one (because it is 
> green). And "L" for the lower left, and "R" for the
> lower right.
> 
> if we went with the "VLAN 1 unconfigurable" strategy, then 
> we'd have to
> tell that customer to open up VLAN 1 on the G cloud and R 
> cloud (and I'm sure I'm using the wrong word,
> but by "open up", I mean make it so that the RBridges are 
> capable of sending and receiving traffic
> on VLAN 1, and that VLAN 1 is not partitioned in the green 
> cloud). It wouldn't cause
> the VLANs to get merged or anything like that. It just means 
> that VLAN 1 would not be allowed to
> be partitioned on any of those 3 clouds, and that the 
> RBridges must be able to use VLAN 1
> to communicate with each other. And it means that all the 
> traffic for RBridge-RBridge communication
> (which consists of IS-IS Hellos, LSP forwarding, and encapsulated
> data packet forwarding across the cloud between RBridges)
> would be sent with an outer VLAN tag of 1.
> 
> If we instead went with
> the "single VLAN, but configurable", then all the RBridges 
> would be configured to use, say, VLAN 7
> for RBridge-RBridge communication on their "port x" which 
> connects to cloud G.
> RB1 and RB2's "port y" would not need to be configured, since 
> VLAN 1 would already work on the cloud
> attached to that port. RB3 and RB4 would need to be 
> configured to use, say, VLAN 3, on their "y" port (the
> one to cloud R).
> 
> Would some number of people like to have a phone call early 
> this week and resolve it? I'd hope that
> the people would include at least you (Silvano), Dinesh, me, 
> Anoop, but I don't mean to exclude anyone.
> 
> Radia
> 
> 
> 
> ----- Original Message -----
> From: Silvano Gai <[email-masked]>
> Date: Sunday, October 28, 2007 4:49 am
> Subject: RE: [rbridge] Final outcome of outer VLAN tags 
> onRBridge-RBridgepackets?
> 
> > 
> > Radia,
> > 
> > Can you explain me if your solution supports the example that I have
> > drawn in PowerPoint at:
> > http://www.ip6.com/example.ppt
> > ?
> > 
> > Thank You
> > 
> > Answering your email:
> > 
> > I have seen customers deploying VLANs in a variety of ways.
> > 
> > Some customers have VLAN 1 end-to-end and they use it for 
> control and
> > data traffic. Some customers use VLAN 1 only for control 
> traffic. Some
> > customers wants all VLANs (including VLAN 1) being local (not
> > end-to-end). Some customers prefer to move some control protocol to
> > another VLAN. I have seen multiple different approaches.
> > 
> > You ask for rational, "tangible reasons". Each customer has its own
> > reasons that don't match the ones of other customers. There are no
> > universal tangible reasons, you just need to realize that 
> IEEE 802.1Q
> > allows VLANs to be deployed in many different way.  Any 
> solution that
> > poses restrictions is going to be OK for some customers and KO for
> > others.
> > 
> > Over the years I have learned to live with the fact that customers 
> > havedifferent deployment approaches that are perfectly valid 
> > because allowed
> > by IEEE 802.1Q and by the products.
> > 
> > In TRILL we often speak about plug-and-play. If we consider
> > plug-and-play, VLAN 1 is the only one enabled by default 
> and therefore
> > it seems a reasonable default solution.
> > 
> > While this is a valid concept in the consumer space, it is 
> absolutely
> > not valid in Enterprise/Datacenter. Enterprise/Datacenter customers
> > request that all the new boxes are shipped with all the ports 
> > disabled,because they realized that the switches will be connected 
> > in complex
> > configurations in which plug-and-play is very dangerous. 
> > 
> > I expect the same to be true for RBridges, where customers will
> > carefully design, test in a separate environment and bring-up a
> > configuration that will match the existing VLAN deployment 
> they have.
> > 
> > Inline for you specific questions:
> > 
> > 
> > > -----Original Message-----
> > > From: Radia Perlman [[email-masked]]
> > > Sent: Saturday, October 27, 2007 8:59 PM
> > > To: Silvano Gai
> > > Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> > > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-
> > > RBridgepackets?
> > > 
> > > I'm anxious to close on this issue, but
> > > Silvano...you always speak in such absolutes: words like
> > > "unrealistic" without giving tangible reasons what the
> > > problem is. Again, everything is engineering tradeoffs, and we 
> > have to
> > > understand what the specific
> > > pros and cons are (not phrases like
> > > "won't work" "unrealistic" "not flexible enough", but 
> instead "won't
> > allow
> > > this *particular* scenario")
> > > 
> > > Question: Is the problem picking specifically VLAN 1 as
> > > our chosen single VLAN number? If we picked a different
> > (unconfigurable)
> > > VLAN number would that be OK? 
> > 
> > I think that VLAN 1 is probably our best default choice. I don't 
> > objectto have VLAN 1 to be the default VLAN.
> > 
> > If so, what number? If you are arguing that
> > > it's OK to require one VLAN not to be partitioned, and that all
> > > RBridge-RBridge
> > > communication be done over that VLAN, then I really don't 
> > understand.
> > I am not sure what you are asking. If you are speaking of 
> the backbone
> > between RBridges, the outer VLAN tag for sure may not be the same
> > end-to-end.
> > 
> > A department of a large corporation may want to deploy RBridges in 5
> > different sites. The VLAN they have available from site_1 to site_2 
> > maybe VLAN 5, form site_1 to site_3 VLAN 7, from site_3 to site_4 
> > VLAN 4.
> > 
> > If you want all this VLANs to be a single VLAN end-to-end, 
> there is a
> > significant change that needs to happen in the communication
> > infrastructure that may be considered difficult or impossible.
> > 
> > If instead you are discussing the access to the RBridge clouds, I 
> > thinkit is reasonable to require that the RBridges that 
> perform TRILL
> > encapsulation for an Ethernet Cloud have a common VLAN. VLAN1 may 
> > be the
> > default, but I think that the value should be programmable.
> > 
> > 
> > > If that were the case, why can't we (TRILL) put a stake in the 
> > ground> and say "RBridges will
> > > use VLAN 1", and if the customer wanted to use VLAN 1 for 
> something
> > > else, but was willing
> > > to configure RBridges to use, say, VLAN 57, why can't 
> that customer
> > > renumber their own
> > > VLANs so that they switch their uses of VLAN 57 and VLAN 
> 1, and let
> > the
> > > rest of
> > > the world have the simplicity of an unconfigurable choice 
> of VLAN 1?
> > 
> > I don't think this is acceptable for many customers. You are 
> > putting a
> > stake in the ground that IEEE has never put.
> > 
> > > 
> > > Are you saying that you don't want to require customers to have 
> > *any*> VLAN number that
> > > isn't partitioned, 
> > 
> > I am not sure what you mean with "*any* VLAN number that isn't
> > partitioned", are you speaking of inner VLAN or outer VLAN?
> > 
> > In most installation the numbering spaces of the Backbone VLANs and
> > Access VLANs are disjoint. I don't think this is an issue since the
> > access VLANs appears in the inner VLAN tag, while the backbone VLANs
> > appears in the outer VLAN tag.
> > 
> > 
> > and you want a solution that somehow finds all
> > > possible ways of having
> > > RBridges talk to each other using every possible VLAN? 
> > 
> > Again, when you are saying "RBridges talk to each other" are you
> > speaking of the TRILL encapsulated frames or of the DRB election on 
> > theaccess?
> > 
> > Again see my example at:
> > http://www.ip6.com/example.ppt
> > 
> > -- Silvano
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Tue, 30 Oct 2007 02:52:42 -0700
From: "Silvano Gai" <[email-masked]>
To: <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?
Status: RO
Content-Length: 18140

Radia,

inline

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 29, 2007 7:46 PM
> To: Silvano Gai
> Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> Subject: Re: RE: RE: [rbridge] Final outcome of outer VLAN tags
onRBridge-
> RBridgepackets?
> 
> 1) I suggested a phone call sometime this week, but it was buried in
the
> end of my message. I'd particularly hope that (at least) you
(Silvano),
> Dinesh, Anoop, me, and Don Eastlake attend, but nobody would be
excluded.
> Send me email with all
> your availability for this week (and time zones) and I'll try to pick
a
> time.
> 
> 2) As for the updated picture, and talking through how I think
> it all would work -- I think all the three clouds are completely
> independent. So I think
> we could just as well be talking about a single layer 2 cloud with a
bunch
> of RBridges
> attached. But I'll use your picture.

A single cloud or three separate clouds are not the same thing. 

Let's assume that cloud L is located in Manhattan (main data center),
cloud R is located in New Jersey (backup data center) and Cloud G is
some form of public/private fiber connectivity with Ethernet switches
connected at the ends. Cloud G is run by central IT. Let's also assume
that the finance department has been assigned two VLANs (7 and 8) on the
Green Cloud and can use only that two VLANs. Originally the finance
department was using routers (instead of RBridges in
http://www.ip6.com/example.ppt), but now it is thinking to replace them
with RBridges. With routers finance needs at least two separate IP
subnets on VLAN 3, one on Cloud L, one on Cloud R. Replacing the routers
with RBridges, finance can use the same IP subnet for VLAN 3 in Cloud L
and Cloud R.

> 
> *********************
> 
> First: let's talk through what happens with the "use VLAN 1, no
> configuration" strategy:
> 
> The rule is that on every layer 2 cloud (R, G, and L in your picture),
> bridges inside each cloud must allow VLAN-1-tagged traffic to pass. 

This is impossible in our scenario. Finance has only VLAN 7 and 8 on the
Green Cloud. Finance is not the only department that wants to deploy
RBridges, also Marketing and Sales want to do the same. The requests of
Finance, Marketing, and Sales to own VLAN 1 on the Green Cloud conflict.
There is a strong corporate policy that the departments cannot share
VLANs (and believe me, on Wall Street these rules are enforced).

On Cloud R also we have an issue; Finance does not own VLAN 1.

Therefore allowing VLAN 1 traffic to pass on Cloud G and R is impossible
from a deployment perspective.

That
> would mean that
> VLAN 1 would not partitioned on that cloud. Also every RBridge port
must
> be configured to allow
> sending and receiving of VLAN 1 tagged traffic.
> 
> The way I read your picture (http://www.ip6.com/example.ppt): As
> configured, RB3, for
> instance, is only able to send/receive frames tagged
> with VLANs 2 and 3 on its port Y3, and send/receive VLANs 7 and 8 on
its
> port X3.
> (Is that a correct interpretation of your picture?)

YES

> So, assuming my interpretation is correct, if you started with an
> installation configured that
> way, then ports X3, Y3, X4, Y4, X1, and X2 would have to be
reconfigured
> to allow use of VLAN 1, and any
> bridges in between these ports (e.g., inside cloud G or cloud R), if
they
> were configured to partition VLAN 1,
> would have to be configured to allow traffic marked with VLAN 1 to be
> forwarded.

In this example, this is impossible, as I explained you above.

> 
> Consequences of not doing the reconfiguration as just stated are:
> If an RBridge R *cannot* send/receive on VLAN 1 on a port, R will not
send
> any Hellos (which might be fine -- perhaps
> there are no other RBridges on the link -- just endnodes, but my
> preference would
> be to discourage and possibly
> disallow having an RBridge port with VLAN 1 turned off). If VLAN 1 is
> partitioned on
> the cloud, the same consequence happens. R will not
> form any RBridge-RBridge adjacencies on that port, so no encapsulated
> traffic will be forwarded across that cloud. With
> the safeguards specified in my earlier emails, R will be conservative
> about encapsulating/decapsulating data traffic
> to/from that link, so that there won't be loops.
> 
> If VLAN 1 is not partitioned and all RBridges can send/receive VLAN 1,
> then everything works very smoothly. Other than
> having had to reconfigure things, I don't see what functionality the
> customer is giving up by allowing RBridges
> to talk on VLAN 1.

You are assuming that a customer "owns" the whole network. This is often
not the case. Departments own pieces of the network. This often is a
complex and painful process that results from merger and acquisition and
from complex security policy inside the corporation.

> 
> ************************
> Now let's talk about the "single VLAN, but we can configure which VLAN
it
> is" strategy:
> 
> The customer *could* reconfigure things to allow VLAN 1 for RBridge-
> RBridge communication, and then
> everything would work as above. But if for some reason they wanted to
only
> allow VLANs 7 and 8 in cloud G,
> and 2 and 3 in cloud R, then they could do the following:
> 
> Ports Y1 and Y2 will not require any configuration -- they already
support
> VLAN 1 (the default).

OK

> Ports X1, X2, X3, and X4 would be configured to send Hellos on either
VLAN
> 7 or 8. 

OK

I'd recommend, if the VLAN
> for Hellos is configurable, that you *accept* Hellos on any of the
VLANs
> for which you can receive traffic. 

This is a detail we can work later.

Whoever
> gets elected DRB (say RB1) specifies, in its Hello, "use VLAN 8", and
then
> X2, X3, and X4, as long as they continue
> to receive Hellos from RB1, send their Hellos on VLAN 8. Furthermore,
LSPs
> on cloud G are transmitted tagged with
> outer VLAN 8. Encapsulated data traffic being forwarded across cloud G
> would also have outer VLAN tag of 8.
> 
> If RB2 were DRB instead of RB1, and RB2 was configured to transmit on
VLAN
> 7, then it would tell all the RBridges to tag
> their RBridge-RBridge traffic with 7. If there are different
priorities,
> say RB1 is DRB for VLAN 7, and wants to
> tag RBridge-RBridge traffic with 7,  and RB2 is DRB for VLAN 8, and
wants
> to tag RBridge-RBridge traffic with "8", then you wind up with two
DRBs
> (one for VLAN 7, and one for VLAN 8). If RB1 tells everyone "use VLAN
7"
> and RB2
> tells everyone "use VLAN 8", then you'll get twice as many Hellos on
the
> link as you'd need.
> So perhaps as an optimization, the RBridges could notice this and if
you
> are DRB for some
> of the VLANs on a cloud, and some other DRB (for a different set of
VLANs
> on the same cloud) is
> telling the RBridges to send Hellos on a different, lower numbered
VLAN,
> then I think it would
> be reasonable to agree to using that VLAN.
> 
> Something that's perhaps a bit subtle, but does indeed work, is to
realize
> what happens if you have
> multiple DRBs as a consequence of load splitting the VLANs. What
happens
> is:
> 
> a) you'll have multiple DRBs, and each DRB will create a different
> pseudonode for that cloud
> 
> b) the pseudonodes will have the same root bridge in the LSP, but with
a
> different, nonoverlapping
> set of VLANs
> 
> c) a multicast packet will not get sent twice on the cloud, because
the
> multicast data packet
> will be (inner) tagged with some VLAN tag, and will only get delivered
to
> the pseudonode that
> includes that VLAN tag.
> 
> Anyway, I'm optimistic at this point that we will converge on either
"VLAN
> 1--nonconfigurable"
> or "single VLAN per layer 2 cloud, but which VLAN is configurable",
but
> that if there really
> is a problem with this, I think a phone call would be the best thing
at
> this point.

"VLAN 1--nonconfigurable" is a non-starter for me, I hope to have
explained why.

"single VLAN per layer 2 cloud" may be workable, but I need to see the
details of the algorithm to see if there are corner cases.

If we can agree to concentrate our focus on a "single VLAN per layer 2
cloud" we have made some progress.

-- Silvano

> Thanks,
> 
> Radia
> 
> ----- Original Message -----
> From: Silvano Gai <[email-masked]>
> Date: Monday, October 29, 2007 3:41 pm
> Subject: RE: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-
> RBridgepackets?
> 
> > Radia,
> >
> > I have redrawn
> > http://www.ip6.com/example.ppt
> >
> > Using more terminology according to your suggestion.
> >
> > Can you rewrite this email using the terminology of the updated
> > > http://www.ip6.com/example.ppt
> >
> > Thank You
> >
> > -- Silvano
> >
> > > -----Original Message-----
> > > From: [email-masked] [[email-masked]]
> > > Sent: Monday, October 29, 2007 1:14 PM
> > > To: Silvano Gai
> > > Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> > > Subject: Re: RE: [rbridge] Final outcome of outer VLAN tags
> > onRBridge-
> > > RBridgepackets?
> > >
> > > Silvano,
> > > Based on your message, I think a lot of the controversy here is
> > simply> miscommunication, which is actually great news.
> > > The VLAN number we have been talking about is solely a local
> > matter on
> > a
> > > single layer 2 cloud. It
> > > is only the outer VLAN number used for RBridge-RBridge
> > communication.>
> > > So looking at your picture, note that we have three separate
> > layer 2
> > > clouds. Let's add "port" numbers,
> > > so that for each of the RBridges, their top port will be called
"x"
> > and
> > > their bottom port would
> > > be called "y".
> > >
> > > Let's call the clouds "G" for the top one (because it is green).
And
> > "L"
> > > for the lower left, and "R" for the
> > > lower right.
> > >
> > > if we went with the "VLAN 1 unconfigurable" strategy, then we'd
have
> > to
> > > tell that customer to open up VLAN 1 on the G cloud and R cloud
(and
> > I'm
> > > sure I'm using the wrong word,
> > > but by "open up", I mean make it so that the RBridges are capable
of
> > > sending and receiving traffic
> > > on VLAN 1, and that VLAN 1 is not partitioned in the green
> > cloud). It
> > > wouldn't cause
> > > the VLANs to get merged or anything like that. It just means that
> > VLAN1
> > > would not be allowed to
> > > be partitioned on any of those 3 clouds, and that the RBridges
> > must be
> > > able to use VLAN 1
> > > to communicate with each other. And it means that all the traffic
> > for> RBridge-RBridge communication
> > > (which consists of IS-IS Hellos, LSP forwarding, and encapsulated
> > > data packet forwarding across the cloud between RBridges)
> > > would be sent with an outer VLAN tag of 1.
> > >
> > > If we instead went with
> > > the "single VLAN, but configurable", then all the RBridges would
be
> > > configured to use, say, VLAN 7
> > > for RBridge-RBridge communication on their "port x" which
> > connects to
> > > cloud G.
> > > RB1 and RB2's "port y" would not need to be configured, since
> > VLAN 1
> > would
> > > already work on the cloud
> > > attached to that port. RB3 and RB4 would need to be configured to
> > use,> say, VLAN 3, on their "y" port (the
> > > one to cloud R).
> > >
> > > Would some number of people like to have a phone call early this
> > weekand
> > > resolve it? I'd hope that
> > > the people would include at least you (Silvano), Dinesh, me,
Anoop,
> > but I
> > > don't mean to exclude anyone.
> > >
> > > Radia
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: Silvano Gai <[email-masked]>
> > > Date: Sunday, October 28, 2007 4:49 am
> > > Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-
> > > RBridgepackets?
> > >
> > > >
> > > > Radia,
> > > >
> > > > Can you explain me if your solution supports the example that I
> > have> > drawn in PowerPoint at:
> > > > http://www.ip6.com/example.ppt
> > > > ?
> > > >
> > > > Thank You
> > > >
> > > > Answering your email:
> > > >
> > > > I have seen customers deploying VLANs in a variety of ways.
> > > >
> > > > Some customers have VLAN 1 end-to-end and they use it for
control
> > and
> > > > data traffic. Some customers use VLAN 1 only for control
traffic.
> > Some
> > > > customers wants all VLANs (including VLAN 1) being local (not
> > > > end-to-end). Some customers prefer to move some control
> > protocol to
> > > > another VLAN. I have seen multiple different approaches.
> > > >
> > > > You ask for rational, "tangible reasons". Each customer has its
> > own> > reasons that don't match the ones of other customers. There
> > are no
> > > > universal tangible reasons, you just need to realize that IEEE
> > 802.1Q
> > > > allows VLANs to be deployed in many different way.  Any solution
> > that
> > > > poses restrictions is going to be OK for some customers and KO
for
> > > > others.
> > > >
> > > > Over the years I have learned to live with the fact that
customers
> > > > havedifferent deployment approaches that are perfectly valid
> > > > because allowed
> > > > by IEEE 802.1Q and by the products.
> > > >
> > > > In TRILL we often speak about plug-and-play. If we consider
> > > > plug-and-play, VLAN 1 is the only one enabled by default and
> > therefore
> > > > it seems a reasonable default solution.
> > > >
> > > > While this is a valid concept in the consumer space, it is
> > absolutely
> > > > not valid in Enterprise/Datacenter. Enterprise/Datacenter
> > customers> > request that all the new boxes are shipped with all
> > the ports
> > > > disabled,because they realized that the switches will be
connected
> > > > in complex
> > > > configurations in which plug-and-play is very dangerous.
> > > >
> > > > I expect the same to be true for RBridges, where customers will
> > > > carefully design, test in a separate environment and bring-up a
> > > > configuration that will match the existing VLAN deployment they
> > have.
> > > >
> > > > Inline for you specific questions:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Radia Perlman [[email-masked]]
> > > > > Sent: Saturday, October 27, 2007 8:59 PM
> > > > > To: Silvano Gai
> > > > > Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> > > > > Subject: Re: [rbridge] Final outcome of outer VLAN tags
> > onRBridge-
> > > > > RBridgepackets?
> > > > >
> > > > > I'm anxious to close on this issue, but
> > > > > Silvano...you always speak in such absolutes: words like
> > > > > "unrealistic" without giving tangible reasons what the
> > > > > problem is. Again, everything is engineering tradeoffs, and we
> > > > have to
> > > > > understand what the specific
> > > > > pros and cons are (not phrases like
> > > > > "won't work" "unrealistic" "not flexible enough", but instead
> > "won't
> > > > allow
> > > > > this *particular* scenario")
> > > > >
> > > > > Question: Is the problem picking specifically VLAN 1 as
> > > > > our chosen single VLAN number? If we picked a different
> > > > (unconfigurable)
> > > > > VLAN number would that be OK?
> > > >
> > > > I think that VLAN 1 is probably our best default choice. I don't
> > > > objectto have VLAN 1 to be the default VLAN.
> > > >
> > > > If so, what number? If you are arguing that
> > > > > it's OK to require one VLAN not to be partitioned, and that
all
> > > > > RBridge-RBridge
> > > > > communication be done over that VLAN, then I really don't
> > > > understand.
> > > > I am not sure what you are asking. If you are speaking of the
> > backbone
> > > > between RBridges, the outer VLAN tag for sure may not be the
same
> > > > end-to-end.
> > > >
> > > > A department of a large corporation may want to deploy RBridges
> > in 5
> > > > different sites. The VLAN they have available from site_1 to
> > site_2> > maybe VLAN 5, form site_1 to site_3 VLAN 7, from site_3
> > to site_4
> > > > VLAN 4.
> > > >
> > > > If you want all this VLANs to be a single VLAN end-to-end,
> > there is
> > a
> > > > significant change that needs to happen in the communication
> > > > infrastructure that may be considered difficult or impossible.
> > > >
> > > > If instead you are discussing the access to the RBridge clouds,
I
> > > > thinkit is reasonable to require that the RBridges that perform
> > TRILL
> > > > encapsulation for an Ethernet Cloud have a common VLAN. VLAN1
may
> > > > be the
> > > > default, but I think that the value should be programmable.
> > > >
> > > >
> > > > > If that were the case, why can't we (TRILL) put a stake in the
> > > > ground> and say "RBridges will
> > > > > use VLAN 1", and if the customer wanted to use VLAN 1 for
> > something
> > > > > else, but was willing
> > > > > to configure RBridges to use, say, VLAN 57, why can't that
> > customer
> > > > > renumber their own
> > > > > VLANs so that they switch their uses of VLAN 57 and VLAN 1,
and
> > let
> > > > the
> > > > > rest of
> > > > > the world have the simplicity of an unconfigurable choice of
> > VLAN1?
> > > >
> > > > I don't think this is acceptable for many customers. You are
> > > > putting a
> > > > stake in the ground that IEEE has never put.
> > > >
> > > > >
> > > > > Are you saying that you don't want to require customers to
have
> > > > *any*> VLAN number that
> > > > > isn't partitioned,
> > > >
> > > > I am not sure what you mean with "*any* VLAN number that isn't
> > > > partitioned", are you speaking of inner VLAN or outer VLAN?
> > > >
> > > > In most installation the numbering spaces of the Backbone VLANs
> > and> > Access VLANs are disjoint. I don't think this is an issue
> > since the
> > > > access VLANs appears in the inner VLAN tag, while the backbone
> > VLANs> > appears in the outer VLAN tag.
> > > >
> > > >
> > > > and you want a solution that somehow finds all
> > > > > possible ways of having
> > > > > RBridges talk to each other using every possible VLAN?
> > > >
> > > > Again, when you are saying "RBridges talk to each other" are you
> > > > speaking of the TRILL encapsulated frames or of the DRB
> > election on
> > > > theaccess?
> > > >
> > > > Again see my example at:
> > > > http://www.ip6.com/example.ppt
> > > >
> > > > -- Silvano
> > >
> >
> >

Date: Mon, 29 Oct 2007 19:46:08 -0700
From: [email-masked]
To: Silvano Gai <[email-masked]>
Priority: normal
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?
Status: RO
Content-Length: 14895

1) I suggested a phone call sometime this week, but it was buried in the end of my message. I'd particularly hope that (at least) you (Silvano), Dinesh, Anoop, me, and Don Eastlake attend, but nobody would be excluded. Send me email with all
your availability for this week (and time zones) and I'll try to pick a time.

2) As for the updated picture, and talking through how I think
it all would work -- I think all the three clouds are completely independent. So I think
we could just as well be talking about a single layer 2 cloud with a bunch of RBridges
attached. But I'll use your picture.

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

First: let's talk through what happens with the "use VLAN 1, no configuration" strategy:

The rule is that on every layer 2 cloud (R, G, and L in your picture), bridges inside each cloud must allow VLAN-1-tagged traffic to pass. That would mean that
VLAN 1 would not partitioned on that cloud. Also every RBridge port must be configured to allow
sending and receiving of VLAN 1 tagged traffic.

The way I read your picture (http://www.ip6.com/example.ppt): As configured, RB3, for
instance, is only able to send/receive frames tagged
with VLANs 2 and 3 on its port Y3, and send/receive VLANs 7 and 8 on its port X3.
(Is that a correct interpretation of your picture?)
So, assuming my interpretation is correct, if you started with an installation configured that
way, then ports X3, Y3, X4, Y4, X1, and X2 would have to be reconfigured to allow use of VLAN 1, and any
bridges in between these ports (e.g., inside cloud G or cloud R), if they were configured to partition VLAN 1,
would have to be configured to allow traffic marked with VLAN 1 to be forwarded.

Consequences of not doing the reconfiguration as just stated are:
If an RBridge R *cannot* send/receive on VLAN 1 on a port, R will not send any Hellos (which might be fine -- perhaps
there are no other RBridges on the link -- just endnodes, but my preference would
be to discourage and possibly
disallow having an RBridge port with VLAN 1 turned off). If VLAN 1 is partitioned on
the cloud, the same consequence happens. R will not
form any RBridge-RBridge adjacencies on that port, so no encapsulated traffic will be forwarded across that cloud. With
the safeguards specified in my earlier emails, R will be conservative about encapsulating/decapsulating data traffic
to/from that link, so that there won't be loops.

If VLAN 1 is not partitioned and all RBridges can send/receive VLAN 1, then everything works very smoothly. Other than
having had to reconfigure things, I don't see what functionality the customer is giving up by allowing RBridges
to talk on VLAN 1.

************************
Now let's talk about the "single VLAN, but we can configure which VLAN it is" strategy:

The customer *could* reconfigure things to allow VLAN 1 for RBridge-RBridge communication, and then
everything would work as above. But if for some reason they wanted to only allow VLANs 7 and 8 in cloud G,
and 2 and 3 in cloud R, then they could do the following:

Ports Y1 and Y2 will not require any configuration -- they already support VLAN 1 (the default).

Ports X1, X2, X3, and X4 would be configured to send Hellos on either VLAN 7 or 8. I'd recommend, if the VLAN
for Hellos is configurable, that you *accept* Hellos on any of the VLANs for which you can receive traffic. Whoever
gets elected DRB (say RB1) specifies, in its Hello, "use VLAN 8", and then X2, X3, and X4, as long as they continue
to receive Hellos from RB1, send their Hellos on VLAN 8. Furthermore, LSPs on cloud G are transmitted tagged with
outer VLAN 8. Encapsulated data traffic being forwarded across cloud G would also have outer VLAN tag of 8.

If RB2 were DRB instead of RB1, and RB2 was configured to transmit on VLAN 7, then it would tell all the RBridges to tag
their RBridge-RBridge traffic with 7. If there are different priorities, say RB1 is DRB for VLAN 7, and wants to
tag RBridge-RBridge traffic with 7,  and RB2 is DRB for VLAN 8, and wants to tag RBridge-RBridge traffic with "8", then you wind up with two DRBs (one for VLAN 7, and one for VLAN 8). If RB1 tells everyone "use VLAN 7" and RB2
tells everyone "use VLAN 8", then you'll get twice as many Hellos on the link as you'd need.
So perhaps as an optimization, the RBridges could notice this and if you are DRB for some
of the VLANs on a cloud, and some other DRB (for a different set of VLANs on the same cloud) is
telling the RBridges to send Hellos on a different, lower numbered VLAN, then I think it would
be reasonable to agree to using that VLAN.

Something that's perhaps a bit subtle, but does indeed work, is to realize what happens if you have
multiple DRBs as a consequence of load splitting the VLANs. What happens is:

a) you'll have multiple DRBs, and each DRB will create a different pseudonode for that cloud

b) the pseudonodes will have the same root bridge in the LSP, but with a different, nonoverlapping
set of VLANs

c) a multicast packet will not get sent twice on the cloud, because the multicast data packet
will be (inner) tagged with some VLAN tag, and will only get delivered to the pseudonode that
includes that VLAN tag.

Anyway, I'm optimistic at this point that we will converge on either "VLAN 1--nonconfigurable"
or "single VLAN per layer 2 cloud, but which VLAN is configurable", but that if there really
is a problem with this, I think a phone call would be the best thing at this point.

Thanks,

Radia

----- Original Message -----
From: Silvano Gai <[email-masked]>
Date: Monday, October 29, 2007 3:41 pm
Subject: RE: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?

> Radia,
> 
> I have redrawn
> http://www.ip6.com/example.ppt
> 
> Using more terminology according to your suggestion.
> 
> Can you rewrite this email using the terminology of the updated
> > http://www.ip6.com/example.ppt
> 
> Thank You
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [email-masked] [[email-masked]]
> > Sent: Monday, October 29, 2007 1:14 PM
> > To: Silvano Gai
> > Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> > Subject: Re: RE: [rbridge] Final outcome of outer VLAN tags 
> onRBridge-
> > RBridgepackets?
> > 
> > Silvano,
> > Based on your message, I think a lot of the controversy here is 
> simply> miscommunication, which is actually great news.
> > The VLAN number we have been talking about is solely a local 
> matter on
> a
> > single layer 2 cloud. It
> > is only the outer VLAN number used for RBridge-RBridge 
> communication.> 
> > So looking at your picture, note that we have three separate 
> layer 2
> > clouds. Let's add "port" numbers,
> > so that for each of the RBridges, their top port will be called "x"
> and
> > their bottom port would
> > be called "y".
> > 
> > Let's call the clouds "G" for the top one (because it is green). And
> "L"
> > for the lower left, and "R" for the
> > lower right.
> > 
> > if we went with the "VLAN 1 unconfigurable" strategy, then we'd have
> to
> > tell that customer to open up VLAN 1 on the G cloud and R cloud (and
> I'm
> > sure I'm using the wrong word,
> > but by "open up", I mean make it so that the RBridges are capable of
> > sending and receiving traffic
> > on VLAN 1, and that VLAN 1 is not partitioned in the green 
> cloud). It
> > wouldn't cause
> > the VLANs to get merged or anything like that. It just means that 
> VLAN1
> > would not be allowed to
> > be partitioned on any of those 3 clouds, and that the RBridges 
> must be
> > able to use VLAN 1
> > to communicate with each other. And it means that all the traffic 
> for> RBridge-RBridge communication
> > (which consists of IS-IS Hellos, LSP forwarding, and encapsulated
> > data packet forwarding across the cloud between RBridges)
> > would be sent with an outer VLAN tag of 1.
> > 
> > If we instead went with
> > the "single VLAN, but configurable", then all the RBridges would be
> > configured to use, say, VLAN 7
> > for RBridge-RBridge communication on their "port x" which 
> connects to
> > cloud G.
> > RB1 and RB2's "port y" would not need to be configured, since 
> VLAN 1
> would
> > already work on the cloud
> > attached to that port. RB3 and RB4 would need to be configured to 
> use,> say, VLAN 3, on their "y" port (the
> > one to cloud R).
> > 
> > Would some number of people like to have a phone call early this 
> weekand
> > resolve it? I'd hope that
> > the people would include at least you (Silvano), Dinesh, me, Anoop,
> but I
> > don't mean to exclude anyone.
> > 
> > Radia
> > 
> > 
> > 
> > ----- Original Message -----
> > From: Silvano Gai <[email-masked]>
> > Date: Sunday, October 28, 2007 4:49 am
> > Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-
> > RBridgepackets?
> > 
> > >
> > > Radia,
> > >
> > > Can you explain me if your solution supports the example that I 
> have> > drawn in PowerPoint at:
> > > http://www.ip6.com/example.ppt
> > > ?
> > >
> > > Thank You
> > >
> > > Answering your email:
> > >
> > > I have seen customers deploying VLANs in a variety of ways.
> > >
> > > Some customers have VLAN 1 end-to-end and they use it for control
> and
> > > data traffic. Some customers use VLAN 1 only for control traffic.
> Some
> > > customers wants all VLANs (including VLAN 1) being local (not
> > > end-to-end). Some customers prefer to move some control 
> protocol to
> > > another VLAN. I have seen multiple different approaches.
> > >
> > > You ask for rational, "tangible reasons". Each customer has its 
> own> > reasons that don't match the ones of other customers. There 
> are no
> > > universal tangible reasons, you just need to realize that IEEE
> 802.1Q
> > > allows VLANs to be deployed in many different way.  Any solution
> that
> > > poses restrictions is going to be OK for some customers and KO for
> > > others.
> > >
> > > Over the years I have learned to live with the fact that customers
> > > havedifferent deployment approaches that are perfectly valid
> > > because allowed
> > > by IEEE 802.1Q and by the products.
> > >
> > > In TRILL we often speak about plug-and-play. If we consider
> > > plug-and-play, VLAN 1 is the only one enabled by default and
> therefore
> > > it seems a reasonable default solution.
> > >
> > > While this is a valid concept in the consumer space, it is
> absolutely
> > > not valid in Enterprise/Datacenter. Enterprise/Datacenter 
> customers> > request that all the new boxes are shipped with all 
> the ports
> > > disabled,because they realized that the switches will be connected
> > > in complex
> > > configurations in which plug-and-play is very dangerous.
> > >
> > > I expect the same to be true for RBridges, where customers will
> > > carefully design, test in a separate environment and bring-up a
> > > configuration that will match the existing VLAN deployment they
> have.
> > >
> > > Inline for you specific questions:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Radia Perlman [[email-masked]]
> > > > Sent: Saturday, October 27, 2007 8:59 PM
> > > > To: Silvano Gai
> > > > Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> > > > Subject: Re: [rbridge] Final outcome of outer VLAN tags 
> onRBridge-
> > > > RBridgepackets?
> > > >
> > > > I'm anxious to close on this issue, but
> > > > Silvano...you always speak in such absolutes: words like
> > > > "unrealistic" without giving tangible reasons what the
> > > > problem is. Again, everything is engineering tradeoffs, and we
> > > have to
> > > > understand what the specific
> > > > pros and cons are (not phrases like
> > > > "won't work" "unrealistic" "not flexible enough", but instead
> "won't
> > > allow
> > > > this *particular* scenario")
> > > >
> > > > Question: Is the problem picking specifically VLAN 1 as
> > > > our chosen single VLAN number? If we picked a different
> > > (unconfigurable)
> > > > VLAN number would that be OK?
> > >
> > > I think that VLAN 1 is probably our best default choice. I don't
> > > objectto have VLAN 1 to be the default VLAN.
> > >
> > > If so, what number? If you are arguing that
> > > > it's OK to require one VLAN not to be partitioned, and that all
> > > > RBridge-RBridge
> > > > communication be done over that VLAN, then I really don't
> > > understand.
> > > I am not sure what you are asking. If you are speaking of the
> backbone
> > > between RBridges, the outer VLAN tag for sure may not be the same
> > > end-to-end.
> > >
> > > A department of a large corporation may want to deploy RBridges 
> in 5
> > > different sites. The VLAN they have available from site_1 to 
> site_2> > maybe VLAN 5, form site_1 to site_3 VLAN 7, from site_3 
> to site_4
> > > VLAN 4.
> > >
> > > If you want all this VLANs to be a single VLAN end-to-end, 
> there is
> a
> > > significant change that needs to happen in the communication
> > > infrastructure that may be considered difficult or impossible.
> > >
> > > If instead you are discussing the access to the RBridge clouds, I
> > > thinkit is reasonable to require that the RBridges that perform
> TRILL
> > > encapsulation for an Ethernet Cloud have a common VLAN. VLAN1 may
> > > be the
> > > default, but I think that the value should be programmable.
> > >
> > >
> > > > If that were the case, why can't we (TRILL) put a stake in the
> > > ground> and say "RBridges will
> > > > use VLAN 1", and if the customer wanted to use VLAN 1 for
> something
> > > > else, but was willing
> > > > to configure RBridges to use, say, VLAN 57, why can't that
> customer
> > > > renumber their own
> > > > VLANs so that they switch their uses of VLAN 57 and VLAN 1, and
> let
> > > the
> > > > rest of
> > > > the world have the simplicity of an unconfigurable choice of 
> VLAN1?
> > >
> > > I don't think this is acceptable for many customers. You are
> > > putting a
> > > stake in the ground that IEEE has never put.
> > >
> > > >
> > > > Are you saying that you don't want to require customers to have
> > > *any*> VLAN number that
> > > > isn't partitioned,
> > >
> > > I am not sure what you mean with "*any* VLAN number that isn't
> > > partitioned", are you speaking of inner VLAN or outer VLAN?
> > >
> > > In most installation the numbering spaces of the Backbone VLANs 
> and> > Access VLANs are disjoint. I don't think this is an issue 
> since the
> > > access VLANs appears in the inner VLAN tag, while the backbone 
> VLANs> > appears in the outer VLAN tag.
> > >
> > >
> > > and you want a solution that somehow finds all
> > > > possible ways of having
> > > > RBridges talk to each other using every possible VLAN?
> > >
> > > Again, when you are saying "RBridges talk to each other" are you
> > > speaking of the TRILL encapsulated frames or of the DRB 
> election on
> > > theaccess?
> > >
> > > Again see my example at:
> > > http://www.ip6.com/example.ppt
> > >
> > > -- Silvano
> > 
> 
> 

Content-class: urn:content-classes:message
Date: Mon, 29 Oct 2007 15:41:12 -0700
From: "Silvano Gai" <[email-masked]>
To: <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?
Status: RO
Content-Length: 8690

Radia,

I have redrawn
http://www.ip6.com/example.ppt

Using more terminology according to your suggestion.

Can you rewrite this email using the terminology of the updated
> http://www.ip6.com/example.ppt

Thank You

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 29, 2007 1:14 PM
> To: Silvano Gai
> Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> Subject: Re: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-
> RBridgepackets?
> 
> Silvano,
> Based on your message, I think a lot of the controversy here is simply
> miscommunication, which is actually great news.
> The VLAN number we have been talking about is solely a local matter on
a
> single layer 2 cloud. It
> is only the outer VLAN number used for RBridge-RBridge communication.
> 
> So looking at your picture, note that we have three separate layer 2
> clouds. Let's add "port" numbers,
> so that for each of the RBridges, their top port will be called "x"
and
> their bottom port would
> be called "y".
> 
> Let's call the clouds "G" for the top one (because it is green). And
"L"
> for the lower left, and "R" for the
> lower right.
> 
> if we went with the "VLAN 1 unconfigurable" strategy, then we'd have
to
> tell that customer to open up VLAN 1 on the G cloud and R cloud (and
I'm
> sure I'm using the wrong word,
> but by "open up", I mean make it so that the RBridges are capable of
> sending and receiving traffic
> on VLAN 1, and that VLAN 1 is not partitioned in the green cloud). It
> wouldn't cause
> the VLANs to get merged or anything like that. It just means that VLAN
1
> would not be allowed to
> be partitioned on any of those 3 clouds, and that the RBridges must be
> able to use VLAN 1
> to communicate with each other. And it means that all the traffic for
> RBridge-RBridge communication
> (which consists of IS-IS Hellos, LSP forwarding, and encapsulated
> data packet forwarding across the cloud between RBridges)
> would be sent with an outer VLAN tag of 1.
> 
> If we instead went with
> the "single VLAN, but configurable", then all the RBridges would be
> configured to use, say, VLAN 7
> for RBridge-RBridge communication on their "port x" which connects to
> cloud G.
> RB1 and RB2's "port y" would not need to be configured, since VLAN 1
would
> already work on the cloud
> attached to that port. RB3 and RB4 would need to be configured to use,
> say, VLAN 3, on their "y" port (the
> one to cloud R).
> 
> Would some number of people like to have a phone call early this week
and
> resolve it? I'd hope that
> the people would include at least you (Silvano), Dinesh, me, Anoop,
but I
> don't mean to exclude anyone.
> 
> Radia
> 
> 
> 
> ----- Original Message -----
> From: Silvano Gai <[email-masked]>
> Date: Sunday, October 28, 2007 4:49 am
> Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-
> RBridgepackets?
> 
> >
> > Radia,
> >
> > Can you explain me if your solution supports the example that I have
> > drawn in PowerPoint at:
> > http://www.ip6.com/example.ppt
> > ?
> >
> > Thank You
> >
> > Answering your email:
> >
> > I have seen customers deploying VLANs in a variety of ways.
> >
> > Some customers have VLAN 1 end-to-end and they use it for control
and
> > data traffic. Some customers use VLAN 1 only for control traffic.
Some
> > customers wants all VLANs (including VLAN 1) being local (not
> > end-to-end). Some customers prefer to move some control protocol to
> > another VLAN. I have seen multiple different approaches.
> >
> > You ask for rational, "tangible reasons". Each customer has its own
> > reasons that don't match the ones of other customers. There are no
> > universal tangible reasons, you just need to realize that IEEE
802.1Q
> > allows VLANs to be deployed in many different way.  Any solution
that
> > poses restrictions is going to be OK for some customers and KO for
> > others.
> >
> > Over the years I have learned to live with the fact that customers
> > havedifferent deployment approaches that are perfectly valid
> > because allowed
> > by IEEE 802.1Q and by the products.
> >
> > In TRILL we often speak about plug-and-play. If we consider
> > plug-and-play, VLAN 1 is the only one enabled by default and
therefore
> > it seems a reasonable default solution.
> >
> > While this is a valid concept in the consumer space, it is
absolutely
> > not valid in Enterprise/Datacenter. Enterprise/Datacenter customers
> > request that all the new boxes are shipped with all the ports
> > disabled,because they realized that the switches will be connected
> > in complex
> > configurations in which plug-and-play is very dangerous.
> >
> > I expect the same to be true for RBridges, where customers will
> > carefully design, test in a separate environment and bring-up a
> > configuration that will match the existing VLAN deployment they
have.
> >
> > Inline for you specific questions:
> >
> >
> > > -----Original Message-----
> > > From: Radia Perlman [[email-masked]]
> > > Sent: Saturday, October 27, 2007 8:59 PM
> > > To: Silvano Gai
> > > Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> > > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-
> > > RBridgepackets?
> > >
> > > I'm anxious to close on this issue, but
> > > Silvano...you always speak in such absolutes: words like
> > > "unrealistic" without giving tangible reasons what the
> > > problem is. Again, everything is engineering tradeoffs, and we
> > have to
> > > understand what the specific
> > > pros and cons are (not phrases like
> > > "won't work" "unrealistic" "not flexible enough", but instead
"won't
> > allow
> > > this *particular* scenario")
> > >
> > > Question: Is the problem picking specifically VLAN 1 as
> > > our chosen single VLAN number? If we picked a different
> > (unconfigurable)
> > > VLAN number would that be OK?
> >
> > I think that VLAN 1 is probably our best default choice. I don't
> > objectto have VLAN 1 to be the default VLAN.
> >
> > If so, what number? If you are arguing that
> > > it's OK to require one VLAN not to be partitioned, and that all
> > > RBridge-RBridge
> > > communication be done over that VLAN, then I really don't
> > understand.
> > I am not sure what you are asking. If you are speaking of the
backbone
> > between RBridges, the outer VLAN tag for sure may not be the same
> > end-to-end.
> >
> > A department of a large corporation may want to deploy RBridges in 5
> > different sites. The VLAN they have available from site_1 to site_2
> > maybe VLAN 5, form site_1 to site_3 VLAN 7, from site_3 to site_4
> > VLAN 4.
> >
> > If you want all this VLANs to be a single VLAN end-to-end, there is
a
> > significant change that needs to happen in the communication
> > infrastructure that may be considered difficult or impossible.
> >
> > If instead you are discussing the access to the RBridge clouds, I
> > thinkit is reasonable to require that the RBridges that perform
TRILL
> > encapsulation for an Ethernet Cloud have a common VLAN. VLAN1 may
> > be the
> > default, but I think that the value should be programmable.
> >
> >
> > > If that were the case, why can't we (TRILL) put a stake in the
> > ground> and say "RBridges will
> > > use VLAN 1", and if the customer wanted to use VLAN 1 for
something
> > > else, but was willing
> > > to configure RBridges to use, say, VLAN 57, why can't that
customer
> > > renumber their own
> > > VLANs so that they switch their uses of VLAN 57 and VLAN 1, and
let
> > the
> > > rest of
> > > the world have the simplicity of an unconfigurable choice of VLAN
1?
> >
> > I don't think this is acceptable for many customers. You are
> > putting a
> > stake in the ground that IEEE has never put.
> >
> > >
> > > Are you saying that you don't want to require customers to have
> > *any*> VLAN number that
> > > isn't partitioned,
> >
> > I am not sure what you mean with "*any* VLAN number that isn't
> > partitioned", are you speaking of inner VLAN or outer VLAN?
> >
> > In most installation the numbering spaces of the Backbone VLANs and
> > Access VLANs are disjoint. I don't think this is an issue since the
> > access VLANs appears in the inner VLAN tag, while the backbone VLANs
> > appears in the outer VLAN tag.
> >
> >
> > and you want a solution that somehow finds all
> > > possible ways of having
> > > RBridges talk to each other using every possible VLAN?
> >
> > Again, when you are saying "RBridges talk to each other" are you
> > speaking of the TRILL encapsulated frames or of the DRB election on
> > theaccess?
> >
> > Again see my example at:
> > http://www.ip6.com/example.ppt
> >
> > -- Silvano
> 

Date: Mon, 29 Oct 2007 13:14:09 -0700
From: [email-masked]
To: Silvano Gai <[email-masked]>
Priority: normal
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?
Status: RO
Content-Length: 7802

Silvano,
Based on your message, I think a lot of the controversy here is simply miscommunication, which is actually great news.
The VLAN number we have been talking about is solely a local matter on a single layer 2 cloud. It
is only the outer VLAN number used for RBridge-RBridge communication.

So looking at your picture, note that we have three separate layer 2 clouds. Let's add "port" numbers,
so that for each of the RBridges, their top port will be called "x" and their bottom port would
be called "y".

Let's call the clouds "G" for the top one (because it is green). And "L" for the lower left, and "R" for the
lower right.

if we went with the "VLAN 1 unconfigurable" strategy, then we'd have to
tell that customer to open up VLAN 1 on the G cloud and R cloud (and I'm sure I'm using the wrong word,
but by "open up", I mean make it so that the RBridges are capable of sending and receiving traffic
on VLAN 1, and that VLAN 1 is not partitioned in the green cloud). It wouldn't cause
the VLANs to get merged or anything like that. It just means that VLAN 1 would not be allowed to
be partitioned on any of those 3 clouds, and that the RBridges must be able to use VLAN 1
to communicate with each other. And it means that all the traffic for RBridge-RBridge communication
(which consists of IS-IS Hellos, LSP forwarding, and encapsulated
data packet forwarding across the cloud between RBridges)
would be sent with an outer VLAN tag of 1.

If we instead went with
the "single VLAN, but configurable", then all the RBridges would be configured to use, say, VLAN 7
for RBridge-RBridge communication on their "port x" which connects to cloud G.
RB1 and RB2's "port y" would not need to be configured, since VLAN 1 would already work on the cloud
attached to that port. RB3 and RB4 would need to be configured to use, say, VLAN 3, on their "y" port (the
one to cloud R).

Would some number of people like to have a phone call early this week and resolve it? I'd hope that
the people would include at least you (Silvano), Dinesh, me, Anoop, but I don't mean to exclude anyone.

Radia

----- Original Message -----
From: Silvano Gai <[email-masked]>
Date: Sunday, October 28, 2007 4:49 am
Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?

> 
> Radia,
> 
> Can you explain me if your solution supports the example that I have
> drawn in PowerPoint at:
> http://www.ip6.com/example.ppt
> ?
> 
> Thank You
> 
> Answering your email:
> 
> I have seen customers deploying VLANs in a variety of ways.
> 
> Some customers have VLAN 1 end-to-end and they use it for control and
> data traffic. Some customers use VLAN 1 only for control traffic. Some
> customers wants all VLANs (including VLAN 1) being local (not
> end-to-end). Some customers prefer to move some control protocol to
> another VLAN. I have seen multiple different approaches.
> 
> You ask for rational, "tangible reasons". Each customer has its own
> reasons that don't match the ones of other customers. There are no
> universal tangible reasons, you just need to realize that IEEE 802.1Q
> allows VLANs to be deployed in many different way.  Any solution that
> poses restrictions is going to be OK for some customers and KO for
> others.
> 
> Over the years I have learned to live with the fact that customers 
> havedifferent deployment approaches that are perfectly valid 
> because allowed
> by IEEE 802.1Q and by the products.
> 
> In TRILL we often speak about plug-and-play. If we consider
> plug-and-play, VLAN 1 is the only one enabled by default and therefore
> it seems a reasonable default solution.
> 
> While this is a valid concept in the consumer space, it is absolutely
> not valid in Enterprise/Datacenter. Enterprise/Datacenter customers
> request that all the new boxes are shipped with all the ports 
> disabled,because they realized that the switches will be connected 
> in complex
> configurations in which plug-and-play is very dangerous. 
> 
> I expect the same to be true for RBridges, where customers will
> carefully design, test in a separate environment and bring-up a
> configuration that will match the existing VLAN deployment they have.
> 
> Inline for you specific questions:
> 
> 
> > -----Original Message-----
> > From: Radia Perlman [[email-masked]]
> > Sent: Saturday, October 27, 2007 8:59 PM
> > To: Silvano Gai
> > Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-
> > RBridgepackets?
> > 
> > I'm anxious to close on this issue, but
> > Silvano...you always speak in such absolutes: words like
> > "unrealistic" without giving tangible reasons what the
> > problem is. Again, everything is engineering tradeoffs, and we 
> have to
> > understand what the specific
> > pros and cons are (not phrases like
> > "won't work" "unrealistic" "not flexible enough", but instead "won't
> allow
> > this *particular* scenario")
> > 
> > Question: Is the problem picking specifically VLAN 1 as
> > our chosen single VLAN number? If we picked a different
> (unconfigurable)
> > VLAN number would that be OK? 
> 
> I think that VLAN 1 is probably our best default choice. I don't 
> objectto have VLAN 1 to be the default VLAN.
> 
> If so, what number? If you are arguing that
> > it's OK to require one VLAN not to be partitioned, and that all
> > RBridge-RBridge
> > communication be done over that VLAN, then I really don't 
> understand.
> I am not sure what you are asking. If you are speaking of the backbone
> between RBridges, the outer VLAN tag for sure may not be the same
> end-to-end.
> 
> A department of a large corporation may want to deploy RBridges in 5
> different sites. The VLAN they have available from site_1 to site_2 
> maybe VLAN 5, form site_1 to site_3 VLAN 7, from site_3 to site_4 
> VLAN 4.
> 
> If you want all this VLANs to be a single VLAN end-to-end, there is a
> significant change that needs to happen in the communication
> infrastructure that may be considered difficult or impossible.
> 
> If instead you are discussing the access to the RBridge clouds, I 
> thinkit is reasonable to require that the RBridges that perform TRILL
> encapsulation for an Ethernet Cloud have a common VLAN. VLAN1 may 
> be the
> default, but I think that the value should be programmable.
> 
> 
> > If that were the case, why can't we (TRILL) put a stake in the 
> ground> and say "RBridges will
> > use VLAN 1", and if the customer wanted to use VLAN 1 for something
> > else, but was willing
> > to configure RBridges to use, say, VLAN 57, why can't that customer
> > renumber their own
> > VLANs so that they switch their uses of VLAN 57 and VLAN 1, and let
> the
> > rest of
> > the world have the simplicity of an unconfigurable choice of VLAN 1?
> 
> I don't think this is acceptable for many customers. You are 
> putting a
> stake in the ground that IEEE has never put.
> 
> > 
> > Are you saying that you don't want to require customers to have 
> *any*> VLAN number that
> > isn't partitioned, 
> 
> I am not sure what you mean with "*any* VLAN number that isn't
> partitioned", are you speaking of inner VLAN or outer VLAN?
> 
> In most installation the numbering spaces of the Backbone VLANs and
> Access VLANs are disjoint. I don't think this is an issue since the
> access VLANs appears in the inner VLAN tag, while the backbone VLANs
> appears in the outer VLAN tag.
> 
> 
> and you want a solution that somehow finds all
> > possible ways of having
> > RBridges talk to each other using every possible VLAN? 
> 
> Again, when you are saying "RBridges talk to each other" are you
> speaking of the TRILL encapsulated frames or of the DRB election on 
> theaccess?
> 
> Again see my example at:
> http://www.ip6.com/example.ppt
> 
> -- Silvano

Content-class: urn:content-classes:message
Date: Sun, 28 Oct 2007 15:55:21 -0500
From: "Eric Gray" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
Status: RO
Content-Length: 11058

Donald,

	The issue with excessively large hello messages because 
of multiple per-VLAN priorities doesn't come up if you don't 
have hello messages with information about more than one VLAN.

	So, IMO, it looks like you are wrong in saying there's
"currently no provision for fragmenting Hellos."  It seems as
if it is simply more like some people are talking about it one
way and others are talking about it another.

	It looks as if - by trying to address a possible scale
issue that might very well be unrealistic - we have invented
a problem and are now dreaming up all kinds of neat and cool
ways to solve it.  Let's just un-invent it...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[email-masked]] 
> Sent: Sunday, October 28, 2007 4:02 PM
> To: Eric Gray
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] A "multiple VLAN Hello" proposal
> Importance: High
> 
> Eric,
> 
> There is currently no provision for fragmenting Hellos. If different
> Rbridges are gong to have different priorities for becoming DRB for
> different VLANs the current IS-IS election style would say that that
> information has to go into the Hello PDUs. If bits maps are 
> better than
> ranges, we could use those.
> 
> Donald
> 
> -----Original Message-----
> From: Eric Gray [mailto:[email-masked]] 
> Sent: Sunday, October 28, 2007 1:29 PM
> To: Radia Perlman; Eastlake III Donald-LDE008
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] A "multiple VLAN Hello" proposal
> 
> Radia,
> 
> 	Using sets of VLANs as a range of values is likely to force
> sub-optimality on load-sharing - possibly to the extent that load
> sharing becomes useless.
> 
> 	It is not a trivial exercise to make VLAN topologies line up
> conveniently with VLAN ID assignments.  In fact, assuming that it
> is possible to modify VLAN topologies, it's most likely infeasible
> to do so in some scenarios.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Radia Perlman
> > Sent: Friday, October 26, 2007 1:26 AM
> > To: Eastlake III Donald-LDE008
> > Cc: Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
> > 
> > Right...I was not intending to preclude having R1 be DRB 
> for (inner) 
> > VLANs (v1, v2, v3) and
> > R2 be DRB for (inner) VLANs (v4, v5, v6). However, as you 
> > point out, if 
> > each RBridge can
> > be configured with a different priority for each of the 4000 
> > VLANs, the 
> > IS-IS Hello would
> > get too large. The only reason for different priorities is 
> to do some 
> > load splitting. I'd argue
> > that with just a tiny bit of flexibility customers can get enough 
> > functionality. So I'd suggest
> > limiting multiple priorities to some reasonable number, like 
> > 3, and sets 
> > of VLANs to ranges.
> > That would mean that R1 can claim to have priority P1 for the 
> > VLANs in 
> > range (n1-n2), and
> > priority P2 for the VLANs in range (n3-n4), and priority P3 
> for VLANs 
> > betwen (n5-n6).
> > This would require (for 3 different priorities) 18 bytes in 
> > the Hello. 
> > For instance, "I have
> > priority 7 for VLANs (1-50) and priority 12 for VLANs (61-80), and 
> > priority 2 for
> > VLANs (101-115). Perhaps another 500 bytes to do a bit mask 
> > of all the 
> > VLANs that
> > you support at all (or alternatively you can't claim to have 
> > a priority 
> > for a range of VLANs unless
> > you support all the VLANs in that range).
> > 
> > Likewise, in the pseudonode, we'd have to say the range of 
> VLANs that 
> > that pseudonode
> > refers to.
> > 
> > And it's NOT a DRB collision if there is a pseudonode, say R1,17,
> > for which R1 is DRB, reporting root bridge X
> > and R2 is DRB on a link with root bridge X as long as the set 
> > of VLANs 
> > reported
> > in R1.17's LSP does not overlap with the set of VLANs that R2 
> > is DRB for 
> > on that link.
> > 
> > And actually, R2 really only needs to decline to forward 
> data (act as 
> > DRB) for the set of
> > VLANs in R1.17's pseudonode that overlaps with R2's. It could 
> > be that R2 
> > has some
> > other VLANs that are not in R1.17's pseudonode.
> > 
> > So that's an additional refinement on the rules that should 
> be added.
> > 
> > Perhaps we should start a different thread on whether 
> people can live 
> > with having a single
> > DRB be configured with at most 3 priorities on a port, and 
> > require the 
> > set of VLANs for
> > each priority to be expressible in a range (rather than having to 
> > enumerate each of the
> > VLAN tags individually).
> > 
> > Radia
> > 
> > 
> > 
> > Eastlake III Donald-LDE008 wrote:
> > > Hi Radia,
> > >
> > > The proposal below appears to be written from the "one 
> DRB per link"
> > > point of view while the current draft claims to support 
> "one DRB per
> > > VLAN per link". Even if you have complete VLAN 1 
> > connectivity and use
> > > single Hellos, I'm not quite sure how the one DRB per 
> VLAN per link
> > > would work. In principle, the per VLAN priority for a 
> > Rbridge port for
> > > all its configured VLANs might not fit into a Hello...
> > >
> > > Thanks,
> > > Donald
> > >
> > > -----Original Message-----
> > > From: [email-masked] 
> > [mailto:[email-masked]] On
> > > Behalf Of Radia Perlman
> > > Sent: Thursday, October 25, 2007 2:56 PM
> > > To: Developing a hybrid router/bridge.
> > > Subject: [rbridge] A "multiple VLAN Hello" proposal
> > >
> > > It's a bit difficult to argue on the list about proposals 
> > when one of 
> > > them has not been specified, especially
> > > since I can imagine lots of variations on multiple VLANs, 
> > and lots of 
> > > questions about choices for
> > > the details.
> > >
> > > Here's an attempt to specify a "send Hellos on multiple 
> > VLANs" proposal.
> > >
> > > I've chosen details
> > > where in many cases there are other options I could have 
> > chosen. But I 
> > > think we need some
> > > tangible proposal with details worked out before 
> advocating for it. 
> > > People should feel free
> > > to suggest modifications to the details below, but I, as I 
> > said, cannot 
> > > argue between proposals
> > > if the proposals aren't concrete. I've tried to make it as 
> > simple as 
> > > possible, as low overhead
> > > as possible, while adding the ability to configure sending 
> > Hellos on 
> > > lots of VLANs.
> > >
> > >
> > > a) RBridges send and receive IS-IS Hellos on VLAN 1
> > >
> > > b) In addition, RBridges MAY be configured to send and 
> > receive Hellos on
> > >
> > > some set of
> > > VLANs in addition to 1
> > >
> > > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all 
> > the VLANs that 
> > > R1 is
> > > configured to send (and receive) on. To clarify, as long as 
> > R1 thinks 
> > > itself is DRB, it will
> > > send Hellos on the complete set of VLANs that R1 is 
> > configured to send 
> > > on. In addition (see
> > > point "e"), R1 may wind up having to send Hellos on some 
> > set of VLANs in
> > >
> > > addition
> > > to those it was configured to send on.
> > >
> > > d) In IS-IS's Hello, R1 reports the set of neighbor 
> RBridges R1 has 
> > > heard Hellos from. In addition,
> > > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN 
> > that R1 hears
> > >
> > > hellos from R2 on.
> > > The one VLAN that R1 reports is the lowest numbered VLAN 
> > that R1 hears a
> > >
> > > Hello from R2 on.
> > >
> > > e) If R1 does not hear a Hello from R2 on any of R1's 
> > configured VLANs,
> > > but does hear on some other VLAN, say VLAN x, then R1 adds 
> > "x" to the 
> > > set of VLANs that
> > > R1 transmits on, as long as it continues to hear Hellos on 
> > VLAN x (and
> > > no
> > > other VLANs) from R2. Note that if R2's Hello gives R2 
> > better priority
> > > for
> > > being DRB, then R1 will not be DRB any more, but MUST 
> > continue sending 
> > > Hellos on
> > > VLAN x (even though x is not in the set of VLANs
> > > that R1 was configured to send on) to ensure that R2 
> > continues to send 
> > > its Hellos on VLAN x.
> > >
> > > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus 
> > the VLAN 
> > > that the DRB reports
> > > that it has heard from you on. This cuts down on Hellos 
> > since it means 
> > > that non-DRB RBridges
> > > will send on at most two VLANs.
> > > {Note: An alternate option would have had every RBridge 
> send Hellos 
> > > always on all VLANs they
> > > have been configured to send on}.
> > >
> > > f) all RBridge-RBridge traffic (other than Hellos) is 
> > always sent on 
> > > VLAN 1. So if R2 cannot
> > > reach the DRB via VLAN 1, then R2 cannot forward data 
> to/from that 
> > > cloud, or receive
> > > LSPs on that cloud. In other words, that link will be 
> > broken for R2. The
> > >
> > > purpose
> > > of the Hellos is only to notice (through a means *in 
> > addition* to the 
> > > safeguards in the other
> > > proposals)  that R2 is not DRB for the link.
> > >
> > > g) We do the same safeguards as in the other proposals (report the
> > > bridge root ID in the pseudonode LSP, don't decapsulate 
> > from ingress Ra 
> > > unless
> > > you have all the relevant pseudonode LSPs attached to Ra to 
> > ensure that 
> > > none of them have
> > > the same root RBridge, and that you delay before 
> > encapsulating data off 
> > > the link until you've
> > > been DRB for enough time to synchronize LSP databases with your
> > > neighbors)
> > >
> > > **************
> > > My thoughts on this:
> > >
> > > a) I assume the only reason to send Hellos on multiple 
> VLANs is to 
> > > minimize the probability
> > > of accidentally having two DRBs, and therefore loops. I'm 
> > not convinced 
> > > this adds safety
> > > over the safeguards in the single VLAN proposals.
> > >
> > > b) this winds up with sending lots more Hellos, but does 
> not create 
> > > additional pseudonodes,
> > > or complicate data forwarding, because the Hellos is only to find 
> > > neighbors, not to repair
> > > use of the link for forwarding data (or propagating LSPs) 
> > if VLAN 1 is 
> > > partitioned on the link
> > >
> > > c) This is a lot more complicated. It might seem simpler to 
> > not try to 
> > > optimize the number of
> > > Hellos (like I did in point e), but there seem to be scary 
> > corner cases 
> > > where all the VLANs
> > > common to R1 and R2 are partitioned. Saying there must be an 
> > > unpartitioned VLAN 1 seems
> > > the safest.
> > >
> > > So, I still like the "just use VLAN 1" proposal.
> > > _______________________________________________
> > > rbridge mailing list
> > > [email-masked]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > >   
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 

Content-class: urn:content-classes:message
Date: Sun, 28 Oct 2007 13:45:24 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "Eric Gray" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
Status: RO
Content-Length: 10644

Donald,

We need to face the reality that the only solution that works is to send
a Hello per VLAN.

We are in the version one of the protocol, we should use well know
solutions and look at optimizations in future versions, when we have
implementation experience.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Sunday, October 28, 2007 1:02 PM
> To: Eric Gray
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
> 
> Eric,
> 
> There is currently no provision for fragmenting Hellos. If different
> Rbridges are gong to have different priorities for becoming DRB for
> different VLANs the current IS-IS election style would say that that
> information has to go into the Hello PDUs. If bits maps are better
than
> ranges, we could use those.
> 
> Donald
> 
> -----Original Message-----
> From: Eric Gray [mailto:[email-masked]]
> Sent: Sunday, October 28, 2007 1:29 PM
> To: Radia Perlman; Eastlake III Donald-LDE008
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] A "multiple VLAN Hello" proposal
> 
> Radia,
> 
> 	Using sets of VLANs as a range of values is likely to force
> sub-optimality on load-sharing - possibly to the extent that load
> sharing becomes useless.
> 
> 	It is not a trivial exercise to make VLAN topologies line up
> conveniently with VLAN ID assignments.  In fact, assuming that it
> is possible to modify VLAN topologies, it's most likely infeasible
> to do so in some scenarios.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Radia Perlman
> > Sent: Friday, October 26, 2007 1:26 AM
> > To: Eastlake III Donald-LDE008
> > Cc: Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
> >
> > Right...I was not intending to preclude having R1 be DRB for (inner)
> > VLANs (v1, v2, v3) and
> > R2 be DRB for (inner) VLANs (v4, v5, v6). However, as you
> > point out, if
> > each RBridge can
> > be configured with a different priority for each of the 4000
> > VLANs, the
> > IS-IS Hello would
> > get too large. The only reason for different priorities is to do
some
> > load splitting. I'd argue
> > that with just a tiny bit of flexibility customers can get enough
> > functionality. So I'd suggest
> > limiting multiple priorities to some reasonable number, like
> > 3, and sets
> > of VLANs to ranges.
> > That would mean that R1 can claim to have priority P1 for the
> > VLANs in
> > range (n1-n2), and
> > priority P2 for the VLANs in range (n3-n4), and priority P3 for
VLANs
> > betwen (n5-n6).
> > This would require (for 3 different priorities) 18 bytes in
> > the Hello.
> > For instance, "I have
> > priority 7 for VLANs (1-50) and priority 12 for VLANs (61-80), and
> > priority 2 for
> > VLANs (101-115). Perhaps another 500 bytes to do a bit mask
> > of all the
> > VLANs that
> > you support at all (or alternatively you can't claim to have
> > a priority
> > for a range of VLANs unless
> > you support all the VLANs in that range).
> >
> > Likewise, in the pseudonode, we'd have to say the range of VLANs
that
> > that pseudonode
> > refers to.
> >
> > And it's NOT a DRB collision if there is a pseudonode, say R1,17,
> > for which R1 is DRB, reporting root bridge X
> > and R2 is DRB on a link with root bridge X as long as the set
> > of VLANs
> > reported
> > in R1.17's LSP does not overlap with the set of VLANs that R2
> > is DRB for
> > on that link.
> >
> > And actually, R2 really only needs to decline to forward data (act
as
> > DRB) for the set of
> > VLANs in R1.17's pseudonode that overlaps with R2's. It could
> > be that R2
> > has some
> > other VLANs that are not in R1.17's pseudonode.
> >
> > So that's an additional refinement on the rules that should be
added.
> >
> > Perhaps we should start a different thread on whether people can
live
> > with having a single
> > DRB be configured with at most 3 priorities on a port, and
> > require the
> > set of VLANs for
> > each priority to be expressible in a range (rather than having to
> > enumerate each of the
> > VLAN tags individually).
> >
> > Radia
> >
> >
> >
> > Eastlake III Donald-LDE008 wrote:
> > > Hi Radia,
> > >
> > > The proposal below appears to be written from the "one DRB per
link"
> > > point of view while the current draft claims to support "one DRB
per
> > > VLAN per link". Even if you have complete VLAN 1
> > connectivity and use
> > > single Hellos, I'm not quite sure how the one DRB per VLAN per
link
> > > would work. In principle, the per VLAN priority for a
> > Rbridge port for
> > > all its configured VLANs might not fit into a Hello...
> > >
> > > Thanks,
> > > Donald
> > >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]] On
> > > Behalf Of Radia Perlman
> > > Sent: Thursday, October 25, 2007 2:56 PM
> > > To: Developing a hybrid router/bridge.
> > > Subject: [rbridge] A "multiple VLAN Hello" proposal
> > >
> > > It's a bit difficult to argue on the list about proposals
> > when one of
> > > them has not been specified, especially
> > > since I can imagine lots of variations on multiple VLANs,
> > and lots of
> > > questions about choices for
> > > the details.
> > >
> > > Here's an attempt to specify a "send Hellos on multiple
> > VLANs" proposal.
> > >
> > > I've chosen details
> > > where in many cases there are other options I could have
> > chosen. But I
> > > think we need some
> > > tangible proposal with details worked out before advocating for
it.
> > > People should feel free
> > > to suggest modifications to the details below, but I, as I
> > said, cannot
> > > argue between proposals
> > > if the proposals aren't concrete. I've tried to make it as
> > simple as
> > > possible, as low overhead
> > > as possible, while adding the ability to configure sending
> > Hellos on
> > > lots of VLANs.
> > >
> > >
> > > a) RBridges send and receive IS-IS Hellos on VLAN 1
> > >
> > > b) In addition, RBridges MAY be configured to send and
> > receive Hellos on
> > >
> > > some set of
> > > VLANs in addition to 1
> > >
> > > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all
> > the VLANs that
> > > R1 is
> > > configured to send (and receive) on. To clarify, as long as
> > R1 thinks
> > > itself is DRB, it will
> > > send Hellos on the complete set of VLANs that R1 is
> > configured to send
> > > on. In addition (see
> > > point "e"), R1 may wind up having to send Hellos on some
> > set of VLANs in
> > >
> > > addition
> > > to those it was configured to send on.
> > >
> > > d) In IS-IS's Hello, R1 reports the set of neighbor RBridges R1
has
> > > heard Hellos from. In addition,
> > > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN
> > that R1 hears
> > >
> > > hellos from R2 on.
> > > The one VLAN that R1 reports is the lowest numbered VLAN
> > that R1 hears a
> > >
> > > Hello from R2 on.
> > >
> > > e) If R1 does not hear a Hello from R2 on any of R1's
> > configured VLANs,
> > > but does hear on some other VLAN, say VLAN x, then R1 adds
> > "x" to the
> > > set of VLANs that
> > > R1 transmits on, as long as it continues to hear Hellos on
> > VLAN x (and
> > > no
> > > other VLANs) from R2. Note that if R2's Hello gives R2
> > better priority
> > > for
> > > being DRB, then R1 will not be DRB any more, but MUST
> > continue sending
> > > Hellos on
> > > VLAN x (even though x is not in the set of VLANs
> > > that R1 was configured to send on) to ensure that R2
> > continues to send
> > > its Hellos on VLAN x.
> > >
> > > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus
> > the VLAN
> > > that the DRB reports
> > > that it has heard from you on. This cuts down on Hellos
> > since it means
> > > that non-DRB RBridges
> > > will send on at most two VLANs.
> > > {Note: An alternate option would have had every RBridge send
Hellos
> > > always on all VLANs they
> > > have been configured to send on}.
> > >
> > > f) all RBridge-RBridge traffic (other than Hellos) is
> > always sent on
> > > VLAN 1. So if R2 cannot
> > > reach the DRB via VLAN 1, then R2 cannot forward data to/from that
> > > cloud, or receive
> > > LSPs on that cloud. In other words, that link will be
> > broken for R2. The
> > >
> > > purpose
> > > of the Hellos is only to notice (through a means *in
> > addition* to the
> > > safeguards in the other
> > > proposals)  that R2 is not DRB for the link.
> > >
> > > g) We do the same safeguards as in the other proposals (report the
> > > bridge root ID in the pseudonode LSP, don't decapsulate
> > from ingress Ra
> > > unless
> > > you have all the relevant pseudonode LSPs attached to Ra to
> > ensure that
> > > none of them have
> > > the same root RBridge, and that you delay before
> > encapsulating data off
> > > the link until you've
> > > been DRB for enough time to synchronize LSP databases with your
> > > neighbors)
> > >
> > > **************
> > > My thoughts on this:
> > >
> > > a) I assume the only reason to send Hellos on multiple VLANs is to
> > > minimize the probability
> > > of accidentally having two DRBs, and therefore loops. I'm
> > not convinced
> > > this adds safety
> > > over the safeguards in the single VLAN proposals.
> > >
> > > b) this winds up with sending lots more Hellos, but does not
create
> > > additional pseudonodes,
> > > or complicate data forwarding, because the Hellos is only to find
> > > neighbors, not to repair
> > > use of the link for forwarding data (or propagating LSPs)
> > if VLAN 1 is
> > > partitioned on the link
> > >
> > > c) This is a lot more complicated. It might seem simpler to
> > not try to
> > > optimize the number of
> > > Hellos (like I did in point e), but there seem to be scary
> > corner cases
> > > where all the VLANs
> > > common to R1 and R2 are partitioned. Saying there must be an
> > > unpartitioned VLAN 1 seems
> > > the safest.
> > >
> > > So, I still like the "just use VLAN 1" proposal.
> > > _______________________________________________
> > > rbridge mailing list
> > > [email-masked]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> >
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Sun, 28 Oct 2007 13:41:45 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eric Gray" <[email-masked]>, "Radia Perlman" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
Status: RO
Content-Length: 9844

I agree with Eric,
VLAN range is not widely deployed today.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Eric Gray
> Sent: Sunday, October 28, 2007 10:29 AM
> To: Radia Perlman; Eastlake III Donald-LDE008
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
> 
> Radia,
> 
> 	Using sets of VLANs as a range of values is likely to force
> sub-optimality on load-sharing - possibly to the extent that load
> sharing becomes useless.
> 
> 	It is not a trivial exercise to make VLAN topologies line up
> conveniently with VLAN ID assignments.  In fact, assuming that it
> is possible to modify VLAN topologies, it's most likely infeasible
> to do so in some scenarios.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Radia Perlman
> > Sent: Friday, October 26, 2007 1:26 AM
> > To: Eastlake III Donald-LDE008
> > Cc: Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
> >
> > Right...I was not intending to preclude having R1 be DRB for (inner)
> > VLANs (v1, v2, v3) and
> > R2 be DRB for (inner) VLANs (v4, v5, v6). However, as you
> > point out, if
> > each RBridge can
> > be configured with a different priority for each of the 4000
> > VLANs, the
> > IS-IS Hello would
> > get too large. The only reason for different priorities is to do
some
> > load splitting. I'd argue
> > that with just a tiny bit of flexibility customers can get enough
> > functionality. So I'd suggest
> > limiting multiple priorities to some reasonable number, like
> > 3, and sets
> > of VLANs to ranges.
> > That would mean that R1 can claim to have priority P1 for the
> > VLANs in
> > range (n1-n2), and
> > priority P2 for the VLANs in range (n3-n4), and priority P3 for
VLANs
> > betwen (n5-n6).
> > This would require (for 3 different priorities) 18 bytes in
> > the Hello.
> > For instance, "I have
> > priority 7 for VLANs (1-50) and priority 12 for VLANs (61-80), and
> > priority 2 for
> > VLANs (101-115). Perhaps another 500 bytes to do a bit mask
> > of all the
> > VLANs that
> > you support at all (or alternatively you can't claim to have
> > a priority
> > for a range of VLANs unless
> > you support all the VLANs in that range).
> >
> > Likewise, in the pseudonode, we'd have to say the range of VLANs
that
> > that pseudonode
> > refers to.
> >
> > And it's NOT a DRB collision if there is a pseudonode, say R1,17,
> > for which R1 is DRB, reporting root bridge X
> > and R2 is DRB on a link with root bridge X as long as the set
> > of VLANs
> > reported
> > in R1.17's LSP does not overlap with the set of VLANs that R2
> > is DRB for
> > on that link.
> >
> > And actually, R2 really only needs to decline to forward data (act
as
> > DRB) for the set of
> > VLANs in R1.17's pseudonode that overlaps with R2's. It could
> > be that R2
> > has some
> > other VLANs that are not in R1.17's pseudonode.
> >
> > So that's an additional refinement on the rules that should be
added.
> >
> > Perhaps we should start a different thread on whether people can
live
> > with having a single
> > DRB be configured with at most 3 priorities on a port, and
> > require the
> > set of VLANs for
> > each priority to be expressible in a range (rather than having to
> > enumerate each of the
> > VLAN tags individually).
> >
> > Radia
> >
> >
> >
> > Eastlake III Donald-LDE008 wrote:
> > > Hi Radia,
> > >
> > > The proposal below appears to be written from the "one DRB per
link"
> > > point of view while the current draft claims to support "one DRB
per
> > > VLAN per link". Even if you have complete VLAN 1
> > connectivity and use
> > > single Hellos, I'm not quite sure how the one DRB per VLAN per
link
> > > would work. In principle, the per VLAN priority for a
> > Rbridge port for
> > > all its configured VLANs might not fit into a Hello...
> > >
> > > Thanks,
> > > Donald
> > >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]] On
> > > Behalf Of Radia Perlman
> > > Sent: Thursday, October 25, 2007 2:56 PM
> > > To: Developing a hybrid router/bridge.
> > > Subject: [rbridge] A "multiple VLAN Hello" proposal
> > >
> > > It's a bit difficult to argue on the list about proposals
> > when one of
> > > them has not been specified, especially
> > > since I can imagine lots of variations on multiple VLANs,
> > and lots of
> > > questions about choices for
> > > the details.
> > >
> > > Here's an attempt to specify a "send Hellos on multiple
> > VLANs" proposal.
> > >
> > > I've chosen details
> > > where in many cases there are other options I could have
> > chosen. But I
> > > think we need some
> > > tangible proposal with details worked out before advocating for
it.
> > > People should feel free
> > > to suggest modifications to the details below, but I, as I
> > said, cannot
> > > argue between proposals
> > > if the proposals aren't concrete. I've tried to make it as
> > simple as
> > > possible, as low overhead
> > > as possible, while adding the ability to configure sending
> > Hellos on
> > > lots of VLANs.
> > >
> > >
> > > a) RBridges send and receive IS-IS Hellos on VLAN 1
> > >
> > > b) In addition, RBridges MAY be configured to send and
> > receive Hellos on
> > >
> > > some set of
> > > VLANs in addition to 1
> > >
> > > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all
> > the VLANs that
> > > R1 is
> > > configured to send (and receive) on. To clarify, as long as
> > R1 thinks
> > > itself is DRB, it will
> > > send Hellos on the complete set of VLANs that R1 is
> > configured to send
> > > on. In addition (see
> > > point "e"), R1 may wind up having to send Hellos on some
> > set of VLANs in
> > >
> > > addition
> > > to those it was configured to send on.
> > >
> > > d) In IS-IS's Hello, R1 reports the set of neighbor RBridges R1
has
> > > heard Hellos from. In addition,
> > > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN
> > that R1 hears
> > >
> > > hellos from R2 on.
> > > The one VLAN that R1 reports is the lowest numbered VLAN
> > that R1 hears a
> > >
> > > Hello from R2 on.
> > >
> > > e) If R1 does not hear a Hello from R2 on any of R1's
> > configured VLANs,
> > > but does hear on some other VLAN, say VLAN x, then R1 adds
> > "x" to the
> > > set of VLANs that
> > > R1 transmits on, as long as it continues to hear Hellos on
> > VLAN x (and
> > > no
> > > other VLANs) from R2. Note that if R2's Hello gives R2
> > better priority
> > > for
> > > being DRB, then R1 will not be DRB any more, but MUST
> > continue sending
> > > Hellos on
> > > VLAN x (even though x is not in the set of VLANs
> > > that R1 was configured to send on) to ensure that R2
> > continues to send
> > > its Hellos on VLAN x.
> > >
> > > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus
> > the VLAN
> > > that the DRB reports
> > > that it has heard from you on. This cuts down on Hellos
> > since it means
> > > that non-DRB RBridges
> > > will send on at most two VLANs.
> > > {Note: An alternate option would have had every RBridge send
Hellos
> > > always on all VLANs they
> > > have been configured to send on}.
> > >
> > > f) all RBridge-RBridge traffic (other than Hellos) is
> > always sent on
> > > VLAN 1. So if R2 cannot
> > > reach the DRB via VLAN 1, then R2 cannot forward data to/from that
> > > cloud, or receive
> > > LSPs on that cloud. In other words, that link will be
> > broken for R2. The
> > >
> > > purpose
> > > of the Hellos is only to notice (through a means *in
> > addition* to the
> > > safeguards in the other
> > > proposals)  that R2 is not DRB for the link.
> > >
> > > g) We do the same safeguards as in the other proposals (report the
> > > bridge root ID in the pseudonode LSP, don't decapsulate
> > from ingress Ra
> > > unless
> > > you have all the relevant pseudonode LSPs attached to Ra to
> > ensure that
> > > none of them have
> > > the same root RBridge, and that you delay before
> > encapsulating data off
> > > the link until you've
> > > been DRB for enough time to synchronize LSP databases with your
> > > neighbors)
> > >
> > > **************
> > > My thoughts on this:
> > >
> > > a) I assume the only reason to send Hellos on multiple VLANs is to
> > > minimize the probability
> > > of accidentally having two DRBs, and therefore loops. I'm
> > not convinced
> > > this adds safety
> > > over the safeguards in the single VLAN proposals.
> > >
> > > b) this winds up with sending lots more Hellos, but does not
create
> > > additional pseudonodes,
> > > or complicate data forwarding, because the Hellos is only to find
> > > neighbors, not to repair
> > > use of the link for forwarding data (or propagating LSPs)
> > if VLAN 1 is
> > > partitioned on the link
> > >
> > > c) This is a lot more complicated. It might seem simpler to
> > not try to
> > > optimize the number of
> > > Hellos (like I did in point e), but there seem to be scary
> > corner cases
> > > where all the VLANs
> > > common to R1 and R2 are partitioned. Saying there must be an
> > > unpartitioned VLAN 1 seems
> > > the safest.
> > >
> > > So, I still like the "just use VLAN 1" proposal.
> > > _______________________________________________
> > > rbridge mailing list
> > > [email-masked]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> >
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Sun, 28 Oct 2007 16:02:06 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Eric Gray" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
Status: RO
Content-Length: 9449

Eric,

There is currently no provision for fragmenting Hellos. If different
Rbridges are gong to have different priorities for becoming DRB for
different VLANs the current IS-IS election style would say that that
information has to go into the Hello PDUs. If bits maps are better than
ranges, we could use those.

Donald

-----Original Message-----
From: Eric Gray [mailto:[email-masked]] 
Sent: Sunday, October 28, 2007 1:29 PM
To: Radia Perlman; Eastlake III Donald-LDE008
Cc: Developing a hybrid router/bridge.
Subject: RE: [rbridge] A "multiple VLAN Hello" proposal

Radia,

	Using sets of VLANs as a range of values is likely to force
sub-optimality on load-sharing - possibly to the extent that load
sharing becomes useless.

	It is not a trivial exercise to make VLAN topologies line up
conveniently with VLAN ID assignments.  In fact, assuming that it
is possible to modify VLAN topologies, it's most likely infeasible
to do so in some scenarios.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Friday, October 26, 2007 1:26 AM
> To: Eastlake III Donald-LDE008
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
> 
> Right...I was not intending to preclude having R1 be DRB for (inner) 
> VLANs (v1, v2, v3) and
> R2 be DRB for (inner) VLANs (v4, v5, v6). However, as you 
> point out, if 
> each RBridge can
> be configured with a different priority for each of the 4000 
> VLANs, the 
> IS-IS Hello would
> get too large. The only reason for different priorities is to do some 
> load splitting. I'd argue
> that with just a tiny bit of flexibility customers can get enough 
> functionality. So I'd suggest
> limiting multiple priorities to some reasonable number, like 
> 3, and sets 
> of VLANs to ranges.
> That would mean that R1 can claim to have priority P1 for the 
> VLANs in 
> range (n1-n2), and
> priority P2 for the VLANs in range (n3-n4), and priority P3 for VLANs 
> betwen (n5-n6).
> This would require (for 3 different priorities) 18 bytes in 
> the Hello. 
> For instance, "I have
> priority 7 for VLANs (1-50) and priority 12 for VLANs (61-80), and 
> priority 2 for
> VLANs (101-115). Perhaps another 500 bytes to do a bit mask 
> of all the 
> VLANs that
> you support at all (or alternatively you can't claim to have 
> a priority 
> for a range of VLANs unless
> you support all the VLANs in that range).
> 
> Likewise, in the pseudonode, we'd have to say the range of VLANs that 
> that pseudonode
> refers to.
> 
> And it's NOT a DRB collision if there is a pseudonode, say R1,17,
> for which R1 is DRB, reporting root bridge X
> and R2 is DRB on a link with root bridge X as long as the set 
> of VLANs 
> reported
> in R1.17's LSP does not overlap with the set of VLANs that R2 
> is DRB for 
> on that link.
> 
> And actually, R2 really only needs to decline to forward data (act as 
> DRB) for the set of
> VLANs in R1.17's pseudonode that overlaps with R2's. It could 
> be that R2 
> has some
> other VLANs that are not in R1.17's pseudonode.
> 
> So that's an additional refinement on the rules that should be added.
> 
> Perhaps we should start a different thread on whether people can live 
> with having a single
> DRB be configured with at most 3 priorities on a port, and 
> require the 
> set of VLANs for
> each priority to be expressible in a range (rather than having to 
> enumerate each of the
> VLAN tags individually).
> 
> Radia
> 
> 
> 
> Eastlake III Donald-LDE008 wrote:
> > Hi Radia,
> >
> > The proposal below appears to be written from the "one DRB per link"
> > point of view while the current draft claims to support "one DRB per
> > VLAN per link". Even if you have complete VLAN 1 
> connectivity and use
> > single Hellos, I'm not quite sure how the one DRB per VLAN per link
> > would work. In principle, the per VLAN priority for a 
> Rbridge port for
> > all its configured VLANs might not fit into a Hello...
> >
> > Thanks,
> > Donald
> >
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]] On
> > Behalf Of Radia Perlman
> > Sent: Thursday, October 25, 2007 2:56 PM
> > To: Developing a hybrid router/bridge.
> > Subject: [rbridge] A "multiple VLAN Hello" proposal
> >
> > It's a bit difficult to argue on the list about proposals 
> when one of 
> > them has not been specified, especially
> > since I can imagine lots of variations on multiple VLANs, 
> and lots of 
> > questions about choices for
> > the details.
> >
> > Here's an attempt to specify a "send Hellos on multiple 
> VLANs" proposal.
> >
> > I've chosen details
> > where in many cases there are other options I could have 
> chosen. But I 
> > think we need some
> > tangible proposal with details worked out before advocating for it. 
> > People should feel free
> > to suggest modifications to the details below, but I, as I 
> said, cannot 
> > argue between proposals
> > if the proposals aren't concrete. I've tried to make it as 
> simple as 
> > possible, as low overhead
> > as possible, while adding the ability to configure sending 
> Hellos on 
> > lots of VLANs.
> >
> >
> > a) RBridges send and receive IS-IS Hellos on VLAN 1
> >
> > b) In addition, RBridges MAY be configured to send and 
> receive Hellos on
> >
> > some set of
> > VLANs in addition to 1
> >
> > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all 
> the VLANs that 
> > R1 is
> > configured to send (and receive) on. To clarify, as long as 
> R1 thinks 
> > itself is DRB, it will
> > send Hellos on the complete set of VLANs that R1 is 
> configured to send 
> > on. In addition (see
> > point "e"), R1 may wind up having to send Hellos on some 
> set of VLANs in
> >
> > addition
> > to those it was configured to send on.
> >
> > d) In IS-IS's Hello, R1 reports the set of neighbor RBridges R1 has 
> > heard Hellos from. In addition,
> > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN 
> that R1 hears
> >
> > hellos from R2 on.
> > The one VLAN that R1 reports is the lowest numbered VLAN 
> that R1 hears a
> >
> > Hello from R2 on.
> >
> > e) If R1 does not hear a Hello from R2 on any of R1's 
> configured VLANs,
> > but does hear on some other VLAN, say VLAN x, then R1 adds 
> "x" to the 
> > set of VLANs that
> > R1 transmits on, as long as it continues to hear Hellos on 
> VLAN x (and
> > no
> > other VLANs) from R2. Note that if R2's Hello gives R2 
> better priority
> > for
> > being DRB, then R1 will not be DRB any more, but MUST 
> continue sending 
> > Hellos on
> > VLAN x (even though x is not in the set of VLANs
> > that R1 was configured to send on) to ensure that R2 
> continues to send 
> > its Hellos on VLAN x.
> >
> > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus 
> the VLAN 
> > that the DRB reports
> > that it has heard from you on. This cuts down on Hellos 
> since it means 
> > that non-DRB RBridges
> > will send on at most two VLANs.
> > {Note: An alternate option would have had every RBridge send Hellos 
> > always on all VLANs they
> > have been configured to send on}.
> >
> > f) all RBridge-RBridge traffic (other than Hellos) is 
> always sent on 
> > VLAN 1. So if R2 cannot
> > reach the DRB via VLAN 1, then R2 cannot forward data to/from that 
> > cloud, or receive
> > LSPs on that cloud. In other words, that link will be 
> broken for R2. The
> >
> > purpose
> > of the Hellos is only to notice (through a means *in 
> addition* to the 
> > safeguards in the other
> > proposals)  that R2 is not DRB for the link.
> >
> > g) We do the same safeguards as in the other proposals (report the
> > bridge root ID in the pseudonode LSP, don't decapsulate 
> from ingress Ra 
> > unless
> > you have all the relevant pseudonode LSPs attached to Ra to 
> ensure that 
> > none of them have
> > the same root RBridge, and that you delay before 
> encapsulating data off 
> > the link until you've
> > been DRB for enough time to synchronize LSP databases with your
> > neighbors)
> >
> > **************
> > My thoughts on this:
> >
> > a) I assume the only reason to send Hellos on multiple VLANs is to 
> > minimize the probability
> > of accidentally having two DRBs, and therefore loops. I'm 
> not convinced 
> > this adds safety
> > over the safeguards in the single VLAN proposals.
> >
> > b) this winds up with sending lots more Hellos, but does not create 
> > additional pseudonodes,
> > or complicate data forwarding, because the Hellos is only to find 
> > neighbors, not to repair
> > use of the link for forwarding data (or propagating LSPs) 
> if VLAN 1 is 
> > partitioned on the link
> >
> > c) This is a lot more complicated. It might seem simpler to 
> not try to 
> > optimize the number of
> > Hellos (like I did in point e), but there seem to be scary 
> corner cases 
> > where all the VLANs
> > common to R1 and R2 are partitioned. Saying there must be an 
> > unpartitioned VLAN 1 seems
> > the safest.
> >
> > So, I still like the "just use VLAN 1" proposal.
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >   
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Sun, 28 Oct 2007 15:54:37 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Announcing Root
Status: RO
Content-Length: 3715

Actually, because an Rbridge may be the DRB from multiple links in the
same VLAN on different ports and each of those ports could be connected
to a different bridged LAN, you have to report a set of spanning tree
root bridge IDs. Since this is a variable amount of information, if
there aren't any spanning tree devices around so you haven't received
any BPDUs, it seems simplest just to report that the size of the set is
zero.

Donald

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Friday, October 12, 2007 12:21 PM
> To: Anoop Ghanwani
> Cc: [email-masked]
> Subject: Re: [rbridge] Consensus Check: Announcing Root
> 
> I'm fine with option (b) but it seems implausible that all 0's could
> ever be a normal MAC address. Among other things, the 00-00-00 OUI is
> reserved for expressing arbitrary EtherTypes in the SNAP SAP format...
> 
> Donald
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[email-masked]]
> Sent: Monday, October 08, 2007 10:56 AM
> To: [email-masked]; Eastlake III Donald-LDE008
> Cc: [email-masked]
> Subject: RE: [rbridge] Consensus Check: Announcing Root
> 
> I would prefer (a) or (b) since 0 is technically
> a valid address.  (b) seems best since it's explicit.
> 
> Anoop
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of
[email-masked]
> > Sent: Sunday, October 07, 2007 8:38 PM
> > To: Eastlake III Donald-LDE008
> > Cc: [email-masked]
> > Subject: Re: [rbridge] Consensus Check: Announcing Root
> >
> > Good point. There might be no bridges. So there has to be a
> > way of encoding that. Anything such as:
> > a) leaving out the TLV in which one announces the root bridge
> > b) using a flag to say "no root"
> > c) using a special address, say 0
> > or I'm sure there are lots of possibilities.
> >
> > Radia
> >
> > ----- Original Message -----
> > From: Eastlake III Donald-LDE008 <[email-masked]>
> > Date: Saturday, October 6, 2007 12:46 pm
> > Subject: [rbridge] Consensus Check: Announcing Root
> >
> > > This is a check via the mailing list on a slight modification of
an
> > > apparent consensus from the minutes of the Chicago meeting for a
> > > changefrom protocol draft -05. The tentative consensus at
> > the Chicago
> > > meeting
> > > was:
> > >
> > >   It is mandatory for an RBridge to announce the bridge root that
> > >   it sees out each physical port.
> > >
> > > Based on mailing list discussion, I would like to tweak this as
> > > follows:
> > >   An Rbridge MUST parse BPDUs it receives on a port and announce
> > >   in the core IS-IS instance the bridge root that it sees out
> > >   each port. For MSTP (Multiple Spanning Tree Protocol), this is
> > >   the CIST (Common and Internal Spanning Tree) root.
> > >
> > > I have a question in connection with this. What is
> > announced for the
> > > port if no BPDU has been received recently or ever? Should
> > there be a
> > > "root MAC address valid" flag per port or should there some
> > > conventionalvalue, like zero, which is announced?
> > >
> > > Thanks,
> > > Donald
> > >
> > > _______________________________________________
> > > rbridge mailing list
> > > [email-masked]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> >
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Sun, 28 Oct 2007 12:43:40 -0500
From: "Eric Gray" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
Status: RO
Content-Length: 7595

Donald,

	We do not have carte-blanch in saying what is correct
and incorrect behavior for RBridges, unless we want to give
up on a large number of common concerns - compatibility with
existing/deployed technologies, software/hardware re-use and
just plain taking advantage of results of past experience,
to name a few.

	In saying that it is alright - at the protocol level 
(what people actually do is their business) - for a device
to treat VLAN traffic promiscuously is assuming both a level
of complexity and a degree of risk in achieving long term 
interoperability between RBridges and other potential VLAN
forwarding devices.

	Also, in establishing a precedent for ignoring what is
"common accepted practice" in existing VLAN devices, we may
expose ourselves to reciprocal future activities.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Friday, October 26, 2007 12:45 AM
> To: Anoop Ghanwani
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
> 
> Hi Anoop,
> 
> I don't look at it that way at all. We get to say what "correct" and
> "incorrect" behavior are for Rbridges.
> 
> TRILL Ethertype frames are special. The Outer VLAN tag on a TRILL
> Ethertype frame is just a transport artifact added to enable the frame
> to get through a Bridged LAN that is in the way. It is unnecessary on
> point-to-point links. If an Outer VLAN tag is present on a 
> TRILL frame,
> it shouldn't affect whether the frame is processed.
> 
> Donald
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On
> Behalf Of Anoop Ghanwani
> Sent: Thursday, October 25, 2007 5:39 PM
> To: Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
> 
> Radia,
> 
> Step "e" would be considered incorrect behavior
> w.r.t. VLANs.  If an end station is not configured
> with a certain VLAN, it should not be receiving and
> trying to process packets from that VLAN.  In this
> case, the end station is the management port running
> IS-IS.
> 
> Anoop 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Radia Perlman
> > Sent: Thursday, October 25, 2007 11:56 AM
> > To: Developing a hybrid router/bridge.
> > Subject: [rbridge] A "multiple VLAN Hello" proposal
> > 
> > It's a bit difficult to argue on the list about proposals 
> > when one of them has not been specified, especially since I 
> > can imagine lots of variations on multiple VLANs, and lots of 
> > questions about choices for the details.
> > 
> > Here's an attempt to specify a "send Hellos on multiple 
> > VLANs" proposal. 
> > I've chosen details
> > where in many cases there are other options I could have 
> > chosen. But I think we need some tangible proposal with 
> > details worked out before advocating for it. 
> > People should feel free
> > to suggest modifications to the details below, but I, as I 
> > said, cannot argue between proposals if the proposals aren't 
> > concrete. I've tried to make it as simple as possible, as low 
> > overhead as possible, while adding the ability to configure 
> > sending Hellos on lots of VLANs.
> > 
> > 
> > a) RBridges send and receive IS-IS Hellos on VLAN 1
> > 
> > b) In addition, RBridges MAY be configured to send and 
> > receive Hellos on some set of VLANs in addition to 1
> > 
> > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the 
> > VLANs that
> > R1 is
> > configured to send (and receive) on. To clarify, as long as 
> > R1 thinks itself is DRB, it will send Hellos on the complete 
> > set of VLANs that R1 is configured to send on. In addition 
> > (see point "e"), R1 may wind up having to send Hellos on some 
> > set of VLANs in addition to those it was configured to send on.
> > 
> > d) In IS-IS's Hello, R1 reports the set of neighbor RBridges 
> > R1 has heard Hellos from. In addition,
> > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN 
> > that R1 hears hellos from R2 on.
> > The one VLAN that R1 reports is the lowest numbered VLAN that 
> > R1 hears a Hello from R2 on.
> > 
> > e) If R1 does not hear a Hello from R2 on any of R1's 
> > configured VLANs, but does hear on some other VLAN, say VLAN 
> > x, then R1 adds "x" to the set of VLANs that
> > R1 transmits on, as long as it continues to hear Hellos on 
> > VLAN x (and no other VLANs) from R2. Note that if R2's Hello 
> > gives R2 better priority for being DRB, then R1 will not be 
> > DRB any more, but MUST continue sending Hellos on VLAN x 
> > (even though x is not in the set of VLANs that R1 was 
> > configured to send on) to ensure that R2 continues to send 
> > its Hellos on VLAN x.
> > 
> > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus 
> > the VLAN that the DRB reports that it has heard from you on. 
> > This cuts down on Hellos since it means that non-DRB RBridges 
> > will send on at most two VLANs.
> > {Note: An alternate option would have had every RBridge send 
> > Hellos always on all VLANs they have been configured to send on}.
> > 
> > f) all RBridge-RBridge traffic (other than Hellos) is always 
> > sent on VLAN 1. So if R2 cannot reach the DRB via VLAN 1, 
> > then R2 cannot forward data to/from that cloud, or receive 
> > LSPs on that cloud. In other words, that link will be broken 
> > for R2. The purpose of the Hellos is only to notice (through 
> > a means *in addition* to the safeguards in the other
> > proposals)  that R2 is not DRB for the link.
> > 
> > g) We do the same safeguards as in the other proposals 
> > (report the bridge root ID in the pseudonode LSP, don't 
> > decapsulate from ingress Ra unless you have all the relevant 
> > pseudonode LSPs attached to Ra to ensure that none of them 
> > have the same root RBridge, and that you delay before 
> > encapsulating data off the link until you've been DRB for 
> > enough time to synchronize LSP databases with your neighbors)
> > 
> > **************
> > My thoughts on this:
> > 
> > a) I assume the only reason to send Hellos on multiple VLANs 
> > is to minimize the probability of accidentally having two 
> > DRBs, and therefore loops. I'm not convinced this adds safety 
> > over the safeguards in the single VLAN proposals.
> > 
> > b) this winds up with sending lots more Hellos, but does not 
> > create additional pseudonodes, or complicate data forwarding, 
> > because the Hellos is only to find neighbors, not to repair 
> > use of the link for forwarding data (or propagating LSPs) if 
> > VLAN 1 is partitioned on the link
> > 
> > c) This is a lot more complicated. It might seem simpler to 
> > not try to optimize the number of Hellos (like I did in point 
> > e), but there seem to be scary corner cases where all the 
> > VLANs common to R1 and R2 are partitioned. Saying there must 
> > be an unpartitioned VLAN 1 seems the safest.
> > 
> > So, I still like the "just use VLAN 1" proposal.
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Sun, 28 Oct 2007 12:28:46 -0500
From: "Eric Gray" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
Status: RO
Content-Length: 8870

Radia,

	Using sets of VLANs as a range of values is likely to force
sub-optimality on load-sharing - possibly to the extent that load
sharing becomes useless.

	It is not a trivial exercise to make VLAN topologies line up
conveniently with VLAN ID assignments.  In fact, assuming that it
is possible to modify VLAN topologies, it's most likely infeasible
to do so in some scenarios.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Friday, October 26, 2007 1:26 AM
> To: Eastlake III Donald-LDE008
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
> 
> Right...I was not intending to preclude having R1 be DRB for (inner) 
> VLANs (v1, v2, v3) and
> R2 be DRB for (inner) VLANs (v4, v5, v6). However, as you 
> point out, if 
> each RBridge can
> be configured with a different priority for each of the 4000 
> VLANs, the 
> IS-IS Hello would
> get too large. The only reason for different priorities is to do some 
> load splitting. I'd argue
> that with just a tiny bit of flexibility customers can get enough 
> functionality. So I'd suggest
> limiting multiple priorities to some reasonable number, like 
> 3, and sets 
> of VLANs to ranges.
> That would mean that R1 can claim to have priority P1 for the 
> VLANs in 
> range (n1-n2), and
> priority P2 for the VLANs in range (n3-n4), and priority P3 for VLANs 
> betwen (n5-n6).
> This would require (for 3 different priorities) 18 bytes in 
> the Hello. 
> For instance, "I have
> priority 7 for VLANs (1-50) and priority 12 for VLANs (61-80), and 
> priority 2 for
> VLANs (101-115). Perhaps another 500 bytes to do a bit mask 
> of all the 
> VLANs that
> you support at all (or alternatively you can't claim to have 
> a priority 
> for a range of VLANs unless
> you support all the VLANs in that range).
> 
> Likewise, in the pseudonode, we'd have to say the range of VLANs that 
> that pseudonode
> refers to.
> 
> And it's NOT a DRB collision if there is a pseudonode, say R1,17,
> for which R1 is DRB, reporting root bridge X
> and R2 is DRB on a link with root bridge X as long as the set 
> of VLANs 
> reported
> in R1.17's LSP does not overlap with the set of VLANs that R2 
> is DRB for 
> on that link.
> 
> And actually, R2 really only needs to decline to forward data (act as 
> DRB) for the set of
> VLANs in R1.17's pseudonode that overlaps with R2's. It could 
> be that R2 
> has some
> other VLANs that are not in R1.17's pseudonode.
> 
> So that's an additional refinement on the rules that should be added.
> 
> Perhaps we should start a different thread on whether people can live 
> with having a single
> DRB be configured with at most 3 priorities on a port, and 
> require the 
> set of VLANs for
> each priority to be expressible in a range (rather than having to 
> enumerate each of the
> VLAN tags individually).
> 
> Radia
> 
> 
> 
> Eastlake III Donald-LDE008 wrote:
> > Hi Radia,
> >
> > The proposal below appears to be written from the "one DRB per link"
> > point of view while the current draft claims to support "one DRB per
> > VLAN per link". Even if you have complete VLAN 1 
> connectivity and use
> > single Hellos, I'm not quite sure how the one DRB per VLAN per link
> > would work. In principle, the per VLAN priority for a 
> Rbridge port for
> > all its configured VLANs might not fit into a Hello...
> >
> > Thanks,
> > Donald
> >
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]] On
> > Behalf Of Radia Perlman
> > Sent: Thursday, October 25, 2007 2:56 PM
> > To: Developing a hybrid router/bridge.
> > Subject: [rbridge] A "multiple VLAN Hello" proposal
> >
> > It's a bit difficult to argue on the list about proposals 
> when one of 
> > them has not been specified, especially
> > since I can imagine lots of variations on multiple VLANs, 
> and lots of 
> > questions about choices for
> > the details.
> >
> > Here's an attempt to specify a "send Hellos on multiple 
> VLANs" proposal.
> >
> > I've chosen details
> > where in many cases there are other options I could have 
> chosen. But I 
> > think we need some
> > tangible proposal with details worked out before advocating for it. 
> > People should feel free
> > to suggest modifications to the details below, but I, as I 
> said, cannot 
> > argue between proposals
> > if the proposals aren't concrete. I've tried to make it as 
> simple as 
> > possible, as low overhead
> > as possible, while adding the ability to configure sending 
> Hellos on 
> > lots of VLANs.
> >
> >
> > a) RBridges send and receive IS-IS Hellos on VLAN 1
> >
> > b) In addition, RBridges MAY be configured to send and 
> receive Hellos on
> >
> > some set of
> > VLANs in addition to 1
> >
> > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all 
> the VLANs that 
> > R1 is
> > configured to send (and receive) on. To clarify, as long as 
> R1 thinks 
> > itself is DRB, it will
> > send Hellos on the complete set of VLANs that R1 is 
> configured to send 
> > on. In addition (see
> > point "e"), R1 may wind up having to send Hellos on some 
> set of VLANs in
> >
> > addition
> > to those it was configured to send on.
> >
> > d) In IS-IS's Hello, R1 reports the set of neighbor RBridges R1 has 
> > heard Hellos from. In addition,
> > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN 
> that R1 hears
> >
> > hellos from R2 on.
> > The one VLAN that R1 reports is the lowest numbered VLAN 
> that R1 hears a
> >
> > Hello from R2 on.
> >
> > e) If R1 does not hear a Hello from R2 on any of R1's 
> configured VLANs,
> > but does hear on some other VLAN, say VLAN x, then R1 adds 
> "x" to the 
> > set of VLANs that
> > R1 transmits on, as long as it continues to hear Hellos on 
> VLAN x (and
> > no
> > other VLANs) from R2. Note that if R2's Hello gives R2 
> better priority
> > for
> > being DRB, then R1 will not be DRB any more, but MUST 
> continue sending 
> > Hellos on
> > VLAN x (even though x is not in the set of VLANs
> > that R1 was configured to send on) to ensure that R2 
> continues to send 
> > its Hellos on VLAN x.
> >
> > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus 
> the VLAN 
> > that the DRB reports
> > that it has heard from you on. This cuts down on Hellos 
> since it means 
> > that non-DRB RBridges
> > will send on at most two VLANs.
> > {Note: An alternate option would have had every RBridge send Hellos 
> > always on all VLANs they
> > have been configured to send on}.
> >
> > f) all RBridge-RBridge traffic (other than Hellos) is 
> always sent on 
> > VLAN 1. So if R2 cannot
> > reach the DRB via VLAN 1, then R2 cannot forward data to/from that 
> > cloud, or receive
> > LSPs on that cloud. In other words, that link will be 
> broken for R2. The
> >
> > purpose
> > of the Hellos is only to notice (through a means *in 
> addition* to the 
> > safeguards in the other
> > proposals)  that R2 is not DRB for the link.
> >
> > g) We do the same safeguards as in the other proposals (report the
> > bridge root ID in the pseudonode LSP, don't decapsulate 
> from ingress Ra 
> > unless
> > you have all the relevant pseudonode LSPs attached to Ra to 
> ensure that 
> > none of them have
> > the same root RBridge, and that you delay before 
> encapsulating data off 
> > the link until you've
> > been DRB for enough time to synchronize LSP databases with your
> > neighbors)
> >
> > **************
> > My thoughts on this:
> >
> > a) I assume the only reason to send Hellos on multiple VLANs is to 
> > minimize the probability
> > of accidentally having two DRBs, and therefore loops. I'm 
> not convinced 
> > this adds safety
> > over the safeguards in the single VLAN proposals.
> >
> > b) this winds up with sending lots more Hellos, but does not create 
> > additional pseudonodes,
> > or complicate data forwarding, because the Hellos is only to find 
> > neighbors, not to repair
> > use of the link for forwarding data (or propagating LSPs) 
> if VLAN 1 is 
> > partitioned on the link
> >
> > c) This is a lot more complicated. It might seem simpler to 
> not try to 
> > optimize the number of
> > Hellos (like I did in point e), but there seem to be scary 
> corner cases 
> > where all the VLANs
> > common to R1 and R2 are partitioned. Saying there must be an 
> > unpartitioned VLAN 1 seems
> > the safest.
> >
> > So, I still like the "just use VLAN 1" proposal.
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >   
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Sun, 28 Oct 2007 04:49:05 -0700
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?
Status: RO
Content-Length: 17802

Radia,

Can you explain me if your solution supports the example that I have
drawn in PowerPoint at:
http://www.ip6.com/example.ppt
?

Thank You

Answering your email:

I have seen customers deploying VLANs in a variety of ways.

Some customers have VLAN 1 end-to-end and they use it for control and
data traffic. Some customers use VLAN 1 only for control traffic. Some
customers wants all VLANs (including VLAN 1) being local (not
end-to-end). Some customers prefer to move some control protocol to
another VLAN. I have seen multiple different approaches.

You ask for rational, "tangible reasons". Each customer has its own
reasons that don't match the ones of other customers. There are no
universal tangible reasons, you just need to realize that IEEE 802.1Q
allows VLANs to be deployed in many different way.  Any solution that
poses restrictions is going to be OK for some customers and KO for
others.

Over the years I have learned to live with the fact that customers have
different deployment approaches that are perfectly valid because allowed
by IEEE 802.1Q and by the products.

In TRILL we often speak about plug-and-play. If we consider
plug-and-play, VLAN 1 is the only one enabled by default and therefore
it seems a reasonable default solution.

While this is a valid concept in the consumer space, it is absolutely
not valid in Enterprise/Datacenter. Enterprise/Datacenter customers
request that all the new boxes are shipped with all the ports disabled,
because they realized that the switches will be connected in complex
configurations in which plug-and-play is very dangerous. 

I expect the same to be true for RBridges, where customers will
carefully design, test in a separate environment and bring-up a
configuration that will match the existing VLAN deployment they have.

Inline for you specific questions:

> -----Original Message-----
> From: Radia Perlman [mailto:[email-masked]]
> Sent: Saturday, October 27, 2007 8:59 PM
> To: Silvano Gai
> Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-
> RBridgepackets?
> 
> I'm anxious to close on this issue, but
> Silvano...you always speak in such absolutes: words like
> "unrealistic" without giving tangible reasons what the
> problem is. Again, everything is engineering tradeoffs, and we have to
> understand what the specific
> pros and cons are (not phrases like
> "won't work" "unrealistic" "not flexible enough", but instead "won't
allow
> this *particular* scenario")
> 
> Question: Is the problem picking specifically VLAN 1 as
> our chosen single VLAN number? If we picked a different
(unconfigurable)
> VLAN number would that be OK? 

I think that VLAN 1 is probably our best default choice. I don't object
to have VLAN 1 to be the default VLAN.

If so, what number? If you are arguing that
> it's OK to require one VLAN not to be partitioned, and that all
> RBridge-RBridge
> communication be done over that VLAN, then I really don't understand.

I am not sure what you are asking. If you are speaking of the backbone
between RBridges, the outer VLAN tag for sure may not be the same
end-to-end.

A department of a large corporation may want to deploy RBridges in 5
different sites. The VLAN they have available from site_1 to site_2 may
be VLAN 5, form site_1 to site_3 VLAN 7, from site_3 to site_4 VLAN 4.

If you want all this VLANs to be a single VLAN end-to-end, there is a
significant change that needs to happen in the communication
infrastructure that may be considered difficult or impossible.

If instead you are discussing the access to the RBridge clouds, I think
it is reasonable to require that the RBridges that perform TRILL
encapsulation for an Ethernet Cloud have a common VLAN. VLAN1 may be the
default, but I think that the value should be programmable.

> If that were the case, why can't we (TRILL) put a stake in the ground
> and say "RBridges will
> use VLAN 1", and if the customer wanted to use VLAN 1 for something
> else, but was willing
> to configure RBridges to use, say, VLAN 57, why can't that customer
> renumber their own
> VLANs so that they switch their uses of VLAN 57 and VLAN 1, and let
the
> rest of
> the world have the simplicity of an unconfigurable choice of VLAN 1?

I don't think this is acceptable for many customers. You are putting a
stake in the ground that IEEE has never put.

> 
> Are you saying that you don't want to require customers to have *any*
> VLAN number that
> isn't partitioned, 

I am not sure what you mean with "*any* VLAN number that isn't
partitioned", are you speaking of inner VLAN or outer VLAN?

In most installation the numbering spaces of the Backbone VLANs and
Access VLANs are disjoint. I don't think this is an issue since the
access VLANs appears in the inner VLAN tag, while the backbone VLANs
appears in the outer VLAN tag.

and you want a solution that somehow finds all
> possible ways of having
> RBridges talk to each other using every possible VLAN? 

Again, when you are saying "RBridges talk to each other" are you
speaking of the TRILL encapsulated frames or of the DRB election on the
access?

Again see my example at:
http://www.ip6.com/example.ppt

-- Silvano

If so, this
> proposal has never been
> specified, and, as I said, can't be evaluated unless it is specified.
> 
> Anyway, I really want to understand the issue, but you really have to
be
> specific about
> what is being precluded by saying "just use VLAN 1", or even the
> fallback compromise "just use a single
> VLAN that is default=1, but the DRB can tell all the other RBridges to
> use some other VLAN
> number instead". I don't think we should give in and make it
> configurable without understanding
> why it is less work for the customer to configure the RBridges to
change
> to a different VLAN number X
> than for that same customer to reconfigure whatever it was they were
> doing to switch VLAN 1
> with VLAN X, so that RBridges can use VLAN 1.
> 
> Radia
> 
> 
> Silvano Gai wrote:
> > Assuming that you always have connectivity on VLAN 1 is unrealistic.
> > Different installation may use VLAN 1 for different purposes.
> >
> > Forbidding by standard to change this VLAN to another value is not
going
> > to work in products. Products will need to support the capability to
> > change this value to meet customer needs. They will therefore invent
> > proprietary mechanism to support a different value. Result: lack of
> > interoperability.
> >
> > -- Silvano
> >
> >
> >> -----Original Message-----
> >> From: Anoop Ghanwani [mailto:[email-masked]]
> >> Sent: Thursday, October 25, 2007 10:20 AM
> >> To: Radia Perlman; Silvano Gai
> >> Cc: Developing a hybrid router/bridge.
> >> Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-
> >> RBridgepackets?
> >>
> >>
> >> Hi Radia,
> >>
> >> I am fairly comfortable with adopting the single
> >> VLAN hello proposal and forcing that to be VLAN 1.
> >>
> >> I would rather not have to deal with the complexity
> >> of making it configurable because even that can
> >> be subject to misconfiguration and would have its
> >> own set of issues, but I am also not totally
> >> opposed to that if someone else feels strongly
> >> about it.  The main argument for doing that
> >> would be point (b) in your message -- that
> >> VLAN 1 was already being used for something
> >> else and the operator didn't want to use it
> >> for RBridge control traffic.
> >>
> >> As you point out, it looks like the proposal
> >> for sending hellos on multiple VLANs would also
> >> require additional scrutiny/specification before
> >> it can be adopted.  Unless shown to be absolutely
> >> necessary, this approach imposes a significant
> >> processing burden so I would rather see us
> >> solve the problem with the hellos on VLAN 1
> >> only.
> >>
> >> Anoop
> >>
> >>
> >>> -----Original Message-----
> >>> From: Radia Perlman [mailto:[email-masked]]
> >>> Sent: Wednesday, October 24, 2007 2:42 PM
> >>> To: Silvano Gai
> >>> Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> >>> Subject: Re: [rbridge] Final outcome of outer VLAN tags
> >>> onRBridge-RBridgepackets?
> >>>
> >>> It's always hard to catch up on a thread after being away
> >>> from email for a couple of days, but Silvano --- both the
> >>> tone and (lack of) content of your message below makes it
> >>> really difficult.
> >>>
> >>> In order to do quality engineering, we need to understand
> >>> what all the tradeoffs are, and we have to be able to do
> >>> discourse in an atmosphere of mutual respect.
> >>>
> >>> Saying something like "not doing it my way is 'too weak to be
> >>> practical', or 'holds water like a pasta strainer' is not
> >>> engineering. It is attempting to ridicule anyone who
> >>> disagrees with you, and also is completely uninformative
> >>> because you are not saying what the tradeoffs are, or even
> >>> the details of how the thing you want would work.
> >>>
> >>> I am usually proud of this WG because we usually do explore
> >>> all the options and what the tradoffs are without resorting
> >>> to bullying and ridicule. Let's strive to do engineering that way.
> >>>
> >>> So let me demonstrate by getting back to the thread.
> >>>
> >>> I think the "downsides" of sending all RBridge-RBridge
> >>> messages on a single unconfigurable VLAN (proposal being VLAN 1)
> >>>
> > are:
> >
> >>> a) if VLAN 1 is indeed partitioned, the RBridges will not
> >>> know through IS-IS Hellos that they have RBridge neighbors,
> >>> and multiple DRBs will be elected. But the proposal also
> >>> includes how to prevent multiple DRB, namely by being
> >>> conservative about forwarding data traffic to/from the link
> >>> until we discover, though reporting the bridge root ID in
> >>> LSPs, that it is safe to do so
> >>> b) a customer might want to not use that VLAN for
> >>> RBridge-RBridge traffic. However, if that customer felt so
> >>> strongly about minimizing RBridge-Rbridge traffic, they could
> >>> reconfigure use of the VLANs to move what they were using
> >>> VLAN 1 to, to some other VLAN. So saying "just use 1" might
> >>> inconvenience one customer who is already very savvy and
> >>> likes to do really fancy configuration things, but does not
> >>> prevent them from accomplishing all the exotic things they
> >>> are trying to do -- just means some more configuration. And
> >>> is saves what hopefully is the vast majority of customers
> >>> from having to do any configuration whatsoever, and
> >>> simplifies the spec and prevents misconfiguration.
> >>>
> >>> The upside of saying "just use 1" is extreme simplicity, and
> >>> with the safeguards, will not have any higher probabilty of
> >>> loops than already exists due to repeaters coming up, or
> >>> bridge spanning tree messages getting lost.
> >>>
> >>> The next more complex proposal was to allow configuration to
> >>> still ultimately use one VLAN per cloud, but allow it to be
> >>> configurable to be something other than 1. I gave a proposal
> >>> for doing that in a previous message (the DRB tells all the
> >>> other RBridges what VLAN to use, while the DRB still sends on
> >>> VLAN 1 in addition to the VLAN the DRB tells everyone to send
> >>> one). I think the upside over the simplest "just use 1", is
> >>> that it allows a customer that doesn't want RBridge-RBridge
> >>> traffic being used on VLAN 1, or intentionally wants data
> >>> traffic on VLAN 1 to be partitioned on a cloud, to move to a
> >>> VLAN on that cloud that is OK not to be partitioned. The
> >>> downside is that steady state the DRB will send one more
> >>> Hello (on VLAN 1) than it would have, once the DRB tells all
> >>> the other RBridges what VLAN to send on, and it is one more
> >>> configuration thing to have to explain. And it seems likely
> >>> that the DRB will be misconfigured and declare that RBridges
> >>> will use VLAN k instead of 1, when some other RBridge on the
> >>> cloud is not configured to support k. It won't be fatal
> >>> (since that other RBridge will still hear the DRB on VLAN 1
> >>> and will also know about the other DRB through link state
> >>> messages). My opinion is that this extra complexity over
> >>> "just use 1" is not warranted given the small upside.
> >>>
> >>> If there is another proposal, say "send all Hellos on all
> >>> VLANs", I claim that the details of that have never been
> >>> specified well enough for that proposal to be evaluated. So
> >>> if someone who advocates that can do that, staying technical,
> >>> covering all details like whether in your IS-IS Hello you
> >>> list all the VLAN tags you've heard Hellos from for each
> >>> neighbor, and how you send a multicast data message when you
> >>> have adjacencies with different VLAN tags for different
> >>> subsets of neighbors, I'd like to hear it.
> >>>
> >>> And by all means, if I have missed some of the downsides on
> >>> "just use VLAN 1", or "just use a single VLAN, but it can be
> >>> configured to be something other than 1", then by all means
> >>> add to the arguments.
> >>>
> >>> Radia
> >>>
> >>>
> >>>
> >>>
> >>> Silvano Gai wrote:
> >>>
> >>>> I want to restate that IMHO a design that sends messages on
> >>>>
> >>> a single
> >>>
> >>>> VLAN is so week to be completely useless.
> >>>>
> >>>> I met Anoop on a plane back from a T11 meeting and we discussed
> >>>>
> > the
> >
> >>>> issue of sending messages on all the configured VLANs.
> >>>>
> >>> Anoop pointed
> >>>
> >>>> out that, if these messages are ISIS messages, this can
> >>>>
> >>> overload the
> >>>
> >>>> RBrige supervisor.
> >>>>
> >>>> We identified a possible solution based on two different
> >>>>
> >>> message types:
> >>>
> >>>> - ISIS used on a single VLAN to compute adjacency
> >>>> - simple per-VLAN checking on all the VLANs to verify
> >>>>
> > reachability.
> >
> >>>> The second kind of messages is much simpler and therefore they
> >>>>
> > load
> >
> >>>> less the RBrige supervisor. In the future, per-VLAN checking can
> >>>>
> > be
> >
> >>>> implemented by the port ASIC. This seems a viable solution that
> >>>> requires design effort, but it is promising.
> >>>>
> >>>> Without the per-VLAN checking, running ISIS on a single VLAN
holds
> >>>> water like a pasta-strainer.
> >>>>
> >>>> -- Silvano
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: [email-masked]
> >>>>>
> >>> [mailto:[email-masked]]
> >>>
> >>>> On
> >>>>
> >>>>
> >>>>> Behalf Of Anoop Ghanwani
> >>>>> Sent: Monday, October 22, 2007 11:01 AM
> >>>>> To: Radia Perlman; Developing a hybrid router/bridge.
> >>>>> Subject: Re: [rbridge] Final outcome of outer VLAN tags
> >>>>>
> > onRBridge-
> >
> >>>>> RBridgepackets?
> >>>>>
> >>>>>
> >>>>> If we want to make implementations work with only a single
> >>>>>
> >>> Hello for
> >>>
> >>>>> all VLANs than the option is (a).  I think that is what it
> >>>>>
> >>> should be.
> >>>
> >>>>> Basically, as a part of RBridge configuration there should be a
> >>>>> "RBridge Control VLAN" configuration that applies to the whole
> >>>>> device.  It should default to VLAN 1, but an operator can
> >>>>>
> >>> choose to
> >>>
> >>>>> change it.
> >>>>> A RBridge only emits Hellos on that VLAN.  If it receives
> >>>>>
> >>> Hellos on
> >>>
> >>>>> any other VLAN that should be detected as an error condition and
> >>>>> reported.
> >>>>>
> >>>>> There have been some problem corner cases that have been
> >>>>>
> >>> pointed out
> >>>
> >>>>> previously on the list that may result in temporary duplication
> >>>>>
> > of
> >
> >>>>> traffic when there is misconfiguration.  Those should be
> >>>>>
> >>> documented.
> >>>
> >>>>> Anoop
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: [email-masked]
> >>>>>> [mailto:[email-masked]] On Behalf Of Radia Perlman
> >>>>>> Sent: Saturday, October 20, 2007 9:47 PM
> >>>>>> To: Developing a hybrid router/bridge.
> >>>>>> Subject: [rbridge] Final outcome of outer VLAN tags on
> >>>>>> RBridge-RBridgepackets?
> >>>>>>
> >>>>>> I'm not sure I understood the final consensus on what we
> >>>>>>
> >>> should do
> >>>
> >>>>>> for outer VLAN tags on inter-RBridge packets.
> >>>>>>
> >>>>>> The possibilities I think the consensus might have been are:
> >>>>>>
> >>>>>> a) only use VLAN 1, explicit tag, no configuration possible.
> >>>>>> b) default is VLAN 1, explicit tag, configuration is possible
to
> >>>>>> change sending with VLAN tag(s) something other than 1.
> >>>>>>
> >>> If this is
> >>>
> >>>>>> what was decided, I don't believe we've worked out the design
> >>>>>> details. I'd assume this would mean RBridges should be willing
> >>>>>>
> > to
> >
> >>>>>> receive packets from other RBridges regardless of outer VLAN
> >>>>>>
> > tag.
> >
> >>>>>> Would we then mark in the Hellos what VLAN tag(s) you've
> >>>>>>
> >>> heard from
> >>>
> >>>>>> what other RBridges with? What do we do with multicast if there
> >>>>>> isn't a single VLAN tag that seems to work to send to everyone?
> >>>>>> Would we allow configuration to send on a set of VLAN
> >>>>>>
> >>> tags, or just
> >>>
> >>>>>> on one at a time (and we allow configuration to say which one
it
> >>>>>> is)?
> >>>>>>
> >>>>>> Certainly a) is simpler. If the consensus was b), we'd
> >>>>>>
> >>> better work
> >>>
> >>>>>> out the details.
> >>>>>>
> >>>>>> Radia
> >>>>>> _______________________________________________
> >>>>>> rbridge mailing list
> >>>>>> [email-masked]
> >>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> _______________________________________________
> >>>>> rbridge mailing list
> >>>>> [email-masked]
> >>>>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>>>
> >>>>>

Date: Sat, 27 Oct 2007 20:58:39 -0700
From: Radia Perlman <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?
Status: RO
Content-Length: 13773

I'm anxious to close on this issue, but
Silvano...you always speak in such absolutes: words like
"unrealistic" without giving tangible reasons what the
problem is. Again, everything is engineering tradeoffs, and we have to 
understand what the specific
pros and cons are (not phrases like
"won't work" "unrealistic" "not flexible enough", but instead "won't allow
this *particular* scenario")

Question: Is the problem picking specifically VLAN 1 as
our chosen single VLAN number? If we picked a different (unconfigurable)
VLAN number would that be OK? If so, what number? If you are arguing that
it's OK to require one VLAN not to be partitioned, and that all 
RBridge-RBridge
communication be done over that VLAN, then I really don't understand.
If that were the case, why can't we (TRILL) put a stake in the ground 
and say "RBridges will
use VLAN 1", and if the customer wanted to use VLAN 1 for something 
else, but was willing
to configure RBridges to use, say, VLAN 57, why can't that customer 
renumber their own
VLANs so that they switch their uses of VLAN 57 and VLAN 1, and let the 
rest of
the world have the simplicity of an unconfigurable choice of VLAN 1?

Are you saying that you don't want to require customers to have *any* 
VLAN number that
isn't partitioned, and you want a solution that somehow finds all 
possible ways of having
RBridges talk to each other using every possible VLAN? If so, this 
proposal has never been
specified, and, as I said, can't be evaluated unless it is specified.

Anyway, I really want to understand the issue, but you really have to be 
specific about
what is being precluded by saying "just use VLAN 1", or even the 
fallback compromise "just use a single
VLAN that is default=1, but the DRB can tell all the other RBridges to 
use some other VLAN
number instead". I don't think we should give in and make it 
configurable without understanding
why it is less work for the customer to configure the RBridges to change 
to a different VLAN number X
than for that same customer to reconfigure whatever it was they were 
doing to switch VLAN 1
with VLAN X, so that RBridges can use VLAN 1.

Radia

Silvano Gai wrote:
> Assuming that you always have connectivity on VLAN 1 is unrealistic.
> Different installation may use VLAN 1 for different purposes.
>
> Forbidding by standard to change this VLAN to another value is not going
> to work in products. Products will need to support the capability to
> change this value to meet customer needs. They will therefore invent
> proprietary mechanism to support a different value. Result: lack of
> interoperability.
>
> -- Silvano
>
>   
>> -----Original Message-----
>> From: Anoop Ghanwani [mailto:[email-masked]]
>> Sent: Thursday, October 25, 2007 10:20 AM
>> To: Radia Perlman; Silvano Gai
>> Cc: Developing a hybrid router/bridge.
>> Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-
>> RBridgepackets?
>>
>>
>> Hi Radia,
>>
>> I am fairly comfortable with adopting the single
>> VLAN hello proposal and forcing that to be VLAN 1.
>>
>> I would rather not have to deal with the complexity
>> of making it configurable because even that can
>> be subject to misconfiguration and would have its
>> own set of issues, but I am also not totally
>> opposed to that if someone else feels strongly
>> about it.  The main argument for doing that
>> would be point (b) in your message -- that
>> VLAN 1 was already being used for something
>> else and the operator didn't want to use it
>> for RBridge control traffic.
>>
>> As you point out, it looks like the proposal
>> for sending hellos on multiple VLANs would also
>> require additional scrutiny/specification before
>> it can be adopted.  Unless shown to be absolutely
>> necessary, this approach imposes a significant
>> processing burden so I would rather see us
>> solve the problem with the hellos on VLAN 1
>> only.
>>
>> Anoop
>>
>>     
>>> -----Original Message-----
>>> From: Radia Perlman [mailto:[email-masked]]
>>> Sent: Wednesday, October 24, 2007 2:42 PM
>>> To: Silvano Gai
>>> Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
>>> Subject: Re: [rbridge] Final outcome of outer VLAN tags
>>> onRBridge-RBridgepackets?
>>>
>>> It's always hard to catch up on a thread after being away
>>> from email for a couple of days, but Silvano --- both the
>>> tone and (lack of) content of your message below makes it
>>> really difficult.
>>>
>>> In order to do quality engineering, we need to understand
>>> what all the tradeoffs are, and we have to be able to do
>>> discourse in an atmosphere of mutual respect.
>>>
>>> Saying something like "not doing it my way is 'too weak to be
>>> practical', or 'holds water like a pasta strainer' is not
>>> engineering. It is attempting to ridicule anyone who
>>> disagrees with you, and also is completely uninformative
>>> because you are not saying what the tradeoffs are, or even
>>> the details of how the thing you want would work.
>>>
>>> I am usually proud of this WG because we usually do explore
>>> all the options and what the tradoffs are without resorting
>>> to bullying and ridicule. Let's strive to do engineering that way.
>>>
>>> So let me demonstrate by getting back to the thread.
>>>
>>> I think the "downsides" of sending all RBridge-RBridge
>>> messages on a single unconfigurable VLAN (proposal being VLAN 1)
>>>       
> are:
>   
>>> a) if VLAN 1 is indeed partitioned, the RBridges will not
>>> know through IS-IS Hellos that they have RBridge neighbors,
>>> and multiple DRBs will be elected. But the proposal also
>>> includes how to prevent multiple DRB, namely by being
>>> conservative about forwarding data traffic to/from the link
>>> until we discover, though reporting the bridge root ID in
>>> LSPs, that it is safe to do so
>>> b) a customer might want to not use that VLAN for
>>> RBridge-RBridge traffic. However, if that customer felt so
>>> strongly about minimizing RBridge-Rbridge traffic, they could
>>> reconfigure use of the VLANs to move what they were using
>>> VLAN 1 to, to some other VLAN. So saying "just use 1" might
>>> inconvenience one customer who is already very savvy and
>>> likes to do really fancy configuration things, but does not
>>> prevent them from accomplishing all the exotic things they
>>> are trying to do -- just means some more configuration. And
>>> is saves what hopefully is the vast majority of customers
>>> from having to do any configuration whatsoever, and
>>> simplifies the spec and prevents misconfiguration.
>>>
>>> The upside of saying "just use 1" is extreme simplicity, and
>>> with the safeguards, will not have any higher probabilty of
>>> loops than already exists due to repeaters coming up, or
>>> bridge spanning tree messages getting lost.
>>>
>>> The next more complex proposal was to allow configuration to
>>> still ultimately use one VLAN per cloud, but allow it to be
>>> configurable to be something other than 1. I gave a proposal
>>> for doing that in a previous message (the DRB tells all the
>>> other RBridges what VLAN to use, while the DRB still sends on
>>> VLAN 1 in addition to the VLAN the DRB tells everyone to send
>>> one). I think the upside over the simplest "just use 1", is
>>> that it allows a customer that doesn't want RBridge-RBridge
>>> traffic being used on VLAN 1, or intentionally wants data
>>> traffic on VLAN 1 to be partitioned on a cloud, to move to a
>>> VLAN on that cloud that is OK not to be partitioned. The
>>> downside is that steady state the DRB will send one more
>>> Hello (on VLAN 1) than it would have, once the DRB tells all
>>> the other RBridges what VLAN to send on, and it is one more
>>> configuration thing to have to explain. And it seems likely
>>> that the DRB will be misconfigured and declare that RBridges
>>> will use VLAN k instead of 1, when some other RBridge on the
>>> cloud is not configured to support k. It won't be fatal
>>> (since that other RBridge will still hear the DRB on VLAN 1
>>> and will also know about the other DRB through link state
>>> messages). My opinion is that this extra complexity over
>>> "just use 1" is not warranted given the small upside.
>>>
>>> If there is another proposal, say "send all Hellos on all
>>> VLANs", I claim that the details of that have never been
>>> specified well enough for that proposal to be evaluated. So
>>> if someone who advocates that can do that, staying technical,
>>> covering all details like whether in your IS-IS Hello you
>>> list all the VLAN tags you've heard Hellos from for each
>>> neighbor, and how you send a multicast data message when you
>>> have adjacencies with different VLAN tags for different
>>> subsets of neighbors, I'd like to hear it.
>>>
>>> And by all means, if I have missed some of the downsides on
>>> "just use VLAN 1", or "just use a single VLAN, but it can be
>>> configured to be something other than 1", then by all means
>>> add to the arguments.
>>>
>>> Radia
>>>
>>>
>>>
>>>
>>> Silvano Gai wrote:
>>>       
>>>> I want to restate that IMHO a design that sends messages on
>>>>         
>>> a single
>>>       
>>>> VLAN is so week to be completely useless.
>>>>
>>>> I met Anoop on a plane back from a T11 meeting and we discussed
>>>>         
> the
>   
>>>> issue of sending messages on all the configured VLANs.
>>>>         
>>> Anoop pointed
>>>       
>>>> out that, if these messages are ISIS messages, this can
>>>>         
>>> overload the
>>>       
>>>> RBrige supervisor.
>>>>
>>>> We identified a possible solution based on two different
>>>>         
>>> message types:
>>>       
>>>> - ISIS used on a single VLAN to compute adjacency
>>>> - simple per-VLAN checking on all the VLANs to verify
>>>>         
> reachability.
>   
>>>> The second kind of messages is much simpler and therefore they
>>>>         
> load
>   
>>>> less the RBrige supervisor. In the future, per-VLAN checking can
>>>>         
> be
>   
>>>> implemented by the port ASIC. This seems a viable solution that
>>>> requires design effort, but it is promising.
>>>>
>>>> Without the per-VLAN checking, running ISIS on a single VLAN holds
>>>> water like a pasta-strainer.
>>>>
>>>> -- Silvano
>>>>
>>>>
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>>           
>>> [mailto:[email-masked]]
>>>       
>>>> On
>>>>
>>>>         
>>>>> Behalf Of Anoop Ghanwani
>>>>> Sent: Monday, October 22, 2007 11:01 AM
>>>>> To: Radia Perlman; Developing a hybrid router/bridge.
>>>>> Subject: Re: [rbridge] Final outcome of outer VLAN tags
>>>>>           
> onRBridge-
>   
>>>>> RBridgepackets?
>>>>>
>>>>>
>>>>> If we want to make implementations work with only a single
>>>>>           
>>> Hello for
>>>       
>>>>> all VLANs than the option is (a).  I think that is what it
>>>>>           
>>> should be.
>>>       
>>>>> Basically, as a part of RBridge configuration there should be a
>>>>> "RBridge Control VLAN" configuration that applies to the whole
>>>>> device.  It should default to VLAN 1, but an operator can
>>>>>           
>>> choose to
>>>       
>>>>> change it.
>>>>> A RBridge only emits Hellos on that VLAN.  If it receives
>>>>>           
>>> Hellos on
>>>       
>>>>> any other VLAN that should be detected as an error condition and
>>>>> reported.
>>>>>
>>>>> There have been some problem corner cases that have been
>>>>>           
>>> pointed out
>>>       
>>>>> previously on the list that may result in temporary duplication
>>>>>           
> of
>   
>>>>> traffic when there is misconfiguration.  Those should be
>>>>>           
>>> documented.
>>>       
>>>>> Anoop
>>>>>
>>>>>
>>>>>           
>>>>>> -----Original Message-----
>>>>>> From: [email-masked]
>>>>>> [mailto:[email-masked]] On Behalf Of Radia Perlman
>>>>>> Sent: Saturday, October 20, 2007 9:47 PM
>>>>>> To: Developing a hybrid router/bridge.
>>>>>> Subject: [rbridge] Final outcome of outer VLAN tags on
>>>>>> RBridge-RBridgepackets?
>>>>>>
>>>>>> I'm not sure I understood the final consensus on what we
>>>>>>             
>>> should do
>>>       
>>>>>> for outer VLAN tags on inter-RBridge packets.
>>>>>>
>>>>>> The possibilities I think the consensus might have been are:
>>>>>>
>>>>>> a) only use VLAN 1, explicit tag, no configuration possible.
>>>>>> b) default is VLAN 1, explicit tag, configuration is possible to
>>>>>> change sending with VLAN tag(s) something other than 1.
>>>>>>             
>>> If this is
>>>       
>>>>>> what was decided, I don't believe we've worked out the design
>>>>>> details. I'd assume this would mean RBridges should be willing
>>>>>>             
> to
>   
>>>>>> receive packets from other RBridges regardless of outer VLAN
>>>>>>             
> tag.
>   
>>>>>> Would we then mark in the Hellos what VLAN tag(s) you've
>>>>>>             
>>> heard from
>>>       
>>>>>> what other RBridges with? What do we do with multicast if there
>>>>>> isn't a single VLAN tag that seems to work to send to everyone?
>>>>>> Would we allow configuration to send on a set of VLAN
>>>>>>             
>>> tags, or just
>>>       
>>>>>> on one at a time (and we allow configuration to say which one it
>>>>>> is)?
>>>>>>
>>>>>> Certainly a) is simpler. If the consensus was b), we'd
>>>>>>             
>>> better work
>>>       
>>>>>> out the details.
>>>>>>
>>>>>> Radia
>>>>>> _______________________________________________
>>>>>> rbridge mailing list
>>>>>> [email-masked]
>>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>>
>>>>>>
>>>>>>             
>>>>> _______________________________________________
>>>>> rbridge mailing list
>>>>> [email-masked]
>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>
>>>>>           

Content-class: urn:content-classes:message
Date: Fri, 26 Oct 2007 14:00:04 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Call: Single Pseudo-node Announcment
Status: RO
Content-Length: 1014

This consensus from the Chicago meeting has been confirmed.

Donald & Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Friday, October 12, 2007 2:46 PM
To: [email-masked]
Subject: [rbridge] Consensus Check: Single Pseudo-node Announcment

This is the last of the consensus checks via the mailing list to confirm
or refute an apparent consensus from the minutes of the Chicago meeting
for a change from protocol draft -05:

   Each RBridge which is DRB for one or more VLANs out one physical
   port should announce only one pseudo-node for the port.

If no particular controversy arises over this in the next two weeks, we
will declare it to be the working group consensus.

Please also post any other comments you have on the current -05 protocol
draft. If a revision can be posted in 3 or 4 weeks, we may be able to do
a working group last call before the December IETF TRILL meeting.

Thanks,
Donald & Erik

Content-class: urn:content-classes:message
Date: Fri, 26 Oct 2007 02:16:13 -0700
From: "Silvano Gai" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?
Status: RO
Content-Length: 10913

Assuming that you always have connectivity on VLAN 1 is unrealistic.
Different installation may use VLAN 1 for different purposes.

Forbidding by standard to change this VLAN to another value is not going
to work in products. Products will need to support the capability to
change this value to meet customer needs. They will therefore invent
proprietary mechanism to support a different value. Result: lack of
interoperability.

-- Silvano

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[email-masked]]
> Sent: Thursday, October 25, 2007 10:20 AM
> To: Radia Perlman; Silvano Gai
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-
> RBridgepackets?
> 
> 
> Hi Radia,
> 
> I am fairly comfortable with adopting the single
> VLAN hello proposal and forcing that to be VLAN 1.
> 
> I would rather not have to deal with the complexity
> of making it configurable because even that can
> be subject to misconfiguration and would have its
> own set of issues, but I am also not totally
> opposed to that if someone else feels strongly
> about it.  The main argument for doing that
> would be point (b) in your message -- that
> VLAN 1 was already being used for something
> else and the operator didn't want to use it
> for RBridge control traffic.
> 
> As you point out, it looks like the proposal
> for sending hellos on multiple VLANs would also
> require additional scrutiny/specification before
> it can be adopted.  Unless shown to be absolutely
> necessary, this approach imposes a significant
> processing burden so I would rather see us
> solve the problem with the hellos on VLAN 1
> only.
> 
> Anoop
> 
> > -----Original Message-----
> > From: Radia Perlman [mailto:[email-masked]]
> > Sent: Wednesday, October 24, 2007 2:42 PM
> > To: Silvano Gai
> > Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] Final outcome of outer VLAN tags
> > onRBridge-RBridgepackets?
> >
> > It's always hard to catch up on a thread after being away
> > from email for a couple of days, but Silvano --- both the
> > tone and (lack of) content of your message below makes it
> > really difficult.
> >
> > In order to do quality engineering, we need to understand
> > what all the tradeoffs are, and we have to be able to do
> > discourse in an atmosphere of mutual respect.
> >
> > Saying something like "not doing it my way is 'too weak to be
> > practical', or 'holds water like a pasta strainer' is not
> > engineering. It is attempting to ridicule anyone who
> > disagrees with you, and also is completely uninformative
> > because you are not saying what the tradeoffs are, or even
> > the details of how the thing you want would work.
> >
> > I am usually proud of this WG because we usually do explore
> > all the options and what the tradoffs are without resorting
> > to bullying and ridicule. Let's strive to do engineering that way.
> >
> > So let me demonstrate by getting back to the thread.
> >
> > I think the "downsides" of sending all RBridge-RBridge
> > messages on a single unconfigurable VLAN (proposal being VLAN 1)
are:
> > a) if VLAN 1 is indeed partitioned, the RBridges will not
> > know through IS-IS Hellos that they have RBridge neighbors,
> > and multiple DRBs will be elected. But the proposal also
> > includes how to prevent multiple DRB, namely by being
> > conservative about forwarding data traffic to/from the link
> > until we discover, though reporting the bridge root ID in
> > LSPs, that it is safe to do so
> > b) a customer might want to not use that VLAN for
> > RBridge-RBridge traffic. However, if that customer felt so
> > strongly about minimizing RBridge-Rbridge traffic, they could
> > reconfigure use of the VLANs to move what they were using
> > VLAN 1 to, to some other VLAN. So saying "just use 1" might
> > inconvenience one customer who is already very savvy and
> > likes to do really fancy configuration things, but does not
> > prevent them from accomplishing all the exotic things they
> > are trying to do -- just means some more configuration. And
> > is saves what hopefully is the vast majority of customers
> > from having to do any configuration whatsoever, and
> > simplifies the spec and prevents misconfiguration.
> >
> > The upside of saying "just use 1" is extreme simplicity, and
> > with the safeguards, will not have any higher probabilty of
> > loops than already exists due to repeaters coming up, or
> > bridge spanning tree messages getting lost.
> >
> > The next more complex proposal was to allow configuration to
> > still ultimately use one VLAN per cloud, but allow it to be
> > configurable to be something other than 1. I gave a proposal
> > for doing that in a previous message (the DRB tells all the
> > other RBridges what VLAN to use, while the DRB still sends on
> > VLAN 1 in addition to the VLAN the DRB tells everyone to send
> > one). I think the upside over the simplest "just use 1", is
> > that it allows a customer that doesn't want RBridge-RBridge
> > traffic being used on VLAN 1, or intentionally wants data
> > traffic on VLAN 1 to be partitioned on a cloud, to move to a
> > VLAN on that cloud that is OK not to be partitioned. The
> > downside is that steady state the DRB will send one more
> > Hello (on VLAN 1) than it would have, once the DRB tells all
> > the other RBridges what VLAN to send on, and it is one more
> > configuration thing to have to explain. And it seems likely
> > that the DRB will be misconfigured and declare that RBridges
> > will use VLAN k instead of 1, when some other RBridge on the
> > cloud is not configured to support k. It won't be fatal
> > (since that other RBridge will still hear the DRB on VLAN 1
> > and will also know about the other DRB through link state
> > messages). My opinion is that this extra complexity over
> > "just use 1" is not warranted given the small upside.
> >
> > If there is another proposal, say "send all Hellos on all
> > VLANs", I claim that the details of that have never been
> > specified well enough for that proposal to be evaluated. So
> > if someone who advocates that can do that, staying technical,
> > covering all details like whether in your IS-IS Hello you
> > list all the VLAN tags you've heard Hellos from for each
> > neighbor, and how you send a multicast data message when you
> > have adjacencies with different VLAN tags for different
> > subsets of neighbors, I'd like to hear it.
> >
> > And by all means, if I have missed some of the downsides on
> > "just use VLAN 1", or "just use a single VLAN, but it can be
> > configured to be something other than 1", then by all means
> > add to the arguments.
> >
> > Radia
> >
> >
> >
> >
> > Silvano Gai wrote:
> > > I want to restate that IMHO a design that sends messages on
> > a single
> > > VLAN is so week to be completely useless.
> > >
> > > I met Anoop on a plane back from a T11 meeting and we discussed
the
> > > issue of sending messages on all the configured VLANs.
> > Anoop pointed
> > > out that, if these messages are ISIS messages, this can
> > overload the
> > > RBrige supervisor.
> > >
> > > We identified a possible solution based on two different
> > message types:
> > > - ISIS used on a single VLAN to compute adjacency
> > > - simple per-VLAN checking on all the VLANs to verify
reachability.
> > >
> > > The second kind of messages is much simpler and therefore they
load
> > > less the RBrige supervisor. In the future, per-VLAN checking can
be
> > > implemented by the port ASIC. This seems a viable solution that
> > > requires design effort, but it is promising.
> > >
> > > Without the per-VLAN checking, running ISIS on a single VLAN holds
> > > water like a pasta-strainer.
> > >
> > > -- Silvano
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: [email-masked]
> > [mailto:[email-masked]]
> > >>
> > > On
> > >
> > >> Behalf Of Anoop Ghanwani
> > >> Sent: Monday, October 22, 2007 11:01 AM
> > >> To: Radia Perlman; Developing a hybrid router/bridge.
> > >> Subject: Re: [rbridge] Final outcome of outer VLAN tags
onRBridge-
> > >> RBridgepackets?
> > >>
> > >>
> > >> If we want to make implementations work with only a single
> > Hello for
> > >> all VLANs than the option is (a).  I think that is what it
> > should be.
> > >> Basically, as a part of RBridge configuration there should be a
> > >> "RBridge Control VLAN" configuration that applies to the whole
> > >> device.  It should default to VLAN 1, but an operator can
> > choose to
> > >> change it.
> > >> A RBridge only emits Hellos on that VLAN.  If it receives
> > Hellos on
> > >> any other VLAN that should be detected as an error condition and
> > >> reported.
> > >>
> > >> There have been some problem corner cases that have been
> > pointed out
> > >> previously on the list that may result in temporary duplication
of
> > >> traffic when there is misconfiguration.  Those should be
> > documented.
> > >>
> > >> Anoop
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: [email-masked]
> > >>> [mailto:[email-masked]] On Behalf Of Radia Perlman
> > >>> Sent: Saturday, October 20, 2007 9:47 PM
> > >>> To: Developing a hybrid router/bridge.
> > >>> Subject: [rbridge] Final outcome of outer VLAN tags on
> > >>> RBridge-RBridgepackets?
> > >>>
> > >>> I'm not sure I understood the final consensus on what we
> > should do
> > >>> for outer VLAN tags on inter-RBridge packets.
> > >>>
> > >>> The possibilities I think the consensus might have been are:
> > >>>
> > >>> a) only use VLAN 1, explicit tag, no configuration possible.
> > >>> b) default is VLAN 1, explicit tag, configuration is possible to
> > >>> change sending with VLAN tag(s) something other than 1.
> > If this is
> > >>> what was decided, I don't believe we've worked out the design
> > >>> details. I'd assume this would mean RBridges should be willing
to
> > >>> receive packets from other RBridges regardless of outer VLAN
tag.
> > >>> Would we then mark in the Hellos what VLAN tag(s) you've
> > heard from
> > >>> what other RBridges with? What do we do with multicast if there
> > >>> isn't a single VLAN tag that seems to work to send to everyone?
> > >>> Would we allow configuration to send on a set of VLAN
> > tags, or just
> > >>> on one at a time (and we allow configuration to say which one it
> > >>> is)?
> > >>>
> > >>> Certainly a) is simpler. If the consensus was b), we'd
> > better work
> > >>> out the details.
> > >>>
> > >>> Radia
> > >>> _______________________________________________
> > >>> rbridge mailing list
> > >>> [email-masked]
> > >>> http://mailman.postel.org/mailman/listinfo/rbridge
> > >>>
> > >>>
> > >> _______________________________________________
> > >> rbridge mailing list
> > >> [email-masked]
> > >> http://mailman.postel.org/mailman/listinfo/rbridge
> > >>
> >

Date: Thu, 25 Oct 2007 22:26:28 -0700
From: Radia Perlman <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
Status: RO
Content-Length: 7448

Right...I was not intending to preclude having R1 be DRB for (inner) 
VLANs (v1, v2, v3) and
R2 be DRB for (inner) VLANs (v4, v5, v6). However, as you point out, if 
each RBridge can
be configured with a different priority for each of the 4000 VLANs, the 
IS-IS Hello would
get too large. The only reason for different priorities is to do some 
load splitting. I'd argue
that with just a tiny bit of flexibility customers can get enough 
functionality. So I'd suggest
limiting multiple priorities to some reasonable number, like 3, and sets 
of VLANs to ranges.
That would mean that R1 can claim to have priority P1 for the VLANs in 
range (n1-n2), and
priority P2 for the VLANs in range (n3-n4), and priority P3 for VLANs 
betwen (n5-n6).
This would require (for 3 different priorities) 18 bytes in the Hello. 
For instance, "I have
priority 7 for VLANs (1-50) and priority 12 for VLANs (61-80), and 
priority 2 for
VLANs (101-115). Perhaps another 500 bytes to do a bit mask of all the 
VLANs that
you support at all (or alternatively you can't claim to have a priority 
for a range of VLANs unless
you support all the VLANs in that range).

Likewise, in the pseudonode, we'd have to say the range of VLANs that 
that pseudonode
refers to.

And it's NOT a DRB collision if there is a pseudonode, say R1,17,
for which R1 is DRB, reporting root bridge X
and R2 is DRB on a link with root bridge X as long as the set of VLANs 
reported
in R1.17's LSP does not overlap with the set of VLANs that R2 is DRB for 
on that link.

And actually, R2 really only needs to decline to forward data (act as 
DRB) for the set of
VLANs in R1.17's pseudonode that overlaps with R2's. It could be that R2 
has some
other VLANs that are not in R1.17's pseudonode.

So that's an additional refinement on the rules that should be added.

Perhaps we should start a different thread on whether people can live 
with having a single
DRB be configured with at most 3 priorities on a port, and require the 
set of VLANs for
each priority to be expressible in a range (rather than having to 
enumerate each of the
VLAN tags individually).

Radia

Eastlake III Donald-LDE008 wrote:
> Hi Radia,
>
> The proposal below appears to be written from the "one DRB per link"
> point of view while the current draft claims to support "one DRB per
> VLAN per link". Even if you have complete VLAN 1 connectivity and use
> single Hellos, I'm not quite sure how the one DRB per VLAN per link
> would work. In principle, the per VLAN priority for a Rbridge port for
> all its configured VLANs might not fit into a Hello...
>
> Thanks,
> Donald
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Radia Perlman
> Sent: Thursday, October 25, 2007 2:56 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] A "multiple VLAN Hello" proposal
>
> It's a bit difficult to argue on the list about proposals when one of 
> them has not been specified, especially
> since I can imagine lots of variations on multiple VLANs, and lots of 
> questions about choices for
> the details.
>
> Here's an attempt to specify a "send Hellos on multiple VLANs" proposal.
>
> I've chosen details
> where in many cases there are other options I could have chosen. But I 
> think we need some
> tangible proposal with details worked out before advocating for it. 
> People should feel free
> to suggest modifications to the details below, but I, as I said, cannot 
> argue between proposals
> if the proposals aren't concrete. I've tried to make it as simple as 
> possible, as low overhead
> as possible, while adding the ability to configure sending Hellos on 
> lots of VLANs.
>
>
> a) RBridges send and receive IS-IS Hellos on VLAN 1
>
> b) In addition, RBridges MAY be configured to send and receive Hellos on
>
> some set of
> VLANs in addition to 1
>
> c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the VLANs that 
> R1 is
> configured to send (and receive) on. To clarify, as long as R1 thinks 
> itself is DRB, it will
> send Hellos on the complete set of VLANs that R1 is configured to send 
> on. In addition (see
> point "e"), R1 may wind up having to send Hellos on some set of VLANs in
>
> addition
> to those it was configured to send on.
>
> d) In IS-IS's Hello, R1 reports the set of neighbor RBridges R1 has 
> heard Hellos from. In addition,
> R1 reports in R1's Hello, for each neighbor R2, *one* VLAN that R1 hears
>
> hellos from R2 on.
> The one VLAN that R1 reports is the lowest numbered VLAN that R1 hears a
>
> Hello from R2 on.
>
> e) If R1 does not hear a Hello from R2 on any of R1's configured VLANs,
> but does hear on some other VLAN, say VLAN x, then R1 adds "x" to the 
> set of VLANs that
> R1 transmits on, as long as it continues to hear Hellos on VLAN x (and
> no
> other VLANs) from R2. Note that if R2's Hello gives R2 better priority
> for
> being DRB, then R1 will not be DRB any more, but MUST continue sending 
> Hellos on
> VLAN x (even though x is not in the set of VLANs
> that R1 was configured to send on) to ensure that R2 continues to send 
> its Hellos on VLAN x.
>
> e) if you are *not* the DRB, you send Hellos on VLAN 1 plus the VLAN 
> that the DRB reports
> that it has heard from you on. This cuts down on Hellos since it means 
> that non-DRB RBridges
> will send on at most two VLANs.
> {Note: An alternate option would have had every RBridge send Hellos 
> always on all VLANs they
> have been configured to send on}.
>
> f) all RBridge-RBridge traffic (other than Hellos) is always sent on 
> VLAN 1. So if R2 cannot
> reach the DRB via VLAN 1, then R2 cannot forward data to/from that 
> cloud, or receive
> LSPs on that cloud. In other words, that link will be broken for R2. The
>
> purpose
> of the Hellos is only to notice (through a means *in addition* to the 
> safeguards in the other
> proposals)  that R2 is not DRB for the link.
>
> g) We do the same safeguards as in the other proposals (report the
> bridge root ID in the pseudonode LSP, don't decapsulate from ingress Ra 
> unless
> you have all the relevant pseudonode LSPs attached to Ra to ensure that 
> none of them have
> the same root RBridge, and that you delay before encapsulating data off 
> the link until you've
> been DRB for enough time to synchronize LSP databases with your
> neighbors)
>
> **************
> My thoughts on this:
>
> a) I assume the only reason to send Hellos on multiple VLANs is to 
> minimize the probability
> of accidentally having two DRBs, and therefore loops. I'm not convinced 
> this adds safety
> over the safeguards in the single VLAN proposals.
>
> b) this winds up with sending lots more Hellos, but does not create 
> additional pseudonodes,
> or complicate data forwarding, because the Hellos is only to find 
> neighbors, not to repair
> use of the link for forwarding data (or propagating LSPs) if VLAN 1 is 
> partitioned on the link
>
> c) This is a lot more complicated. It might seem simpler to not try to 
> optimize the number of
> Hellos (like I did in point e), but there seem to be scary corner cases 
> where all the VLANs
> common to R1 and R2 are partitioned. Saying there must be an 
> unpartitioned VLAN 1 seems
> the safest.
>
> So, I still like the "just use VLAN 1" proposal.
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

Content-class: urn:content-classes:message
Date: Thu, 25 Oct 2007 22:03:51 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
Status: RO
Content-Length: 6256

Donald,

Once you've established connectivity over VLAN 1,
you can then exchange the list of VLANs that are
configured on that RBridge port and arbitrate 
which RBridge becomes designated for each VLAN.
For example, if RB1 has VLANs {2,4,6,8} and
RB2 has VLANs {3,5,7,9} configured, then they
will both become DRBs for those set of VLANs 
because there is no overlap.  For the ones that
there is overlap, there will need to be a tie
breaking mechanism.

Anoop 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Thursday, October 25, 2007 9:43 PM
> To: Radia Perlman
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
> 
> Hi Radia,
> 
> The proposal below appears to be written from the "one DRB per link"
> point of view while the current draft claims to support "one 
> DRB per VLAN per link". Even if you have complete VLAN 1 
> connectivity and use single Hellos, I'm not quite sure how 
> the one DRB per VLAN per link would work. In principle, the 
> per VLAN priority for a Rbridge port for all its configured 
> VLANs might not fit into a Hello...
> 
> Thanks,
> Donald
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Thursday, October 25, 2007 2:56 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] A "multiple VLAN Hello" proposal
> 
> It's a bit difficult to argue on the list about proposals 
> when one of them has not been specified, especially since I 
> can imagine lots of variations on multiple VLANs, and lots of 
> questions about choices for the details.
> 
> Here's an attempt to specify a "send Hellos on multiple 
> VLANs" proposal.
> 
> I've chosen details
> where in many cases there are other options I could have 
> chosen. But I think we need some tangible proposal with 
> details worked out before advocating for it. 
> People should feel free
> to suggest modifications to the details below, but I, as I 
> said, cannot argue between proposals if the proposals aren't 
> concrete. I've tried to make it as simple as possible, as low 
> overhead as possible, while adding the ability to configure 
> sending Hellos on lots of VLANs.
> 
> 
> a) RBridges send and receive IS-IS Hellos on VLAN 1
> 
> b) In addition, RBridges MAY be configured to send and 
> receive Hellos on
> 
> some set of
> VLANs in addition to 1
> 
> c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the 
> VLANs that
> R1 is
> configured to send (and receive) on. To clarify, as long as 
> R1 thinks itself is DRB, it will send Hellos on the complete 
> set of VLANs that R1 is configured to send on. In addition 
> (see point "e"), R1 may wind up having to send Hellos on some 
> set of VLANs in
> 
> addition
> to those it was configured to send on.
> 
> d) In IS-IS's Hello, R1 reports the set of neighbor RBridges 
> R1 has heard Hellos from. In addition,
> R1 reports in R1's Hello, for each neighbor R2, *one* VLAN 
> that R1 hears
> 
> hellos from R2 on.
> The one VLAN that R1 reports is the lowest numbered VLAN that 
> R1 hears a
> 
> Hello from R2 on.
> 
> e) If R1 does not hear a Hello from R2 on any of R1's 
> configured VLANs, but does hear on some other VLAN, say VLAN 
> x, then R1 adds "x" to the set of VLANs that
> R1 transmits on, as long as it continues to hear Hellos on 
> VLAN x (and no other VLANs) from R2. Note that if R2's Hello 
> gives R2 better priority for being DRB, then R1 will not be 
> DRB any more, but MUST continue sending Hellos on VLAN x 
> (even though x is not in the set of VLANs that R1 was 
> configured to send on) to ensure that R2 continues to send 
> its Hellos on VLAN x.
> 
> e) if you are *not* the DRB, you send Hellos on VLAN 1 plus 
> the VLAN that the DRB reports that it has heard from you on. 
> This cuts down on Hellos since it means that non-DRB RBridges 
> will send on at most two VLANs.
> {Note: An alternate option would have had every RBridge send 
> Hellos always on all VLANs they have been configured to send on}.
> 
> f) all RBridge-RBridge traffic (other than Hellos) is always 
> sent on VLAN 1. So if R2 cannot reach the DRB via VLAN 1, 
> then R2 cannot forward data to/from that cloud, or receive 
> LSPs on that cloud. In other words, that link will be broken 
> for R2. The
> 
> purpose
> of the Hellos is only to notice (through a means *in 
> addition* to the safeguards in the other
> proposals)  that R2 is not DRB for the link.
> 
> g) We do the same safeguards as in the other proposals 
> (report the bridge root ID in the pseudonode LSP, don't 
> decapsulate from ingress Ra unless you have all the relevant 
> pseudonode LSPs attached to Ra to ensure that none of them 
> have the same root RBridge, and that you delay before 
> encapsulating data off the link until you've been DRB for 
> enough time to synchronize LSP databases with your
> neighbors)
> 
> **************
> My thoughts on this:
> 
> a) I assume the only reason to send Hellos on multiple VLANs 
> is to minimize the probability of accidentally having two 
> DRBs, and therefore loops. I'm not convinced this adds safety 
> over the safeguards in the single VLAN proposals.
> 
> b) this winds up with sending lots more Hellos, but does not 
> create additional pseudonodes, or complicate data forwarding, 
> because the Hellos is only to find neighbors, not to repair 
> use of the link for forwarding data (or propagating LSPs) if 
> VLAN 1 is partitioned on the link
> 
> c) This is a lot more complicated. It might seem simpler to 
> not try to optimize the number of Hellos (like I did in point 
> e), but there seem to be scary corner cases where all the 
> VLANs common to R1 and R2 are partitioned. Saying there must 
> be an unpartitioned VLAN 1 seems the safest.
> 
> So, I still like the "just use VLAN 1" proposal.
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Fri, 26 Oct 2007 00:43:01 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
Status: RO
Content-Length: 5033

Hi Radia,

The proposal below appears to be written from the "one DRB per link"
point of view while the current draft claims to support "one DRB per
VLAN per link". Even if you have complete VLAN 1 connectivity and use
single Hellos, I'm not quite sure how the one DRB per VLAN per link
would work. In principle, the per VLAN priority for a Rbridge port for
all its configured VLANs might not fit into a Hello...

Thanks,
Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Thursday, October 25, 2007 2:56 PM
To: Developing a hybrid router/bridge.
Subject: [rbridge] A "multiple VLAN Hello" proposal

It's a bit difficult to argue on the list about proposals when one of 
them has not been specified, especially
since I can imagine lots of variations on multiple VLANs, and lots of 
questions about choices for
the details.

Here's an attempt to specify a "send Hellos on multiple VLANs" proposal.

I've chosen details
where in many cases there are other options I could have chosen. But I 
think we need some
tangible proposal with details worked out before advocating for it. 
People should feel free
to suggest modifications to the details below, but I, as I said, cannot 
argue between proposals
if the proposals aren't concrete. I've tried to make it as simple as 
possible, as low overhead
as possible, while adding the ability to configure sending Hellos on 
lots of VLANs.

a) RBridges send and receive IS-IS Hellos on VLAN 1

b) In addition, RBridges MAY be configured to send and receive Hellos on

some set of
VLANs in addition to 1

c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the VLANs that 
R1 is
configured to send (and receive) on. To clarify, as long as R1 thinks 
itself is DRB, it will
send Hellos on the complete set of VLANs that R1 is configured to send 
on. In addition (see
point "e"), R1 may wind up having to send Hellos on some set of VLANs in

addition
to those it was configured to send on.

d) In IS-IS's Hello, R1 reports the set of neighbor RBridges R1 has 
heard Hellos from. In addition,
R1 reports in R1's Hello, for each neighbor R2, *one* VLAN that R1 hears

hellos from R2 on.
The one VLAN that R1 reports is the lowest numbered VLAN that R1 hears a

Hello from R2 on.

e) If R1 does not hear a Hello from R2 on any of R1's configured VLANs,
but does hear on some other VLAN, say VLAN x, then R1 adds "x" to the 
set of VLANs that
R1 transmits on, as long as it continues to hear Hellos on VLAN x (and
no
other VLANs) from R2. Note that if R2's Hello gives R2 better priority
for
being DRB, then R1 will not be DRB any more, but MUST continue sending 
Hellos on
VLAN x (even though x is not in the set of VLANs
that R1 was configured to send on) to ensure that R2 continues to send 
its Hellos on VLAN x.

e) if you are *not* the DRB, you send Hellos on VLAN 1 plus the VLAN 
that the DRB reports
that it has heard from you on. This cuts down on Hellos since it means 
that non-DRB RBridges
will send on at most two VLANs.
{Note: An alternate option would have had every RBridge send Hellos 
always on all VLANs they
have been configured to send on}.

f) all RBridge-RBridge traffic (other than Hellos) is always sent on 
VLAN 1. So if R2 cannot
reach the DRB via VLAN 1, then R2 cannot forward data to/from that 
cloud, or receive
LSPs on that cloud. In other words, that link will be broken for R2. The

purpose
of the Hellos is only to notice (through a means *in addition* to the 
safeguards in the other
proposals)  that R2 is not DRB for the link.

g) We do the same safeguards as in the other proposals (report the
bridge root ID in the pseudonode LSP, don't decapsulate from ingress Ra 
unless
you have all the relevant pseudonode LSPs attached to Ra to ensure that 
none of them have
the same root RBridge, and that you delay before encapsulating data off 
the link until you've
been DRB for enough time to synchronize LSP databases with your
neighbors)

**************
My thoughts on this:

a) I assume the only reason to send Hellos on multiple VLANs is to 
minimize the probability
of accidentally having two DRBs, and therefore loops. I'm not convinced 
this adds safety
over the safeguards in the single VLAN proposals.

b) this winds up with sending lots more Hellos, but does not create 
additional pseudonodes,
or complicate data forwarding, because the Hellos is only to find 
neighbors, not to repair
use of the link for forwarding data (or propagating LSPs) if VLAN 1 is 
partitioned on the link

c) This is a lot more complicated. It might seem simpler to not try to 
optimize the number of
Hellos (like I did in point e), but there seem to be scary corner cases 
where all the VLANs
common to R1 and R2 are partitioned. Saying there must be an 
unpartitioned VLAN 1 seems
the safest.

So, I still like the "just use VLAN 1" proposal.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Fri, 26 Oct 2007 00:44:48 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
Status: RO
Content-Length: 5993

Hi Anoop,

I don't look at it that way at all. We get to say what "correct" and
"incorrect" behavior are for Rbridges.

TRILL Ethertype frames are special. The Outer VLAN tag on a TRILL
Ethertype frame is just a transport artifact added to enable the frame
to get through a Bridged LAN that is in the way. It is unnecessary on
point-to-point links. If an Outer VLAN tag is present on a TRILL frame,
it shouldn't affect whether the frame is processed.

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anoop Ghanwani
Sent: Thursday, October 25, 2007 5:39 PM
To: Radia Perlman; Developing a hybrid router/bridge.
Subject: Re: [rbridge] A "multiple VLAN Hello" proposal

Radia,

Step "e" would be considered incorrect behavior
w.r.t. VLANs.  If an end station is not configured
with a certain VLAN, it should not be receiving and
trying to process packets from that VLAN.  In this
case, the end station is the management port running
IS-IS.

Anoop 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Thursday, October 25, 2007 11:56 AM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] A "multiple VLAN Hello" proposal
> 
> It's a bit difficult to argue on the list about proposals 
> when one of them has not been specified, especially since I 
> can imagine lots of variations on multiple VLANs, and lots of 
> questions about choices for the details.
> 
> Here's an attempt to specify a "send Hellos on multiple 
> VLANs" proposal. 
> I've chosen details
> where in many cases there are other options I could have 
> chosen. But I think we need some tangible proposal with 
> details worked out before advocating for it. 
> People should feel free
> to suggest modifications to the details below, but I, as I 
> said, cannot argue between proposals if the proposals aren't 
> concrete. I've tried to make it as simple as possible, as low 
> overhead as possible, while adding the ability to configure 
> sending Hellos on lots of VLANs.
> 
> 
> a) RBridges send and receive IS-IS Hellos on VLAN 1
> 
> b) In addition, RBridges MAY be configured to send and 
> receive Hellos on some set of VLANs in addition to 1
> 
> c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the 
> VLANs that
> R1 is
> configured to send (and receive) on. To clarify, as long as 
> R1 thinks itself is DRB, it will send Hellos on the complete 
> set of VLANs that R1 is configured to send on. In addition 
> (see point "e"), R1 may wind up having to send Hellos on some 
> set of VLANs in addition to those it was configured to send on.
> 
> d) In IS-IS's Hello, R1 reports the set of neighbor RBridges 
> R1 has heard Hellos from. In addition,
> R1 reports in R1's Hello, for each neighbor R2, *one* VLAN 
> that R1 hears hellos from R2 on.
> The one VLAN that R1 reports is the lowest numbered VLAN that 
> R1 hears a Hello from R2 on.
> 
> e) If R1 does not hear a Hello from R2 on any of R1's 
> configured VLANs, but does hear on some other VLAN, say VLAN 
> x, then R1 adds "x" to the set of VLANs that
> R1 transmits on, as long as it continues to hear Hellos on 
> VLAN x (and no other VLANs) from R2. Note that if R2's Hello 
> gives R2 better priority for being DRB, then R1 will not be 
> DRB any more, but MUST continue sending Hellos on VLAN x 
> (even though x is not in the set of VLANs that R1 was 
> configured to send on) to ensure that R2 continues to send 
> its Hellos on VLAN x.
> 
> e) if you are *not* the DRB, you send Hellos on VLAN 1 plus 
> the VLAN that the DRB reports that it has heard from you on. 
> This cuts down on Hellos since it means that non-DRB RBridges 
> will send on at most two VLANs.
> {Note: An alternate option would have had every RBridge send 
> Hellos always on all VLANs they have been configured to send on}.
> 
> f) all RBridge-RBridge traffic (other than Hellos) is always 
> sent on VLAN 1. So if R2 cannot reach the DRB via VLAN 1, 
> then R2 cannot forward data to/from that cloud, or receive 
> LSPs on that cloud. In other words, that link will be broken 
> for R2. The purpose of the Hellos is only to notice (through 
> a means *in addition* to the safeguards in the other
> proposals)  that R2 is not DRB for the link.
> 
> g) We do the same safeguards as in the other proposals 
> (report the bridge root ID in the pseudonode LSP, don't 
> decapsulate from ingress Ra unless you have all the relevant 
> pseudonode LSPs attached to Ra to ensure that none of them 
> have the same root RBridge, and that you delay before 
> encapsulating data off the link until you've been DRB for 
> enough time to synchronize LSP databases with your neighbors)
> 
> **************
> My thoughts on this:
> 
> a) I assume the only reason to send Hellos on multiple VLANs 
> is to minimize the probability of accidentally having two 
> DRBs, and therefore loops. I'm not convinced this adds safety 
> over the safeguards in the single VLAN proposals.
> 
> b) this winds up with sending lots more Hellos, but does not 
> create additional pseudonodes, or complicate data forwarding, 
> because the Hellos is only to find neighbors, not to repair 
> use of the link for forwarding data (or propagating LSPs) if 
> VLAN 1 is partitioned on the link
> 
> c) This is a lot more complicated. It might seem simpler to 
> not try to optimize the number of Hellos (like I did in point 
> e), but there seem to be scary corner cases where all the 
> VLANs common to R1 and R2 are partitioned. Saying there must 
> be an unpartitioned VLAN 1 seems the safest.
> 
> So, I still like the "just use VLAN 1" proposal.
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

Date: Thu, 25 Oct 2007 19:47:03 -0700
From: Radia Perlman <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
Status: RO
Content-Length: 5879

Hmm. I was wondering if an RBridge might be able to receive on a VLAN 
that it
isn't configured to officially support. But actually, what I meant was 
that I was
assuming there might be a large subset of VLANs that the RBridge can 
send and
receive on. and some smaller subset of those that it is configured to 
send IS-IS Hellos on.
So if an RBridge does support all 4000 VLANs, by default it would only 
send IS-IS Hellos
on VLAN 1, but would receive on any of them. And it might be configured 
to send on
a subset of the supported VLANs, but hopefully not all 4000. So that's 
what I was trying to get at.

Radia

Anoop Ghanwani wrote:
> Radia,
>
> Step "e" would be considered incorrect behavior
> w.r.t. VLANs.  If an end station is not configured
> with a certain VLAN, it should not be receiving and
> trying to process packets from that VLAN.  In this
> case, the end station is the management port running
> IS-IS.
>
> Anoop 
>
>   
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Radia Perlman
>> Sent: Thursday, October 25, 2007 11:56 AM
>> To: Developing a hybrid router/bridge.
>> Subject: [rbridge] A "multiple VLAN Hello" proposal
>>
>> It's a bit difficult to argue on the list about proposals 
>> when one of them has not been specified, especially since I 
>> can imagine lots of variations on multiple VLANs, and lots of 
>> questions about choices for the details.
>>
>> Here's an attempt to specify a "send Hellos on multiple 
>> VLANs" proposal. 
>> I've chosen details
>> where in many cases there are other options I could have 
>> chosen. But I think we need some tangible proposal with 
>> details worked out before advocating for it. 
>> People should feel free
>> to suggest modifications to the details below, but I, as I 
>> said, cannot argue between proposals if the proposals aren't 
>> concrete. I've tried to make it as simple as possible, as low 
>> overhead as possible, while adding the ability to configure 
>> sending Hellos on lots of VLANs.
>>
>>
>> a) RBridges send and receive IS-IS Hellos on VLAN 1
>>
>> b) In addition, RBridges MAY be configured to send and 
>> receive Hellos on some set of VLANs in addition to 1
>>
>> c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the 
>> VLANs that
>> R1 is
>> configured to send (and receive) on. To clarify, as long as 
>> R1 thinks itself is DRB, it will send Hellos on the complete 
>> set of VLANs that R1 is configured to send on. In addition 
>> (see point "e"), R1 may wind up having to send Hellos on some 
>> set of VLANs in addition to those it was configured to send on.
>>
>> d) In IS-IS's Hello, R1 reports the set of neighbor RBridges 
>> R1 has heard Hellos from. In addition,
>> R1 reports in R1's Hello, for each neighbor R2, *one* VLAN 
>> that R1 hears hellos from R2 on.
>> The one VLAN that R1 reports is the lowest numbered VLAN that 
>> R1 hears a Hello from R2 on.
>>
>> e) If R1 does not hear a Hello from R2 on any of R1's 
>> configured VLANs, but does hear on some other VLAN, say VLAN 
>> x, then R1 adds "x" to the set of VLANs that
>> R1 transmits on, as long as it continues to hear Hellos on 
>> VLAN x (and no other VLANs) from R2. Note that if R2's Hello 
>> gives R2 better priority for being DRB, then R1 will not be 
>> DRB any more, but MUST continue sending Hellos on VLAN x 
>> (even though x is not in the set of VLANs that R1 was 
>> configured to send on) to ensure that R2 continues to send 
>> its Hellos on VLAN x.
>>
>> e) if you are *not* the DRB, you send Hellos on VLAN 1 plus 
>> the VLAN that the DRB reports that it has heard from you on. 
>> This cuts down on Hellos since it means that non-DRB RBridges 
>> will send on at most two VLANs.
>> {Note: An alternate option would have had every RBridge send 
>> Hellos always on all VLANs they have been configured to send on}.
>>
>> f) all RBridge-RBridge traffic (other than Hellos) is always 
>> sent on VLAN 1. So if R2 cannot reach the DRB via VLAN 1, 
>> then R2 cannot forward data to/from that cloud, or receive 
>> LSPs on that cloud. In other words, that link will be broken 
>> for R2. The purpose of the Hellos is only to notice (through 
>> a means *in addition* to the safeguards in the other
>> proposals)  that R2 is not DRB for the link.
>>
>> g) We do the same safeguards as in the other proposals 
>> (report the bridge root ID in the pseudonode LSP, don't 
>> decapsulate from ingress Ra unless you have all the relevant 
>> pseudonode LSPs attached to Ra to ensure that none of them 
>> have the same root RBridge, and that you delay before 
>> encapsulating data off the link until you've been DRB for 
>> enough time to synchronize LSP databases with your neighbors)
>>
>> **************
>> My thoughts on this:
>>
>> a) I assume the only reason to send Hellos on multiple VLANs 
>> is to minimize the probability of accidentally having two 
>> DRBs, and therefore loops. I'm not convinced this adds safety 
>> over the safeguards in the single VLAN proposals.
>>
>> b) this winds up with sending lots more Hellos, but does not 
>> create additional pseudonodes, or complicate data forwarding, 
>> because the Hellos is only to find neighbors, not to repair 
>> use of the link for forwarding data (or propagating LSPs) if 
>> VLAN 1 is partitioned on the link
>>
>> c) This is a lot more complicated. It might seem simpler to 
>> not try to optimize the number of Hellos (like I did in point 
>> e), but there seem to be scary corner cases where all the 
>> VLANs common to R1 and R2 are partitioned. Saying there must 
>> be an unpartitioned VLAN 1 seems the safest.
>>
>> So, I still like the "just use VLAN 1" proposal.
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>     

Content-class: urn:content-classes:message
Date: Thu, 25 Oct 2007 14:38:57 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
Status: RO
Content-Length: 5118

Radia,

Step "e" would be considered incorrect behavior
w.r.t. VLANs.  If an end station is not configured
with a certain VLAN, it should not be receiving and
trying to process packets from that VLAN.  In this
case, the end station is the management port running
IS-IS.

Anoop 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Thursday, October 25, 2007 11:56 AM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] A "multiple VLAN Hello" proposal
> 
> It's a bit difficult to argue on the list about proposals 
> when one of them has not been specified, especially since I 
> can imagine lots of variations on multiple VLANs, and lots of 
> questions about choices for the details.
> 
> Here's an attempt to specify a "send Hellos on multiple 
> VLANs" proposal. 
> I've chosen details
> where in many cases there are other options I could have 
> chosen. But I think we need some tangible proposal with 
> details worked out before advocating for it. 
> People should feel free
> to suggest modifications to the details below, but I, as I 
> said, cannot argue between proposals if the proposals aren't 
> concrete. I've tried to make it as simple as possible, as low 
> overhead as possible, while adding the ability to configure 
> sending Hellos on lots of VLANs.
> 
> 
> a) RBridges send and receive IS-IS Hellos on VLAN 1
> 
> b) In addition, RBridges MAY be configured to send and 
> receive Hellos on some set of VLANs in addition to 1
> 
> c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the 
> VLANs that
> R1 is
> configured to send (and receive) on. To clarify, as long as 
> R1 thinks itself is DRB, it will send Hellos on the complete 
> set of VLANs that R1 is configured to send on. In addition 
> (see point "e"), R1 may wind up having to send Hellos on some 
> set of VLANs in addition to those it was configured to send on.
> 
> d) In IS-IS's Hello, R1 reports the set of neighbor RBridges 
> R1 has heard Hellos from. In addition,
> R1 reports in R1's Hello, for each neighbor R2, *one* VLAN 
> that R1 hears hellos from R2 on.
> The one VLAN that R1 reports is the lowest numbered VLAN that 
> R1 hears a Hello from R2 on.
> 
> e) If R1 does not hear a Hello from R2 on any of R1's 
> configured VLANs, but does hear on some other VLAN, say VLAN 
> x, then R1 adds "x" to the set of VLANs that
> R1 transmits on, as long as it continues to hear Hellos on 
> VLAN x (and no other VLANs) from R2. Note that if R2's Hello 
> gives R2 better priority for being DRB, then R1 will not be 
> DRB any more, but MUST continue sending Hellos on VLAN x 
> (even though x is not in the set of VLANs that R1 was 
> configured to send on) to ensure that R2 continues to send 
> its Hellos on VLAN x.
> 
> e) if you are *not* the DRB, you send Hellos on VLAN 1 plus 
> the VLAN that the DRB reports that it has heard from you on. 
> This cuts down on Hellos since it means that non-DRB RBridges 
> will send on at most two VLANs.
> {Note: An alternate option would have had every RBridge send 
> Hellos always on all VLANs they have been configured to send on}.
> 
> f) all RBridge-RBridge traffic (other than Hellos) is always 
> sent on VLAN 1. So if R2 cannot reach the DRB via VLAN 1, 
> then R2 cannot forward data to/from that cloud, or receive 
> LSPs on that cloud. In other words, that link will be broken 
> for R2. The purpose of the Hellos is only to notice (through 
> a means *in addition* to the safeguards in the other
> proposals)  that R2 is not DRB for the link.
> 
> g) We do the same safeguards as in the other proposals 
> (report the bridge root ID in the pseudonode LSP, don't 
> decapsulate from ingress Ra unless you have all the relevant 
> pseudonode LSPs attached to Ra to ensure that none of them 
> have the same root RBridge, and that you delay before 
> encapsulating data off the link until you've been DRB for 
> enough time to synchronize LSP databases with your neighbors)
> 
> **************
> My thoughts on this:
> 
> a) I assume the only reason to send Hellos on multiple VLANs 
> is to minimize the probability of accidentally having two 
> DRBs, and therefore loops. I'm not convinced this adds safety 
> over the safeguards in the single VLAN proposals.
> 
> b) this winds up with sending lots more Hellos, but does not 
> create additional pseudonodes, or complicate data forwarding, 
> because the Hellos is only to find neighbors, not to repair 
> use of the link for forwarding data (or propagating LSPs) if 
> VLAN 1 is partitioned on the link
> 
> c) This is a lot more complicated. It might seem simpler to 
> not try to optimize the number of Hellos (like I did in point 
> e), but there seem to be scary corner cases where all the 
> VLANs common to R1 and R2 are partitioned. Saying there must 
> be an unpartitioned VLAN 1 seems the safest.
> 
> So, I still like the "just use VLAN 1" proposal.
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Date: Thu, 25 Oct 2007 11:55:31 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] A "multiple VLAN Hello" proposal
Status: RO
Content-Length: 4207

It's a bit difficult to argue on the list about proposals when one of 
them has not been specified, especially
since I can imagine lots of variations on multiple VLANs, and lots of 
questions about choices for
the details.

Here's an attempt to specify a "send Hellos on multiple VLANs" proposal. 
I've chosen details
where in many cases there are other options I could have chosen. But I 
think we need some
tangible proposal with details worked out before advocating for it. 
People should feel free
to suggest modifications to the details below, but I, as I said, cannot 
argue between proposals
if the proposals aren't concrete. I've tried to make it as simple as 
possible, as low overhead
as possible, while adding the ability to configure sending Hellos on 
lots of VLANs.

a) RBridges send and receive IS-IS Hellos on VLAN 1

b) In addition, RBridges MAY be configured to send and receive Hellos on 
some set of
VLANs in addition to 1

c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the VLANs that 
R1 is
configured to send (and receive) on. To clarify, as long as R1 thinks 
itself is DRB, it will
send Hellos on the complete set of VLANs that R1 is configured to send 
on. In addition (see
point "e"), R1 may wind up having to send Hellos on some set of VLANs in 
addition
to those it was configured to send on.

d) In IS-IS's Hello, R1 reports the set of neighbor RBridges R1 has 
heard Hellos from. In addition,
R1 reports in R1's Hello, for each neighbor R2, *one* VLAN that R1 hears 
hellos from R2 on.
The one VLAN that R1 reports is the lowest numbered VLAN that R1 hears a 
Hello from R2 on.

e) If R1 does not hear a Hello from R2 on any of R1's configured VLANs,
but does hear on some other VLAN, say VLAN x, then R1 adds "x" to the 
set of VLANs that
R1 transmits on, as long as it continues to hear Hellos on VLAN x (and no
other VLANs) from R2. Note that if R2's Hello gives R2 better priority for
being DRB, then R1 will not be DRB any more, but MUST continue sending 
Hellos on
VLAN x (even though x is not in the set of VLANs
that R1 was configured to send on) to ensure that R2 continues to send 
its Hellos on VLAN x.

e) if you are *not* the DRB, you send Hellos on VLAN 1 plus the VLAN 
that the DRB reports
that it has heard from you on. This cuts down on Hellos since it means 
that non-DRB RBridges
will send on at most two VLANs.
{Note: An alternate option would have had every RBridge send Hellos 
always on all VLANs they
have been configured to send on}.

f) all RBridge-RBridge traffic (other than Hellos) is always sent on 
VLAN 1. So if R2 cannot
reach the DRB via VLAN 1, then R2 cannot forward data to/from that 
cloud, or receive
LSPs on that cloud. In other words, that link will be broken for R2. The 
purpose
of the Hellos is only to notice (through a means *in addition* to the 
safeguards in the other
proposals)  that R2 is not DRB for the link.

g) We do the same safeguards as in the other proposals (report the
bridge root ID in the pseudonode LSP, don't decapsulate from ingress Ra 
unless
you have all the relevant pseudonode LSPs attached to Ra to ensure that 
none of them have
the same root RBridge, and that you delay before encapsulating data off 
the link until you've
been DRB for enough time to synchronize LSP databases with your neighbors)

**************
My thoughts on this:

a) I assume the only reason to send Hellos on multiple VLANs is to 
minimize the probability
of accidentally having two DRBs, and therefore loops. I'm not convinced 
this adds safety
over the safeguards in the single VLAN proposals.

b) this winds up with sending lots more Hellos, but does not create 
additional pseudonodes,
or complicate data forwarding, because the Hellos is only to find 
neighbors, not to repair
use of the link for forwarding data (or propagating LSPs) if VLAN 1 is 
partitioned on the link

c) This is a lot more complicated. It might seem simpler to not try to 
optimize the number of
Hellos (like I did in point e), but there seem to be scary corner cases 
where all the VLANs
common to R1 and R2 are partitioned. Saying there must be an 
unpartitioned VLAN 1 seems
the safest.

So, I still like the "just use VLAN 1" proposal.

Date: Thu, 25 Oct 2007 11:07:14 -0700
From: Radia Perlman <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?
Status: RO
Content-Length: 13277

We should definitely arrange a phone call when you get back, though I've 
heard a rumor there
are phones in Italy. :-)

I do not understand most of what you said below.

a) unmodified IS-IS: I fail to see why sending IS-IS Hellos on more 
VLANs is "less of a change" to IS-IS. I'm
guessing, but perhaps you are suggesting that if we send Hellos on all 
the VLANs then
we don't need to report the bridge root ID in the LSP or do the
other safeguards (e.g., not decapsulating from ingress R1 unless you 
have checked all the
pseudonodes that R1 is attached to to ensure R1 isn't reporting the same 
root bridge ID).
I believe these safeguards are not complex or expensive and should be
done no matter how many VLANs we send Hellos on.

b) robustness:  I believe that the single VLAN proposal *is* robust.
Furthermore, I believe that if there is a cloud with lots of RBridges 
configured for sending
and receiving on different subsets of VLANs, there is more likelihood of 
problems,
especially if the "multiple VLAN proposal" (details still to be 
specified) does *not* include
the root bridge ID in LSPs and the other safeguards.

c) interoperability goal: I believe making fewer things configurable is 
the greatest way of
enhancing interoperability

That said....I was trying to imagine what a "send on multiple VLANs" 
proposal could possibly be.
TRILL never worked it out -- my fault to a large extent since I hadn't 
been following the
kinds of configuration that have been added to bridges that encourage 
partitioned VLANs on
a cloud. Thank you, Anoop, for noticing. I think what we'd been assuming 
was that you'd
form adjacencies based on VLAN tag, and R1 and R2 might talk with VLAN 
A, and
R2 and R3 might talk with VLAN B, etc., on the same cloud. This not only 
multiplies
the number of pseudonodes, but as Don pointed out, doesn't work with 
forwarding multicast data.

So, I'll write a separate note with a proposal for multiple VLANs that 
might be palatable.

Radia

Silvano Gai wrote:
> Radia,
>
> I am currently in Italy with limited connectivity. I'll write you a more
> complete reply next week.
>
> I have also the additional issue that I find hard to discuss these
> topics by email. I prefer face-to-face meeting in front of a whiteboard.
>
> Anyhow, let me try
>
> I think that the root of the disagreement is in the priority of the
> requirements.
>
> For me and others robustness and interoperability are paramount, because
> we look at TRILL in the Enterprise/Datacenter where there is no margin
> for errors, even in the presence of misconfigurations. Moreover we want
> to use ISIS unmodified with just few TLV added. If the price to pay for
> this solution is to use a "robust" CPU for the RBridge supervisor, we
> are happy to pay the price. Dinesh will present at the next IETF
> robustness and interoperability issues.
>
> For Anoop, loading the supervisor switch as little as possible is
> paramount. He seems to look more at green field installation, where
> interoperability and robustness to misconfiguration are somehow
> important, but not paramount.
>
> This difference in requirements causes differences in the preferred
> solution:
> - I prefer to use the standard ISIS with Hellos on all VLANs for
> discovery and LSP only on one VLAN.
> - Anoop prefers to not send the Hellos on all VLANs for discovery and he
> is willing to follow your lead to somehow modifying ISIS, adding
> additional steps to check Spanning tree roots, synchronize LSP
> databases, etc.
>
> When you have done all the changes that you propose to ISIS, I am not
> sure that we are using "an existing routing protocol" (as per TRILL
> charter), I think we have designed something new.
>
> Summarizing my goals are:
> - Robustness
> - Interoperability
> - Unmodified ISIS (e.g. no synchronization steps)
>
> My solution is to use what ISIS provides, i.e.
> - Hellos on all configured VLANs for discovery and LSP only on one VLAN.
>
>
> -- Silvano
>
>
>   
>> -----Original Message-----
>> From: Radia Perlman [mailto:[email-masked]]
>> Sent: Wednesday, October 24, 2007 2:42 PM
>> To: Silvano Gai
>> Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
>> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-
>> RBridgepackets?
>>
>> It's always hard to catch up on a thread after being away from email
>>     
> for
>   
>> a couple of days, but
>> Silvano --- both the tone and (lack of) content of your message below
>> makes it really difficult.
>>
>> In order to do quality engineering, we need to understand what all the
>> tradeoffs are, and we
>> have to be able to do discourse in an atmosphere of mutual respect.
>>
>> Saying something like "not doing it my way is 'too weak to be
>> practical', or 'holds water like
>> a pasta strainer' is not engineering. It is attempting to ridicule
>> anyone who disagrees with you,
>> and also is completely uninformative because you are not saying what
>>     
> the
>   
>> tradeoffs are, or
>> even the details of how the thing you want would work.
>>
>> I am usually proud of this WG because we usually do explore all the
>> options and what the
>> tradoffs are without resorting to bullying and ridicule. Let's strive
>>     
> to
>   
>> do engineering that way.
>>
>> So let me demonstrate by getting back to the thread.
>>
>> I think the "downsides" of sending all RBridge-RBridge messages on a
>> single unconfigurable
>> VLAN (proposal being VLAN 1) are:
>> a) if VLAN 1 is indeed partitioned, the RBridges will not know through
>> IS-IS Hellos that they have RBridge neighbors, and
>> multiple DRBs will be elected. But the proposal also includes how
>> to prevent multiple DRB, namely by being conservative about forwarding
>> data traffic to/from the link until we discover, though reporting the
>> bridge root ID in LSPs,
>> that it is safe to do so
>> b) a customer might want to not use that VLAN for RBridge-RBridge
>> traffic. However,
>> if that customer felt so strongly about minimizing RBridge-Rbridge
>> traffic, they could reconfigure use of the VLANs to move what they
>>     
> were
>   
>> using VLAN 1
>> to, to some other VLAN. So saying "just use 1" might inconvenience one
>> customer who is
>> already very savvy and likes to do really fancy configuration things,
>> but does not
>> prevent them from accomplishing all the exotic things they are trying
>>     
> to
>   
>> do -- just means
>> some more configuration. And is saves what hopefully is the vast
>> majority of customers from
>> having to do any configuration whatsoever, and simplifies the spec and
>> prevents misconfiguration.
>>
>> The upside of saying "just use 1" is extreme simplicity, and with the
>> safeguards, will not have
>> any higher probabilty of loops than already exists due to repeaters
>> coming up, or bridge
>> spanning tree messages getting lost.
>>
>> The next more complex proposal was to allow configuration to still
>> ultimately use one VLAN per
>> cloud, but allow it to be configurable to be something other than 1. I
>> gave a proposal for
>> doing that in a previous message (the DRB tells all the other
>> RBridges what VLAN to use, while the DRB still sends on VLAN 1 in
>>     
> addition
>   
>> to the VLAN the DRB tells everyone to send one). I think the upside
>>     
> over
>   
>> the simplest "just use 1", is
>> that it allows a customer that doesn't want RBridge-RBridge traffic
>> being used on VLAN 1,
>> or intentionally wants data traffic on VLAN 1 to be partitioned on a
>> cloud, to move to
>> a VLAN on that cloud that is OK not to be partitioned. The downside is
>> that steady state
>> the DRB will send one more Hello (on VLAN 1) than it would have, once
>> the DRB tells
>> all the other RBridges what VLAN to send on, and it is one more
>> configuration thing to
>> have to explain. And it seems likely that the DRB will be
>>     
> misconfigured
>   
>> and declare that
>> RBridges will use VLAN k instead of 1, when some other RBridge on the
>> cloud is not
>> configured to support k. It won't be fatal (since that other RBridge
>> will still hear the DRB
>> on VLAN 1 and will also know about the other DRB through link state
>> messages). My opinion
>> is that this extra complexity over "just use 1" is not warranted given
>> the small upside.
>>
>> If there is another proposal, say "send all Hellos on all VLANs", I
>> claim that the details of
>> that have never been specified well enough for that proposal to be
>> evaluated. So if someone
>> who advocates that can do that, staying technical, covering all
>>     
> details
>   
>> like whether in your
>> IS-IS Hello you list all the VLAN tags you've heard Hellos from for
>>     
> each
>   
>> neighbor, and
>> how you send a multicast data message when you have adjacencies with
>> different VLAN tags
>> for different subsets of neighbors, I'd like to hear it.
>>
>> And by all means, if I have missed some of the downsides on "just use
>> VLAN 1", or
>> "just use a single VLAN, but it can be configured to be something
>>     
> other
>   
>> than 1", then
>> by all means add to the arguments.
>>
>> Radia
>>
>>
>>
>>
>> Silvano Gai wrote:
>>     
>>> I want to restate that IMHO a design that sends messages on a single
>>> VLAN is so week to be completely useless.
>>>
>>> I met Anoop on a plane back from a T11 meeting and we discussed the
>>> issue of sending messages on all the configured VLANs. Anoop pointed
>>>       
> out
>   
>>> that, if these messages are ISIS messages, this can overload the
>>>       
> RBrige
>   
>>> supervisor.
>>>
>>> We identified a possible solution based on two different message
>>>       
> types:
>   
>>> - ISIS used on a single VLAN to compute adjacency
>>> - simple per-VLAN checking on all the VLANs to verify reachability.
>>>
>>> The second kind of messages is much simpler and therefore they load
>>>       
> less
>   
>>> the RBrige supervisor. In the future, per-VLAN checking can be
>>> implemented by the port ASIC. This seems a viable solution that
>>>       
> requires
>   
>>> design effort, but it is promising.
>>>
>>> Without the per-VLAN checking, running ISIS on a single VLAN holds
>>>       
> water
>   
>>> like a pasta-strainer.
>>>
>>> -- Silvano
>>>
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>>         
> [mailto:[email-masked]]
>   
>>> On
>>>
>>>       
>>>> Behalf Of Anoop Ghanwani
>>>> Sent: Monday, October 22, 2007 11:01 AM
>>>> To: Radia Perlman; Developing a hybrid router/bridge.
>>>> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-
>>>> RBridgepackets?
>>>>
>>>>
>>>> If we want to make implementations work with
>>>> only a single Hello for all VLANs than the
>>>> option is (a).  I think that is what it should be.
>>>> Basically, as a part of RBridge configuration
>>>> there should be a "RBridge Control VLAN" configuration
>>>> that applies to the whole device.  It should default
>>>> to VLAN 1, but an operator can choose to change it.
>>>> A RBridge only emits Hellos on that VLAN.  If it
>>>> receives Hellos on any other VLAN that should
>>>> be detected as an error condition and reported.
>>>>
>>>> There have been some problem corner cases that
>>>> have been pointed out previously on the list
>>>> that may result in temporary duplication of
>>>> traffic when there is misconfiguration.  Those
>>>> should be documented.
>>>>
>>>> Anoop
>>>>
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf Of Radia Perlman
>>>>> Sent: Saturday, October 20, 2007 9:47 PM
>>>>> To: Developing a hybrid router/bridge.
>>>>> Subject: [rbridge] Final outcome of outer VLAN tags on
>>>>> RBridge-RBridgepackets?
>>>>>
>>>>> I'm not sure I understood the final consensus on what we
>>>>> should do for outer VLAN tags on inter-RBridge packets.
>>>>>
>>>>> The possibilities I think the consensus might have been are:
>>>>>
>>>>> a) only use VLAN 1, explicit tag, no configuration possible.
>>>>> b) default is VLAN 1, explicit tag, configuration is possible
>>>>> to change sending with VLAN tag(s) something other than 1. If
>>>>> this is what was decided, I don't believe we've worked out
>>>>> the design details. I'd assume this would mean RBridges
>>>>> should be willing to receive packets from other RBridges
>>>>> regardless of outer VLAN tag. Would we then mark in the
>>>>> Hellos what VLAN tag(s) you've heard from what other RBridges
>>>>> with? What do we do with multicast if there isn't a single
>>>>> VLAN tag that seems to work to send to everyone? Would we
>>>>> allow configuration to send on a set of VLAN tags, or just on
>>>>> one at a time (and we allow configuration to say which one it is)?
>>>>>
>>>>> Certainly a) is simpler. If the consensus was b), we'd better
>>>>> work out the details.
>>>>>
>>>>> Radia
>>>>> _______________________________________________
>>>>> rbridge mailing list
>>>>> [email-masked]
>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>
>>>>>
>>>>>           
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> [email-masked]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>
>>>>         
>
>   

Content-class: urn:content-classes:message
Date: Thu, 25 Oct 2007 10:19:47 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Silvano Gai" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?
Status: RO
Content-Length: 9861

Hi Radia,

I am fairly comfortable with adopting the single
VLAN hello proposal and forcing that to be VLAN 1.

I would rather not have to deal with the complexity
of making it configurable because even that can
be subject to misconfiguration and would have its
own set of issues, but I am also not totally
opposed to that if someone else feels strongly
about it.  The main argument for doing that
would be point (b) in your message -- that
VLAN 1 was already being used for something 
else and the operator didn't want to use it
for RBridge control traffic.

As you point out, it looks like the proposal
for sending hellos on multiple VLANs would also
require additional scrutiny/specification before
it can be adopted.  Unless shown to be absolutely
necessary, this approach imposes a significant
processing burden so I would rather see us
solve the problem with the hellos on VLAN 1
only.

Anoop

> -----Original Message-----
> From: Radia Perlman [mailto:[email-masked]] 
> Sent: Wednesday, October 24, 2007 2:42 PM
> To: Silvano Gai
> Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Final outcome of outer VLAN tags 
> onRBridge-RBridgepackets?
> 
> It's always hard to catch up on a thread after being away 
> from email for a couple of days, but Silvano --- both the 
> tone and (lack of) content of your message below makes it 
> really difficult.
> 
> In order to do quality engineering, we need to understand 
> what all the tradeoffs are, and we have to be able to do 
> discourse in an atmosphere of mutual respect.
> 
> Saying something like "not doing it my way is 'too weak to be 
> practical', or 'holds water like a pasta strainer' is not 
> engineering. It is attempting to ridicule anyone who 
> disagrees with you, and also is completely uninformative 
> because you are not saying what the tradeoffs are, or even 
> the details of how the thing you want would work.
> 
> I am usually proud of this WG because we usually do explore 
> all the options and what the tradoffs are without resorting 
> to bullying and ridicule. Let's strive to do engineering that way.
> 
> So let me demonstrate by getting back to the thread.
> 
> I think the "downsides" of sending all RBridge-RBridge 
> messages on a single unconfigurable VLAN (proposal being VLAN 1) are:
> a) if VLAN 1 is indeed partitioned, the RBridges will not 
> know through IS-IS Hellos that they have RBridge neighbors, 
> and multiple DRBs will be elected. But the proposal also 
> includes how to prevent multiple DRB, namely by being 
> conservative about forwarding data traffic to/from the link 
> until we discover, though reporting the bridge root ID in 
> LSPs, that it is safe to do so
> b) a customer might want to not use that VLAN for 
> RBridge-RBridge traffic. However, if that customer felt so 
> strongly about minimizing RBridge-Rbridge traffic, they could 
> reconfigure use of the VLANs to move what they were using 
> VLAN 1 to, to some other VLAN. So saying "just use 1" might 
> inconvenience one customer who is already very savvy and 
> likes to do really fancy configuration things, but does not 
> prevent them from accomplishing all the exotic things they 
> are trying to do -- just means some more configuration. And 
> is saves what hopefully is the vast majority of customers 
> from having to do any configuration whatsoever, and 
> simplifies the spec and prevents misconfiguration.
> 
> The upside of saying "just use 1" is extreme simplicity, and 
> with the safeguards, will not have any higher probabilty of 
> loops than already exists due to repeaters coming up, or 
> bridge spanning tree messages getting lost.
> 
> The next more complex proposal was to allow configuration to 
> still ultimately use one VLAN per cloud, but allow it to be 
> configurable to be something other than 1. I gave a proposal 
> for doing that in a previous message (the DRB tells all the 
> other RBridges what VLAN to use, while the DRB still sends on 
> VLAN 1 in addition to the VLAN the DRB tells everyone to send 
> one). I think the upside over the simplest "just use 1", is 
> that it allows a customer that doesn't want RBridge-RBridge 
> traffic being used on VLAN 1, or intentionally wants data 
> traffic on VLAN 1 to be partitioned on a cloud, to move to a 
> VLAN on that cloud that is OK not to be partitioned. The 
> downside is that steady state the DRB will send one more 
> Hello (on VLAN 1) than it would have, once the DRB tells all 
> the other RBridges what VLAN to send on, and it is one more 
> configuration thing to have to explain. And it seems likely 
> that the DRB will be misconfigured and declare that RBridges 
> will use VLAN k instead of 1, when some other RBridge on the 
> cloud is not configured to support k. It won't be fatal 
> (since that other RBridge will still hear the DRB on VLAN 1 
> and will also know about the other DRB through link state 
> messages). My opinion is that this extra complexity over 
> "just use 1" is not warranted given the small upside.
> 
> If there is another proposal, say "send all Hellos on all 
> VLANs", I claim that the details of that have never been 
> specified well enough for that proposal to be evaluated. So 
> if someone who advocates that can do that, staying technical, 
> covering all details like whether in your IS-IS Hello you 
> list all the VLAN tags you've heard Hellos from for each 
> neighbor, and how you send a multicast data message when you 
> have adjacencies with different VLAN tags for different 
> subsets of neighbors, I'd like to hear it.
> 
> And by all means, if I have missed some of the downsides on 
> "just use VLAN 1", or "just use a single VLAN, but it can be 
> configured to be something other than 1", then by all means 
> add to the arguments.
> 
> Radia
> 
> 
> 
> 
> Silvano Gai wrote:
> > I want to restate that IMHO a design that sends messages on 
> a single 
> > VLAN is so week to be completely useless.
> >
> > I met Anoop on a plane back from a T11 meeting and we discussed the 
> > issue of sending messages on all the configured VLANs. 
> Anoop pointed 
> > out that, if these messages are ISIS messages, this can 
> overload the 
> > RBrige supervisor.
> >
> > We identified a possible solution based on two different 
> message types:
> > - ISIS used on a single VLAN to compute adjacency
> > - simple per-VLAN checking on all the VLANs to verify reachability.
> >
> > The second kind of messages is much simpler and therefore they load 
> > less the RBrige supervisor. In the future, per-VLAN checking can be 
> > implemented by the port ASIC. This seems a viable solution that 
> > requires design effort, but it is promising.
> >
> > Without the per-VLAN checking, running ISIS on a single VLAN holds 
> > water like a pasta-strainer.
> >
> > -- Silvano
> >
> >
> >   
> >> -----Original Message-----
> >> From: [email-masked] 
> [mailto:[email-masked]]
> >>     
> > On
> >   
> >> Behalf Of Anoop Ghanwani
> >> Sent: Monday, October 22, 2007 11:01 AM
> >> To: Radia Perlman; Developing a hybrid router/bridge.
> >> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- 
> >> RBridgepackets?
> >>
> >>
> >> If we want to make implementations work with only a single 
> Hello for 
> >> all VLANs than the option is (a).  I think that is what it 
> should be.
> >> Basically, as a part of RBridge configuration there should be a 
> >> "RBridge Control VLAN" configuration that applies to the whole 
> >> device.  It should default to VLAN 1, but an operator can 
> choose to 
> >> change it.
> >> A RBridge only emits Hellos on that VLAN.  If it receives 
> Hellos on 
> >> any other VLAN that should be detected as an error condition and 
> >> reported.
> >>
> >> There have been some problem corner cases that have been 
> pointed out 
> >> previously on the list that may result in temporary duplication of 
> >> traffic when there is misconfiguration.  Those should be 
> documented.
> >>
> >> Anoop
> >>
> >>     
> >>> -----Original Message-----
> >>> From: [email-masked]
> >>> [mailto:[email-masked]] On Behalf Of Radia Perlman
> >>> Sent: Saturday, October 20, 2007 9:47 PM
> >>> To: Developing a hybrid router/bridge.
> >>> Subject: [rbridge] Final outcome of outer VLAN tags on 
> >>> RBridge-RBridgepackets?
> >>>
> >>> I'm not sure I understood the final consensus on what we 
> should do 
> >>> for outer VLAN tags on inter-RBridge packets.
> >>>
> >>> The possibilities I think the consensus might have been are:
> >>>
> >>> a) only use VLAN 1, explicit tag, no configuration possible.
> >>> b) default is VLAN 1, explicit tag, configuration is possible to 
> >>> change sending with VLAN tag(s) something other than 1. 
> If this is 
> >>> what was decided, I don't believe we've worked out the design 
> >>> details. I'd assume this would mean RBridges should be willing to 
> >>> receive packets from other RBridges regardless of outer VLAN tag. 
> >>> Would we then mark in the Hellos what VLAN tag(s) you've 
> heard from 
> >>> what other RBridges with? What do we do with multicast if there 
> >>> isn't a single VLAN tag that seems to work to send to everyone? 
> >>> Would we allow configuration to send on a set of VLAN 
> tags, or just 
> >>> on one at a time (and we allow configuration to say which one it 
> >>> is)?
> >>>
> >>> Certainly a) is simpler. If the consensus was b), we'd 
> better work 
> >>> out the details.
> >>>
> >>> Radia
> >>> _______________________________________________
> >>> rbridge mailing list
> >>> [email-masked]
> >>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>
> >>>       
> >> _______________________________________________
> >> rbridge mailing list
> >> [email-masked]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>     
> 

Content-class: urn:content-classes:message
Date: Thu, 25 Oct 2007 09:25:26 -0700
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?
Status: RO
Content-Length: 10708

Radia,

I am currently in Italy with limited connectivity. I'll write you a more
complete reply next week.

I have also the additional issue that I find hard to discuss these
topics by email. I prefer face-to-face meeting in front of a whiteboard.

Anyhow, let me try

I think that the root of the disagreement is in the priority of the
requirements.

For me and others robustness and interoperability are paramount, because
we look at TRILL in the Enterprise/Datacenter where there is no margin
for errors, even in the presence of misconfigurations. Moreover we want
to use ISIS unmodified with just few TLV added. If the price to pay for
this solution is to use a "robust" CPU for the RBridge supervisor, we
are happy to pay the price. Dinesh will present at the next IETF
robustness and interoperability issues.

For Anoop, loading the supervisor switch as little as possible is
paramount. He seems to look more at green field installation, where
interoperability and robustness to misconfiguration are somehow
important, but not paramount.

This difference in requirements causes differences in the preferred
solution:
- I prefer to use the standard ISIS with Hellos on all VLANs for
discovery and LSP only on one VLAN.
- Anoop prefers to not send the Hellos on all VLANs for discovery and he
is willing to follow your lead to somehow modifying ISIS, adding
additional steps to check Spanning tree roots, synchronize LSP
databases, etc.

When you have done all the changes that you propose to ISIS, I am not
sure that we are using "an existing routing protocol" (as per TRILL
charter), I think we have designed something new.

Summarizing my goals are:
- Robustness
- Interoperability
- Unmodified ISIS (e.g. no synchronization steps)

My solution is to use what ISIS provides, i.e.
- Hellos on all configured VLANs for discovery and LSP only on one VLAN.

-- Silvano

> -----Original Message-----
> From: Radia Perlman [mailto:[email-masked]]
> Sent: Wednesday, October 24, 2007 2:42 PM
> To: Silvano Gai
> Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-
> RBridgepackets?
> 
> It's always hard to catch up on a thread after being away from email
for
> a couple of days, but
> Silvano --- both the tone and (lack of) content of your message below
> makes it really difficult.
> 
> In order to do quality engineering, we need to understand what all the
> tradeoffs are, and we
> have to be able to do discourse in an atmosphere of mutual respect.
> 
> Saying something like "not doing it my way is 'too weak to be
> practical', or 'holds water like
> a pasta strainer' is not engineering. It is attempting to ridicule
> anyone who disagrees with you,
> and also is completely uninformative because you are not saying what
the
> tradeoffs are, or
> even the details of how the thing you want would work.
> 
> I am usually proud of this WG because we usually do explore all the
> options and what the
> tradoffs are without resorting to bullying and ridicule. Let's strive
to
> do engineering that way.
> 
> So let me demonstrate by getting back to the thread.
> 
> I think the "downsides" of sending all RBridge-RBridge messages on a
> single unconfigurable
> VLAN (proposal being VLAN 1) are:
> a) if VLAN 1 is indeed partitioned, the RBridges will not know through
> IS-IS Hellos that they have RBridge neighbors, and
> multiple DRBs will be elected. But the proposal also includes how
> to prevent multiple DRB, namely by being conservative about forwarding
> data traffic to/from the link until we discover, though reporting the
> bridge root ID in LSPs,
> that it is safe to do so
> b) a customer might want to not use that VLAN for RBridge-RBridge
> traffic. However,
> if that customer felt so strongly about minimizing RBridge-Rbridge
> traffic, they could reconfigure use of the VLANs to move what they
were
> using VLAN 1
> to, to some other VLAN. So saying "just use 1" might inconvenience one
> customer who is
> already very savvy and likes to do really fancy configuration things,
> but does not
> prevent them from accomplishing all the exotic things they are trying
to
> do -- just means
> some more configuration. And is saves what hopefully is the vast
> majority of customers from
> having to do any configuration whatsoever, and simplifies the spec and
> prevents misconfiguration.
> 
> The upside of saying "just use 1" is extreme simplicity, and with the
> safeguards, will not have
> any higher probabilty of loops than already exists due to repeaters
> coming up, or bridge
> spanning tree messages getting lost.
> 
> The next more complex proposal was to allow configuration to still
> ultimately use one VLAN per
> cloud, but allow it to be configurable to be something other than 1. I
> gave a proposal for
> doing that in a previous message (the DRB tells all the other
> RBridges what VLAN to use, while the DRB still sends on VLAN 1 in
addition
> to the VLAN the DRB tells everyone to send one). I think the upside
over
> the simplest "just use 1", is
> that it allows a customer that doesn't want RBridge-RBridge traffic
> being used on VLAN 1,
> or intentionally wants data traffic on VLAN 1 to be partitioned on a
> cloud, to move to
> a VLAN on that cloud that is OK not to be partitioned. The downside is
> that steady state
> the DRB will send one more Hello (on VLAN 1) than it would have, once
> the DRB tells
> all the other RBridges what VLAN to send on, and it is one more
> configuration thing to
> have to explain. And it seems likely that the DRB will be
misconfigured
> and declare that
> RBridges will use VLAN k instead of 1, when some other RBridge on the
> cloud is not
> configured to support k. It won't be fatal (since that other RBridge
> will still hear the DRB
> on VLAN 1 and will also know about the other DRB through link state
> messages). My opinion
> is that this extra complexity over "just use 1" is not warranted given
> the small upside.
> 
> If there is another proposal, say "send all Hellos on all VLANs", I
> claim that the details of
> that have never been specified well enough for that proposal to be
> evaluated. So if someone
> who advocates that can do that, staying technical, covering all
details
> like whether in your
> IS-IS Hello you list all the VLAN tags you've heard Hellos from for
each
> neighbor, and
> how you send a multicast data message when you have adjacencies with
> different VLAN tags
> for different subsets of neighbors, I'd like to hear it.
> 
> And by all means, if I have missed some of the downsides on "just use
> VLAN 1", or
> "just use a single VLAN, but it can be configured to be something
other
> than 1", then
> by all means add to the arguments.
> 
> Radia
> 
> 
> 
> 
> Silvano Gai wrote:
> > I want to restate that IMHO a design that sends messages on a single
> > VLAN is so week to be completely useless.
> >
> > I met Anoop on a plane back from a T11 meeting and we discussed the
> > issue of sending messages on all the configured VLANs. Anoop pointed
out
> > that, if these messages are ISIS messages, this can overload the
RBrige
> > supervisor.
> >
> > We identified a possible solution based on two different message
types:
> > - ISIS used on a single VLAN to compute adjacency
> > - simple per-VLAN checking on all the VLANs to verify reachability.
> >
> > The second kind of messages is much simpler and therefore they load
less
> > the RBrige supervisor. In the future, per-VLAN checking can be
> > implemented by the port ASIC. This seems a viable solution that
requires
> > design effort, but it is promising.
> >
> > Without the per-VLAN checking, running ISIS on a single VLAN holds
water
> > like a pasta-strainer.
> >
> > -- Silvano
> >
> >
> >
> >> -----Original Message-----
> >> From: [email-masked]
[mailto:[email-masked]]
> >>
> > On
> >
> >> Behalf Of Anoop Ghanwani
> >> Sent: Monday, October 22, 2007 11:01 AM
> >> To: Radia Perlman; Developing a hybrid router/bridge.
> >> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-
> >> RBridgepackets?
> >>
> >>
> >> If we want to make implementations work with
> >> only a single Hello for all VLANs than the
> >> option is (a).  I think that is what it should be.
> >> Basically, as a part of RBridge configuration
> >> there should be a "RBridge Control VLAN" configuration
> >> that applies to the whole device.  It should default
> >> to VLAN 1, but an operator can choose to change it.
> >> A RBridge only emits Hellos on that VLAN.  If it
> >> receives Hellos on any other VLAN that should
> >> be detected as an error condition and reported.
> >>
> >> There have been some problem corner cases that
> >> have been pointed out previously on the list
> >> that may result in temporary duplication of
> >> traffic when there is misconfiguration.  Those
> >> should be documented.
> >>
> >> Anoop
> >>
> >>
> >>> -----Original Message-----
> >>> From: [email-masked]
> >>> [mailto:[email-masked]] On Behalf Of Radia Perlman
> >>> Sent: Saturday, October 20, 2007 9:47 PM
> >>> To: Developing a hybrid router/bridge.
> >>> Subject: [rbridge] Final outcome of outer VLAN tags on
> >>> RBridge-RBridgepackets?
> >>>
> >>> I'm not sure I understood the final consensus on what we
> >>> should do for outer VLAN tags on inter-RBridge packets.
> >>>
> >>> The possibilities I think the consensus might have been are:
> >>>
> >>> a) only use VLAN 1, explicit tag, no configuration possible.
> >>> b) default is VLAN 1, explicit tag, configuration is possible
> >>> to change sending with VLAN tag(s) something other than 1. If
> >>> this is what was decided, I don't believe we've worked out
> >>> the design details. I'd assume this would mean RBridges
> >>> should be willing to receive packets from other RBridges
> >>> regardless of outer VLAN tag. Would we then mark in the
> >>> Hellos what VLAN tag(s) you've heard from what other RBridges
> >>> with? What do we do with multicast if there isn't a single
> >>> VLAN tag that seems to work to send to everyone? Would we
> >>> allow configuration to send on a set of VLAN tags, or just on
> >>> one at a time (and we allow configuration to say which one it is)?
> >>>
> >>> Certainly a) is simpler. If the consensus was b), we'd better
> >>> work out the details.
> >>>
> >>> Radia
> >>> _______________________________________________
> >>> rbridge mailing list
> >>> [email-masked]
> >>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>
> >>>
> >> _______________________________________________
> >> rbridge mailing list
> >> [email-masked]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>

Content-class: urn:content-classes:message
Date: Wed, 24 Oct 2007 14:42:00 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLANtagsonRBridge-RBridgepackets?
Status: RO
Content-Length: 7493

Silvano,

I am not opposed to using per-VLAN connectivity
detection (which we're saying should be done by
hellos) if it is shown to be absolutely essential.
As long as there is a way around it, I prefer to
avoid having to send them.

We should probably delay the decision until
we understand what scenarios make it an absolute
requirement before we make it such.

Anoop

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Silvano Gai
> Sent: Wednesday, October 24, 2007 10:13 AM
> To: Eastlake III Donald-LDE008
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Final outcome of outer 
> VLANtagsonRBridge-RBridgepackets?
> 
> 
> Donald,
> 
> My concern is misconfiguration.
> 
> If we don't send at least a simple Hello per VLAN misconfigurations go
> undetected and can cause frame duplication.
> 
> See also my latest reply to Anoop: we don't need to send an LSP.
> 
> Whatever scheme that sends frames only on one VLAN cannot detect VLAN
> misconfiguration by definition.
> 
> We have a simple and tested solution: "Let's send Hellos on all VLANs
> for discovery and LSP only on one VLAN."
> 
> This solves the issue of Anoop, of not sending multiple LSPs.
> 
> Let's use it
> 
> -- Silvano
> 
> P.S. I'll not be able to make the December TRILL meeting, 
> since it is at
> the same time as T11/FCoE. Dinesh can present a slide set 
> with the most
> important issues related to misconfiguration.
> 
> 
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008 
> [mailto:[email-masked]]
> > Sent: Tuesday, October 23, 2007 1:46 PM
> > To: Silvano Gai
> > Cc: Developing a hybrid router/bridge.
> > Subject: RE: [rbridge] Final outcome of outer VLAN tagsonRBridge-
> > RBridgepackets?
> > 
> > Hi Silvano,
> > 
> > I have two questions:
> > 
> > (1) What exactly is the problem you see with doing adjacency on one
> > VLAN? It could be that you think that Hellos on one VLAN would be OK
> but
> > it is too much of a configuration burden to expect network
> > administrators to figure out which VLAN and to then configure their
> > Rbridges. Or it could be that you think that even if each 
> port on each
> > Rbridge was configured to the "best" single VLAN, the adjacencies
> found
> > would be too sparse compared to those potentially possible. Or you
> could
> > think that both of these and/or other things are the main problem...
> > 
> > (2) If multiple Hellos on different VLANs, or some other technique,
> are
> > used to learn the full VLAN connectivity, what are Rbriges 
> supposed to
> > do when no single VLAN will get to all the desired destinations? For
> > example, assume that Rbridge-A is connected as follows:
> > 
> > 	On VLAN 2 to B and C
> > 	On VLAN 3 to C, D, and E
> > 	On VLAN 4 to F, G, and H
> > 	On VLAN 5 to D, E, F, and G
> > 
> > If Rbrdige-A wants to send a multi-destination frame to all of B
> through
> > H, it would seem that it has to send it at least three 
> times to get to
> > all the one-Rbridge-hop destinations and to avoid duplication. For
> > example, multicast on VLANs 3 and 4 and unicast to B. Or,
> alternatively,
> > multicast on VLANs 2 and 5 and unicast to H. Or, if the complexity
> > exceeds some threshold, Rbridge-A could just forget about optimality
> and
> > unicast the frame separately to B through H.
> > 
> > How would you suggest handling such situations?
> > 
> > Thanks,
> > Donald
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Silvano Gai
> > Sent: Tuesday, October 23, 2007 6:21 AM
> > To: Anoop Ghanwani; Radia Perlman; Developing a hybrid 
> router/bridge.
> > Subject: Re: [rbridge] Final outcome of outer VLAN
> > tagsonRBridge-RBridgepackets?
> > 
> > I want to restate that IMHO a design that sends messages on a single
> > VLAN is so week to be completely useless.
> > 
> > I met Anoop on a plane back from a T11 meeting and we discussed the
> > issue of sending messages on all the configured VLANs. Anoop pointed
> out
> > that, if these messages are ISIS messages, this can overload the
> RBrige
> > supervisor.
> > 
> > We identified a possible solution based on two different message
> types:
> > - ISIS used on a single VLAN to compute adjacency
> > - simple per-VLAN checking on all the VLANs to verify reachability.
> > 
> > The second kind of messages is much simpler and therefore they load
> less
> > the RBrige supervisor. In the future, per-VLAN checking can be
> > implemented by the port ASIC. This seems a viable solution that
> requires
> > design effort, but it is promising.
> > 
> > Without the per-VLAN checking, running ISIS on a single VLAN holds
> water
> > like a pasta-strainer.
> > 
> > -- Silvano
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> [mailto:[email-masked]]
> > On
> > > Behalf Of Anoop Ghanwani
> > > Sent: Monday, October 22, 2007 11:01 AM
> > > To: Radia Perlman; Developing a hybrid router/bridge.
> > > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-
> > > RBridgepackets?
> > >
> > >
> > > If we want to make implementations work with
> > > only a single Hello for all VLANs than the
> > > option is (a).  I think that is what it should be.
> > > Basically, as a part of RBridge configuration
> > > there should be a "RBridge Control VLAN" configuration
> > > that applies to the whole device.  It should default
> > > to VLAN 1, but an operator can choose to change it.
> > > A RBridge only emits Hellos on that VLAN.  If it
> > > receives Hellos on any other VLAN that should
> > > be detected as an error condition and reported.
> > >
> > > There have been some problem corner cases that
> > > have been pointed out previously on the list
> > > that may result in temporary duplication of
> > > traffic when there is misconfiguration.  Those
> > > should be documented.
> > >
> > > Anoop
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of Radia Perlman
> > > > Sent: Saturday, October 20, 2007 9:47 PM
> > > > To: Developing a hybrid router/bridge.
> > > > Subject: [rbridge] Final outcome of outer VLAN tags on
> > > > RBridge-RBridgepackets?
> > > >
> > > > I'm not sure I understood the final consensus on what we
> > > > should do for outer VLAN tags on inter-RBridge packets.
> > > >
> > > > The possibilities I think the consensus might have been are:
> > > >
> > > > a) only use VLAN 1, explicit tag, no configuration possible.
> > > > b) default is VLAN 1, explicit tag, configuration is possible
> > > > to change sending with VLAN tag(s) something other than 1. If
> > > > this is what was decided, I don't believe we've worked out
> > > > the design details. I'd assume this would mean RBridges
> > > > should be willing to receive packets from other RBridges
> > > > regardless of outer VLAN tag. Would we then mark in the
> > > > Hellos what VLAN tag(s) you've heard from what other RBridges
> > > > with? What do we do with multicast if there isn't a single
> > > > VLAN tag that seems to work to send to everyone? Would we
> > > > allow configuration to send on a set of VLAN tags, or just on
> > > > one at a time (and we allow configuration to say which 
> one it is)?
> > > >
> > > > Certainly a) is simpler. If the consensus was b), we'd better
> > > > work out the details.
> > > >
> > > > Radia

Date: Wed, 24 Oct 2007 14:42:06 -0700
From: Radia Perlman <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?
Status: RO
Content-Length: 8196

It's always hard to catch up on a thread after being away from email for 
a couple of days, but
Silvano --- both the tone and (lack of) content of your message below 
makes it really difficult.

In order to do quality engineering, we need to understand what all the 
tradeoffs are, and we
have to be able to do discourse in an atmosphere of mutual respect.

Saying something like "not doing it my way is 'too weak to be 
practical', or 'holds water like
a pasta strainer' is not engineering. It is attempting to ridicule 
anyone who disagrees with you,
and also is completely uninformative because you are not saying what the 
tradeoffs are, or
even the details of how the thing you want would work.

I am usually proud of this WG because we usually do explore all the 
options and what the
tradoffs are without resorting to bullying and ridicule. Let's strive to 
do engineering that way.

So let me demonstrate by getting back to the thread.

I think the "downsides" of sending all RBridge-RBridge messages on a 
single unconfigurable
VLAN (proposal being VLAN 1) are:
a) if VLAN 1 is indeed partitioned, the RBridges will not know through
IS-IS Hellos that they have RBridge neighbors, and
multiple DRBs will be elected. But the proposal also includes how
to prevent multiple DRB, namely by being conservative about forwarding
data traffic to/from the link until we discover, though reporting the 
bridge root ID in LSPs,
that it is safe to do so
b) a customer might want to not use that VLAN for RBridge-RBridge 
traffic. However,
if that customer felt so strongly about minimizing RBridge-Rbridge
traffic, they could reconfigure use of the VLANs to move what they were 
using VLAN 1
to, to some other VLAN. So saying "just use 1" might inconvenience one 
customer who is
already very savvy and likes to do really fancy configuration things, 
but does not
prevent them from accomplishing all the exotic things they are trying to 
do -- just means
some more configuration. And is saves what hopefully is the vast 
majority of customers from
having to do any configuration whatsoever, and simplifies the spec and 
prevents misconfiguration.

The upside of saying "just use 1" is extreme simplicity, and with the 
safeguards, will not have
any higher probabilty of loops than already exists due to repeaters 
coming up, or bridge
spanning tree messages getting lost.

The next more complex proposal was to allow configuration to still 
ultimately use one VLAN per
cloud, but allow it to be configurable to be something other than 1. I 
gave a proposal for
doing that in a previous message (the DRB tells all the other
RBridges what VLAN to use, while the DRB still sends on VLAN 1 in addition
to the VLAN the DRB tells everyone to send one). I think the upside over 
the simplest "just use 1", is
that it allows a customer that doesn't want RBridge-RBridge traffic 
being used on VLAN 1,
or intentionally wants data traffic on VLAN 1 to be partitioned on a 
cloud, to move to
a VLAN on that cloud that is OK not to be partitioned. The downside is 
that steady state
the DRB will send one more Hello (on VLAN 1) than it would have, once 
the DRB tells
all the other RBridges what VLAN to send on, and it is one more 
configuration thing to
have to explain. And it seems likely that the DRB will be misconfigured 
and declare that
RBridges will use VLAN k instead of 1, when some other RBridge on the 
cloud is not
configured to support k. It won't be fatal (since that other RBridge 
will still hear the DRB
on VLAN 1 and will also know about the other DRB through link state 
messages). My opinion
is that this extra complexity over "just use 1" is not warranted given 
the small upside.

If there is another proposal, say "send all Hellos on all VLANs", I 
claim that the details of
that have never been specified well enough for that proposal to be 
evaluated. So if someone
who advocates that can do that, staying technical, covering all details 
like whether in your
IS-IS Hello you list all the VLAN tags you've heard Hellos from for each 
neighbor, and
how you send a multicast data message when you have adjacencies with 
different VLAN tags
for different subsets of neighbors, I'd like to hear it.

And by all means, if I have missed some of the downsides on "just use 
VLAN 1", or
"just use a single VLAN, but it can be configured to be something other 
than 1", then
by all means add to the arguments.

Radia

Silvano Gai wrote:
> I want to restate that IMHO a design that sends messages on a single
> VLAN is so week to be completely useless.
>
> I met Anoop on a plane back from a T11 meeting and we discussed the
> issue of sending messages on all the configured VLANs. Anoop pointed out
> that, if these messages are ISIS messages, this can overload the RBrige
> supervisor.
>
> We identified a possible solution based on two different message types:
> - ISIS used on a single VLAN to compute adjacency
> - simple per-VLAN checking on all the VLANs to verify reachability.
>
> The second kind of messages is much simpler and therefore they load less
> the RBrige supervisor. In the future, per-VLAN checking can be
> implemented by the port ASIC. This seems a viable solution that requires
> design effort, but it is promising.
>
> Without the per-VLAN checking, running ISIS on a single VLAN holds water
> like a pasta-strainer.
>
> -- Silvano
>
>
>   
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>>     
> On
>   
>> Behalf Of Anoop Ghanwani
>> Sent: Monday, October 22, 2007 11:01 AM
>> To: Radia Perlman; Developing a hybrid router/bridge.
>> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-
>> RBridgepackets?
>>
>>
>> If we want to make implementations work with
>> only a single Hello for all VLANs than the
>> option is (a).  I think that is what it should be.
>> Basically, as a part of RBridge configuration
>> there should be a "RBridge Control VLAN" configuration
>> that applies to the whole device.  It should default
>> to VLAN 1, but an operator can choose to change it.
>> A RBridge only emits Hellos on that VLAN.  If it
>> receives Hellos on any other VLAN that should
>> be detected as an error condition and reported.
>>
>> There have been some problem corner cases that
>> have been pointed out previously on the list
>> that may result in temporary duplication of
>> traffic when there is misconfiguration.  Those
>> should be documented.
>>
>> Anoop
>>
>>     
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Radia Perlman
>>> Sent: Saturday, October 20, 2007 9:47 PM
>>> To: Developing a hybrid router/bridge.
>>> Subject: [rbridge] Final outcome of outer VLAN tags on
>>> RBridge-RBridgepackets?
>>>
>>> I'm not sure I understood the final consensus on what we
>>> should do for outer VLAN tags on inter-RBridge packets.
>>>
>>> The possibilities I think the consensus might have been are:
>>>
>>> a) only use VLAN 1, explicit tag, no configuration possible.
>>> b) default is VLAN 1, explicit tag, configuration is possible
>>> to change sending with VLAN tag(s) something other than 1. If
>>> this is what was decided, I don't believe we've worked out
>>> the design details. I'd assume this would mean RBridges
>>> should be willing to receive packets from other RBridges
>>> regardless of outer VLAN tag. Would we then mark in the
>>> Hellos what VLAN tag(s) you've heard from what other RBridges
>>> with? What do we do with multicast if there isn't a single
>>> VLAN tag that seems to work to send to everyone? Would we
>>> allow configuration to send on a set of VLAN tags, or just on
>>> one at a time (and we allow configuration to say which one it is)?
>>>
>>> Certainly a) is simpler. If the consensus was b), we'd better
>>> work out the details.
>>>
>>> Radia
>>> _______________________________________________
>>> rbridge mailing list
>>> [email-masked]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>>       
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>     

Content-class: urn:content-classes:message
Date: Wed, 24 Oct 2007 17:09:41 -0400
From: "Caitlin Bestler" <[email-masked]>
To: "Joe Touch" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] TRILL meeting in Vancouver
Status: RO
Content-Length: 205

Joe touch wrote:

>TRILL appears to be consistently scheduled on top of TSVWG.
>I'm in favor of moving it unless it sits on top of TCPM.

Seconded. Those are the three highest priority sessions for me.

Date: Wed, 24 Oct 2007 11:24:07 -0700
From: Joe Touch <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] TRILL meeting in Vancouver
Status: RO
Content-Length: 1629

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

TRILL appears to be consistently scheduled on top of TSVWG. I'm in favor
of moving it unless it sits on top of TCPM.

Joe

Eastlake III Donald-LDE008 wrote:
> A draft agenda for the 70th IETF meeting in Vancouver, British Columbia=
,
> has been posted a few days ahead of schedule on the www.ietf.org web
> site. It shows TRILL as being Thursday morning. However, a couple of ou=
r
> working group draft authors have requested that we attempt to have the
> meeting move to Tuesday. Although it is not clear that we can do this,
> keeping in mind other working group and meeting space constraints (for
> example, as an Internet Area WG we can't conflict with the INTAREA
> meeting Tuesday afternoon), we plan to request such a move to Tuesday.
>=20
> Thanks,
> Erik and Donald
>=20
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

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

--------------enig627519C66833ACE6BA63E905--

Content-class: urn:content-classes:message
Date: Wed, 24 Oct 2007 14:02:15 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] TRILL meeting in Vancouver
Status: RO
Content-Length: 592

A draft agenda for the 70th IETF meeting in Vancouver, British Columbia,
has been posted a few days ahead of schedule on the www.ietf.org web
site. It shows TRILL as being Thursday morning. However, a couple of our
working group draft authors have requested that we attempt to have the
meeting move to Tuesday. Although it is not clear that we can do this,
keeping in mind other working group and meeting space constraints (for
example, as an Internet Area WG we can't conflict with the INTAREA
meeting Tuesday afternoon), we plan to request such a move to Tuesday.

Thanks,
Erik and Donald

Content-class: urn:content-classes:message
Date: Wed, 24 Oct 2007 10:13:06 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tagsonRBridge-RBridgepackets?
Status: RO
Content-Length: 6885

Donald,

My concern is misconfiguration.

If we don't send at least a simple Hello per VLAN misconfigurations go
undetected and can cause frame duplication.

See also my latest reply to Anoop: we don't need to send an LSP.

Whatever scheme that sends frames only on one VLAN cannot detect VLAN
misconfiguration by definition.

We have a simple and tested solution: "Let's send Hellos on all VLANs
for discovery and LSP only on one VLAN."

This solves the issue of Anoop, of not sending multiple LSPs.

Let's use it

-- Silvano

P.S. I'll not be able to make the December TRILL meeting, since it is at
the same time as T11/FCoE. Dinesh can present a slide set with the most
important issues related to misconfiguration.

> -----Original Message-----
> From: Eastlake III Donald-LDE008 [mailto:[email-masked]]
> Sent: Tuesday, October 23, 2007 1:46 PM
> To: Silvano Gai
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Final outcome of outer VLAN tagsonRBridge-
> RBridgepackets?
> 
> Hi Silvano,
> 
> I have two questions:
> 
> (1) What exactly is the problem you see with doing adjacency on one
> VLAN? It could be that you think that Hellos on one VLAN would be OK
but
> it is too much of a configuration burden to expect network
> administrators to figure out which VLAN and to then configure their
> Rbridges. Or it could be that you think that even if each port on each
> Rbridge was configured to the "best" single VLAN, the adjacencies
found
> would be too sparse compared to those potentially possible. Or you
could
> think that both of these and/or other things are the main problem...
> 
> (2) If multiple Hellos on different VLANs, or some other technique,
are
> used to learn the full VLAN connectivity, what are Rbriges supposed to
> do when no single VLAN will get to all the desired destinations? For
> example, assume that Rbridge-A is connected as follows:
> 
> 	On VLAN 2 to B and C
> 	On VLAN 3 to C, D, and E
> 	On VLAN 4 to F, G, and H
> 	On VLAN 5 to D, E, F, and G
> 
> If Rbrdige-A wants to send a multi-destination frame to all of B
through
> H, it would seem that it has to send it at least three times to get to
> all the one-Rbridge-hop destinations and to avoid duplication. For
> example, multicast on VLANs 3 and 4 and unicast to B. Or,
alternatively,
> multicast on VLANs 2 and 5 and unicast to H. Or, if the complexity
> exceeds some threshold, Rbridge-A could just forget about optimality
and
> unicast the frame separately to B through H.
> 
> How would you suggest handling such situations?
> 
> Thanks,
> Donald
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Silvano Gai
> Sent: Tuesday, October 23, 2007 6:21 AM
> To: Anoop Ghanwani; Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Final outcome of outer VLAN
> tagsonRBridge-RBridgepackets?
> 
> I want to restate that IMHO a design that sends messages on a single
> VLAN is so week to be completely useless.
> 
> I met Anoop on a plane back from a T11 meeting and we discussed the
> issue of sending messages on all the configured VLANs. Anoop pointed
out
> that, if these messages are ISIS messages, this can overload the
RBrige
> supervisor.
> 
> We identified a possible solution based on two different message
types:
> - ISIS used on a single VLAN to compute adjacency
> - simple per-VLAN checking on all the VLANs to verify reachability.
> 
> The second kind of messages is much simpler and therefore they load
less
> the RBrige supervisor. In the future, per-VLAN checking can be
> implemented by the port ASIC. This seems a viable solution that
requires
> design effort, but it is promising.
> 
> Without the per-VLAN checking, running ISIS on a single VLAN holds
water
> like a pasta-strainer.
> 
> -- Silvano
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Anoop Ghanwani
> > Sent: Monday, October 22, 2007 11:01 AM
> > To: Radia Perlman; Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-
> > RBridgepackets?
> >
> >
> > If we want to make implementations work with
> > only a single Hello for all VLANs than the
> > option is (a).  I think that is what it should be.
> > Basically, as a part of RBridge configuration
> > there should be a "RBridge Control VLAN" configuration
> > that applies to the whole device.  It should default
> > to VLAN 1, but an operator can choose to change it.
> > A RBridge only emits Hellos on that VLAN.  If it
> > receives Hellos on any other VLAN that should
> > be detected as an error condition and reported.
> >
> > There have been some problem corner cases that
> > have been pointed out previously on the list
> > that may result in temporary duplication of
> > traffic when there is misconfiguration.  Those
> > should be documented.
> >
> > Anoop
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Radia Perlman
> > > Sent: Saturday, October 20, 2007 9:47 PM
> > > To: Developing a hybrid router/bridge.
> > > Subject: [rbridge] Final outcome of outer VLAN tags on
> > > RBridge-RBridgepackets?
> > >
> > > I'm not sure I understood the final consensus on what we
> > > should do for outer VLAN tags on inter-RBridge packets.
> > >
> > > The possibilities I think the consensus might have been are:
> > >
> > > a) only use VLAN 1, explicit tag, no configuration possible.
> > > b) default is VLAN 1, explicit tag, configuration is possible
> > > to change sending with VLAN tag(s) something other than 1. If
> > > this is what was decided, I don't believe we've worked out
> > > the design details. I'd assume this would mean RBridges
> > > should be willing to receive packets from other RBridges
> > > regardless of outer VLAN tag. Would we then mark in the
> > > Hellos what VLAN tag(s) you've heard from what other RBridges
> > > with? What do we do with multicast if there isn't a single
> > > VLAN tag that seems to work to send to everyone? Would we
> > > allow configuration to send on a set of VLAN tags, or just on
> > > one at a time (and we allow configuration to say which one it is)?
> > >
> > > Certainly a) is simpler. If the consensus was b), we'd better
> > > work out the details.
> > >
> > > Radia
> > > _______________________________________________
> > > rbridge mailing list
> > > [email-masked]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> >
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Wed, 24 Oct 2007 10:11:19 -0700
From: "Silvano Gai" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Dinesh G Dutt" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLANtagsonRBridge-RBridgepackets?
Status: RO
Content-Length: 2878

Anoop,

I disagree.

We started all this discussion because you said that sending LSP on all
the VLANs was not scalable.

Now we discovered that there is a standard, existing solution that uses
Hellos on multiple VLANs for discovery and send LSP only on one VLAN.

This solution is robust and not subject to the corner cases that are
possible if you don't send Hellos on all the VLANs.

Let's use it, not invent anything new and close this topic.

-- Silvano

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[email-masked]]
> Sent: Tuesday, October 23, 2007 4:42 PM
> To: Dinesh G Dutt
> Cc: Silvano Gai; Radia Perlman; Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Final outcome of outer VLANtagsonRBridge-
> RBridgepackets?
> 
> Hi Dinesh,
> 
> It doesn't look like it would be essential at
> this point, so if we want to put it in for
> faster detection of certain configuration problems
> then it should be put in as optional.
> 
> Anoop
> 
> > -----Original Message-----
> > From: Dinesh G Dutt [mailto:[email-masked]]
> > Sent: Tuesday, October 23, 2007 2:11 PM
> > To: Anoop Ghanwani
> > Cc: Silvano Gai; Radia Perlman; Developing a hybrid router/bridge.
> > Subject: RE: [rbridge] Final outcome of outer
> > VLANtagsonRBridge-RBridgepackets?
> >
> > Anoop,
> >
> > I spoke to David Ward, an IS-IS expert here at Cisco (and a
> > co-author on the L2 ISIS draft) and he said that it's
> > perfectly fine to use Hellos on multiple VLANs for discovery
> > and send LSP only on one VLAN, one of the common ones.
> >
> > Can we then conclude that by default we send Hellos on a set
> > of one or more configured VLANs with the set being equal to
> > the active set of VLANs on that link by default ?
> >
> > Thanks,
> >
> > Dinesh
> > On Tue, 2007-10-23 at 10:04 -0700, Anoop Ghanwani wrote:
> > > > -----Original Message-----
> > > > From: Dinesh G Dutt [mailto:[email-masked]]
> > > > Sent: Tuesday, October 23, 2007 7:21 AM
> > > > To: Silvano Gai
> > > > Cc: Anoop Ghanwani; Radia Perlman; Developing a hybrid
> > router/bridge.
> > > > Subject: Re: [rbridge] Final outcome of outer VLAN
> > > > tagsonRBridge-RBridgepackets?
> > > >
> > > > I agree that using a single VLAN solution for IS-IS DRB is weak.
> > > > However, I'm skeptical that another protocol that also just
sends
> > > > Hellos is much more scalabale or better than IS-IS sending only
> > > > Hellos on all configured VLANs.
> > >
> > > Dinesh,
> > >
> > > The key here is just sending hellos as opposed to
> > maintaining a full
> > > IS-IS adjacency on the VLAN.  As long maintaining the
> > adjancency and
> > > sending LSPs on every VLAN is not required, the protocol
> > that is used
> > > for it doesn't matter.
> > >
> > > Anoop
> > --
> > "And those who were seen dancing were thought to be insane by
> > those who could not hear the music." -- Angela Monet
> >

Content-class: urn:content-classes:message
Date: Tue, 23 Oct 2007 16:42:16 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLANtagsonRBridge-RBridgepackets?
Status: RO
Content-Length: 2025

Hi Dinesh,

It doesn't look like it would be essential at
this point, so if we want to put it in for
faster detection of certain configuration problems
then it should be put in as optional.

Anoop 

> -----Original Message-----
> From: Dinesh G Dutt [mailto:[email-masked]] 
> Sent: Tuesday, October 23, 2007 2:11 PM
> To: Anoop Ghanwani
> Cc: Silvano Gai; Radia Perlman; Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Final outcome of outer 
> VLANtagsonRBridge-RBridgepackets?
> 
> Anoop,
> 
> I spoke to David Ward, an IS-IS expert here at Cisco (and a 
> co-author on the L2 ISIS draft) and he said that it's 
> perfectly fine to use Hellos on multiple VLANs for discovery 
> and send LSP only on one VLAN, one of the common ones.
> 
> Can we then conclude that by default we send Hellos on a set 
> of one or more configured VLANs with the set being equal to 
> the active set of VLANs on that link by default ?
> 
> Thanks,
> 
> Dinesh
> On Tue, 2007-10-23 at 10:04 -0700, Anoop Ghanwani wrote:
> > > -----Original Message-----
> > > From: Dinesh G Dutt [mailto:[email-masked]]
> > > Sent: Tuesday, October 23, 2007 7:21 AM
> > > To: Silvano Gai
> > > Cc: Anoop Ghanwani; Radia Perlman; Developing a hybrid 
> router/bridge.
> > > Subject: Re: [rbridge] Final outcome of outer VLAN 
> > > tagsonRBridge-RBridgepackets?
> > > 
> > > I agree that using a single VLAN solution for IS-IS DRB is weak.
> > > However, I'm skeptical that another protocol that also just sends 
> > > Hellos is much more scalabale or better than IS-IS sending only 
> > > Hellos on all configured VLANs.
> > 
> > Dinesh,
> > 
> > The key here is just sending hellos as opposed to 
> maintaining a full 
> > IS-IS adjacency on the VLAN.  As long maintaining the 
> adjancency and 
> > sending LSPs on every VLAN is not required, the protocol 
> that is used 
> > for it doesn't matter.
> > 
> > Anoop
> --
> "And those who were seen dancing were thought to be insane by 
> those who could not hear the music." -- Angela Monet
> 

Content-class: urn:content-classes:message
Date: Tue, 23 Oct 2007 17:14:27 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft
Status: RO
Content-Length: 2257

Sorry, my smiley was in connection with the "not yet specified"ness, not
to say that corruption isn't a serious problem when it occurs. At
transit Rbridges, TRILL data frames can normally be transmitted
unchanged from how they are received, including the FCS, or with only a
change in VLAN (or possibly priority) for which the FCS adjustment
shouldn't be too hard.

Donald 

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Monday, October 22, 2007 4:25 PM
To: Eastlake III Donald-LDE008
Cc: Developing a hybrid router/bridge.
Subject: RE: [rbridge] Trivial question about FCS in Figure 3 of
currentprotocol draft

Eastlake III Donald-LDE008 writes:
> Well, it doesn't seem that different from the situation with 802.1Q
> bridges inserting and deleting C and S tags or 802.1AE interfaces
> inserting or removing security tags or whatever.

It's not.  That's exactly why I said:

  That's not necessarily a horrible thing, in as much as most
  VLAN-capable bridges already do this today, but still a knowing
  choice.

> But I guess I don't see any problem with putting in a sentence about
> this.

OK; thanks.

> PS:  :-) I suppose people that are really worried about corruption or
> tampering with data inside their Rbridges should use the as yet to be
> specified security option of the as yet to be fully specified option
> feature...

I know you have a smiley there, but the lingering concern is about
message integrity being compromised by inadvertent errors rather than
protection from some sort of active attack.  End-to-end preservation
of FCS does provide protection against simple blunders.  Regeneration
at each node does not.

I wouldn't have made as big a deal out of it if we hadn't had our own
frightening run-in with the problem.  We had a "switch" (bridge) that
enjoyed flipping bits every once in a while on large packets.  The
fact that it computed a new FCS on entry into the VLAN (addition of
802.1Q header) meant that the failure was hard to find and nasty in
character.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

From: Dinesh G Dutt <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Date: Tue, 23 Oct 2007 14:10:48 -0700
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN	tagsonRBridge-RBridgepackets?
Status: RO
Content-Length: 1436

Anoop,

I spoke to David Ward, an IS-IS expert here at Cisco (and a co-author on
the L2 ISIS draft) and he said that it's perfectly fine to use Hellos on
multiple VLANs for discovery and send LSP only on one VLAN, one of the
common ones.

Can we then conclude that by default we send Hellos on a set of one or
more configured VLANs with the set being equal to the active set of
VLANs on that link by default ?

Thanks,

Dinesh
On Tue, 2007-10-23 at 10:04 -0700, Anoop Ghanwani wrote:
> > -----Original Message-----
> > From: Dinesh G Dutt [mailto:[email-masked]] 
> > Sent: Tuesday, October 23, 2007 7:21 AM
> > To: Silvano Gai
> > Cc: Anoop Ghanwani; Radia Perlman; Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] Final outcome of outer VLAN 
> > tagsonRBridge-RBridgepackets?
> > 
> > I agree that using a single VLAN solution for IS-IS DRB is weak.
> > However, I'm skeptical that another protocol that also just 
> > sends Hellos is much more scalabale or better than IS-IS 
> > sending only Hellos on all configured VLANs. 
> 
> Dinesh,
> 
> The key here is just sending hellos as opposed to maintaining
> a full IS-IS adjacency on the VLAN.  As long maintaining the
> adjancency and sending LSPs on every VLAN is not required, the
> protocol that is used for it doesn't matter.
> 
> Anoop
-- 
?And those who were seen dancing were thought to be insane by those  
who could not hear the music.? -- Angela Monet

Content-class: urn:content-classes:message
Date: Tue, 23 Oct 2007 16:45:42 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Silvano Gai" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tagsonRBridge-RBridgepackets?
Status: RO
Content-Length: 5594

Hi Silvano,

I have two questions:

(1) What exactly is the problem you see with doing adjacency on one
VLAN? It could be that you think that Hellos on one VLAN would be OK but
it is too much of a configuration burden to expect network
administrators to figure out which VLAN and to then configure their
Rbridges. Or it could be that you think that even if each port on each
Rbridge was configured to the "best" single VLAN, the adjacencies found
would be too sparse compared to those potentially possible. Or you could
think that both of these and/or other things are the main problem...

(2) If multiple Hellos on different VLANs, or some other technique, are
used to learn the full VLAN connectivity, what are Rbriges supposed to
do when no single VLAN will get to all the desired destinations? For
example, assume that Rbridge-A is connected as follows:

	On VLAN 2 to B and C
	On VLAN 3 to C, D, and E
	On VLAN 4 to F, G, and H
	On VLAN 5 to D, E, F, and G

If Rbrdige-A wants to send a multi-destination frame to all of B through
H, it would seem that it has to send it at least three times to get to
all the one-Rbridge-hop destinations and to avoid duplication. For
example, multicast on VLANs 3 and 4 and unicast to B. Or, alternatively,
multicast on VLANs 2 and 5 and unicast to H. Or, if the complexity
exceeds some threshold, Rbridge-A could just forget about optimality and
unicast the frame separately to B through H.

How would you suggest handling such situations?

Thanks,
Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Silvano Gai
Sent: Tuesday, October 23, 2007 6:21 AM
To: Anoop Ghanwani; Radia Perlman; Developing a hybrid router/bridge.
Subject: Re: [rbridge] Final outcome of outer VLAN
tagsonRBridge-RBridgepackets?

I want to restate that IMHO a design that sends messages on a single
VLAN is so week to be completely useless.

I met Anoop on a plane back from a T11 meeting and we discussed the
issue of sending messages on all the configured VLANs. Anoop pointed out
that, if these messages are ISIS messages, this can overload the RBrige
supervisor.

We identified a possible solution based on two different message types:
- ISIS used on a single VLAN to compute adjacency
- simple per-VLAN checking on all the VLANs to verify reachability.

The second kind of messages is much simpler and therefore they load less
the RBrige supervisor. In the future, per-VLAN checking can be
implemented by the port ASIC. This seems a viable solution that requires
design effort, but it is promising.

Without the per-VLAN checking, running ISIS on a single VLAN holds water
like a pasta-strainer.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Anoop Ghanwani
> Sent: Monday, October 22, 2007 11:01 AM
> To: Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-
> RBridgepackets?
> 
> 
> If we want to make implementations work with
> only a single Hello for all VLANs than the
> option is (a).  I think that is what it should be.
> Basically, as a part of RBridge configuration
> there should be a "RBridge Control VLAN" configuration
> that applies to the whole device.  It should default
> to VLAN 1, but an operator can choose to change it.
> A RBridge only emits Hellos on that VLAN.  If it
> receives Hellos on any other VLAN that should
> be detected as an error condition and reported.
> 
> There have been some problem corner cases that
> have been pointed out previously on the list
> that may result in temporary duplication of
> traffic when there is misconfiguration.  Those
> should be documented.
> 
> Anoop
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Radia Perlman
> > Sent: Saturday, October 20, 2007 9:47 PM
> > To: Developing a hybrid router/bridge.
> > Subject: [rbridge] Final outcome of outer VLAN tags on
> > RBridge-RBridgepackets?
> >
> > I'm not sure I understood the final consensus on what we
> > should do for outer VLAN tags on inter-RBridge packets.
> >
> > The possibilities I think the consensus might have been are:
> >
> > a) only use VLAN 1, explicit tag, no configuration possible.
> > b) default is VLAN 1, explicit tag, configuration is possible
> > to change sending with VLAN tag(s) something other than 1. If
> > this is what was decided, I don't believe we've worked out
> > the design details. I'd assume this would mean RBridges
> > should be willing to receive packets from other RBridges
> > regardless of outer VLAN tag. Would we then mark in the
> > Hellos what VLAN tag(s) you've heard from what other RBridges
> > with? What do we do with multicast if there isn't a single
> > VLAN tag that seems to work to send to everyone? Would we
> > allow configuration to send on a set of VLAN tags, or just on
> > one at a time (and we allow configuration to say which one it is)?
> >
> > Certainly a) is simpler. If the consensus was b), we'd better
> > work out the details.
> >
> > Radia
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

From: Dinesh G Dutt <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Date: Tue, 23 Oct 2007 10:09:52 -0700
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN	tagsonRBridge-RBridgepackets?
Status: RO
Content-Length: 1169

I have always thought that we need only Hellos to be per active VLAN so
that we can achieve reachability. I was not planning on sending LSPs per
VLAN. 

Dinesh
On Tue, 2007-10-23 at 10:04 -0700, Anoop Ghanwani wrote:
> > -----Original Message-----
> > From: Dinesh G Dutt [mailto:[email-masked]] 
> > Sent: Tuesday, October 23, 2007 7:21 AM
> > To: Silvano Gai
> > Cc: Anoop Ghanwani; Radia Perlman; Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] Final outcome of outer VLAN 
> > tagsonRBridge-RBridgepackets?
> > 
> > I agree that using a single VLAN solution for IS-IS DRB is weak.
> > However, I'm skeptical that another protocol that also just 
> > sends Hellos is much more scalabale or better than IS-IS 
> > sending only Hellos on all configured VLANs. 
> 
> Dinesh,
> 
> The key here is just sending hellos as opposed to maintaining
> a full IS-IS adjacency on the VLAN.  As long maintaining the
> adjancency and sending LSPs on every VLAN is not required, the
> protocol that is used for it doesn't matter.
> 
> Anoop
-- 
?And those who were seen dancing were thought to be insane by those  
who could not hear the music.? -- Angela Monet

Content-class: urn:content-classes:message
Date: Tue, 23 Oct 2007 10:04:12 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>, "Silvano Gai" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tagsonRBridge-RBridgepackets?
Status: RO
Content-Length: 785

> -----Original Message-----
> From: Dinesh G Dutt [mailto:[email-masked]] 
> Sent: Tuesday, October 23, 2007 7:21 AM
> To: Silvano Gai
> Cc: Anoop Ghanwani; Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Final outcome of outer VLAN 
> tagsonRBridge-RBridgepackets?
> 
> I agree that using a single VLAN solution for IS-IS DRB is weak.
> However, I'm skeptical that another protocol that also just 
> sends Hellos is much more scalabale or better than IS-IS 
> sending only Hellos on all configured VLANs. 

Dinesh,

The key here is just sending hellos as opposed to maintaining
a full IS-IS adjacency on the VLAN.  As long maintaining the
adjancency and sending LSPs on every VLAN is not required, the
protocol that is used for it doesn't matter.

Anoop

Content-class: urn:content-classes:message
Date: Tue, 23 Oct 2007 10:01:17 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Radia Perlman" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?
Status: RO
Content-Length: 4861

Silvano,

If we require the database synchronization step in Radia's
other email (#e) then we don't really need per VLAN messages.

Even if we have per-VLAN messages there will still be
scenarios that will break and we can at best only
detect them.

The only case where I think the per-VLAN scheme has an
advantage over the database synchronization approach
is when you have 2 ports that come up _simultaneously_
on a LAN and those have the misconfiguration problem
of not being able to see each other on the "RBridge
control VLAN".  In that case, depending on the
size of the network and how long it takes an LSP
to propagate, the per VLAN messages may detect the
problem a bit quicker.

Anoop

> -----Original Message-----
> From: Silvano Gai [mailto:[email-masked]] 
> Sent: Tuesday, October 23, 2007 3:21 AM
> To: Anoop Ghanwani; Radia Perlman; Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Final outcome of outer VLAN tags 
> onRBridge-RBridgepackets?
> 
> 
> I want to restate that IMHO a design that sends messages on a 
> single VLAN is so week to be completely useless.
> 
> I met Anoop on a plane back from a T11 meeting and we 
> discussed the issue of sending messages on all the configured 
> VLANs. Anoop pointed out that, if these messages are ISIS 
> messages, this can overload the RBrige supervisor.
> 
> We identified a possible solution based on two different 
> message types:
> - ISIS used on a single VLAN to compute adjacency
> - simple per-VLAN checking on all the VLANs to verify reachability.
> 
> The second kind of messages is much simpler and therefore 
> they load less the RBrige supervisor. In the future, per-VLAN 
> checking can be implemented by the port ASIC. This seems a 
> viable solution that requires design effort, but it is promising.
> 
> Without the per-VLAN checking, running ISIS on a single VLAN 
> holds water like a pasta-strainer.
> 
> -- Silvano
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Anoop Ghanwani
> > Sent: Monday, October 22, 2007 11:01 AM
> > To: Radia Perlman; Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- 
> > RBridgepackets?
> > 
> > 
> > If we want to make implementations work with only a single 
> Hello for 
> > all VLANs than the option is (a).  I think that is what it 
> should be.
> > Basically, as a part of RBridge configuration there should be a 
> > "RBridge Control VLAN" configuration that applies to the 
> whole device.  
> > It should default to VLAN 1, but an operator can choose to 
> change it.
> > A RBridge only emits Hellos on that VLAN.  If it receives Hellos on 
> > any other VLAN that should be detected as an error condition and 
> > reported.
> > 
> > There have been some problem corner cases that have been 
> pointed out 
> > previously on the list that may result in temporary duplication of 
> > traffic when there is misconfiguration.  Those should be documented.
> > 
> > Anoop
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Radia Perlman
> > > Sent: Saturday, October 20, 2007 9:47 PM
> > > To: Developing a hybrid router/bridge.
> > > Subject: [rbridge] Final outcome of outer VLAN tags on 
> > > RBridge-RBridgepackets?
> > >
> > > I'm not sure I understood the final consensus on what we 
> should do 
> > > for outer VLAN tags on inter-RBridge packets.
> > >
> > > The possibilities I think the consensus might have been are:
> > >
> > > a) only use VLAN 1, explicit tag, no configuration possible.
> > > b) default is VLAN 1, explicit tag, configuration is possible to 
> > > change sending with VLAN tag(s) something other than 1. 
> If this is 
> > > what was decided, I don't believe we've worked out the design 
> > > details. I'd assume this would mean RBridges should be willing to 
> > > receive packets from other RBridges regardless of outer VLAN tag. 
> > > Would we then mark in the Hellos what VLAN tag(s) you've 
> heard from 
> > > what other RBridges with? What do we do with multicast if there 
> > > isn't a single VLAN tag that seems to work to send to everyone? 
> > > Would we allow configuration to send on a set of VLAN 
> tags, or just 
> > > on one at a time (and we allow configuration to say which one it 
> > > is)?
> > >
> > > Certainly a) is simpler. If the consensus was b), we'd 
> better work 
> > > out the details.
> > >
> > > Radia
> > > _______________________________________________
> > > rbridge mailing list
> > > [email-masked]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 

From: Dinesh G Dutt <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Tue, 23 Oct 2007 07:20:57 -0700
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tags	onRBridge-RBridgepackets?
Status: RO
Content-Length: 4392

I agree that using a single VLAN solution for IS-IS DRB is weak.
However, I'm skeptical that another protocol that also just sends Hellos
is much more scalabale or better than IS-IS sending only Hellos on all
configured VLANs. 

Dinesh
On Tue, 2007-10-23 at 03:20 -0700, Silvano Gai wrote:
> I want to restate that IMHO a design that sends messages on a single
> VLAN is so week to be completely useless.
> 
> I met Anoop on a plane back from a T11 meeting and we discussed the
> issue of sending messages on all the configured VLANs. Anoop pointed out
> that, if these messages are ISIS messages, this can overload the RBrige
> supervisor.
> 
> We identified a possible solution based on two different message types:
> - ISIS used on a single VLAN to compute adjacency
> - simple per-VLAN checking on all the VLANs to verify reachability.
> 
> The second kind of messages is much simpler and therefore they load less
> the RBrige supervisor. In the future, per-VLAN checking can be
> implemented by the port ASIC. This seems a viable solution that requires
> design effort, but it is promising.
> 
> Without the per-VLAN checking, running ISIS on a single VLAN holds water
> like a pasta-strainer.
> 
> -- Silvano
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Anoop Ghanwani
> > Sent: Monday, October 22, 2007 11:01 AM
> > To: Radia Perlman; Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-
> > RBridgepackets?
> > 
> > 
> > If we want to make implementations work with
> > only a single Hello for all VLANs than the
> > option is (a).  I think that is what it should be.
> > Basically, as a part of RBridge configuration
> > there should be a "RBridge Control VLAN" configuration
> > that applies to the whole device.  It should default
> > to VLAN 1, but an operator can choose to change it.
> > A RBridge only emits Hellos on that VLAN.  If it
> > receives Hellos on any other VLAN that should
> > be detected as an error condition and reported.
> > 
> > There have been some problem corner cases that
> > have been pointed out previously on the list
> > that may result in temporary duplication of
> > traffic when there is misconfiguration.  Those
> > should be documented.
> > 
> > Anoop
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Radia Perlman
> > > Sent: Saturday, October 20, 2007 9:47 PM
> > > To: Developing a hybrid router/bridge.
> > > Subject: [rbridge] Final outcome of outer VLAN tags on
> > > RBridge-RBridgepackets?
> > >
> > > I'm not sure I understood the final consensus on what we
> > > should do for outer VLAN tags on inter-RBridge packets.
> > >
> > > The possibilities I think the consensus might have been are:
> > >
> > > a) only use VLAN 1, explicit tag, no configuration possible.
> > > b) default is VLAN 1, explicit tag, configuration is possible
> > > to change sending with VLAN tag(s) something other than 1. If
> > > this is what was decided, I don't believe we've worked out
> > > the design details. I'd assume this would mean RBridges
> > > should be willing to receive packets from other RBridges
> > > regardless of outer VLAN tag. Would we then mark in the
> > > Hellos what VLAN tag(s) you've heard from what other RBridges
> > > with? What do we do with multicast if there isn't a single
> > > VLAN tag that seems to work to send to everyone? Would we
> > > allow configuration to send on a set of VLAN tags, or just on
> > > one at a time (and we allow configuration to say which one it is)?
> > >
> > > Certainly a) is simpler. If the consensus was b), we'd better
> > > work out the details.
> > >
> > > Radia
> > > _______________________________________________
> > > rbridge mailing list
> > > [email-masked]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
-- 
?And those who were seen dancing were thought to be insane by those  
who could not hear the music.? -- Angela Monet

Content-class: urn:content-classes:message
Date: Tue, 23 Oct 2007 03:20:34 -0700
From: "Silvano Gai" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Radia Perlman" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?
Status: RO
Content-Length: 3644

I want to restate that IMHO a design that sends messages on a single
VLAN is so week to be completely useless.

I met Anoop on a plane back from a T11 meeting and we discussed the
issue of sending messages on all the configured VLANs. Anoop pointed out
that, if these messages are ISIS messages, this can overload the RBrige
supervisor.

We identified a possible solution based on two different message types:
- ISIS used on a single VLAN to compute adjacency
- simple per-VLAN checking on all the VLANs to verify reachability.

The second kind of messages is much simpler and therefore they load less
the RBrige supervisor. In the future, per-VLAN checking can be
implemented by the port ASIC. This seems a viable solution that requires
design effort, but it is promising.

Without the per-VLAN checking, running ISIS on a single VLAN holds water
like a pasta-strainer.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Anoop Ghanwani
> Sent: Monday, October 22, 2007 11:01 AM
> To: Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-
> RBridgepackets?
> 
> 
> If we want to make implementations work with
> only a single Hello for all VLANs than the
> option is (a).  I think that is what it should be.
> Basically, as a part of RBridge configuration
> there should be a "RBridge Control VLAN" configuration
> that applies to the whole device.  It should default
> to VLAN 1, but an operator can choose to change it.
> A RBridge only emits Hellos on that VLAN.  If it
> receives Hellos on any other VLAN that should
> be detected as an error condition and reported.
> 
> There have been some problem corner cases that
> have been pointed out previously on the list
> that may result in temporary duplication of
> traffic when there is misconfiguration.  Those
> should be documented.
> 
> Anoop
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Radia Perlman
> > Sent: Saturday, October 20, 2007 9:47 PM
> > To: Developing a hybrid router/bridge.
> > Subject: [rbridge] Final outcome of outer VLAN tags on
> > RBridge-RBridgepackets?
> >
> > I'm not sure I understood the final consensus on what we
> > should do for outer VLAN tags on inter-RBridge packets.
> >
> > The possibilities I think the consensus might have been are:
> >
> > a) only use VLAN 1, explicit tag, no configuration possible.
> > b) default is VLAN 1, explicit tag, configuration is possible
> > to change sending with VLAN tag(s) something other than 1. If
> > this is what was decided, I don't believe we've worked out
> > the design details. I'd assume this would mean RBridges
> > should be willing to receive packets from other RBridges
> > regardless of outer VLAN tag. Would we then mark in the
> > Hellos what VLAN tag(s) you've heard from what other RBridges
> > with? What do we do with multicast if there isn't a single
> > VLAN tag that seems to work to send to everyone? Would we
> > allow configuration to send on a set of VLAN tags, or just on
> > one at a time (and we allow configuration to say which one it is)?
> >
> > Certainly a) is simpler. If the consensus was b), we'd better
> > work out the details.
> >
> > Radia
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Date: Mon, 22 Oct 2007 17:23:34 -0700
From: [email-masked]
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 11529

This is a multi-part message in MIME format.

--Boundary_(ID_aZKPm/MXYup5zLLATOxNmg)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

This goes along with the previous question I just posted, with subject line
"Final outcome of outer VLAN tags on RBridge-RBridge    packets?"

After rereading the thread with this subject line, there were a few 
"Hmm, have to think
about that" comments, and one person who seemed unhappy with
not letting the VLAN be configurable, and then the thread seemed to just
peter out.
So I will
reiterate what I think the details of the proposal are, along with
a counterproposal if people *really* want it configurable. Though I
prefer not configurable. Before editing the spec, I would like people
to explicitly say whether they're happy with the proposal below, or
if not, whether they're happy with the additional proposal below the
line of stars, and perhaps they could say "I could live with either, I
prefer nonconfigurable", or "I could only live with configurable, and
am OK with the proposal below the stars", or "I don't like either one
because....and I'd like to counterpropose ..."

Thanks.....Radia

---------Nonconfigurable proposal-------

a) on each layer 2 cloud, all RBrdge-RBridge communication (including
IS-IS Hellos and encapsulated data packet forwarding) will be sent with

one VLAN tag, VLAN 1, with an explicit outer VLAN tag. This would not be configurable.
Therefore we would not need to worry about the case where there are different
configurations of RBridges on the same cloud.

b) it will be a MUST to listen to spanning tree messages and include the 
root bridge ID
in the pseudonode LSP. Note that "listening to" either STP or RSTP is identical.
In other words, an RBridge does not need to know or care whether the bridges
are running STP or RSTP. As for MSTP, the only spanning tree RBridges need
to listen to is the CIST (common and internal spanning
tree). The only root bridge RBridges would report (in the case of MSTP) is
the root bridge of the CIST.

c) if R1 notices (in the link state database)
a pseudonode with a root bridge that is the same as a 
link that R1 thinks
R1 is designated on, R1 does not forward data to/from that link if R1's 
6-byte IS-IS ID
is less than the ID of  the DRB for that pseudonode

d) if R1 is DRB on a link, R1 will not decapsulate anything onto the 
link from ingress R2 unless
R1 has received an LSP from R2 and all pseudonodes that R2 (in R2's LSP)
claims to be  attached to,
and that R2 claims to be DRB for

e) when R1 first comes up, it waits some amount of time on a link before 
deciding that it is DRB
(several Hello intervals), and after becoming DRB, it still does not 
forward data off the link until
it has synchronized LSP databases with its neighbors. "Synchronizing" 
means that it receives
a CSNP from the neighbor, and winds up with LSPs at least as up-to-date 
as those reported
in that CSNP. (Note: I think it would be a good idea to have a flag in 
the Hello message saying "I'd
like to receive a CSNP from you" in case the neighbor sent one and it 
got lost -- on a LAN,
the DRB should be sending them periodically, but if we have pt-to-pt 
links at least in current IS-IS,
CSNPs are not sent periodically, though we could say RBridges should 
send them periodically
on pt-to-pt links.)

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

--------Proposal adding configurability-------

If we *had* to make the VLAN in a) configurable, this is a suggestion for
how to do it:
1) steady state on any VLAN cloud, all the RBridges would transmit on
only one VLAN tag, and all would be using the same VLAN tag

2) the default would be VLAN 1

3) all RBridges would be willing to receive IS-IS Hellos with
any VLAN tag (or maybe some subset that is configurable, that must
always contain VLAN 1)

4) The DRB states in its Hello, what VLAN tag is to be used. If the
DRB says "use VLAN 7", then all RBridges must switch to using VLAN tag 7,
until they no longer hear that DRB's hellos. If
they no longer hear the DRB's Hellos, (which means they think they
are DRB at least temporarily) they revert
to whatever they are configured to send on. "use VLAN 7" means
that *all* RBridge-RBridge communication (data packet forwarding and
IS-IS Hellos) will be sent using VLAN tag 7. Except (as noted in 6) below)
the DRB will send its Hellos both on 7 and 1. (The reason I said this is
that I think it might be safer).

5) The default is to send on VLAN 1. If you are configured to send on 7,
then you send on *both* VLAN 1 and VLAN 7, until you are told
by the DRB what to send on, and then you send ONLY on that one (whether
it be 1, 7, or something else)

6) if you are DRB, and you are configured to send on 7, you always send
both on 1 and 7, and report in your Hello "send on 7", which will cause
all the other RBridges to send Hellos *only* on 7, where you will send
on 1 and 7. You only report, in your Hello, the list of other RBridges
on that cloud that you successfully hear Hellos from on 7 (even if
you hear Hellos from them on 1 or some other VLAN tag)

*However* I still recommend making VLAN 1 *not* configurable. I'd think
if a customer is willing to do fancy configuration, and wanted to keep
RBridge-RBridge traffic off VLAN 1, or wanted VLAN 1 to be partitioned
on a layer 2 cloud, then that customer could renumber the use of their VLANs
to make VLAN 1 be one that is not partitioned, and that is OK to send
RBridge traffic on.

But at any rate -- I want to make sure we all agree to one design.

Radia

--Boundary_(ID_aZKPm/MXYup5zLLATOxNmg)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<small>This goes along with the previous question I just posted, with
subject line<br>
"Final outcome of outer VLAN tags on RBridge-RBridge&nbsp;&nbsp;&nbsp; packets?"</small><br>
<br>
<small>After rereading the thread with this subject line, there were a
few "Hmm, have to think<br>
about that" comments, and one person who seemed unhappy with<br>
not letting the VLAN be configurable, and then the thread seemed to just<br>
peter out.<br>
So I will<br>
reiterate what I think the details of the proposal are, along with<br>
a counterproposal if people *really* want it configurable. Though I<br>
prefer not configurable. Before editing the spec, I would like people<br>
to explicitly say whether they're happy with the proposal below, or<br>
if not, whether they're happy with the additional proposal below the<br>
line of stars, and perhaps they could say "I could live with either, I<br>
prefer nonconfigurable", or "I could only live with configurable, and<br>
am OK with the proposal below the stars", or "I don't like either one<br>
because....and I'd like to counterpropose ..."<br>
<br>
Thanks.....Radia<br>
<br>
<big>---------Nonconfigurable proposal-------<br>
</big></small><br>
<small>a) on each layer 2 cloud, all RBrdge-RBridge communication
(including</small><br>
<small>IS-IS Hellos and encapsulated data packet forwarding) will be
sent with <br>
</small>
<pre wrap="">one VLAN tag, VLAN 1, with an explicit outer VLAN tag. This would not be configurable.
Therefore we would not need to worry about the case where there are different
configurations of RBridges on the same cloud.

b) it will be a MUST to listen to spanning tree messages and include the 
root bridge ID
in the pseudonode LSP. Note that "listening to" either STP or RSTP is identical.
In other words, an RBridge does not need to know or care whether the bridges
are running STP or RSTP. As for MSTP, the only spanning tree RBridges need
to listen to is the CIST (common and internal spanning
tree). The only root bridge RBridges would report (in the case of MSTP) is
the root bridge of the CIST.

c) if R1 notices (in the link state database)
a pseudonode with a root bridge that is the same as a 
link that R1 thinks
R1 is designated on, R1 does not forward data to/from that link if R1's 
6-byte IS-IS ID
is less than the ID of  the DRB for that pseudonode

d) if R1 is DRB on a link, R1 will not decapsulate anything onto the 
link from ingress R2 unless
R1 has received an LSP from R2 and all pseudonodes that R2 (in R2's LSP)
claims to be  attached to,
and that R2 claims to be DRB for

e) when R1 first comes up, it waits some amount of time on a link before 
deciding that it is DRB
(several Hello intervals), and after becoming DRB, it still does not 
forward data off the link until
it has synchronized LSP databases with its neighbors. "Synchronizing" 
means that it receives
a CSNP from the neighbor, and winds up with LSPs at least as up-to-date 
as those reported
in that CSNP. (Note: I think it would be a good idea to have a flag in 
the Hello message saying "I'd
like to receive a CSNP from you" in case the neighbor sent one and it 
got lost -- on a LAN,
the DRB should be sending them periodically, but if we have pt-to-pt 
links at least in current IS-IS,
CSNPs are not sent periodically, though we could say RBridges should 
send them periodically
on pt-to-pt links.)

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

<big>--------Proposal adding configurability-------</big>

If we *had* to make the VLAN in a) configurable, this is a suggestion for
how to do it:
1) steady state on any VLAN cloud, all the RBridges would transmit on
only one VLAN tag, and all would be using the same VLAN tag

2) the default would be VLAN 1

3) all RBridges would be willing to receive IS-IS Hellos with
any VLAN tag (or maybe some subset that is configurable, that must
always contain VLAN 1)

4) The DRB states in its Hello, what VLAN tag is to be used. If the
DRB says "use VLAN 7", then all RBridges must switch to using VLAN tag 7,
until they no longer hear that DRB's hellos. If
they no longer hear the DRB's Hellos, (which means they think they
are DRB at least temporarily) they revert
to whatever they are configured to send on. "use VLAN 7" means
that *all* RBridge-RBridge communication (data packet forwarding and
IS-IS Hellos) will be sent using VLAN tag 7. Except (as noted in 6) below)
the DRB will send its Hellos both on 7 and 1. (The reason I said this is
that I think it might be safer).

5) The default is to send on VLAN 1. If you are configured to send on 7,
then you send on *both* VLAN 1 and VLAN 7, until you are told
by the DRB what to send on, and then you send ONLY on that one (whether
it be 1, 7, or something else)

6) if you are DRB, and you are configured to send on 7, you always send
both on 1 and 7, and report in your Hello "send on 7", which will cause
all the other RBridges to send Hellos *only* on 7, where you will send
on 1 and 7. You only report, in your Hello, the list of other RBridges
on that cloud that you successfully hear Hellos from on 7 (even if
you hear Hellos from them on 1 or some other VLAN tag)

*However* I still recommend making VLAN 1 *not* configurable. I'd think
if a customer is willing to do fancy configuration, and wanted to keep
RBridge-RBridge traffic off VLAN 1, or wanted VLAN 1 to be partitioned
on a layer 2 cloud, then that customer could renumber the use of their VLANs
to make VLAN 1 be one that is not partitioned, and that is OK to send
RBridge traffic on.

But at any rate -- I want to make sure we all agree to one design.

Radia

</pre>
<br>
</body>
</html>

--Boundary_(ID_aZKPm/MXYup5zLLATOxNmg)--

Date: Mon, 22 Oct 2007 16:24:41 -0400
From: James Carlson <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft
Status: RO
Content-Length: 1603

Eastlake III Donald-LDE008 writes:
> Well, it doesn't seem that different from the situation with 802.1Q
> bridges inserting and deleting C and S tags or 802.1AE interfaces
> inserting or removing security tags or whatever.

It's not.  That's exactly why I said:

  That's not necessarily a horrible thing, in as much as most
  VLAN-capable bridges already do this today, but still a knowing
  choice.

> But I guess I don't see any problem with putting in a sentence about
> this.

OK; thanks.

> PS:  :-) I suppose people that are really worried about corruption or
> tampering with data inside their Rbridges should use the as yet to be
> specified security option of the as yet to be fully specified option
> feature...

I know you have a smiley there, but the lingering concern is about
message integrity being compromised by inadvertent errors rather than
protection from some sort of active attack.  End-to-end preservation
of FCS does provide protection against simple blunders.  Regeneration
at each node does not.

I wouldn't have made as big a deal out of it if we hadn't had our own
frightening run-in with the problem.  We had a "switch" (bridge) that
enjoyed flipping bits every once in a while on large packets.  The
fact that it computed a new FCS on entry into the VLAN (addition of
802.1Q header) meant that the failure was hard to find and nasty in
character.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Content-class: urn:content-classes:message
Date: Mon, 22 Oct 2007 16:13:41 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft
Status: RO
Content-Length: 2502

Well, it doesn't seem that different from the situation with 802.1Q
bridges inserting and deleting C and S tags or 802.1AE interfaces
inserting or removing security tags or whatever.

But I guess I don't see any problem with putting in a sentence about
this.

Thanks,
Donald

PS:  :-) I suppose people that are really worried about corruption or
tampering with data inside their Rbridges should use the as yet to be
specified security option of the as yet to be fully specified option
feature...

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Monday, October 22, 2007 3:26 PM
To: Eastlake III Donald-LDE008
Cc: Developing a hybrid router/bridge.
Subject: RE: [rbridge] Trivial question about FCS in Figure 3 of
currentprotocol draft

Eastlake III Donald-LDE008 writes:
> Another strategy is to keep the FCS on admitting a frame and whenever
> you delete, insert, or change anything in the frame during processing
to
> do a compensating adjustment to the FCS, then transmit this modified
FCS
> with the frame.

That's a tall order with insert or delete, though there seem to be
(encumbered) mechanisms available.  I suspect that most
implementations will simply recompute unless a suitable adjustment
algorithm is suggested as part of the final document.

> This alternative to generating it from scratch when the
> frame leaves the bridge/Rbridge would have a reasonable chance of
> detecting something like memory corruption within the device.

Sure.  I doubt that we'll see this in practice, though, and I think we
need to be aware that what we are really endorsing here is breaking
the end-to-end CRC argument for Ethernet subnetworks.  That's not
necessarily a horrible thing, in as much as most VLAN-capable bridges
already do this today, but still a knowing choice.

> But I don't think we should say anything about which strategy Rbridge
> implementations use other than requiring them to send frames with
> correct FCS values and discard received frames with bad FCS values. 

In as much as it affects the correctness of the bits on the wire, I
think mentioning the risks of the regeneration issue is in scope for
this document.  It's as much in-scope as it was to create an option to
_avoid_ the very same problem in RFC 3518.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Date: Mon, 22 Oct 2007 15:26:26 -0400
From: James Carlson <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft
Status: RO
Content-Length: 1726

Eastlake III Donald-LDE008 writes:
> Another strategy is to keep the FCS on admitting a frame and whenever
> you delete, insert, or change anything in the frame during processing to
> do a compensating adjustment to the FCS, then transmit this modified FCS
> with the frame.

That's a tall order with insert or delete, though there seem to be
(encumbered) mechanisms available.  I suspect that most
implementations will simply recompute unless a suitable adjustment
algorithm is suggested as part of the final document.

> This alternative to generating it from scratch when the
> frame leaves the bridge/Rbridge would have a reasonable chance of
> detecting something like memory corruption within the device.

Sure.  I doubt that we'll see this in practice, though, and I think we
need to be aware that what we are really endorsing here is breaking
the end-to-end CRC argument for Ethernet subnetworks.  That's not
necessarily a horrible thing, in as much as most VLAN-capable bridges
already do this today, but still a knowing choice.

> But I don't think we should say anything about which strategy Rbridge
> implementations use other than requiring them to send frames with
> correct FCS values and discard received frames with bad FCS values. 

In as much as it affects the correctness of the bits on the wire, I
think mentioning the risks of the regeneration issue is in scope for
this document.  It's as much in-scope as it was to create an option to
_avoid_ the very same problem in RFC 3518.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Content-class: urn:content-classes:message
Date: Mon, 22 Oct 2007 14:22:23 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Egress processing of unicast not locally known
Status: RO
Content-Length: 3717

Dinesh,

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

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

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

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

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

Thanks,
Donald

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

Donald,

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

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

Content-class: urn:content-classes:message
Date: Mon, 22 Oct 2007 11:01:17 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Final outcome of outer VLAN tags on RBridge-RBridgepackets?
Status: RO
Content-Length: 2200

If we want to make implementations work with
only a single Hello for all VLANs than the
option is (a).  I think that is what it should be.
Basically, as a part of RBridge configuration
there should be a "RBridge Control VLAN" configuration
that applies to the whole device.  It should default
to VLAN 1, but an operator can choose to change it.
A RBridge only emits Hellos on that VLAN.  If it
receives Hellos on any other VLAN that should
be detected as an error condition and reported.

There have been some problem corner cases that
have been pointed out previously on the list
that may result in temporary duplication of
traffic when there is misconfiguration.  Those
should be documented.

Anoop

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Saturday, October 20, 2007 9:47 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] Final outcome of outer VLAN tags on 
> RBridge-RBridgepackets?
> 
> I'm not sure I understood the final consensus on what we 
> should do for outer VLAN tags on inter-RBridge packets.
> 
> The possibilities I think the consensus might have been are:
> 
> a) only use VLAN 1, explicit tag, no configuration possible.
> b) default is VLAN 1, explicit tag, configuration is possible 
> to change sending with VLAN tag(s) something other than 1. If 
> this is what was decided, I don't believe we've worked out 
> the design details. I'd assume this would mean RBridges 
> should be willing to receive packets from other RBridges 
> regardless of outer VLAN tag. Would we then mark in the 
> Hellos what VLAN tag(s) you've heard from what other RBridges 
> with? What do we do with multicast if there isn't a single 
> VLAN tag that seems to work to send to everyone? Would we 
> allow configuration to send on a set of VLAN tags, or just on 
> one at a time (and we allow configuration to say which one it is)?
> 
> Certainly a) is simpler. If the consensus was b), we'd better 
> work out the details.
> 
> Radia
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Mon, 22 Oct 2007 13:40:45 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft
Status: RO
Content-Length: 2637

I agree it is not as simple as I made out.

Another strategy is to keep the FCS on admitting a frame and whenever
you delete, insert, or change anything in the frame during processing to
do a compensating adjustment to the FCS, then transmit this modified FCS
with the frame. This alternative to generating it from scratch when the
frame leaves the bridge/Rbridge would have a reasonable chance of
detecting something like memory corruption within the device.

But I don't think we should say anything about which strategy Rbridge
implementations use other than requiring them to send frames with
correct FCS values and discard received frames with bad FCS values. 

Thanks,
Donald

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Monday, October 22, 2007 12:10 PM
To: Eastlake III Donald-LDE008
Cc: Radia Perlman; Developing a hybrid router/bridge.
Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of
currentprotocol draft

Eastlake III Donald-LDE008 writes:
> The FCS is commonly something that's buried in the port hardware and
> gets generated at the time of or just before frame transmission and
> checked at the time of or just after receipt and sometimes doesn't
exist
> in the interior of a bridge/Rbridge.
> 
> Since Figures 3 and 7 say they are a frame as it appears on the wire,
> which is what IETF protocol descriptions are normally interested in,
one
> and only one FCS should be shown.

I'm not sure that the question or the answer are 'trivial' here.

In a regular (non-VLAN) bridge, the FCS is normally preserved
end-to-end, so that it protects the frame in transit from molestation
by intermediate bridges.  This is why RFC 3518 (PPP Bridging) contains
a LAN Frame Checksum Preservation feature.

With VLANs, this is no longer true, and corruption introduced by an
intermediate malfunctioning bridge was in fact the cause of a
significant network outage at Sun several years ago -- so I think it's
not a trivial matter to commit to non-preservation of FCS.

All that said, I agree with the current plan: there's a single
medium-dependent FCS, checked and regenerated at hop, and thus no
protection of the frame contents while resident in system memory of
one of the intermediate bridges.  Adding an option (sigh!) for
end-to-end preservation would be nice, but may well be fighting an
uphill battle in terms of functionality and compexity.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Date: Mon, 22 Oct 2007 12:09:52 -0400
From: James Carlson <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of current	protocol draft
Status: RO
Content-Length: 1657

Eastlake III Donald-LDE008 writes:
> The FCS is commonly something that's buried in the port hardware and
> gets generated at the time of or just before frame transmission and
> checked at the time of or just after receipt and sometimes doesn't exist
> in the interior of a bridge/Rbridge.
> 
> Since Figures 3 and 7 say they are a frame as it appears on the wire,
> which is what IETF protocol descriptions are normally interested in, one
> and only one FCS should be shown.

I'm not sure that the question or the answer are 'trivial' here.

In a regular (non-VLAN) bridge, the FCS is normally preserved
end-to-end, so that it protects the frame in transit from molestation
by intermediate bridges.  This is why RFC 3518 (PPP Bridging) contains
a LAN Frame Checksum Preservation feature.

With VLANs, this is no longer true, and corruption introduced by an
intermediate malfunctioning bridge was in fact the cause of a
significant network outage at Sun several years ago -- so I think it's
not a trivial matter to commit to non-preservation of FCS.

All that said, I agree with the current plan: there's a single
medium-dependent FCS, checked and regenerated at hop, and thus no
protection of the frame contents while resident in system memory of
one of the intermediate bridges.  Adding an option (sigh!) for
end-to-end preservation would be nice, but may well be fighting an
uphill battle in terms of functionality and compexity.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Content-class: urn:content-classes:message
Date: Sun, 21 Oct 2007 17:02:17 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of current protocol draft
Status: RO
Content-Length: 1227

See Section 4.1.4.

The FCS is commonly something that's buried in the port hardware and
gets generated at the time of or just before frame transmission and
checked at the time of or just after receipt and sometimes doesn't exist
in the interior of a bridge/Rbridge.

Since Figures 3 and 7 say they are a frame as it appears on the wire,
which is what IETF protocol descriptions are normally interested in, one
and only one FCS should be shown.

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Sunday, October 21, 2007 12:39 AM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Trivial question about FCS in Figure 3 of
currentprotocol draft

Figure 3 (bottom of page 9) has "Ethernet FCS". Since there are two 
Ethernet headers
(inner and outer), wouldn't there be two Ethernet FCS's? Should the 
diagram simply
omit "Ethernet FCS" or put it twice? Or is it correct somehow and I'm 
not looking at it right,
or do we actually intend to omit the inner Ethernet frame's FCS?

Thanks,

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

Date: Sat, 20 Oct 2007 21:47:10 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Final outcome of outer VLAN tags on RBridge-RBridge packets?
Status: RO
Content-Length: 998

I'm not sure I understood the final consensus on what we should do for 
outer VLAN tags on inter-RBridge packets.

The possibilities I think the consensus might have been are:

a) only use VLAN 1, explicit tag, no configuration possible.
b) default is VLAN 1, explicit tag, configuration is possible to change 
sending with VLAN tag(s)
something other than 1. If this is what was decided, I don't believe 
we've worked out the design
details. I'd assume this would mean RBridges should be willing to 
receive packets from other
RBridges regardless of outer VLAN tag. Would we then mark in the Hellos 
what VLAN tag(s)
you've heard from what other RBridges with? What do we do with multicast 
if there isn't a single
VLAN tag that seems to work to send to everyone? Would we allow 
configuration to
send on a set of VLAN tags, or just on one at a time (and we allow 
configuration to say
which one it is)?

Certainly a) is simpler. If the consensus was b), we'd better work out 
the details.

Radia

Date: Sat, 20 Oct 2007 21:39:07 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Trivial question about FCS in Figure 3 of current protocol draft
Status: RO
Content-Length: 347

Figure 3 (bottom of page 9) has "Ethernet FCS". Since there are two 
Ethernet headers
(inner and outer), wouldn't there be two Ethernet FCS's? Should the 
diagram simply
omit "Ethernet FCS" or put it twice? Or is it correct somehow and I'm 
not looking at it right,
or do we actually intend to omit the inner Ethernet frame's FCS?

Thanks,

Radia

Content-class: urn:content-classes:message
Date: Fri, 19 Oct 2007 16:25:48 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Milestones have been updates
Status: RO
Content-Length: 147

Hi,

The TRILL WG Milestones have been updated on our charter page including
elimination of the Routing Requirements deliverable.

Thanks,
Donald

Content-class: urn:content-classes:message
Date: Thu, 18 Oct 2007 12:37:34 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] Consensus Call: V-field reversion
Status: RO
Content-Length: 2456

Is there any objection to the following format:

                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                 | V | R |M|Op-Length| Hop Count | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |   Egress RBridge Nickname     |  Ingress RBridge Nickname     | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Where V = version, R = reserved, and M = multi-destination.

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Tuesday, October 02, 2007 11:18 PM
To: [email-masked]
Subject: [rbridge] Consensus Call: V-field reversion

This consensus from the Chicago meeting has been confirmed.

Donald & Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Monday, September 17, 2007 1:37 AM
To: Joe Touch
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: V-field reversion

Right. (I'm generally using the somewhat less formal wording from the
minutes in these consensus checks.)

Thanks,
Donald

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 9:53 AM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: V-field reversion

Eastlake III Donald-LDE008 wrote:
> This is a check via the mailing list to confirm or refute an apparent
> consensus at the Chicago meeting for a change from protocol draft -05:
> 
>    Eliminate different V field values and revert to two version bits
>    and two reserved bits with the previous provisions that this draft
>    specifies version zero, frames with an unknown version are
>    discarded, reserved bits MUST be zero and are ignored on receipt.

Minor nit to avoid ambiguity:

...MUST be _set to_ zero...

> If no particular controversy arises over this in the next two weeks,
we
> will declare it to be the working group consensus.
> 
> Thanks,
> Donald & Erik
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

-- 
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

Content-class: urn:content-classes:message
Date: Thu, 18 Oct 2007 12:33:45 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Call: Inner Multicast Address of TRILL IS-ISFrames
Status: RO
Content-Length: 960

This consensus from the Chicago meeting has been confirmed.

Donald & Erik 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Tuesday, October 02, 2007 11:25 PM
To: [email-masked]
Subject: [rbridge] Consensus Check: Inner Multicast Address of TRILL
IS-ISFrames

This is a check via the mailing list to confirm or refute an apparent
consensus from the minutes of the Chicago meeting for a change from
protocol draft -05:

   Utilize a different multicast address ("All-IS-IS-RBridges"),
   allocated to RBridges, as the inner MAC destination address of
   TRILL IS-IS Frames.

If no particular controversy arises over this in the next two weeks, we
will declare it to be the working group consensus.

Thanks,
Donald & Erik

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Fri, 12 Oct 2007 13:27:16 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Announcing Root
Status: RO
Content-Length: 3388

I think the reserved value apply only to the OUI inside the SNAP, not
the one in the MAC address.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Friday, October 12, 2007 12:21 PM
> To: Anoop Ghanwani
> Cc: [email-masked]
> Subject: Re: [rbridge] Consensus Check: Announcing Root
> 
> I'm fine with option (b) but it seems implausible that all 0's could
> ever be a normal MAC address. Among other things, the 00-00-00 OUI is
> reserved for expressing arbitrary EtherTypes in the SNAP SAP format...
> 
> Donald
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[email-masked]]
> Sent: Monday, October 08, 2007 10:56 AM
> To: [email-masked]; Eastlake III Donald-LDE008
> Cc: [email-masked]
> Subject: RE: [rbridge] Consensus Check: Announcing Root
> 
> I would prefer (a) or (b) since 0 is technically
> a valid address.  (b) seems best since it's explicit.
> 
> Anoop
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of
[email-masked]
> > Sent: Sunday, October 07, 2007 8:38 PM
> > To: Eastlake III Donald-LDE008
> > Cc: [email-masked]
> > Subject: Re: [rbridge] Consensus Check: Announcing Root
> >
> > Good point. There might be no bridges. So there has to be a
> > way of encoding that. Anything such as:
> > a) leaving out the TLV in which one announces the root bridge
> > b) using a flag to say "no root"
> > c) using a special address, say 0
> > or I'm sure there are lots of possibilities.
> >
> > Radia
> >
> > ----- Original Message -----
> > From: Eastlake III Donald-LDE008 <[email-masked]>
> > Date: Saturday, October 6, 2007 12:46 pm
> > Subject: [rbridge] Consensus Check: Announcing Root
> >
> > > This is a check via the mailing list on a slight modification of
an
> > > apparent consensus from the minutes of the Chicago meeting for a
> > > changefrom protocol draft -05. The tentative consensus at
> > the Chicago
> > > meeting
> > > was:
> > >
> > >   It is mandatory for an RBridge to announce the bridge root that
> > >   it sees out each physical port.
> > >
> > > Based on mailing list discussion, I would like to tweak this as
> > > follows:
> > >   An Rbridge MUST parse BPDUs it receives on a port and announce
> > >   in the core IS-IS instance the bridge root that it sees out
> > >   each port. For MSTP (Multiple Spanning Tree Protocol), this is
> > >   the CIST (Common and Internal Spanning Tree) root.
> > >
> > > I have a question in connection with this. What is
> > announced for the
> > > port if no BPDU has been received recently or ever? Should
> > there be a
> > > "root MAC address valid" flag per port or should there some
> > > conventionalvalue, like zero, which is announced?
> > >
> > > Thanks,
> > > Donald
> > >
> > > _______________________________________________
> > > rbridge mailing list
> > > [email-masked]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> >
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Fri, 12 Oct 2007 15:20:38 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Announcing Root
Status: RO
Content-Length: 2705

I'm fine with option (b) but it seems implausible that all 0's could
ever be a normal MAC address. Among other things, the 00-00-00 OUI is
reserved for expressing arbitrary EtherTypes in the SNAP SAP format...

Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Monday, October 08, 2007 10:56 AM
To: [email-masked]; Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: [rbridge] Consensus Check: Announcing Root

I would prefer (a) or (b) since 0 is technically
a valid address.  (b) seems best since it's explicit.

Anoop 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Sunday, October 07, 2007 8:38 PM
> To: Eastlake III Donald-LDE008
> Cc: [email-masked]
> Subject: Re: [rbridge] Consensus Check: Announcing Root
> 
> Good point. There might be no bridges. So there has to be a 
> way of encoding that. Anything such as:
> a) leaving out the TLV in which one announces the root bridge
> b) using a flag to say "no root"
> c) using a special address, say 0
> or I'm sure there are lots of possibilities.
> 
> Radia
> 
> ----- Original Message -----
> From: Eastlake III Donald-LDE008 <[email-masked]>
> Date: Saturday, October 6, 2007 12:46 pm
> Subject: [rbridge] Consensus Check: Announcing Root
> 
> > This is a check via the mailing list on a slight modification of an 
> > apparent consensus from the minutes of the Chicago meeting for a 
> > changefrom protocol draft -05. The tentative consensus at 
> the Chicago 
> > meeting
> > was:
> > 
> >   It is mandatory for an RBridge to announce the bridge root that
> >   it sees out each physical port.
> > 
> > Based on mailing list discussion, I would like to tweak this as
> > follows:
> >   An Rbridge MUST parse BPDUs it receives on a port and announce
> >   in the core IS-IS instance the bridge root that it sees out
> >   each port. For MSTP (Multiple Spanning Tree Protocol), this is
> >   the CIST (Common and Internal Spanning Tree) root.
> > 
> > I have a question in connection with this. What is 
> announced for the 
> > port if no BPDU has been received recently or ever? Should 
> there be a 
> > "root MAC address valid" flag per port or should there some 
> > conventionalvalue, like zero, which is announced?
> > 
> > Thanks,
> > Donald
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Fri, 12 Oct 2007 14:46:16 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Check: Single Pseudo-node Announcment
Status: RO
Content-Length: 672

This is the last of the consensus checks via the mailing list to confirm
or refute an apparent consensus from the minutes of the Chicago meeting
for a change from protocol draft -05:

   Each RBridge which is DRB for one or more VLANs out one physical
   port should announce only one pseudo-node for the port.

If no particular controversy arises over this in the next two weeks, we
will declare it to be the working group consensus.

Please also post any other comments you have on the current -05 protocol
draft. If a revision can be posted in 3 or 4 weeks, we may be able to do
a working group last call before the December IETF TRILL meeting.

Thanks,
Donald & Erik

Content-class: urn:content-classes:message
Date: Mon, 8 Oct 2007 07:55:36 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Announcing Root
Status: RO
Content-Length: 2236

I would prefer (a) or (b) since 0 is technically
a valid address.  (b) seems best since it's explicit.

Anoop 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Sunday, October 07, 2007 8:38 PM
> To: Eastlake III Donald-LDE008
> Cc: [email-masked]
> Subject: Re: [rbridge] Consensus Check: Announcing Root
> 
> Good point. There might be no bridges. So there has to be a 
> way of encoding that. Anything such as:
> a) leaving out the TLV in which one announces the root bridge
> b) using a flag to say "no root"
> c) using a special address, say 0
> or I'm sure there are lots of possibilities.
> 
> Radia
> 
> ----- Original Message -----
> From: Eastlake III Donald-LDE008 <[email-masked]>
> Date: Saturday, October 6, 2007 12:46 pm
> Subject: [rbridge] Consensus Check: Announcing Root
> 
> > This is a check via the mailing list on a slight modification of an 
> > apparent consensus from the minutes of the Chicago meeting for a 
> > changefrom protocol draft -05. The tentative consensus at 
> the Chicago 
> > meeting
> > was:
> > 
> >   It is mandatory for an RBridge to announce the bridge root that
> >   it sees out each physical port.
> > 
> > Based on mailing list discussion, I would like to tweak this as
> > follows:
> >   An Rbridge MUST parse BPDUs it receives on a port and announce
> >   in the core IS-IS instance the bridge root that it sees out
> >   each port. For MSTP (Multiple Spanning Tree Protocol), this is
> >   the CIST (Common and Internal Spanning Tree) root.
> > 
> > I have a question in connection with this. What is 
> announced for the 
> > port if no BPDU has been received recently or ever? Should 
> there be a 
> > "root MAC address valid" flag per port or should there some 
> > conventionalvalue, like zero, which is announced?
> > 
> > Thanks,
> > Donald
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Date: Sun, 07 Oct 2007 20:38:14 -0700
From: [email-masked]
To: Eastlake III Donald-LDE008 <[email-masked]>
Priority: normal
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Announcing Root
Status: RO
Content-Length: 1575

Good point. There might be no bridges. So there has to be a way of encoding that. Anything such as:
a) leaving out the TLV in which one announces the root bridge
b) using a flag to say "no root"
c) using a special address, say 0
or I'm sure there are lots of possibilities.

Radia

----- Original Message -----
From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Saturday, October 6, 2007 12:46 pm
Subject: [rbridge] Consensus Check: Announcing Root

> This is a check via the mailing list on a slight modification of an
> apparent consensus from the minutes of the Chicago meeting for a 
> changefrom protocol draft -05. The tentative consensus at the 
> Chicago meeting
> was:
> 
>   It is mandatory for an RBridge to announce the bridge root that
>   it sees out each physical port.
> 
> Based on mailing list discussion, I would like to tweak this as 
> follows:
>   An Rbridge MUST parse BPDUs it receives on a port and announce
>   in the core IS-IS instance the bridge root that it sees out
>   each port. For MSTP (Multiple Spanning Tree Protocol), this is
>   the CIST (Common and Internal Spanning Tree) root.
> 
> I have a question in connection with this. What is announced for the
> port if no BPDU has been received recently or ever? Should there be a
> "root MAC address valid" flag per port or should there some 
> conventionalvalue, like zero, which is announced?
> 
> Thanks,
> Donald
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Sun, 7 Oct 2007 13:24:41 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1180

I don't see why the IEEE would be interested in this. It requires that
the outer MAC addresses (except for certain control frames/addresses) be
insignificant. This is true for point-to-point links between Rbridges
and between routers but not for point-to-point links between Bridges.
The IETF does routers and Rbridges. (I was there when one of the leaders
in 802.1 said in front of the 802.1 working group (not their exact
words) "Oh, RBridges swap the outer addresses on each hop. They are
obviously routers, not bridges.")

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Joe Touch
Sent: Friday, October 05, 2007 8:24 PM
To: Radia Perlman
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links

Radia Perlman wrote:
...
> So I'd prefer not having this feature at all, since I don't understand
> its purpose, 

I would really like the purpose to be explained before we explore
alternative solutions. And when I say purpose, I mean:

	- why the IETF rbridge WG should be addressing this issue now

vs., e.g., the IEEE, for some future link technology, now or in the
future.

Joe

Content-class: urn:content-classes:message
Date: Sat, 6 Oct 2007 15:46:16 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Check: Announcing Root
Status: RO
Content-Length: 912

This is a check via the mailing list on a slight modification of an
apparent consensus from the minutes of the Chicago meeting for a change
from protocol draft -05. The tentative consensus at the Chicago meeting
was:

   It is mandatory for an RBridge to announce the bridge root that
   it sees out each physical port.

Based on mailing list discussion, I would like to tweak this as follows:

   An Rbridge MUST parse BPDUs it receives on a port and announce
   in the core IS-IS instance the bridge root that it sees out
   each port. For MSTP (Multiple Spanning Tree Protocol), this is
   the CIST (Common and Internal Spanning Tree) root.

I have a question in connection with this. What is announced for the
port if no BPDU has been received recently or ever? Should there be a
"root MAC address valid" flag per port or should there some conventional
value, like zero, which is announced?

Thanks,
Donald

Date: Fri, 05 Oct 2007 20:44:24 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1326

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

Silvano Gai wrote:
=2E..
>> So what do I save again? Yes, on the rewriting and additional lookup.
>> But space?
>=20
> At 100 Gb/s you can send 150 millions frame/s, i.e. you have 6 ns/frame=
=2E

And solving that problem would be a fine issue for the IEEE 802.3 HSSG.
There would be a similar benefit for any pt-pt 100 gbps link, as an
optimization. However, this is at the level of optimizing a single link;
unless this is a pt-pt  device, there would be other links with similar
lookup requirements, so the benefit would be fractional anyway.

This remains, as a result, (a) in the margins of a (b) future problem.

Joe

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

--------------enig6395B1F83F4AF6369D24C8E1--

Content-class: urn:content-classes:message
Date: Fri, 5 Oct 2007 19:54:23 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 714

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Silvano Gai
> Sent: Friday, October 05, 2007 6:40 PM
> To: Joe Touch
> Cc: [email-masked]; Radia Perlman
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> At 100 Gb/s you can send 150 millions frame/s, i.e. you have 
> 6 ns/frame.
> Any operation you save it counts. Also the memory bandwidth 
> saved in retrieving the rewrite information may make the 
> difference from being able to use off chip memory (larger) or 
> being forced to stay on chip (smaller).

I don't understand why memory bandwidth would be an issue.  
We are talking a single address per port.

Anoop

Content-class: urn:content-classes:message
Date: Fri, 5 Oct 2007 18:39:30 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1576

Joe, 

inline

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Friday, October 05, 2007 6:01 PM
> To: Silvano Gai
> Cc: Eastlake III Donald-LDE008; Radia Perlman; [email-masked]
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[email-masked]]
> >> Sent: Friday, October 05, 2007 5:23 PM
> >> To: Silvano Gai
> >> Cc: Eastlake III Donald-LDE008; Radia Perlman; [email-masked]
> >> Subject: Re: [rbridge] Consensus Check: Point to Point links
> >>
> >>
> >>
> >> Silvano Gai wrote:
> >>> Joe,
> >>>
> >>> If there is a bridge in between two RBridges you need to have a
full
> >>> adjacency table.
> >>>
> >>> If the link is point to point, you can save the table.
> >> If the link is point to point, I still need to know what to send
over
> >> the link, so each side still needs adjacency information.
> >
> >
> > This is not correct; you need to do a lookup to find the port, that
is
> > it.
> > Otherwise you need to do a lookup to find the MAC address, rewrite
the
> > MAC address and then another lookup to find the port.
> 
> So what do I save again? Yes, on the rewriting and additional lookup.
> But space?
> 

At 100 Gb/s you can send 150 millions frame/s, i.e. you have 6 ns/frame.
Any operation you save it counts. Also the memory bandwidth saved in
retrieving the rewrite information may make the difference from being
able to use off chip memory (larger) or being forced to stay on chip
(smaller).

-- Silvano

Date: Fri, 05 Oct 2007 18:00:38 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1640

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

Silvano Gai wrote:
> Joe,
>=20
>> -----Original Message-----
>> From: Joe Touch [mailto:[email-masked]]
>> Sent: Friday, October 05, 2007 5:23 PM
>> To: Silvano Gai
>> Cc: Eastlake III Donald-LDE008; Radia Perlman; [email-masked]
>> Subject: Re: [rbridge] Consensus Check: Point to Point links
>>
>>
>>
>> Silvano Gai wrote:
>>> Joe,
>>>
>>> If there is a bridge in between two RBridges you need to have a full
>>> adjacency table.
>>>
>>> If the link is point to point, you can save the table.
>> If the link is point to point, I still need to know what to send over
>> the link, so each side still needs adjacency information.
>=20
>=20
> This is not correct; you need to do a lookup to find the port, that is
> it.
> Otherwise you need to do a lookup to find the MAC address, rewrite the
> MAC address and then another lookup to find the port.

So what do I save again? Yes, on the rewriting and additional lookup.
But space?

Joe

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

--------------enig20CCBFAF71ABF2EE759B67F9--

Content-class: urn:content-classes:message
Date: Fri, 5 Oct 2007 17:27:58 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 6333

Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Friday, October 05, 2007 5:23 PM
> To: Silvano Gai
> Cc: Eastlake III Donald-LDE008; Radia Perlman; [email-masked]
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> >
> > If there is a bridge in between two RBridges you need to have a full
> > adjacency table.
> >
> > If the link is point to point, you can save the table.
> 
> If the link is point to point, I still need to know what to send over
> the link, so each side still needs adjacency information.

This is not correct; you need to do a lookup to find the port, that is
it.
Otherwise you need to do a lookup to find the MAC address, rewrite the
MAC address and then another lookup to find the port.

-- Silvano

> 
> > When the standard will be done, 40 and 100 Gb/s links will start to
be
> > used.
> > On these links saving the adjacency table is a big deal.
> 
> And when those links are defined, such pt-pt links can be usefully
> defined within the IEEE.
> 
> > It is not only the silicon cost, but also the memory bandwidth.
> >
> > I don't see the additional complexity of a statement that says:
> > "on point-to-point link the MAC address xxxxxxxxx can be used as a
> > destination MAC".
> 
> I see absolutely no need for this group to make that recommendation.
> 
> Joe
> 
> >
> > -- Silvano
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[email-masked]]
> >> Sent: Friday, October 05, 2007 12:05 AM
> >> To: Silvano Gai
> >> Cc: Eastlake III Donald-LDE008; Radia Perlman; [email-masked]
> >> Subject: Re: [rbridge] Consensus Check: Point to Point links
> >>
> >> I do not understand the need to avoid a single entry per link. This
is
> >> hyperoptimization at the expense of complexity, and isn't useful.
> >>
> >> Joe
> >>
> >> Silvano Gai wrote:
> >>> I agree with Donald on all points.
> >>> The saving comes from not having to maintain an adjacency table on
> > high
> >>> speed point-to-point links.
> >>>
> >>> -- Silvano
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked]
> > [mailto:[email-masked]]
> >>> On
> >>>> Behalf Of Eastlake III Donald-LDE008
> >>>> Sent: Thursday, October 04, 2007 9:24 PM
> >>>> To: Radia Perlman
> >>>> Cc: [email-masked]
> >>>> Subject: Re: [rbridge] Consensus Check: Point to Point links
> >>>>
> >>>> Hi Radia,
> >>>>
> >>>> See below at @@@
> >>>>
> >>>> -----Original Message-----
> >>>> From: Radia Perlman [mailto:[email-masked]]
> >>>> Sent: Thursday, October 04, 2007 11:51 AM
> >>>> To: Eastlake III Donald-LDE008
> >>>> Cc: [email-masked]
> >>>> Subject: Re: [rbridge] Consensus Check: Point to Point links
> >>>>
> >>>> Personally, I need a reminder of what we are trying to accomplish
> > with
> >>>> this before I can have
> >>>> any opinion.
> >>>>
> >>>> a) Is omitting the outer VLAN tag to save space?
> >>>>
> >>>> @@@ Yes. The outer VLAN tag does nothing for you on a
> > point-to-point
> >>>> link.
> >>>>
> >>>> b) Why put in anything for destination address other than the MAC
> >>>> address of the next hop
> >>>> RBridge, or put in anything into the source address other than
your
> >>> own
> >>>> MAC address?
> >>>> It won't save space. So what does it gain?
> >>>>
> >>>> @@@ While no one has given a really crisp response to that
> > question,
> >>> it
> >>>> is my impression that some believe it will make it possible to
> > produce
> >>>> simpler, less expensive, or more efficient hardware for this
case.
> >>>>
> >>>> c) Is there any danger if an RBridge is confused about whether
this
> > is
> >>> a
> >>>> pt-to-pt link or not?
> >>>>
> >>>> @@@ I think there might be. And because of this and the extreme
> >>>> commonness of the point-to-point case, it may be reasonable to
> >>> consider
> >>>> this in designing TRILL. For example, if a fixed MAC address were
> > used
> >>>> (such as the unicast version of the All-Rbridges multicast
address
> >>> (just
> >>>> turn off the group bit)), then an interface receiving a frame
with
> >>> that
> >>>> source address would know there was a sender on the link who
> > believes
> >>>> the link was point-to-point. If the receiver knows it is not
> >>>> point-to-point or is unwilling to handle such frames, it could
take
> >>>> appropriate action. Also, Rbridge would know to never bother
> >>> "learning"
> >>>> the location of that MAC address.
> >>>>
> >>>> @@@ Thanks,
> >>>> @@@ Donald
> >>>>
> >>>> I can see the advantage of omitting the entire outer header if it
> > is
> >>>> somehow absolutely
> >>>> known this is a pt-to-pt link, and both ends of the link
understand
> >>>> this. But that isn't what's
> >>>> being proposed here. It seems to be only omitting the VLAN tag,
and
> >>>> allowing insertion of
> >>>> random addresses into the source and destination fields in the
> > outer
> >>>> header, if I'm reading
> >>>> it correctly.
> >>>>
> >>>> So anyway, clarification at this point would certainly help me.
> >>>>
> >>>>
> >>>> Eastlake III Donald-LDE008 wrote:
> >>>>> This is a check via the mailing list to confirm or refute an
> >>> apparent
> >>>>> consensus from the minutes of the Chicago meeting for a change
> > from
> >>>>> protocol draft -05:
> >>>>>
> >>>>>    If it is known that a link is a point to point link between
two
> >>>>>    RBridges, then the outer header, if it is an Ethernet header,
> > can
> >>>>>    have any source and/or destination addresses, those addresses
> >>> will
> >>>>>    be ignored on receipt, and the outer VLAN tag can be omitted.
> >>>>>
> >>>>> If no particular controversy arises over this in the next two
> > weeks,
> >>>> we
> >>>>> will declare it to be the working group consensus.
> >>>>>
> >>>>> Thanks,
> >>>>> Donald & Erik
> >>>>>
> >>>>> _______________________________________________
> >>>>> rbridge mailing list
> >>>>> [email-masked]
> >>>>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>>>
> >>>> _______________________________________________
> >>>> rbridge mailing list
> >>>> [email-masked]
> >>>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>> _______________________________________________
> >>> rbridge mailing list
> >>> [email-masked]
> >>> http://mailman.postel.org/mailman/listinfo/rbridge
> >

Date: Fri, 05 Oct 2007 17:22:43 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 6218

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

Silvano Gai wrote:
> Joe,
>=20
> If there is a bridge in between two RBridges you need to have a full
> adjacency table.
>=20
> If the link is point to point, you can save the table.

If the link is point to point, I still need to know what to send over
the link, so each side still needs adjacency information.

> When the standard will be done, 40 and 100 Gb/s links will start to be
> used.
> On these links saving the adjacency table is a big deal.

And when those links are defined, such pt-pt links can be usefully
defined within the IEEE.

> It is not only the silicon cost, but also the memory bandwidth.
>=20
> I don't see the additional complexity of a statement that says:
> "on point-to-point link the MAC address xxxxxxxxx can be used as a
> destination MAC".

I see absolutely no need for this group to make that recommendation.

Joe

>=20
> -- Silvano
>=20
>> -----Original Message-----
>> From: Joe Touch [mailto:[email-masked]]
>> Sent: Friday, October 05, 2007 12:05 AM
>> To: Silvano Gai
>> Cc: Eastlake III Donald-LDE008; Radia Perlman; [email-masked]
>> Subject: Re: [rbridge] Consensus Check: Point to Point links
>>
>> I do not understand the need to avoid a single entry per link. This is=

>> hyperoptimization at the expense of complexity, and isn't useful.
>>
>> Joe
>>
>> Silvano Gai wrote:
>>> I agree with Donald on all points.
>>> The saving comes from not having to maintain an adjacency table on
> high
>>> speed point-to-point links.
>>>
>>> -- Silvano
>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
> [mailto:[email-masked]]
>>> On
>>>> Behalf Of Eastlake III Donald-LDE008
>>>> Sent: Thursday, October 04, 2007 9:24 PM
>>>> To: Radia Perlman
>>>> Cc: [email-masked]
>>>> Subject: Re: [rbridge] Consensus Check: Point to Point links
>>>>
>>>> Hi Radia,
>>>>
>>>> See below at @@@
>>>>
>>>> -----Original Message-----
>>>> From: Radia Perlman [mailto:[email-masked]]
>>>> Sent: Thursday, October 04, 2007 11:51 AM
>>>> To: Eastlake III Donald-LDE008
>>>> Cc: [email-masked]
>>>> Subject: Re: [rbridge] Consensus Check: Point to Point links
>>>>
>>>> Personally, I need a reminder of what we are trying to accomplish
> with
>>>> this before I can have
>>>> any opinion.
>>>>
>>>> a) Is omitting the outer VLAN tag to save space?
>>>>
>>>> @@@ Yes. The outer VLAN tag does nothing for you on a
> point-to-point
>>>> link.
>>>>
>>>> b) Why put in anything for destination address other than the MAC
>>>> address of the next hop
>>>> RBridge, or put in anything into the source address other than your
>>> own
>>>> MAC address?
>>>> It won't save space. So what does it gain?
>>>>
>>>> @@@ While no one has given a really crisp response to that
> question,
>>> it
>>>> is my impression that some believe it will make it possible to
> produce
>>>> simpler, less expensive, or more efficient hardware for this case.
>>>>
>>>> c) Is there any danger if an RBridge is confused about whether this
> is
>>> a
>>>> pt-to-pt link or not?
>>>>
>>>> @@@ I think there might be. And because of this and the extreme
>>>> commonness of the point-to-point case, it may be reasonable to
>>> consider
>>>> this in designing TRILL. For example, if a fixed MAC address were
> used
>>>> (such as the unicast version of the All-Rbridges multicast address
>>> (just
>>>> turn off the group bit)), then an interface receiving a frame with
>>> that
>>>> source address would know there was a sender on the link who
> believes
>>>> the link was point-to-point. If the receiver knows it is not
>>>> point-to-point or is unwilling to handle such frames, it could take
>>>> appropriate action. Also, Rbridge would know to never bother
>>> "learning"
>>>> the location of that MAC address.
>>>>
>>>> @@@ Thanks,
>>>> @@@ Donald
>>>>
>>>> I can see the advantage of omitting the entire outer header if it
> is
>>>> somehow absolutely
>>>> known this is a pt-to-pt link, and both ends of the link understand
>>>> this. But that isn't what's
>>>> being proposed here. It seems to be only omitting the VLAN tag, and
>>>> allowing insertion of
>>>> random addresses into the source and destination fields in the
> outer
>>>> header, if I'm reading
>>>> it correctly.
>>>>
>>>> So anyway, clarification at this point would certainly help me.
>>>>
>>>>
>>>> Eastlake III Donald-LDE008 wrote:
>>>>> This is a check via the mailing list to confirm or refute an
>>> apparent
>>>>> consensus from the minutes of the Chicago meeting for a change
> from
>>>>> protocol draft -05:
>>>>>
>>>>>    If it is known that a link is a point to point link between two
>>>>>    RBridges, then the outer header, if it is an Ethernet header,
> can
>>>>>    have any source and/or destination addresses, those addresses
>>> will
>>>>>    be ignored on receipt, and the outer VLAN tag can be omitted.
>>>>>
>>>>> If no particular controversy arises over this in the next two
> weeks,
>>>> we
>>>>> will declare it to be the working group consensus.
>>>>>
>>>>> Thanks,
>>>>> Donald & Erik
>>>>>
>>>>> _______________________________________________
>>>>> rbridge mailing list
>>>>> [email-masked]
>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> [email-masked]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>> _______________________________________________
>>> rbridge mailing list
>>> [email-masked]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>=20

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

--------------enig83F16098522DF34C30EAFBB7--

Date: Fri, 05 Oct 2007 17:24:08 -0700
From: Joe Touch <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1091

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

Radia Perlman wrote:
=2E..
> So I'd prefer not having this feature at all, since I don't understand
> its purpose,=20

I would really like the purpose to be explained before we explore
alternative solutions. And when I say purpose, I mean:

	- why the IETF rbridge WG should be addressing this issue now

vs., e.g., the IEEE, for some future link technology, now or in the futur=
e.

Joe

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

--------------enig055E4A4EDC94B3320BB19FE7--

Content-class: urn:content-classes:message
Date: Fri, 5 Oct 2007 15:58:50 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 5120

Joe,

If there is a bridge in between two RBridges you need to have a full
adjacency table.

If the link is point to point, you can save the table.

When the standard will be done, 40 and 100 Gb/s links will start to be
used.
On these links saving the adjacency table is a big deal.
It is not only the silicon cost, but also the memory bandwidth.

I don't see the additional complexity of a statement that says:
"on point-to-point link the MAC address xxxxxxxxx can be used as a
destination MAC".

-- Silvano

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Friday, October 05, 2007 12:05 AM
> To: Silvano Gai
> Cc: Eastlake III Donald-LDE008; Radia Perlman; [email-masked]
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> I do not understand the need to avoid a single entry per link. This is
> hyperoptimization at the expense of complexity, and isn't useful.
> 
> Joe
> 
> Silvano Gai wrote:
> > I agree with Donald on all points.
> > The saving comes from not having to maintain an adjacency table on
high
> > speed point-to-point links.
> >
> > -- Silvano
> >
> >> -----Original Message-----
> >> From: [email-masked]
[mailto:[email-masked]]
> > On
> >> Behalf Of Eastlake III Donald-LDE008
> >> Sent: Thursday, October 04, 2007 9:24 PM
> >> To: Radia Perlman
> >> Cc: [email-masked]
> >> Subject: Re: [rbridge] Consensus Check: Point to Point links
> >>
> >> Hi Radia,
> >>
> >> See below at @@@
> >>
> >> -----Original Message-----
> >> From: Radia Perlman [mailto:[email-masked]]
> >> Sent: Thursday, October 04, 2007 11:51 AM
> >> To: Eastlake III Donald-LDE008
> >> Cc: [email-masked]
> >> Subject: Re: [rbridge] Consensus Check: Point to Point links
> >>
> >> Personally, I need a reminder of what we are trying to accomplish
with
> >> this before I can have
> >> any opinion.
> >>
> >> a) Is omitting the outer VLAN tag to save space?
> >>
> >> @@@ Yes. The outer VLAN tag does nothing for you on a
point-to-point
> >> link.
> >>
> >> b) Why put in anything for destination address other than the MAC
> >> address of the next hop
> >> RBridge, or put in anything into the source address other than your
> > own
> >> MAC address?
> >> It won't save space. So what does it gain?
> >>
> >> @@@ While no one has given a really crisp response to that
question,
> > it
> >> is my impression that some believe it will make it possible to
produce
> >> simpler, less expensive, or more efficient hardware for this case.
> >>
> >> c) Is there any danger if an RBridge is confused about whether this
is
> > a
> >> pt-to-pt link or not?
> >>
> >> @@@ I think there might be. And because of this and the extreme
> >> commonness of the point-to-point case, it may be reasonable to
> > consider
> >> this in designing TRILL. For example, if a fixed MAC address were
used
> >> (such as the unicast version of the All-Rbridges multicast address
> > (just
> >> turn off the group bit)), then an interface receiving a frame with
> > that
> >> source address would know there was a sender on the link who
believes
> >> the link was point-to-point. If the receiver knows it is not
> >> point-to-point or is unwilling to handle such frames, it could take
> >> appropriate action. Also, Rbridge would know to never bother
> > "learning"
> >> the location of that MAC address.
> >>
> >> @@@ Thanks,
> >> @@@ Donald
> >>
> >> I can see the advantage of omitting the entire outer header if it
is
> >> somehow absolutely
> >> known this is a pt-to-pt link, and both ends of the link understand
> >> this. But that isn't what's
> >> being proposed here. It seems to be only omitting the VLAN tag, and
> >> allowing insertion of
> >> random addresses into the source and destination fields in the
outer
> >> header, if I'm reading
> >> it correctly.
> >>
> >> So anyway, clarification at this point would certainly help me.
> >>
> >>
> >> Eastlake III Donald-LDE008 wrote:
> >>> This is a check via the mailing list to confirm or refute an
> > apparent
> >>> consensus from the minutes of the Chicago meeting for a change
from
> >>> protocol draft -05:
> >>>
> >>>    If it is known that a link is a point to point link between two
> >>>    RBridges, then the outer header, if it is an Ethernet header,
can
> >>>    have any source and/or destination addresses, those addresses
> > will
> >>>    be ignored on receipt, and the outer VLAN tag can be omitted.
> >>>
> >>> If no particular controversy arises over this in the next two
weeks,
> >> we
> >>> will declare it to be the working group consensus.
> >>>
> >>> Thanks,
> >>> Donald & Erik
> >>>
> >>> _______________________________________________
> >>> rbridge mailing list
> >>> [email-masked]
> >>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>
> >>
> >> _______________________________________________
> >> rbridge mailing list
> >> [email-masked]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Fri, 5 Oct 2007 17:39:24 -0400
From: "Caitlin Bestler" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 795

Radia Perlman wrote:
-----Original Message-----

I also don't understand why this is important, but to the extent with 
which I do understand the implementation concern, how about instead of
saying you can put whatever you want in source and destination, we
instead define two constant MAC addresses, one that can always be used
by an RBridge in the source field, say, RBridge-from-MAC, and another
that can always be used in the destination field, say RBridge-to-MAC.

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

What I like about this proposal is that any RBridge that does not
care to implement this feature will just see traffic that is not
addressed to it. I think the only impact beyond the RBridges that
are actually implementing the feature is the need to reserve the
special MAC addresses.

Date: Fri, 05 Oct 2007 14:04:10 -0700
From: Radia Perlman <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 7388

I also don't understand why this is important, but to the extent with 
which I do understand the
implementation concern, how about instead of saying you can put whatever 
you want in
source and destination, we instead define two constant MAC addresses, 
one that can
always be used by an RBridge in the source field, say, RBridge-from-MAC,
and another that can always be
used in the destination field, say RBridge-to-MAC.
So if you think it's a pt-to-pt link, and you don't want to keep
track of the MAC address of your neighbor, you can fill out the outer 
header with those
two MAC addresses. If you are confused and there are bridges on the 
link, nobody will
get confused. If "RBridge-from-MAC" is used by multiple RBridges on the 
same layer 2 cloud,
bridges will have confused caches about the location of that address, 
but that won't matter if
it's never used in the destination field.

There is the problem that if there are multiple RBridges on the link 
(and the RBridges haven't
yet figured that out), then packets will get duplicated because both 
RBridges will pick up the
packet. (the same would be true if you think you're on a pt-to-pt link 
with the "allow random
addresses in there proposal). This (constant addresses) is safer because 
you wouldn't have the
problem of a confused RBridge on a link with hundreds of other RBridges 
picking up every
packet that RBridges are trying to forward to each other.

So I'd prefer not having this feature at all, since I don't understand 
its purpose, but if we are
going to do it, because (to the extent to which I understand it) an 
RBridge might not have
a MAC address on a pt-to-pt link to use as the source, and/or the 
RBridge doesn't want
to keep track of the next hop RBridge address to fill out the 
destination address, then having
a constant from and to address would seem a better and less mysterious 
solution than saying
the addresses can be any random value.

Radia

Anoop Ghanwani wrote:
> I agree with Joe on this point.
>
> Anoop 
>
>   
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Joe Touch
>> Sent: Friday, October 05, 2007 12:05 AM
>> To: Silvano Gai
>> Cc: [email-masked]; Radia Perlman
>> Subject: Re: [rbridge] Consensus Check: Point to Point links
>>
>> I do not understand the need to avoid a single entry per 
>> link. This is hyperoptimization at the expense of complexity, 
>> and isn't useful.
>>
>> Joe
>>
>> Silvano Gai wrote:
>>     
>>> I agree with Donald on all points.
>>> The saving comes from not having to maintain an adjacency table on 
>>> high speed point-to-point links.
>>>
>>> -- Silvano
>>>
>>>       
>>>> -----Original Message-----
>>>> From: [email-masked] 
>>>>         
>> [mailto:[email-masked]]
>>     
>>> On
>>>       
>>>> Behalf Of Eastlake III Donald-LDE008
>>>> Sent: Thursday, October 04, 2007 9:24 PM
>>>> To: Radia Perlman
>>>> Cc: [email-masked]
>>>> Subject: Re: [rbridge] Consensus Check: Point to Point links
>>>>
>>>> Hi Radia,
>>>>
>>>> See below at @@@
>>>>
>>>> -----Original Message-----
>>>> From: Radia Perlman [mailto:[email-masked]]
>>>> Sent: Thursday, October 04, 2007 11:51 AM
>>>> To: Eastlake III Donald-LDE008
>>>> Cc: [email-masked]
>>>> Subject: Re: [rbridge] Consensus Check: Point to Point links
>>>>
>>>> Personally, I need a reminder of what we are trying to accomplish 
>>>> with this before I can have any opinion.
>>>>
>>>> a) Is omitting the outer VLAN tag to save space?
>>>>
>>>> @@@ Yes. The outer VLAN tag does nothing for you on a 
>>>>         
>> point-to-point 
>>     
>>>> link.
>>>>
>>>> b) Why put in anything for destination address other than the MAC 
>>>> address of the next hop RBridge, or put in anything into 
>>>>         
>> the source 
>>     
>>>> address other than your
>>>>         
>>> own
>>>       
>>>> MAC address?
>>>> It won't save space. So what does it gain?
>>>>
>>>> @@@ While no one has given a really crisp response to that 
>>>>         
>> question,
>>     
>>> it
>>>       
>>>> is my impression that some believe it will make it possible to 
>>>> produce simpler, less expensive, or more efficient 
>>>>         
>> hardware for this case.
>>     
>>>> c) Is there any danger if an RBridge is confused about 
>>>>         
>> whether this 
>>     
>>>> is
>>>>         
>>> a
>>>       
>>>> pt-to-pt link or not?
>>>>
>>>> @@@ I think there might be. And because of this and the extreme 
>>>> commonness of the point-to-point case, it may be reasonable to
>>>>         
>>> consider
>>>       
>>>> this in designing TRILL. For example, if a fixed MAC address were 
>>>> used (such as the unicast version of the All-Rbridges multicast 
>>>> address
>>>>         
>>> (just
>>>       
>>>> turn off the group bit)), then an interface receiving a frame with
>>>>         
>>> that
>>>       
>>>> source address would know there was a sender on the link 
>>>>         
>> who believes 
>>     
>>>> the link was point-to-point. If the receiver knows it is not 
>>>> point-to-point or is unwilling to handle such frames, it 
>>>>         
>> could take 
>>     
>>>> appropriate action. Also, Rbridge would know to never bother
>>>>         
>>> "learning"
>>>       
>>>> the location of that MAC address.
>>>>
>>>> @@@ Thanks,
>>>> @@@ Donald
>>>>
>>>> I can see the advantage of omitting the entire outer 
>>>>         
>> header if it is 
>>     
>>>> somehow absolutely known this is a pt-to-pt link, and both ends of 
>>>> the link understand this. But that isn't what's being 
>>>>         
>> proposed here. 
>>     
>>>> It seems to be only omitting the VLAN tag, and allowing 
>>>>         
>> insertion of 
>>     
>>>> random addresses into the source and destination fields in 
>>>>         
>> the outer 
>>     
>>>> header, if I'm reading it correctly.
>>>>
>>>> So anyway, clarification at this point would certainly help me.
>>>>
>>>>
>>>> Eastlake III Donald-LDE008 wrote:
>>>>         
>>>>> This is a check via the mailing list to confirm or refute an
>>>>>           
>>> apparent
>>>       
>>>>> consensus from the minutes of the Chicago meeting for a 
>>>>>           
>> change from 
>>     
>>>>> protocol draft -05:
>>>>>
>>>>>    If it is known that a link is a point to point link between two
>>>>>    RBridges, then the outer header, if it is an Ethernet 
>>>>>           
>> header, can
>>     
>>>>>    have any source and/or destination addresses, those addresses
>>>>>           
>>> will
>>>       
>>>>>    be ignored on receipt, and the outer VLAN tag can be omitted.
>>>>>
>>>>> If no particular controversy arises over this in the next 
>>>>>           
>> two weeks,
>>     
>>>> we
>>>>         
>>>>> will declare it to be the working group consensus.
>>>>>
>>>>> Thanks,
>>>>> Donald & Erik
>>>>>
>>>>> _______________________________________________
>>>>> rbridge mailing list
>>>>> [email-masked]
>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>
>>>>>           
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> [email-masked]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>         
>>> _______________________________________________
>>> rbridge mailing list
>>> [email-masked]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>       
>>     

Content-class: urn:content-classes:message
Date: Fri, 5 Oct 2007 09:52:55 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Joe Touch" <[email-masked]>, "Silvano Gai" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 4745

I agree with Joe on this point.

Anoop 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Friday, October 05, 2007 12:05 AM
> To: Silvano Gai
> Cc: [email-masked]; Radia Perlman
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> I do not understand the need to avoid a single entry per 
> link. This is hyperoptimization at the expense of complexity, 
> and isn't useful.
> 
> Joe
> 
> Silvano Gai wrote:
> > I agree with Donald on all points.
> > The saving comes from not having to maintain an adjacency table on 
> > high speed point-to-point links.
> > 
> > -- Silvano
> > 
> >> -----Original Message-----
> >> From: [email-masked] 
> [mailto:[email-masked]]
> > On
> >> Behalf Of Eastlake III Donald-LDE008
> >> Sent: Thursday, October 04, 2007 9:24 PM
> >> To: Radia Perlman
> >> Cc: [email-masked]
> >> Subject: Re: [rbridge] Consensus Check: Point to Point links
> >>
> >> Hi Radia,
> >>
> >> See below at @@@
> >>
> >> -----Original Message-----
> >> From: Radia Perlman [mailto:[email-masked]]
> >> Sent: Thursday, October 04, 2007 11:51 AM
> >> To: Eastlake III Donald-LDE008
> >> Cc: [email-masked]
> >> Subject: Re: [rbridge] Consensus Check: Point to Point links
> >>
> >> Personally, I need a reminder of what we are trying to accomplish 
> >> with this before I can have any opinion.
> >>
> >> a) Is omitting the outer VLAN tag to save space?
> >>
> >> @@@ Yes. The outer VLAN tag does nothing for you on a 
> point-to-point 
> >> link.
> >>
> >> b) Why put in anything for destination address other than the MAC 
> >> address of the next hop RBridge, or put in anything into 
> the source 
> >> address other than your
> > own
> >> MAC address?
> >> It won't save space. So what does it gain?
> >>
> >> @@@ While no one has given a really crisp response to that 
> question,
> > it
> >> is my impression that some believe it will make it possible to 
> >> produce simpler, less expensive, or more efficient 
> hardware for this case.
> >>
> >> c) Is there any danger if an RBridge is confused about 
> whether this 
> >> is
> > a
> >> pt-to-pt link or not?
> >>
> >> @@@ I think there might be. And because of this and the extreme 
> >> commonness of the point-to-point case, it may be reasonable to
> > consider
> >> this in designing TRILL. For example, if a fixed MAC address were 
> >> used (such as the unicast version of the All-Rbridges multicast 
> >> address
> > (just
> >> turn off the group bit)), then an interface receiving a frame with
> > that
> >> source address would know there was a sender on the link 
> who believes 
> >> the link was point-to-point. If the receiver knows it is not 
> >> point-to-point or is unwilling to handle such frames, it 
> could take 
> >> appropriate action. Also, Rbridge would know to never bother
> > "learning"
> >> the location of that MAC address.
> >>
> >> @@@ Thanks,
> >> @@@ Donald
> >>
> >> I can see the advantage of omitting the entire outer 
> header if it is 
> >> somehow absolutely known this is a pt-to-pt link, and both ends of 
> >> the link understand this. But that isn't what's being 
> proposed here. 
> >> It seems to be only omitting the VLAN tag, and allowing 
> insertion of 
> >> random addresses into the source and destination fields in 
> the outer 
> >> header, if I'm reading it correctly.
> >>
> >> So anyway, clarification at this point would certainly help me.
> >>
> >>
> >> Eastlake III Donald-LDE008 wrote:
> >>> This is a check via the mailing list to confirm or refute an
> > apparent
> >>> consensus from the minutes of the Chicago meeting for a 
> change from 
> >>> protocol draft -05:
> >>>
> >>>    If it is known that a link is a point to point link between two
> >>>    RBridges, then the outer header, if it is an Ethernet 
> header, can
> >>>    have any source and/or destination addresses, those addresses
> > will
> >>>    be ignored on receipt, and the outer VLAN tag can be omitted.
> >>>
> >>> If no particular controversy arises over this in the next 
> two weeks,
> >> we
> >>> will declare it to be the working group consensus.
> >>>
> >>> Thanks,
> >>> Donald & Erik
> >>>
> >>> _______________________________________________
> >>> rbridge mailing list
> >>> [email-masked]
> >>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>
> >>
> >> _______________________________________________
> >> rbridge mailing list
> >> [email-masked]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> 

Content-class: urn:content-classes:message
Date: Fri, 5 Oct 2007 08:28:27 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 3639

I don't see any inconsistency between your statement and my statement.

Donald 

-----Original Message-----
From: Dinesh G Dutt [mailto:[email-masked]] 
Sent: Friday, October 05, 2007 2:06 AM
To: Eastlake III Donald-LDE008
Cc: Anoop Ghanwani; [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links

Hi Donald,

BPDUs in the L2 world (such as STP, LLDP etc.) are typically identified 
by MAC addresses, not ethertype. Some newer protocols such as CFM & OAM 
are identified by ethertype and there is supposedly a move to identify 
newer BPDUs using ethertype.

The frames we're talking of sending with a fixed (or reserved) address 
are the data frames. BPDUs including IS-IS will use the regular MAC 
address.

Dinesh
Eastlake III Donald-LDE008 wrote:
> Actually, although I'm not entirely sure, I believe that BPDUs, LLDP
> PDUs, etc., all start with an Ethertype which identifies them so, in
> principle, they could be made to work on a specially equipped point to
> point link with no outer MAC addresses. However, I don't think anyone
> has proposed that TRILL should consider omitting the outer MAC
addresses
> except when that suggestion appears as part of a question asking why,
if
> you want to do some optimization on a point-to-point link, you don't
> want to do even more optimization.
>
> Donald
>
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[email-masked]] 
> Sent: Thursday, October 04, 2007 1:46 PM
> To: Radia Perlman; Eastlake III Donald-LDE008
> Cc: [email-masked]
> Subject: RE: [rbridge] Consensus Check: Point to Point links
>
>  
>
>   
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Radia Perlman
>> Sent: Thursday, October 04, 2007 8:51 AM
>> To: Eastlake III Donald-LDE008
>> Cc: [email-masked]
>> Subject: Re: [rbridge] Consensus Check: Point to Point links
>>
>> Personally, I need a reminder of what we are trying to 
>> accomplish with this before I can have any opinion.
>>
>> a) Is omitting the outer VLAN tag to save space?
>> b) Why put in anything for destination address other than the 
>> MAC address of the next hop RBridge, or put in anything into 
>> the source address other than your own MAC address?
>> It won't save space. So what does it gain?
>> c) Is there any danger if an RBridge is confused about 
>> whether this is a pt-to-pt link or not?
>>
>> I can see the advantage of omitting the entire outer header 
>> if it is somehow absolutely known this is a pt-to-pt link, 
>> and both ends of the link understand this. 
>>     
>
> That wouldn't work because there are other frames that will
> have to have MAC addresses, e.g. LACP, LLDP.
>
>   
>> But that isn't 
>> what's being proposed here. It seems to be only omitting the 
>> VLAN tag, and allowing insertion of random addresses into the 
>> source and destination fields in the outer header, if I'm 
>> reading it correctly.
>>     
>
> I don't like the idea of random addresses (is it that
> a big a deal to set them correctly?), but as long as
> it's completely optional, I don't really care. 
> [By the way, even though the proposal says that it
> can be random, it really can't because we have to
> say that they cannot be from the BPDU address space
> or things like LACP and LLDP will break.]
>
> Anoop
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> 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

Date: Fri, 05 Oct 2007 00:04:32 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 4819

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

I do not understand the need to avoid a single entry per link. This is
hyperoptimization at the expense of complexity, and isn't useful.

Joe

Silvano Gai wrote:
> I agree with Donald on all points.
> The saving comes from not having to maintain an adjacency table on high=

> speed point-to-point links.
>=20
> -- Silvano
>=20
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
> On
>> Behalf Of Eastlake III Donald-LDE008
>> Sent: Thursday, October 04, 2007 9:24 PM
>> To: Radia Perlman
>> Cc: [email-masked]
>> Subject: Re: [rbridge] Consensus Check: Point to Point links
>>
>> Hi Radia,
>>
>> See below at @@@
>>
>> -----Original Message-----
>> From: Radia Perlman [mailto:[email-masked]]
>> Sent: Thursday, October 04, 2007 11:51 AM
>> To: Eastlake III Donald-LDE008
>> Cc: [email-masked]
>> Subject: Re: [rbridge] Consensus Check: Point to Point links
>>
>> Personally, I need a reminder of what we are trying to accomplish with=

>> this before I can have
>> any opinion.
>>
>> a) Is omitting the outer VLAN tag to save space?
>>
>> @@@ Yes. The outer VLAN tag does nothing for you on a point-to-point
>> link.
>>
>> b) Why put in anything for destination address other than the MAC
>> address of the next hop
>> RBridge, or put in anything into the source address other than your
> own
>> MAC address?
>> It won't save space. So what does it gain?
>>
>> @@@ While no one has given a really crisp response to that question,
> it
>> is my impression that some believe it will make it possible to produce=

>> simpler, less expensive, or more efficient hardware for this case.
>>
>> c) Is there any danger if an RBridge is confused about whether this is=

> a
>> pt-to-pt link or not?
>>
>> @@@ I think there might be. And because of this and the extreme
>> commonness of the point-to-point case, it may be reasonable to
> consider
>> this in designing TRILL. For example, if a fixed MAC address were used=

>> (such as the unicast version of the All-Rbridges multicast address
> (just
>> turn off the group bit)), then an interface receiving a frame with
> that
>> source address would know there was a sender on the link who believes
>> the link was point-to-point. If the receiver knows it is not
>> point-to-point or is unwilling to handle such frames, it could take
>> appropriate action. Also, Rbridge would know to never bother
> "learning"
>> the location of that MAC address.
>>
>> @@@ Thanks,
>> @@@ Donald
>>
>> I can see the advantage of omitting the entire outer header if it is
>> somehow absolutely
>> known this is a pt-to-pt link, and both ends of the link understand
>> this. But that isn't what's
>> being proposed here. It seems to be only omitting the VLAN tag, and
>> allowing insertion of
>> random addresses into the source and destination fields in the outer
>> header, if I'm reading
>> it correctly.
>>
>> So anyway, clarification at this point would certainly help me.
>>
>>
>> Eastlake III Donald-LDE008 wrote:
>>> This is a check via the mailing list to confirm or refute an
> apparent
>>> consensus from the minutes of the Chicago meeting for a change from
>>> protocol draft -05:
>>>
>>>    If it is known that a link is a point to point link between two
>>>    RBridges, then the outer header, if it is an Ethernet header, can
>>>    have any source and/or destination addresses, those addresses
> will
>>>    be ignored on receipt, and the outer VLAN tag can be omitted.
>>>
>>> If no particular controversy arises over this in the next two weeks,
>> we
>>> will declare it to be the working group consensus.
>>>
>>> Thanks,
>>> Donald & Erik
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> [email-masked]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>=20
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

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

--------------enig96CF07652A6976A30F1E6CC0--

Date: Thu, 04 Oct 2007 23:05:39 -0700
From: Dinesh G Dutt <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 3313

Hi Donald,

BPDUs in the L2 world (such as STP, LLDP etc.) are typically identified 
by MAC addresses, not ethertype. Some newer protocols such as CFM & OAM 
are identified by ethertype and there is supposedly a move to identify 
newer BPDUs using ethertype.

The frames we're talking of sending with a fixed (or reserved) address 
are the data frames. BPDUs including IS-IS will use the regular MAC 
address.

Dinesh
Eastlake III Donald-LDE008 wrote:
> Actually, although I'm not entirely sure, I believe that BPDUs, LLDP
> PDUs, etc., all start with an Ethertype which identifies them so, in
> principle, they could be made to work on a specially equipped point to
> point link with no outer MAC addresses. However, I don't think anyone
> has proposed that TRILL should consider omitting the outer MAC addresses
> except when that suggestion appears as part of a question asking why, if
> you want to do some optimization on a point-to-point link, you don't
> want to do even more optimization.
>
> Donald
>
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[email-masked]] 
> Sent: Thursday, October 04, 2007 1:46 PM
> To: Radia Perlman; Eastlake III Donald-LDE008
> Cc: [email-masked]
> Subject: RE: [rbridge] Consensus Check: Point to Point links
>
>  
>
>   
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Radia Perlman
>> Sent: Thursday, October 04, 2007 8:51 AM
>> To: Eastlake III Donald-LDE008
>> Cc: [email-masked]
>> Subject: Re: [rbridge] Consensus Check: Point to Point links
>>
>> Personally, I need a reminder of what we are trying to 
>> accomplish with this before I can have any opinion.
>>
>> a) Is omitting the outer VLAN tag to save space?
>> b) Why put in anything for destination address other than the 
>> MAC address of the next hop RBridge, or put in anything into 
>> the source address other than your own MAC address?
>> It won't save space. So what does it gain?
>> c) Is there any danger if an RBridge is confused about 
>> whether this is a pt-to-pt link or not?
>>
>> I can see the advantage of omitting the entire outer header 
>> if it is somehow absolutely known this is a pt-to-pt link, 
>> and both ends of the link understand this. 
>>     
>
> That wouldn't work because there are other frames that will
> have to have MAC addresses, e.g. LACP, LLDP.
>
>   
>> But that isn't 
>> what's being proposed here. It seems to be only omitting the 
>> VLAN tag, and allowing insertion of random addresses into the 
>> source and destination fields in the outer header, if I'm 
>> reading it correctly.
>>     
>
> I don't like the idea of random addresses (is it that
> a big a deal to set them correctly?), but as long as
> it's completely optional, I don't really care. 
> [By the way, even though the proposal says that it
> can be random, it really can't because we have to
> say that they cannot be from the BPDU address space
> or things like LACP and LLDP will break.]
>
> Anoop
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> 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

Content-class: urn:content-classes:message
Date: Thu, 4 Oct 2007 21:53:48 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 3707

I agree with Donald on all points.
The saving comes from not having to maintain an adjacency table on high
speed point-to-point links.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Thursday, October 04, 2007 9:24 PM
> To: Radia Perlman
> Cc: [email-masked]
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> Hi Radia,
> 
> See below at @@@
> 
> -----Original Message-----
> From: Radia Perlman [mailto:[email-masked]]
> Sent: Thursday, October 04, 2007 11:51 AM
> To: Eastlake III Donald-LDE008
> Cc: [email-masked]
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> Personally, I need a reminder of what we are trying to accomplish with
> this before I can have
> any opinion.
> 
> a) Is omitting the outer VLAN tag to save space?
> 
> @@@ Yes. The outer VLAN tag does nothing for you on a point-to-point
> link.
> 
> b) Why put in anything for destination address other than the MAC
> address of the next hop
> RBridge, or put in anything into the source address other than your
own
> MAC address?
> It won't save space. So what does it gain?
> 
> @@@ While no one has given a really crisp response to that question,
it
> is my impression that some believe it will make it possible to produce
> simpler, less expensive, or more efficient hardware for this case.
> 
> c) Is there any danger if an RBridge is confused about whether this is
a
> 
> pt-to-pt link or not?
> 
> @@@ I think there might be. And because of this and the extreme
> commonness of the point-to-point case, it may be reasonable to
consider
> this in designing TRILL. For example, if a fixed MAC address were used
> (such as the unicast version of the All-Rbridges multicast address
(just
> turn off the group bit)), then an interface receiving a frame with
that
> source address would know there was a sender on the link who believes
> the link was point-to-point. If the receiver knows it is not
> point-to-point or is unwilling to handle such frames, it could take
> appropriate action. Also, Rbridge would know to never bother
"learning"
> the location of that MAC address.
> 
> @@@ Thanks,
> @@@ Donald
> 
> I can see the advantage of omitting the entire outer header if it is
> somehow absolutely
> known this is a pt-to-pt link, and both ends of the link understand
> this. But that isn't what's
> being proposed here. It seems to be only omitting the VLAN tag, and
> allowing insertion of
> random addresses into the source and destination fields in the outer
> header, if I'm reading
> it correctly.
> 
> So anyway, clarification at this point would certainly help me.
> 
> 
> Eastlake III Donald-LDE008 wrote:
> > This is a check via the mailing list to confirm or refute an
apparent
> > consensus from the minutes of the Chicago meeting for a change from
> > protocol draft -05:
> >
> >    If it is known that a link is a point to point link between two
> >    RBridges, then the outer header, if it is an Ethernet header, can
> >    have any source and/or destination addresses, those addresses
will
> >    be ignored on receipt, and the outer VLAN tag can be omitted.
> >
> > If no particular controversy arises over this in the next two weeks,
> we
> > will declare it to be the working group consensus.
> >
> > Thanks,
> > Donald & Erik
> >
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Fri, 5 Oct 2007 00:29:44 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1078

Hi Caitlin,

It is my understanding that some IETF routing protocols do have special
provisions for "un-numbered links" but by that they mean that IP
addresses are not allocated for the ends of the links. This is a
precedent for not allocating layer-N addresses for a layer-N protocol on
a layer-N-point-to-point link, although in this case N=3.

Layer-3 routing protocols generally aren't concerned with layer-2
addresses or even what layer-2 protocol is running on the link...

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Caitlin Bestler
Sent: Thursday, October 04, 2007 12:58 PM
To: Silvano Gai; Eric Gray; Joe Touch
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links

Why wouldn't a "other end of the link" reserved MAC address be
just as applicable for core Routers that are directly connected
to each other point-to-point?

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Fri, 5 Oct 2007 00:28:36 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 7923

Eric,

Well, even if a consensus of the working group wanted to do maple walnut
waffle-cones with caramel, there is a problem that, as far as I can see,
that isn't in our Charter. But I think that this is related enough to
TRILL, as I will explain, that it would be OK to include in our output
if the working group wants to do so.

802.3-like interfaces for point-to-point use as indicated here can be
practical for Rbridge but not for 802.1 bridges because of the
characteristics of the TRILL protocol. In TRILL, the outer VLAN tag is
just an artifact for getting to the next Rbridge (or Rbridges) for TRILL
EtherType frames.  In a point-to-point link between Rbridges, that tag
and the outer MAC addresses are not logically necessary for TRILL
frames. Then tag can be omitted and the addresses can be a value ignored
on receipt.

However, whether you could implenent this feature is influenced by the
design of TRILL. For example, I believe the current protocol spec says
that local sources/sinks of frames on an Rbridge (for example SNMP) are
treated as if they were on a virtual port out of the Rbridge. That means
that, between two Rbridges, such frames area always encapsulated, even
if we has an Rbridge with a co-located management station talking to an
SNMP implementtion in a second Rbridge just one point-to-point link
away. If, in this case, such frames were sent in native form, it seems
to me it would at least make it a more difficult to use, for example, a
fixed MAC address interface or to correctly detect when the assumption
that the interface in point-to-point is incorrect. Thus, even if this
feature isn't mentioned in the TRILL effect, the difficulty and perhaps
even the possibility of implementing it could be affected by details of
the TRILL protocol.

There is also the question of whether the use of such an interface for a
link should be indicated in the Rbridge MIB, although if a fixed know
MAC address were used, I believe that could simply be checked for in the
MIB.

Donald

-----Original Message-----
From: Eric Gray [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2007 3:10 PM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] Consensus Check: Point to Point links

Donald,

	Perhaps all of these things are true. 

	So what?

	The argument that a lot of people would like to do X could
be used to do a lot of things.  I'd like us to make maple walnut 
waffle-cones - possibly with caramel on top. 

	Ummm, does that sound good! 

	What does ANY of this have to do with TRILL?

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Wednesday, October 03, 2007 2:25 PM
> To: [email-masked]
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> Hi Eric,
> 
> I believe the generally understood meaning of point-to-point is a link
> with exactly two devices on it, in this case RBridges.
> 
> It is true that one could always do this sort of thing outside the
> standards. But in Chicago the working group appeared to 
> believe this was
> sufficiently important to say in the standard and, while the consensus
> in the room was not that detailed, I got the general impression that
> people would be favorable to, in a later management document, having a
> MIB variable that would enable one to configure an interface as being
> known point-to-point, possibly point-to-point, or prohibited 
> from using
> this point-to-point outer address flexibility, or some such management
> configuration feature. There also seemed to have been at least some
> interest in an automated way of determining that an interface was
> point-to-point, perhaps based on the receive of 802.1AB frames all
> containing appropriate indications coupled with the receipt 
> of no native
> frames.
> 
> Point-to-point links are, in fact, very common in modern 
> 802.3 networks.
> 
> Donald
> 
> -----Original Message-----
> From: Eric Gray [mailto:[email-masked]] 
> Sent: Wednesday, October 03, 2007 11:11 AM
> To: Eastlake III Donald-LDE008; [email-masked]
> Subject: RE: [rbridge] Consensus Check: Point to Point links
> 
> Donald,
> 
> 	Given that it is not crystal clear what you mean by 
> "point to point link", I am not sure I agree with this, at
> least as you have worded it here.
> 
> 	If you mean that the link is a full-duplex Ethernet
> link and the two end-points have some definitive mechansim
> for determining that they are the only entities using the
> link between them, there may be issues with doing this.
> 
> 	For example, if the link is technically an Ethernet 
> link, then it is not unlikely that one or the other devices 
> may have multiple roles - i.e. - it may be both an RBridge 
> for some frames and either a regular bridge or end station
> (for example, a router) for others.  It's arguable that, in
> this case, the multi-role device is two (or more) separate
> entities - thus invalidating a "point to point" definition
> for this case (though only two distinct physical devices
> are connected via this link).
> 
> 	Without a clear agreement between involved entities,
> this sort of "short-cut" addressing is likely to result in
> higher-level (slow path) processing of many (if not all) 
> of the frames transiting the link for some implementations.
> Moreover, without an unambiguous determination of exactly
> when this would apply, it will not be unambiguously clear
> when a receiving implementation would have to switch to a
> "promiscuous listening" mode.
> 
> 	I believe omission of the outer VLAN tag suffers from
> the same ambiguity.  For instance, it is possible for two
> devices to have a "point to point" relationship within a 
> VLAN context that would not be the case without the VLAN
> context.
> 
> 	Hence it appears we would have to be explicit in what
> we mean by "point to point" link and how we expect that the
> entities (RBridges) involved would be able to disambiguate
> this p2p status for any given link.
> 
> 	If we are saying that two devices - using some means 
> out of scope for our specification - are somehow aware of an 
> unambiguous point-to-point relationship between them and can
> therefore use any MAC DA on transmission, and ignore it on
> receipt, we could make the same argument for virtually any 
> encapsulation choice we might prefer.  But, it would be as
> valid to observe that we don't need to specify what is - in
> essence - an out-of-context (mis)behavior between consenting 
> implementations...
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Eastlake III 
> > Donald-LDE008
> > Sent: Tuesday, October 02, 2007 11:27 PM
> > To: [email-masked]
> > Subject: [rbridge] Consensus Check: Point to Point links
> > 
> > This is a check via the mailing list to confirm or refute 
> an apparent
> > consensus from the minutes of the Chicago meeting for a change from
> > protocol draft -05:
> > 
> >    If it is known that a link is a point to point link between two
> >    RBridges, then the outer header, if it is an Ethernet header, can
> >    have any source and/or destination addresses, those 
> addresses will
> >    be ignored on receipt, and the outer VLAN tag can be omitted.
> > 
> > If no particular controversy arises over this in the next two 
> > weeks, we
> > will declare it to be the working group consensus.
> > 
> > Thanks,
> > Donald & Erik
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Fri, 5 Oct 2007 00:24:16 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 2955

Hi Radia,

See below at @@@

-----Original Message-----
From: Radia Perlman [mailto:[email-masked]] 
Sent: Thursday, October 04, 2007 11:51 AM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links

Personally, I need a reminder of what we are trying to accomplish with 
this before I can have
any opinion.

a) Is omitting the outer VLAN tag to save space?

@@@ Yes. The outer VLAN tag does nothing for you on a point-to-point
link.

b) Why put in anything for destination address other than the MAC 
address of the next hop
RBridge, or put in anything into the source address other than your own 
MAC address?
It won't save space. So what does it gain?

@@@ While no one has given a really crisp response to that question, it
is my impression that some believe it will make it possible to produce
simpler, less expensive, or more efficient hardware for this case.

c) Is there any danger if an RBridge is confused about whether this is a

pt-to-pt link or not?

@@@ I think there might be. And because of this and the extreme
commonness of the point-to-point case, it may be reasonable to consider
this in designing TRILL. For example, if a fixed MAC address were used
(such as the unicast version of the All-Rbridges multicast address (just
turn off the group bit)), then an interface receiving a frame with that
source address would know there was a sender on the link who believes
the link was point-to-point. If the receiver knows it is not
point-to-point or is unwilling to handle such frames, it could take
appropriate action. Also, Rbridge would know to never bother "learning"
the location of that MAC address.

@@@ Thanks,
@@@ Donald

I can see the advantage of omitting the entire outer header if it is 
somehow absolutely
known this is a pt-to-pt link, and both ends of the link understand 
this. But that isn't what's
being proposed here. It seems to be only omitting the VLAN tag, and 
allowing insertion of
random addresses into the source and destination fields in the outer 
header, if I'm reading
it correctly.

So anyway, clarification at this point would certainly help me.

Eastlake III Donald-LDE008 wrote:
> This is a check via the mailing list to confirm or refute an apparent
> consensus from the minutes of the Chicago meeting for a change from
> protocol draft -05:
>
>    If it is known that a link is a point to point link between two
>    RBridges, then the outer header, if it is an Ethernet header, can
>    have any source and/or destination addresses, those addresses will
>    be ignored on receipt, and the outer VLAN tag can be omitted.
>
> If no particular controversy arises over this in the next two weeks,
we
> will declare it to be the working group consensus.
>
> Thanks,
> Donald & Erik
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

Content-class: urn:content-classes:message
Date: Fri, 5 Oct 2007 00:14:14 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 2452

Actually, although I'm not entirely sure, I believe that BPDUs, LLDP
PDUs, etc., all start with an Ethertype which identifies them so, in
principle, they could be made to work on a specially equipped point to
point link with no outer MAC addresses. However, I don't think anyone
has proposed that TRILL should consider omitting the outer MAC addresses
except when that suggestion appears as part of a question asking why, if
you want to do some optimization on a point-to-point link, you don't
want to do even more optimization.

Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Thursday, October 04, 2007 1:46 PM
To: Radia Perlman; Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: [rbridge] Consensus Check: Point to Point links

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Thursday, October 04, 2007 8:51 AM
> To: Eastlake III Donald-LDE008
> Cc: [email-masked]
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> Personally, I need a reminder of what we are trying to 
> accomplish with this before I can have any opinion.
> 
> a) Is omitting the outer VLAN tag to save space?
> b) Why put in anything for destination address other than the 
> MAC address of the next hop RBridge, or put in anything into 
> the source address other than your own MAC address?
> It won't save space. So what does it gain?
> c) Is there any danger if an RBridge is confused about 
> whether this is a pt-to-pt link or not?
> 
> I can see the advantage of omitting the entire outer header 
> if it is somehow absolutely known this is a pt-to-pt link, 
> and both ends of the link understand this. 

That wouldn't work because there are other frames that will
have to have MAC addresses, e.g. LACP, LLDP.

> But that isn't 
> what's being proposed here. It seems to be only omitting the 
> VLAN tag, and allowing insertion of random addresses into the 
> source and destination fields in the outer header, if I'm 
> reading it correctly.

I don't like the idea of random addresses (is it that
a big a deal to set them correctly?), but as long as
it's completely optional, I don't really care. 
[By the way, even though the proposal says that it
can be random, it really can't because we have to
say that they cannot be from the BPDU address space
or things like LACP and LLDP will break.]

Anoop

Content-class: urn:content-classes:message
Date: Thu, 4 Oct 2007 14:08:52 -0500
From: "Eric Gray" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Radia Perlman" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 2821

Anoop,

	Making it completely optional is a problem as well, and this
is where I am having the most difficulty - particular with "random"
addresses that require ignoring.

	The issue is that this is a wrong-way-around unilateral choice
- i.e. - it is the sender that we say might have the option of doing
this, but the receiver that has the complexity of supporting either
way of doing it.

	If the entity making the choice was also the one having to pay
for it, then I would agree that making it a choice would be okay.

	That does not seem to be the case!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
> Sent: Thursday, October 04, 2007 1:46 PM
> To: Radia Perlman; Eastlake III Donald-LDE008
> Cc: [email-masked]
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
>  
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Radia Perlman
> > Sent: Thursday, October 04, 2007 8:51 AM
> > To: Eastlake III Donald-LDE008
> > Cc: [email-masked]
> > Subject: Re: [rbridge] Consensus Check: Point to Point links
> > 
> > Personally, I need a reminder of what we are trying to 
> > accomplish with this before I can have any opinion.
> > 
> > a) Is omitting the outer VLAN tag to save space?
> > b) Why put in anything for destination address other than the 
> > MAC address of the next hop RBridge, or put in anything into 
> > the source address other than your own MAC address?
> > It won't save space. So what does it gain?
> > c) Is there any danger if an RBridge is confused about 
> > whether this is a pt-to-pt link or not?
> > 
> > I can see the advantage of omitting the entire outer header 
> > if it is somehow absolutely known this is a pt-to-pt link, 
> > and both ends of the link understand this. 
> 
> That wouldn't work because there are other frames that will
> have to have MAC addresses, e.g. LACP, LLDP.
> 
> > But that isn't 
> > what's being proposed here. It seems to be only omitting the 
> > VLAN tag, and allowing insertion of random addresses into the 
> > source and destination fields in the outer header, if I'm 
> > reading it correctly.
> 
> I don't like the idea of random addresses (is it that
> a big a deal to set them correctly?), but as long as
> it's completely optional, I don't really care. 
> [By the way, even though the proposal says that it
> can be random, it really can't because we have to
> say that they cannot be from the BPDU address space
> or things like LACP and LLDP will break.]
> 
> Anoop
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Thu, 4 Oct 2007 10:45:47 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1666

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Thursday, October 04, 2007 8:51 AM
> To: Eastlake III Donald-LDE008
> Cc: [email-masked]
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> Personally, I need a reminder of what we are trying to 
> accomplish with this before I can have any opinion.
> 
> a) Is omitting the outer VLAN tag to save space?
> b) Why put in anything for destination address other than the 
> MAC address of the next hop RBridge, or put in anything into 
> the source address other than your own MAC address?
> It won't save space. So what does it gain?
> c) Is there any danger if an RBridge is confused about 
> whether this is a pt-to-pt link or not?
> 
> I can see the advantage of omitting the entire outer header 
> if it is somehow absolutely known this is a pt-to-pt link, 
> and both ends of the link understand this. 

That wouldn't work because there are other frames that will
have to have MAC addresses, e.g. LACP, LLDP.

> But that isn't 
> what's being proposed here. It seems to be only omitting the 
> VLAN tag, and allowing insertion of random addresses into the 
> source and destination fields in the outer header, if I'm 
> reading it correctly.

I don't like the idea of random addresses (is it that
a big a deal to set them correctly?), but as long as
it's completely optional, I don't really care. 
[By the way, even though the proposal says that it
can be random, it really can't because we have to
say that they cannot be from the BPDU address space
or things like LACP and LLDP will break.]

Anoop

Content-class: urn:content-classes:message
Date: Thu, 4 Oct 2007 12:58:09 -0400
From: "Caitlin Bestler" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Eric Gray" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 160

Why wouldn't a "other end of the link" reserved MAC address be
just as applicable for core Routers that are directly connected
to each other point-to-point?

Date: Thu, 04 Oct 2007 08:50:34 -0700
From: Radia Perlman <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1717

Personally, I need a reminder of what we are trying to accomplish with 
this before I can have
any opinion.

a) Is omitting the outer VLAN tag to save space?
b) Why put in anything for destination address other than the MAC 
address of the next hop
RBridge, or put in anything into the source address other than your own 
MAC address?
It won't save space. So what does it gain?
c) Is there any danger if an RBridge is confused about whether this is a 
pt-to-pt link or not?

I can see the advantage of omitting the entire outer header if it is 
somehow absolutely
known this is a pt-to-pt link, and both ends of the link understand 
this. But that isn't what's
being proposed here. It seems to be only omitting the VLAN tag, and 
allowing insertion of
random addresses into the source and destination fields in the outer 
header, if I'm reading
it correctly.

So anyway, clarification at this point would certainly help me.

Eastlake III Donald-LDE008 wrote:
> This is a check via the mailing list to confirm or refute an apparent
> consensus from the minutes of the Chicago meeting for a change from
> protocol draft -05:
>
>    If it is known that a link is a point to point link between two
>    RBridges, then the outer header, if it is an Ethernet header, can
>    have any source and/or destination addresses, those addresses will
>    be ignored on receipt, and the outer VLAN tag can be omitted.
>
> If no particular controversy arises over this in the next two weeks, we
> will declare it to be the working group consensus.
>
> Thanks,
> Donald & Erik
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

Content-class: urn:content-classes:message
Date: Thu, 4 Oct 2007 07:17:59 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eric Gray" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Caitlin Bestler <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 2817

A frame that is switched by a Bridge is NEVER addressed to the Bridge.
An encapsulated frame that is switched by an RBridge is ALWAYS addressed
to the RBridge.

I understand management frames; it is not what we are discussing here.

Using a reserved MAC address or ignoring the MAC address on
point-to-point links achieves the same goal. Pick one, I don't care.

This is a simple and effective solution; I don't understand the need to
deny it.

-- Silvano

> -----Original Message-----
> From: Eric Gray [mailto:[email-masked]]
> Sent: Thursday, October 04, 2007 5:29 AM
> To: Silvano Gai; Joe Touch
> Cc: [email-masked]; Caitlin Bestler
> Subject: RE: [rbridge] Consensus Check: Point to Point links
> 
> Silvano,
> 
> 	It is not exactly true that bridges are never addressed at the
> MAC layer.  Consider, for example, how bridges are typically managed
> using SNMP, or HTML.
> 
> 	However, the case is still general, because everything you say
> about RBridges - and the likelihood that they might be connected via
> P2P links - similarly applies to other devices (L2 end-stations, such
> as routers, for example.  And objecting that it may (or may not) be
> easy for these devices to determine that a link is P2P is an argument
> that applies equally to RBridges.
> 
> 	I think it is not possible at this point to argue that there is
> consensus to do this work here, in the TRILL working group.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Silvano Gai
> > Sent: Thursday, October 04, 2007 1:56 AM
> > To: Joe Touch
> > Cc: [email-masked]; Caitlin Bestler
> > Subject: Re: [rbridge] Consensus Check: Point to Point links
> >
> > Because Bridges are never addressed at the MAC layer,
> > RBridges instead are!
> >
> > -- Silvano
> >
> > > -----Original Message-----
> > > From: Joe Touch [mailto:[email-masked]]
> > > Sent: Wednesday, October 03, 2007 10:48 PM
> > > To: Silvano Gai
> > > Cc: Dinesh G Dutt; [email-masked]; Caitlin Bestler
> > > Subject: Re: [rbridge] Consensus Check: Point to Point links
> > >
> > >
> > >
> > > Silvano Gai wrote:
> > > > Joe,
> > > >
> > > > Nobody is asking "to specify a new, non-ethernet link layer."
> > > >
> > > > We are just asking to have a reserved MAC address that means
"the
> > other
> > > > end of the link".
> > > >
> > > > The frame is still 100% compliant with Ethernet.
> > >
> > > If regular ethernet and regular bridges don't need this, why do
> > rbridges?
> > >
> > > (bridges are already connected by such pt-pt links)
> > >
> > > Joe
> >
> >
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >

Content-class: urn:content-classes:message
Date: Thu, 4 Oct 2007 07:33:15 -0500
From: "Eric Gray" <[email-masked]>
To: "Joe Touch" <[email-masked]>, "Silvano Gai" <[email-masked]>
Cc: [email-masked], Caitlin Bestler <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1248

Joe,

	While what Silvano says about bridges not (typically) being
addressed by MAC address is true, and it is even more likely to be
true for neighbor to neighbor communications, I agree that this is
a general problem.

	I can hardly believe that this is the only example ever to
come up of a layer-2 forwarding device wanting to have direct -
neighbor to neighbor - protocol exchanges.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Thursday, October 04, 2007 1:48 AM
> To: Silvano Gai
> Cc: [email-masked]; Caitlin Bestler
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> * PGP Signed: 10/04/2007 at 07:47:58 AM
> 
> 
> Silvano Gai wrote:
> > Joe,
> > 
> > Nobody is asking "to specify a new, non-ethernet link layer."
> > 
> > We are just asking to have a reserved MAC address that 
> means "the other
> > end of the link".
> > 
> > The frame is still 100% compliant with Ethernet.
> 
> If regular ethernet and regular bridges don't need this, why 
> do rbridges?
> 
> (bridges are already connected by such pt-pt links)
> 
> Joe
> 
> * Joe Touch <[email-masked]>
> * 0x89A766BB (L)
> 
> 

Content-class: urn:content-classes:message
Date: Thu, 4 Oct 2007 07:28:36 -0500
From: "Eric Gray" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Caitlin Bestler <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1981

Silvano,

	It is not exactly true that bridges are never addressed at the 
MAC layer.  Consider, for example, how bridges are typically managed
using SNMP, or HTML.

	However, the case is still general, because everything you say
about RBridges - and the likelihood that they might be connected via
P2P links - similarly applies to other devices (L2 end-stations, such
as routers, for example.  And objecting that it may (or may not) be
easy for these devices to determine that a link is P2P is an argument
that applies equally to RBridges.

	I think it is not possible at this point to argue that there is
consensus to do this work here, in the TRILL working group.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Silvano Gai
> Sent: Thursday, October 04, 2007 1:56 AM
> To: Joe Touch
> Cc: [email-masked]; Caitlin Bestler
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> Because Bridges are never addressed at the MAC layer,
> RBridges instead are!
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: Joe Touch [mailto:[email-masked]]
> > Sent: Wednesday, October 03, 2007 10:48 PM
> > To: Silvano Gai
> > Cc: Dinesh G Dutt; [email-masked]; Caitlin Bestler
> > Subject: Re: [rbridge] Consensus Check: Point to Point links
> > 
> > 
> > 
> > Silvano Gai wrote:
> > > Joe,
> > >
> > > Nobody is asking "to specify a new, non-ethernet link layer."
> > >
> > > We are just asking to have a reserved MAC address that means "the
> other
> > > end of the link".
> > >
> > > The frame is still 100% compliant with Ethernet.
> > 
> > If regular ethernet and regular bridges don't need this, why do
> rbridges?
> > 
> > (bridges are already connected by such pt-pt links)
> > 
> > Joe
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Thu, 4 Oct 2007 07:23:33 -0500
From: "Eric Gray" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Caitlin Bestler <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 5295

Silvano,

	This is NOT AT ALL what Donald said.  Having a reserved 
MAC address for the other end of a link is completely different
from saying "any MAC address may be used and MUST be ignored on
receipt."

	As for this - cleary different - proposal, I think it is
quite reasonable, but almost certainly not something for us to
do - HERE.  As Joe points out, this is a general problem that 
should be addresses generally, rather than here and just for
RBridges.

	This should be done via the IEEE.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Silvano Gai
> Sent: Thursday, October 04, 2007 1:42 AM
> To: Joe Touch
> Cc: [email-masked]; Caitlin Bestler
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> Joe,
> 
> Nobody is asking "to specify a new, non-ethernet link layer."
> 
> We are just asking to have a reserved MAC address that means 
> "the other
> end of the link".
> 
> The frame is still 100% compliant with Ethernet.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: Joe Touch [mailto:[email-masked]]
> > Sent: Wednesday, October 03, 2007 10:26 PM
> > To: Silvano Gai
> > Cc: Dinesh G Dutt; [email-masked]; Caitlin Bestler
> > Subject: Re: [rbridge] Consensus Check: Point to Point links
> > 
> > 
> > 
> > Silvano Gai wrote:
> > > Joe,
> > >
> > > The majority of RBridges will be deployed in backbone where they
> will be
> > > connected by point-to-point links. The classical case will be 10GE
> links
> > > (which are only full-duplex). There will be no bridges 
> between them.
> > >
> > > What we are asking is a sentence that guarantees a simplified
> > > interoperability in this case.
> > >
> > > I don't see what harm it can do.
> > 
> > I don't see the need to specify a new, non-ethernet link layer.
> > 
> > If this maps to "point to point links can use encapsulation-only
> > ethernet" (I'm familiar with such a thing; does it ignore addresses
> and
> > use the MAC only for the CRC? if so, what is it called 
> exactly?), and
> we
> > can point to that, then there's no need for us to define it.
> > 
> > If no such thing exists, then it might be useful to raise 
> this in the
> > IEEE. I don't see why it is more relevant to rbridges than to any
> other
> > kind of bridge - for which pt-pt interconnections are also already
> used.
> > 
> > Joe
> > 
> > >
> > > -- Silvano
> > >
> > >
> > >> -----Original Message-----
> > >> From: Joe Touch [mailto:[email-masked]]
> > >> Sent: Wednesday, October 03, 2007 10:06 PM
> > >> To: Silvano Gai
> > >> Cc: Dinesh G Dutt; [email-masked]; Caitlin Bestler
> > >> Subject: Re: [rbridge] Consensus Check: Point to Point links
> > >>
> > >> I can't speak for others, but I'm completely lost on this point.
> > > Rbridge
> > >> is defining a layer on top of ethernet. This pt-pt link stuff
> sounds
> > >> like it's redefining the ethernet layer for a special case.
> > >>
> > >> Whether it's useful to have ethernet have a definition 
> for a pt-pt
> > > case
> > >> is not relevant to this WG, IMO. It seems at best out of scope,
> even
> > > if
> > >> it is useful.
> > >>
> > >> Can anyone explain why this shouldn't be already handled by
> ethernet,
> > >> and if it isn't, why we need to handle it as a special case here?
> > >>
> > >> Joe
> > >>
> > >> Silvano Gai wrote:
> > >>> I totally agree with Dinesh
> > >>>
> > >>> -- Silvano
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: [email-masked]
> > > [mailto:[email-masked]]
> > >>> On
> > >>>> Behalf Of Dinesh G Dutt
> > >>>> Sent: Wednesday, October 03, 2007 5:24 PM
> > >>>> To: Joe Touch
> > >>>> Cc: [email-masked]; Caitlin Bestler
> > >>>> Subject: Re: [rbridge] Consensus Check: Point to Point links
> > >>>>
> > >>>> The reason this is useful in the spec is that we can have
> > >>>> interoperability. The situation is common enough that allowing
> > >>>> interoperability simplifies implementations.
> > >>>>
> > >>>> Dinesh
> > >>>> Joe Touch wrote:
> > >>>>> Eric Gray wrote:
> > >>>>>
> > >>>>>> Caitlin,
> > >>>>>>
> > >>>>> ...
> > >>>>>
> > >>>>>> I get the sense that you're not disagreeing with 
> either Joe or
> > >>>>>> myself.
> > >>>>>>
> > >>>>> I agree with the nuances Caitlin is raising; the conclusion is
> > > that
> > >>> this
> > >>>>> need not be in the spec, as far as we three appear to agree.
> > >>>>>
> > >>>>> Joe
> > >>>>>
> > >>>>>
> > >>>>>
> > >
> --------------------------------------------------------------
> ----------
> > >>>>> _______________________________________________
> > >>>>> rbridge mailing list
> > >>>>> [email-masked]
> > >>>>> 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
> > >>>> [email-masked]
> > >>>> http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Date: Wed, 03 Oct 2007 23:33:08 -0700
From: Dinesh G Dutt <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Egress processing of unicast not	locallyknown
Status: RO
Content-Length: 2519

Anoop,

Did you mean that in the example that he quoted the reason for dropping 
the frame was access control (such as 802.1x authenticated) ? To me 
access control is a very generic term that can also include things such 
as security ACLs.

"Access Control" is orthogonal to forwarding. For example, I can have IP 
FIB entries or MAC table entries associated with a frame, but can drop a 
specific frame such as those going to "port 80" as part of access 
control. What Donald is specifying *seems* to be in addition to access 
control.

Dinesh
Anoop Ghanwani wrote:
> I'm not sure why the case of "MAC address could
> not be on that link" needs to be called out at all.
> That is an access control issue.  But I am OK
> with having it if someone really feels strongly
> about it.
>
> Anoop 
>
>   
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Eastlake III 
>> Donald-LDE008
>> Sent: Tuesday, October 02, 2007 8:25 PM
>> To: [email-masked]
>> Subject: [rbridge] Consensus Check: Egress processing of 
>> unicast not locallyknown
>>
>> This is a check via the mailing list to confirm or refute an 
>> apparent consensus from the minutes of the Chicago meeting 
>> for a change from protocol draft -05:
>>
>>    Egress RBridges that receive a known unicast TRILL data frame whose
>>    inner destination address is not known locally should send the
>>    native form of the frame out on every link for which the RBridge
>>    is DRB for the frame's VLAN unless it knows that an end station
>>    with that MAC address could not be on that link. (For example,
>>    there is a layer-2 registration procedure for end stations on that
>>    link and the destination MAC address in question is not
>>    registered.) This is a local decision. No "error" message will be
>>    defined for this condition at this time.
>>
>> If no particular controversy arises over this in the next two 
>> weeks, we will declare it to be the working group consensus.
>>
>> Thanks,
>> Donald & Erik
>>
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>     
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> 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

Date: Wed, 03 Oct 2007 23:29:26 -0700
From: Dinesh G Dutt <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Egress processing of unicast not locally known
Status: RO
Content-Length: 1497

Donald,

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

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

Content-class: urn:content-classes:message
Date: Wed, 3 Oct 2007 22:56:27 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Caitlin Bestler <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 757

Because Bridges are never addressed at the MAC layer,
RBridges instead are!

-- Silvano

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Wednesday, October 03, 2007 10:48 PM
> To: Silvano Gai
> Cc: Dinesh G Dutt; [email-masked]; Caitlin Bestler
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> >
> > Nobody is asking "to specify a new, non-ethernet link layer."
> >
> > We are just asking to have a reserved MAC address that means "the
other
> > end of the link".
> >
> > The frame is still 100% compliant with Ethernet.
> 
> If regular ethernet and regular bridges don't need this, why do
rbridges?
> 
> (bridges are already connected by such pt-pt links)
> 
> Joe

Date: Wed, 03 Oct 2007 22:47:58 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Caitlin Bestler <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1090

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

Silvano Gai wrote:
> Joe,
>=20
> Nobody is asking "to specify a new, non-ethernet link layer."
>=20
> We are just asking to have a reserved MAC address that means "the other=

> end of the link".
>=20
> The frame is still 100% compliant with Ethernet.

If regular ethernet and regular bridges don't need this, why do rbridges?=

(bridges are already connected by such pt-pt links)

Joe

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

--------------enig0A4EF94378C9754934695B86--

Content-class: urn:content-classes:message
Date: Wed, 3 Oct 2007 22:41:59 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Caitlin Bestler <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 4004

Joe,

Nobody is asking "to specify a new, non-ethernet link layer."

We are just asking to have a reserved MAC address that means "the other
end of the link".

The frame is still 100% compliant with Ethernet.

-- Silvano

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Wednesday, October 03, 2007 10:26 PM
> To: Silvano Gai
> Cc: Dinesh G Dutt; [email-masked]; Caitlin Bestler
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> >
> > The majority of RBridges will be deployed in backbone where they
will be
> > connected by point-to-point links. The classical case will be 10GE
links
> > (which are only full-duplex). There will be no bridges between them.
> >
> > What we are asking is a sentence that guarantees a simplified
> > interoperability in this case.
> >
> > I don't see what harm it can do.
> 
> I don't see the need to specify a new, non-ethernet link layer.
> 
> If this maps to "point to point links can use encapsulation-only
> ethernet" (I'm familiar with such a thing; does it ignore addresses
and
> use the MAC only for the CRC? if so, what is it called exactly?), and
we
> can point to that, then there's no need for us to define it.
> 
> If no such thing exists, then it might be useful to raise this in the
> IEEE. I don't see why it is more relevant to rbridges than to any
other
> kind of bridge - for which pt-pt interconnections are also already
used.
> 
> Joe
> 
> >
> > -- Silvano
> >
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[email-masked]]
> >> Sent: Wednesday, October 03, 2007 10:06 PM
> >> To: Silvano Gai
> >> Cc: Dinesh G Dutt; [email-masked]; Caitlin Bestler
> >> Subject: Re: [rbridge] Consensus Check: Point to Point links
> >>
> >> I can't speak for others, but I'm completely lost on this point.
> > Rbridge
> >> is defining a layer on top of ethernet. This pt-pt link stuff
sounds
> >> like it's redefining the ethernet layer for a special case.
> >>
> >> Whether it's useful to have ethernet have a definition for a pt-pt
> > case
> >> is not relevant to this WG, IMO. It seems at best out of scope,
even
> > if
> >> it is useful.
> >>
> >> Can anyone explain why this shouldn't be already handled by
ethernet,
> >> and if it isn't, why we need to handle it as a special case here?
> >>
> >> Joe
> >>
> >> Silvano Gai wrote:
> >>> I totally agree with Dinesh
> >>>
> >>> -- Silvano
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked]
> > [mailto:[email-masked]]
> >>> On
> >>>> Behalf Of Dinesh G Dutt
> >>>> Sent: Wednesday, October 03, 2007 5:24 PM
> >>>> To: Joe Touch
> >>>> Cc: [email-masked]; Caitlin Bestler
> >>>> Subject: Re: [rbridge] Consensus Check: Point to Point links
> >>>>
> >>>> The reason this is useful in the spec is that we can have
> >>>> interoperability. The situation is common enough that allowing
> >>>> interoperability simplifies implementations.
> >>>>
> >>>> Dinesh
> >>>> Joe Touch wrote:
> >>>>> Eric Gray wrote:
> >>>>>
> >>>>>> Caitlin,
> >>>>>>
> >>>>> ...
> >>>>>
> >>>>>> I get the sense that you're not disagreeing with either Joe or
> >>>>>> myself.
> >>>>>>
> >>>>> I agree with the nuances Caitlin is raising; the conclusion is
> > that
> >>> this
> >>>>> need not be in the spec, as far as we three appear to agree.
> >>>>>
> >>>>> Joe
> >>>>>
> >>>>>
> >>>>>
> >
------------------------------------------------------------------------
> >>>>> _______________________________________________
> >>>>> rbridge mailing list
> >>>>> [email-masked]
> >>>>> 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
> >>>> [email-masked]
> >>>> http://mailman.postel.org/mailman/listinfo/rbridge
> >

Date: Wed, 03 Oct 2007 22:25:32 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Caitlin Bestler <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 4034

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

Silvano Gai wrote:
> Joe,
>=20
> The majority of RBridges will be deployed in backbone where they will b=
e
> connected by point-to-point links. The classical case will be 10GE link=
s
> (which are only full-duplex). There will be no bridges between them.
>=20
> What we are asking is a sentence that guarantees a simplified
> interoperability in this case.
>=20
> I don't see what harm it can do.

I don't see the need to specify a new, non-ethernet link layer.

If this maps to "point to point links can use encapsulation-only
ethernet" (I'm familiar with such a thing; does it ignore addresses and
use the MAC only for the CRC? if so, what is it called exactly?), and we
can point to that, then there's no need for us to define it.

If no such thing exists, then it might be useful to raise this in the
IEEE. I don't see why it is more relevant to rbridges than to any other
kind of bridge - for which pt-pt interconnections are also already used.

Joe

>=20
> -- Silvano
>=20
>=20
>> -----Original Message-----
>> From: Joe Touch [mailto:[email-masked]]
>> Sent: Wednesday, October 03, 2007 10:06 PM
>> To: Silvano Gai
>> Cc: Dinesh G Dutt; [email-masked]; Caitlin Bestler
>> Subject: Re: [rbridge] Consensus Check: Point to Point links
>>
>> I can't speak for others, but I'm completely lost on this point.
> Rbridge
>> is defining a layer on top of ethernet. This pt-pt link stuff sounds
>> like it's redefining the ethernet layer for a special case.
>>
>> Whether it's useful to have ethernet have a definition for a pt-pt
> case
>> is not relevant to this WG, IMO. It seems at best out of scope, even
> if
>> it is useful.
>>
>> Can anyone explain why this shouldn't be already handled by ethernet,
>> and if it isn't, why we need to handle it as a special case here?
>>
>> Joe
>>
>> Silvano Gai wrote:
>>> I totally agree with Dinesh
>>>
>>> -- Silvano
>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
> [mailto:[email-masked]]
>>> On
>>>> Behalf Of Dinesh G Dutt
>>>> Sent: Wednesday, October 03, 2007 5:24 PM
>>>> To: Joe Touch
>>>> Cc: [email-masked]; Caitlin Bestler
>>>> Subject: Re: [rbridge] Consensus Check: Point to Point links
>>>>
>>>> The reason this is useful in the spec is that we can have
>>>> interoperability. The situation is common enough that allowing
>>>> interoperability simplifies implementations.
>>>>
>>>> Dinesh
>>>> Joe Touch wrote:
>>>>> Eric Gray wrote:
>>>>>
>>>>>> Caitlin,
>>>>>>
>>>>> ...
>>>>>
>>>>>> I get the sense that you're not disagreeing with either Joe or
>>>>>> myself.
>>>>>>
>>>>> I agree with the nuances Caitlin is raising; the conclusion is
> that
>>> this
>>>>> need not be in the spec, as far as we three appear to agree.
>>>>>
>>>>> Joe
>>>>>
>>>>>
>>>>>
> -----------------------------------------------------------------------=
-
>>>>> _______________________________________________
>>>>> rbridge mailing list
>>>>> [email-masked]
>>>>> 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
>>>> [email-masked]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>=20

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

--------------enigA2AF5F76AFB8EC16381EFC62--

Content-class: urn:content-classes:message
Date: Wed, 3 Oct 2007 22:12:07 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Caitlin Bestler <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 2677

Joe,

The majority of RBridges will be deployed in backbone where they will be
connected by point-to-point links. The classical case will be 10GE links
(which are only full-duplex). There will be no bridges between them.

What we are asking is a sentence that guarantees a simplified
interoperability in this case.

I don't see what harm it can do.

-- Silvano

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Wednesday, October 03, 2007 10:06 PM
> To: Silvano Gai
> Cc: Dinesh G Dutt; [email-masked]; Caitlin Bestler
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> I can't speak for others, but I'm completely lost on this point.
Rbridge
> is defining a layer on top of ethernet. This pt-pt link stuff sounds
> like it's redefining the ethernet layer for a special case.
> 
> Whether it's useful to have ethernet have a definition for a pt-pt
case
> is not relevant to this WG, IMO. It seems at best out of scope, even
if
> it is useful.
> 
> Can anyone explain why this shouldn't be already handled by ethernet,
> and if it isn't, why we need to handle it as a special case here?
> 
> Joe
> 
> Silvano Gai wrote:
> > I totally agree with Dinesh
> >
> > -- Silvano
> >
> >> -----Original Message-----
> >> From: [email-masked]
[mailto:[email-masked]]
> > On
> >> Behalf Of Dinesh G Dutt
> >> Sent: Wednesday, October 03, 2007 5:24 PM
> >> To: Joe Touch
> >> Cc: [email-masked]; Caitlin Bestler
> >> Subject: Re: [rbridge] Consensus Check: Point to Point links
> >>
> >> The reason this is useful in the spec is that we can have
> >> interoperability. The situation is common enough that allowing
> >> interoperability simplifies implementations.
> >>
> >> Dinesh
> >> Joe Touch wrote:
> >>> Eric Gray wrote:
> >>>
> >>>> Caitlin,
> >>>>
> >>> ...
> >>>
> >>>> I get the sense that you're not disagreeing with either Joe or
> >>>> myself.
> >>>>
> >>> I agree with the nuances Caitlin is raising; the conclusion is
that
> > this
> >>> need not be in the spec, as far as we three appear to agree.
> >>>
> >>> Joe
> >>>
> >>>
> >>>
> >
------------------------------------------------------------------------
> >>> _______________________________________________
> >>> rbridge mailing list
> >>> [email-masked]
> >>> 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
> >> [email-masked]
> >> http://mailman.postel.org/mailman/listinfo/rbridge

Date: Wed, 03 Oct 2007 22:05:56 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Caitlin Bestler <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 2638

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

I can't speak for others, but I'm completely lost on this point. Rbridge
is defining a layer on top of ethernet. This pt-pt link stuff sounds
like it's redefining the ethernet layer for a special case.

Whether it's useful to have ethernet have a definition for a pt-pt case
is not relevant to this WG, IMO. It seems at best out of scope, even if
it is useful.

Can anyone explain why this shouldn't be already handled by ethernet,
and if it isn't, why we need to handle it as a special case here?

Joe

Silvano Gai wrote:
> I totally agree with Dinesh
>=20
> -- Silvano
>=20
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
> On
>> Behalf Of Dinesh G Dutt
>> Sent: Wednesday, October 03, 2007 5:24 PM
>> To: Joe Touch
>> Cc: [email-masked]; Caitlin Bestler
>> Subject: Re: [rbridge] Consensus Check: Point to Point links
>>
>> The reason this is useful in the spec is that we can have
>> interoperability. The situation is common enough that allowing
>> interoperability simplifies implementations.
>>
>> Dinesh
>> Joe Touch wrote:
>>> Eric Gray wrote:
>>>
>>>> Caitlin,
>>>>
>>> ...
>>>
>>>> I get the sense that you're not disagreeing with either Joe or
>>>> myself.
>>>>
>>> I agree with the nuances Caitlin is raising; the conclusion is that
> this
>>> need not be in the spec, as far as we three appear to agree.
>>>
>>> Joe
>>>
>>>
>>>
> -----------------------------------------------------------------------=
-
>>> _______________________________________________
>>> rbridge mailing list
>>> [email-masked]
>>> 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
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge

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

--------------enigD1E08DA8E6AC49518C1057BC--

Content-class: urn:content-classes:message
Date: Wed, 3 Oct 2007 21:15:48 -0700
From: "Silvano Gai" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Caitlin Bestler <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1387

I totally agree with Dinesh

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Dinesh G Dutt
> Sent: Wednesday, October 03, 2007 5:24 PM
> To: Joe Touch
> Cc: [email-masked]; Caitlin Bestler
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> The reason this is useful in the spec is that we can have
> interoperability. The situation is common enough that allowing
> interoperability simplifies implementations.
> 
> Dinesh
> Joe Touch wrote:
> > Eric Gray wrote:
> >
> >> Caitlin,
> >>
> > ...
> >
> >> I get the sense that you're not disagreeing with either Joe or
> >> myself.
> >>
> >
> > I agree with the nuances Caitlin is raising; the conclusion is that
this
> > need not be in the spec, as far as we three appear to agree.
> >
> > Joe
> >
> >
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > 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
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Date: Wed, 03 Oct 2007 17:23:45 -0700
From: Dinesh G Dutt <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked], Caitlin Bestler <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 862

The reason this is useful in the spec is that we can have 
interoperability. The situation is common enough that allowing 
interoperability simplifies implementations.

Dinesh
Joe Touch wrote:
> Eric Gray wrote:
>   
>> Caitlin,
>>     
> ...
>   
>> I get the sense that you're not disagreeing with either Joe or 
>> myself.
>>     
>
> I agree with the nuances Caitlin is raising; the conclusion is that this
> need not be in the spec, as far as we three appear to agree.
>
> Joe
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> 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

Content-class: urn:content-classes:message
Date: Wed, 3 Oct 2007 14:10:04 -0500
From: "Eric Gray" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 5683

Donald,

	Perhaps all of these things are true. 

	So what?

	The argument that a lot of people would like to do X could
be used to do a lot of things.  I'd like us to make maple walnut 
waffle-cones - possibly with caramel on top. 

	Ummm, does that sound good! 

	What does ANY of this have to do with TRILL?

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Wednesday, October 03, 2007 2:25 PM
> To: [email-masked]
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> Hi Eric,
> 
> I believe the generally understood meaning of point-to-point is a link
> with exactly two devices on it, in this case RBridges.
> 
> It is true that one could always do this sort of thing outside the
> standards. But in Chicago the working group appeared to 
> believe this was
> sufficiently important to say in the standard and, while the consensus
> in the room was not that detailed, I got the general impression that
> people would be favorable to, in a later management document, having a
> MIB variable that would enable one to configure an interface as being
> known point-to-point, possibly point-to-point, or prohibited 
> from using
> this point-to-point outer address flexibility, or some such management
> configuration feature. There also seemed to have been at least some
> interest in an automated way of determining that an interface was
> point-to-point, perhaps based on the receive of 802.1AB frames all
> containing appropriate indications coupled with the receipt 
> of no native
> frames.
> 
> Point-to-point links are, in fact, very common in modern 
> 802.3 networks.
> 
> Donald
> 
> -----Original Message-----
> From: Eric Gray [mailto:[email-masked]] 
> Sent: Wednesday, October 03, 2007 11:11 AM
> To: Eastlake III Donald-LDE008; [email-masked]
> Subject: RE: [rbridge] Consensus Check: Point to Point links
> 
> Donald,
> 
> 	Given that it is not crystal clear what you mean by 
> "point to point link", I am not sure I agree with this, at
> least as you have worded it here.
> 
> 	If you mean that the link is a full-duplex Ethernet
> link and the two end-points have some definitive mechansim
> for determining that they are the only entities using the
> link between them, there may be issues with doing this.
> 
> 	For example, if the link is technically an Ethernet 
> link, then it is not unlikely that one or the other devices 
> may have multiple roles - i.e. - it may be both an RBridge 
> for some frames and either a regular bridge or end station
> (for example, a router) for others.  It's arguable that, in
> this case, the multi-role device is two (or more) separate
> entities - thus invalidating a "point to point" definition
> for this case (though only two distinct physical devices
> are connected via this link).
> 
> 	Without a clear agreement between involved entities,
> this sort of "short-cut" addressing is likely to result in
> higher-level (slow path) processing of many (if not all) 
> of the frames transiting the link for some implementations.
> Moreover, without an unambiguous determination of exactly
> when this would apply, it will not be unambiguously clear
> when a receiving implementation would have to switch to a
> "promiscuous listening" mode.
> 
> 	I believe omission of the outer VLAN tag suffers from
> the same ambiguity.  For instance, it is possible for two
> devices to have a "point to point" relationship within a 
> VLAN context that would nto be the case without the VLAN
> context.
> 
> 	Hence it appears we would have to be explicit in what
> we mean by "point to point" link and how we expect that the
> entities (RBridges) involved would be able to disambiguate
> this p2p status for any given link.
> 
> 	If we are saying that two devices - using some means 
> out of scope for our specification - are somehow aware of an 
> unambiguous point-to-point relationship between them and can
> therefore use any MAC DA on transmission, and ignore it on
> receipt, we could make the same argument for virtually any 
> encapsulation choice we might prefer.  But, it would be as
> valid to observe that we don't need to specify what is - in
> essence - an out-of-context (mis)behavior between consenting 
> implementations...
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Eastlake III 
> > Donald-LDE008
> > Sent: Tuesday, October 02, 2007 11:27 PM
> > To: [email-masked]
> > Subject: [rbridge] Consensus Check: Point to Point links
> > 
> > This is a check via the mailing list to confirm or refute 
> an apparent
> > consensus from the minutes of the Chicago meeting for a change from
> > protocol draft -05:
> > 
> >    If it is known that a link is a point to point link between two
> >    RBridges, then the outer header, if it is an Ethernet header, can
> >    have any source and/or destination addresses, those 
> addresses will
> >    be ignored on receipt, and the outer VLAN tag can be omitted.
> > 
> > If no particular controversy arises over this in the next two 
> > weeks, we
> > will declare it to be the working group consensus.
> > 
> > Thanks,
> > Donald & Erik
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Date: Wed, 03 Oct 2007 11:27:42 -0700
From: Joe Touch <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: [email-masked], Caitlin Bestler <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 960

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

Eric Gray wrote:
> Caitlin,
=2E..
>=20
> I get the sense that you're not disagreeing with either Joe or=20
> myself.

I agree with the nuances Caitlin is raising; the conclusion is that this
need not be in the spec, as far as we three appear to agree.

Joe

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

--------------enig494762C0C5C8396E6529941F--

Content-class: urn:content-classes:message
Date: Wed, 3 Oct 2007 14:24:58 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 4647

Hi Eric,

I believe the generally understood meaning of point-to-point is a link
with exactly two devices on it, in this case RBridges.

It is true that one could always do this sort of thing outside the
standards. But in Chicago the working group appeared to believe this was
sufficiently important to say in the standard and, while the consensus
in the room was not that detailed, I got the general impression that
people would be favorable to, in a later management document, having a
MIB variable that would enable one to configure an interface as being
known point-to-point, possibly point-to-point, or prohibited from using
this point-to-point outer address flexibility, or some such management
configuration feature. There also seemed to have been at least some
interest in an automated way of determining that an interface was
point-to-point, perhaps based on the receive of 802.1AB frames all
containing appropriate indications coupled with the receipt of no native
frames.

Point-to-point links are, in fact, very common in modern 802.3 networks.

Donald

-----Original Message-----
From: Eric Gray [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2007 11:11 AM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] Consensus Check: Point to Point links

Donald,

	Given that it is not crystal clear what you mean by 
"point to point link", I am not sure I agree with this, at
least as you have worded it here.

	If you mean that the link is a full-duplex Ethernet
link and the two end-points have some definitive mechansim
for determining that they are the only entities using the
link between them, there may be issues with doing this.

	For example, if the link is technically an Ethernet 
link, then it is not unlikely that one or the other devices 
may have multiple roles - i.e. - it may be both an RBridge 
for some frames and either a regular bridge or end station
(for example, a router) for others.  It's arguable that, in
this case, the multi-role device is two (or more) separate
entities - thus invalidating a "point to point" definition
for this case (though only two distinct physical devices
are connected via this link).

	Without a clear agreement between involved entities,
this sort of "short-cut" addressing is likely to result in
higher-level (slow path) processing of many (if not all) 
of the frames transiting the link for some implementations.
Moreover, without an unambiguous determination of exactly
when this would apply, it will not be unambiguously clear
when a receiving implementation would have to switch to a
"promiscuous listening" mode.

	I believe omission of the outer VLAN tag suffers from
the same ambiguity.  For instance, it is possible for two
devices to have a "point to point" relationship within a 
VLAN context that would nto be the case without the VLAN
context.

	Hence it appears we would have to be explicit in what
we mean by "point to point" link and how we expect that the
entities (RBridges) involved would be able to disambiguate
this p2p status for any given link.

	If we are saying that two devices - using some means 
out of scope for our specification - are somehow aware of an 
unambiguous point-to-point relationship between them and can
therefore use any MAC DA on transmission, and ignore it on
receipt, we could make the same argument for virtually any 
encapsulation choice we might prefer.  But, it would be as
valid to observe that we don't need to specify what is - in
essence - an out-of-context (mis)behavior between consenting 
implementations...

--
Eric Gray
Principal Engineer
Ericsson  

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

Content-class: urn:content-classes:message
Date: Wed, 3 Oct 2007 14:24:26 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1434

That's reasonable. "can be omitted" implies MAY to me.

Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2007 12:41 PM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] Consensus Check: Point to Point links

I'm OK with this as long as the omission of the
outer VLAN tag is a MAY rather than a MUST.

Anoop

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

Content-class: urn:content-classes:message
Date: Wed, 3 Oct 2007 13:22:08 -0500
From: "Eric Gray" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1789

Caitlin,

	Please see one comment below...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]] 
> Sent: Wednesday, October 03, 2007 2:18 PM
> To: Joe Touch; Eric Gray
> Cc: [email-masked]
> Subject: RE: [rbridge] Consensus Check: Point to Point links
> Importance: High
> 
> 
> Joe Touch wrote:
> 
> > I concur with Eric. My concern is why we are defining behavior
> specific
> > to pt-pt links for rbridges when they are not similarly defined for
> > general 802.11 networks.
> 
> > If there is such a definition, we should point to it, but we should
> not
> > create our own. There's no unique need.
> 
> I can imagine several scenarios where there is a truly safe
> point-to-point
> link between two RBridges, and it is indeed safe for them to use a
> custom
> tunneling between them.
> 
> What I don't see is why they need the specification to give them
> permission.
> 
> If that link is *truly* and securely point-to-point they could just as
> easily
> declare themselves to be a single RBridge and said link to be a
> "inter-processor
> bus". When an RBridge is implemented on multiple processors the IETF
> does NOT
> specify the bus that connects them.
> 
> So basically, whenever this sort of optimized encapsulation is valid
> there is
> no need to explicitly state so. If there is a need for the alternate
> encapsulation
> to be officially blessed then it probably means that it isn't 
> safe to do
> it.
> 
> If *nobody* else can see the optimized frames then who is there to
> complain
> that they are non-compliant?

Hence the reference to "consenting implementations" in my earlier
mail.

I get the sense that you're not disagreeing with either Joe or 
myself.

Content-class: urn:content-classes:message
Date: Wed, 3 Oct 2007 14:17:42 -0400
From: "Caitlin Bestler" <[email-masked]>
To: "Joe Touch" <[email-masked]>, "Eric Gray" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1182

Joe Touch wrote:

> I concur with Eric. My concern is why we are defining behavior
specific
> to pt-pt links for rbridges when they are not similarly defined for
> general 802.11 networks.

> If there is such a definition, we should point to it, but we should
not
> create our own. There's no unique need.

I can imagine several scenarios where there is a truly safe
point-to-point
link between two RBridges, and it is indeed safe for them to use a
custom
tunneling between them.

What I don't see is why they need the specification to give them
permission.

If that link is *truly* and securely point-to-point they could just as
easily
declare themselves to be a single RBridge and said link to be a
"inter-processor
bus". When an RBridge is implemented on multiple processors the IETF
does NOT
specify the bus that connects them.

So basically, whenever this sort of optimized encapsulation is valid
there is
no need to explicitly state so. If there is a need for the alternate
encapsulation
to be officially blessed then it probably means that it isn't safe to do
it.

If *nobody* else can see the optimized frames then who is there to
complain
that they are non-compliant?

Date: Wed, 03 Oct 2007 10:16:28 -0700
From: Joe Touch <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1001

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

Donald, et al.,

I concur with Eric. My concern is why we are defining behavior specific
to pt-pt links for rbridges when they are not similarly defined for
general 802.11 networks.

If there is such a definition, we should point to it, but we should not
create our own. There's no unique need.

Joe

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

--------------enig8BCFD82B1C00DE99977AEB41--

Content-class: urn:content-classes:message
Date: Wed, 3 Oct 2007 10:03:43 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Egress processing of unicast not locallyknown
Status: RO
Content-Length: 1598

I'm not sure why the case of "MAC address could
not be on that link" needs to be called out at all.
That is an access control issue.  But I am OK
with having it if someone really feels strongly
about it.

Anoop 

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

Content-class: urn:content-classes:message
Date: Wed, 3 Oct 2007 09:41:13 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 1138

I'm OK with this as long as the omission of the
outer VLAN tag is a MAY rather than a MUST.

Anoop

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

Content-class: urn:content-classes:message
Date: Wed, 3 Oct 2007 10:10:51 -0500
From: "Eric Gray" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 3349

Donald,

	Given that it is not crystal clear what you mean by 
"point to point link", I am not sure I agree with this, at
least as you have worded it here.

	If you mean that the link is a full-duplex Ethernet
link and the two end-points have some definitive mechansim
for determining that they are the only entities using the
link between them, there may be issues with doing this.

	For example, if the link is technically an Ethernet 
link, then it is not unlikely that one or the other devices 
may have multiple roles - i.e. - it may be both an RBridge 
for some frames and either a regular bridge or end station
(for example, a router) for others.  It's arguable that, in
this case, the multi-role device is two (or more) separate
entities - thus invalidating a "point to point" definition
for this case (though only two distinct physical devices
are connected via this link).

	Without a clear agreement between involved entities,
this sort of "short-cut" addressing is likely to result in
higher-level (slow path) processing of many (if not all) 
of the frames transiting the link for some implementations.
Moreover, without an unambiguous determination of exactly
when this would apply, it will not be unambiguously clear
when a receiving implementation would have to switch to a
"promiscuous listening" mode.

	I believe omission of the outer VLAN tag suffers from
the same ambiguity.  For instance, it is possible for two
devices to have a "point to point" relationship within a 
VLAN context that would nto be the case without the VLAN
context.

	Hence it appears we would have to be explicit in what
we mean by "point to point" link and how we expect that the
entities (RBridges) involved would be able to disambiguate
this p2p status for any given link.

	If we are saying that two devices - using some means 
out of scope for our specification - are somehow aware of an 
unambiguous point-to-point relationship between them and can
therefore use any MAC DA on transmission, and ignore it on
receipt, we could make the same argument for virtually any 
encapsulation choice we might prefer.  But, it would be as
valid to observe that we don't need to specify what is - in
essence - an out-of-context (mis)behavior between consenting 
implementations...

--
Eric Gray
Principal Engineer
Ericsson  

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

Content-class: urn:content-classes:message
Date: Tue, 2 Oct 2007 23:26:38 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Check: Point to Point links
Status: RO
Content-Length: 578

This is a check via the mailing list to confirm or refute an apparent
consensus from the minutes of the Chicago meeting for a change from
protocol draft -05:

   If it is known that a link is a point to point link between two
   RBridges, then the outer header, if it is an Ethernet header, can
   have any source and/or destination addresses, those addresses will
   be ignored on receipt, and the outer VLAN tag can be omitted.

If no particular controversy arises over this in the next two weeks, we
will declare it to be the working group consensus.

Thanks,
Donald & Erik

Content-class: urn:content-classes:message
Date: Tue, 2 Oct 2007 23:25:16 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Check: Egress processing of unicast not locally known
Status: RO
Content-Length: 887

This is a check via the mailing list to confirm or refute an apparent
consensus from the minutes of the Chicago meeting for a change from
protocol draft -05:

   Egress RBridges that receive a known unicast TRILL data frame whose
   inner destination address is not known locally should send the
   native form of the frame out on every link for which the RBridge
   is DRB for the frame's VLAN unless it knows that an end station
   with that MAC address could not be on that link. (For example,
   there is a layer-2 registration procedure for end stations on that
   link and the destination MAC address in question is not
   registered.) This is a local decision. No "error" message will be
   defined for this condition at this time.

If no particular controversy arises over this in the next two weeks, we
will declare it to be the working group consensus.

Thanks,
Donald & Erik

Content-class: urn:content-classes:message
Date: Tue, 2 Oct 2007 23:24:30 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Check: Inner Multicast Address of TRILL IS-IS Frames
Status: RO
Content-Length: 461

This is a check via the mailing list to confirm or refute an apparent
consensus from the minutes of the Chicago meeting for a change from
protocol draft -05:

   Utilize a different multicast address ("All-IS-IS-RBridges"),
   allocated to RBridges, as the inner MAC destination address of
   TRILL IS-IS Frames.

If no particular controversy arises over this in the next two weeks, we
will declare it to be the working group consensus.

Thanks,
Donald & Erik

Content-class: urn:content-classes:message
Date: Tue, 2 Oct 2007 23:23:58 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Call: MAC learning timers
Status: RO
Content-Length: 3857

The consensus at the Chicago meeting that the MAC address learning
timers in Rbridges should follow the IEEE 802.1-2005 (Section 8.8.3)
recommendations is confirmed.

Donald & Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Monday, September 17, 2007 1:37 AM
To: Joe Touch; James Carlson
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: MAC learning timers

It's just a recommendation in the IEEE 802.1Q-2005 Standard as quoted
below.

Donald

>From IEEE 802.1Q-2005, Section 8.8.3, "Dynamic Filtering Entries", page
56:

The ageing out of Dynamic Filtering Entries ensures that end stations
that have been moved to a different part of the network will not be
permanently prevented from receiving frames. It also takes account of
changes in the active topology of the network that can cause end
stations to appear to move from the point of view of the bridge; i.e.,
the path to those end stations subsequently lies through a different
Bridge Port.

The Ageing Time may be set by management (Clause 12). A range of
applicable values and a recommended default is specified in Table 8-3;
this is suggested to remove the need for explicit configuration in most
cases. If the value of Ageing Time can be set by management, the Bridge
shall have the capability to use values in the range specified, with a
granularity of 1 s.

              Table 8-3-Ageing time parameter value

    Parameter        Recommended Default Value        Range
   Ageing Time         300.0 s.                     10.0 - 1,000,000.0s

NOTE 4-The granularity is specified in order to establish a common basis
for the granularity expressed in the management operations defined in
Clause 12, not to constrain the granularity of the actual timer
supported by a conformant implementation. If the implementation supports
a granularity other than 1 s, then it is possible that the value read
back by management following a Set operation will not match the actual
value expressed in the Set.

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Friday, September 07, 2007 7:30 PM
To: James Carlson
Cc: Eastlake III Donald-LDE008; [email-masked]
Subject: Re: [rbridge] Consensus Check: MAC learning timers

James Carlson wrote:
> Joe Touch writes:
>> James Carlson wrote:
>>> Instead, our role is to design TRILL, and specify what's _required_
to
>>> make that work.  Is there an issue here that, if someone had a good
>>> reason to use some other set of defaults for these parameters, doing
>>> so would break TRILL?
>> I'm concerned about breaking the non-TRILL devices by TRILL behavior.
If
>> our caches have timeouts different from theirs, then the overall
system
>> won't be as plug-and-play -- or, more specifically, more
'replug-and-play'.
>>
>> That's why we're recommending IEEE values and defaults; that didn't
come
>> out of the blue.
> 
> Yes, and that's precisely the reason to "recommend" those defaults --
> as in BCP 14 "SHOULD."  I never did suggest that they came out of the
> blue or that anyone ought to ignore them.
> 
> However, as a matter of operating TRILL, they don't appear (to me at
> least) to be key issues that will cause TRILL failure.  That means
> they're not a "MUST."

That's fine. Let's hear what others think. I just want to make sure
we're picking the right one and understanding what we're picking; I
really didn't have an a-priori decision.

Joe

-- 
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Tue, 2 Oct 2007 23:18:26 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Call: V-field reversion
Status: RO
Content-Length: 1884

This consensus from the Chicago meeting has been confirmed.

Donald & Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Monday, September 17, 2007 1:37 AM
To: Joe Touch
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: V-field reversion

Right. (I'm generally using the somewhat less formal wording from the
minutes in these consensus checks.)

Thanks,
Donald

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 9:53 AM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: V-field reversion

Eastlake III Donald-LDE008 wrote:
> This is a check via the mailing list to confirm or refute an apparent
> consensus at the Chicago meeting for a change from protocol draft -05:
> 
>    Eliminate different V field values and revert to two version bits
>    and two reserved bits with the previous provisions that this draft
>    specifies version zero, frames with an unknown version are
>    discarded, reserved bits MUST be zero and are ignored on receipt.

Minor nit to avoid ambiguity:

...MUST be _set to_ zero...

> If no particular controversy arises over this in the next two weeks,
we
> will declare it to be the working group consensus.
> 
> Thanks,
> Donald & Erik
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

-- 
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge