Subject: [rbridge] Consensus Check: Pseudonode suppression

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Thu, 3 Jan 2008 14:13:32 -0500

This is a check via the mailing list to confirm or refute an apparent
consensus at the Vancouver meeting taken from the minutes of that
meeting:

   Move the Pseudonode suppression provisions
      out of the TRILL base protocol specification into a document
      closer to IS-IS.

If no particular controversy arises over this in the next three weeks,
We will declare it to be the working group consensus.

Thanks,
Donald & Erik

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Mon, 7 Jan 2008 13:36:15 -0500

Remove any text prohibiting implementation
      of GVRP or MVRP on RBridges.

Thanks,
Donald & Erik

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Mon, 7 Jan 2008 13:34:19 -0500

Currently broadcast, unknown unicast, and
      non-IP-derived multicast frames are output to all links. This is
      wasteful if there are no end stations on the link. Provide that
      a port can be configured so as to be disabled for end station
      traffic.

Thanks,
Donald & Erik

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Mon, 7 Jan 2008 11:14:27 -0800

This certainly makes sense is what I tend to
think of as a TRILL "core" port.   On such a 
port, we would never see non-TRILL encap'ed
frames (other than the usual exceptions such
as BPDUs and other link layer control traffic).

I wonder if it makes sense to also have a 
configuration for a TRILL "edge" port -- one
where we are configured to never send TRILL
encap'ed traffic because we don't intend for 
it to be used as a transit link (even though
connectivity may exist to another RBridge 
for redundancy purposes).  

Anoop 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Monday, January 07, 2008 10:34 AM
> To: [email-masked]
> Subject: [rbridge] Consensus Check: Configure ports to 
> disable end stationtraffic
> 
> This is a check via the mailing list to confirm or refute an 
> apparent consensus at the Vancouver meeting taken from the 
> minutes of that
> meeting:
> 
> If no particular controversy arises over this in the next 
> three weeks, We will declare it to be the working group consensus.
> 
> Thanks,
> Donald & Erik
>

---

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 7 Jan 2008 14:26:41 -0500

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Anoop Ghanwani
> Sent: Monday, January 07, 2008 11:14 AM
> To: Eastlake III Donald-LDE008; [email-masked]
> Subject: Re: [rbridge] Consensus Check: Configure ports to disable
> endstationtraffic
> 
> 

This is certainly something specialized implementations
SHOULD be allowed to do.

The physical ingress/egress point for a chassis could
be given RBridge functionality, and it would certainly
be in a position to know what sort of networking functionality
was allowed in the internal slots.

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 Jan 2008 11:32:24 -0800

I'm concerned about the case where an end station moves and doesn't 
announce itself. There's no requirement in ethernet to do so, and such a 
station would never be discovered if we don't flood broadcast to all links.

I.e., the optimization below is a recipe for ARP failure in such cases. 
I disagree with it.

Joe

---

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 7 Jan 2008 15:43:49 -0500

On
> Behalf Of Joe Touch
> Sent: Monday, January 07, 2008 11:32 AM
> To: Anoop Ghanwani
> Cc: [email-masked]
> Subject: Re: [rbridge] Consensus Check: Configure ports to disableend
> stationtraffic
> 
> announce itself. There's no requirement in ethernet to do so, and such
> a station would never be discovered if we don't flood broadcast to all
> links.
> 

In the general case, I agree with you. But I believe there are special
cases where such optimization are valid and valuable. For example, a
chassis manager does not need to rely on ARP to detect when the card
in a given slot has been inserted or removed.

In other words, designation of an "edge port" should be based on
something more than a network administrator checking a box that
says "I don't plan on putting any rbridges to the left of this
rbridge". Inherent physical topology is at least one criteria
that I think justifies making such assumptions. There may be
others, but I haven't worked with any of them.

---

From: James Carlson <[email-masked]>
Date: Mon, 7 Jan 2008 15:39:27 -0500

> I.e., the optimization below is a recipe for ARP failure in such cases. 

That "failure" is exactly the intent.

In other words, if you connect an end station to a special internal
network that is intentionally designed by a network administrator
_not_ to have end stations on it at all (which is what this
configuration option specifies), then you've made a mistake, and you
should _expect_ the node's attempts to communicate to fail miserably.

