[rbridge] RBridge: a case of study
Radia Perlman
Radia.Perlman at sun.com
Wed Oct 31 14:50:36 PDT 2007
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:anoop at brocade.com]
>> 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: rbridge-bounces at postel.org
>>> [mailto:rbridge-bounces at postel.org] 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" <eric.gray at ericsson.com>
>>> To: "Eastlake III Donald-LDE008"
>>> <Donald.Eastlake at motorola.com>, "Zhi-Hern Loh"
>>>
>> <zloh at fulcrummicro.com>
>>
>>> Cc: "Developing a hybrid router/bridge." <rbridge at postel.org>
>>> 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: rbridge-bounces at postel.org
>>>> [mailto:rbridge-bounces at postel.org] 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: rbridge-bounces at postel.org
>>>> [mailto:rbridge-bounces at postel.org] 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" <anoop at brocade.com> wrote:
>>>>
>>>>>> -----Original Message-----
>>>>>> From: rbridge-bounces at postel.org
>>>>>> [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson
>>>>>> Sent: Tuesday, October 30, 2007 2:37 PM
>>>>>> To: Silvano Gai
>>>>>> Cc: Developing a hybrid router/bridge.; Radia.Perlman at Sun.COM
>>>>>> 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
>>>> rbridge at postel.org
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> rbridge at postel.org
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>
>>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> rbridge at postel.org
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>>
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
More information about the rbridge
mailing list