Subject: RE: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in Support of RBridges) to Informational RFC

From: "Eric Gray \(LO/EUS\)" <[email-masked]>
Date: Tue, 20 Mar 2007 13:30:32 -0500

Silvano,

	Thanks for posting these comments.  Please see below.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Silvano Gai
> Sent: Tuesday, March 20, 2007 12:35 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [rbridge] Last Call: 
> draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in 
> Support of RBridges) to Informational RFC
> 
> 
> This document has some issues that need to be corrected before it can
> pass an IESG last call.

I think as a strict matter of process, we don't get to say what MUST be
corrected before a document can pass IESG last call (if there is such a
thing).

Luckily, I believe this is an IETF Last Call, where the idea is that the
IESG is asking for our input before making _their_ decision as to what -
if anything - MUST be changed.

> 
> In order of importance:
> 1) The document equates Ethernet with IEEE 802 and this is clearly
> incorrect, since IEEE 802 includes also technologies like Token Ring,
> DQDB, Wireless that are clearly outside the scope of TRILL. Ethernet
> must be equated with IEEE 802.3

Which is historically at least as incorrect.

This comment was made during the working group last call.  Specific
changes were made that I hoped would address this comment.

Why did you not earlier state specifically what part of the changes
made were not satisfactory to you at that time?

> 
> 2) The document discusses Spanning Tree compatibility in section 1.2
> where it claims that BPDUs must be terminated and in Section 4.1 where
> the term "block" is used. This is clearly in contrast with what
> discussed in the WG and in the base protocol spec, where BPDUs are at
> least processed (in one proposal) or even sourced by RBridges (in an
> alternate proposal).

This was the terminology decided on by the working group at the time.

This comment was also made during the working group last call, and
explanations were provided and - I believe - some small explanatory
changes were made to the text.

Again, why did you not earlier state specifically what part of the 
changes made were not satisfactory to you at that time?

> 
> 3) Section 1.1 Terminology is formally incorrect since [TARCH] is not
an
> approved document. It is also substantially incorrect since many terms
> listed are not used in this document and some are not agreed in the
WG.
> I propose to eliminate this section.

As a matter of process, again, this issue is addressed by listing the
Architecture as a Normative reference.

Because the document is intended to be an informational RFC, the WG 
chairs informed me that IESG members are comfortable with pushing this
to IETF last call ahead of its (one) normative reference.

That, again, is their prerogative.

> 
> 4) The document uses the term "will" that is not compliant with
RFC2119.
> In general a better definition of what is mandatory and what is
optional
> is important in a requirement document.

This is an informational document, proposed as an informational RFC.

This is also a requirements document, stating what is needed from any
candidate routing protocol.  It is not an options list, or a wish list.
People may decide to ignore requirements in this document, and that is
okay - because it is strictly informational.  The requirements listed
in this document represent the things that the TRILL working group had
agreed were needed and should be documented at the time the document 
was/is/will be published.

The choice to avoid 2119 language was - for this reason - a deliberate
one, discussed on several occasions in the working group.  There is no
inclusion of the "usage" of RFC 2119 terminology, nor any reference to
RFC 2119.  Hence the word "will" can be, and is, used as it would be
interpreted in the English language.

If you would care to provide a reasonably authoritative reference for
English usage of the word "will" that is in conflict with any specific
usage of the word in this document, I'd be happy to consider including 
it as a reference in this document and changing the specific instances
you point out.

> 
> 5) Introduction - Bridging limitation. The first paragraph refers to
> Ethernet networks used without Spanning Tree. This is irrelevant, 
> since Spanning Tree is always deployed in conjunction with Ethernet. 

This follows only because: 

o	you disagree with the inclusive way this document uses the term 
	Ethernet.  Let's not conflate issues here.
	
	The way the document uses the term Ethernet was explained to you

	- and to the working group - as a result of your earlier working

	group last call comments.

o	you exclude Ethernet deployments in small networks where small
	Ethernet switches _clearly_ do not use spanning tree.

o	you exclude Ethernet, and Ethernet-like, encapsulation in new,
	in progress, and yet to be developed technologies in making 
	this statement.

In short, your statement that spanning tree is always used in Ethernet
networks is correct only if you define Ethernet networks as including
spanning tree.  Interestingly enough, I do not recall that spanning 
tree is actually defined by 802.3.

