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: Tue, 28 Feb 2006 08:22:53 -0500

Robey,

	Great, thanks for the clarification!

--
Eric 

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] 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" <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,
--> 
--> 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
--> --> 
--> _______________________________________________
--> 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
-->