Obviously, the default should be to forward these messages (ports
can't be "TRILL-only" type by default), but why try to prohibit
implementations from offering an option if vendors so choose?  ARP
failure modes for nodes that shouldn't be there at all shouldn't be a
reason for a prohibition.

On the consensus proposal, I don't see a real reason why a description
of such an option needs to be in the spec -- it seems to me that an
implementation could provide such a feature under the guise of a
"local optimization" without needing this group's permission to do so
-- but if it is going to be there as an option, I'd weakly support it.
(Really ... do we think we can outlaw vendor features or that we need
to explicitly endorse each one?)

(I say "weakly" because _every_ option added increases complexity, and
that's one of the important problems.  But if it's somehow crucial,
then ok.)

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 Jan 2008 13:08:34 -0800

James Carlson wrote:
> implementations from offering an option if vendors so choose? 

No reason. This is fine in that case. The doc should be clear about the 
potential for silent misconfiguration in those cases.

(note - this is a silent misconfiguration issue; it'd be much easier if 
we could know that such a misconfiguration would be detectable)

Joe

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Mon, 7 Jan 2008 13:15:59 -0800

If the network operator decides that a link should
never have end stations on it, and if an end station
ends up there, then that is a misconfiguration
and I think it would be OK for the end station 
to not be reachable in that case.

BTW, even if the end station annouced itself,
configuring the link per Donald's message would
have prevented us from reaching that station.
In other words, this problem will happen regardless
of the protocol in operation.

If we don't allow the optimization, the spec will
require that RBridges flood copies of all frames
on all links.

This is a configuration optimization which I think
is essential and which, even if not provided by 
the spec, will most likely be provided by
implementations.

Anoop

> From: Joe Touch [mailto:[email-masked]] 
> Cc: Eastlake III Donald-LDE008; [email-masked]
> Subject: Re: [rbridge] Consensus Check: Configure ports to 
> I'm concerned about the case where an end station moves and 
> doesn't announce itself. There's no requirement in ethernet 
> to do so, and such a station would never be discovered if we 
> don't flood broadcast to all links.
> 
> > port, we would never see non-TRILL encap'ed frames (other than the 
> > usual exceptions such as BPDUs and other link layer control 
> traffic).
> > 
> > I wonder if it makes sense to also have a configuration for a TRILL 
> > "edge" port -- one where we are configured to never send TRILL 
> > encap'ed traffic because we don't intend for it to be used as a 
> > transit link (even though connectivity may exist to another RBridge 
> >> Subject: [rbridge] Consensus Check: Configure ports to disable end 
> >> stationtraffic
> >>
> >> If no particular controversy arises over this in the next three 
> >> weeks, We will declare it to be the working group consensus.
> >>
> >> Thanks,
> >> Donald & Erik
> >>

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 Jan 2008 13:31:56 -0800

PS - I do have to admit I don't like optimizations that have silent 
failure modes. I hope we can spend more time focusing on the core 
functionality, and less time on things like this.

Joe

Joe Touch wrote:
>>> announce itself. There's no requirement in ethernet to do so, and 
>>> such a station would never be discovered if we don't flood broadcast 
>>> to all links.
>>>
>>> I.e., the optimization below is a recipe for ARP failure in such 
>>> cases. I disagree with it.
>>

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 8 Jan 2008 13:15:51 -0600

James,

	I agree with you and Anoop on one point: if configuration
assumes the absence of end-stations on a local link and end 
stations are either already present, or are later are added on 
that local link, then this is a configuration/deployment error.

	However I disagree that ARP failure is a specific intent
of the configuration option mentioned in Donald's "consensus
check" or that this is sufficient to somehow "enforce" a network
operator's intention that a link should remain "end-station free."

	Certainly ARP will not work, but neither will any other 
broadcast or (non-IP) multicast based application or protocol.
That is essentially a side effect, however, and not the intent
of the consensus originally proposed.  In the original proposed
consensus (which I notice has been removed from this thread),
the intention was to eliminate wasteful forwarding to a link 
that contains no end-stations.

	While I believe the consensus proposal has been misworded
in such a way that it implies configuration would be used to 
indicate that a link has no end-stations, merely disabling the
forwarding of ARP (and other similar traffic) will not prevent
end-stations from being added to a link - and working on that
link - nor will it necessarily prevent existing end-stations 
from continuing to work on such a link.

	Hence configuring an RBridge to disable certain types of
presumed wasteful traffic forwarding on a link is orthogonal to 
indentifying that link as end-station free.

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:[email-masked]] On Behalf Of James Carlson
> Sent: Monday, January 07, 2008 3:39 PM
> To: Joe Touch
> Cc: [email-masked]
> Subject: Re: [rbridge] Consensus Check: Configure ports 
> todisable end stationtraffic
> 
> Joe Touch writes:

---

From: James Carlson <[email-masked]>
Date: Tue, 8 Jan 2008 14:51:15 -0500

> operator's intention that a link should remain "end-station free."
[...]
> indentifying that link as end-station free.

I don't think it's quite orthogonal.  The two are related in that if
you "optimize" away this "wasteful" traffic, you necessarily also
break the operation of any ordinary end stations that may be present
on that link, as Joe Touch was correctly pointing out.  Those nodes
can't work normally, so you're already partway down the path to
breaking those nodes intentionally.

But fair enough to observe that there are two different intents here.
I think Anoop was arguing more forcefully in favor of having a more
generic (and thus simpler) "no end-station on this link" option on the
theory that some links may be "known" (by an administrator) to be on
the inside of a network, and thus optimizing all of the end-station-
related behavior away would be useful for some implementations.

