Subject: [rbridge] A question about (R)STP and routing protocol

From: zhaisuping at huawei.com (Suping Zhai)
Date: Thu, 23 Feb 2006 10:40:33 +0800

hi,
I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details.
What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? 
How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? 
Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path?

TIA.

Best Regards,
zhaisuping at huawei.com
Huawei Technologies Co., Ltd.
Tel: +86-10-82836882
Fax: +86-10-82836020
2006-02-23

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 22 Feb 2006 21:15:19 -0800

Suping Zhai,

You are not the first person to ask these questions.
There is a lot of confusion over what is different between RSTP and STP,
and what is different between RSTP and link state routing.
I'll try to explain.

1) What's the difference between RSTP and STP?

RSTP and STP are almost identical, are compatible,
and it would be less confusing to think of RSTP as a different
version of the bridge spec than a different protocol.

RSTP calculates the
same spanning tree, and uses the same algorithm and even
packet formats as STP. Both RSTP and STP calculate a tree of shortest paths
from the Root bridge, which is the bridge with lowest ID/priority.

The major difference between RSTP and STP
is how they avoid temporary loops.
STP did it with a timer. RSTP coordinates between neighbors
to turn on links more quickly after topology changes.

However, in either case, it is impossible to always avoid temporary
loops...the simplest case is when a repeater comes up, or if too many
spanning tree messages get lost due to congestion.

So to summarize, both STP and RSTP use the same basic
algorithm...the heart of algorithm is to calculate a tree
of shortest paths from a single point.
And the resulting tree and data packet
forwarding path is the same in both (because it is the
same algorithm). A single shared loop-free subset
of the physical topology is calculated, upon which data packets are
forwarded.

2) What is the difference between RSTP and IS-IS?

This is harder to answer than the difference between RSTP and STP,
because IS-IS and spanning tree (RSTP/STP) are so very different from
each other. IS-IS passes around topology
information so that every RBridge calculates the shortest path between
itself
and each
destination. With spanning tree (RSTP/STP) each bridge just knows which
subset of its
own ports are "in" or "out" of the spanning tree. If a link is not in
the spanning tree,
then it cannot be used, even if it is the shortest path between point A
and B, and
pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated
on the links in the spanning tree, because no traffic can be on links
not in the
spanning tree.

Also spanning tree bridges learn, based on
seeing data traffic, which
direction the source is. (which of its own local ports lead to the
source of
the data packet). So packets must always arrive from a particular source
from
the same direction or else bridges will get confused. In contrast, with
IS-IS,
switches can do path splitting; using multiple paths to reach a destination.

3) What is difference between RSTP and RBridge approach?

RBridge incorporates
a TTL into the header of forwarded data packets so a temporary loop is
not really bad, so it need not
be very conservative about avoiding loops. Also,
a link state protocol (IS-IS) calculates shortest
pair-wise paths. Also, it can calculate multiple paths to the
destination, and do path splitting.

4) What is the difference between recent work in IEEE to calculate
per-ingress trees, and RBridge approach?

IEEE may indeed wind up doing the same thing as RBridge. Several years
before TRILL I tried to get IEEE interested in doing this approach,
but they were not interested, perhaps because I didn't explain it
well enough. Now that work has started in IETF, I think it is possible
that IEEE will converge on the same solution, which would actually
be good for the industry.

Radia

Suping Zhai wrote:

>------------------------------------------------------------------------
>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Thu, 23 Feb 2006 10:40:02 +0100

Let me give my opinions interleaved.
By the way, as the Abridges draft we submitted last december is 
somewhere between the current RBridges proposal and the IEEE Shortest 
Path Bridging, we think it would help clarify to obtain comments to our 
draft from the RBridges WG members.
Regards
Guillermo Ibanez

http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt

Guillermo Ibanez

>switches can do path splitting; using multiple paths to reach a destination.
It is important to remember that the standard convergence times of RSTP 
are lower than those of routing protocols, unless specific measures for 
milliseconds convergence are applied.

>destination, and do path splitting.
Both IEEE Shortest Path Bridging and the Abridges draft proposal ( see
http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt)
obtain shortest paths. They do not allow  path splitting, but are less 
complex than IS-IS
and do not mix STP and IS-IS protocols in same area.

>be good for the industry.
I do not see an easy convergence between IEEE and RBridge proposals 
unless the two groups cooperate strongly.
IEEE will likely preserve basic RSTP mechanisms (fast convergence and 
distance vector to (multiple) root bridges) with multiple spanning trees 
(this is my guess, I do not follow their recent activities), while 
RBridge uses IS-IS (link state mechanisms) as basic protocol.

Guillermo Ibanez

-- 
Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid
1.1.B.11 Colmenarejo 91-6241393
4.1.F.13 Legan?s 91-6248794

---

From: robey at huawei.com (robey)
Date: Sat, 25 Feb 2006 11:52:47 +0800

Hi,Guillermo Ibanez,

I have read through your Abridge draft, and think it provider a simpler method to achieve shortest path bridges .
In terms of approaches presented in Abridge draft, when packets of one specific traffic destined to same destination arrived at edge bridge, if these packets are kind of unknown packets, they will be broadcasted on ingress tree, then  after learing  unicast path FDB entry for the flow, packets of the traffic will be forwarded on the engress tree, in this case it is possible to bring about misorder of frames related to the traffic.How can you solve this problem?

Maybe we can create symmetric tree, and still consider using ingress tree to forward broadcast/multicast/unknown packets and using egress tree to forward unicast packets,  in this way not only can it overcome the above problem ,but also have a simpler method to create FDB entries and can avoid address learning (except foraddresses of end nodes) which can reduce traffic flooding when topology changes.

Best regards

robey

From: "Guillermo Ib??ez" <gibanez at it.uc3m.es>
To: "Developing a hybrid router/bridge." <rbridge at postel.org>
Sent: Thursday, February 23, 2006 5:40 PM
Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Tue, 28 Feb 2006 12:33:59 +0100

Hi Robey,

          Many thanks for your feedback on the Abridges draft.
While preparing the response  I have seen the mail from Eric Gray. I 
agree with him and I think it applies as well to Abridges. The 
disordering is equally  very unlikely  by the same reasons and some 
additional for Abridges.
          Forcing the trees to be symmetric may solve the problem, but 
the only solution that I know with spanning trees protocols to ensure 
symmetric trees (N. Finn, cut vectors) increases the convergence time of 
the trees and limits the core to 64 bridges maximum. IS-IS is better to 
ensure symmetric trees but to obtain same convergence speed as RSTP 
based protocols is a pending task, as far as I know.
        Broadcasts in the Abridges scenario are rather unfrequent. 
Abridges do not use MAC learning.  Abridges are targetted to big size 
campus networks, where broadcasts should be very limited. So the  
mechanism proposed in the draft is to avoid addresses learning of all 
hosts in the network (it does not scale) and use ARP/Abridge  Servers, 
to perform the ARP resolution and to obtain the destination Abridge for 
destination host. Hosts (pairs host-Abridge) are previously registered 
upon detection by its designated Abridge.  Even the forwarding between 
Abridges is not based in MAC learning, but in forwarding via root port 
of the tree of every Abridge. By using the servers, broadcasts are 
reduced only to a backup mechanism role in the case of ARP or other 
services using broadcast.
        As the origin of the (potential but unlikely) problem is to use 
different tree in broadcast of unknown hosts versus unicast, a remedy, 
although not very efficient, is to replace broadcast by repeated unicast 
to all ARB egress bridges via all root ports of the ingress Abridge.  
In  fact, The "all Abridges"  multicast address might be used instead of 
the broadcast address for this functionality.  This would be a different 
way of performing broadcasts among Abridges in the campus/enterprise core.
Regards
Guillermo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gibanez.vcf
Type: text/x-vcard
Size: 424 bytes
Desc: not available
Url : http://www.postel.org/pipermail/rbridge/attachments/20060228/2a39ef45/gibanez.vcf

---

From: robey at huawei.com (robey)
Date: Wed, 01 Mar 2006 11:55:22 +0800

Hi,Guillermo,

I agree that the present solution of symmetic tree protocol developed by IEEE will limit the the core to 64 bridges maximum, so the symmetic tree protocol  has to be improved further.
I think Abridges draft providers simpler approach to implement shortest bridges, and misorder of frames can be avoided by the mechanisms as you presented in your mail, so it is deserved to study and promote the related work of Abridges.

Best regards

Robey

----- Original Message ----- 
From: "Guillermo Ib??ez" <gibanez at it.uc3m.es>
To: "Developing a hybrid router/bridge." <rbridge at postel.org>
Sent: Tuesday, February 28, 2006 7:33 PM
Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft

>>>>>Huawei Technologies Co., Ltd.

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

Date: Wed, 01 Mar 2006 11:55:22 +0800
From: robey <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 11788

Hi,Guillermo,

I agree that the present solution of symmetic tree protocol developed by IEEE will limit the the core to 64 bridges maximum, so the symmetic tree protocol  has to be improved further.
I think Abridges draft providers simpler approach to implement shortest bridges, and misorder of frames can be avoided by the mechanisms as you presented in your mail, so it is deserved to study and promote the related work of Abridges.

Best regards

Robey

----- Original Message ----- 
From: "Guillermo Ibáñez" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Sent: Tuesday, February 28, 2006 7:33 PM
Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft

>>From: "Guillermo Ibáñez" <[email-masked]>
>>To: "Developing a hybrid router/bridge." <[email-masked]>
>>>>>[email-masked]
>>>>>[email-masked]
>>>>[email-masked]
>>>Guillermo Ibáñez
>>>Departamento de Ingeniería Telemática
>>>4.1.F.13 Leganés 91-6248794
>>>
>>>[email-masked]
>>[email-masked]

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

> [email-masked]

Date: Wed, 01 Mar 2006 09:35:34 +0800
From: Suping Zhai <[email-masked]>
To: =?GB2312?Q?Guillermo Ib=A8=A2?ez?= <[email-masked]>, "[email-masked]" <[email-masked]>
Organization: huawei
Subject: Re: [rbridge] Additioanla clarification Abridges port types Re: A questionabout (R)STP and routing protocol / requestfor comments to Abridges draft
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 8793

Hi Guillermo,
Thank you for your help and clarification.
As far as now, I think this approach is the relative simple solution for the shortest bridge, but need further speculation and verification. I will present my ideas if any question wrt this solution.

Regards,
Suping
>Hi Suping,
>   Just a clarification. Abridges have core ports (those connected to 
>other Abridges) and distribution ports (those connected to standard 
>bridges). Core ports run AMSTP protocol and distribution ports run RSTP 
>or STP protocol. The ports selfconfigure as core or distribution ports 
>according to the standard protocol migration procedure 802.1D (i.e. 
>depending on the protocol type of STP BPDUs they hear from neighbour).
>Distribution ports are standard ports regarding learning. Specific 
>operation corresponds to core ports.
>Regards
>Guillermo
> 
>Suping Zhai wrote:
>
>>Hi Guillermo,
>>Thank you for your response. After I have gone through the following draft, there are some doubts wrt the following aspects,
>>1) what's the orientation wrt the basic RSTP instance in the core Abrige network?  What I understand is per-Abridge RSTP is enough for the forwarding and there is no need for the aforementioned basic RSTP instance.
>>
>>2) In 4.3.2 it says that Abridge may learn from the received frames both outer MAC and inter MAC address, called the double MAC adress learning. On the other hand, when talk about the symmetric spanning tree problem in section 4.8 and 6.2, it says that Abridges don't learn addresses. So which is the right one or I missed some points?
>>
>>Regards
>>Suping  
>>  
>>
>>>>>[email-masked]
>>>>>[email-masked]
>>>>[email-masked]
>>>Guillermo Ib???ez
>>>Departamento de Ingenier??a Telem??tica
>>>4.1.F.13 Legan??s 91-6248794
>>>
>>>[email-masked]

Date: Tue, 28 Feb 2006 16:32:19 +0100
From: =?UTF-8?B?R3VpbGxlcm1vIEliw6HDsWV6?= <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: [rbridge] Additioanla clarification Abridges port types Re: A question about (R)STP and routing protocol / requestfor comments to Abridges draft
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 9263

