Subject: [rbridge] Pseudonode minimization thoughts...

From: Radia Perlman <[email-masked]>
Date: Mon, 28 Jan 2008 21:05:13 -0800

The WG seemed to think that the pseudonode minimization was a good thing 
for all link state protocols, and therefore
should be proposed in the routing working group rather than in TRILL.

I'm not convinced it is possible to put in the extra flags necessary for 
OSPF, so perhaps it should just be presented in IS-IS instead.

Also, I was thinking about a rationale for a good cutover. What I 
proposed originally, picking numbers out of
the air, was 1 or 2 routers, no pseudonode, 5 or more, pseudonode, and 
anything in between, stick with what it was.

Originally, IS-IS was designed for CLNP, and it was necessary to report, 
for each link, all the attached endnodes. So
even if there were only 2 routers on a LAN, it made sense to create a 
pseudonode, so that all the endnodes wouldn't
get reported by both routers.

But for TRILL--there really isn't anything reported in the pseudonode 
other than the set of router neighbors.
Things like the set of supported VLANs, and the set of roots that an 
RBridge might select for a multicast tree, are all
reported in the RBridge's individual LSP. The only thing in the 
pseudonode LSP is the set of RBridge neighbors.

So, I'm thinking that the right cutover would be something like 15 
RBridge neighbors before it's worth creating another
LSP that has a whole header, and appears in every other RBridge's CSNP.

I  must say it's not easy to find the packet formats for IS-IS to get 
the exact number of bytes in an LSP. :-(

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

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Tue, 29 Jan 2008 19:26:42 -0000

Yes,

There are a few concerns..

I have been looking at this with Radia. Using Link Local Signalling
(Extended Options -TLV) worked on by Alex Zinin this is in fact quite
possible with OSPF. This draft is an OSPF working group draft and so
presumably will be implemented. draft-ietf-ospf-lls-03.txt

Matthew R Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: 29 January 2008 05:05
To: Developing a hybrid router/bridge.
Subject: [rbridge] Pseudonode minimization thoughts...

Radia

---

From: mike shand <[email-masked]>
Date: Wed, 30 Jan 2008 09:19:13 +0000

Radia,
    I'm confused. I thought that what you were proposing was switching 
all the mechanisms from "LAN" to "Pt-Pt". i.e. not only removing the 
pseudonode, but also using pt-pt mechanisms for the update process, 
rather than the broadcast and CSNP mechanism we have for LANs.

This is exactly what we do at the moment when we configure a LAN as a 2 
node pt-pt "LAN".

However, this made me very nervous since I don't like the idea of 
dynamically messing with the operation of the update process.

But, this post makes me think that you mean ONLY getting rid of the 
pseudonode, but retaining the CSNP and broadcast based update process. 
Otherwise, if you reduce a 15 node LAN to a full mesh pt-pt you are 
going to get in excess of 200 LSPs crossing the LAN (not to mention ACKs).

If all you want to do is get rid of the pseudonode, then I am much less 
nervous, But I'm still not really convinced it is worth the bother.

Could you explain exactly what you have in mind.

    Mike

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 30 Jan 2008 12:22:03 -0600

Mike,

	I'm not sure where you got the impression that we're
planning to change all interactions between RBridges to a
P2P model.  I think it's possible that you're conflating a
few - probably unrelated - discussions/issues.

	We've had a lot of discussion around behaviors and
possible optimizations for the case where we can be certain
(possibly based on configuration) that a connection between
exactly 2 RBridges is P2P.

	One of the optimizations is that - where this applies
- then it's clearly unnecessary to use any of the mechanisms
associated with the MP2MP case.  Such an optimization should 
include not using pseudo nodes - if (for some reason) pseudo
nodes might otherwise be created in all cases.

	This is not obviously related to possibly using P2P 
update processes when more than 2 RBridges are connected via 
the same link, is it?

--
Eric Gray
Principal Engineer
Ericsson  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of mike shand
> Sent: Wednesday, January 30, 2008 4:19 AM
> To: Radia Perlman
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Pseudonode minimization thoughts...
> 
> Radia,

---

From: Radia Perlman <[email-masked]>
Date: Wed, 30 Jan 2008 11:59:27 -0800

Absolutely. The intention wasn't to "treat the link like a pt-to-pt 
link" in terms of how LSPs get flooded and ack'ed and all that.
That would be too much trouble. It might be more efficient if there are 
really just two RBridges, to send acks for each LSP
rather than the periodic CSNP, but it seems like more trouble for 
implementations to be
able to switch back and forth, and more confusing to switch modes. And 
even with just two RBridges, it isn't horrible
to send CSNPs.

However, it does seem horrible to create a pseudonode and an associated 
LSP for it,
for every port, whether there are only two RBridges on the link,
or worse yet, a single RBridge with a single endnode.

So yes...I'm only proposing that a "non-pseudonode LAN" get reported in 
LSPs differently. If R1, R2, R3, and R4 are on a link,
and, say, R1 is DRB, then if R1 says "use pseudonode named R1.25", then 
each of R1, R2, R3, and R4 report the
neighbor "R1.25" in their LSP, and R1 also generates a pseudonode for 
R1.25, and reports in that, neighbors R1, R2, R3, and R4.

If R1 says "don't use pseudonode", then each of them reports 3 
neighbors; R1 reports R2, R3, R4.....R2 reports R1, R3, R4, etc.

Hope that clarifies -- and sorry for the English ambiguity in the phrase 
"treat the link like a bunch of pt-to-pt links" which undoubtedly
was a bit scary if you interpreted it the other way.

Radia

mike shand wrote:
> This is exactly what we do at the moment when we configure a LAN as a 
> 2 node pt-pt "LAN".
>
> If all you want to do is get rid of the pseudonode, then I am much 
> less nervous, But I'm still not really convinced it is worth the bother.
>
>> The WG seemed to think that the pseudonode minimization was a good 
>> thing for all link state protocols, and therefore
>> I'm not convinced it is possible to put in the extra flags necessary 
>> for OSPF, so perhaps it should just be presented in IS-IS instead.
>>
>> the air, was 1 or 2 routers, no pseudonode, 5 or more, pseudonode, 
>> and anything in between, stick with what it was.
>>
>> Originally, IS-IS was designed for CLNP, and it was necessary to 
>> report, for each link, all the attached endnodes. So

---

From: mike shand <[email-masked]>
Date: Thu, 31 Jan 2008 10:19:39 +0000

Radia Perlman wrote:
> That would be too much trouble. It might be more efficient if there 
> are really just two RBridges, to send acks for each LSP
> However, it does seem horrible to create a pseudonode and an 
> associated LSP for it,
> So yes...I'm only proposing that a "non-pseudonode LAN" get reported 
> in LSPs differently. If R1, R2, R3, and R4 are on a link,
> and, say, R1 is DRB, then if R1 says "use pseudonode named R1.25", 
> then each of R1, R2, R3, and R4 report the
> Hope that clarifies -- and sorry for the English ambiguity in the 
> phrase "treat the link like a bunch of pt-to-pt links" which undoubtedly
Radia,
    Thanks for the clarification. Much less scary:-)

But I'm still not convinced there is any need for this complexity.

We already handle the N=2 case by configuration, and that DOES turn the 
link into a genuine pt-pt link using pt-pt update process. This seems 
like a worthwhile optimization, but I wouldn't want to do it 
automagically. Configuration seems to work well. People tend to know 
whether or not they have 2 or more routers on a LAN, and if they think 
there are 2 and a third turns up that is clearly an error, and should be 
treated as such. See

draft-ietf-isis-igp-p2p-over-lan-06.txt

If the motivation for removing the pseudonode is purely space saving in 
the LSP database, then it seems to me that this only applies for very 
small N. I think you win with N=3, and lose with N=4, and it gets worse 
rapidy for >4. And that is assuming we only have router neighbor 
advertisements.