It seems particularly attractive given that TRILL wants to encapsulate
things.  If we were "only" bridging, this wouldn't be an issue.

I'd be ok with either intended option, but would slightly prefer not
bothering to document this special link behavior, as it looks to me to
be the sort of enhancement that vendors could cook up on their own
without affecting either TRILL interoperability or ordinary RBridge
operation.  It's not something I think is strictly _needed_ in the
TRILL document in order to make it complete ... though it seems Anoop
does.

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 8 Jan 2008 14:16:53 -0600

Donald,

	The wording of this is ambiguous and the intention is 
therefore not clear.

	What it appears like people are arguing for is the option
to exclude - via configuration - any port from the flooding or
other broadcast/multicast traffic.  One reason for doing this 
might be that the network operator is certain that there are not
and never will be end-stations associated with this link.  This
is merely one reason.

	As I mentioned in response to James' comment, disabling
flooding, and forwarding of other forms of broadcast/multicast
traffic does not necessarily preclude attachment of many of 
today's end-stations (although disabling ARP responses would 
make it more difficult, as would bi-directionally disabling 
broadcast forwarding).

	Hence configuring a port to disable flooding for that 
port and configuring a port to say there are no end-stations 
is not exactly that same thing.

	Further, the proposed consensus is unclear on the scope
to which it might apply.  I assume that the intention is only
to apply this on egress from the RBridge domain onto a legacy
Ethernet link.  If this is the case, however, that should be
explicitly stated as part of the proposed consensus.

	However, even if this is the case, it clearly must be
the case that we are assuming no similar technology is also
connected to this same link - and the link is in fact a stub 
with respect to every VLAN with which it is associated - or
we face the situation in which we don't forward broadcast or
flooded messages some other technology relies on to discover
topological pathologies itself - in the event of accidental
connections.

	Also, the proposed consensus is unclear on the impact
that declaring a port as transit only would have on non-IP
multicast traffic

	Frankly, I believe the proposed consensus would be more
clear and acceptable if it implied less.  For example, I would
find something along these lines more acceptable:

"Forwarding of flooded and/broadcast frames on every port 
 associated with a VLAN, or every port in a LAN, except the
 port on which it was received is the default case. However,
 it is possible to preclude forwarding of this traffic for
 any port on which it is not required - via configuration,
 for example."

Naturally, this also would need to be explicitly defined to
apply only to RBridge egress.

	And even in this case, I have to wonder why we need to
say anything at all on this topic.  This strikes me as being
pretty much out of scope, since it relates to behavior that
does not impact RBridge interoperability in any way.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Monday, January 07, 2008 1:34 PM
> To: [email-masked]

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 8 Jan 2008 17:51:37 -0600

James,

	Perhaps not quite orthogonal, but definitely not 
100 % correlated.

	I disagree that you would necessarily break the 
normal operation of end-stations running on the link.
I thought I had said that previosuly, so maybe I am
not getting your point.  However, I am pretty sure 
Joe was talking about "silent end stations" which is
pretty far from the "normal case" these days.

	Many of today's end stations would work, as long 
as you don't explicitly disable ARP (as in both sending
requests and receiving responses) because many of them 
do not rely on being discovered by flooding.

	Also, the notion of "known to be on the inside
of the network" is a trap people fall into if they were
not listening to the discussion in this working group 
from 18 to 24 months ago in which the point was made on
several occasions that the intended "topological" notion
of "inside the network" is not actually topological at
all.  Connect two links that appear to be "outside of the
network" and they are now "inside of the network."  The
apparent "connection" of two or more "outside links" is
a normal occurrence during network startup.  Connection
or disconnection of physical links is something that an
operator may not have direct control over.

	However, I agree that this is something that should 
be out of scope (avoiding these discussions entirely).
And for mostly the same reasons.  But I also thought I
said that already too...

--
Eric Gray
Principal Engineer
Ericsson  

> From: James Carlson [mailto:[email-masked]] 
> Sent: Tuesday, January 08, 2008 2:51 PM
> To: Eric Gray
> Cc: Joe Touch; [email-masked]
> Subject: RE: [rbridge] Consensus Check: Configure ports 
> todisable endstationtraffic
> Importance: High
> 
> Eric Gray writes:

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Jan 2008 16:11:40 -0800

> pretty far from the "normal case" these days.

Keep in mind that a station may not know it moved. Sure, if its ether 
cable is disconnected at the end station, the most common current 
implemetations will announce themselves when reconnected. But users can 
move a hub without disrupting connectivity at an end station, and nodes 
would never re-announce themselves in that case.

I.e., AFAICT this is the normal case when moving a hub.

Joe

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Tue, 8 Jan 2008 18:18:11 -0800

> Sent: Tuesday, January 08, 2008 11:51 AM
> To: Eric Gray
> Cc: [email-masked]; Joe Touch
> Subject: Re: [rbridge] Consensus Check: Configure 
> portstodisable end stationtraffic
> 

