Subject: [rbridge] Setting initial "hop count" value

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 02 May 2007 09:18:50 -0700

We didn't say what the initial value of the "hop count" field should be.

One tempting thing would be to set it to the computing number of hops to
the egress RBridge, since the ingress RBridge knows how long the path is 
(based on
computation from the link state database). It would be easy for an 
RBridge to
include not just the next hop to the egress RBridge, but the hop count 
as well,
so that it would know how to set the hop count field.

However, layer 3 people these days do various clever "detour" things 
when they
can't reach the next hop, so that packets can still get to the 
destination while
the routing algorithm is converging. So the hop count could need to be 
more than
what the ingress guy thinks.

But I think it's a good idea for multicast for the ingress RBridge to 
set the initial
hop count to be equal to the maximum length from that RBridge to any 
other RBridge
(in the selected tree).

We even could be clever and an RBridge in the core that is forwarding on 
various branches
could decrement the hop count by more if it knows that some branch of 
the chosen
distribution tree needs a smaller count in order to reach to the ends of 
that branch.

This would make multicast even safer.

At any rate, it's always seemed a bit weird to have a field like "TTL" 
in IP without
saying in the spec what to set it to. We don't have to make the 
suggestion a MUST, but it would
be nice to give some recommendation in the TRILL spec about what to set 
it to.

Comments?

Radia

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 2 May 2007 09:37:15 -0700

Radia,

I am sympathetic with the proposal.

There is an interesting paper on the topic that we should all read to be
informed

http://www.ieee802.org/1/files/public/docs2006/aq-seaman-exact-hop-count
-1206-01.pdf

-- Silvano

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Radia Perlman
> Sent: Wednesday, May 02, 2007 9:19 AM
> To: rbridge at postel.org
> Subject: [rbridge] Setting initial "hop count" value
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 2 May 2007 12:40:23 -0500

Radia,

	So, it MUST be clear at this point that it would have 
been a BAD idea to have suggested a value for TTL in IP back
when the initial RFC was first written.  A reasonable value
- back then - might have been 4 or 8.  After all, 16 was 
thought to be the same as infinity in some routing protocols
defined at an even later date.

	I agree that - at this point - we might be in a better
position to make reasonable guesses (such as you propose),
but we should be cautious.  The reason why I suggest this is
that we are talking about potentially defining a default that
MAY be set in any deployed RBridge implementation and may end
up being unreasonable in some (possibly near-future) usage.

	Hence I suggest we phrase any such recommendation as 
carefully as possible - to allow for a subsequent discovery
that some value outside of our recommendation is better for
real-world deployments.

	Also, we should avoid being too loose in defining the
"clever" things an implementation MAY do, in order to avoid 
encouraging conflicting interpretations that MAY lead to 
non-interoperable implementations.

	All of those qualifications made, I would suggest that 
it may be sufficient to set the hop count (at the ingress) to 
the distance (in hops) to the appropriate egress(es) - plus
some increment (where the increment might be 2, for instance).
We also then need to specify the usual behavioral requirements
(such as that each RBridge MUST decrement the hop-count by at 
least one).

	Also, these days, it's quite common for implementations
to be able to change things that might previously have been
"cast in stone" using a simple firmware (or flash) upgrade.  

	So, as long as we include the appropriate language in 
suggestions we make, it SHOULD be okay to make them.

--
Eric Gray
Principal Engineer
Ericsson  

> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Wednesday, May 02, 2007 12:19 PM

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 02 May 2007 12:11:53 -0700

I disagree with optimizing hopcount. It's intended to break loops; if
you're looping at all, you're already not optimizing. I'd leave it at
the max value and allow its safety to be derived from loop-breaking, not
optimization.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 02 May 2007 12:13:28 -0700

PS - Bob Briscoe uses similar logic in his re-feedback concept from
Sigcomm 2005, which he discusses in his 'flow rate fairness' I-D
(briscoe-tsvarea-fair).

Interesting doesn't mean conservative or useful at this point ;-)

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://mailman.postel.org/pipermail/rbridge/attachments/20070502/a5b490b2/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 02 May 2007 12:24:32 -0700

FWIW, IMO, the TTL ought to be:

	SHOULD be max-val
	MAY be operator set, either to optimize or
		for scoping (as with IP TTL)

Note that it's not IP that generally uses scoping, but only multicast. I
don't see why IP multicast scoping maps to our situation, so I don't see
why any choice but "max-val" is appropriate.

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://mailman.postel.org/pipermail/rbridge/attachments/20070502/b5782596/signature.bin

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 2 May 2007 14:42:43 -0500

