Subject: [rbridge] loops in trill networks

From: loa at pi.se (Loa Andersson)
Date: Tue, 11 Oct 2005 15:23:09 +0200

All,

this might be an old discussion, but it is some time since it
look at it. What do we do in trill networks about transient
loops, i.e. if use link state protocols there is a possibility
that we have transient loops. With no TTL mechanisms those looping
frames could cause quite a bit of problem.

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson at acreo.se
                                            loa at pi.se

---

From: mike at linx.net (Mike Hughes)
Date: Tue, 11 Oct 2005 14:30:44 +0100

> frames could cause quite a bit of problem.

Unless I've missed something, or things have changed overnight, there is a
TTL provided in the SHIM header.

Mike
-- 
Mike Hughes     Chief Technical Officer  London Internet Exchange
mike at linx.net   http://www.linx.net/
     "Only one thing in life is certain: init is Process #1"

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 11 Oct 2005 07:07:07 -0700

There is, and that's what it's there for.

Joe

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

---

From: loa at pi.se (Loa Andersson)
Date: Tue, 11 Oct 2005 16:22:41 +0200

Oh, yes it is true ...

but I thought that a trill network could consist of a mixed
of rbridges and the type of bridges that exist today, if that
is the case you can possibly form the loop over only non-rbridges

but I'm not up to speed on this, there might be a way to handle
this also

/Loa

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

-- 
Loa Andersson

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 11 Oct 2005 08:26:19 -0700

> is the case you can possibly form the loop over only non-rbridges

The conventional bridges have a spanning tree, which is what already
prevents such loops currently.

Think of the path between two nodes (hosts, routers, etc. - anything
that sources/sinks L2 frames) as having three components (at most):

node--->(bridgepath1)----(rbridgepath)----(bridgepath2)--->node

the ingress (bridgepath1) and egress (bridgepath2) conventional bridge
paths use spanning trees, so they can't have loops.

The rbridge uses the TTL, so it can't have a loop at its layer. Even
when it tunnels over conventional bridges ('inside' the rbridge, in a
sense), those can't have loops because they're spanning-tree.

The combination of spanning tree in all bridge paths and TTL in the
rbridge logical path prevents loops in the node-node path.

Joe

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 11 Oct 2005 09:44:05 -0700

There's nothing an RBridge can do about loops consisting of just bridges.
Which is why it's good to partition the spanning trees formed by the
bridges so that the remaining spanning trees are as small, and therefore
as stable, as possible.

RBridges are like routers. They sit at a layer above bridges. The bridges
form what looks like a single link to the RBridges. If there are a bunch
of bridges connecting a bunch of segments, all the RBridges attached to
that portion of the network see that bridged segment as a single link.

Radia

---

From: akatlas at gmail.com (Alia Atlas)
Date: Tue, 11 Oct 2005 10:41:29 -0700

What about potential frame reordering
during the routing convergence? Is this a concern?

Alia

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/rbridge/attachments/20051011/54202245/attachment.html

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 11 Oct 2005 11:03:01 -0700

I'm not sure what protocols there are that need absolute ordering 
guarantees.
RSTP can reorder sometimes after a topology change, so apparently
occasional reordering is not considered a problem.
All the IETF protocols, I believe, are designed to withstand some packet
reordering (and should, in my opinion, any well designed protocol).

Radia

Alia Atlas wrote:

> On 10/11/05, *Radia Perlman* <Radia.Perlman at sun.com 
> <mailto:Radia.Perlman at sun.com>> wrote:
>
>     >>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa at pi.se
>     <mailto:loa at pi.se>> wrote:
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>rbridge at postel.org <mailto:rbridge at postel.org>
>     rbridge at postel.org <mailto:rbridge at postel.org>

---

From: akatlas at gmail.com (Alia Atlas)
Date: Tue, 11 Oct 2005 11:17:48 -0700

> I'm not sure what protocols there are that need absolute ordering

Likewise, but I thought that Ethernet had that constraint.

> occasional reordering is not considered a problem.

It might be useful to have a small amount of text about that.

> reordering (and should, in my opinion, any well designed protocol).

Sure - anything on top of IP isn't an issue. My concern was other stuff.

Alia

Radia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/rbridge/attachments/20051011/116becef/attachment.html

---

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Tue, 11 Oct 2005 21:09:54 +0200

--On tirsdag, oktober 11, 2005 11:17:48 -0700 Alia Atlas 

> Sure - anything on top of IP isn't an issue.  My concern was other stuff.

Reordering (anything that places a packet more than 3 places out of its 
proper position in the TCP stream) will trigger TCP duplicate acks, and 
therefore retransmissions.

These play hell with performance.

No numbers......

---

From: akatlas at gmail.com (Alia Atlas)
Date: Tue, 11 Oct 2005 13:34:13 -0700

> These play hell with performance.

Sure. But we live with these issues today on IP networks during a network
convergence event. Therefore, it seems reasonable that the IP traffic could
live with the same issues between RBridges during a convergence event there.

The other aspect of this is having acceptable load-balancing such that
micro-flows
don't get reordered - but we beat that to death a while ago.

Alia

No numbers......
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/rbridge/attachments/20051011/f7865c96/attachment.html