> I'd be ok with either intended option, but would slightly 
> prefer not bothering to document this special link behavior, 
> as it looks to me to be the sort of enhancement that vendors 
> could cook up on their own without affecting either TRILL 
> interoperability or ordinary RBridge operation.  It's not 
> something I think is strictly _needed_ in the TRILL document 
> in order to make it complete ... though it seems Anoop does.

I agree it's not absolutely needed, but now that we have
discussed it on the mailing list, that we know it's useful,
and that we know the potential problems, we might as well
document it so we don't have to depend on every implementer
figuring it out for themselves.

Anoop

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 9 Jan 2008 07:39:19 -0600

Anoop,

	Sorry to have to disagree with your well-intended
suggestion, but this is a BAD idea.

	The fact that we don't need to document it from a
interoperability perspective is sufficient reason not to
do so.

	In addition, anything we document because we "know
it to be true and useful" we need to be certain is also
immutable - even if we also know that we need to include
it in the specification.  Otherwise, it's a risk we are
undertaking that what we "know to be true and useful" 
will be false or dangerous next year.

	Hence the fact that we believe we could document it
is not sufficient reason to do so.  Therefore, to remove
any possible ambiguity, the argument to avoid including
this is sufficient while the argument to include it is
not.

--
Eric Gray
Principal Engineer
Ericsson  

> From: Anoop Ghanwani [mailto:[email-masked]] 
> Sent: Tuesday, January 08, 2008 9:18 PM
> To: James Carlson; Eric Gray
> Subject: RE: [rbridge] Consensus Check: Configure

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 09 Jan 2008 08:07:03 -0800

I concur,

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 09 Jan 2008 08:04:39 -0800

I agree with James' position. 802.1d bridges do such optimizations 
without their being specified in the spec. This seems like a 
box-specific optimization and I don't see a need for something like this 
in the spec.

Dinesh

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 09 Jan 2008 08:06:34 -0800

I concur with Eric,

Dinesh

---

From: James Carlson <[email-masked]>
Date: Wed, 9 Jan 2008 11:18:09 -0500

> pretty far from the "normal case" these days.

Silent end stations are but one instance of the breakage -- and those
can actually happen if (as another poster pointed out) there's a
repeater or an ordinary bridge in the way that prevents the link
up/down transitions that would ordinarily cause chatter.

> do not rely on being discovered by flooding.

I don't see how that's true.  The original message in this thread
(lost in context due to odd quoting practices) said this:

Suppose we have such a switch, and someone enables it to disable that
traffic.

If that's done, then:

  - Broadcast ARP queries from other nodes on other Ethernet
    subnetworks will not be relayed to this link.  There will be no
    way for other nodes to _find_ the marooned node.

  - Broadcast ARP probes for address use (duplicate address detection)
    will not be sent to this link, allowing nodes on other links
    within the same broadcast domain to use the same IP address,
    undetected.

  - Non-IP broadcast messages won't be sent to this link.  Any
    protocols built on broadcast will fail.

I'm not sure what functionality you're intending to describe, but it
doesn't sound at all to me like this configuration will "work."

---

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 9 Jan 2008 13:20:38 -0500

> operator may not have direct control over.

If all that is required to have a "port known not to do X"
actually do X is for an operator to misconnect a cable then
I would agree that the RBridge (or Bridge) probably should
not be assuming that the cables were inserted properly.
That's just dangerous.

But there are specialized Bridges where such mis-configurations
are simply not physically possible. To cite one example, it is
common for Hypervisor's to offer (via a privileged domain such
as "Dom 0") a software switch that has internal ports leading
to virtual NICs associated with Guest Partitions and the actual
external Ethernet ports leading to the real world. No network
technician can accidentally plug a Virtual Machine into the
Ethernet Port, or vise versa.

> And for mostly the same reasons.  But I also thought I

Agreed. The key is that we do no what any RBridge to be
forced to do something that is clearly not appropriate 
given its physical packaging solely because a poorly worded
paragraph made it a requirement even though there was no
actual benefit to any actual deployment.

These special configurations do not need explicit blessing
in the draft.

Not being anywhere near as familiar with core bridges as I
am with edge issues, I am still unclear as to whether "port
with no end stations" is an aspiration that a network administrator
would like to see (but for which there is no guarantee, and hence
equipment should not simply assume that the aspiration will be
met) or something inherent (it would be physically absurd
to connect end stations off a given link because it inherently
is a long-haul link outside the building, or somesuch).

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Wed, 9 Jan 2008 10:30:06 -0800

I'd be interested in finding out what caused the editors
to send out the consensus check.  Obviously there was 
some discussion about this at the Vancouver meeting and
some folks must've thought it was a good idea.

(I wasn't at the meeting so I don't know who supported
this.)

While I don't feel very strongly about having to put
this in the document, I think it would be useful.  I
disagree that it would be a "BAD idea" to put it in
the document - I see it as extra information to help
the implementer.

