[rbridge] Comments to draft Touch-00

[Joe Touch]

Gray, Eric wrote:
> 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.

I don't expect it; I asked for clarification (the mails refer to
touch-00, not touch-prob-00), and tried to point out where issues were
covered in the other doc for that reason.

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

The problem is already defined without reference to a solution (section
2), with the sole exception of using the name (rbridges) in the final
section on issues not solved. That can easily be remedied by replacing
'rbridge' with 'the desired solution'.

The 'desired properties' and 'applicability' are discussed in terms of a
solution - I thought that was more typical than not. Is there a way to
avoid that in this section of the doc, except by saying "anything that
solves the problem is fine", and if so is that what is preferred?

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

Different groups have used it in different ways - I was asking how to
proceed, given that. If we're all comfortable with "campus" meaning
"group of cooperating rbridge devices", that's fine...

> 	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 all agree on that. If it's so clear, then let's agree on a definition
and put it down in the doc.

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

I'm editor of the doc, not sole author. I've asked for assistance where
needed. For the document, I included statements made on the list - not
my own ideas per se - and asked for backup or clarification. I'd be just
as happy to delete the statement, since it wasn't my idea I was asserting.

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

Agreed. The doc needs to discuss both possibilities and where each might
arise - with citations for each case.

However, don't expect me to provide citations for a summary of what many
have raised on the list, sometimes as questions or propositions. T

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

Agreed - that needs to be added.

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

Yes, but we also were talking about per-VLAN tables. I wasn't sure that
didn't require some configuration of the ports.

> EG> As far as I know, the goal is to allow configuration free RBridges.
> EG> 
> EG>

Yes. If everyone is convinced that VLANs don't affect this, then the doc
will be changed to reflect that.

>> 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
> _______________________________________________
> 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/20051109/4f7a86c2/signature.bin