with no pseudonode we get n(n-1) neighbor advertisments, and with a 
pseudoonode we get 2n advertisments.
The pseudonode itself adds some 27 octets of header, and there is no 
area address. and we need another 2 for the neighbor TLV header.
Router neighbors take 12 octets per additional neighbor (narrow 
metrics), or 11 for wide metrics.

So for N=3 we have

with PN 6*12 +29 = 101
without PN 3*2*12 = 72

For n=4

with 8*12+29 =125
without 4*3*12 = 144

for n=15

with 30*12+29 = 389
without 15*14*12 = 2520

I may have made a few errors there, but I think the principle is clear.

It only seems worthwhile for the n=3 case. And even that is marginal.

Of course there is the additional complexity of generating the PN, but 
we have to do all the DR election stuff for the update process anyway, 
so I don't see that as much complexity compared with the complexity of 
figuring out whether you have to do it or not.

I'm not even convinced it simplifies the SPF, but since an SPF for a 
several hundred node network takes < 1mS, I don't see this as a big 
issue either way. However for a 15 node LAN, WITH pseudonode you explore 
1 hop to the PN then 14 hops to the other nodes, then check on back link 
from each of the 14 to the PN (i.e 29 links). In the non PN case you 
explore 14 hops, then another 14 hops back from each of those 14 (i.e. 
210 links). It would need a better analysis to determine exactly what 
the relative merits are, but at best I would say it is a wash, and it 
might even be a pessimisation not to have a PN.

"If it ain't broke, don't fix it."

    Mike

>> pseudonode, but retaining the CSNP and broadcast based update 
>> process. Otherwise, if you reduce a 15 node LAN to a full mesh pt-pt 
>> you are going to get in excess of 200 LSPs crossing the LAN (not to 
>> mention ACKs).
>>
>>
>>> even if there were only 2 routers on a LAN, it made sense to create 
>>> a pseudonode, so that all the endnodes wouldn't
>>> But for TRILL--there really isn't anything reported in the 
>>> pseudonode other than the set of router neighbors.
>>> I  must say it's not easy to find the packet formats for IS-IS to 
>>> get the exact number of bytes in an LSP. :-(
>>>
>>> Radia

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Thu, 31 Jan 2008 11:00:55 -0000

Hi Mike
 
I did similar slightly more detailed  (but approx the same math) on this last year for OSPF and produced quite similar results. This is a byte count justification, but the SPF one yields similar numbers.
 
The issue here is the build up of (OSPF) the Network-LSA. / Pseudonode LSP. For each Lan that is missed by the designers a Network-LSA is flooded out to the whole area. Over time these build up.
 
The amount of data we are discussing on the LAN here is as you say quite small. Perhaps a decrease for 4? routers, and perhaps a small increase for 5? depending on circumstances, but its still bytes on Mb links
 
The problem is a remote router processing all sorts of unneccessary LSAs that arnt required to build the graph. Its a clean up that has been waiting for a while I would guess? So much of the world has moved pt-to-pt...
 
If this can be done as Radia  is suggesting without upsetting the flooding on the Lan and with few changes, and have the database clean itself up a bit I think that this is worthwhile..
 
my 2 cents..
 
Matthew R Thomas

________________________________

From: [email-masked] on behalf of mike shand
Sent: Thu 31/01/2008 10:19
To: Radia Perlman
Cc: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Pseudonode minimization thoughts...

Radia,

So for N=3 we have

with PN 6*12 +29 = 101
without PN 3*2*12 = 72

For n=4

with 8*12+29 =125
without 4*3*12 = 144

for n=15

with 30*12+29 = 389
without 15*14*12 = 2520

    Mike

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 31 Jan 2008 17:01:57 -0800

Radia -

The CSNP cost is a red herring.
CSNPs are not permanently stored in your LSPDB - they are used to verify
that your LSPDB is in sync with your neighbor(s) and then discarded. So
unless you are going to argue that the extra bandwidth used by CSNPs
(which are sent infrequently - even when periodic) with the additional
pseudo-LSP entries is prohibitive - this issue can be ignored.

Therefore Mike's calculations of the space savings/costs should be taken
as representative of the impact of this "enhancement".

As for your statement:

"I don't think it is complex. It costs 2 bits in Hellos."

This is a gross oversimplification. Although only two bits may needed
for encoding, there are numerous concerns which have to be addressed in
a robust implementation. For example:

1)How to do the transitions in a hitless manner
2)What should be done if all routers on the network do not support the
extension
3)Rate limiting transitions to avoid storms associated with router
instability

Given the quite limited set of circumstances in which any benefits are
realized and the modest gains that the extension can achieve in those
cases, it is very difficult for me to have any enthusiasm for this idea.

As for the zero configuration issue, treat LANs as LANs always if you
must.

   Les

> Sent: Thursday, January 31, 2008 1:15 PM
> To: Mike Shand (mshand)
> Well, I think it is really important to avoid configuration -- both
> because of the hassle of configuration,
> and people getting configruation wrong.
> 
> This proposal eliminates
> "silly pseudonodes", i.e., pseudonodes
> when there are only 1 or 2 routers on a link, and does not require
> configuration.
> 
> I don't think it is complex. It costs 2 bits in Hellos. I'm glad you
> worked out the math though. You're right, Mike, that if
> you just look at bytes in the LSP database, the cutover is at 4
routers
> where it is better to have a pseudonode, if you
> ignore the overhead of the CSNP (with a pseudonode *every* RBridge has
> to report an extra LSP ID and sequence number
> in the CSNP which is not trivial).
> 
> Your math was a bit terse, so let me redo it using your basic numbers
> and with a bit more explanation.
> I agree with your numbers, but I think it might be hard for others (it
> was hard for me) to understand it.
> 
> You said a pseudonode has 27 bytes of header.
> Plus it has to list all the router neighbors on the link.
> 
> You said that to report a neighbor it is 12 octets for narrow metrics,
> and 1 octets for wide metrics. Is that backwards perhaps?
> I'd think it should take more space to report a side metric, but no
> matter -- I'll use 12 octets per neighbor. (though it would
> be nice to get a clarification on that -- I could imagine that when
they
> redid the TLV for reporting metrics, they not only
> widened the metric but also compressed the format, or maybe got rid of
> multiple metrics).
> 
> So, with 4 routers, I seem to get the same result as you said, which
is
> it costs 21 octets in the LSP database to not use a pseudonode:
> 
> Here's the math worked out, with more comments:
> 
> Assuming 4 routers:
> Without pseudonode: each router reports 3 neighbors, so that costs 36
> octets each.
> With pseudonode, each router reports 1 neighbor, so that saves 24
octets
> in 4 LSPs, at a total savings of 96 octets, but then
> you have to add in the pseudonode LSP which has a header of 27, plus 4
> neighbors, so 27+4*12=75 octets. So I get that with
> 4 routers the octets in the LSP database alone, as you observe, you
lose
> without a pseudonode by 21 octets.
> Though as I said, the extra LSP also means an extra field in all the
> CSNPs.
> 
> With 5 routers, I get:
> 
> Without pseudonode, each router reports 4 neighbors, so that costs 48
> octets each, at a total cost of 5*48=240.
> With pseudonode, each router reports 1 neighbor instead of 4, saving
36
> octets in each of 5, at a savings of 180.
> The cost of the pseudonode is 27+5*12=87, so not having a pseudonode
> costs 180-87, or 93 octets. (though again, this is
> somewhat mitigated by getting rid of the extra LSP to report in the
CSNP).
> 
> This is useful data, in helping to pick the cutoff point. A possible
> reason to have a wider window between "no" and "yes" for
> pseudonode is so that it won't flip very often -- once a link has lots
> of routers, it stays that way. I think it will be very rare
> for a link to have exactly 5 routers, and even though in theory you
are
> wasting 93 bytes in the LSP database with 5 routers,
> it is mitigated by one less entry in the CSNP, which is multiplied by
> the total number of routers in the campus. So I think that
> the cutoffs of "2" and "5" are probably justifiable as the default,
> though I'd be happy with "2" and "4" as the default.
> 
> But at any rate, the difference in complexity between this proposal
> (which is 2 bits in a Hello, and the code to follow orders
> and report your neighbors directly rather than the pseudonode) vs
> requiring configuration on every pt-to-pt port (which more and
> more will be close to "all of them"), plus the potential for wrong
> configuration (more likely, the mistake will be not configuring a port
> to be pt-to-pt and therefore winding up with "silly pseudonodes") -- I
> think that this is important in order to allow reasonable
> operation with zero configuration.
> 
> Radia
> 
> 
> 
> 
> mike shand wrote:
> > Radia Perlman wrote:
> >

