Subject: [rbridge] Additioanla clarification Abridges port types Re: A question about (R)STP and routing protocol / requestfor comments to Abridges draft

From: robey at huawei.com (robey)
Date: Mon, 06 Mar 2006 11:27:21 +0800

Hi, Guillermo,

I have the following questions to ask for you about the Abridge draft:

(1) In one part of the daft it said ?Abridges overcome Rbridges L2 network size restrictions allowing applicability to very large Ethernet campus networks while maintaining zero configuration and high performance?,But I know when Abridges are applied in core network, you have to do some configuration, e.g. determine which abridge is edge bridge (do you want to each abridge is edge bridge, so don?t need to configure?),so how  can we maintain zero configuration? .Otherwise in other part of the draft it said ?The parameters to  configure are those common to RSTP, such as selection of the Root Bridge and configuration of the Backup Bridges for the region and their priorities.?. (2) In the section 4.8,it describes the following:?-The bridge ID of the destination is translated to the  port MAC destination address of the destination Abridge at the internal Abridge table. - The frame is encapsulated with an external L2 header with  Destination Bridge ID.?I don?t know when port MAC destination address of the destination Abridge can be used in routing function? Does one destination Abridge have one or many port MAC destination address? (3) In the section 4.8,it describes the following: ?Abridges only forward a frame received at a designated port, upstream, via the root port. The L2 external destination address can be the Destination Bridge ID itself?. I think when one switch receive in-coming data packets, it will forward data packets base ? destination address? and FID entries (also called FDB entries),so why doesn?t AMSP create FID entries in terms of root port ID and egress bridge MAC address previously? Hope you help me to clarify the above questions. Thank you much! Robey 

----- Original Message ----- 
From: "Guillermo Ib??ez" <gibanez at it.uc3m.es>
To: <zhaisuping at huawei.com>
Cc: <rbridge at postel.org>
Sent: Tuesday, February 28, 2006 11:32 PM
Subject: [rbridge] Additioanla clarification Abridges port types Re: A question about (R)STP and routing protocol / requestfor comments to Abridges draft

> 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  
>>  
>>
>>>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
>>>
>>>
>>>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-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.
>>>
>>>    
>>>
>>>>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: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Mon, 06 Mar 2006 10:56:53 +0100

robey wrote:

>(1) In one part of the daft it said ?Abridges overcome Rbridges L2 network size restrictions allowing applicability to very large Ethernet campus networks while maintaining zero configuration and high performance?,But I know when Abridges are applied in core network, you have to do some configuration, e.g. determine which abridge is edge bridge (do you want to each abridge is edge bridge, so don?t need to configure?),so how  can we maintain zero configuration? .
>
By default all Abridges are edge bridges, transit Abridges are a subset 
functionally of edge Abridges. As in current spanning tree protocols, 
mechanisms operate at port level. A port detecting STP or RSTP BPDUs 
selfconfigures in Acces port mode, then that Abridge will work as edge 
bridge. A non edge (or transit) Abridge is an Abridge with no ports 
selfconfigured as Access ports, all ports selfconfigured as Core ports.

>Otherwise in other part of the draft it said ?The parameters to  configure are those common to RSTP, such as selection of the Root Bridge and configuration of the Backup Bridges for the region and their priorities.?. 
>
>(2) In the section 4.8,it describes the following:?-The bridge ID of the destination is translated to the  port MAC destination address of the destination Abridge at the internal Abridge table. - The frame is encapsulated with an external L2 header with  Destination Bridge ID.?I don?t know when port MAC destination address of the destination Abridge can be used in routing function? Does one destination Abridge have one or many port MAC destination address? 
>
It might be done in both ways: many MACs of ports or a single bridge ID. 
The former requires learning of every corresponding MAC or port at 
corresponding tree branch. The later looks simpler, although a bit more 
different to current routing  in standard bridges, but the result and 
compatibility is the same.