Joe,

	Hop-count - like TTL - is not intended to "break loops."
It is intended to mitigate the impact of looping PDUs (frames
or packets).

	For this reason, setting a low value can be extremely 
useful for multicast, flooded or broadcast traffic.  A value
set to the greatest possible value will eventually cause all
PDUs that are looping to be dropped, but this may be after
the traffic has been multiplied many times.

	However, you raise an interesting point.  As I believe
we are currently considering it, multiple destination frames
(multicast, flooded and broadcast) are intended to be sent on
a tree that essentially has the properties of a spanning tree. 
That being the case, if hop-count is not intended to mitigate
looping of multi-destination frames, then I agree with your
point and feel that it might NOT be a good idea to contrain
the hop-count value based on the radius of the TRILL network.

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
> Sent: Wednesday, May 02, 2007 3:12 PM
> To: Radia Perlman
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Setting initial "hop count" value
> 
> * PGP Signed: 05/02/2007 at 09:11:54 PM
> * Joe Touch <touch at isi.edu>
> * 0x89A766BB (L)
> 
>

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 02 May 2007 13:26:39 -0700

Eric Gray (LO/EUS) wrote:
> useful for multicast, flooded or broadcast traffic.

Any TTL > 0 can cause any duplicated packet to expand to consume all
resources anyway; you can't assume that the duplication cycle is larger
than 1. That's why we rely on other mechanisms to avoid copy loops,
notably strict tree structures which never have looping transients.

As a result, the only benefit to TTL is to prevent unicast packets from
looping in the system forever OR to constrain the reach of a packet
(unicast or multi/broadcast). The former is sufficiently accomplished by
a max-ttl, and the latter should not be relevant in our system.

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://mailman.postel.org/pipermail/rbridge/attachments/20070502/6922c202/signature.bin

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 2 May 2007 15:31:09 -0500

Joe,

	How did you arrive at the conclusion that any TTL
greater than zero can cause duplicated packets to consume all
available resources?  This strikes me as an extremely suspect
conclusion...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> From: Joe Touch [mailto:touch at ISI.EDU] 
> Sent: Wednesday, May 02, 2007 4:27 PM
> To: Eric Gray (LO/EUS)
> Cc: Radia Perlman; rbridge at postel.org
> Importance: High
> * PGP Signed: 05/02/2007 at 10:26:40 PM
> 
> 
> * 0x89A766BB

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 2 May 2007 13:37:07 -0700

Eric,

It is a tree only when the topology is stable; in transient is not a
tree. Loops happen during transition.

Joe,

Loops are much more dangerous at layer 2 than at layer 3. I am
sympathetic with Radia that anything we can do to mitigate them is good.

-- Silvano

On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Wednesday, May 02, 2007 12:43 PM
> To: Joe Touch; Radia Perlman

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 02 May 2007 13:48:48 -0700

> available resources?  This strikes me as an extremely suspect

Because you don't limit fanout; any TTL>0 could cause a link to receive
double the planned resources, since the packet could loop back around
once (which is all it takes in that case).

If you do limit fanout, it needs to be a function of the number of hops
that a broadcast might take, where the largest TTL you can tolerate is
max-BW/number-expected-hops. That could easily result in TTL<1, or at
least a TTL<diameter, which ends up meaning your multi/broadcast fails.

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://mailman.postel.org/pipermail/rbridge/attachments/20070502/f8b7430a/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 02 May 2007 13:58:23 -0700

> sympathetic with Radia that anything we can do to mitigate them is good.

This is why we ought to be using a spanning tree for those, and let that
tree be suboptimal and/or converge via means that avoid looping
transients. It's not a good reason to over-tune TTL at L2.

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://mailman.postel.org/pipermail/rbridge/attachments/20070502/b1261aff/signature.bin

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 2 May 2007 15:59:41 -0500

Joe,

	Minimally, every replication costs at least one
hop.  Assuming the usual rule (don't forward if TTL or
hop count would be zero - or less - after decrementing),
a frame/packet would require a non-zero TTL to have any
impact on link resources.

	That aside, in a realistic scenario (where the 
link is not intended just to serve that one replication
point), a single looping stream of traffic initially
takes a very small portion of the available resources 
and only becomes significant after some multiplication
has occurred (usually more than one).

	And the fan-out is naturally restricted to the 
number of interfaces in the replicating device - i.e.
- in a practical application, at most one copy to each 
interface on which replication occurs.  Hence it is a
necessity that a full loop is traversed at least once
(and involving at least one other device) before their
is any multiplication.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Wednesday, May 02, 2007 4:49 PM
> To: Eric Gray (LO/EUS)
> * PGP Signed: 05/02/2007 at 10:48:48 PM
> 
> 
> >> > Old Signed: 05/02/2007 at 10:26:40 PM
> >>
> >>

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 02 May 2007 14:16:00 -0700