---

From: Radia Perlman <[email-masked]>
Date: Thu, 31 Jan 2008 20:31:01 -0800

Les, I'll address each of your concerns in the points below, and below 
that I have some questions for Mike and Les about IS-IS.

1) "What happens with mix of routers that support this feature or not?"

No problem at all. Whether this is being done or
not on link L is completely irrelevant to routers that are not attached
to L. Having a mix of routers on L is also not a problem. That's what
the extra bit in the Hello is -- saying you support this feature. If any 
router on L does not support the feature,
it works like it does today -- with a pseudonode, even if there are just 
2 routers, unless someone has configured all the routers
on L to consider L
to be pt-to-pt.

2) "How bad a hit are transitions?":

I think most "Ethernet" links, once we get rid of bridges, will only be 
pt-to-pt, so in that case there will be no
transitions to/from pseudonode. There would be no pseudonodes.

The only time there would be transitions is if we actually have a shared 
cloud with 3 or more routers.

I don't think this is a problem. It *is* a little worse when a (non-DR) 
router goes up or down when you have n (with n>2) routers
on a link when you don't use a pseudonode. With a pseudonode, when a 
non-DR goes up or down, there are just 2
new LSPs (if someone is coming up). Without a pseudonode, all the 
routers have to reissue their LSP to include the
new neighbor (or get rid of the dead one). But the proposal is to have a 
pseudonode if there are "a lot" of routers. We just
need to decide what "a lot" is.

Obviously I'm not against pseudonodes (just "silly pseudonodes" -- where 
there are only 2 or 1 routers on a link).

Suppose we got rid of the hysteresis and made it be "use pseudonode if 
there are at least 3 routers, otherwise, don't".
Some people get concerned about the hit of transitioning between 
pseudonode and not. But I think the only difference
at that threshold (2 routers vs 3) is that with a pseudonode, if it's a 
non-DR that joins or leaves, it's 2 LSPs that
gets issued, and without, it's 3 LSPs that get issued (the new guy, and 
the existing 2 have to each reissue their LSP to
include the new guy. I don't think that can be considered a big deal. 
With the hysteresis, transitions would happen even less frequently
(the first time you get to the high water mark, and then the first time 
you hit the low water mark.

3) "CSNP cost is a red herring since they take up no memory":

Counting the exact bytes in memory is a good back of the envelope 
estimate, but the exact numbers are not that important
(a few percent one way or the other are not that important -- both 
schemes work just fine in some ranges). Nor is it
possible to get an exact answer since there are other factors such as 
bandwidth.  That's all I was saying.

There *are* issues other than just counting the LSP database size in 
terms of the bytes in the LSPs.
CSNPs and acks take up bandwidth on each link, proportional to the 
number of LSPs (and each pseudonode
adds an extra LSP). On pt-to-pt links, keeping track
of the ack-status for each neighbor for each LSP presumably takes up 
memory, so each pseudonode takes up
memory in each pt-to-pt port on routers anywhere in the area And there 
is probably various implementation-specific
housekeeping like pointers to LSPs, that would take up memory per LSP.

Mike's arithmetic does show it's not stupid to use pseudonodes with 
relatively small numbers of routers on the link (like 3).
His arithmetic eased my anxiety attack over having introduced 
pseudonodes in the first place (for DECnet Phase V routing), since
I was thinking that although it made sense for CLNP and large shared 
CSMA/CD links,
in this new world where if we get rid of bridges, "Ethernets" are 
basically all links are pt-to-pt links,
that pseudonodes would wind up being a bad idea. In my anxiety attack, I 
was thinking that pseudonodes would only
be cheaper if there were like 20 routers on a link, since in TRILL 
(unlike CLNP where you have to list all the endnodes)
there's nothing in the pseudonode LSP except listing the routers on that 
link. But as I said, Mike's arithmetic reassured me
that it's fine to use pseudonodes, except it would be good to avoid them 
without any configuration, in the cases of
1 or 2 routers on the link.

4) limited circumstances when this is useful: Suppose a router 
mindlessly assumed there was a pseudonode for every port? I'd hope
it's smart enough not to create a pseudonode when there isn't even a 
single router neighbor? Not sure what IS-IS implementations
do with this. I could imagine that a router with a bunch of ports, each 
of which are "Ethernets", and for which hundreds of them
just have a single endnode on the other end, the router might elect 
itself DR, and create and advertise a pseudonode for each of those ports.
That would clearly be silly, and fairly easily avoided with the rule 
"don't advertise a pseudonode unless there is at least 2 routers
listed in the pseudonode (you and one other). So I think we need to 
ensure that this doesn't happen (don't advertise pseudonodes
when there is just a single router). And maybe it already does (can 
anyone verify this?)

The other case is when there are 2 routers. This might be basically 
*all* the router-router links, assuming a campus where all the bridges have
been upgraded into RBridges. In that case there would be 33% more LSPs, 
and an LSP approximately twice as big. It could be
even bigger than that if there are multiple pt-to-pt Ethernets 
connecting the same two routers. With pseudonodes, each port would be
a pseudonode, whereas it would be relatively easy for R1 to realize it 
shouldn't list R2 as a neighbor multiple times.

****************
So, actually, I have a few questions:

a) without configuration, would an IS-IS router today create a 
pseudonode if it is the only router on an Ethernet link?
For instance, suppose R1 and R2
are neighbors on an Ethernet, and R2 goes down. Will R1 will issue two 
LSPs, one saying the pseudonode is R1.25 with neighbor R1,
and another saying R1 has neighbor R1.25? Or when R2 goes down, does R1 
get rid of the pseudonode?

b) suppose R1 and R2 are both on the same Ethernet, and one is 
configured that that port is pt-to-pt and the other is not configured
that way. What happens?

c) suppose R1, R2, and R3 are all on the same Ethernet, and all are 
configured that that port is pt-to-pt. What happens?

Radia