There was not at the time of the working group last call, nor have 
I seen any indication that there is now, a consensus to change the
wording of this document with respect to this issue. 

My earlier justification that using a less inclusive interpretation
of "Ethernet" would mean replacing the term Ethernet with a more 
explicitly inclusive (and complex) phrase in each place where it 
occurs, still applies.

> The correct contrast must be between Ethernet with Spanning Tree and
> Ethernet with TRILL. 

This only follows if you assume that the way that Ethernet is used
in this document is wrong.

A point has been made - more than once - that there is no absolutely 
cannonical definition of Ethernet.  You might choose to decide that
Ethernet is defined by 802.3 - in spite of the fact that Ethernet and
802.3 have been considered by many to be distinct for many years.  If 
you do, then you would be limiting the definition to exclude how the
technology works with bridges, and you would be forcing arbitrarily
complicated verbiage in what is essentially a relatively high-level
document that doesn't need that degree of technical precision.  And
you would still be wrong by some (other) definitions of Ethernet.

> The claim of a single broadcast/flooding domain is incorrect since 
> VLANs have solved this issue many years ago.

For the purposes of this document, it is not explicitly necessary -
nor necessarily even a good idea - to dwell in too great detail on
the ways that a domain that would be "a single broadcast/flooding
domain" in the absence of VLANs, becomes multiply sub-setted by the
inclusions of VLANs.

I do not recall seeing this comment during the working group last
call.  If I had, one of the things I would have pointed out is that
this is not explicitly an "issue" in forming requirements in this
document, and that your taking exception to the wording - in a more 
representative context - is based on your interpretation of the 
statement (possibly in a less representative context).  Here is the 
context:

"... bridged networks consist of single broadcast/flooding domains."

One - fairly simplistic - way to look at VLANs is that the use of a
VLAN ID allows VLAN bridges to treat the non-VLAN broadcast domain
as having been divided into multiple logical broadcast domains, with
each such logical broadcast domain being effectively - logically -
a bridged network consisting of a single broadcast/flooding domain.

In this view, the statement is not incorrect - however you might not
like it.

If you would like me to phrase this point some other way, propose an
alternative wording, don't just say "it's wrong."

> 
> -- Silvano Gai
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of The IESG
> > Sent: Friday, March 16, 2007 2:53 PM
> > To: IETF-Announce
> > Cc: [email-masked]
> > Subject: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL
> > RoutingRequirements in Support of RBridges) to Informational RFC
> > 
> > The IESG has received a request from the Transparent Interconnection
> of
> > Lots of Links WG (trill) to consider the following document:
> > 
> > - 'TRILL Routing Requirements in Support of RBridges '
> >    <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC
> > 
> > The IESG plans to make a decision in the next few weeks, 
> and solicits
> > final comments on this action.  Please send substantive comments to
> the
> > [email-masked] mailing lists by 2007-03-30. Exceptionally,
> > comments may be sent to [email-masked] instead. In either 
> case, please
> > retain the beginning of the Subject line to allow automated sorting.
> > 
> > The file can be obtained via
> >
> http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-r
> eqs-02.txt
> > 
> > 
> > IESG discussion can be tracked via
> >
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_id&dTag=
> 15
> > 187&rfc_flag=0
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 21 Mar 2007 08:58:42 +0100

--On 20. mars 2007 09:35 -0700 Silvano Gai <[email-masked]> wrote:

> Ethernet networks used without Spanning Tree. This is irrelevant, since
> Spanning Tree is always deployed in conjunction with Ethernet. The
> correct contrast must be between Ethernet with Spanning Tree and
> Ethernet with TRILL. The claim of a single broadcast/flooding domain is
> incorrect since VLANs have solved this issue many years ago.

"always" is too strong, since most unmanaged bridges (intended for 
consumers' home networks, but often dangled off the edge of corporate 
networks as port expanders, without asking for permission) don't seem to be 
supporting Spanning Tree. However, these are not going to support TRILL 
either, so for the environments considered here, "always" is probably true.

               Harald

---

From: "Eric Gray \(LO/EUS\)" <[email-masked]>
Date: Wed, 21 Mar 2007 04:32:55 -0500

Harald,

	As it was originally chartered, the TRILL working group allowed
scope for definition of TRILL bridges that could be cheaply produced,
modulo the inclusion of a ink-state routing protocol as a complicating
factor.  It is not clear at this point that this has changed.

	Consequently, at least some of the people working on this are
