[rbridge] Comments on: http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.txt

[Gray, Eric]

Silvano,

	Please see below...

--
Eric

-- [snip] -- 
--> 
--> Sgai 3> It is very important to say that this protocol must provide a
--> loop free topology for multicast/broadcast under any condition,
including 
--> transient loops, to prevent multicast/broadcast storm.
-- [snip] --

I think I know what you're trying to say here, but "topology" is not
the right word.  This is probably a point of confusion - based on the
way STP works - that you're bringing up and I may need to fix.  I do
not recall using "topology" in this specific context, however (L2 link
topology refers to "physical topology" and specifically to discovery).

What I think you're trying to say is that it is important to say that
the protocol must ensure loop free delivery - particularly in regard
to multicast, broadcast and flooded frames.

I already have agreed that we need to be more explicit about that, and
I will figure out a way to clarify the architecture in this respect.

This cannot go in the section where you point it out, however, as that
section identifies what we plan to use a link-state routing protocol
to accomplish.  Clearly, the "blocking" behavior discussed previously
has nothing much to do with link-state routing.

One question I have to you is: does it make sense to talk about a
"topology change state" in an architecture document where we don't
specifically define a state machine?  I believe that we need to 
make the simple point that protocol specifications need to address
this concern.

Another question I have for you is: does this apply to unicast as
well?  I was under the impression that you agreed that TTL is good
enough for unicast forwarding to known destinations.

-- [snip --