Silvano Gai wrote:
...
> sympathetic with Radia that anything we can do to mitigate them is good.

I cannot understand why that would be true. Resources are more
constrained and impact more users at L3.

While mitigating loops is good, I see no reason not to apply what we
know and have learned from L3 here, which is that TTL may matter for
multicast scoping, but it isn't the dominant mitigation for copy loops.
See RFC2365, which lists many reasons for using TTL in multicast, but
doesn't talk about copy loop (e.g., see Sec 3).

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://mailman.postel.org/pipermail/rbridge/attachments/20070502/2030560f/signature.bin

---

From: saikat at seas.upenn.edu ([email-masked])
Date: Wed, 02 May 2007 18:10:01 -0400

> constrained and impact more users at L3.

One reason I have heard is that loops are typically shorter at L2 and 
thus overwhelms the affected nodes more severely (the packet comes back 
to the node more quickly).

---

From: arien.vijn at ams-ix.net (Arien Vijn)
Date: Thu, 3 May 2007 00:26:11 +0200

Hello,

> constrained and impact more users at L3.

[...]

It is absolutely true for self-learning ethernet switches.

Ethernet loops cause station movements. The source mac address of a  
looped frame gets learned behind a looping port. At that moment all  
unicast traffic for that address is send into the loop. That traffic  
causes even more station movements and there you have it.

That is quiet different for layer-3 equipment were looping packets do  
not affect the state of the router(s) forwarding them.

- -- Arien

- --
Arien Vijn
Amsterdam Internet Exchange
http://www.ams-ix.net

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 2 May 2007 16:28:00 -0700

Joe,

> Sent: Wednesday, May 02, 2007 2:16 PM
> To: Silvano Gai
> Cc: Eric Gray (LO/EUS); Radia Perlman; rbridge at postel.org

There are many many reasons. 

1) The problem is with all multidestination frames, but it is
particularly severe with Ethernet Broadcast. The reason is that all the
stations (switches, RBridges, routers, hosts, etc) are mandate to
receive broadcast.

ROUTERS DO NOT PROPAGATE BROADCAST AND THIS IS A HUGE DIFFERENCE BETWEEN
L2 AND L3. 

2) Loop tend to be shorter at layer 2 (few hops, let's say 4)

3) RBridge latency will probably be very low (500 ns)

4) A frame can complete a loop in 2 microseconds

5) the spikes of broadcast traffic will be very intense and will
saturate all the receiving queues of all the stations (again hosts,
RBridges ...)

6) these broadcast frames will sit in front of the IS-IS frames and
contend for CPU resources

7) the ISIS convergence time will get worst. In a limit case, ISIS will
never converge

8) Anyhow, the IS-IS converges times is probably 4 or more order of
magnitude greater than the time it takes a frame to loop.

9) I have seen network coming to a complete stop. The only way to
restart them was to power cycle.

10) As soon as the broadcast storm start, all the host crashes (due to
the broadcast in the RX queues).

It is a doomsday scenario: if you have seen a broadcast storm you don't
want to see another one.

Granted there are measure that have been put in place to limit the
possibility that this happens, for example today bridges have separate
queues for BPDUs, but we still need to be EXTREMELY careful

-- Silvano

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 2 May 2007 16:35:57 -0700

Joe,

> Sent: Wednesday, May 02, 2007 1:58 PM
> To: Silvano Gai
> This is why we ought to be using a spanning tree for those, 

You are not claiming that we need to run the Spanning Tree Protocol,
correct?

and let that
> transients. 

This is not easy. Radia RPF proposal seems a good start, but it is:
- not agreed yet
- Unproven

It is pretty straightforward to use Radia RPF proposal to reduce the
probability of transient loops. If you want to "GUARANTEE" that there
are no transient loops, that is a different story, since it has a
significant state requirement that can impact low end implementation. I
am all for it, but we need to discuss it in a separate thread.

-- Silvano

It's not a good reason to over-tune TTL at L2.

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 02 May 2007 16:36:48 -0700

...
> queues for BPDUs, but we still need to be EXTREMELY careful

All great reasons for not relying on TTLs to bail you out of a storm. A
TTL of N can result in K^N/J copies if it loops through just one
replication point with K outputs with a loop length of J. Given loop
lengths could be 2-3, what TTL is reasonable to prevent this sort of
blowup that isn't going to impact the reachability diameter?