>(3) In the section 4.8,it describes the following: ?Abridges only forward a frame received at a designated port, upstream, via the root port. The L2 external destination address can be the Destination Bridge ID itself?. I think when one switch receive in-coming data packets, it will forward data packets base ? destination address? and FID entries (also called FDB entries),so why doesn?t AMSP create FID entries in terms of root port ID and egress bridge MAC address previously? 
>
Yes. I forgot to mention it explicitly.

>Hope you help me to clarify the above questions. Thank you much! Robey 
>

-- 
Prof. Dr. Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid
http://www.it.uc3m.es/netcom/
609177932

---

From: robey at huawei.com (robey)
Date: Tue, 07 Mar 2006 09:56:17 +0800

Hi,Guillermo,
See my interleaving opions.
Thank you much!
Robey

----- Original Message ----- 
From: "Guillermo Ib??ez" <gibanez at it.uc3m.es>
To: "Developing a hybrid router/bridge." <rbridge at postel.org>
Sent: Monday, March 06, 2006 5:56 PM
Subject: Re: [rbridge] Additioanla clarification Abridges port types Re: A question about (R)STP and routing protocol / requestfor comments to Abridges draft

> selfconfigured as Access ports, all ports selfconfigured as Core ports.
I agree with your explanation.

> compatibility is the same.

Do you mean if using many MACs of ports Source address learning  have to be proceeded about source address of external hearder? But in section 6.2 it says " no address learning is used".Otherwise as you pointed address learning is not feasible in asymmetric spanning trees environment.

> Yes. I forgot to mention it explicitly.

Ok, you can explain it in the Abridge draft clearly.
Otherwise, on the one hand one part of the draft says no address learning is need ,on the other hand other part of the draft says address learning has to be proceeded.
Although I know you are right based your real meaning, but hope you can describe this exactly.e.g. in section 6.2 you can say " no address learning is needed in the core ports of core layer.

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Tue, 07 Mar 2006 10:40:34 +0100

I agree that the text in the draft is somewhat misleading regarding 
learning in the core. Learning occurs in the Acces side of the Abridges 
and does not in the Core side.
I will state more sharply these issues in next draft version.
Regards
Guillermo

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Tue, 14 Mar 2006 12:07:51 -0500

Hi All,

I was wondering which VLAN tag will there be (if there will be any) on the
encapsulated packets.

Thanks in advance for your answers.

With regards,

Saikat

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 14 Mar 2006 10:08:12 -0800

Do you mean on the outside header? I was assuming no tag. We want all 
bridges that might
be on an intermediate link to be willing to forward the packet.

But now that you asked...I suppose it's possible that there might be a 
link where bridges
might do something weird if there is no tag (as in, add a tag, or refuse 
to forward it).
I guess on a link like that, there would have to be a tag.

The outer header is really a hop-by-hop header, so it should be whatever 
is appopriate to
that hop. In theory we could mix media, and have an intermediate link 
which isn't even Ethernet,
say it is link type L,
in which case the outer header would be an L header.

At any rate, if an intermediate bridge really did decide to add a VLAN 
tag to the outer header,
the next RBridge will remove the outer header anyway, and generate a new 
outer header for
the next hop.

Radia

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Tue, 14 Mar 2006 13:31:38 -0500

> -----Original Message-----
> From: Radia Perlman [mailto:Radia.Perlman at sun.com]
> Sent: Tuesday, March 14, 2006 1:08 PM
> To: saikat at seas.upenn.edu; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] VLAN tag for the encapsulated packets
> 
> Do you mean on the outside header? 

Yes.

> I was assuming no tag. We want all bridges that might be on an
> intermediate link to be willing to forward the packet.