This is a multi-part message in MIME format.
--------------050904090305040305080102
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Suping,
   Just a clarification. Abridges have core ports (those connected to 
other Abridges) and distribution ports (those connected to standard 
bridges). Core ports run AMSTP protocol and distribution ports run RSTP 
or STP protocol. The ports selfconfigure as core or distribution ports 
according to the standard protocol migration procedure 802.1D (i.e. 
depending on the protocol type of STP BPDUs they hear from neighbour).
Distribution ports are standard ports regarding learning. Specific 
operation corresponds to core ports.
Regards
Guillermo
 
Suping Zhai wrote:

>Hi Guillermo,
>Thank you for your response. After I have gone through the following draft, there are some doubts wrt the following aspects,
>1) what's the orientation wrt the basic RSTP instance in the core Abrige network?  What I understand is per-Abridge RSTP is enough for the forwarding and there is no need for the aforementioned basic RSTP instance.
>
>2) In 4.3.2 it says that Abridge may learn from the received frames both outer MAC and inter MAC address, called the double MAC adress learning. On the other hand, when talk about the symmetric spanning tree problem in section 4.8 and 6.2, it says that Abridges don't learn addresses. So which is the right one or I missed some points?
>
>Regards
>Suping  
>  
>
>>>>[email-masked]
>>>>[email-masked]
>>>[email-masked]
>>Guillermo Ibá?ez
>>Departamento de Ingeniería Telemática
>>4.1.F.13 Leganés 91-6248794
>>
>>[email-masked]

--------------050904090305040305080102
Content-Type: text/x-vcard; charset=utf-8;
 name="gibanez.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="gibanez.vcf"

YmVnaW46dmNhcmQNCmZuO3F1b3RlZC1wcmludGFibGU6R3VpbGxlcm1vIEEuIEliPUMzPUEx
PUMzPUIxZXoNCm47cXVvdGVkLXByaW50YWJsZTpJYj1DMz1BMT1DMz1CMWV6O0d1aWxsZXJt
byBBLg0Kb3JnOlVuaXZlcnNpZGFkIENhcmxvcyBJSUkgTWFkcmlkO0luZ2VuaWVyaWEgVGVs
ZW1hdGljYQ0KYWRyO3F1b3RlZC1wcmludGFibGU6Ozs7TGVnYW49QzM9QTlzO01hZHJpZDsy
ODkxMTtTcGFpbg0KZW1haWw7aW50ZXJuZXQ6Z2liYW5lekBpdC51YzNtLmVzDQp0aXRsZTpQ
cm9mLiBEci4NCnRlbDt3b3JrOjM0IDkxIDYyNDEzNDMNCnRlbDtmYXg6MzQgNjI0ODc0OQ0K
eC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpodHRwOi8vZW5qYW1icmUuaXQudWMzbS5lcy9+
Z2liYW5lei9pbmRpY2UuaHRtbA0KdmVyc2lvbjoyLjENCmVuZDp2Y2FyZA0KDQo=
--------------050904090305040305080102--

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 28 Feb 2006 08:22:53 -0500
Subject: Re: [rbridge] A question about (R)STP and routing protocol /	requ		est for comments to Abridges draft
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 13404

Robey,

	Great, thanks for the clarification!

--
Eric 

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of robey
--> Sent: Monday, February 27, 2006 8:48 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] A question about (R)STP and routing 
--> protocol / requ est for comments to Abridges draft
--> 
--> Hi,Eric,
--> 
--> Thank for your comments first.
--> I agree with your opinion that the likelihood of frame 
--> misorder is not big.
--> Otherwise, about your question of "How does use of 
--> symmetric trees impact on out of order delivery?", I can 
--> say if symmetric trees is used ,the path destined to one 
--> destination before obtaining  unicast FDB entries for that 
--> destination and the path destined to same destination after 
--> obtaining FDB entries  through source address learning will 
--> be same,so no misorder of frames occur.
--> 
--> Best regards
--> 
--> Robey
--> 
--> ----- Original Message ----- 
--> From: "Gray, Eric" <[email-masked]>
--> To: "'Developing a hybrid router/bridge.'" <[email-masked]>
--> Sent: Tuesday, February 28, 2006 3:43 AM
--> Subject: Re: [rbridge] A question about (R)STP and routing 
--> protocol / requ est for comments to Abridges draft
--> 
--> 
--> Robey,
--> 
--> I can't answer for Guilllermo's draft, but I can answer
--> for (or comment on) the general case addressed by documents 
--> already chartered for the WG.  Please see below... 
--> 
--> --> -----Original Message-----
--> --> From: [email-masked] 
--> --> [mailto:[email-masked]] On Behalf Of robey
--> --> Sent: Friday, February 24, 2006 10:53 PM
--> --> To: Developing a hybrid router/bridge.
--> --> Subject: Re: [rbridge] A question about (R)STP and routing 
--> --> protocol / request for comments to Abridges draft
--> --> 
--> --> Hi,Guillermo Ibanez,
--> --> 
--> --> I have read through your Abridge draft, and think it 
--> --> provider a simpler method to achieve shortest path bridges .
--> --> In terms of approaches presented in Abridge draft, when 
--> --> packets of one specific traffic destined to same 
--> --> destination arrived at edge bridge, if these packets are 
--> --> kind of unknown packets, they will be broadcasted on 
--> --> ingress tree, then  after learing  unicast path FDB entry 
--> --> for the flow, packets of the traffic will be forwarded on 
--> --> the engress tree, in this case it is possible to bring 
--> --> about misorder of frames related to the traffic.
--> -->
--> --> How can you solve this problem?
--> 
--> Realistically speaking, several potential behaviors are not
--> very likely.
--> 
--> One example is the scenario where a lot of frames are sent
--> to a host that has not yet been discovered on the network.
--> 
--> Even in the case where this may occur, the degree to which
--> small scale out of order delivery is pathological behavior
--> with today's higher-level protocols is very small.
--> 
--> Finally, because the ultimate unicast delivery path will be
--> along the shortest path, the window of opportunity that may
--> result in actual out of order delivery, in transition from
--> flooding to simple delivery, is very small (especially if 
--> the traffic stream is a small fraction of link capacity).
--> 
--> --> 
--> --> Maybe we can create symmetric tree, and still consider 
--> --> using ingress tree to forward broadcast/multicast/unknown 
--> --> packets and using egress tree to forward unicast packets,  
--> --> in this way not only can it overcome the above problem ,but 
--> --> also have a simpler method to create FDB entries and can 
--> --> avoid address learning (except foraddresses of end nodes) 
--> --> which can reduce traffic flooding when topology changes.
--> 
--> How does use of symmetric trees impact on out of order delivery?
--> 
--> --> 
--> --> Best regards
--> --> 
--> --> robey
--> --> 
--> --> 
--> --> 
--> --> 
--> --> From: "Guillermo Ib??ez" <[email-masked]>
--> --> To: "Developing a hybrid router/bridge." <[email-masked]>
--> --> Sent: Thursday, February 23, 2006 5:40 PM
--> --> Subject: Re: [rbridge] A question about (R)STP and routing 
--> --> protocol / request for comments to Abridges draft
--> --> 
--> --> 
--> --> > Let me give my opinions interleaved.
--> --> > By the way, as the Abridges draft we submitted last 
--> december is 
--> --> > somewhere between the current RBridges proposal and the 
--> --> IEEE Shortest 
--> --> > Path Bridging, we think it would help clarify to obtain 
--> --> comments to our 
--> --> > draft from the RBridges WG members.
--> --> > Regards
--> --> > Guillermo Ibanez
--> --> > 
--> --> > 
--> --> > 
--> --> http://www.ietf.org/internet-drafts/draft-gibanez-trill-abri
--> --> dge-00.txt
--> --> > 
--> --> > Guillermo Ibanez
--> --> > 
--> --> > 
--> --> > Radia Perlman wrote:
--> --> > 
--> --> >>Suping Zhai,
--> --> >>
--> --> >>You are not the first person to ask these questions.
--> --> >>There is a lot of confusion over what is different 
--> --> between RSTP and STP,
--> --> >>and what is different between RSTP and link state routing.
--> --> >>I'll try to explain.
--> --> >>
--> --> >>1) What's the difference between RSTP and STP?
--> --> >>
--> --> >>RSTP and STP are almost identical, are compatible,
--> --> >>and it would be less confusing to think of RSTP as a different
--> --> >>version of the bridge spec than a different protocol.
--> --> >>
--> --> >>RSTP calculates the
--> --> >>same spanning tree, and uses the same algorithm and even
--> --> >>packet formats as STP. Both RSTP and STP calculate a tree 
--> --> of shortest paths
--> --> >>from the Root bridge, which is the bridge with lowest 
--> ID/priority.
--> --> >>
--> --> >>The major difference between RSTP and STP
--> --> >>is how they avoid temporary loops.
--> --> >>STP did it with a timer. RSTP coordinates between neighbors
--> --> >>to turn on links more quickly after topology changes.
--> --> >>
--> --> >>However, in either case, it is impossible to always avoid 
--> --> temporary
--> --> >>loops...the simplest case is when a repeater comes up, or 
--> --> if too many
--> --> >>spanning tree messages get lost due to congestion.
--> --> >>
--> --> >>So to summarize, both STP and RSTP use the same basic
--> --> >>algorithm...the heart of algorithm is to calculate a tree
--> --> >>of shortest paths from a single point.
--> --> >>And the resulting tree and data packet
--> --> >>forwarding path is the same in both (because it is the
--> --> >>same algorithm). A single shared loop-free subset
--> --> >>of the physical topology is calculated, upon which data 
--> --> packets are
--> --> >>forwarded.
--> --> >>
--> --> >>  
--> --> >>
--> --> >>2) What is the difference between RSTP and IS-IS?
--> --> >>
--> --> >>This is harder to answer than the difference between 
--> RSTP and STP,
--> --> >>because IS-IS and spanning tree (RSTP/STP) are so very 
--> --> different from
--> --> >>each other. IS-IS passes around topology
--> --> >>information so that every RBridge calculates the shortest 
--> --> path between
--> --> >>itself
--> --> >>and each
--> --> >>destination. With spanning tree (RSTP/STP) each bridge 
--> --> just knows which
--> --> >>subset of its
--> --> >>own ports are "in" or "out" of the spanning tree. If a 
--> --> link is not in
--> --> >>the spanning tree,
--> --> >>then it cannot be used, even if it is the shortest path 
--> --> between point A
--> --> >>and B, and
--> --> >>pairwise paths can be quite suboptimal. Furthermore, 
--> --> traffic is concentrated
--> --> >>on the links in the spanning tree, because no traffic can 
--> --> be on links
--> --> >>not in the
--> --> >>spanning tree.
--> --> >>
--> --> >>Also spanning tree bridges learn, based on
--> --> >>seeing data traffic, which
--> --> >>direction the source is. (which of its own local 
--> ports lead to the
--> --> >>source of
--> --> >>the data packet). So packets must always arrive from a 
--> --> particular source
--> --> >>from
--> --> >>the same direction or else bridges will get confused. In 
--> --> contrast, with
--> --> >>IS-IS,
--> --> >>switches can do path splitting; using multiple paths to 
--> --> reach a destination.
--> --> >>
--> --> >>  
--> --> >>
--> --> > It is important to remember that the standard convergence 
--> --> times of RSTP 
--> --> > are lower than those of routing protocols, unless 
--> --> specific measures for 
--> --> > milliseconds convergence are applied.
--> --> > 
--> --> >>3) What is difference between RSTP and RBridge approach?
--> --> >>
--> --> >>RBridge incorporates
--> --> >>a TTL into the header of forwarded data packets so a 
--> --> temporary loop is
--> --> >>not really bad, so it need not
--> --> >>be very conservative about avoiding loops. Also,
--> --> >>a link state protocol (IS-IS) calculates shortest
--> --> >>pair-wise paths. Also, it can calculate multiple paths to the
--> --> >>destination, and do path splitting.
--> --> >>  
--> --> >>
--> --> > Both IEEE Shortest Path Bridging and the Abridges draft 
--> --> proposal ( see
--> --> > 
--> --> http://www.ietf.org/internet-drafts/draft-gibanez-trill-abri
--> --> dge-00.txt)
--> --> > obtain shortest paths. They do not allow  path splitting, 
--> --> but are less 
--> --> > complex than IS-IS
--> --> > and do not mix STP and IS-IS protocols in same area.
--> --> > 
--> --> >>4) What is the difference between recent work in IEEE 
--> to calculate
--> --> >>per-ingress trees, and RBridge approach?
--> --> >>
--> --> >>IEEE may indeed wind up doing the same thing as RBridge. 
--> --> Several years
--> --> >>before TRILL I tried to get IEEE interested in doing this 
--> --> approach,
--> --> >>but they were not interested, perhaps because I 
--> didn't explain it
--> --> >>well enough. Now that work has started in IETF, I think 
--> --> it is possible
--> --> >>that IEEE will converge on the same solution, which 
--> would actually
--> --> >>be good for the industry.
--> --> >>Radia
--> --> >>  
--> --> >>
--> --> > I do not see an easy convergence between IEEE and RBridge 
--> --> proposals 
--> --> > unless the two groups cooperate strongly.
--> --> > IEEE will likely preserve basic RSTP mechanisms (fast 
--> --> convergence and 
--> --> > distance vector to (multiple) root bridges) with multiple 
--> --> spanning trees 
--> --> > (this is my guess, I do not follow their recent 
--> --> activities), while 
--> --> > RBridge uses IS-IS (link state mechanisms) as basic protocol.
--> --> > 
--> --> > 
--> --> > Guillermo Ibanez
--> --> > 
--> --> >>Suping Zhai wrote:
--> --> >>
--> --> >>  
--> --> >>
--> --> >>>hi,
--> --> >>>I am confronted with some questions when reading the 
--> --> Rbridge protocol related draft and hope someone can help me 
--> --> with details.
--> --> >>>What's the essential difference between (R)STP and 
--> --> routing protocol(e.g. IS-IS)? 
--> --> >>>How dose the routing protocol(e.g. IS-IS) can optimize 
--> --> the routing path while (R)STP can't? 
--> --> >>>Can we optimize the (R)STP protocol itself to reach that 
--> --> goal? If that's the case, then I think that all RBridge WG 
--> --> works can be substituted. And I have seen some work been 
--> --> done in IEEE802.1aq which is on the way to the per bridge 
--> --> MSTP road. But what I imagine is that should we get a 
--> --> comparable simple and untangled solution for the bridge 
--> --> network routing path?
--> --> >>>
--> --> >>>TIA.
--> --> >>>
--> --> >>>Best Regards,
--> --> >>>[email-masked]
--> --> >>>Huawei Technologies Co., Ltd.
--> --> >>>Tel: +86-10-82836882
--> --> >>>Fax: +86-10-82836020
--> --> >>>2006-02-23
--> --> >>>
--> --> >>>
--> --> >>>
--> --> >>>
--> --> >>>
--> --> >>> 
--> --> >>>
--> --> >>>---------------------------------------------------------
--> --> ---------------
--> --> >>>
--> --> >>>_______________________________________________
--> --> >>>rbridge mailing list
--> --> >>>[email-masked]
--> --> >>>http://www.postel.org/mailman/listinfo/rbridge
--> --> >>> 
--> --> >>>
--> --> >>>    
--> --> >>>
--> --> >>
--> --> >>  
--> --> >>
--> --> >>----------------------------------------------------------
--> --> --------------
--> --> >>
--> --> >>_______________________________________________
--> --> >>rbridge mailing list
--> --> >>[email-masked]
--> --> >>http://www.postel.org/mailman/listinfo/rbridge
--> --> >>  
--> --> >>
--> --> > 
--> --> > -- 
--> --> > Guillermo Ib??ez
--> --> > Departamento de Ingenier?a Telem?tica
--> --> > Universidad Carlos III de Madrid
--> --> > 1.1.B.11 Colmenarejo 91-6241393
--> --> > 4.1.F.13 Legan?s 91-6248794
--> --> > 
--> --> > _______________________________________________
--> --> > rbridge mailing list
--> --> > [email-masked]
--> --> > http://www.postel.org/mailman/listinfo/rbridge
--> --> >
--> --> _______________________________________________
--> --> rbridge mailing list
--> --> [email-masked]
--> --> http://www.postel.org/mailman/listinfo/rbridge
--> --> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Tue, 28 Feb 2006 13:23:02 +0100
From: =?UTF-8?B?R3VpbGxlcm1vIEliw6HDsWV6?= <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [rbridge] A question about (R)STP and routing protocol / requestfor comments to Abridges draft
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 9371