Les Ginsberg (ginsberg) wrote:
>> From: [email-masked] [mailto:[email-masked]]
>>     
> On
>   
>> Behalf Of Radia Perlman
>>>> able to switch back and forth, and more confusing to switch modes.
>>>>         
> And
>   
>>>> So yes...I'm only proposing that a "non-pseudonode LAN" get
>>>>         
> reported
>   
>>>> neighbor "R1.25" in their LSP, and R1 also generates a pseudonode
>>>>         
> for
>   
>>>> phrase "treat the link like a bunch of pt-to-pt links" which
>>>>         
>> undoubtedly
>>     
>>> We already handle the N=2 case by configuration, and that DOES turn
>>>       
> the
>   
>>> link into a genuine pt-pt link using pt-pt update process. This
>>>       
> seems
>   
>>> whether or not they have 2 or more routers on a LAN, and if they
>>>       
> think
>   
>>> there are 2 and a third turns up that is clearly an error, and
>>>       
> should be
>   
>>> treated as such. See
>>>
>>> If the motivation for removing the pseudonode is purely space saving
>>>       
> in
>   
>>> the LSP database, then it seems to me that this only applies for
>>>       
> very
>   
>>> small N. I think you win with N=3, and lose with N=4, and it gets
>>>       
> worse
>   
>>> I may have made a few errors there, but I think the principle is
>>>       
> clear.
>   
>>> It only seems worthwhile for the n=3 case. And even that is
>>>       
> marginal.
>   
>>> Of course there is the additional complexity of generating the PN,
>>>       
> but
>   
>>> we have to do all the DR election stuff for the update process
>>>       
> anyway,
>   
>>> so I don't see that as much complexity compared with the complexity
>>>       
> of
>   
>>> issue either way. However for a 15 node LAN, WITH pseudonode you
>>>       
> explore
>   
>>> 1 hop to the PN then 14 hops to the other nodes, then check on back
>>>       
> link
>   
>>> explore 14 hops, then another 14 hops back from each of those 14
>>>       
> (i.e.
>   
>>> 210 links). It would need a better analysis to determine exactly
>>>       
> what
>   
>>> the relative merits are, but at best I would say it is a wash, and
>>>       
> it
>   
>>>>>    I'm confused. I thought that what you were proposing was
>>>>>           
> switching
>   
>>>>> all the mechanisms from "LAN" to "Pt-Pt". i.e. not only removing
>>>>>           
> the
>   
>>>>> pseudonode, but also using pt-pt mechanisms for the update
>>>>>           
> process,
>   
>>>>> This is exactly what we do at the moment when we configure a LAN
>>>>>           
> as a
>   
>>>>> 2 node pt-pt "LAN".
>>>>>
>>>>> But, this post makes me think that you mean ONLY getting rid of
>>>>>           
> the
>   
>>>>> process. Otherwise, if you reduce a 15 node LAN to a full mesh
>>>>>           
> pt-pt
>   
>>>>> you are going to get in excess of 200 LSPs crossing the LAN (not
>>>>>           
> to
>   
>>>>> mention ACKs).
>>>>>
>>>>>
>>>>> less nervous, But I'm still not really convinced it is worth the
>>>>>           
>> bother.
>>     
>>>>>> The WG seemed to think that the pseudonode minimization was a
>>>>>>             
> good
>   
>>>>>> should be proposed in the routing working group rather than in
>>>>>>             
> TRILL.
>   
>>>>>> I'm not convinced it is possible to put in the extra flags
>>>>>>             
> necessary
>   
>>>>>> for OSPF, so perhaps it should just be presented in IS-IS
>>>>>>             
> instead.
>   
>>>>>> the air, was 1 or 2 routers, no pseudonode, 5 or more,
>>>>>>             
> pseudonode,
>   
>>>>>> even if there were only 2 routers on a LAN, it made sense to
>>>>>>             
> create
>   
>>>>>> Things like the set of supported VLANs, and the set of roots that
>>>>>>             
> an
>   
>>>>>> So, I'm thinking that the right cutover would be something like
>>>>>>             
> 15
>   
>>>>>> LSP that has a whole header, and appears in every other RBridge's
>>>>>>             
>> CSNP.
>>     

Date: Thu, 31 Jan 2008 20:31:01 -0800
From: Radia Perlman <[email-masked]>
To: "Les Ginsberg (ginsberg)" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 20974

Les, I'll address each of your concerns in the points below, and below 
that I have some questions for Mike and Les about IS-IS.

1) "What happens with mix of routers that support this feature or not?"

No problem at all. Whether this is being done or
not on link L is completely irrelevant to routers that are not attached
to L. Having a mix of routers on L is also not a problem. That's what
the extra bit in the Hello is -- saying you support this feature. If any 
router on L does not support the feature,
it works like it does today -- with a pseudonode, even if there are just 
2 routers, unless someone has configured all the routers
on L to consider L
to be pt-to-pt.

2) "How bad a hit are transitions?":

I think most "Ethernet" links, once we get rid of bridges, will only be 
pt-to-pt, so in that case there will be no
transitions to/from pseudonode. There would be no pseudonodes.

The only time there would be transitions is if we actually have a shared 
cloud with 3 or more routers.

I don't think this is a problem. It *is* a little worse when a (non-DR) 
router goes up or down when you have n (with n>2) routers
on a link when you don't use a pseudonode. With a pseudonode, when a 
non-DR goes up or down, there are just 2
new LSPs (if someone is coming up). Without a pseudonode, all the 
routers have to reissue their LSP to include the
new neighbor (or get rid of the dead one). But the proposal is to have a 
pseudonode if there are "a lot" of routers. We just
need to decide what "a lot" is.

Obviously I'm not against pseudonodes (just "silly pseudonodes" -- where 
there are only 2 or 1 routers on a link).

Suppose we got rid of the hysteresis and made it be "use pseudonode if 
there are at least 3 routers, otherwise, don't".
Some people get concerned about the hit of transitioning between 
pseudonode and not. But I think the only difference
at that threshold (2 routers vs 3) is that with a pseudonode, if it's a 
non-DR that joins or leaves, it's 2 LSPs that
gets issued, and without, it's 3 LSPs that get issued (the new guy, and 
the existing 2 have to each reissue their LSP to
include the new guy. I don't think that can be considered a big deal. 
With the hysteresis, transitions would happen even less frequently
(the first time you get to the high water mark, and then the first time 
you hit the low water mark.

3) "CSNP cost is a red herring since they take up no memory":

Counting the exact bytes in memory is a good back of the envelope 
estimate, but the exact numbers are not that important
(a few percent one way or the other are not that important -- both 
schemes work just fine in some ranges). Nor is it
possible to get an exact answer since there are other factors such as 
bandwidth.  That's all I was saying.

There *are* issues other than just counting the LSP database size in 
terms of the bytes in the LSPs.
CSNPs and acks take up bandwidth on each link, proportional to the 
number of LSPs (and each pseudonode
adds an extra LSP). On pt-to-pt links, keeping track
of the ack-status for each neighbor for each LSP presumably takes up 
memory, so each pseudonode takes up
memory in each pt-to-pt port on routers anywhere in the area And there 
is probably various implementation-specific
housekeeping like pointers to LSPs, that would take up memory per LSP.

Mike's arithmetic does show it's not stupid to use pseudonodes with 
relatively small numbers of routers on the link (like 3).
His arithmetic eased my anxiety attack over having introduced 
pseudonodes in the first place (for DECnet Phase V routing), since
I was thinking that although it made sense for CLNP and large shared 
CSMA/CD links,
in this new world where if we get rid of bridges, "Ethernets" are 
basically all links are pt-to-pt links,
that pseudonodes would wind up being a bad idea. In my anxiety attack, I 
was thinking that pseudonodes would only
be cheaper if there were like 20 routers on a link, since in TRILL 
(unlike CLNP where you have to list all the endnodes)
there's nothing in the pseudonode LSP except listing the routers on that 
link. But as I said, Mike's arithmetic reassured me
that it's fine to use pseudonodes, except it would be good to avoid them 
without any configuration, in the cases of
1 or 2 routers on the link.

4) limited circumstances when this is useful: Suppose a router 
mindlessly assumed there was a pseudonode for every port? I'd hope
it's smart enough not to create a pseudonode when there isn't even a 
single router neighbor? Not sure what IS-IS implementations
do with this. I could imagine that a router with a bunch of ports, each 
of which are "Ethernets", and for which hundreds of them
just have a single endnode on the other end, the router might elect 
itself DR, and create and advertise a pseudonode for each of those ports.
That would clearly be silly, and fairly easily avoided with the rule 
"don't advertise a pseudonode unless there is at least 2 routers
listed in the pseudonode (you and one other). So I think we need to 
ensure that this doesn't happen (don't advertise pseudonodes
when there is just a single router). And maybe it already does (can 
anyone verify this?)

The other case is when there are 2 routers. This might be basically 
*all* the router-router links, assuming a campus where all the bridges have
been upgraded into RBridges. In that case there would be 33% more LSPs, 
and an LSP approximately twice as big. It could be
even bigger than that if there are multiple pt-to-pt Ethernets 
connecting the same two routers. With pseudonodes, each port would be
a pseudonode, whereas it would be relatively easy for R1 to realize it 
shouldn't list R2 as a neighbor multiple times.