thinking that a <well-known but not named here> work group switch may
very well be replaced by a TRILL capable bridge - possibly made by the
same vendor, at the same manufacturing facility.

--
Eric

> [mailto:[email-masked]] On Behalf Of Harald Tveit 
> Alvestrand
> Sent: Wednesday, March 21, 2007 3:59 AM
> To: Silvano Gai; [email-masked]
> Cc: [email-masked]
> draft-ietf-trill-routing-reqs (TRILL RoutingRequirements in 
> > incorrect since VLANs have soFrom [email-masked] Wed Mar 21 05:36:20 2007
Content-class: urn:content-classes:message
Date: Wed, 21 Mar 2007 04:32:55 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Harald Tveit Alvestrand" <[email-masked]>,
	"Silvano Gai" <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: RE: [rbridge] Last Call: draft-ietf-trill-routing-reqs
	(TRILL	RoutingRequirements in Support of RBridges) to
	Informational RFC

Harald,

	As it was originally chartered, the TRILL working group allowed
scope for definition of TRILL bridges that could be cheaply produced,
modulo the inclusion of a ink-state routing protocol as a complicating
factor.  It is not clear at this point that this has changed.

	Consequently, at least some of the people working on this are
thinking that a <well-known but not named here> work group switch may
very well be replaced by a TRILL capable bridge - possibly made by the
same vendor, at the same manufacturing facility.

--
Eric

> [mailto:[email-masked]] On Behalf Of Harald Tveit 
> Alvestrand
> Sent: Wednesday, March 21, 2007 3:59 AM
> To: Silvano Gai; [email-masked]
> Cc: [email-masked]
> draft-ietf-trill-routing-reqs (TRILL RoutingRequirements in

---

From: Pekka Savola <[email-masked]>
Date: Wed, 21 Mar 2007 11:30:42 +0200 (EET)

On Wed, 21 Mar 2007, Harald Tveit Alvestrand wrote:
> "always" is too strong, since most unmanaged bridges (intended for consumers' 
> home networks, but often dangled off the edge of corporate networks as port 
> expanders, without asking for permission) don't seem to be supporting 
> Spanning Tree. However, these are not going to support TRILL either, so for 
> the environments considered here, "always" is probably true.

FWIW, not sure if it matters, but our offices have a relatively 
small Ethernet network (50+ switches) and we havelved this issue many years ago.
>=20
> "always" is too strong, since most unmanaged bridges (intended for=20
> consumers' home networks, but often dangled off the edge of corporate=20
> networks as port expanders, without asking for permission)=20
> don't seem to be=20
> supporting Spanning Tree. However, these are not going to=20
> support TRILL=20
> either, so for the environments considered here, "always" is=20
> probably true.
>=20
>                Harald
>=20
>=20

---

From: Pekka Savola <[email-masked]>
Date: Wed, 21 Mar 2007 11:30:42 +0200 (EET)

FWIW, not sure if it matters, but our offices have a relatively 
small Ethernet network (50+ switches) and we have specifically 
disabled STP.

You can't run STP on host ports, and it's too much of a hassle to 
enable it on inter-switch ports, so it's easier to disable it 
everywhere.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

 specifically 
disabled STP.

You can't run STP on host ports, and it's too much of a hassle to 
enable it on inter-switch ports, so it's easier to disable it 
everywhere.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Eric Gray \(LO/EUS\)" <[email-masked]>
Date: Wed, 21 Mar 2007 05:48:15 -0500

Dinesh,

	Thank you for your comments.  Please see below...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:[email-masked]] On Behalf Of Dinesh G Dutt
> Sent: Tuesday, March 20, 2007 10:33 PM
> To: [email-masked]
> Cc: [email-masked]; IETF-Announce
> draft-ietf-trill-routing-reqs (TRILL Routing Requirements in 
> I have a few comments on the document.
> 
> - Section 1, Bridging Limitations: The first two paragraphs are 
> structured around the logic: because ethernet header doesn't have 
> a TTL or a hop count, the only choice was to use spanning tree. 
> IEEE 802.1 has defined several headers such as 802.1Q header that 
> carries the VLAN. If they wanted to add a TTL, they could have. 
> They picked spanning tree and said that therefore they didn't need 
> a TTL.  To the extent this represents history, I think it is 
> inaccurate. To the extent it attempts to explain the rationale for 
> RBridges, it seems unnecessary. A sufficient replacement maybe 
> along the lines of: 
>
> "Spanning Tree Protocol and its variants are the control protocol 
> deployed in current 802.1D Ethernet bridges.  This protocol 
> constructs a single tree out of a mesh of network connections. 
> This tree eliminates usage of equal cost multipaths and results in 
> non-optimal pair-wise forwarding."
> 

This is a reasonable proposal for replacement text.  If there
are no objections from the working group, or the IESG, I would
be happy to make this change.

Thanks!

> - Section 1, Bridging Limitations: More specific comments:
>   - "Because of the potential for severe impact from looping traffic, 
>     many (if not most) current bridge implementations stop forwarding
>     of traffic frames following a topology change event and restart 
>     only after STP/RSTP is complete" is incorrect. All 802.1D bridges 
>     allow (R/M)STP to complete before moving a port to forwarding 
>     state. I'd remove the phrase in parentheses.

Good suggestion.  Assuming the same acceptance, I can make this
change as well.

>   - "Inefficient inter-bridge connection usage". What do you 
>     mean by this phrase?

I assume this is a reasonably well understood aspect of using
a spanning tree as opposed to using shortest path routing.

It is not difficult to come up with a reasonable scenario in
which shortest path forwarding results in 80% of the total
link-by-link forwarding load that is generated by the same
amount of traffic in a corresponding spanning tree scenario.

The reason why this happens is that a spanning tree may be
constructed in which the path for some destinations will
traverse at least one additional link, when arriving from
some sources.  Practically speaking, unless a spanning tree 
is constructed per-source bridge, it's easy to show that 
this will be true for at least some source and destination 
pairs.

Assuming the simplistic (VLAN-free) scenario that is basic
to the "configuration-free" capability that is part of the
chartered goals of TRILL, there would only be one spanning
tree in a bridged network.  Hence, in this scenario, there
would be many cases in which traffic traverses at least one
additional link.

If traffic is demonstrably required to traverse more links
than some theoretical minimum, than link utilization is -
by definition - less efficient than it theoretically can
be.

> 
> - Section 1.2, Backward Compatibility and section 4.1: "...they 
> terminate a bridged spanning tree, (i.e. - they do not forward 
> BPDUs)". 
>
> I thought that we have not concluded the discussion on preventing 
> loops for interconnected Bridges and RBridges based on the email 
> thread that started a while back. Putting a decision in this 
> section on the solution seems a little unnecessary. 

I am not sure that this text - or something like it - is unnecessary 
from a compatibility perspective, and it may be the case that this 
change would require a new working group last call.  However, if it 
is acceptable to the IESG either that the change does not require a 
new last call, or a second working group last call is needed, then I 
would be happy to make this change as well.

> What is proposed in the current solution is to run a spanning tree 
> protocol instance per port which maybe not scalable. 
>
> I think something like "It's strongly desirable to minimize the
> interaction between the bridges and Rbridges and constrain a 
> spanning tree" is more appropriate.

Yet it is difficult to imagine how this would translate to a 
requirement that would make sense to someone evaluating the 
acceptability of a routing protocol for the TRILL problem-space.
Perhaps it would be simpler to omit the offending text?

> 
> - Ethernet and 802 is used interchangeably. Isn't Ethernet 
> 802.3 only ? 
> Look at: http://en.wikipedia.org/wiki/IEEE_802.3 or 
> http://www.ieee802.org/3/.
> 
> I don't see anything on what I consider to be another 
> important goal: to 
> have a single protocol to compute unicast, multicast and broadcast 
> routes. This reduces operational overhead by having to understand and 
> debug a single protocol.
> 
> The IESG wrote:
> > The IESG has received a request from the Transparent 
> Interconnection of 
> > final comments on this action.  Please send substantive 
> comments to the
> w_id&dTag=15187&rfc_flag=0
> >
> We make our world significant by the courage of our questions and by 
> the depth of our answers.                               - Carl Sagan

---

From: "Silvano Gai" <[email-masked]>
Date: Tue, 20 Mar 2007 09:35:03 -0700

In order of importance:

3) Section 1.1 Terminology is formally incorrect since [TARCH] is not an
approved document. It is also substantially incorrect since many terms
listed are not used in this document and some are not agreed in the WG.
I propose to eliminate this section.

4) The document uses the term "will" that is not compliant with RFC2119.
In general a better definition of what is mandatory and what is optional
is important in a requirement document.

