Subject: [rbridge] Comments to draft Touch-00

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 9 Nov 2005 18:34:11 -0200

Guillermo,

	Please see responses in line below...

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Wednesday, November 09, 2005 2:13 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Comments to draft Touch-00
--> 
--> 
--> Eric,
-->       I insert just a couple of comments to your comments.
--> Guillermo
--> 
--> Gray, Eric wrote:
--> 
--> >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.
--> >
--> >  
--> >
--> 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 
--> [physically] via standard bridges. As long as we are not considering a 
--> *RBridge core* scenario (RBridges interconnected directly between them),
I 
--> see the term internal [inadequate].
--> 

Some things are only confusing if we fail to accept them as given.  :-)

In previous discussions we discussed at great length how it is that the 
fact that two or more RBridges are 1) part of the same broadcast domain,
2) connected to each other by a link of some kind and 3) cooperating (as
in they are not configured to ignore each other) means that the "link"
connecting them is a "campus-internal" link.

We need to work with this as a definition, rather than try to invent new
terms and definitions - unless there is some reason why it absolutely does
not work - or we will be going in circles forever.

This is critical to any further discussion of the proposal.  Forwarding 
between RBrdiges over 'internal' links is based on shortest path - however
the frames might be forwarded on those links themselves - and that is a
basic element of the RBridge proposal.

Those links may be constructed using any arbitrary technology, as long as
they looks to RBridges at each end as a link.  That includes 802 spanning
trees, and Ethernet/802 pseudo wires for example.

-->
--> >	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.
--> >  
--> >
--> The fair comparison would be with RSTP convergence, not with STP 
--> convergence. Remember that the current IEEE standard is RSTP. STP is
legacy.
--> 
--> >	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.).
--> >  
--> >
--> 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.

This is combining functions.  As I believe I indicated in response to Joe,
there are indeed devices that provide the ability to insert non-VLAN traffic
on a VLAN.  There are also devices with the ability to stack VLAN tags in a
similar fashion.  Interesting, but not particularly relevant.  Typical
bridges
are completely VLAN unaware and require no configuration to support VLANs.

It is certainly possible to make a bridge that is capable of consistently 
handling VLAN as context information for learning and filtering, but without
the ability to change (or insert) the VLAN ID in frames being forwarded.

In such a bridge, no configuration is required in order to make it work - 
any more than configuration is required to make bridge learning and
filtering
without VLAN context information work.

It is certainly possible to combine functionality that requires
configuration
with essential RBridge functionality.  However, since a goal is to allow for
RBridge deployment with configuration, it should be a non-goal to include
any
such functional combination as part of the basic RBridge design.

--> 
--> >	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
--> >--> 
--> >_______________________________________________
--> >rbridge mailing list
--> >rbridge at postel.org
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >
--> >  
--> >
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->