[rbridge] Comments on: http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.txt
Eric.Gray at marconi.com
Tue Oct 31 09:42:38 PST 2006
Please see below...
-- [snip] --
--> Sgai 3> It is very important to say that this protocol must provide a
--> loop free topology for multicast/broadcast under any condition,
--> 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
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 --
More information about the rbridge