****************
So, actually, I have a few questions:

a) without configuration, would an IS-IS router today create a 
pseudonode if it is the only router on an Ethernet link?
For instance, suppose R1 and R2
are neighbors on an Ethernet, and R2 goes down. Will R1 will issue two 
LSPs, one saying the pseudonode is R1.25 with neighbor R1,
and another saying R1 has neighbor R1.25? Or when R2 goes down, does R1 
get rid of the pseudonode?

b) suppose R1 and R2 are both on the same Ethernet, and one is 
configured that that port is pt-to-pt and the other is not configured
that way. What happens?

c) suppose R1, R2, and R3 are all on the same Ethernet, and all are 
configured that that port is pt-to-pt. What happens?

Radia

Les Ginsberg (ginsberg) wrote:
>> From: [email-masked] [mailto:[email-masked]]
>>     
> On
>   
>> Behalf Of Radia Perlman
>>>> able to switch back and forth, and more confusing to switch modes.
>>>>         
> And
>   
>>>> So yes...I'm only proposing that a "non-pseudonode LAN" get
>>>>         
> reported
>   
>>>> neighbor "R1.25" in their LSP, and R1 also generates a pseudonode
>>>>         
> for
>   
>>>> phrase "treat the link like a bunch of pt-to-pt links" which
>>>>         
>> undoubtedly
>>     
>>> We already handle the N=2 case by configuration, and that DOES turn
>>>       
> the
>   
>>> link into a genuine pt-pt link using pt-pt update process. This
>>>       
> seems
>   
>>> whether or not they have 2 or more routers on a LAN, and if they
>>>       
> think
>   
>>> there are 2 and a third turns up that is clearly an error, and
>>>       
> should be
>   
>>> treated as such. See
>>>
>>> If the motivation for removing the pseudonode is purely space saving
>>>       
> in
>   
>>> the LSP database, then it seems to me that this only applies for
>>>       
> very
>   
>>> small N. I think you win with N=3, and lose with N=4, and it gets
>>>       
> worse
>   
>>> I may have made a few errors there, but I think the principle is
>>>       
> clear.
>   
>>> It only seems worthwhile for the n=3 case. And even that is
>>>       
> marginal.
>   
>>> Of course there is the additional complexity of generating the PN,
>>>       
> but
>   
>>> we have to do all the DR election stuff for the update process
>>>       
> anyway,
>   
>>> so I don't see that as much complexity compared with the complexity
>>>       
> of
>   
>>> issue either way. However for a 15 node LAN, WITH pseudonode you
>>>       
> explore
>   
>>> 1 hop to the PN then 14 hops to the other nodes, then check on back
>>>       
> link
>   
>>> explore 14 hops, then another 14 hops back from each of those 14
>>>       
> (i.e.
>   
>>> 210 links). It would need a better analysis to determine exactly
>>>       
> what
>   
>>> the relative merits are, but at best I would say it is a wash, and
>>>       
> it
>   
>>>>>    I'm confused. I thought that what you were proposing was
>>>>>           
> switching
>   
>>>>> all the mechanisms from "LAN" to "Pt-Pt". i.e. not only removing
>>>>>           
> the
>   
>>>>> pseudonode, but also using pt-pt mechanisms for the update
>>>>>           
> process,
>   
>>>>> This is exactly what we do at the moment when we configure a LAN
>>>>>           
> as a
>   
>>>>> 2 node pt-pt "LAN".
>>>>>
>>>>> But, this post makes me think that you mean ONLY getting rid of
>>>>>           
> the
>   
>>>>> process. Otherwise, if you reduce a 15 node LAN to a full mesh
>>>>>           
> pt-pt
>   
>>>>> you are going to get in excess of 200 LSPs crossing the LAN (not
>>>>>           
> to
>   
>>>>> mention ACKs).
>>>>>
>>>>>
>>>>> less nervous, But I'm still not really convinced it is worth the
>>>>>           
>> bother.
>>     
>>>>>> The WG seemed to think that the pseudonode minimization was a
>>>>>>             
> good
>   
>>>>>> should be proposed in the routing working group rather than in
>>>>>>             
> TRILL.
>   
>>>>>> I'm not convinced it is possible to put in the extra flags
>>>>>>             
> necessary
>   
>>>>>> for OSPF, so perhaps it should just be presented in IS-IS
>>>>>>             
> instead.
>   
>>>>>> the air, was 1 or 2 routers, no pseudonode, 5 or more,
>>>>>>             
> pseudonode,
>   
>>>>>> even if there were only 2 routers on a LAN, it made sense to
>>>>>>             
> create
>   
>>>>>> Things like the set of supported VLANs, and the set of roots that
>>>>>>             
> an
>   
>>>>>> So, I'm thinking that the right cutover would be something like
>>>>>>             
> 15
>   
>>>>>> LSP that has a whole header, and appears in every other RBridge's
>>>>>>             
>> CSNP.
>>     

Content-class: urn:content-classes:message
Date: Thu, 31 Jan 2008 17:01:57 -0800
From: "Les Ginsberg (ginsberg)" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Mike Shand (mshand)" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 13340

Radia -

As for your statement:

   Les