Current ethernet relies on spanning tree to avoid this; why not - as we
originally discussed - rely on spanning tree for broadcasts and
multicasts and then this ceases to be an issue...?

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://mailman.postel.org/pipermail/rbridge/attachments/20070502/d64c41d6/signature.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 2 May 2007 16:42:02 -0700

Joe,

> Sent: Wednesday, May 02, 2007 4:37 PM
> To: Silvano Gai

You miss one point.

The Spanning Tree Protocol has an interlock mechanism that ABSOLUTELY
guarantees no transient loops.

A Spanning Tree based on an ISIS database will not have this interlock
mechanism and transient loops will be possible.

-- Silvano

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 02 May 2007 16:42:31 -0700

...
> You are not claiming that we need to run the Spanning Tree Protocol,

No; I was claiming that there's a legitimate reason to still have a
spanning tree inside the campus.

> am all for it, but we need to discuss it in a separate thread.

Agreed; I'm not convinced that such transients aren't OK if they exist
with conventional implementations. Remember that rbridges aren't
intended to scale beyond current implementations, which means that
however existing implementations support spanning trees and deal (or
don't) with transient loops should map here just fine.

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://mailman.postel.org/pipermail/rbridge/attachments/20070502/e6447755/signature.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 2 May 2007 16:46:33 -0700

Joe

> Sent: Wednesday, May 02, 2007 4:43 PM
> To: Silvano Gai

Agreed, we are in synch.

> with conventional implementations. 

They don't. Today the Spanning Tree protocol never generates a transient
loop. 

-- Silvano

Remember that rbridges aren't

---

From: pfr at info.ucl.ac.be (Pierre Francois)
Date: Thu, 03 May 2007 02:01:31 +0200

All,

Use draft-ietf-rtgwg-ordered-fib-00.

Just kidding ;-)

Pierre.

Silvano Gai wrote:
>>> It is a doomsday scenario: if you have seen a broadcast storm you
>>>       
> don't
>   
>>> want to see another one.
>>>
>>> possibility that this happens, for example today bridges have
>>>       
> separate
>   
>> All great reasons for not relying on TTLs to bail you out of a storm.
>>     
> A
>   
>> Current ethernet relies on spanning tree to avoid this; why not - as
>>     
> we
>

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 2 May 2007 17:32:56 -0700

We discussed that possibility, but unfortunately
draft-ietf-rtgwg-ordered-fib-00 does not apply to multicast

-- Silvano

> From: Pierre Francois [mailto:pfr at info.ucl.ac.be]
> Sent: Wednesday, May 02, 2007 5:02 PM
> To: Silvano Gai
> Cc: Joe Touch; rbridge at postel.org; Radia Perlman

---

From: pfr at info.ucl.ac.be (Pierre Francois)
Date: Thu, 03 May 2007 02:52:55 +0200

Silvano,

You can expand ofib to avoid loop storms in multicast.
Very roughly, the idea is that you (a node) update the incoming 
interface that suceeds the rpf check for a given S,G after the ones that 
are below you in the initial S,G tree.
In other words, you order the transition of nodes in the tree from the 
leaves towards the root.

Sorry to be so short, but I've got a ph. thesis to submit by tomorrow ;-)

Cheers,
Pierre.

Silvano Gai wrote:
>>>> All great reasons for not relying on TTLs to bail you out of a
>>>>         
> storm.
>   
>>> A
>>>
>>>       
>>>> replication point with K outputs with a loop length of J. Given
>>>>         
> loop
>   
>>>> lengths could be 2-3, what TTL is reasonable to prevent this sort
>>>>         
> of
>   
>>>> Current ethernet relies on spanning tree to avoid this; why not -
>>>>         
> as
>   
>>> we
>>>
>>>       
>>> The Spanning Tree Protocol has an interlock mechanism that
>>>       
> ABSOLUTELY
>   
>>> A Spanning Tree based on an ISIS database will not have this
>>>       
> interlock
>

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 03 May 2007 07:26:22 -0700

...
> mechanism and transient loops will be possible.

My point is that maybe this means ISIS-based spanning tree isn't
appropriate. Multicast/broadcast cannot be effectively contained by TTL
alone.

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://mailman.postel.org/pipermail/rbridge/attachments/20070503/fd7c6233/signature-0001.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 3 May 2007 07:33:30 -0700

Joe,

> Sent: Thursday, May 03, 2007 7:26 AM
> To: Silvano Gai
as
ABSOLUTELY
interlock
> appropriate. Multicast/broadcast cannot be effectively contained by
TTL

