Subject: [rbridge] A question about (R)STP and routing protocol / requ est for comments to Abridges draft

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 27 Feb 2006 14:43:08 -0500

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: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] 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" <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
--> 
--> 
--> > 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,
--> >>>zhaisuping at huawei.com
--> >>>Huawei Technologies Co., Ltd.
--> >>>Tel: +86-10-82836882
--> >>>Fax: +86-10-82836020
--> >>>2006-02-23
--> >>>
--> >>>
--> >>>
--> >>>
--> >>>
--> >>> 
--> >>>
--> >>>---------------------------------------------------------
--> ---------------
--> >>>
--> >>>_______________________________________________
--> >>>rbridge mailing list
--> >>>rbridge at postel.org
--> >>>http://www.postel.org/mailman/listinfo/rbridge
--> >>> 
--> >>>
--> >>>    
--> >>>
--> >>
--> >>  
--> >>
--> >>----------------------------------------------------------
--> --------------
--> >>
--> >>_______________________________________________
--> >>rbridge mailing list
--> >>rbridge at postel.org
--> >>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
--> > rbridge at postel.org
--> > http://www.postel.org/mailman/listinfo/rbridge
--> >
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

---

From: robey at huawei.com (robey)
Date: Tue, 28 Feb 2006 09:48:18 +0800

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" <Eric.Gray at marconi.com>
To: "'Developing a hybrid router/bridge.'" <rbridge at postel.org>
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,

--> 

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