This is a multi-part message in MIME format.
--------------060501020909010303030807
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Abridges, as Rbridges are targetted to campus/enterprise networks, so 
different service providers are not contemplated.
VLAN discrimination is optional, but we have to choose between 
selfconfiguration (one of the main objectives of Rbridges and Abridges) 
and features. The main issue with VLANs is that they require careful 
planning and configuration of their tree instances. In the campus 
network core, the single shortest path forwarding among Abridges ensures 
confidentiality by preventing traffic broadcasts. VLANs are suited at 
lower (access) level, provided that the configuration is automatic 
enough. The VLAN tag can be transported end to end inside the 
encapsulated frame.
The only logical use I see for VLANs in the campus core is to link VLAN 
ID to the per-destination tree, as it is done in different ways in 
Global Open Ethernet and Shortest Path Bridging. I do not know how VLANs 
are assigned (manually, automatically) in these cases. It should be 
fully automatic, selfconfiguring.

Suping Zhai wrote:

>Hi Guillermo,
>Still another observation wrt the following draft.
>If in the core Abridge there is no VLAN discrimination, so are there any security issues or application complex implications? What I concern is that the Abridges in the core belong to different service provider or something like that, if the VLAN domain a good way to control the access?
>
>Regards,
>Suping
>  
>
>>>>[email-masked]
>>>>[email-masked]
>>>[email-masked]
>>Guillermo Ibá?ez
>>Departamento de Ingeniería Telemática
>>4.1.F.13 Leganés 91-6248794
>>
>>[email-masked]

--------------060501020909010303030807
Content-Type: text/x-vcard; charset=utf-8;
 name="gibanez.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="gibanez.vcf"

YmVnaW46dmNhcmQNCmZuO3F1b3RlZC1wcmludGFibGU6R3VpbGxlcm1vIEEuIEliPUMzPUEx
PUMzPUIxZXoNCm47cXVvdGVkLXByaW50YWJsZTpJYj1DMz1BMT1DMz1CMWV6O0d1aWxsZXJt
byBBLg0Kb3JnOlVuaXZlcnNpZGFkIENhcmxvcyBJSUkgTWFkcmlkO0luZ2VuaWVyaWEgVGVs
ZW1hdGljYQ0KYWRyO3F1b3RlZC1wcmludGFibGU6Ozs7TGVnYW49QzM9QTlzO01hZHJpZDsy
ODkxMTtTcGFpbg0KZW1haWw7aW50ZXJuZXQ6Z2liYW5lekBpdC51YzNtLmVzDQp0aXRsZTpQ
cm9mLiBEci4NCnRlbDt3b3JrOjM0IDkxIDYyNDEzNDMNCnRlbDtmYXg6MzQgNjI0ODc0OQ0K
eC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpodHRwOi8vZW5qYW1icmUuaXQudWMzbS5lcy9+
Z2liYW5lei9pbmRpY2UuaHRtbA0KdmVyc2lvbjoyLjENCmVuZDp2Y2FyZA0KDQo=
--------------060501020909010303030807--

Date: Tue, 28 Feb 2006 12:43:36 +0100
From: =?UTF-8?B?R3VpbGxlcm1vIEliw6HDsWV6?= <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [rbridge] A question about (R)STP and routing protocol / requestfor comments to Abridges draft
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 9410

This is a multi-part message in MIME format.
--------------010706030603050708040502
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Suping,
    Please find my answers interleaved.
Regards
Guillermo Ibañez

Suping Zhai wrote:

>Hi Guillermo,
>Thank you for your response. After I have gone through the following draft, there are some doubts wrt the following aspects,
>1) what's the orientation wrt the basic RSTP instance in the core Abrige network?  What I understand is per-Abridge RSTP is enough for the forwarding and there is no need for the aforementioned basic RSTP instance.
>
>  
>
There are two alternatives. The most traditional is to use a basic RSTP 
instance and a combined BPDU where the m-records of all tree instances 
are included. The most radical is to use fully independent RSTP instances.

>2) In 4.3.2 it says that Abridge may learn from the received frames both outer MAC and inter MAC address, called the double MAC adress learning. On the other hand, when talk about the symmetric spanning tree problem in section 4.8 and 6.2, it says that Abridges don't learn addresses. So which is the right one or I missed some points?
>
>  
>
The double MAC learning refers to learning the association of host to 
its Abridge  from inspecting in the double layer 2 encapsulated the 
pairs host origin-Abridge origin host destination-Abridge destination, 
to later resolve the destination Abridge from the destination host. 
Double MAC learning is only advisable in networks  with a moderate 
number of hosts like metropolitan backbones.

>Suping  
>>>>[email-masked]
>>>>[email-masked]
>>>[email-masked]
>>Guillermo Ibá?ez
>>Departamento de Ingeniería Telemática
>>4.1.F.13 Leganés 91-6248794
>>
>>[email-masked]

--------------010706030603050708040502
Content-Type: text/x-vcard; charset=utf-8;
 name="gibanez.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="gibanez.vcf"

YmVnaW46dmNhcmQNCmZuO3F1b3RlZC1wcmludGFibGU6R3VpbGxlcm1vIEEuIEliPUMzPUEx
PUMzPUIxZXoNCm47cXVvdGVkLXByaW50YWJsZTpJYj1DMz1BMT1DMz1CMWV6O0d1aWxsZXJt
byBBLg0Kb3JnOlVuaXZlcnNpZGFkIENhcmxvcyBJSUkgTWFkcmlkO0luZ2VuaWVyaWEgVGVs
ZW1hdGljYQ0KYWRyO3F1b3RlZC1wcmludGFibGU6Ozs7TGVnYW49QzM9QTlzO01hZHJpZDsy
ODkxMTtTcGFpbg0KZW1haWw7aW50ZXJuZXQ6Z2liYW5lekBpdC51YzNtLmVzDQp0aXRsZTpQ
cm9mLiBEci4NCnRlbDt3b3JrOjM0IDkxIDYyNDEzNDMNCnRlbDtmYXg6MzQgNjI0ODc0OQ0K
eC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpodHRwOi8vZW5qYW1icmUuaXQudWMzbS5lcy9+
Z2liYW5lei9pbmRpY2UuaHRtbA0KdmVyc2lvbjoyLjENCmVuZDp2Y2FyZA0KDQo=
--------------010706030603050708040502--

Date: Tue, 28 Feb 2006 12:33:59 +0100
From: =?UTF-8?B?R3VpbGxlcm1vIEliw6HDsWV6?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 11478

This is a multi-part message in MIME format.
--------------060802050809020202040009
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Robey,

robey wrote:

>From: "Guillermo Ibáñez" <[email-masked]>
>To: "Developing a hybrid router/bridge." <[email-masked]>
>>>>[email-masked]
>>>>[email-masked]
>>>[email-masked]
>>Guillermo Ibáñez
>>Departamento de Ingeniería Telemática
>>4.1.F.13 Leganés 91-6248794
>>
>>[email-masked]
>[email-masked]

--------------060802050809020202040009
Content-Type: text/x-vcard; charset=utf-8;
 name="gibanez.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="gibanez.vcf"

YmVnaW46dmNhcmQNCmZuO3F1b3RlZC1wcmludGFibGU6R3VpbGxlcm1vIEEuIEliPUMzPUEx
PUMzPUIxZXoNCm47cXVvdGVkLXByaW50YWJsZTpJYj1DMz1BMT1DMz1CMWV6O0d1aWxsZXJt
byBBLg0Kb3JnOlVuaXZlcnNpZGFkIENhcmxvcyBJSUkgTWFkcmlkO0luZ2VuaWVyaWEgVGVs
ZW1hdGljYQ0KYWRyO3F1b3RlZC1wcmludGFibGU6Ozs7TGVnYW49QzM9QTlzO01hZHJpZDsy
ODkxMTtTcGFpbg0KZW1haWw7aW50ZXJuZXQ6Z2liYW5lekBpdC51YzNtLmVzDQp0aXRsZTpQ
cm9mLiBEci4NCnRlbDt3b3JrOjM0IDkxIDYyNDEzNDMNCnRlbDtmYXg6MzQgNjI0ODc0OQ0K
eC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpodHRwOi8vZW5qYW1icmUuaXQudWMzbS5lcy9+
Z2liYW5lei9pbmRpY2UuaHRtbA0KdmVyc2lvbjoyLjENCmVuZDp2Y2FyZA0KDQo=
--------------060802050809020202040009--