You are right, IS-IS spanning tree alone is not enough, we need
something like Radia RPF proposal and it must be mandatory.

See my next email

-- Silvano

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Thu, 3 May 2007 09:48:18 -0500

Silvano,

	I am clearly missing part of these discussions, and I doubt 
I am alone in doing so.

	First, what exactly is the "Radia RPF" proposal that you
mention in another thread of discussion, that you also say is 
both "unproven" and "not agreed" to, AND why would we use that
in lieue of some form of existing spanning tree protocol for
the multi-destination case?

	And, second, I was under the strong impression we were
not planning to use SPF routing for the multi-destination case.
Is that part of the "Radia RPF" proposal?

	Given that (M/R)STP is a proven - loop free - technique
for handling loop prevention in multi-destination traffic for
L2 forwarding, AND that we're not as much concerned about the
use of SPF routing for the multi-destination case, _why_ would
we want to invent some other technique for setting up spanning
trees?

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
> Sent: Wednesday, May 02, 2007 7:42 PM
> To: Joe Touch
> Subject: RE: [rbridge] Setting initial "hop count" value
> 
> Joe,
>

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Thu, 3 May 2007 09:54:23 -0500

Silvano,

	Same question applies here.  It's one thing to say that we
don't run STP in the conventional bridging sense.  We don't run
IS-IS in the conventional IP (or OSI) routing sense, either.  It
is quite another to say that we don't use an existing spanning
tree protocol (perhaps with different BPDUs - e.g. - RBPDUs) and
gain all of the advantages of existing implementation, and field
deployment experience associated with it.

	Are you (and probably Joe) saying that we want to invent
something new here?

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Wednesday, May 02, 2007 7:47 PM
> To: Joe Touch
> > >>> sympathetic with Radia that anything we can do to 
> mitigate them is
> > > good.

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 3 May 2007 07:57:56 -0700

Eric,

> From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com]
> Sent: Thursday, May 03, 2007 7:48 AM
> To: Silvano Gai; Joe Touch

I have resend her proposal to the mailing list in a separate email. You
may want to go back and read the comments of Dino and Sanjaya.

> Is that part of the "Radia RPF" proposal?

Radia proposal is an addendum to 
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03
.txt

That states:

3.4.1. Distribution Tree Calculation 

   RBridges do not use the spanning tree protocol to calculate 
   distribution trees. Instead, distribution trees are calculated based 
   on the link state information, selecting a particular RBridge as the 
   root.  

   Calculation of a tree rooted at Ri is done independently by each 
   RBridge Rn by performing the SPF (Shortest Path First) calculation 
   with Ri as the root without requiring any additional exchange of 
   information.

> we want to invent some other technique for setting up spanning

What you are proposing is different of what is in the current draft.

-- Silvano

loop
of
as
ABSOLUTELY
interlock

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 3 May 2007 08:02:45 -0700

Eric,

>From when I joined this WG all the base protocol drafts have always
assumed that TRILL was using IS-IS to compute what we now call
"Distribution Trees". We changed the names from "source routed tree" to
"distribution tree" and the number of these trees, but never the way
they were computed.

-- Silvano

> Sent: Thursday, May 03, 2007 7:54 AM

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Thu, 3 May 2007 10:16:06 -0500

Silvano,

	That was true, right up until the proposal was made to make
the trees bi-directional.  That - in turn was necessitated by the
proposal to allow some edge RBridges to opt-out of sourcing their
own distribution trees.  At that point, more than a few people
started to think that we were then abandoning the use of SPF for
the multi-destination case.

	The rationale for thinking that is really quite obvious.

	Note that - if you assume a tree computed with X as root,
spanning tree protocol effectively sets up a tree with X as root 
and shortest paths computed from X to all leaf bridges.

	If you assume a bi-directional tree computed with X as root
- even if computed explicitly using SPF routing - that tree is the 
shortest path from one leaf to another only by a happy accident in 
some cases and NOT at all in all other cases.

	If using a bi-directional spanning tree means essentially
abandoning SPF routing, then the advantage you might hope to get
from not using (M/R)STP vanishes in a puff of smoke in comparison
with the cost we can expect to pay to develop an alternative, and
(eventually) make it work.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Thursday, May 03, 2007 11:03 AM
> To: Eric Gray (LO/EUS); Joe Touch
> > > > No; I was claiming that there's a legitimate reason to 
> still have
> a
> > > > > probability of transient loops. If you want to 
> "GUARANTEE" that
> > > there
> > > > > are no transient loops, that is a different story, 
> since it has
> a

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Thu, 3 May 2007 10:16:30 -0500