Anoop 

> From: Dinesh G Dutt [mailto:[email-masked]] 
> Sent: Wednesday, January 09, 2008 8:07 AM
> To: Eric Gray
> Cc: Anoop Ghanwani; James Carlson; [email-masked]; Joe Touch
> disable end station traffic
> 
> I concur with Eric,
> 
> Dinesh
> Eric Gray wrote:
> > Anoop,
> >
> interoperability 
> > perspective is sufficient reason not to do so.
> >
> > 	In addition, anything we document because we "know it 
> to be true and 
> > useful" we need to be certain is also immutable - even if 
> we also know 
> > that we need to include it in the specification.  Otherwise, it's a 
> > risk we are undertaking that what we "know to be true and useful"
> > 	Hence the fact that we believe we could document it is 
> not sufficient 
> > reason to do so.  Therefore, to remove any possible ambiguity, the 
> > argument to avoid including this is sufficient while the 
> argument to 
> > include it is not.
> >
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> >
> >   
> prefer not 
> >>> bothering to document this special link behavior, as it 
> looks to me 
> >>> to be the sort of enhancement that vendors could cook up on their 
> >>> own without affecting either TRILL interoperability or ordinary 
> >>> RBridge operation.  It's not something I think is 
> strictly _needed_ 
> >>> in the TRILL document in order to make it complete ... though it 
> >>> seems Anoop does.
> >>>       
> discussed it 
> >> on the mailing list, that we know it's useful, and that we 
> know the 
> >> potential problems, we might as well document it so we 
> don't have to 
> >> depend on every implementer figuring it out for themselves.
> >>
> >> Anoop
> >>
> >>     
> >

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Wed, 9 Jan 2008 10:56:18 -0800

> Sent: Wednesday, January 09, 2008 10:42 AM
> To: Anoop Ghanwani
> Cc: Dinesh G Dutt; Eric Gray; [email-masked]; Joe Touch
> Subject: RE: [rbridge] Consensus Check: Configure ports to 
> Anoop Ghanwani writes:
> > I'd be interested in finding out what caused the editors to 
> send out 
> > the consensus check.  Obviously there was some discussion 
> about this 
> > at the Vancouver meeting and some folks must've thought it 
> was a good 
> > idea.
> 
> Please clarify.  Do you mean the rationale that the proposers 
> had for including the feature in the specification at all or 
> literally the reason for sending the confirmation email message?
> 
> If it's the latter, I don't understand.  Official business of 
> the IETF needs to take place on mailing lists, not in the 
> limited confines of in-person meetings.  See RFC 2418.

It's the latter...I'm wondering where the idea of
putting this in originated because I didn't see 
anything about it on the list until the consensus
check was sent out, and it must've been something
at the meeting that prompted the consensus check.

Anoop

---

From: James Carlson <[email-masked]>
Date: Wed, 9 Jan 2008 13:41:45 -0500

> some folks must've thought it was a good idea.

Please clarify.  Do you mean the rationale that the proposers had for
including the feature in the specification at all or literally the
reason for sending the confirmation email message?

If it's the latter, I don't understand.  Official business of the IETF
needs to take place on mailing lists, not in the limited confines of
in-person meetings.  See RFC 2418.

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 9 Jan 2008 13:53:46 -0600

Joe,

	That being the case, it is likely that I have 
unfairly blamed the OS when I've been obliged to use
"ipconfig /release" and "ipconfig /renew" because I
can't get a response from the network.  

	:-)

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Tuesday, January 08, 2008 7:12 PM
> To: Eric Gray
> Cc: James Carlson; [email-masked]
> * PGP Signed: 01/09/2008 at 01:11:41 AM
> 
> 
> Eric Gray wrote:
> > James,
> > 
> * Joe Touch <[email-masked]>
> * 0x89A766BB
> 
>

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 9 Jan 2008 13:47:37 -0600

James,

	Please see below...

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Wednesday, January 09, 2008 11:18 AM
> To: Eric Gray
> todisableendstationtraffic
> Importance: High
> 
> Eric Gray writes:

That is not strictly true in many cases.  For example, if the 
"marooned node" has used DHCP to obtain an IP address and the
information for the default router, DNS server, etc. - then
it will be in the bridge (and presumably RBridge) forwarding
tables, and if the DHCP server is also the local LAN's default
router (or, in many cases, any router), then it will have the 
MAC<->IP address mapping to respond to an ARP request from 
anywhere else.

This is the common case in many enterprise networks.

Note that - if broadcast traffic is bi-directionaally disabled,
then the DHCP request will not have been forwarded and the end
station ("marooned node") will truly be marooned.  However, I
suggest that this could be a very bad idea over the long run.
This could break things that work today and will very probably
break things (or make it difficult to work around) in anything
new proposed - for example - by IEEE.

>     within the same broadcast domain to use the same IP address,

