[rbridge] Comments to draft Touch-00

[Gray, Eric]

Joe,

	As the second document was not posted until this week, I have
not had so much as a second to look at it. So naturally my comments
in response to Guillermo's earlier comments are in reference to the
first document.  I think it is innapproriate for you to expect, or 
even imply that you expect, comments on your second document at this
point.

	It is generally an error in IETF people-to-people protocol to
describe a problem in terms of any solution - least of all your own
solution - as it looks too much like you're making up a problem that
requires your solution.  Consequently, the document is very unlikely
to make progress until it is no longer couched in terms of specific
solution(s).

	It might be easier to write it down that way, but it will not
be easier to convince people to accept what is written.  :-)

	As far as whether or not we all agree on the meaning of the 
word "campus" it is unlikely that we all completely agree on the 
meaning of any word in any language.  Working on getting a common
agreement on the meaning of the current terminology is very likely
to be a more productive than picking a different term to disagree
on.

	Please see additional comments below (prefixed with EG>)

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Joe Touch
--> Sent: Tuesday, November 08, 2005 6:52 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Comments to draft Touch-00
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Earlier, you wrote:


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

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

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

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.

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

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

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

EG>
EG> Yes, and using confusing phraseology does not help either for us,
EG> or for them.
EG>

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

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

EG>
EG>
EG> Yes, no doubt it would. However, you're the one making the statement
EG> - therefore it is reasonable for everyone to assume you had a basis 
EG> for making it.  My point in saying that a reference or example would
EG> help is to prod you to do so.
EG> 
EG> Please do not make statements and expect me to prove them.  I already
EG> have a job...
EG>
EG>

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

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

EG>
EG>
EG> It is not clear that we agree on the purpose for a problem statement
EG> at all.  This is not a detail; you made the statement that convergence
EG> would be faster, but you've not made it clear under what circumstances
EG> this would be true.  In complete fairness, Guillermo has certainly made
EG> the point that it is not true in all circumstances and it is equally 
EG> fair to expect the document to address these limitations.
EG>
EG> This is a requirement of a problem statement unless the purpose of the
EG> problem statement is just to be an excuse for moving on to a specific 
EG> solution.  If a problem statement is intended to be a description of a
EG> specific problem we want to solve, it must be put in a specific context.
EG> 
EG>

> 	Since an RBridge is - among other things - a VLAN aware bridge, I 
> 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).

EG>
EG>
EG> Strictly speaking of RBridges as an extension of bridge functionality,
EG> bridges are not (properly, at least) used to transfer traffic from one
EG> VLAN to another.  This should be true of insertion of traffic onto a
EG> specific VLAN (effectively transferring from the default VLAN to one
EG> that has a specific - non-zero - VLAN ID).  It could also be stretched 
EG> to include changing the VLAN ID for local scope reasons - but this is
EG> something that is commonly done (and requires configuration).
EG>
EG> Transferring traffic from one VLAN to another is (properly) a function
EG> of routing and it is not much of a stretch to say that this applies to
EG> initial insertion onto a non-default VLAN.
EG>
EG> In any case, for bridges which are currently VLAN unaware, there is
EG> no need to configure VLAN information.  It is certainly possible to
EG> make RBridges VLAN aware and _only_ require configuration when VLAN
EG> context (IDs) changes in transfer across an RBridge.
EG>
EG> As far as I know, the goal is to allow configuration free RBridges.
EG> 
EG>

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

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.

EG>
EG> Agreed.
EG>

Joe

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