Date: Tue, 28 Feb 2006 11:36:27 +0800
From: Suping Zhai <[email-masked]>
To: =?GB2312?Q?Guillermo Ib=A8=A2?ez?= <[email-masked]>, "[email-masked]" <[email-masked]>
Organization: huawei
Subject: Re: [rbridge] A question about (R)STP and routing protocol / requestfor comments to Abridges draft
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 7347

Hi Guillermo,
Thank you for your response. After I have gone through the following draft, there are some doubts wrt the following aspects,
1) what's the orientation wrt the basic RSTP instance in the core Abrige network?  What I understand is per-Abridge RSTP is enough for the forwarding and there is no need for the aforementioned basic RSTP instance.

2) In 4.3.2 it says that Abridge may learn from the received frames both outer MAC and inter MAC address, called the double MAC adress learning. On the other hand, when talk about the symmetric spanning tree problem in section 4.8 and 6.2, it says that Abridges don't learn addresses. So which is the right one or I missed some points?

Regards
Suping  
>>>[email-masked]
>>>[email-masked]
>>[email-masked]
>Guillermo Ib???ez
>Departamento de Ingenier??a Telem??tica
>4.1.F.13 Legan??s 91-6248794
>
>[email-masked]

Date: Tue, 28 Feb 2006 11:43:31 +0800
From: Suping Zhai <[email-masked]>
To: =?GB2312?Q?Guillermo Ib=A8=A2?ez?= <[email-masked]>, "[email-masked]" <[email-masked]>
Organization: huawei
Subject: Re: [rbridge] A question about (R)STP and routing protocol / requestfor comments to Abridges draft
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 7008

Hi Guillermo,
Still another observation wrt the following draft.
If in the core Abridge there is no VLAN discrimination, so are there any security issues or application complex implications? What I concern is that the Abridges in the core belong to different service provider or something like that, if the VLAN domain a good way to control the access?

Regards,
Suping
>>>[email-masked]
>>>[email-masked]
>>[email-masked]
>Guillermo Ib???ez
>Departamento de Ingenier??a Telem??tica
>4.1.F.13 Legan??s 91-6248794
>
>[email-masked]

Date: Tue, 28 Feb 2006 09:48:18 +0800
From: robey <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A question about (R)STP and routing protocol /	requ	est for comments to Abridges draft
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 11461

Hi,Eric,

Thank for your comments first.
I agree with your opinion that the likelihood of frame misorder is not big.
Otherwise, about your question of "How does use of symmetric trees impact on out of order delivery?", I can say if symmetric trees is used ,the path destined to one destination before obtaining  unicast FDB entries for that destination and the path destined to same destination after obtaining FDB entries  through source address learning will be same,so no misorder of frames occur.

Best regards

Robey

----- Original Message ----- 
From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Sent: Tuesday, February 28, 2006 3:43 AM
Subject: Re: [rbridge] A question about (R)STP and routing protocol / requ est for comments to Abridges draft

Robey,

I can't answer for Guilllermo's draft, but I can answer
for (or comment on) the general case addressed by documents 
already chartered for the WG.  Please see below... 

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of robey
--> Sent: Friday, February 24, 2006 10:53 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] A question about (R)STP and routing 
--> protocol / request for comments to Abridges draft
--> 
--> Hi,Guillermo Ibanez,
--> 
--> I have read through your Abridge draft, and think it 
--> provider a simpler method to achieve shortest path bridges .
--> In terms of approaches presented in Abridge draft, when 
--> packets of one specific traffic destined to same 
--> destination arrived at edge bridge, if these packets are 
--> kind of unknown packets, they will be broadcasted on 
--> ingress tree, then  after learing  unicast path FDB entry 
--> for the flow, packets of the traffic will be forwarded on 
--> the engress tree, in this case it is possible to bring 
--> about misorder of frames related to the traffic.
-->
--> How can you solve this problem?

Realistically speaking, several potential behaviors are not
very likely.

One example is the scenario where a lot of frames are sent
to a host that has not yet been discovered on the network.

Even in the case where this may occur, the degree to which
small scale out of order delivery is pathological behavior
with today's higher-level protocols is very small.

Finally, because the ultimate unicast delivery path will be
along the shortest path, the window of opportunity that may
result in actual out of order delivery, in transition from
flooding to simple delivery, is very small (especially if 
the traffic stream is a small fraction of link capacity).

--> 
--> Maybe we can create symmetric tree, and still consider 
--> using ingress tree to forward broadcast/multicast/unknown 
--> packets and using egress tree to forward unicast packets,  
--> in this way not only can it overcome the above problem ,but 
--> also have a simpler method to create FDB entries and can 
--> avoid address learning (except foraddresses of end nodes) 
--> which can reduce traffic flooding when topology changes.

How does use of symmetric trees impact on out of order delivery?

--> 
--> Best regards
--> 
--> robey
--> 
--> 
--> 
--> 
--> From: "Guillermo Ib??ez" <[email-masked]>
--> To: "Developing a hybrid router/bridge." <[email-masked]>
--> Sent: Thursday, February 23, 2006 5:40 PM
--> Subject: Re: [rbridge] A question about (R)STP and routing 
--> protocol / request for comments to Abridges draft
--> 
--> 
--> > Let me give my opinions interleaved.
--> > By the way, as the Abridges draft we submitted last december is 
--> > somewhere between the current RBridges proposal and the 
--> IEEE Shortest 
--> > Path Bridging, we think it would help clarify to obtain 
--> comments to our 
--> > draft from the RBridges WG members.
--> > Regards
--> > Guillermo Ibanez
--> > 
--> > 
--> > 
--> http://www.ietf.org/internet-drafts/draft-gibanez-trill-abri
--> dge-00.txt
--> > 
--> > Guillermo Ibanez
--> > 
--> > 
--> > Radia Perlman wrote:
--> > 
--> >>Suping Zhai,
--> >>
--> >>You are not the first person to ask these questions.
--> >>There is a lot of confusion over what is different 
--> between RSTP and STP,
--> >>and what is different between RSTP and link state routing.
--> >>I'll try to explain.
--> >>
--> >>1) What's the difference between RSTP and STP?
--> >>
--> >>RSTP and STP are almost identical, are compatible,
--> >>and it would be less confusing to think of RSTP as a different
--> >>version of the bridge spec than a different protocol.
--> >>
--> >>RSTP calculates the
--> >>same spanning tree, and uses the same algorithm and even
--> >>packet formats as STP. Both RSTP and STP calculate a tree 
--> of shortest paths
--> >>from the Root bridge, which is the bridge with lowest ID/priority.
--> >>
--> >>The major difference between RSTP and STP
--> >>is how they avoid temporary loops.
--> >>STP did it with a timer. RSTP coordinates between neighbors
--> >>to turn on links more quickly after topology changes.
--> >>
--> >>However, in either case, it is impossible to always avoid 
--> temporary
--> >>loops...the simplest case is when a repeater comes up, or 
--> if too many
--> >>spanning tree messages get lost due to congestion.
--> >>
--> >>So to summarize, both STP and RSTP use the same basic
--> >>algorithm...the heart of algorithm is to calculate a tree
--> >>of shortest paths from a single point.
--> >>And the resulting tree and data packet
--> >>forwarding path is the same in both (because it is the
--> >>same algorithm). A single shared loop-free subset
--> >>of the physical topology is calculated, upon which data 
--> packets are
--> >>forwarded.
--> >>
--> >>  
--> >>
--> >>2) What is the difference between RSTP and IS-IS?
--> >>
--> >>This is harder to answer than the difference between RSTP and STP,
--> >>because IS-IS and spanning tree (RSTP/STP) are so very 
--> different from
--> >>each other. IS-IS passes around topology
--> >>information so that every RBridge calculates the shortest 
--> path between
--> >>itself
--> >>and each
--> >>destination. With spanning tree (RSTP/STP) each bridge 
--> just knows which
--> >>subset of its
--> >>own ports are "in" or "out" of the spanning tree. If a 
--> link is not in
--> >>the spanning tree,
--> >>then it cannot be used, even if it is the shortest path 
--> between point A
--> >>and B, and
--> >>pairwise paths can be quite suboptimal. Furthermore, 
--> traffic is concentrated
--> >>on the links in the spanning tree, because no traffic can 
--> be on links
--> >>not in the
--> >>spanning tree.
--> >>
--> >>Also spanning tree bridges learn, based on
--> >>seeing data traffic, which
--> >>direction the source is. (which of its own local ports lead to the
--> >>source of
--> >>the data packet). So packets must always arrive from a 
--> particular source
--> >>from
--> >>the same direction or else bridges will get confused. In 
--> contrast, with
--> >>IS-IS,
--> >>switches can do path splitting; using multiple paths to 
--> reach a destination.
--> >>
--> >>  
--> >>
--> > It is important to remember that the standard convergence 
--> times of RSTP 
--> > are lower than those of routing protocols, unless 
--> specific measures for 
--> > milliseconds convergence are applied.
--> > 
--> >>3) What is difference between RSTP and RBridge approach?
--> >>
--> >>RBridge incorporates
--> >>a TTL into the header of forwarded data packets so a 
--> temporary loop is
--> >>not really bad, so it need not
--> >>be very conservative about avoiding loops. Also,
--> >>a link state protocol (IS-IS) calculates shortest
--> >>pair-wise paths. Also, it can calculate multiple paths to the
--> >>destination, and do path splitting.
--> >>  
--> >>
--> > Both IEEE Shortest Path Bridging and the Abridges draft 
--> proposal ( see
--> > 
--> http://www.ietf.org/internet-drafts/draft-gibanez-trill-abri
--> dge-00.txt)
--> > obtain shortest paths. They do not allow  path splitting, 
--> but are less 
--> > complex than IS-IS
--> > and do not mix STP and IS-IS protocols in same area.
--> > 
--> >>4) What is the difference between recent work in IEEE to calculate
--> >>per-ingress trees, and RBridge approach?
--> >>
--> >>IEEE may indeed wind up doing the same thing as RBridge. 
--> Several years
--> >>before TRILL I tried to get IEEE interested in doing this 
--> approach,
--> >>but they were not interested, perhaps because I didn't explain it
--> >>well enough. Now that work has started in IETF, I think 
--> it is possible
--> >>that IEEE will converge on the same solution, which would actually
--> >>be good for the industry.
--> >>Radia
--> >>  
--> >>
--> > I do not see an easy convergence between IEEE and RBridge 
--> proposals 
--> > unless the two groups cooperate strongly.
--> > IEEE will likely preserve basic RSTP mechanisms (fast 
--> convergence and 
--> > distance vector to (multiple) root bridges) with multiple 
--> spanning trees 
--> > (this is my guess, I do not follow their recent 
--> activities), while 
--> > RBridge uses IS-IS (link state mechanisms) as basic protocol.
--> > 
--> > 
--> > Guillermo Ibanez
--> > 
--> >>Suping Zhai wrote:
--> >>
--> >>  
--> >>
--> >>>hi,
--> >>>I am confronted with some questions when reading the 
--> Rbridge protocol related draft and hope someone can help me 
--> with details.
--> >>>What's the essential difference between (R)STP and 
--> routing protocol(e.g. IS-IS)? 
--> >>>How dose the routing protocol(e.g. IS-IS) can optimize 
--> the routing path while (R)STP can't? 
--> >>>Can we optimize the (R)STP protocol itself to reach that 
--> goal? If that's the case, then I think that all RBridge WG 
--> works can be substituted. And I have seen some work been 
--> done in IEEE802.1aq which is on the way to the per bridge 
--> MSTP road. But what I imagine is that should we get a 
--> comparable simple and untangled solution for the bridge 
--> network routing path?
--> >>>
--> >>>TIA.
--> >>>
--> >>>Best Regards,
--> >>>[email-masked]
--> >>>Huawei Technologies Co., Ltd.
--> >>>Tel: +86-10-82836882
--> >>>Fax: +86-10-82836020
--> >>>2006-02-23
--> >>>
--> >>>
--> >>>
--> >>>
--> >>>
--> >>> 
--> >>>
--> >>>---------------------------------------------------------
--> ---------------
--> >>>
--> >>>_______________________________________________
--> >>>rbridge mailing list
--> >>>[email-masked]
--> >>>http://www.postel.org/mailman/listinfo/rbridge
--> >>> 
--> >>>
--> >>>    
--> >>>
--> >>
--> >>  
--> >>
--> >>----------------------------------------------------------
--> --------------
--> >>
--> >>_______________________________________________
--> >>rbridge mailing list
--> >>[email-masked]
--> >>http://www.postel.org/mailman/listinfo/rbridge
--> >>  
--> >>
--> > 
--> > -- 
--> > Guillermo Ib??ez
--> > Departamento de Ingenier?a Telem?tica
--> > Universidad Carlos III de Madrid
--> > 1.1.B.11 Colmenarejo 91-6241393
--> > 4.1.F.13 Legan?s 91-6248794
--> > 
--> > _______________________________________________
--> > rbridge mailing list
--> > [email-masked]
--> > http://www.postel.org/mailman/listinfo/rbridge
--> >
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 
_______________________________________________
rbridge mailing list
[email-masked]
http://www.postel.org/mailman/listinfo/rbridge

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Mon, 27 Feb 2006 14:43:08 -0500
Subject: Re: [rbridge] A question about (R)STP and routing protocol / requ	est for comments to Abridges draft
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 10514

