Subject: [rbridge] Comments to draft Touch-00

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 9 Nov 2005 16:24:10 -0200

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 09 Nov 2005 10:46:42 -0800

> even imply that you expect, comments on your second document at this

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.

> to make progress until it is no longer couched in terms of specific

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?

> be easier to convince people to accept what is written.  :-)
?
> to be a more productive than picking a different term to disagree

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

> --> Subject: Re: [rbridge] Comments to draft Touch-00

We all agree on that. If it's so clear, then let's agree on a definition
and put it down in the doc.

> EG> Please do not make statements and expect me to prove them.  I already

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.

> 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> no need to configure VLAN information. 

Agreed - that needs to be added.

> EG> It is certainly possible to

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.

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

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

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Wed, 09 Nov 2005 21:24:36 +0100

Just a few comments

>didn't require some configuration of the ports.
I think VLANs will normally reire configuration of the ports. It seems 
that assuming they will not require configuration means they will be 
configured at the bridges and that nodes are always connected to a 
bridge that tags the frames (or the nodes themselves tag the frames).

>will be changed to reflect that.
I think pure configuration free RBridges are not possible with VLANs. 
Somebody has to tell the networks what port belongs to what VLAN.
Guillermo

>------------------------------------------------------------------------
>

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Wed, 09 Nov 2005 21:31:41 +0100

Although obvioully desirable, I see extremely difficult to make the 
problem statement in this case whithout pointing to the proposed solution.
This is reinforced by the fact that some potential challenges to the 
existing solution, like loioking for bigger network sizes, are excluded 
as requirements or design objectives. So we end specifying what we can 
already get with the proposed solution.
Guillermo

---

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Wed, 09 Nov 2005 13:07:58 -0800

> "group of cooperating rbridge devices", that's fine...

The classical way of finessing that problem is to have an early terminology 
section, saying "in this document, foo means bar - note that it is used for 
other concepts in other contexts".....

I like terminology sections.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://www.postel.org/pipermail/rbridge/attachments/20051109/ac54f0f0/attachment.bin