routers
they
is
octets
lose
36
CSNP).
are
> >>>> get the exact number of bytes in an LSP. :-(

Date: Thu, 31 Jan 2008 13:14:37 -0800
From: Radia Perlman <[email-masked]>
To: mike shand <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 11177

This proposal eliminates

you just look at bytes in the LSP database, the cutover is at 4 routers 

be nice to get a clarification on that -- I could imagine that when they 

So, with 4 routers, I seem to get the same result as you said, which is 
it costs 21 octets in the LSP database to not use a pseudonode:

Assuming 4 routers:
Without pseudonode: each router reports 3 neighbors, so that costs 36 
octets each.
With pseudonode, each router reports 1 neighbor, so that saves 24 octets 
in 4 LSPs, at a total savings of 96 octets, but then
you have to add in the pseudonode LSP which has a header of 27, plus 4 
neighbors, so 27+4*12=75 octets. So I get that with
4 routers the octets in the LSP database alone, as you observe, you lose 
without a pseudonode by 21 octets.
Though as I said, the extra LSP also means an extra field in all the CSNPs.

With 5 routers, I get:

Without pseudonode, each router reports 4 neighbors, so that costs 48 
octets each, at a total cost of 5*48=240.
With pseudonode, each router reports 1 neighbor instead of 4, saving 36 
octets in each of 5, at a savings of 180.
The cost of the pseudonode is 27+5*12=87, so not having a pseudonode 
costs 180-87, or 93 octets. (though again, this is
somewhat mitigated by getting rid of the extra LSP to report in the CSNP).

for a link to have exactly 5 routers, and even though in theory you are 

Radia

>>>> get the exact number of bytes in an LSP. :-(

Date: Thu, 31 Jan 2008 12:48:18 -0800
From: Dinesh G Dutt <[email-masked]>
To: mike shand <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 7592

I agree with Mike. We already have an existing IS-IS way, using config, 
to support this and I prefer to not make the protocol more complex,

Dinesh

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

Content-class: urn:content-classes:message
Date: Thu, 31 Jan 2008 11:00:55 -0000
From: "Thomas, Matthew R" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: [rbridge] FW:  Pseudonode minimization thoughts...
Status: RO
Content-Length: 8251

Hi Mike

 

 
my 2 cents..
 
Matthew R Thomas

Radia,

So for N=3 we have

with PN 6*12 +29 = 101
without PN 3*2*12 = 72

For n=4

with 8*12+29 =125
without 4*3*12 = 144

for n=15

with 30*12+29 = 389
without 15*14*12 = 2520

    Mike

Date: Thu, 31 Jan 2008 10:19:39 +0000
From: mike shand <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 6858

Radia,

So for N=3 we have

with PN 6*12 +29 = 101
without PN 3*2*12 = 72

For n=4

with 8*12+29 =125
without 4*3*12 = 144

for n=15

with 30*12+29 = 389
without 15*14*12 = 2520

    Mike

>>> get the exact number of bytes in an LSP. :-(

Date: Wed, 30 Jan 2008 11:59:27 -0800
From: Radia Perlman <[email-masked]>
To: mike shand <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 4204

Radia

>> the exact number of bytes in an LSP. :-(

Content-class: urn:content-classes:message
Date: Wed, 30 Jan 2008 12:22:03 -0600
From: "Eric Gray" <[email-masked]>
To: "mike shand" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 4233

Mike,

--
Eric Gray
Principal Engineer
Ericsson  

> process. 

Date: Wed, 30 Jan 2008 09:19:13 +0000
From: mike shand <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 2711

Radia,

    Mike

> the exact number of bytes in an LSP. :-(

Content-class: urn:content-classes:message
Date: Tue, 29 Jan 2008 19:26:42 -0000
From: "Thomas, Matthew R" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 2187

Yes,

Matthew R Thomas

-----Original Message-----

Radia

Date: Mon, 28 Jan 2008 21:05:13 -0800
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 1482

Radia

Content-class: urn:content-classes:message
Date: Sun, 13 Jan 2008 23:01:29 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] IEEE 802.1 Review
Status: RO
Content-Length: 710

At the Vancouver meeting, the TRILL co-chairs took an action item to
check with our Area Director and determine whether the slide
presentation of the TRILL architecture to IEEE 802.1, which Eric Gray
did a while ago, and his report back to TRILL, meets our Charter
requirement for such review.

The TRILL Charter currently says "... IEEE 802.1 will be asked to review
the architecture document ...". The conclusion of the Chairs and AD is
that the 802.1 review needs to be of a version of the architecture
document to meet this Charter requirement. So, unless the Charter is
modified, at some point in the future we would need to request such a
review of a specific architecture draft.

Thanks,
Donald & Erik

Content-class: urn:content-classes:message
Date: Sun, 13 Jan 2008 22:56:31 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Updated Vancouver minutes
Status: RO
Content-Length: 380

Hi,

A slightly expanded and hopefully more clear set of minutes for the
TRILL meeting at IETF-70 in Vancouver have been uploaded to the meeting
materials page.

Thanks,
Donald
====================================================
 Donald E. Eastlake 3rd      +1-508-786-7554 (work)
 Motorola Laboratories
 111 Locke Drive
 Marlborough, MA 01752 USA
 [email-masked]

Content-class: urn:content-classes:message
Date: Thu, 10 Jan 2008 10:05:12 -0600
From: "Eric Gray" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Dinesh G Dutt" <[email-masked]>, "James Carlson" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable endstation traffic
Status: RO
Content-Length: 7810

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
> Cc: [email-masked]; Joe Touch
> Subject: Re: [rbridge] Consensus Check: Configure ports to 
> disable endstation traffic
> 
> 
> Well, this can be seen as more than an optimization.
> It could be seen as a security feature.

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.

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

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.

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

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.

> 
> 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
> > Cc: [email-masked]; Joe Touch
> > Subject: Re: [rbridge] Consensus Check: Configure portsto 
> > disable end stationtraffic
> > 
> > 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:
> > >   
> > >> 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.
> > >>     
> > >
> > > 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.)
> > >
> > >   
> > 
> > --
> > We make our world significant by the courage of our 
> questions and by 
> > the depth of our answers.                               - Carl Sagan
> > 

Content-class: urn:content-classes:message
Date: Wed, 9 Jan 2008 23:46:05 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Check: Milestone Move
Status: RO
Content-Length: 383

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 milestones to March 2008 for Problem
      Statement and Architecture document.

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

Content-class: urn:content-classes:message
Date: Wed, 9 Jan 2008 23:27:27 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Check: Against P2P Fixed Addresses Proposal
Status: RO
Content-Length: 633

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:

		Against the proposal presented at IETF-70
      for p2p link configuration permitting a fixed source and
      destination address.

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

====================================================
 Donald E. Eastlake 3rd      +1-508-786-7554 (work)
 Motorola Laboratories
 111 Locke Drive
 Marlborough, MA 01752 USA
 [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 9 Jan 2008 23:26:24 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end station traffic
Status: RO
Content-Length: 3664

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

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:

           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.

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

Content-class: urn:content-classes:message
Date: Wed, 9 Jan 2008 17:19:43 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>, "James Carlson" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end station traffic
Status: RO
Content-Length: 3748

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
> Cc: [email-masked]; Joe Touch
> Subject: Re: [rbridge] Consensus Check: Configure portsto 
> disable end stationtraffic
> 
> 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:
> >   
> >> 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.
> >>     
> >
> > 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.)
> >
> >   
> 
> --
> We make our world significant by the courage of our questions and by 
> the depth of our answers.                               - Carl Sagan
> 

Content-class: urn:content-classes:message
Date: Wed, 9 Jan 2008 16:59:32 -0600
From: "Eric Gray" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "James Carlson" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end station traffic
Status: RO
Content-Length: 2989

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 [mailto:[email-masked]] 
> Sent: Wednesday, January 09, 2008 1:56 PM
> To: James Carlson
> Cc: Dinesh G Dutt; Eric Gray; [email-masked]; Joe Touch
> Subject: RE: [rbridge] Consensus Check: Configure ports to 
> disable end station traffic
> 
>  
> 
> > From: James Carlson [mailto:[email-masked]] 
> > 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 
> > disable end station traffic
> > 
> > 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
> 

Content-class: urn:content-classes:message
Date: Wed, 9 Jan 2008 16:46:43 -0600
From: "Eric Gray" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "James Carlson" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end station traffic
Status: RO
Content-Length: 1855

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  

> From: Anoop Ghanwani [mailto:[email-masked]] 
> Sent: Wednesday, January 09, 2008 1:56 PM
> To: James Carlson
> Cc: Dinesh G Dutt; Eric Gray; [email-masked]; Joe Touch
> Subject: RE: [rbridge] Consensus Check: Configure ports to 
> disable end station traffic
> 
>  
> 
> > From: James Carlson [mailto:[email-masked]] 
> > 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 
> > disable end station traffic
> > 
> > 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
> 

Date: Wed, 9 Jan 2008 17:16:29 -0500
From: James Carlson <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Configure ports to disable	end	stationtraffic
Status: RO
Content-Length: 1724

Joe Touch writes:
> James Carlson wrote:
> > 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? 
> 
> No reason. This is fine in that case. The doc should be clear about the 
> 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.

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

Date: Wed, 9 Jan 2008 15:32:15 -0500
From: James Carlson <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports todisableendstationtraffic
Status: RO
Content-Length: 529

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.

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

Content-class: urn:content-classes:message
Date: Wed, 9 Jan 2008 14:52:35 -0600
From: "Eric Gray" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>, "James Carlson" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable endstation traffic
Status: RO
Content-Length: 2006

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
> Cc: [email-masked]; Joe Touch
> Subject: RE: [rbridge] Consensus Check: Configure ports to 
> disable endstation traffic
> Importance: High
> 
> 
> 
> > Behalf Of Eric Gray
> > Sent: Wednesday, January 09, 2008 5:39 AM
> > To: Anoop Ghanwani; James Carlson
> > Cc: [email-masked]; Joe Touch
> > Subject: Re: [rbridge] Consensus Check: Configure ports to disable
> > endstation traffic
> > 
> > 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.
> > 
> 
> 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?
> 
> 
> 

Content-class: urn:content-classes:message
Date: Wed, 9 Jan 2008 14:27:59 -0600
From: "Eric Gray" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports todisableendstationtraffic
Status: RO
Content-Length: 5184

James,

	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.

--
Eric Gray
Principal Engineer
Ericsson  

> From: James Carlson [mailto:[email-masked]] 
> Sent: Wednesday, January 09, 2008 3:04 PM
> To: Eric Gray
> Cc: Joe Touch; [email-masked]
> Subject: RE: [rbridge] Consensus Check: Configure ports 
> todisableendstationtraffic
> Importance: High
> 
> Eric Gray writes:
> > > From: James Carlson [mailto:[email-masked]] 
> [...]
> > > 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.
> > 
> > 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.
> 
> 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.
> 
> > 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.
> 
> Some DHCP servers generate broadcast responses and others generate
> unicast only.  It depends.  :-<
> 
> >  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.
> 
> 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.
> 
> > >   - 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.
> > 
> > Again, this is difficult to imagine unless the "marooned node"
> > 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.
> 
> > >   - Non-IP broadcast messages won't be sent to this link.  Any
> > >     protocols built on broadcast will fail.
> > 
> > Yes - at least to the extent that the "marooned node" counts on
> > receiving broadcast messages.  And?
> 
> ... and it's broken.
> 
> > 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?
> 
> "Very."
> 
> What do VLANs have to do with anything at all?  Broadcast works fine
> on VLANs.
> 
> > > 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."
> > 
> > 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.
> 
> I'm snooping broadcast right now, and I see a bunch of traffic.
> 
> I really don't understand what you're saying.
> 
> -- 
> 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
> 

Date: Wed, 9 Jan 2008 15:04:29 -0500
From: James Carlson <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports todisableendstationtraffic
Status: RO
Content-Length: 4366

Eric Gray writes:
> > From: James Carlson [mailto:[email-masked]] 
[...]
> > 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.
> 
> 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.

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.

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

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

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

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.

> >   - 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.
> 
> Again, this is difficult to imagine unless the "marooned node"
> 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.

> >   - Non-IP broadcast messages won't be sent to this link.  Any
> >     protocols built on broadcast will fail.
> 
> Yes - at least to the extent that the "marooned node" counts on
> receiving broadcast messages.  And?

... and it's broken.

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

"Very."

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

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

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

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

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

Content-class: urn:content-classes:message
Date: Wed, 9 Jan 2008 15:33:34 -0500
From: "Caitlin Bestler" <[email-masked]>
To: "Eric Gray" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>, "James Carlson" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable endstation traffic
Status: RO
Content-Length: 754

> Behalf Of Eric Gray
> Sent: Wednesday, January 09, 2008 5:39 AM
> To: Anoop Ghanwani; James Carlson
> Cc: [email-masked]; Joe Touch
> Subject: Re: [rbridge] Consensus Check: Configure ports to disable
> endstation traffic
> 
> 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.
> 

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?

Content-class: urn:content-classes:message
Date: Wed, 9 Jan 2008 13:53:46 -0600
From: "Eric Gray" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Configure ports todisable	endstationtraffic
Status: RO
Content-Length: 1504

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  

> From: Joe Touch [mailto:[email-masked]] 
> Sent: Tuesday, January 08, 2008 7:12 PM
> To: Eric Gray
> Cc: James Carlson; [email-masked]
> Subject: Re: [rbridge] Consensus Check: Configure ports 
> todisable endstationtraffic
> Importance: High
> 
> * PGP Signed: 01/09/2008 at 01:11:41 AM
> 
> 
> Eric Gray wrote:
> > 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.
> 
> 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
> 
> * Joe Touch <[email-masked]>
> * 0x89A766BB
> 
> 

Content-class: urn:content-classes:message
Date: Wed, 9 Jan 2008 13:47:37 -0600
From: "Eric Gray" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports todisableendstationtraffic
Status: RO
Content-Length: 5539

James,

	Please see below...

--
Eric Gray
Principal Engineer
Ericsson  

> From: James Carlson [mailto:[email-masked]] 
> Sent: Wednesday, January 09, 2008 11:18 AM
> To: Eric Gray
> Cc: Joe Touch; [email-masked]
> Subject: RE: [rbridge] Consensus Check: Configure ports 
> todisableendstationtraffic
> Importance: High
> 
> Eric Gray writes:
> > 	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.
> 
> 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.
> 
> > 	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.
> 
> I don't see how that's true.  The original message in this thread
> (lost in context due to odd quoting practices) said this:
> 
>            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.
> 
> 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.

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.

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

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

> 
>   - Non-IP broadcast messages won't be sent to this link.  Any
>     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?

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

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.

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

Date: Wed, 9 Jan 2008 13:41:45 -0500
From: James Carlson <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end station traffic
Status: RO
Content-Length: 835

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.

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

Content-class: urn:content-classes:message
Date: Wed, 9 Jan 2008 10:56:18 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end station traffic
Status: RO
Content-Length: 1221

> From: James Carlson [mailto:[email-masked]] 
> 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 
> disable end station traffic
> 
> 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

Content-class: urn:content-classes:message
Date: Wed, 9 Jan 2008 10:30:06 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>, "Eric Gray" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end station traffic
Status: RO
Content-Length: 3650

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
> Subject: Re: [rbridge] Consensus Check: Configure ports to 
> disable end station traffic
> 
> I concur with Eric,
> 
> Dinesh
> Eric Gray wrote:
> > 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
> >> Cc: [email-masked]; Joe Touch
> >> Subject: RE: [rbridge] Consensus Check: Configure 
> portstodisable end 
> >> stationtraffic
> >> Importance: High
> >>
> >>  
> >>
> >>     
> >>> [mailto:[email-masked]] On Behalf Of James Carlson
> >>> 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
> >>
> >>     
> >
> We make our world significant by the courage of our questions and by 
> the depth of our answers.                               - Carl Sagan
> 
> 

Content-class: urn:content-classes:message
Date: Wed, 9 Jan 2008 13:20:38 -0500
From: "Caitlin Bestler" <[email-masked]>
To: "Eric Gray" <[email-masked]>, "James Carlson" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure portstodisable	endstationtraffic
Status: RO
Content-Length: 2470

Eric Gray wrote:

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

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.

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

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

Date: Wed, 9 Jan 2008 11:18:09 -0500
From: James Carlson <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports todisable	endstationtraffic
Status: RO
Content-Length: 2185

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

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.

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

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

           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.

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

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

Date: Wed, 09 Jan 2008 08:07:03 -0800
From: Dinesh G Dutt <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Allow GVRP/MVRP
Status: RO
Content-Length: 753

I concur,

Dinesh
Eastlake III Donald-LDE008 wrote:
> 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:
>
>       Remove any text prohibiting implementation
>       of GVRP or MVRP on RBridges.
>
> 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
>

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

Date: Wed, 09 Jan 2008 08:06:34 -0800
From: Dinesh G Dutt <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end	station traffic
Status: RO
Content-Length: 2634

I concur with Eric,

Dinesh
Eric Gray wrote:
> 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
>> Cc: [email-masked]; Joe Touch
>> Subject: RE: [rbridge] Consensus Check: Configure 
>> portstodisable end stationtraffic
>> Importance: High
>>
>>  
>>
>>     
>>> [mailto:[email-masked]] On Behalf Of James Carlson
>>> 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
>>
>>     
>

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

Date: Wed, 09 Jan 2008 08:04:39 -0800
From: Dinesh G Dutt <[email-masked]>
To: James Carlson <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports to	disable	end	stationtraffic
Status: RO
Content-Length: 2074

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

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

Content-class: urn:content-classes:message
Date: Wed, 9 Jan 2008 07:39:19 -0600
From: "Eric Gray" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "James Carlson" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end station traffic
Status: RO
Content-Length: 2190

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
> Cc: [email-masked]; Joe Touch
> Subject: RE: [rbridge] Consensus Check: Configure 
> portstodisable end stationtraffic
> Importance: High
> 
>  
> 
> > [mailto:[email-masked]] On Behalf Of James Carlson
> > 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
> 

Content-class: urn:content-classes:message
Date: Tue, 8 Jan 2008 18:18:11 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "James Carlson" <[email-masked]>, "Eric Gray" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure portstodisable	end	stationtraffic
Status: RO
Content-Length: 1035

> [mailto:[email-masked]] On Behalf Of James Carlson
> 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

Date: Tue, 08 Jan 2008 16:11:40 -0800
From: Joe Touch <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Configure ports todisable	endstationtraffic
Status: RO
Content-Length: 1556

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4595508A4DA10237401BD43C
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Eric Gray wrote:
> James,
>=20
> 	Perhaps not quite orthogonal, but definitely not=20
> 100 % correlated.
>=20
> 	I disagree that you would necessarily break the=20
> 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=20
> Joe was talking about "silent end stations" which is
> pretty far from the "normal case" these days.

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

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

Joe

--------------enig4595508A4DA10237401BD43C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig4595508A4DA10237401BD43C--

Content-class: urn:content-classes:message
Date: Tue, 8 Jan 2008 17:51:37 -0600
From: "Eric Gray" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports todisable	endstationtraffic
Status: RO
Content-Length: 3883

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:
> > 	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."
> [...]
> > 	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.
> 
> 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.
> 
> -- 
> 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
> 

Content-class: urn:content-classes:message
Date: Tue, 8 Jan 2008 14:16:53 -0600
From: "Eric Gray" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end stationtraffic
Status: RO
Content-Length: 3674

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  

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

Date: Tue, 8 Jan 2008 14:51:15 -0500
From: James Carlson <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports todisable	end	stationtraffic
Status: RO
Content-Length: 2020

Eric Gray writes:
> 	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."
[...]
> 	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.

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.

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

Content-class: urn:content-classes:message
Date: Tue, 8 Jan 2008 13:15:51 -0600
From: "Eric Gray" <[email-masked]>
To: "James Carlson" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Configure ports todisable	end	stationtraffic
Status: RO
Content-Length: 3920

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

Date: Mon, 07 Jan 2008 13:31:56 -0800
From: Joe Touch <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Configure ports to disable	end	stationtraffic
Status: RO
Content-Length: 2245

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5FBBDCCD2ED91F696B3807E9
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

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

Joe

Joe Touch wrote:
>=20
>=20
> James Carlson wrote:
>> Joe Touch writes:
>>> I'm concerned about the case where an end station moves and doesn't=20
>>> announce itself. There's no requirement in ethernet to do so, and=20
>>> 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=20
>>> cases. I disagree with it.
>>
>> 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?=20
>=20
> No reason. This is fine in that case. The doc should be clear about the=
=20
> potential for silent misconfiguration in those cases.
>=20
> (note - this is a silent misconfiguration issue; it'd be much easier if=
=20
> we could know that such a misconfiguration would be detectable)
>=20
> Joe
>=20
>=20

--------------enig5FBBDCCD2ED91F696B3807E9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig5FBBDCCD2ED91F696B3807E9--

Content-class: urn:content-classes:message
Date: Mon, 7 Jan 2008 13:15:59 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end stationtraffic
Status: RO
Content-Length: 3294

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]] 
> Sent: Monday, January 07, 2008 11:32 AM
> To: Anoop Ghanwani
> Cc: Eastlake III Donald-LDE008; [email-masked]
> Subject: Re: [rbridge] Consensus Check: Configure ports to 
> disable end stationtraffic
> 
> 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
> 
> Anoop Ghanwani wrote:
> > 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
> > 
> >> [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:
> >>
> >>            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.
> >>
> >> 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
> >>

Date: Mon, 07 Jan 2008 13:08:34 -0800
From: Joe Touch <[email-masked]>
To: James Carlson <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Configure ports to disable	end	stationtraffic
Status: RO
Content-Length: 1978

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig018F75FDE7138156AE91D536
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

James Carlson wrote:
> Joe Touch writes:
>> I'm concerned about the case where an end station moves and doesn't=20
>> announce itself. There's no requirement in ethernet to do so, and such=
 a=20
>> station would never be discovered if we don't flood broadcast to all l=
inks.
>>
>> I.e., the optimization below is a recipe for ARP failure in such cases=
=2E=20
>> I disagree with it.
>=20
> That "failure" is exactly the intent.
>=20
> 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.
>=20
> 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?=20

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

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

Joe

--------------enig018F75FDE7138156AE91D536
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig018F75FDE7138156AE91D536--

Date: Mon, 7 Jan 2008 15:39:27 -0500
From: James Carlson <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Configure ports to disable	end	stationtraffic
Status: RO
Content-Length: 1833

Joe Touch writes:
> 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.

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

Content-class: urn:content-classes:message
Date: Mon, 7 Jan 2008 15:43:49 -0500
From: "Caitlin Bestler" <[email-masked]>
To: "Joe Touch" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Configure ports to disableend	stationtraffic
Status: RO
Content-Length: 1264

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

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.

Date: Mon, 07 Jan 2008 11:32:24 -0800
From: Joe Touch <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end	stationtraffic
Status: RO
Content-Length: 2901

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5AC50F7F791749839490C2AC
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

I'm concerned about the case where an end station moves and doesn't=20
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 link=
s.

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

Joe

Anoop Ghanwani wrote:
> This certainly makes sense is what I tend to
> think of as a TRILL "core" port.   On such a=20
> port, we would never see non-TRILL encap'ed
> frames (other than the usual exceptions such
> as BPDUs and other link layer control traffic).
>=20
> I wonder if it makes sense to also have a=20
> configuration for a TRILL "edge" port -- one
> where we are configured to never send TRILL
> encap'ed traffic because we don't intend for=20
> it to be used as a transit link (even though
> connectivity may exist to another RBridge=20
> for redundancy purposes). =20
>=20
> Anoop=20
>=20
>> From: [email-masked]=20
>> [mailto:[email-masked]] On Behalf Of Eastlake III=20
>> Donald-LDE008
>> Sent: Monday, January 07, 2008 10:34 AM
>> To: [email-masked]
>> Subject: [rbridge] Consensus Check: Configure ports to=20
>> disable end stationtraffic
>>
>> This is a check via the mailing list to confirm or refute an=20
>> apparent consensus at the Vancouver meeting taken from the=20
>> minutes of that
>> meeting:
>>
>>            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.
>>
>> If no particular controversy arises over this in the next=20
>> three weeks, We will declare it to be the working group consensus.
>>
>> Thanks,
>> Donald & Erik
>>
>=20

--------------enig5AC50F7F791749839490C2AC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig5AC50F7F791749839490C2AC--

Content-class: urn:content-classes:message
Date: Mon, 7 Jan 2008 14:26:41 -0500
From: "Caitlin Bestler" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable endstationtraffic
Status: RO
Content-Length: 1160

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

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.

Content-class: urn:content-classes:message
Date: Mon, 7 Jan 2008 11:14:27 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end stationtraffic
Status: RO
Content-Length: 1597

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 

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

Content-class: urn:content-classes:message
Date: Mon, 7 Jan 2008 13:36:15 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Check: Allow GVRP/MVRP
Status: RO
Content-Length: 380

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:

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

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

Content-class: urn:content-classes:message
Date: Mon, 7 Jan 2008 13:34:19 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Check: Configure ports to disable end station traffic
Status: RO
Content-Length: 573

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:

           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.

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

Content-class: urn:content-classes:message
Date: Thu, 3 Jan 2008 14:13:32 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Check: Pseudonode suppression
Status: RO
Content-Length: 432

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

Content-class: urn:content-classes:message
Date: Wed, 2 Jan 2008 14:29:49 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Minutes for TRILL at IETF-70 posted
Status: RO
Content-Length: 430

Hi,

Tentative minutes from the Vancouver TRILL meeting in December 2007 have
been posted and are available on the Meeting Materials page for IETF-70
at http://www3.ietf.org/proceedings/07dec/minutes/trill.txt.

Thanks,
Donald
====================================================
 Donald E. Eastlake 3rd      +1-508-786-7554 (work)
 Motorola Laboratories
 111 Locke Drive
 Marlborough, MA 01752 USA
 [email-masked]