Robey,

	I can't answer for Guilllermo's draft, but I can answer
for (or comment on) the general case addressed by documents 
already chartered for the WG.  Please see below... 

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of robey
--> Sent: Friday, February 24, 2006 10:53 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] A question about (R)STP and routing 
--> protocol / request for comments to Abridges draft
--> 
--> Hi,Guillermo Ibanez,
--> 
--> I have read through your Abridge draft, and think it 
--> provider a simpler method to achieve shortest path bridges .
--> In terms of approaches presented in Abridge draft, when 
--> packets of one specific traffic destined to same 
--> destination arrived at edge bridge, if these packets are 
--> kind of unknown packets, they will be broadcasted on 
--> ingress tree, then  after learing  unicast path FDB entry 
--> for the flow, packets of the traffic will be forwarded on 
--> the engress tree, in this case it is possible to bring 
--> about misorder of frames related to the traffic.
-->
--> How can you solve this problem?

Realistically speaking, several potential behaviors are not
very likely.

One example is the scenario where a lot of frames are sent
to a host that has not yet been discovered on the network.

Even in the case where this may occur, the degree to which
small scale out of order delivery is pathological behavior
with today's higher-level protocols is very small.

Finally, because the ultimate unicast delivery path will be
along the shortest path, the window of opportunity that may
result in actual out of order delivery, in transition from
flooding to simple delivery, is very small (especially if 
the traffic stream is a small fraction of link capacity).

--> 
--> Maybe we can create symmetric tree, and still consider 
--> using ingress tree to forward broadcast/multicast/unknown 
--> packets and using egress tree to forward unicast packets,  
--> in this way not only can it overcome the above problem ,but 
--> also have a simpler method to create FDB entries and can 
--> avoid address learning (except foraddresses of end nodes) 
--> which can reduce traffic flooding when topology changes.

How does use of symmetric trees impact on out of order delivery?

--> 
--> Best regards
--> 
--> robey
--> 
--> 
--> 
--> 
--> From: "Guillermo Ib??ez" <[email-masked]>
--> To: "Developing a hybrid router/bridge." <[email-masked]>
--> Sent: Thursday, February 23, 2006 5:40 PM
--> Subject: Re: [rbridge] A question about (R)STP and routing 
--> protocol / request for comments to Abridges draft
--> 
--> 
--> > Let me give my opinions interleaved.
--> > By the way, as the Abridges draft we submitted last december is 
--> > somewhere between the current RBridges proposal and the 
--> IEEE Shortest 
--> > Path Bridging, we think it would help clarify to obtain 
--> comments to our 
--> > draft from the RBridges WG members.
--> > Regards
--> > Guillermo Ibanez
--> > 
--> > 
--> > 
--> http://www.ietf.org/internet-drafts/draft-gibanez-trill-abri
--> dge-00.txt
--> > 
--> > Guillermo Ibanez
--> > 
--> > 
--> > Radia Perlman wrote:
--> > 
--> >>Suping Zhai,
--> >>
--> >>You are not the first person to ask these questions.
--> >>There is a lot of confusion over what is different 
--> between RSTP and STP,
--> >>and what is different between RSTP and link state routing.
--> >>I'll try to explain.
--> >>
--> >>1) What's the difference between RSTP and STP?
--> >>
--> >>RSTP and STP are almost identical, are compatible,
--> >>and it would be less confusing to think of RSTP as a different
--> >>version of the bridge spec than a different protocol.
--> >>
--> >>RSTP calculates the
--> >>same spanning tree, and uses the same algorithm and even
--> >>packet formats as STP. Both RSTP and STP calculate a tree 
--> of shortest paths
--> >>from the Root bridge, which is the bridge with lowest ID/priority.
--> >>
--> >>The major difference between RSTP and STP
--> >>is how they avoid temporary loops.
--> >>STP did it with a timer. RSTP coordinates between neighbors
--> >>to turn on links more quickly after topology changes.
--> >>
--> >>However, in either case, it is impossible to always avoid 
--> temporary
--> >>loops...the simplest case is when a repeater comes up, or 
--> if too many
--> >>spanning tree messages get lost due to congestion.
--> >>
--> >>So to summarize, both STP and RSTP use the same basic
--> >>algorithm...the heart of algorithm is to calculate a tree
--> >>of shortest paths from a single point.
--> >>And the resulting tree and data packet
--> >>forwarding path is the same in both (because it is the
--> >>same algorithm). A single shared loop-free subset
--> >>of the physical topology is calculated, upon which data 
--> packets are
--> >>forwarded.
--> >>
--> >>  
--> >>
--> >>2) What is the difference between RSTP and IS-IS?
--> >>
--> >>This is harder to answer than the difference between RSTP and STP,
--> >>because IS-IS and spanning tree (RSTP/STP) are so very 
--> different from
--> >>each other. IS-IS passes around topology
--> >>information so that every RBridge calculates the shortest 
--> path between
--> >>itself
--> >>and each
--> >>destination. With spanning tree (RSTP/STP) each bridge 
--> just knows which
--> >>subset of its
--> >>own ports are "in" or "out" of the spanning tree. If a 
--> link is not in
--> >>the spanning tree,
--> >>then it cannot be used, even if it is the shortest path 
--> between point A
--> >>and B, and
--> >>pairwise paths can be quite suboptimal. Furthermore, 
--> traffic is concentrated
--> >>on the links in the spanning tree, because no traffic can 
--> be on links
--> >>not in the
--> >>spanning tree.
--> >>
--> >>Also spanning tree bridges learn, based on
--> >>seeing data traffic, which
--> >>direction the source is. (which of its own local ports lead to the
--> >>source of
--> >>the data packet). So packets must always arrive from a 
--> particular source
--> >>from
--> >>the same direction or else bridges will get confused. In 
--> contrast, with
--> >>IS-IS,
--> >>switches can do path splitting; using multiple paths to 
--> reach a destination.
--> >>
--> >>  
--> >>
--> > It is important to remember that the standard convergence 
--> times of RSTP 
--> > are lower than those of routing protocols, unless 
--> specific measures for 
--> > milliseconds convergence are applied.
--> > 
--> >>3) What is difference between RSTP and RBridge approach?
--> >>
--> >>RBridge incorporates
--> >>a TTL into the header of forwarded data packets so a 
--> temporary loop is
--> >>not really bad, so it need not
--> >>be very conservative about avoiding loops. Also,
--> >>a link state protocol (IS-IS) calculates shortest
--> >>pair-wise paths. Also, it can calculate multiple paths to the
--> >>destination, and do path splitting.
--> >>  
--> >>
--> > Both IEEE Shortest Path Bridging and the Abridges draft 
--> proposal ( see
--> > 
--> http://www.ietf.org/internet-drafts/draft-gibanez-trill-abri
--> dge-00.txt)
--> > obtain shortest paths. They do not allow  path splitting, 
--> but are less 
--> > complex than IS-IS
--> > and do not mix STP and IS-IS protocols in same area.
--> > 
--> >>4) What is the difference between recent work in IEEE to calculate
--> >>per-ingress trees, and RBridge approach?
--> >>
--> >>IEEE may indeed wind up doing the same thing as RBridge. 
--> Several years
--> >>before TRILL I tried to get IEEE interested in doing this 
--> approach,
--> >>but they were not interested, perhaps because I didn't explain it
--> >>well enough. Now that work has started in IETF, I think 
--> it is possible
--> >>that IEEE will converge on the same solution, which would actually
--> >>be good for the industry.
--> >>Radia
--> >>  
--> >>
--> > I do not see an easy convergence between IEEE and RBridge 
--> proposals 
--> > unless the two groups cooperate strongly.
--> > IEEE will likely preserve basic RSTP mechanisms (fast 
--> convergence and 
--> > distance vector to (multiple) root bridges) with multiple 
--> spanning trees 
--> > (this is my guess, I do not follow their recent 
--> activities), while 
--> > RBridge uses IS-IS (link state mechanisms) as basic protocol.
--> > 
--> > 
--> > Guillermo Ibanez
--> > 
--> >>Suping Zhai wrote:
--> >>
--> >>  
--> >>
--> >>>hi,
--> >>>I am confronted with some questions when reading the 
--> Rbridge protocol related draft and hope someone can help me 
--> with details.
--> >>>What's the essential difference between (R)STP and 
--> routing protocol(e.g. IS-IS)? 
--> >>>How dose the routing protocol(e.g. IS-IS) can optimize 
--> the routing path while (R)STP can't? 
--> >>>Can we optimize the (R)STP protocol itself to reach that 
--> goal? If that's the case, then I think that all RBridge WG 
--> works can be substituted. And I have seen some work been 
--> done in IEEE802.1aq which is on the way to the per bridge 
--> MSTP road. But what I imagine is that should we get a 
--> comparable simple and untangled solution for the bridge 
--> network routing path?
--> >>>
--> >>>TIA.
--> >>>
--> >>>Best Regards,
--> >>>[email-masked]
--> >>>Huawei Technologies Co., Ltd.
--> >>>Tel: +86-10-82836882
--> >>>Fax: +86-10-82836020
--> >>>2006-02-23
--> >>>
--> >>>
--> >>>
--> >>>
--> >>>
--> >>> 
--> >>>
--> >>>---------------------------------------------------------
--> ---------------
--> >>>
--> >>>_______________________________________________
--> >>>rbridge mailing list
--> >>>[email-masked]
--> >>>http://www.postel.org/mailman/listinfo/rbridge
--> >>> 
--> >>>
--> >>>    
--> >>>
--> >>
--> >>  
--> >>
--> >>----------------------------------------------------------
--> --------------
--> >>
--> >>_______________________________________________
--> >>rbridge mailing list
--> >>[email-masked]
--> >>http://www.postel.org/mailman/listinfo/rbridge
--> >>  
--> >>
--> > 
--> > -- 
--> > Guillermo Ib??ez
--> > Departamento de Ingenier?a Telem?tica
--> > Universidad Carlos III de Madrid
--> > 1.1.B.11 Colmenarejo 91-6241393
--> > 4.1.F.13 Legan?s 91-6248794
--> > 
--> > _______________________________________________
--> > rbridge mailing list
--> > [email-masked]
--> > http://www.postel.org/mailman/listinfo/rbridge
--> >
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Sat, 25 Feb 2006 11:52:47 +0800
From: robey <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 7982

Hi,Guillermo Ibanez,

Best regards

robey

