Subject: [rbridge] Unnecessary flooding through ST

From: quasarus at gazeta.pl (Wojtek Paprowicz)
Date: Wed, 1 Feb 2006 15:14:43 +0100

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 02 Feb 2006 20:19:48 -0800

Welcome aboard!

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20060202/c20e839a/signature.bin

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 03 Feb 2006 11:41:04 -0800

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

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Sat, 04 Feb 2006 09:13:32 +0100

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:

>_______________________________________________
>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