Silvano,

	What is in the current draft represents a process anomaly.

	As you said, the RPF proposal has not been agreed to, and
should not - therefore - have been added to a working group draft.

	The proposal to simply use (some form of) spanning tree is
not new either, particularly in relationship to multi-destination
distribution.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Thursday, May 03, 2007 10:58 AM

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 3 May 2007 08:31:34 -0700

The RPF proposal is NOT in the current draft, since it is not agreed.

-- Silvano

> Sent: Thursday, May 03, 2007 8:17 AM
> > > > > > It is a doomsday scenario: if you have seen a broadcast
storm
> > you
> > > > don't
> > > > > > want to see another one.
> > > > > >
> > > > > > Granted there are measure that have been put in place to
limit
> > the

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 3 May 2007 08:35:33 -0700

Eric,

> Sent: Thursday, May 03, 2007 8:16 AM

During that discussion I never read anybody proposing to use the
Spanning Tree Protocol.

-- Silvano

> > > > > however existing implementations support spanning trees and
deal
> > (or

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Thu, 3 May 2007 10:52:56 -0500

Silvano,

	Sorry for the confusion, but did you not say (below)
that it is an addendum to version -03 of the protocol draft?

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Thursday, May 03, 2007 11:32 AM

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Thu, 3 May 2007 11:26:43 -0500

Silvano,

	I did some looking, and you are correct.  I mentioned it to
Radia in an off-line discussion on November 1st of last year, in
response to her proposal to make distribution trees bi-directional.  
The discussion was not meant to be off-line, but Radia had excluded
the list in one of her replies.

	I extracted that part of the conversation below.

	Even assuming this was not publicly mentioned previously,
is there a flaw in the argument I made to you just now?

	Possibly I made the mistake of thinking that - because the
argument is inescapably obvious to me - then it must be equally
obvious to the rest of the working group.

	It is worth noting that several of the replies on that thread
("Compromise proposal---allowing tradeoff between computation and 
optimality of delivery") seemed (to me, at least) to assume the use
of STP.

On November 1st, at 3:35 P.M. (EST), Radia Perlman said:
--> I'm talking about a bidirectional tree. Just like with the 
--> spanning tree computed by legacy bridges, packets don't 
--> traverse links twice. A particular bridge B has a root 
--> port and other ports for which it is DB.
--> On the ports for which B is DB, B sends the frame and it 
--> travels further from the root on those paths.
--> It's only on the root port that the frame travels towards 
--> the root, and then when the root receives the frame, it 
--> only sends the frame onto other ports (not the one it got
--> it from).

To which I responded (at 4:43 P.M. of the same day):
->	Is this not a fundamental departure from how Ingress RBridge
-> Trees are expected to work?  My understanding was that an IRT 
-> is uni-directional.
->
->	Also, how does this work in the broadcast/multicast case -
-> unless we are in fact using STP (or a variation of STP)?  If
-> the tree is bi-directional, how does a node on the tree know
-> how to forward flooded traffic without potentially producing
-> a storm?
->
->	If we are in fact using a variation of STP to set up the 
-> shared IRT, how does this differ from existing proposals in
-> the IEEE?

I never received a reply to this note, but Radia did later reply
to Donald Eastlake on the same subject (including the list - see
her post on Sat 11/4/2006 6:23 PM, EST).

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Thursday, May 03, 2007 11:36 AM

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 3 May 2007 09:50:01 -0700

Eric,

I should have said that Radia presented it in Prague and on the mailing
list as a feature to add while going from draft 03 to draft 04

-- Silvano

> Sent: Thursday, May 03, 2007 8:53 AM
> > > > > > > TTL of N can result in K^N/J copies if it loops through
just
> > one
> > > > > > > originally discussed - rely on spanning tree for
broadcasts
> > and

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 3 May 2007 13:49:22 -0700

Eric,

1) There is no doubt that a solution based on some variation of the
Spanning Tree Protocol may be used to compute bidirectional distribution
trees.

2) There is no doubt that such a solution will have no transient loops
and will not need "the RADIA RPF" proposal.

THIS SOLUTION WILL NOT SATTISFY THE STRONG CUSTOMER DEMAND TO ELIMINATE
SPANNING TREE.

If we go that path, it is also clear that there is no need for IS-IS at
all. We just have a set of distributions trees, we can stick an
additional 1Q tag in the frame doing the function of tree selector and
we achieve shortest path, and equal and unequal cost multipath. Do you
agree that there will be no advantage in running the core instance of
ISIS?

Due to the customer requirements I am against running the Spanning Tree
Protocol in TRILL to compute distribution trees.

-- Silvano