From: "Guillermo Ibáñez" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Sent: Thursday, February 23, 2006 5:40 PM
Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft

>>>[email-masked]
>>>[email-masked]
>>[email-masked]
> Guillermo Ibáñez
> Departamento de Ingeniería Telemática
> 4.1.F.13 Leganés 91-6248794
> 
> [email-masked]

Date: Fri, 24 Feb 2006 10:34:01 +0800
From: Suping Zhai <[email-masked]>
To: Radia Perlman <[email-masked]>, "[email-masked]" <[email-masked]>
Organization: huawei
Subject: Re: [rbridge] A question about (R)STP and routing protocol
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 8388

Hi Radia,
Thank you at first for you response. See inline my further doubts.
>This would be much clearer if I could make little ASCII drawings, but
>tonight I'm tired. Maybe I'll
>make a pdf drawing and send it to you if I can't explain in words.
>
>With spanning tree, there is only a single loop-free tree that is
>calculated by all the bridges.
>Let's say there is one link that is not selected to be in the spanning
>tree, and it connects
>B1 and B2. If B1 has a packet that needs to get sent to B2, it cannot
>use the B1-B2 link,
>since that link is not in the spanning tree. The spanning tree path
>between any two points can
>be quite bad because it is constrained not to use some links. In
>contrast, the IS-IS path
>can always choose the shortest path between any two points.
>
>As for whether RSTP/STP can be modified to calculate the same paths as
>IS-IS...sure...in the
>sense that anything can be modified to be anything else. But it really
>would be completely doing
>it a different way. The spanning tree algorithm is very different from
>Dijkstra/link state routing.

>
>So, the spanning tree has ALL bridges calculate the SAME spanning
>tree...the tree of shortest
>paths from the Root bridge to all the other bridges. IS-IS has each
>switch calclate a DIFFERENT
>graph, which is the graph of shortest paths from that switch to each
>destination. ANd I said "graph"
>rather than "tree" because with IS-IS you can calculate multiple paths
>to a destination. If you do
>that (calculate multiple paths), then it's no longer a tree.

[zsp]I go through some kinds of topology and use two kinds algorithms, that is using STP algorithm and Dijkstra seperately, and ultimately get the same tree or graph. So perhaps what I should ask is in what situation, with what topology there are different result forwarding tree when using above two mechanisms?

Suping
>
>Even if bridges were modified somehow to calculate the same paths as
>IS-IS, they would not
>be able to do path splitting (i.e., multiple paths to the same
>destination), because all traffic from S
>must be received on the same port....by the nature of how bridges do
>learning.
>
>If you do the modifications to achieve the same things as TRILL, you are
>basically doing the TRILL
>design....replacing spanning tree with link state Dijkstra, doing
>endnode learning differently, and
>then while you are at it, it would be a good idea to add a TTL to the
>header so temporary loops
>aren't a problem.
>
>Radia
>
>Suping Zhai wrote:
>
>>Radia,
>>Thank you for your detail explanations.
>>With the following 2) point, I am not yet clear enough and hope you can help me with that.
>>What I think about IS-IS is that, IS-IS router uses the neighbour link state informations, using the Dijakson algorithm to calculate the shortest path to the DR(Designated Router).
>>For the STP/RSTP(as I understand, they are almost the same regarding to the algorithm except for some convergence optimization), bridge also use the neighbour link state informations, using algorithm like Dijackson to calculate the tree path from the root bridge to every leaf bridge.
>>
>>So my question is, in what sense you can differ the result tree or routing path from the IS-IS and STP/RSTP? And are there any difference between the IS-IS and STP/RSTP with regard to the path calculation mechanisms?
>>With that my last question is, if STP/RSTP can be optimized to get the same result with what the IS-IS has?
>>
>>With Kind Regards,
>>Suping
>>
>>  
>>
>>>Suping Zhai,
>>>
>>>>[email-masked]
>>>>[email-masked]

Date: Thu, 23 Feb 2006 10:40:02 +0100
From: =?UTF-8?B?R3VpbGxlcm1vIEliw6HDsWV6?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 6316

Guillermo Ibanez

Guillermo Ibanez

>>[email-masked]
>>[email-masked]
>[email-masked]

-- 
Guillermo Ibáñez
Departamento de Ingeniería Telemática
Universidad Carlos III de Madrid
1.1.B.11 Colmenarejo 91-6241393
4.1.F.13 Leganés 91-6248794

Date: Wed, 22 Feb 2006 21:15:19 -0800
From: Radia Perlman <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] A question about (R)STP and routing protocol
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4479

Suping Zhai,

RSTP calculates the

RBridge incorporates

Radia

Suping Zhai wrote:

>[email-masked]
>[email-masked]

Date: Thu, 23 Feb 2006 10:40:33 +0800
From: Suping Zhai <[email-masked]>
To: Radia Perlman <[email-masked]>, "[email-masked]" <[email-masked]>
Organization: huawei
Subject: [rbridge] A question about (R)STP and routing protocol
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 800

hi,

TIA.

Best Regards,
[email-masked]

Date: Sat, 18 Feb 2006 13:26:38 +0100
From: =?windows-1252?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] VLAN and learning questions
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1936

Regarding 2, this is also called dual-MAC learning, as used in Global 
Open Ethernet and others. I agree it is an efficient mechanism although 
for big networks the ARP broadcast may not be acceptable.
Regards
Guillermo
Jianlin Zeng wrote:

> Hi,
>
> I?ve studied the document draft-perlman-trill-rbridge-protocol-00.txt 
> and have the following questions/suggestions:
>
>    1. Should the VLAN tag be carried on the outer header only? Legacy
>       bridges needs the VLAN tag from outer header if the frame is not
>       received from the default VLAN of the ingress port. RBridge can
>       always derive VLAN of the received frame based on VLAN tag in
>       the outer header or default port VLAN if the tag is not there.
>    2. Regarding learning of end node information, would the action of
>       having designated RBridges to query/learn end node information
>       and broadcast to every RBridges consume too much bandwidth and
>       processing power? This requires huge network and processing
>       resources as network gets bigger. For deployments that don?t
>       require ARP/ND proxy, each RBridge can learn the (Designated
>       RBridge address, end node address) information directly from the
>       SA in the outer header and SA in the inner header. This doesn?t
>       need extra broadcasting packets and can be implemented in the
>       hardware. An aging mechanism similar to legacy bridges can be
>       implemented by each RBridge to keep the end node information
>       database fresh enough.
>
> Thanks,
>
> Jianlin
>
>[email-masked]

Content-class: urn:content-classes:message
Date: Fri, 17 Feb 2006 16:59:06 -0800
From: "Jianlin Zeng" <[email-masked]>
To: <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Endnode learning from data packets vs from link stateinformation
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4360

Hi Radia,

Thanks for the answer. As you pointed out, it's a tradeoff to pick which
direction and go with it. 

The biggest advantages of RBridge as you described in the draft is
shortest paths forwarding with TTL vs STP. This along is already a huge
improvement over current layer 2 networks. If the draft can define a
base that can achieve this goal and is scalable and simple to implement,
it will be much easier to be adopted by current switch vendors. The
fancy features like ARP/ND proxy/mix link types etc can be defined as
optional add-on features to make RBridge even more attractive.

Jianlin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Friday, February 17, 2006 3:12 PM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Endnode learning from data packets vs from link
stateinformation

Jianlin Zeng,

Both really good questions. I prefer (when I'm reading email threads)
to have only one technical topic in each thread, so I took the
liberty of changing the subject line and in this reply, only
asking about endnode learning.

It is an interesting variant, as you propose,
to not bother broadcasting endnode
information in link state information, and only figure it
out from encapsulated data packets. However,
for most data packets, only the "egress RBridge" is
in the shim header, not the "ingress RBridge".

As you point out though, if we have the source address
in the OUTER header be the ingress RBridge's MAC address, then
RBridges can do the mapping of ("ingress RBridge MAC address,
endnode MAC address"). Currently, the internet draft
specifies that in the outer header, the SA is the transmitting
RBridge, so the SA in the outer header would change
at each hop.
There are a couple of worries
I'd have about using original RBridge as the SA in the outer
header rather than the transmitting RBridge on that hop.

a) Might it confuse bridge learning if they see the MAC
address of the original RBridge coming from different directions?
Maybe this wouldn't be a problem because the destination
address in the outer header would always be one local to
that bridged link.

b) IS-IS uses a single 6-byte ID for the RBridge, whereas it
might have multiple MAC addresses. I suppose we could
add information into the LSP to indicate "variant MAC addresses",
since IS-IS would, without us adding that field, only tell
us how to reach the system ID of the destination RBridge.

c) I was thinking about potentially mixing link types at
some point in the future, and I think it would be
easier to do this if the outer header was link-specific,
so this would allow RBridge encapsulated
packets to traverse some mythical kind of link, with say,
4 byte addresses. If we were to do something like that,
we wouldn't be able to put in the original RBridge MAC
address into the SA of that type of header.

There might be more issues, but it would be interesting
to look at the tradeoffs. I'm not sure whether it's going to
be easy to definitely decide this, so this might
be one of those cases where we should just pick one
direction and run with it.

Radia

>    2. Regarding learning of end node information, would the action of
>       having designated RBridges to query/learn end node information
and
>       broadcast to every RBridges consume too much bandwidth and
>       processing power? This requires huge network and processing
>       resources as network gets bigger. For deployments that don't
>       require ARP/ND proxy, each RBridge can learn the (Designated
>       RBridge address, end node address) information directly from the
>       SA in the outer header and SA in the inner header. This doesn't
>       need extra broadcasting packets and can be implemented in the
>       hardware. An aging mechanism similar to legacy bridges can be
>       implemented by each RBridge to keep the end node information
>       database fresh enough.
> 
>  
> 
> Thanks,
> 
> Jianlin
> 
> 
>
> [email-masked]

[email-masked]

Date: Fri, 17 Feb 2006 15:12:07 -0800
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Endnode learning from data packets vs from link state information
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3331

Jianlin Zeng,

Both really good questions. I prefer (when I'm reading email threads)
to have only one technical topic in each thread, so I took the
liberty of changing the subject line and in this reply, only
asking about endnode learning.

It is an interesting variant, as you propose,
to not bother broadcasting endnode
information in link state information, and only figure it
out from encapsulated data packets. However,
for most data packets, only the "egress RBridge" is
in the shim header, not the "ingress RBridge".

As you point out though, if we have the source address
in the OUTER header be the ingress RBridge's MAC address, then
RBridges can do the mapping of ("ingress RBridge MAC address,
endnode MAC address"). Currently, the internet draft
specifies that in the outer header, the SA is the transmitting
RBridge, so the SA in the outer header would change
at each hop.
There are a couple of worries
I'd have about using original RBridge as the SA in the outer
header rather than the transmitting RBridge on that hop.

a) Might it confuse bridge learning if they see the MAC
address of the original RBridge coming from different directions?
Maybe this wouldn't be a problem because the destination
address in the outer header would always be one local to
that bridged link.

b) IS-IS uses a single 6-byte ID for the RBridge, whereas it
might have multiple MAC addresses. I suppose we could
add information into the LSP to indicate "variant MAC addresses",
since IS-IS would, without us adding that field, only tell
us how to reach the system ID of the destination RBridge.

c) I was thinking about potentially mixing link types at
some point in the future, and I think it would be
easier to do this if the outer header was link-specific,
so this would allow RBridge encapsulated
packets to traverse some mythical kind of link, with say,
4 byte addresses. If we were to do something like that,
we wouldn't be able to put in the original RBridge MAC
address into the SA of that type of header.

There might be more issues, but it would be interesting
to look at the tradeoffs. I'm not sure whether it's going to
be easy to definitely decide this, so this might
be one of those cases where we should just pick one
direction and run with it.

Radia

>    2. Regarding learning of end node information, would the action of
>       having designated RBridges to query/learn end node information and
>       broadcast to every RBridges consume too much bandwidth and
>       processing power? This requires huge network and processing
>       resources as network gets bigger. For deployments that don?t
>       require ARP/ND proxy, each RBridge can learn the (Designated
>       RBridge address, end node address) information directly from the
>       SA in the outer header and SA in the inner header. This doesn?t
>       need extra broadcasting packets and can be implemented in the
>       hardware. An aging mechanism similar to legacy bridges can be
>       implemented by each RBridge to keep the end node information
>       database fresh enough.
> 
>  
> 
> Thanks,
> 
> Jianlin
> 
> 
> [email-masked]