Again, this is difficult to imagine unless the "marooned node"
is unable to contact the DHCP server, or DHCP is not in use.

>     protocols built on broadcast will fail.

Yes - at least to the extent that the "marooned node" counts on
receiving broadcast messages.  And?

Given the prevalence of VLAN technologies, and the detrimental
effect that broadcast-based protocols have in a VLAN environment,
how common is it in today's networks for workstations to use many
protocols that uses broadcast for both query and response?

> doesn't sound at all to me like this configuration will "work."

Try it in your home network, if you can.  Better yet, use Ethereal
to see what happens when you add a laptop to your local network.

Chances are you will see only one broadcast message associated with
adding the laptop and that will be coming from it, not going to it.

Also, once you start using the laptop, it may send one or more ARP 
queries to your default router (or it may simply forward everything 
to the default router's MAC, which it may have acquired from the 
DHCP response, and rely on IP re-directs if necessary).  Again,
broadcast messages come from the "marooned node" instead of going
to it.

If you let the laptop stay idle long enough, it may get lost from 
bridge/switch forwarding tables.  But even if this happens, it is
very likely that the user will release and re-acquire an IP address
(via the DHCP server) - or reboot - and all will be well.  Note 
that the need to do that is not uncommon for some operating systems
as it is.

Meanwhile, if you were thinking that merely disabling forwarding of
broadcast traffic to a link would prevent someone (e.g. - a hacker)
from putting an end-station on the link and accessing the network,
you should think again.  This is especially true if the person in
question merely wants to access the network for a short period of
time and then leave.

It will "work", sometimes without special effort, but almost any 
time with some minimal amount of manual configuration at the end 
station being inserted.

---

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 9 Jan 2008 15:33:34 -0500

On
> Behalf Of Eric Gray
> Sent: Wednesday, January 09, 2008 5:39 AM
> To: Anoop Ghanwani; James Carlson
> endstation traffic

Would it make sense to go as far as to state that any
implementation-specific optimizations on frame forwarding
that are appropriate for a 802.1 Bridge are appropriate
for an RBRidge?

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 9 Jan 2008 14:52:35 -0600

Not especially.

Personally, I think that statement may be true, but I shy away
from including it in the specification.

To a certain extent, that would be a motherhood and apple pie
statement that - unfortunately - might not be true all of the 
time.  

Plus, in this case, there is still no particular issue with 
respect to interoperability between RBridges that is addressed 
by this specific aspect of forwarding at the egress.

Given that it is not hard to determine that there are a large
number of things (implementation specific optimizations) that 
are okay (they seem to work at least in some deployments) for 
802.1 bridges that may have to be considered before we could 
make such a statement, and no really relevant reason to make 
it, the sensible thing to do would be to remain silent on that
score.

--
Eric Gray
Principal Engineer
Ericsson  

> From: Caitlin Bestler [mailto:[email-masked]] 
> Sent: Wednesday, January 09, 2008 3:34 PM
> To: Eric Gray; Anoop Ghanwani; James Carlson
> disable endstation traffic
> Importance: High
> 
> 
>

---

From: James Carlson <[email-masked]>
Date: Wed, 9 Jan 2008 15:32:15 -0500

Eric Gray writes:
> 	Given that we (and a number of others) seem to agree that 
> this should not be included in the specification - for whatever
> reason - than the fact that we don't seem to be understanding 
> each other's point is a good reason to just let this drop.

I'll certainly agree with that.

---

From: James Carlson <[email-masked]>
Date: Wed, 9 Jan 2008 15:04:29 -0500

[...]
> MAC<->IP address mapping to respond to an ARP request from 

Who is generating that ARP response?

It can't be the marooned node, because the ARP request itself is a
broadcast, which (by definition of this new feature) is not propagated
onto the feature-limited link.

Thus, it sounds like you're talking about some sort of proxy ARP
within a bridged network.  I suppose that's "possible" but I would
have a hard time calling it anything other than "extraordinary."

> This is the common case in many enterprise networks.

Generating an ARP response on behalf of a node that's bridged but
can't see the original ARP request is "common?"  Not in any of the
networks I work on.  The only case I know of is with proxy-ARP'd PPP
links, but I don't think we're talking about that sort of situation.

> station ("marooned node") will truly be marooned.

Some DHCP servers generate broadcast responses and others generate
unicast only.  It depends.  :-<

>  However, I

Certainly ... and the existence of that breakage does in fact leave
that node "broken," which was my original claim.  It's broken anyway,
so we might as well assume that the admin was smart enough not to put
it there.  It's not much different from assuming that he knows enough
to apply power, and to plug the Ethernet wire into the network rather
than the PBX line.

> is unable to contact the DHCP server, or DHCP is not in use.

It's by definition of the proposed configuration option we've been
discussing.  When configured in this way, broadcast messages will not
be sent to that link.  The existence or use of DHCP is immaterial.

> receiving broadcast messages.  And?

... and it's broken.

> protocols that uses broadcast for both query and response?