-- Silvano Gai

On
of
> The IESG plans to make a decision in the next few weeks, and solicits
the
> comments may be sent to [email-masked] instead. In either case, please
http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt
> IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
15

---

From: Dinesh G Dutt <[email-masked]>
Date: Tue, 20 Mar 2007 19:33:26 -0700

- Section 1, Bridging Limitations: The first two paragraphs are 
structured around the logic: because ethernet header doesn't have a TTL 
or a hop count, the only choice was to use spanning tree. IEEE 802.1 has 
defined several headers such as 802.1Q header that carries the VLAN. If 
they wanted to add a TTL, they could have. They picked spanning tree and 
said that therefore they didn't need a TTL.  To the extent this 
represents history, I think it is inaccurate. To the extent it attempts 
to explain the rationale for RBridges, it seems unnecessary. A 
sufficient replacement maybe along the lines of: "Spanning Tree Protocol 
and its variants are the control protocol deployed in current 802.1D 
Ethernet bridges. This protocol constructs a single tree out of a mesh 
of network connections. This tree eliminates usage of equal cost 
multipaths and results in non-optimal pair-wise forwarding."

- Section 1, Bridging Limitations: More specific comments:
  - "Because of the potential for severe impact from looping traffic, 
many (if not most) current bridge  
    implementations stop forwarding of traffic frames following a 