Content-class: urn:content-classes:message
Date: Fri, 17 Feb 2006 14:21:01 -0800
From: "Jianlin Zeng" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] VLAN and learning questions
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4819

This is a multi-part message in MIME format.

------_=_NextPart_001_01C63410.6F2FA1B3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

I've studied the document draft-perlman-trill-rbridge-protocol-00.txt
and have the following questions/suggestions:

=20

1.	Should the VLAN tag be carried on the outer header only? Legacy
bridges needs the VLAN tag from outer header if the frame is not
received from the default VLAN of the ingress port. RBridge can always
derive VLAN of the received frame based on VLAN tag in the outer header
or default port VLAN if the tag is not there.
2.	Regarding learning of end node information, would the action of
having designated RBridges to query/learn end node information and
broadcast to every RBridges consume too much bandwidth and processing
power? This requires huge network and processing resources as network
gets bigger. For deployments that don't require ARP/ND proxy, each
RBridge can learn the (Designated RBridge address, end node address)
information directly from the SA in the outer header and SA in the inner
header. This doesn't need extra broadcasting packets and can be
implemented in the hardware. An aging mechanism similar to legacy
bridges can be implemented by each RBridge to keep the end node
information database fresh enough.

=20

Thanks,

Jianlin

------_=_NextPart_001_01C63410.6F2FA1B3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I&#8217;ve studied the document =
draft-perlman-trill-rbridge-protocol-00.txt
and have the following questions/suggestions:</span></font></p>

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

<ol start=3D1 type=3D1>
 <li class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
     font-family:Arial'>Should the VLAN tag be carried on the outer =
header
     only? Legacy bridges needs the VLAN tag from outer header if the =
frame is
     not received from the default VLAN of the ingress port. RBridge can =
always
     derive VLAN of the received frame based on VLAN tag in the outer =
header or
     default port VLAN if the tag is not there.</span></font></li>
 <li class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
     font-family:Arial'>Regarding learning of end node information, =
would the
     action of having designated RBridges to query/learn end node =
information
     and broadcast to every RBridges consume too much bandwidth and =
processing
     power? This requires huge network and processing resources as =
network gets
     bigger. For deployments that don&#8217;t require ARP/ND proxy, each =
RBridge
     can learn the (Designated RBridge address, end node address) =
information
     directly from the SA in the outer header and SA in the inner =
header. This
     doesn&#8217;t need extra broadcasting packets and can be =
implemented in
     the hardware. An aging mechanism similar to legacy bridges can be
     implemented by each RBridge to keep the end node information =
database fresh
     enough.</span></font></li>
</ol>

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

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

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

</div>

</body>

</html>

------_=_NextPart_001_01C63410.6F2FA1B3--

Date: Mon, 13 Feb 2006 11:07:09 -0800
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] rbridge protocol docment now available
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1710

Hi, all,

The following document has been submitted as an individual I-D. We would
like to offer it as a WG document, as per discussions in Vancouver. It
is currently available at:
http://www.postel.org/rbridge/draft-perlman-trill-rbridge-protocol-00.txt

It should appear in the usual I-D places shortly as well.

Joe and Radia

- ---

TRILL Working Group                                          R. Perlman
Internet Draft                                                      Sun
Expires: August 2006                                           J. Touch
                                                                USC/ISI
                                                      February 13, 2006

                   Rbridges: Base Protocol Specification
                draft-perlman-trill-rbridge-protocol-00.txt
...
Abstract

   RBridges provide the ability to have an entire campus, with multiple
   physical links, look to IP like a single subnet. The design allows
   for zero configuration of switches within a campus, optimal pair-wise
   routing, safe forwarding even during periods of temporary loops, and
   the ability to cut down on ARP/ND traffic. The design also supports
   VLANs, and allows forwarding tables to be based on RBridge
   destinations (rather than endnode destinations), which allows
   internal routing tables to be substantially smaller than in
   conventional bridge systems.

From: Eastlake III Donald-LDE008 <[email-masked]>
To: "TRILL <[email-masked]>" <[email-masked]>
Date: Fri, 10 Feb 2006 00:54:33 -0500
Subject: [rbridge] Call for items for the March meeting agenda
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 451

Hi,

Erik and I are starting to work on the agenda for the March meeting. Our major documents are obvious items but we welcome other suggestions for topics or presentations.

Thanks,
Donald

 =========================================================
 Donald E. Eastlake III       [email-masked]
 Motorola Laboratories              +1-508-786-7554 (work)
 111 Locke Drive                    +1-508-634-2066 (home)
 Marlboro, MA 01752 USA

From: Eastlake III Donald-LDE008 <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Date: Sat, 4 Feb 2006 15:29:36 -0500 
Subject: Re: [rbridge] Donald Eastlake as TRILL Co-Chair
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 431

Thanks,
Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Thursday, February 02, 2006 11:20 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Donald Eastlake as TRILL Co-Chair

Welcome aboard!

Joe
[email-masked]

Date: Sat, 04 Feb 2006 09:13:32 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Where do VLAN tags go in forwarded frames?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1873

Just following the line of thought of Radia and thinking aloud...
On one hand, duplicating the VLAN tag is an additional complexity and 
not fully justified. On the other hand, if restrictions on the difusion 
of frames are required, the duplication of VLAN tag will be required, 
specially if standard bridges must also limit the difusion of unknown 
destinations and multicasts. If VLAN tag is duplicated, the objection is 
then that complexity introduced is something closet to MAC in MAC 
encapsulation plus VLAN stacking plus IS-IS, just for a campus network.
Guillermo

Radia Perlman wrote:

>How do RBridges know a packet is for a particular VLAN? For originating
>frames, it would be the same as for bridges, i.e., sometimes the endnode
>fills it in, sometimes a bridge between the RBridge and the endnode fills
>it in, and sometimes the RBridge fills it in. (I assume bridges today
>are configured as to whether they should add VLAN tags for untagged packets
>from a particular link?)
>
>However, for packets in transit between RBridges, is there any reason
>to duplicate the VLAN tag into the outer header? (review...the original
>frame is "inside", then there's a shim header with ingress/egress RBridge
>and TTL, and an "outer" Ethernet header with Ethertype 
>"RBridge-forwarded frame".)
>It doesn't seem necessary for correctness, but it might be more convenient
>for RBridge forwarding (only for unknown destinations and multicasts)
>if they didn't need to look inside at the inner header to find out if
>the scope of delivery is just to a VLAN.
>
>Radia
>
>[email-masked]

From: "Gray, Eric" <[email-masked]>
To: "'Radia Perlman'" <[email-masked]>
Date: Fri, 3 Feb 2006 16:05:50 -0500 
Cc: "'Developing a hybrid router/bridge.'" <[email-masked]>
Subject: Re: [rbridge] Where do VLAN tags go in forwarded frames?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3937

Radia, 

	Please see below...

--
Eric

--> 
--> How do RBridges know a packet is for a particular VLAN? 
-->

Without going into the details (most people won't really 
want to hear them, and those who might can find them in 
appropriate 802.## specifications), there is a code point
in the basic Ethernet/802.3 header to determine which (of
several) encapsulations applies to this frame.

If the code point indicates it is VLAN tagged, then the
forwarding device may look at the appropriate offset to
determine which VLAN this frame applies to.

-->
--> For originating frames, it would be the same as for bridges, 
--> i.e., sometimes the endnode fills it in, sometimes a bridge 
--> between the RBridge and the endnode fills it in, and sometimes 
--> the RBridge fills it in. (I assume bridges today are configured 
--> as to whether they should add VLAN tags for untagged packets
--> from a particular link?)
-->

There is a concept of "port-based" VLANs - in which the port
to VLAN information is (typically) configured.  If frames are
received on such a port, and the forwarding device determines
that they need to be forwarded on one or more ports that use
VLAN-tagged frames (to allow support of multiple VLANs on the
port), the receiving port-to-VLAN information is used to map
the frame encapsulation for a transmitting (forwarding) port.

This may done on a port by port basis, but it is typically the
case that a single VLAN is identified by a common tag on all
ports for any individual device (thus allowing for identical
VLAN-tagged encapsulation to be used).

Forwarding from port-based VLAN port to port-based VLAN port
(where both are mapped to the same VLAN context), or from 
VLAN-tagged port to VLAN-tagged port (where the mappings of
VLAN tag values are the same) - requires no special forwarding
or encapuslation activities.

--> 
--> However, for packets in transit between RBridges, is there any 
--> reason to duplicate the VLAN tag into the outer header? 
--> (review...the original frame is "inside", then there's a shim 
--> header with ingress/egress RBridge and TTL, and an "outer" 
--> Ethernet header with Ethertype "RBridge-forwarded frame".)
-->

This depends on whether this additional level of multiplexing
is required to support the number of potential encapsulations
required.

In the MPLS label encapsulated approach proposed at the last
meeting, this might not be required.  We could - for example 
- use different labels associated with the same egress to de-
multiplex different VLAN contexts.

Given that this would allow for intermediate RBridges to easily
distinguish forwarding on a VLAN basis, using a single field
look-up, this might be highly desirable (and probably should be
considered, if it is not already).

Also it is not necessary that an outer VLAN tag mapping would 
be on a one-to-one basis with the innner VLAN tag in any case - 
unless this was desired in order to reduce requirements for 
configuration.

-->
--> It doesn't seem necessary for correctness, but it might be more 
--> convenient for RBridge forwarding (only for unknown destinations  
--> and multicasts) if they didn't need to look inside at the inner  
--> header to find out if the scope of delivery is just to a VLAN.
-->

It would be a matter of using one off-set verses another, as long 
as a two field look-up is required in any case.  The real issue is
whether or not it is appropriate to assume "correct" format using
well understood off-set values is guaranteed in RBridge forwarded
frames.  

As long as formatting is reasonably consistent (having a smallish 
number of possible, easily distinguishable, formats), it should not 
matter whether you look N bits into the frame or N+M bits into the 
frame to find a VLAN tag.

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

Date: Fri, 03 Feb 2006 11:41:04 -0800
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Where do VLAN tags go in forwarded frames?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 955

How do RBridges know a packet is for a particular VLAN? For originating
frames, it would be the same as for bridges, i.e., sometimes the endnode
fills it in, sometimes a bridge between the RBridge and the endnode fills
it in, and sometimes the RBridge fills it in. (I assume bridges today
are configured as to whether they should add VLAN tags for untagged packets
from a particular link?)

However, for packets in transit between RBridges, is there any reason
to duplicate the VLAN tag into the outer header? (review...the original
frame is "inside", then there's a shim header with ingress/egress RBridge
and TTL, and an "outer" Ethernet header with Ethertype 
"RBridge-forwarded frame".)
It doesn't seem necessary for correctness, but it might be more convenient
for RBridge forwarding (only for unknown destinations and multicasts)
if they didn't need to look inside at the inner header to find out if
the scope of delivery is just to a VLAN.

Radia

Date: Thu, 02 Feb 2006 20:19:48 -0800
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Donald Eastlake as TRILL Co-Chair
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 722

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

Welcome aboard!

Joe

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

--------------enig0DFC1878EEC0DF2EEAB09E86--

Content-class: urn:content-classes:message
Date: Thu, 2 Feb 2006 09:47:54 +0100
From: "Sofia, Rute" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>, "Wojtek Paprowicz" <[email-masked]>
Subject: Re: [rbridge] Unnecessary flooding through ST
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1904

Hello,

> --> I know of no reason why this would not also happen if we
> --> were to replace RBridges with IS-IS routers.
> 
> After thinking a little further about this, I must conclude
> that the last sentence above is not correct, as stated and 
> without further amplification.
> 
> I thought it made a good "short answer", but it does not.
> 
> Strictly speaking, the statement might be true for flooding
> between RBridges.  Even in this limited sense, however, the
> amount of flooding required would be much less, since the 
> exposure to L2 addresses would be limited to the addresses
> of the local IS-IS routers on any single shared media.
> 
> In terms of flooding into the network via egress RBridges,
> clearly this would not happen if the RBridge was replaced
> by an IS-IS router.
> 
> Consequently, notwithstanding the potential mitigation 
> techniques and factors, the extent of flooding in the case
> pointed out by Wojtek Paprowicz could be much worse than 
> would be the case without the interactions between bridge
> learning, STP and the SPF computation.  
> 
> That is, if there was an additonal delay in "learning" as
> a result of requiring a new SPF computation.
> 

Wojtek is indeed speaking of the last case you are mentioning, i.e.,
besides IS-IS, you still have the flooding performed in the ST. It is a
fact that IS-IS has to be tuned and that anyway the spfdelay timer may
give rise to the same problems. But the problem here is indeed allowing
Rbridges to try to get info about destinations in two ways 1) on demand
as usual, by means of the ST; 2) without requesting, by means of IS-IS.
This makes things worse. 
This is in fact what Rbridges for now describes as a concept and is a
potential source of problems for convergence. You mentioned that some
people are working on ways to reduce the need for flooding. Can you
please point out some sources?