"Very."

What do VLANs have to do with anything at all?  Broadcast works fine
on VLANs.

> adding the laptop and that will be coming from it, not going to it.

I'm snooping broadcast right now, and I see a bunch of traffic.

I really don't understand what you're saying.

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 9 Jan 2008 14:27:59 -0600

James,

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Wednesday, January 09, 2008 3:04 PM
> To: Eric Gray

---

From: James Carlson <[email-masked]>
Date: Wed, 9 Jan 2008 17:16:29 -0500

> potential for silent misconfiguration in those cases.

One possibility would be for implementations that offer this option to
listen to traffic on the links on which default broadcast has been
disabled.  If the implementation sees packets it's not expecting
there, then either raise an alarm or simply turn the option flag back
off automatically in order to preserve correct operation.

That wouldn't be _perfect_, as a quarry of completely silent local
nodes would (as described before) fail to operate completely
correctly, but it may well be "good enough" for general use, given
that most nodes will eventually send some sort of packet once in a
while, if only as a lark, and you just need _one_ to detect the
misconfiguration.

The option proposed is an optimization that reduces duplicate
transmissions ... but does so only for traffic that ought to be (by
design) very low rate; unknown destinations and broadcast.  If it
isn't implemented or if it might automatically turn itself back off,
it doesn't seem like a substantial problem to me, though I suppose
there are a few degenerate large flat networks out there where
broadcast more resembles a shower than a mist.

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 9 Jan 2008 16:46:43 -0600

Anoop,

	Look for "Tentative Consensus" in the presentation on 
"Changes from -06 to -07", given by Donald Eastlake (III).
It's from the minutes available at:

http://www3.ietf.org/proceedings/07dec/minutes/trill.txt

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Wednesday, January 09, 2008 1:56 PM
> To: James Carlson

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 9 Jan 2008 16:59:32 -0600

Anoop,

	This is a good question.  Hopefully we've all had a chance
to look at the minutes.

	From the minutes, it looks as if we could say two things:

1) there was not anything like an overwhelming consensus even at
   the meeting and
2) there seems to be some disparity between the wording in this
   and the apparent meaning given in the discussion about it.

For the second point, there is a distinction that is not made
clear (in any way) between a link with no end-stations and a
point to point link between exactly two RBridges.  Also, the
minutes do not make clear what happens on discovery of the fact
that this configuration is incorrect (the minutes state that the
port would be disabled - which hardly strikes me as the most
robust thing to do in handling this situation).

In defense of the question, there had been prior discussion on
the mailing list to allow that RBridges might be configured to
recognize that a link is point to point.  I am not at all sure
there was any basis to call this a "tentative consensus."  In
the prior discussion on the mailing list, I believe the points
that Joe brought up at the meeting were also made (i.e. - it is
a soruce for configuration error with no real benefit).