> Sent: Thursday, May 03, 2007 9:27 AM
> > > > > > > > It is pretty straightforward to use Radia RPF proposal
to
> > > > > > reduce the
> > > > > > > Agreed; I'm not convinced that such transients aren't OK
if
> > > > > > they exist

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 03 May 2007 14:08:29 -0700

> THIS SOLUTION WILL NOT SATTISFY THE STRONG CUSTOMER DEMAND TO ELIMINATE

TRILL isn't designed to get rid of spanning tree necessarily. It's
designed to overcome the limitations of ST w.r.t. unicast traffic.

There's no point in overcoming ST w.r.t. multicast/broadcast per se. As
Eric noted, if getting rid of ST forces a new solution just for the sake
of avoiding ST (i.e., marketing), it's not a useful position to take.

...
> Protocol in TRILL to compute distribution trees.

Responding to customers is what companies do; here in the IETF, we
believe in rough consensus and running code, and people speak as
individuals, not on behalf of companies or customers ;-)

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://mailman.postel.org/pipermail/rbridge/attachments/20070503/0ebdd3fc/signature.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 3 May 2007 14:27:08 -0700

Joe,

I understand IETF enough ;-) I never said that I was speaking as a
company.
I still believe customer requirements are important.

More inline:

> Sent: Thursday, May 03, 2007 2:08 PM
> To: Silvano Gai

If you have a bunch of distribution trees computed by the Spanning Tree
Protocol let's just use them also for unicast traffic. We put a tag in
the frame to select the distribution tree and we are done.

This completely solves the limitation you mention with respect to
unicast traffic.

Why do we need IS-IS?

Don't tell me is a customer need ;-)

-- Silvano

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Thu, 3 May 2007 16:48:25 -0500

Silvano,

	I am certain I've had this discussion before, but - like 
the other one - possibly not on the list.

	So, I will repeat what I found out in earlier discussion.

	There is a definite advantage to using IS-IS for unicast
forwarding.  That can be independent of how forwarding is done
for the multi-destination distribution tree.  Of course, it is
a different question whether or not it is a good idea for unicast
and multi-destination traffic to use divergent paths - but that
question exists as soon as you allow that multi-destination data
traffic might be sent via a distribution tree not rooted at the 
ingress.

	Note that you've apparently broadened the requirement of
customers (who typically don't make staements about technology
preference, preferring to state requirements in terms of the
the desirable behavior they are looking for).  I doubt that a
customer is telling you that they won't accept a solution that
is based on using spanning tree for a relatively insignificant
portion of the offered traffic load, as long as they get a
solution that makes efficient use of link resources generally.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Thursday, May 03, 2007 4:49 PM
> > > > > > > > > This is not easy. Radia RPF proposal seems a 
> good start,
> > > > > > > but it is:
> > > > > > > > > - not agreed yet
> > > > > > > > > - Unproven
> > > > > > > > >
> > > > > > > They don't. Today the Spanning Tree protocol 
> never generates
> > > > > > > a transient
> > > > > > > loop.
> > > > > > >
> > > > > > > -- Silvano
> > > > > > >

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Thu, 3 May 2007 16:53:42 -0500

Silvano,

	Of course customer requirements are important, but see my
reply on another thread.  Basically, the customer will ask for 
a certain behavior out of the technology - not a specific choice
for the technology itself.

	Naturally, there will be customers with requirements they