Regards,
Rute

From: "Gray, Eric" <[email-masked]>
To: "'Wojtek Paprowicz'" <[email-masked]>
Date: Wed, 1 Feb 2006 16:34:22 -0500 
Cc: "'Developing a hybrid router/bridge.'" <[email-masked]>
Subject: Re: [rbridge] Unnecessary flooding through ST
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4693

One correction, below (sorry for the lengthy discussion)...

--- [SNIP] ---
--> --> The process of exchanging LSPs takes very little time. 
--> --> However, if Rbridge A received another frame addressed
--> --> to host B it will flood it again because the SPF 
--> --> computation didn't take place yet. spfDelay typically 
--> --> takes 5s (but can be tuned). Does this mean that during
--> --> that time any transmission from host A to host B in the
--> --> provided scenario will be carried by means of the ST? 
--> -->
--> 
--> There are schemes for reducing the impact of flooding for
--> unknown destinations.  For example, some bridges may limit 
--> the periodicity for flooding to each unknown destination.
--> 
--> There are problems with doing this in certain corner cases
--> and it should not be a required behavior, so cases will
--> arise in which continuous flooding will happen.
--> 
--> However, there are some natural limiting factors where some
--> higher layer protocol is involved - depending on the need
--> for HostB to eventually ACK at the higher layer for frames
--> it receives from HostA.  Consequently, HostA will - at some
--> point - stop sending frames to HostB until is has received
--> something from HostB in return.
--> 
--> There may be some very small delay between the time that
--> HostA starts getting replies from HostB, and the time when
--> RBridgeA receives (and acts on) an update from RBridgeB.
--> During that time, some degree of flooding may continue.
--> 
--> I know of no reason why this would not also happen if we
--> were to replace RBridges with IS-IS routers.

After thinking a little further about this, I must conclude
that the last sentence above is not correct, as stated and 
without further amplification.

I thought it made a good "short answer", but it does not.

Strictly speaking, the statement might be true for flooding
between RBridges.  Even in this limited sense, however, the
amount of flooding required would be much less, since the 
exposure to L2 addresses would be limited to the addresses
of the local IS-IS routers on any single shared media.

In terms of flooding into the network via egress RBridges,
clearly this would not happen if the RBridge was replaced
by an IS-IS router.

Consequently, notwithstanding the potential mitigation 
techniques and factors, the extent of flooding in the case
pointed out by Wojtek Paprowicz could be much worse than 
would be the case without the interactions between bridge
learning, STP and the SPF computation.  

That is, if there was an additonal delay in "learning" as
a result of requiring a new SPF computation.

My understanding of how we will use SPF routing in general, 
however, is that an SPF computation should not be required 
for addition of new destination reachability information,
as long as the SPF computation to the egress RBridge has 
previously been completed (and we have not also received
an indication that inter-RBridge topology has changed).
Instead, the new entry would simply be added as a "learned"
destination associated with a specific egress RBridge for
which a shortest path has already been determined.

Consequently, an SPF computation would only be required if
it has not previously been done for the egress from which
ingress RBridges have "learned" a new destination address.

The question then gets back to how likely is this scenario
and - assuming it is likely enough to be a problem - does
it make sense to do something about it (e.g. - use a shorter 
delay value) in computing an SPF for "learned" destinations? 

Since, in the worst case, an SPF computation might not have
been completed for the specific egress RBridge from which a
new destination was learned, other RBridges (that might need
to forward frames toward that egress) would either have to
perform that computation very quickly, or would flood frames 
associated with that (and possibly many other) destination(s)
throughout the entire broadcast domain.

As that should happen - at most - one time for each egress 
RBridge, this does end up making the likelihood that it may
happen comparable (within the RBridge campus) to what it 
would be if RBridges were replaced with routers.

The potential for longer term flooding throughout the entire
broadcast domain, however, argues that SPF computations MUST 
be performed each time a new RBridge is discovered and that - 
at least initially - flooding may need to be inhibited until 
shortest paths have been computed to all known RBridges.

In addition, it may be necessary to always inhibit flooding
(via the IRT) whenever a new RBridge is discovered.  But that
is a matter for further study...

--> 
--- [SNIP] ---

From: "Gray, Eric" <[email-masked]>
To: "'Wojtek Paprowicz'" <[email-masked]>
Date: Wed, 1 Feb 2006 13:38:03 -0500 
Cc: "'Developing a hybrid router/bridge.'" <[email-masked]>
Subject: Re: [rbridge] Unnecessary flooding through ST
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5621

Wojtek Paprowicz, 

	These are good points you bring up.

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Wojtek Paprowicz
--> Sent: Wednesday, February 01, 2006 9:15 AM
--> To: [email-masked]
--> Subject: [rbridge] Unnecessary flooding through ST
--> 
--> Hello,
--> 
--> I would like to ask all of you a question which is very 
--> important to me. Basically, Rbridges run IS-IS but not
--> only. They use spanning tree (ST) for, among others,
--> broadcast transmission.
-->

In order to avoid potential confusion, we are trying to use
the term "Ingress RBridge Tree" as opposed to "Spanning Tree"
in this case.

This tree would be used for flooding, broadcast and possibly
layer 2 multicast (at least as a default mode).

--> However, ST they use is calculated based on the information 
--> stored LSP database. As far as I know, in IS-IS, we have 
--> spfDelay timer which determines the minimum time between 
--> the start of two consecutive SPF computations. Let's assume 
--> a network below:
--> 
--> HostA <> RbridgeA <> RbridgeB <> HostB
--> 
--> Rbridge A received a frame from a host A to unknown 
--> destination (let's assume that host B just attached
--> to the network).
-->

This example is somewhat unusual because HostA has to at 
least suspect that HostB is attached to the network or it 
would not be sending frames to it.

However a similar scenario might arise by moving HostB - 
from, for example, a third port on RBridgeA to the port
on RBridgeB to which you show it attached above.  In
this case, however, frames addressed to HostB will - in
the worst case - be unicast routed to the "old location"
until such time as either HostB is rediscovered at the
"new location" or the existing RBridge table entries for
HostB are "aged out".

Even in this case, it is extremely unlikely both HostA 
and HostB would be unknown.

--> 
--> The receiving Rbridge A floods the frame by means of
--> the ST but also exchanges the information about the 
--> sending host if it was also unknown. As host B just 
--> attached it will be recognized by Rbridge B very soon. 
--> Rbridge B will generate LSP to inform others of a new
--> host. Rbridge A receives this LSP with the info on 
--> host B inside and updates its LSP database. 
-->

This seems correct, assuming both hosts are unknown.

--> The process of exchanging LSPs takes very little time. 
--> However, if Rbridge A received another frame addressed
--> to host B it will flood it again because the SPF 
--> computation didn't take place yet. spfDelay typically 
--> takes 5s (but can be tuned). Does this mean that during
--> that time any transmission from host A to host B in the
--> provided scenario will be carried by means of the ST? 
-->

There are schemes for reducing the impact of flooding for
unknown destinations.  For example, some bridges may limit 
the periodicity for flooding to each unknown destination.

There are problems with doing this in certain corner cases
and it should not be a required behavior, so cases will
arise in which continuous flooding will happen.

However, there are some natural limiting factors where some
higher layer protocol is involved - depending on the need
for HostB to eventually ACK at the higher layer for frames
it receives from HostA.  Consequently, HostA will - at some
point - stop sending frames to HostB until is has received
something from HostB in return.

There may be some very small delay between the time that
HostA starts getting replies from HostB, and the time when
RBridgeA receives (and acts on) an update from RBridgeB.
During that time, some degree of flooding may continue.

I know of no reason why this would not also happen if we
were to replace RBridges with IS-IS routers.

-->
--> In other words, Rbridge A will be flooding the network  
--> with frames from host A to host B for maximum 5s or less, 
--> if the spfDelay timer was triggered earlier, till it re-
--> computes its routing and forwarding table.
-->

It may turn out that we can work with a smaller value for
a delay timer in computing shortest paths.

Also, as a mitigating factor, it is worth noting that the
use of an SPF routing protocol will ensure that all RBridges 
(at least within a common VLAN context) are updated at about 
the same time when any new destination is learned by any of 
those same RBridges.  This means that it is not necessary
for each of N-1 RBridges to flood at least one frame for all
destinations "discovered" at an Nth RBridge - assuming full
connectivity among N RBridges.

Consequently, this should result in less flooding in densely 
connected RBridge topologies.

Finally, some people within the working group are working to
define optimizations that will further reduce the need for
flooding, as well as potentially reduce the use of the entire
IRT (Ingress RBridge Tree) in the multicast case.

--> 
--> I will be very thankful for your explanation on that. 
--> Please forgive me if I have misunderstood some aspects 
--> of Rbridges and troubled you unnecessarily.
--> 
--> ------------------------
--> With kind regards,
--> 
--> Wojtek Paprowicz
--> student of the University of Science and Technology AGH
--> Cracow, Poland
--> ------------------------
--> 
--> 
--> -- 
--> Wysokie Obroty Magazyn - nowy miesiecznik motoryzacyjny. 
--> Pierwszy numer juz w sprzedazy.
--> Wiecej informacji na: http://auto.gazeta.pl/auto/0,0.html
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Wed, 1 Feb 2006 15:14:43 +0100
From: Wojtek Paprowicz <[email-masked]>
To: [email-masked]
Subject: [rbridge] Unnecessary flooding through ST
Reply-To: Wojtek Paprowicz <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2030

Hello,

I would like to ask all of you a question which is very important to me. Basically, Rbridges run IS-IS
but not only. They use spanning tree (ST) for, among others, broadcast transmission.
However, ST they use is calculated based on the information stored LSP
database. As far as I know, in IS-IS, we have spfDelay timer which
determines the minimum time between the start of two consecutive SPF
computations. Let's assume a network below:

HostA <> RbridgeA <> RbridgeB <> HostB

Rbridge A received a frame from a host A to
unknown destination (let's assume that host B just attached to the
network).

The receiving Rbridge A floods the frame by means of
the ST but also exchnages the information about the sending host if it
was also unknown. As host B just attached it will be recognized by
Rbridge B very soon. Rbridge B will generate LSP to inform others of a
new host. Rbridge A receives this LSP with the info on host B inside
and updates its LSP database. The process of exchanging LSPs takes very
little time. However, if Rbridge A received another frame addressed
to host B it will flood it again because the SPF computation didn't
take place yet. spfDelay typically takes 5s (but can be tuned). Does this mean that
during that time any transmission from host A to host B in the
provided scenario will be carried by means of the ST? In other words,
Rbridge A will be flooding the network with frames from host A to host
B for maximum 5s or less, if the spfDelay timer was triggered earlier,
till it re-computes its routing and forwarding table.

I will be very thankful for your explanation on that. Please forgive me
if I have misunderstood some aspects of Rbridges and troubled you
unnecessarily.

------------------------
With kind regards,

Wojtek Paprowicz
student of the University of Science and Technology AGH
Cracow, Poland
------------------------

-- 
Wysokie Obroty Magazyn - nowy miesiecznik motoryzacyjny. Pierwszy numer juz w sprzedazy.
Wiecej informacji na: http://auto.gazeta.pl/auto/0,0.html