[rbridge] Comments to draft Touch-00

[Guillermo Ibáñez]

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 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.

>	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.

>	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
>
>  
>