topology change event and restart only after STP/RSTP is
    complete" is incorrect. All 802.1D bridges allow (R/M)STP to 
complete before moving a port to forwarding state. I'd
    remove the phrase in parentheses.
  - "Inefficient inter-bridge connection usage". What do you mean by 
this phrase ?

- Section 1.2, Backward Compatibility and section 4.1: "...they 
terminate a bridged spanning tree, (i.e. - they do not forward BPDUs)". 
I thought that we have not concluded the discussion on preventing loops 
for interconnected Bridges and RBridges based on the email thread that 
started a while back. Putting a decision in this section on the solution 
seems a little unnecessary. What is proposed in the current solution is 
to run a spanning tree protocol instance per port which maybe not 
scalable. I think something like "It's strongly desirable to minimize 
the interaction between the bridges and Rbridges and constrain a 
spanning tree" is more appropriate.

- Ethernet and 802 is used interchangeably. Isn't Ethernet 802.3 only ? 
Look at: http://en.wikipedia.org/wiki/IEEE_802.3 or 
http://www.ieee802.org/3/.

I don't see anything on what I consider to be another important goal: to 
have a single protocol to compute unicast, multicast and broadcast 
routes. This reduces operational overhead by having to understand and 
debug a single protocol.

The IESG wrote:
> The IESG has received a request from the Transparent Interconnection of 
> final comments on this action.  Please send substantive comments to the
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15187&rfc_flag=0
>

---

From: caowayne <[email-masked]>
Date: Wed, 21 Mar 2007 19:23:31 +0800

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 21 Mar 2007 12:15:07 -0700

Hi Eric,

>>   - "Inefficient inter-bridge connection usage". What do you 
I guess my issue is the choice of words "inter-bridge connection usage". 
"connection" is undefined and not sure if it is the right word.
> by definition - less efficient than it theoretically can
If this what you want to say, something along the lines of "Non-optimal 
pair-wise forwarding of unicast frames using spanning tree also results 
in inefficient usage of links" will be sufficient. However, I think that 
merely stating the lack of non-optimal pair-wise forwarding is 
sufficient to imply this and many other issues around this style.
> Perhaps it would be simpler to omit the offending text?
OK with me.

Dinesh

---

From: "Eric Gray \(LO/EUS\)" <[email-masked]>
Date: Thu, 22 Mar 2007 11:08:21 -0500

Dinesh,

	Please see one more question below...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> From: Dinesh G Dutt [mailto:[email-masked]] 
> Sent: Wednesday, March 21, 2007 3:15 PM
> To: Eric Gray (LO/EUS)
> Cc: [email-masked]; [email-masked]; IETF-Announce
sufficient 
> to imply this and many other issues around this style.

I'm not sure how much clearer it is to say what you're suggesting
than what it already says.  However this is not critical text, so
what would you like it to say and where would you like it to go?

What I'm asking for is "replace text saying <$*%&(%)> with new text
saying <*$&*@(_&$&>"...