Subject: [rbridge] Comments to draft Touch-00

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 8 Nov 2005 21:00:02 -0200

Guillermo/Joe,

	I agree with Guillermo that the abstract - along with several other
sections - describes RBridge solutions instead of the problems addressed.
I strongly suspect that many (if not most) of Guillermo's comments would
be addressed if the draft were targetted more toward describing problems
rather than the RBridge solution(s).

	Questions about whether RSTP, self-rooted multiple spanning trees 
and/or Shortest Path Bridging are also solutions (with or without implied 
preferences) should be a separate issue, document and discussion.

	We have been using the term campus for some time now and I think it
is clear that introducing a new term at this point is probably not a good
idea.  For one thing, we're defining terms like internal and external as
relative to a campus (and therefore, defining the term campus in the same
process).  If we assume that we were to define the terms internal and 
external relative to some other term "X", then we come up with the same
areas of potential confusion with a different term.  Do we need to go
through that exercise just to demonstrate this?

	However, it would help if we did not use clearly confusing wording
(such as the phrase "this communication may traverse external devices, 
but is still considered internal").  I think - for instance - that we've
beat the definitions of internal and external to the point that it should
be very clear what is internal and what is external (and, therefore, what
is internal is internal not external).  We have elastically defined the
term "internal" to me between mutually participating RBridges and - as a
consequence - it does have an agreed topological meaning.

	I agree with Joe that small changes can have big effects but I also
agree with Guillermo that we need to at least briefly illustrate how this
can occur.  It would probably be sufficient to show how (possibly faulty)
bridge networks could result in many interface forwarding-state changes
as a result of loss of a key bridge or link.  Alternatively, we could just 
add a reference to some place(s) where this is documented elsewhere. 

	In the same sense that we hope to avoid configuration, we probably
should not assume RBrdiges will be deployed in an idealistic configuration 
either.  In other words, we should describe what causes the problem with 
STP (or RSTP) with a view to how it might be fixed in design rather than
in deployment.

	I agree with Guillermo that more information is required with repect
to convergence time considerations or camparisons between STP/RSTP and SPF
routing.  I suspect that this might be related to the blurring of intenal 
and external described above.  The presence of bridges and other devices 
on links between RBridges (at least RBridges not deliberately configured 
to ignore each other) does not change the fact that these links are campus-
internal and - in fact - these components are also internal to the campus.
However, it might be fair to say that SPF convergence between directly 
connected RBridges should be faster than STP convergence between directly 
connected bridges.

	Since an RBridge is - among other things - a VLAN aware bridge, I 
do not agree that support for VLANs necessarily requires configuration.
The fact that - from RBridge's perspective - a VLAN is simply an ID, makes
it possible, for example, for an RBridge to simply use the ID as part of
context it uses for learning, shortest path determination, spanning tree
setup, etc.  In this sense, it would be necessary to configure information
relative to specific VLAN IDs only if something other than simple context
is required (like authentication, ID-to-ID translation/mapping, etc.).

	For IANA considerations change the first sentence to read:

    "This document currently has no IANA considerations."

and it will be correct until the situation changes (at which time, it
should be changed as well).

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Monday, November 07, 2005 7:23 AM
--> To: Developing a hybrid router/bridge.
--> Subject: [rbridge] Comments to draft Touch-00
--> 
--> 
--> Joe,
--> 
-->       Please find attached commented draft. Comments are 
--> indicated with GI>
--> 
--> Guillermo Ib??ez
-->

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 08 Nov 2005 15:51:55 -0800

> rather than the RBridge solution(s).

I'm presuming this addresses the first doc; see below...

> preferences) should be a separate issue, document and discussion.

Problem statements often cite or refer to current work that might solve
the problem, as well as allude to the solution as in "something that
solves this will work under the following conditions". That requires
saying something about the possible solutions in that doc, but it
doesn't define the solutions. It's just 'enough to identify them', as
well as to indicate that existing solutions may not suffice.

> idea.

The issue is whether it means the same thing to all of us. Does it?

> For one thing, we're defining terms like internal and external as
> but is still considered internal").

I came up with an explanation of that that's visual in the second doc. I
can include that in the first, but that strays into 'describing the
solution' more.

> I think - for instance - that we've
> is internal is internal not external).

To us; these docs are not for us ;-) We need to explain this so a newbie
to TRILL can understand.

> We have elastically defined the

Yes - if someone has a picture, please send it; if not, a ref would be
fantastic.

> connected RBridges should be faster than STP convergence between directly 

This is addressed in the second doc; I had hoped to avoid that level of
discussion in the first.

> do not agree that support for VLANs necessarily requires configuration.

How do you know which traffic is on which VLAN, i.e., if it arrives at
the rbridge and isn't VLAN-tagged yet? (maybe I need to brush up on how
VLANs work, but I thought you needed to tag ports somewhere).

> should be changed as well).

P&AS should not have IANA considerations unless the problem is itself
with IANA-based information. That's not the case here - there's no
IANA-centric issue. Architectures that address the problem (such as
rbridges) may have IANA considerations, but that's not relevant to the
P&AS doc.

Arch docs should have an IANA consideration if any variants of instances
of the architecture would have new protocol/port/etc numbers. So far,
the arch doc indicates that this might be the case for rbridges.

Joe

> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge

-------------- 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/20051108/0a8d64a0/signature.bin

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Wed, 09 Nov 2005 08:12:56 +0100

Eric,
      I insert just a couple of comments to your comments.
Guillermo

>consequence - it does have an agreed topological meaning.
May be I did not follow the terms discussion in detail, but it is very 
confusing to consider *internally* connected to RBridges that are 
connected phisically via standard bridges. As long as we are not 
considering a *RBridge core* scenario (RBridges interconnected directly 
between them), I see the term internal inadecuate.

>connected RBridges should be faster than STP convergence between directly 
The fair comparison would be with RSTP convergence, not with STP 
convergence. Remember that the current IEEE standard is RSTP. STP is legacy.

>is required (like authentication, ID-to-ID translation/mapping, etc.).
If , as most common  example, per-port VLANs are used, it must be 
configured which ports belong to which VLANs. If VLAN ID learning is 
assumed, somebody (Bridge or host) must label the frames with the VLAN 
tag. This "somebody" must be instructed (configured) to label with such 
value for VLAN.