On the first point, only one opinion is expressed in the minutes
and that opinion is disagreement (Joe's point mentioned above).

--
Eric Gray
Principal Engineer
Ericsson

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Wed, 9 Jan 2008 17:19:43 -0800

Well, this can be seen as more than an optimization.
It could be seen as a security feature.

For example, with 802.1Q bridges, we have configurations
for "Admit VLAN-tagged frames" or "Admit all" on each
port.  This does not affect interoperability in any
way.  However, it just says that the switch port is
not willing to admit untagged traffic.  They could
have just left this out of the spec and untagged
traffic would have gotten the PVID and the world
would have done just fine. 

Going back to the example that has been pointed
out by folks where ARP breaks.  In 802.1Q, if an 
end station moves from a port that admits untagged
traffic to a port that doesn't admit untagged traffic
then things would break there as well.

In any case, I don't know why folks are making 
such a big deal about this.  Since it doesn't affect
interoperability, it's not required in the spec.
But the spec already has TONS of informational
material, so I don't see why adding something 
like this is a problem - something which actually
helps the implementer.

Anoop

> [mailto:[email-masked]] On Behalf Of Dinesh G Dutt
> Sent: Wednesday, January 09, 2008 8:05 AM
> To: James Carlson
> Subject: Re: [rbridge] Consensus Check: Configure portsto 
> I agree with James' position. 802.1d bridges do such 
> optimizations without their being specified in the spec. This 
> seems like a box-specific optimization and I don't see a need 
> for something like this in the spec.
> 
> Dinesh
> James Carlson wrote:
> > Joe Touch writes:
> >   
> >> such a station would never be discovered if we don't flood 
> broadcast to all links.
> >>

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Wed, 9 Jan 2008 23:26:24 -0500

Hi,

Speaking as co-chair:

All "Consensus Check" messages that have been posted here are because
there was at least a rough consensus at a meeting and, per IETF
procedure, the consensus is being tested on the mailing list. It is then
the job of the working group chairs to judge the consensus of the
working group based on integrating the meeting and mailing list.

There were two distinct proposals presented in Vancouver, one of which
is outlined in the message below, and for which there was a consensus in
favor at the meeting.

The second was a specific proposal for point-2-point links between
Rbridges for which I will post a Consensus Check right after this
message. This second proposal specified fixed destination and source
addresses for a port so configured and the consensus at the meeting was
against it. There were several negative comments on the second proposal.

Sorry if the minutes are confusing on this point. If it is not too late
to change them, I'll try to clarify them.

Speaking as a member of the WG:

"End station traffic" below means all traffic except (1) TRILL Ethertype
frames and (2) link/media control frames (frames with a destination
address in the range 01-80-C2-00-00-00 to 01-80-C2-00-00-0F). An end
station on a link where all connectivity to the outside world is via one
or more Rbridges whose ports to that link are configured to disable such
traffic would be completely marooned. It seems likely that there would
be a MIB counter for end station frames received on a port that was
"disabled" for them but we haven't done any MIB work yet.

I was motivated to make this proposal when I recently read the
Architecture draft and was thereby reminded that the current TRILL
specification requires that all broadcast, unknown unicast, and
non-IP-derived multicast are output to every link. In a modern all
Rbridged 802.3 campus, one would expect that all links would be Rbridge
to end station or Rbridge to Rbridge. Thus, all such frames output on an
Rbridge to Rbridge link are completely wasted. The extent of the waste
would depend on the percentage of traffic of this type. While keeping
such traffic to a small percentage is generally desirable, there may be
networks where it is substantial, resulting in a substantial waste of
capacity on all Rbridge to Rbridge links. So I believe this capability
will be present in essentially all configurable Rbridges. Given this,
and the simplicity of the option, my personal opinion is that we should
provide for it.

In principle you could also disable TRILL traffic. But that does seems
like a bad idea. Disabling end station traffic incorrectly would just
maroon one or more end stations. Disabling TRILL traffic incorrectly can
lead to loops and traffic storms that could bring down part or all of
your network.

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Monday, January 07, 2008 1:34 PM
To: [email-masked]
Subject: [rbridge] Consensus Check: Configure ports to disable end
stationtraffic

Thanks,
Donald & Erik

---

From: "Eric Gray" <[email-masked]>
Date: Thu, 10 Jan 2008 10:05:12 -0600

Anoop,

	Please see in-line below...

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
> Sent: Wednesday, January 09, 2008 8:20 PM
> To: Dinesh G Dutt; James Carlson

Possibly, but not as originally proposed at the start of this 
thread.

Donald has restated the portion of the proposal that breaks 
the original statement into two pieces - with one of those 
pieces being the option to configure a port on an RBridge as
one end of a P2P link.  

You should note two things in Donald's new post:

1) the new proposal does not elaborate on the implications
   of having a P2P configuration option, it does not state
   why it might be useful, nor does it state what impact
   adding this feature would have on the specification;
2) the consensus at the meeting was against including that 
   in the protocol specification.

Part of the message, in which he said he was planning to re-
state that portion of the consensus call, mentioned that one 
advantage of allowing this would be an implementation could
exclude all traffic that is neither TRILL-encapsulated nor 
bridging control traffic from ports that might be configured 
for P2P connection.

IFF he were to make that an explicit part of the proposal, 
THEN you could make the argument that this is a security
feature.  I don't know whether or not that argument would 
fly, but you could make it.  For it to work, though, the
specification would have to be very explicit about what is
not allowed - and it would have to deal with both the P2P
case and the MP2MP, RBridge only, case OR it would simply
not be very effective as a security feature.

As it is, most people were under the impression that the 
reason why this had been brought up previously is that a
few of the working members of the WG had proposed use of
an abbreviated encapsulation for RBridge links that were
strictly point to point.  In that case, and with that 
background, the existence of end-stations on a link was a
collateral consideration, since the proposal depended on
more than the lack of end-stations - it also required the
presence of not more than 2 RBridges on the same link.

Apparently, several ideas have been conflated into a single
potential approach - configuring a port as one end of a P2P
link could allow many things.  However, it is also the case
that the WG decided that it is not necessary for us to say
this in the protocol specification, since it is obvious that
many people can think of these things on their own, we are
not planning to specify a distinct encapsulation in the P2P
case, and it isn't relevant from a protocol interoperability 
perspective.

> would have done just fine. 

I think that might be an over-simplification.  Having the
option to ignore untagged frames allows implementations
built to only handle tagged frames to interoperate with
other 802.1Q bridges, since requiring the option to turn
off forwarding of untagged frames provides a means to
ensure that an 802.1Q bridge that doesn't handle untagged
frames, doesn't see them.

Apparently, there must have been at least one implementer
that felt that having the option to ensure only tagged
frames show up on core links was important - hence it is
necessary to be able to ensure that they can be blocked.

That is fairly close to being an interoperability issue.

> then things would break there as well.

Maybe.

I believe it is the case that some platform/OS combinations
may have the native ability to discover the existing link 
encapsulation from simple snooping.