I have a basic doubt about it. My understanding is (and this could be plain
wrong; please correct me if that is so) that there is one instance of
spanning tree per VLAN ID. Then do bridges also create another spanning tree
instance for the "blank ID"? If they do not, which spanning tree would they
use for a packet with no VLAN tag? The issue is that if there is no entry in
the forwarding tables for the legacy bridges, then the encapsulated packet
needs to be broadcast; in that case in order to avoid a loop, one perhaps
needs to ensure that either (i) the broadcast packet is carrying a VLAN ID
(which could be put in by the legacy bridges) so that the packet always goes
along a given spanning tree, or (ii) the superposition of the different
spanning trees is still a spanning tree. Otherwise if the packet goes from
one spanning to another spanning tree, then loops are possible.

> I guess on a link like that, there would have to be a tag.

Isn't there a significant configuration burden (at least similar to VLAN
configuration)? E.g., how will an RBridge know which VLANs are present in
the legacy LAN it is connected to? The second problem is that a given VLAN
may not connect two RBridges and thus, depending up on the next hop, the
current RBridge may need to choose different VLAN IDs. Which then means that
RBridges need to maintain different forwarding tables (e.g., for
"link-cost") per VLAN. Is that how the system work?

> in which case the outer header would be an L header.

I agree.

> the next RBridge will remove the outer header anyway, and generate a new

Yes, but the issue is with connectivity. If an intermediate legacy bridge
adds a VLAN ID, is it guaranteed that the next RBridge would get the
(encapsulated) packet (i.e., is it possible that the legacy bridge puts in a
VLAN ID whose span does not include the next RBridge?)?

Thanks.

Saikat

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 14 Mar 2006 10:39:59 -0800

Saikat Ray wrote:

>instance for the "blank ID"? 
>
Just want to clear up this misunderstanding. There is one spanning tree 
per ingress RBridge.
This spanning tree is then pruned according to VLANs, as well as IP 
multicast addresses.

So the actual spanning tree is selected based on the "ingress RBridge" 
specified in the shim header.
This spanning tree defines outgoing ports. Then, for each outgoing port 
(for this particular spanning tree),
there is a list of VLANs reachable through that port in this spanning 
tree, as well as IP multicasts.

So, that means if there is a VLAN A packet that is introduced into the 
campus by RBridge R1, the
shim header will indicate "R1". Some RBridge R2, in the center of the 
campus, receives the encapsulated
packet via port P1, say. R2 first says "is P1 the correct in-link for 
the "ingress R1" spanning tree? If not,
R2 drops the packet. If yes, then R2 will forward the packet onto some 
subset of the ports that are
indicated as outgoing for the ingress-R1-spanning tree. Let's say that 
in the Dijstra calculation that
calculates the ingress-R1 spanning tree, R2 concludes that ports P2, P7, 
and P8 are outgoing ports
for that spanning tree (with P1 the incoming port for that spanning 
tree). R2 has also marked that
there are VLAN A links reachable via P7 and P8, but not P2. THerefore, 
R2 will forward the
packet onto P7 and P8.

Hope that's understandable. Otherwise I'll have to draw those little 
ASCII pictures, which I hate drawing (and
only slightly less hate reading). :-)

Radia

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Tue, 14 Mar 2006 13:55:07 -0500

> This spanning tree is then pruned according to VLANs, as well as IP

This is at the level of RBridges (i.e., viewing the legacy LANs as "links"),
right? My concern was about a given legacy LAN segment (which is a single
"link" at the level of RBridges). Suppose that there are two VLANs on this
legacy LAN, VLAN1 and VLAN2. Now there are two RBridges, R1 and R2,
connected to this legacy LAN. Moreover, suppose that the "physical link"
that connects R2 to this legacy LAN (i.e., to some legacy bridge) is on
VLAN2, but not on VLAN1. Then, what happens when R1 sends an encapsulated
packet to R2 with
i) No VLAN ID, and
ii) With VLAN ID set to VLAN1?

And, finally what happens when R1 sends an encapsulated packet to R2 with no
VLAN ID and the legacy bridges on this legacy LAN do not know about the
location of R2?

Isn't there a possibility that R2 would not get the packet in the previous
scenarios?