base on "belief systems" and imperfect knowledge of the how a
specific technology works (and - more importantly - sometimes 
doesn't work).  As Joe was saying (I think) that is a customer
management issue, not a technology one...

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Thursday, May 03, 2007 5:27 PM
> To: Joe Touch

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 03 May 2007 14:59:43 -0700

Silvano Gai wrote:
...
> This completely solves the limitation you mention with respect to

The point of TRILL was to apply Internet routing to L2. IS-IS is an
example of Internet routing (do we NEED IS-IS? or is it just a
convenient version of Internet routing that can support L2 tags; I think
the latter is more relevant).

As to multicast, I don't see why Internet versions of this aren't
sufficient as well. Internet TTLs aren't the primary means by which
storms are avoided, and shouldn't be here either. However, IF such
storms are that much of a concern, then for the multicast traffic (of
which broadcast is a degenerate case anyway), then using a ST seems like
a fine way to apply existing technology.

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://mailman.postel.org/pipermail/rbridge/attachments/20070503/cd824d51/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 03 May 2007 15:02:00 -0700

> for the technology itself.

Eric is more generous than I w.r.t. customers. IMO, they don't even know
what behavior they want most of the time either.

We (the IETF) build what we think is useful, *whether or not* the
customer wants it. The customer doesn't want congestion control - at
least they don't want it to apply to *their* traffic.

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://mailman.postel.org/pipermail/rbridge/attachments/20070503/55167de4/signature.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 3 May 2007 15:29:15 -0700

Joe,

> Sent: Thursday, May 03, 2007 3:00 PM
> To: Silvano Gai
> sufficient as well. 

Please see my post of yesterday where I explained the differences.

-- Silvano

Internet TTLs aren't the primary means by which

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 03 May 2007 16:11:25 -0700

Silvano Gai wrote:
...
> Please see my post of yesterday where I explained the differences.

You explained that routers do not propagate broadcast, but even a
radius-based TTL can overwhelm the system if there's a loop anyway.

You explained that we need different queues for broadcast and/or
multicast to avoid interference with routing protocols, which is
probably judicious anyway, and is already the case in L2 (e.g.,
broadcast vs. BPDU queues, as you note).

Otherwise, you didn't explain why we can't just use what already works
in the Internet.

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://mailman.postel.org/pipermail/rbridge/attachments/20070503/ca09fceb/signature.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 3 May 2007 17:21:19 -0700

Joe

> Sent: Thursday, May 03, 2007 4:11 PM
> To: Silvano Gai

My message had ten points. You summarized in two, for example, you
complete missed that multicast traffic can be filtered while broadcast
traffic must be received. 

> Otherwise, you didn't explain why we can't just use what already works

I am getting tired of this argument, write a concrete proposal, don't
just say "use what already works in the Internet."

If the Internet has already solved all the issues, why do we need TRILL?

-- Silvano

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 03 May 2007 21:37:34 -0700

...
> traffic must be received. 

That's an endpoint issue, not an L2 forwarding issue.

> just say "use what already works in the Internet."

I did - I proposed existing ST for multicast/broadcast only. You
continue to want to propose something new.

> If the Internet has already solved all the issues, why do we need TRILL?

I already answered that as well. Let me be more clear:

"We do NOT need TRILL to fix anything in either broadcast or multicast".

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://mailman.postel.org/pipermail/rbridge/attachments/20070503/b042d435/signature.bin

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Fri, 4 May 2007 09:59:46 -0500

TRILL-ers,

There appears to be a general acceptance of the idea of having 
bi-directional trees used for distribution of multi-destination 
frame traffic, at this point.

This means that there is necessarily a departure from the unicast
forwarding scheme (based on SPF using IS-IS) for non-unicast and
unknown unicast frame forwarding.

For reasons that have been beaten to death on this list, that is
not necessarily a BAD THING.

Given this general trend, I agree with Joe that using existing STP 
algorithms to establish these bi-directional trees is far better
than starting from scratch with something else - however clever
that something else may be.

The same arguments that hold for using IS-IS (as opposed to just
starting with IS-IS and building something new, or developing an
entirely new SPF routing algorithm), should hold for creation of 
bi-directional L2 distribution trees as well.

Note that while STP and RSTP would create a single spanning tree
for all RBridges in the scope of a single VLAN, MSTP may be used
to create multiple spanning trees - thereby effectively providing
for the "multi-pathing" of multi-destination frames.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Friday, May 04, 2007 12:38 AM
> To: Silvano Gai
> * PGP Signed: 05/04/2007 at 06:37:34 AM
> 
> 
> Silvano Gai wrote:
> > Joe
> ...

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Fri, 4 May 2007 09:10:51 -0700

Eric,

This is a departure of the current consensus as CLEARLY described in:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03
.txt

I oppose using the Spanning Tree Protocol. 
With your proposal RBridge users will have to understand and manage
IS-IS and the Spanning Tree Protocol.

-- Silvano

> Sent: Friday, May 04, 2007 8:00 AM
> To: Joe Touch; Silvano Gai
> Subject: RE: [rbridge] Emerging consensus to use STP for non-unicast?
(was
> - Setting initial "hop count" value)
> 
> TRILL-ers,
>

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Fri, 04 May 2007 11:34:21 -0700

> bi-directional L2 distribution trees as well.

 From what I can see there is no emerging consensus to do such a radical 
change, and it seems to be a complete departure from the TRILL charter 
which starts with 'using an existing link-state routing protocol 
technology.'

While layering or reusing 802.1D might be interesting to explore, I 
suspect there are some hard design issues (whether there is a single STP 
instance across the whole network, or a separate STP instance that just 
include the RBridge overlay.)
In any case, had we proposed that as the TRILL charter when TRILL 
started I am pretty sure the IESG would have just told us to go work in 
IEEE 802.

    Erik