Re: [rbridge] Pseudonode minimization thoughts...

["Les Ginsberg (ginsberg)" <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Radia Perlman
> Sent: Thursday, January 31, 2008 1:15 PM
> To: Mike Shand (mshand)
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Pseudonode minimization thoughts...
> 
> 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:
> >
> >> 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,
> >     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
> >
> >
> >> Radia
> >>
> >>
> >> mike shand wrote:
> >>
> >>> 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
> >>>
> >>> Radia Perlman wrote:
> >>>
> >>>> 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
> >>>> [e-mail]
> >>>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>>
> >>>>
> >>>>
> >>
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge
From [e-mail]  Thu Jan 31 20:33:29 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 54B0928C138
	for <[e-mail]>; Thu, 31 Jan 2008 20:33:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id uxWMcFsWP+UJ
	for <[e-mail]>;
	Thu, 31 Jan 2008 20:33:27 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by core3.amsl.com (Postfix) with ESMTP id 01D0628C0D7
	for <[e-mail]>; Thu, 31 Jan 2008 20:33:26 -0800 (PST)
Received: from boreas.isi.edu (localhost [127.0.0.1])
	by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m114VoF4018837;
	Thu, 31 Jan 2008 20:31:50 -0800 (PST)
Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50])
	by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m114V9uO018578
	for <[e-mail]>; Thu, 31 Jan 2008 20:31:10 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com
	(Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25
	2004))
	with ESMTP id <[e-mail]> for
	[e-mail]; Thu, 31 Jan 2008 20:31:03 -0800 (PST)
Received: from [192.168.2.61] ([67.161.89.58])
	by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02
	(built
	Aug 25 2004)) with ESMTPSA id <[e-mail]> for
	[e-mail]; Thu, 31 Jan 2008 20:31:03 -0800 (PST)
Date: Thu, 31 Jan 2008 20:31:01 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Les Ginsberg (ginsberg)" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
References: <[e-mail]> <[e-mail]>
	<[e-mail]> <[e-mail]>
	<[e-mail]>
	<[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

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:
> 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
>
>   
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>>     
> On
>   
>> Behalf Of Radia Perlman
>> Sent: Thursday, January 31, 2008 1:15 PM
>> To: Mike Shand (mshand)
>> Cc: Developing a hybrid router/bridge.
>> Subject: Re: [rbridge] Pseudonode minimization thoughts...
>>
>> 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:
>>>
>>>       
>>>> 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,
>>>     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
>>>
>>>
>>>       
>>>> Radia
>>>>
>>>>
>>>> mike shand wrote:
>>>>
>>>>         
>>>>> 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
>>>>>
>>>>> Radia Perlman wrote:
>>>>>
>>>>>           
>>>>>> 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
>>>>>> [e-mail]
>>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>>       
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>     

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge

Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m114V9uO018578 for <[e-mail]>; Thu, 31 Jan 2008 20:31:10 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 31 Jan 2008 20:31:03 -0800 (PST)
Received: from [192.168.2.61] ([67.161.89.58]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 31 Jan 2008 20:31:03 -0800 (PST)
Date: Thu, 31 Jan 2008 20:31:01 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Les Ginsberg (ginsberg)" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 01 Feb 2008 04:31:48 -0000
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:
> 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
>
>   
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>>     
> On
>   
>> Behalf Of Radia Perlman
>> Sent: Thursday, January 31, 2008 1:15 PM
>> To: Mike Shand (mshand)
>> Cc: Developing a hybrid router/bridge.
>> Subject: Re: [rbridge] Pseudonode minimization thoughts...
>>
>> 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:
>>>
>>>       
>>>> 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,
>>>     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
>>>
>>>
>>>       
>>>> Radia
>>>>
>>>>
>>>> mike shand wrote:
>>>>
>>>>         
>>>>> 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
>>>>>
>>>>> Radia Perlman wrote:
>>>>>
>>>>>           
>>>>>> 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
>>>>>> [e-mail]
>>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>>       
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>     



Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m1111B0k016062 for <[e-mail]>; Thu, 31 Jan 2008 17:01:12 -0800 (PST)
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 31 Jan 2008 17:01:11 -0800
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1111Bhj023007;  Thu, 31 Jan 2008 17:01:11 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id m1110bcO025031; Fri, 1 Feb 2008 01:00:50 GMT
Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 31 Jan 2008 17:00:44 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 31 Jan 2008 17:01:57 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Pseudonode minimization thoughts...
Thread-Index: AchkUCbKXlJikOqVTme4h1bg+O2zjQAG9xMg
References: <[e-mail]> <[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Les Ginsberg (ginsberg)" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Mike Shand (mshand)" <[e-mail]>
X-OriginalArrivalTime: 01 Feb 2008 01:00:44.0924 (UTC) FILETIME=[DFD043C0:01C8646D]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13779; t=1201827671; x=1202691671; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22Les=20Ginsberg=20(ginsberg)=22=20<ginsberg@cisc o.com> |Subject:=20RE=3A=20[rbridge]=20Pseudonode=20minimization=2 0thoughts... |Sender:=20; bh=Zqo9/uvKRsh9KP8yVM24C1a+cEJswZQebyDtETV+KB4=; b=y1tKMotejVg4Sdh4R4cVsMzjDpdNBo5Xo4pxJ+ipttYfhby1eC0UQJjPho whgIHmzt42TU1qmWde9eNQ9WMtaAsre4wbgi7Vt1UIHf7ixd7w2Dw6KaEf/T 5zUNt3fiLW;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m1111B0k016062
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 01 Feb 2008 01:02:45 -0000
Status: RO
Content-Length: 13340

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Radia Perlman
> Sent: Thursday, January 31, 2008 1:15 PM
> To: Mike Shand (mshand)
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Pseudonode minimization thoughts...
> 
> 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:
> >
> >> 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,
> >     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
> >
> >
> >> Radia
> >>
> >>
> >> mike shand wrote:
> >>
> >>> 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
> >>>
> >>> Radia Perlman wrote:
> >>>
> >>>> 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
> >>>> [e-mail]
> >>>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>>
> >>>>
> >>>>
> >>
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0VLEuZx005332 for <[e-mail]>; Thu, 31 Jan 2008 13:14:57 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 31 Jan 2008 13:14:41 -0800 (PST)
Received: from [129.150.37.38] ([192.18.101.5]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 31 Jan 2008 13:14:41 -0800 (PST)
Date: Thu, 31 Jan 2008 13:14:37 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: mike shand <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 31 Jan 2008 21:16:20 -0000
Status: RO
Content-Length: 11177

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:
>   
>> 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,
>     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
>
>   
>> Radia
>>
>>
>> mike shand wrote:
>>     
>>> 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
>>>
>>> Radia Perlman wrote:
>>>       
>>>> 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
>>>> [e-mail]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>
>>>>   
>>>>         
>>     
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   



Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0VKmJ4Y027171 for <[e-mail]>; Thu, 31 Jan 2008 12:48:19 -0800 (PST)
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 31 Jan 2008 12:48:18 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0VKmHvk008499;  Thu, 31 Jan 2008 12:48:17 -0800
Received: from [171.71.58.95] (dhcp-171-71-58-95.cisco.com [171.71.58.95]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0VKmHZx012897; Thu, 31 Jan 2008 20:48:17 GMT
Message-ID: <[e-mail]>
Date: Thu, 31 Jan 2008 12:48:18 -0800
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20071031)
MIME-Version: 1.0
To: mike shand <[e-mail]>
References: <[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7782; t=1201812497; x=1202676497; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Pseudonode=20minimization=2 0thoughts... |Sender:=20; bh=EZXiZiufxFLFZPKGeCoj1+3h/McmMngSRHk5rSZRc4Q=; b=VYon906x9gTMfk2FUK+pJFzgf14t0Ysz+CBRGyW1XXKU3wpJwBy8HjfrmE DxjQ8LIjb8VKa9wylF1nJ34P9y5Q/Tl98EaWGAQTpRzc6L73gprRR1DR39T9 PoA5qHtsP9zNyHW9OWmSRECYXke2U0ChP86SPuw7VNKKLj6BjpEB4=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 31 Jan 2008 20:48:40 -0000
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
mike shand wrote:
> Radia Perlman wrote:
>   
>> 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,
>     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
>
>   
>> Radia
>>
>>
>> mike shand wrote:
>>     
>>> 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
>>>
>>> Radia Perlman wrote:
>>>       
>>>> 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
>>>> [e-mail]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>
>>>>   
>>>>         
>>     
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

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



Received: from sernt12.essex.ac.uk (sernt12.essex.ac.uk [155.245.42.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0VB0um2018509 for <[e-mail]>; Thu, 31 Jan 2008 03:00:58 -0800 (PST)
Received: from sernt14.essex.ac.uk ([155.245.42.34]) by sernt12.essex.ac.uk with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 31 Jan 2008 11:00:55 +0000
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Thu, 31 Jan 2008 11:00:55 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Pseudonode minimization thoughts...
Thread-Index: Achj9VxyPQQE+zueSVWkEe+L+Q0VlwAAIfdb
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Thomas, Matthew R" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 31 Jan 2008 11:00:55.0419 (UTC) FILETIME=[8D53FCB0:01C863F8]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m0VB0um2018509
Cc: [e-mail]
Subject: [rbridge] FW:  Pseudonode minimization thoughts...
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 31 Jan 2008 11:01:15 -0000
Status: RO
Content-Length: 8251

 
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: [e-mail] 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 Perlman wrote:
> 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,
    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

>
> Radia
>
>
> mike shand wrote:
>> 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
>>
>> Radia Perlman wrote:
>>> 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
>>> [e-mail]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>>  
>>
>
>

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge





Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0VAJgEV006021 for <[e-mail]>; Thu, 31 Jan 2008 02:19:43 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.25,284,1199660400";  d="scan'208";a="4476149"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Jan 2008 11:19:42 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0VAJfgP032345;  Thu, 31 Jan 2008 11:19:41 +0100
Received: from [10.61.66.229] (ams3-vpn-dhcp741.cisco.com [10.61.66.229]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0VAJdEp029546;  Thu, 31 Jan 2008 10:19:40 GMT
Message-ID: <[e-mail]>
Date: Thu, 31 Jan 2008 10:19:39 +0000
From: mike shand <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7029; t=1201774781; x=1202638781; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20mike=20shand=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Pseudonode=20minimization=2 0thoughts... |Sender:=20; bh=ynlO4o7NubQ+JKTnVI7oA3UKeRb5i9cQI/K7MwOrsmE=; b=wFM8+VXm7wpxc4NhgCSRZOPLyyk2o+cQlgNFAGAhzIqvhFtP3iJ948io9f s4rgV4urqXjNzNzxnluXHSaFo1rVFiSQyxqSEX6x3N3uAkAzlVspaPkUtOjM BG0eYCfMO0;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 31 Jan 2008 10:20:34 -0000
Status: RO
Content-Length: 6858

Radia Perlman wrote:
> 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,
    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

>
> Radia
>
>
> mike shand wrote:
>> 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
>>
>> Radia Perlman wrote:
>>> 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
>>> [e-mail]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>>   
>>
>
>



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0UJxiHw027172 for <[e-mail]>; Wed, 30 Jan 2008 11:59:45 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 30 Jan 2008 11:59:34 -0800 (PST)
Received: from [129.150.36.74] ([192.18.101.5]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Wed, 30 Jan 2008 11:59:34 -0800 (PST)
Date: Wed, 30 Jan 2008 11:59:27 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: mike shand <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 30 Jan 2008 20:01:12 -0000
Status: RO
Content-Length: 4204

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:
> 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
>
> Radia Perlman wrote:
>> 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
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>   
>



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0UIMUhk015700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 30 Jan 2008 10:22:31 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m0UIMTcj030120; Wed, 30 Jan 2008 12:22:29 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 30 Jan 2008 12:22:28 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Wed, 30 Jan 2008 12:22:03 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Pseudonode minimization thoughts...
Thread-Index: AchjL5v147wBPfGyTYmNiauYzLrK9wAOzylA
References: <[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "mike shand" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 30 Jan 2008 18:22:28.0900 (UTC) FILETIME=[12429E40:01C8636D]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m0UIMUhk015700
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 30 Jan 2008 18:23:37 -0000
Status: RO
Content-Length: 4233

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  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 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,
>     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
> 
> Radia Perlman wrote:
> > 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
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> >   
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0U9JGB3022230 for <[e-mail]>; Wed, 30 Jan 2008 01:19:17 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.25,276,1199660400";  d="scan'208";a="4352407"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Jan 2008 10:19:16 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0U9JFBH005122;  Wed, 30 Jan 2008 10:19:15 +0100
Received: from [10.61.81.100] (ams3-vpn-dhcp4453.cisco.com [10.61.81.100]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0U9JElJ021128;  Wed, 30 Jan 2008 09:19:14 GMT
Message-ID: <[e-mail]>
Date: Wed, 30 Jan 2008 09:19:13 +0000
From: mike shand <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2776; t=1201684755; x=1202548755; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20mike=20shand=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Pseudonode=20minimization=2 0thoughts... |Sender:=20; bh=VGlB17YVb3zorkGDUQQplplwQpgh/C7gz8vQBrlL87k=; b=e38b5IU2pyDtaM5v6OWF2+vstZPSwo7EEVzfVUv6gpSlqcj+YKvsJWZrqO O2QM/IXtOSXslO1JBMrZ7Hryy0wMOVVmBXseq5qeASU8Rs0e2ryflu5iAgTV dToAVGjG1F;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 30 Jan 2008 09:19:47 -0000
Status: RO
Content-Length: 2711

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

Radia Perlman wrote:
> 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
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   



Received: from sernt12.essex.ac.uk (sernt12.essex.ac.uk [155.245.42.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0TJQhUR013393 for <[e-mail]>; Tue, 29 Jan 2008 11:26:44 -0800 (PST)
Received: from sernt14.essex.ac.uk ([155.245.42.34]) by sernt12.essex.ac.uk with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 29 Jan 2008 19:26:42 +0000
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 29 Jan 2008 19:26:42 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Pseudonode minimization thoughts...
Thread-Index: AchiNjz++T2+ljWQTJaJwrWfpxjEgwAdpzEg
References: <[e-mail]>
From: "Thomas, Matthew R" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 29 Jan 2008 19:26:42.0650 (UTC) FILETIME=[E0DC73A0:01C862AC]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m0TJQhUR013393
Subject: Re: [rbridge] Pseudonode minimization thoughts...
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 29 Jan 2008 19:28:07 -0000
Status: RO
Content-Length: 2187

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: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: 29 January 2008 05:05
To: Developing a hybrid router/bridge.
Subject: [rbridge] Pseudonode minimization thoughts...

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
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0T55QTJ011946 for <[e-mail]>; Mon, 28 Jan 2008 21:05:27 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 28 Jan 2008 21:05:19 -0800 (PST)
Received: from [129.150.38.38] ([192.18.101.5]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 28 Jan 2008 21:05:19 -0800 (PST)
Date: Mon, 28 Jan 2008 21:05:13 -0800
From: Radia Perlman <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Pseudonode minimization thoughts...
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 29 Jan 2008 05:05:33 -0000
Status: RO
Content-Length: 1482

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


Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id m0E41ZM6013223 for <[e-mail]>; Sun, 13 Jan 2008 20:01:36 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-153.messagelabs.com!1200283294!6778676!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 14230 invoked from network); 14 Jan 2008 04:01:34 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-153.messagelabs.com with SMTP; 14 Jan 2008 04:01:34 -0000
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m0E41Y4i018011 for <[e-mail]>; Sun, 13 Jan 2008 21:01:34 -0700 (MST)
Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id m0E41XBl009063 for <[e-mail]>; Sun, 13 Jan 2008 22:01:33 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id m0E41WL6009051 for <[e-mail]>; Sun, 13 Jan 2008 22:01:33 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 13 Jan 2008 23:01:29 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IEEE 802.1 Review
Thread-Index: AchWYiRDZefWIXYqReig8YMIwVRgUg==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-CFilter-Loop: Reflected
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m0E41ZM6013223
Subject: [rbridge] IEEE 802.1 Review
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 14 Jan 2008 04:02:16 -0000
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



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id m0E3ua6t011849 for <[e-mail]>; Sun, 13 Jan 2008 19:56:37 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-4.tower-119.messagelabs.com!1200282995!31355502!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 7276 invoked from network); 14 Jan 2008 03:56:35 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-119.messagelabs.com with SMTP; 14 Jan 2008 03:56:35 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m0E3uZai017125 for <[e-mail]>; Sun, 13 Jan 2008 20:56:35 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id m0E3uYqm025197 for <[e-mail]>; Sun, 13 Jan 2008 21:56:34 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id m0E3uXiD025193 for <[e-mail]>; Sun, 13 Jan 2008 21:56:34 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 13 Jan 2008 22:56:31 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Updated Vancouver minutes
Thread-Index: AchWYXKjwVs7MvnkTx+9JJUhGZ8VsQ==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-CFilter-Loop: Reflected
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m0E3ua6t011849
Subject: [rbridge] Updated Vancouver minutes
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 14 Jan 2008 03:57:05 -0000
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      [phone] (work)
 Motorola Laboratories
 111 Locke Drive
 Marlborough, MA 01752 USA
 [e-mail]



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0AG5RR7002305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 10 Jan 2008 08:05:28 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m0AG5E45019656; Thu, 10 Jan 2008 10:05:15 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 10 Jan 2008 10:05:14 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 10 Jan 2008 10:05:12 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports to disable endstation traffic
Thread-Index: AchS27kCRBFHgUNuQxuqo/2zyuWFkgASPS/wAB0yIXA=
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Dinesh G Dutt" <[e-mail]>, "James Carlson" <[e-mail]>
X-OriginalArrivalTime: 10 Jan 2008 16:05:14.0453 (UTC) FILETIME=[95E2B850:01C853A2]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m0AG5RR7002305
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable endstation traffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Jan 2008 16:06:13 -0000
Status: RO
Content-Length: 7810

Anoop,

	Please see in-line below...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
> Sent: Wednesday, January 09, 2008 8:20 PM
> To: Dinesh G Dutt; James Carlson
> Cc: [e-mail]; 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
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Dinesh G Dutt
> > Sent: Wednesday, January 09, 2008 8:05 AM
> > To: James Carlson
> > Cc: [e-mail]; 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
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id m0A4k8AR003042 for <[e-mail]>; Wed, 9 Jan 2008 20:46:09 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-9.tower-119.messagelabs.com!1199940368!29767599!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 16908 invoked from network); 10 Jan 2008 04:46:08 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 10 Jan 2008 04:46:08 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m0A4k7U2002039 for <[e-mail]>; Wed, 9 Jan 2008 21:46:07 -0700 (MST)
Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id m0A4k7iN007125 for <[e-mail]>; Wed, 9 Jan 2008 22:46:07 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id m0A4k68R007113 for <[e-mail]>; Wed, 9 Jan 2008 22:46:07 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 Jan 2008 23:46:05 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Consensus Check: Milestone Move
Thread-Index: AchTQRs7tIJPYoZvT9ysvj1s2BuWnwAAmTkw
References: <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-CFilter-Loop: Reflected
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m0A4k8AR003042
Subject: [rbridge] Consensus Check: Milestone Move
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Jan 2008 04:46:37 -0000
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



Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id m0A4RWAZ028478 for <[e-mail]>; Wed, 9 Jan 2008 20:27:32 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-153.messagelabs.com!1199939250!6211664!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.189.100.102]
Received: (qmail 13456 invoked from network); 10 Jan 2008 04:27:31 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-3.tower-153.messagelabs.com with SMTP; 10 Jan 2008 04:27:31 -0000
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m0A4RURe019845 for <[e-mail]>; Wed, 9 Jan 2008 21:27:30 -0700 (MST)
Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m0A4RTKQ005560 for <[e-mail]>; Wed, 9 Jan 2008 22:27:30 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m0A4RSxS005540 for <[e-mail]>; Wed, 9 Jan 2008 22:27:29 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 Jan 2008 23:27:27 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Consensus Check: Against P2P Fixed Addresses Proposal
Thread-Index: AchTQRs7tIJPYoZvT9ysvj1s2BuWnw==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-CFilter-Loop: Reflected
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m0A4RWAZ028478
Subject: [rbridge] Consensus Check: Against P2P Fixed Addresses Proposal
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Jan 2008 04:28:03 -0000
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      [phone] (work)
 Motorola Laboratories
 111 Locke Drive
 Marlborough, MA 01752 USA
 [e-mail]



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id m0A4Qdsf028234 for <[e-mail]>; Wed, 9 Jan 2008 20:26:40 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-7.tower-119.messagelabs.com!1199939197!30873784!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.189.100.101]
Received: (qmail 16251 invoked from network); 10 Jan 2008 04:26:38 -0000
Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-7.tower-119.messagelabs.com with SMTP; 10 Jan 2008 04:26:38 -0000
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m0A4QRbQ002508 for <[e-mail]>; Wed, 9 Jan 2008 21:26:37 -0700 (MST)
Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m0A4QQtn017856 for <[e-mail]>; Wed, 9 Jan 2008 22:26:26 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m0A4QPRn017840 for <[e-mail]>; Wed, 9 Jan 2008 22:26:25 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 Jan 2008 23:26:24 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports to disable end station traffic
Thread-Index: Acfu8AG2sB8qXAEkTHKan3F795gcpRfSqTvAAMg3aqAAdfSkMA==
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-CFilter-Loop: Reflected
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m0A4Qdsf028234
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end station traffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Jan 2008 04:27:15 -0000
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Monday, January 07, 2008 1:34 PM
To: [e-mail]
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



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0A1NmrH000097 for <[e-mail]>; Wed, 9 Jan 2008 17:23:50 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.24,264,1196668800"; d="scan'208";a="29012557"
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 09 Jan 2008 17:23:48 -0800
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-plato-6 [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 3B5FE2382FF; Wed,  9 Jan 2008 17:23:48 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 9 Jan 2008 17:20:17 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Wed, 9 Jan 2008 17:19:43 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports to disable end station traffic
Thread-Index: AchS27kCRBFHgUNuQxuqo/2zyuWFkgASPS/w
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]><[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Dinesh G Dutt" <[e-mail]>, "James Carlson" <[e-mail]>
X-OriginalArrivalTime: 10 Jan 2008 01:20:17.0511 (UTC) FILETIME=[F5A45770:01C85326]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m0A1NmrH000097
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end station traffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Jan 2008 01:24:13 -0000
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

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Dinesh G Dutt
> Sent: Wednesday, January 09, 2008 8:05 AM
> To: James Carlson
> Cc: [e-mail]; 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
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09MxWe3013068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 9 Jan 2008 14:59:34 -0800 (PST)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m09MxUwQ015906; Wed, 9 Jan 2008 16:59:30 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 9 Jan 2008 16:59:29 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 Jan 2008 16:59:32 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports to disable end station traffic
Thread-Index: AchS8JeXjmsGLEBsTLqw0UtBlkhpgwAAIejgAAgmNoA=
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "James Carlson" <[e-mail]>
X-OriginalArrivalTime: 09 Jan 2008 22:59:29.0867 (UTC) FILETIME=[4A7429B0:01C85313]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m09MxWe3013068
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end station traffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 23:01:58 -0000
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  

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



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09MlCAk009063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 9 Jan 2008 14:47:13 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m09MkgQJ013018; Wed, 9 Jan 2008 16:46:42 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 9 Jan 2008 16:46:42 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 Jan 2008 16:46:43 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports to disable end station traffic
Thread-Index: AchS8JeXjmsGLEBsTLqw0UtBlkhpgwAAIejgAAgAzcA=
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "James Carlson" <[e-mail]>
X-OriginalArrivalTime: 09 Jan 2008 22:46:42.0457 (UTC) FILETIME=[810AB090:01C85311]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m09MlCAk009063
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end station traffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 22:48:15 -0000
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  

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



Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09MeT83006585 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Wed, 9 Jan 2008 14:40:30 -0800 (PST)
Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m09MeRG1006710 for <[e-mail]>; Wed, 9 Jan 2008 22:40:29 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m09MeQCD057492 for <[e-mail]>; Wed, 9 Jan 2008 17:40:26 -0500 (EST)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m09MGdAO008454; Wed, 9 Jan 2008 17:16:39 -0500 (EST)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m09MGU4b008443; Wed, 9 Jan 2008 17:16:30 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 9 Jan 2008 17:16:29 -0500
From: James Carlson <[e-mail]>
To: Joe Touch <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Consensus Check: Configure ports to disable	end	stationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 22:41:13 -0000
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              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09Ku4GT027390 for <[e-mail]>; Wed, 9 Jan 2008 12:56:05 -0800 (PST)
Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m09Ku3Ts025235 for <[e-mail]>; Wed, 9 Jan 2008 20:56:03 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m09Ku35e010230 for <[e-mail]>; Wed, 9 Jan 2008 15:56:03 -0500 (EST)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m09KWGRZ015468; Wed, 9 Jan 2008 15:32:16 -0500 (EST)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m09KWFTc015465; Wed, 9 Jan 2008 15:32:15 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 9 Jan 2008 15:32:15 -0500
From: James Carlson <[e-mail]>
To: Eric Gray <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports todisableendstationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 21:05:20 -0000
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              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09Kqw8p019661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 9 Jan 2008 12:52:59 -0800 (PST)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m09KqbVa024673; Wed, 9 Jan 2008 14:52:40 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 9 Jan 2008 14:52:37 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 Jan 2008 14:52:35 -0600
Message-ID: <[e-mail]>
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7702CAAC5E@nekter>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports to disable endstation traffic
Thread-Index: AchSNmJjj/4azNl4RQ+aBZqwMkmStAAL0+tQABeNhoAADq3eQAAAJAMQ
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <78C9135A3D2ECE4B8162EBDCE82CAD7702CAAC5E@nekter>
From: "Eric Gray" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>, "James Carlson" <[e-mail]>
X-OriginalArrivalTime: 09 Jan 2008 20:52:37.0684 (UTC) FILETIME=[913D3740:01C85301]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m09Kqw8p019661
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable endstation traffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 20:53:59 -0000
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  

> -----Original Message-----
> From: Caitlin Bestler [mailto:[e-mail]] 
> Sent: Wednesday, January 09, 2008 3:34 PM
> To: Eric Gray; Anoop Ghanwani; James Carlson
> Cc: [e-mail]; Joe Touch
> Subject: RE: [rbridge] Consensus Check: Configure ports to 
> disable endstation traffic
> Importance: High
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eric Gray
> > Sent: Wednesday, January 09, 2008 5:39 AM
> > To: Anoop Ghanwani; James Carlson
> > Cc: [e-mail]; 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?
> 
> 
> 



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09KS2ro010451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 9 Jan 2008 12:28:03 -0800 (PST)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m09KS001009579; Wed, 9 Jan 2008 14:28:00 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 9 Jan 2008 14:28:00 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 Jan 2008 14:27:59 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports todisableendstationtraffic
Thread-Index: AchS/CkARGXTUxDwQ6+jYegAVdhakAAAaxHw
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "James Carlson" <[e-mail]>
X-OriginalArrivalTime: 09 Jan 2008 20:28:00.0577 (UTC) FILETIME=[20D09310:01C852FE]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m09KS2ro010451
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports todisableendstationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 20:44:34 -0000
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  

> -----Original Message-----
> From: James Carlson [mailto:[e-mail]] 
> Sent: Wednesday, January 09, 2008 3:04 PM
> To: Eric Gray
> Cc: Joe Touch; [e-mail]
> Subject: RE: [rbridge] Consensus Check: Configure ports 
> todisableendstationtraffic
> Importance: High
> 
> Eric Gray writes:
> > > -----Original Message-----
> > > From: James Carlson [mailto:[e-mail]] 
> [...]
> > > 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              
> <[e-mail]>
> 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
> 



Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09KSbDJ010644 for <[e-mail]>; Wed, 9 Jan 2008 12:28:38 -0800 (PST)
Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m09KSbr0016067 for <[e-mail]>; Wed, 9 Jan 2008 20:28:37 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m09KSbAd004009 for <[e-mail]>; Wed, 9 Jan 2008 15:28:37 -0500 (EST)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m09K4esl014790; Wed, 9 Jan 2008 15:04:40 -0500 (EST)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m09K4UrF014785; Wed, 9 Jan 2008 15:04:30 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 9 Jan 2008 15:04:29 -0500
From: James Carlson <[e-mail]>
To: Eric Gray <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports todisableendstationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 20:44:30 -0000
Status: RO
Content-Length: 4366

Eric Gray writes:
> > -----Original Message-----
> > From: James Carlson [mailto:[e-mail]] 
[...]
> > 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              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09KYm4s012289 for <[e-mail]>; Wed, 9 Jan 2008 12:34:49 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Wed, 9 Jan 2008 15:33:34 -0500
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7702CAAC5E@nekter>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports to disable endstation traffic
Thread-Index: AchSNmJjj/4azNl4RQ+aBZqwMkmStAAL0+tQABeNhoAADq3eQA==
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Caitlin Bestler" <[e-mail]>
To: "Eric Gray" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>, "James Carlson" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m09KYm4s012289
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable endstation traffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 20:39:30 -0000
Status: RO
Content-Length: 754

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eric Gray
> Sent: Wednesday, January 09, 2008 5:39 AM
> To: Anoop Ghanwani; James Carlson
> Cc: [e-mail]; 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?





Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09JrnQG028973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 9 Jan 2008 11:53:50 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m09Jrl4d030201; Wed, 9 Jan 2008 13:53:47 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 9 Jan 2008 13:53:47 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 Jan 2008 13:53:46 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports todisable	endstationtraffic
Thread-Index: AchS0E3Pci8fkrVUTdmlOdhfmXq4sQAKLh5w
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Joe Touch" <[e-mail]>
X-OriginalArrivalTime: 09 Jan 2008 19:53:47.0513 (UTC) FILETIME=[5917DE90:01C852F9]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m09JrnQG028973
Cc: [e-mail]
Subject: Re: [rbridge] Consensus Check: Configure ports todisable	endstationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 19:54:00 -0000
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  

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Tuesday, January 08, 2008 7:12 PM
> To: Eric Gray
> Cc: James Carlson; [e-mail]
> 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 <[e-mail]>
> * 0x89A766BB
> 
> 



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09Jlgm9027326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 9 Jan 2008 11:47:43 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m09JldmJ027213; Wed, 9 Jan 2008 13:47:39 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 9 Jan 2008 13:47:39 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 Jan 2008 13:47:37 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports todisableendstationtraffic
Thread-Index: AchS5pruzCJWWd3fT+OGanXn/6644AADS+Jw
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "James Carlson" <[e-mail]>
X-OriginalArrivalTime: 09 Jan 2008 19:47:39.0359 (UTC) FILETIME=[7DA806F0:01C852F8]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m09Jlgm9027326
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports todisableendstationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 19:48:37 -0000
Status: RO
Content-Length: 5539

James,

	Please see below...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: James Carlson [mailto:[e-mail]] 
> Sent: Wednesday, January 09, 2008 11:18 AM
> To: Eric Gray
> Cc: Joe Touch; [e-mail]
> 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              
> <[e-mail]>
> 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
> 



Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09JL493017388 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Wed, 9 Jan 2008 11:21:04 -0800 (PST)
Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m09JL3tq019251 for <[e-mail]>; Wed, 9 Jan 2008 19:21:03 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m09JL36x052915 for <[e-mail]>; Wed, 9 Jan 2008 14:21:03 -0500 (EST)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m09Ig7rp014236; Wed, 9 Jan 2008 13:42:07 -0500 (EST)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m09Ifmsm014229; Wed, 9 Jan 2008 13:41:48 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 9 Jan 2008 13:41:45 -0500
From: James Carlson <[e-mail]>
To: Anoop Ghanwani <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end station traffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 19:21:42 -0000
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              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09Iul36007274 for <[e-mail]>; Wed, 9 Jan 2008 10:56:48 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.24,263,1196668800"; d="scan'208";a="28955501"
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 09 Jan 2008 10:56:44 -0800
Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 84FF32382FB; Wed,  9 Jan 2008 10:56:46 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 9 Jan 2008 10:56:46 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Wed, 9 Jan 2008 10:56:18 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports to disable end station traffic
Thread-Index: AchS8JeXjmsGLEBsTLqw0UtBlkhpgwAAIejg
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "James Carlson" <[e-mail]>
X-OriginalArrivalTime: 09 Jan 2008 18:56:46.0513 (UTC) FILETIME=[6204B210:01C852F1]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m09Iul36007274
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end station traffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 18:58:37 -0000
Status: RO
Content-Length: 1221

 

> -----Original Message-----
> From: James Carlson [mailto:[e-mail]] 
> Sent: Wednesday, January 09, 2008 10:42 AM
> To: Anoop Ghanwani
> Cc: Dinesh G Dutt; Eric Gray; [e-mail]; 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



Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09IUXtZ027587 for <[e-mail]>; Wed, 9 Jan 2008 10:30:35 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.24,263,1196668800"; d="scan'208";a="17710568"
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 09 Jan 2008 10:30:32 -0800
Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 0CE182382FB; Wed,  9 Jan 2008 10:30:33 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 9 Jan 2008 10:30:32 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Wed, 9 Jan 2008 10:30:06 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports to disable end station traffic
Thread-Index: AchS2a1Z2G8Rcj36Q4WDXJedkO1CVQAEzK0w
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Dinesh G Dutt" <[e-mail]>, "Eric Gray" <[e-mail]>
X-OriginalArrivalTime: 09 Jan 2008 18:30:32.0954 (UTC) FILETIME=[B81AA5A0:01C852ED]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m09IUXtZ027587
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end station traffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 18:32:11 -0000
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 

> -----Original Message-----
> From: Dinesh G Dutt [mailto:[e-mail]] 
> Sent: Wednesday, January 09, 2008 8:07 AM
> To: Eric Gray
> Cc: Anoop Ghanwani; James Carlson; [e-mail]; 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
> >
> >   
> >> -----Original Message-----
> >> From: Anoop Ghanwani [mailto:[e-mail]]
> >> Sent: Tuesday, January 08, 2008 9:18 PM
> >> To: James Carlson; Eric Gray
> >> Cc: [e-mail]; Joe Touch
> >> Subject: RE: [rbridge] Consensus Check: Configure 
> portstodisable end 
> >> stationtraffic
> >> Importance: High
> >>
> >>  
> >>
> >>     
> >>> -----Original Message-----
> >>> From: [e-mail]
> >>> [mailto:[e-mail]] On Behalf Of James Carlson
> >>> Sent: Tuesday, January 08, 2008 11:51 AM
> >>> To: Eric Gray
> >>> Cc: [e-mail]; 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
> >>
> >>     
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> >   
> 
> --
> We make our world significant by the courage of our questions and by 
> the depth of our answers.                               - Carl Sagan
> 
> 



Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09ILnM1024457 for <[e-mail]>; Wed, 9 Jan 2008 10:21:50 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Wed, 9 Jan 2008 13:20:38 -0500
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7702CAABA0@nekter>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure portstodisable	endstationtraffic
Thread-Index: AchST15o+t5LFRVORLmAXind8LOkWQAAB9cQACbbFVA=
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Caitlin Bestler" <[e-mail]>
To: "Eric Gray" <[e-mail]>, "James Carlson" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m09ILnM1024457
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure portstodisable	endstationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 18:22:18 -0000
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).




Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09Gg8lP014744 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Wed, 9 Jan 2008 08:42:09 -0800 (PST)
Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m09Gg6lj006176 for <[e-mail]>; Wed, 9 Jan 2008 16:42:07 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m09Gg6W5010255 for <[e-mail]>; Wed, 9 Jan 2008 11:42:06 -0500 (EST)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m09GIAZW012869; Wed, 9 Jan 2008 11:18:10 -0500 (EST)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m09GI9mM012864; Wed, 9 Jan 2008 11:18:09 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 9 Jan 2008 11:18:09 -0500
From: James Carlson <[e-mail]>
To: Eric Gray <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports todisable	endstationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 16:43:31 -0000
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              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09G73hr029975 for <[e-mail]>; Wed, 9 Jan 2008 08:07:04 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.24,263,1196668800"; d="scan'208";a="33000089"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Jan 2008 08:07:03 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m09G73RL007321;  Wed, 9 Jan 2008 08:07:03 -0800
Received: from [10.21.91.215] (sjc-vpn5-983.cisco.com [10.21.91.215]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m09G72cV000336; Wed, 9 Jan 2008 16:07:03 GMT
Message-ID: <[e-mail]>
Date: Wed, 09 Jan 2008 08:07:03 -0800
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20071031)
MIME-Version: 1.0
To: Eastlake III Donald-LDE008 <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=779; t=1199894823; x=1200758823; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Consensus=20Check=3A=20Allo w=20GVRP/MVRP |Sender:=20; bh=3Qkb3M9zX1YxcPKW4hp5rkuM/1WN4jVGAFB1qmZV+ak=; b=bhMZdkeu4XckjPk5ru6g3MNmn+0Tk9kk1u8YnObp0XM2xvwyRfhfT+JYke tNZJWwkqta9zrXtnRjn1Zm0CjLPTYu0VagFLjLNSGbZG+Op1LMuub/bzkA0I F4o+eSTQ2T7hhcjuSKF6CJfdN+P4Wb8CaHheE9zYCLBpHedUWd+ow=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Consensus Check: Allow GVRP/MVRP
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 16:07:40 -0000
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
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

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



Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09G6b3s029718 for <[e-mail]>; Wed, 9 Jan 2008 08:06:38 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.24,263,1196668800"; d="scan'208";a="32999824"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Jan 2008 08:06:36 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m09G6aex006278;  Wed, 9 Jan 2008 08:06:36 -0800
Received: from [10.21.91.215] (sjc-vpn5-983.cisco.com [10.21.91.215]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m09G6YcV029800; Wed, 9 Jan 2008 16:06:34 GMT
Message-ID: <[e-mail]>
Date: Wed, 09 Jan 2008 08:06:34 -0800
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20071031)
MIME-Version: 1.0
To: Eric Gray <[e-mail]>
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2715; t=1199894796; x=1200758796; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Consensus=20Check=3A=20Conf igure=20ports=20to=20disable=20end=09station=0A=20traffic |Sender:=20; bh=0Lm9X9E2Qc1nQ0JS3UrVYoWtJTBV7gfiJjpKGlInjL8=; b=E3CBDvh6YVLuWYbJ541SzCAeWUqrKcklFU8kDUJsB1sQLt1EreiVti3CvC WW8xJlQeimV+gnw3Kqe67wbYkl72YmYMv6G/FdIV0mcM/aA6koXHpwSWYx/Z 3iJZgyiqFJJqKLkMho1rLYb9Hz+eBNwC1tBvfhk0JCjSKBHO8Cuqg=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end	station traffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 16:07:22 -0000
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  
>
>   
>> -----Original Message-----
>> From: Anoop Ghanwani [mailto:[e-mail]] 
>> Sent: Tuesday, January 08, 2008 9:18 PM
>> To: James Carlson; Eric Gray
>> Cc: [e-mail]; Joe Touch
>> Subject: RE: [rbridge] Consensus Check: Configure 
>> portstodisable end stationtraffic
>> Importance: High
>>
>>  
>>
>>     
>>> -----Original Message-----
>>> From: [e-mail] 
>>> [mailto:[e-mail]] On Behalf Of James Carlson
>>> Sent: Tuesday, January 08, 2008 11:51 AM
>>> To: Eric Gray
>>> Cc: [e-mail]; 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
>>
>>     
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

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



Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09G4f5s028594 for <[e-mail]>; Wed, 9 Jan 2008 08:04:42 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.24,263,1196668800";  d="scan'208";a="7413000"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 09 Jan 2008 08:04:40 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m09G4ekm016828;  Wed, 9 Jan 2008 08:04:40 -0800
Received: from [10.21.91.215] (sjc-vpn5-983.cisco.com [10.21.91.215]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m09G4dFK010609; Wed, 9 Jan 2008 16:04:40 GMT
Message-ID: <[e-mail]>
Date: Wed, 09 Jan 2008 08:04:39 -0800
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20071031)
MIME-Version: 1.0
To: James Carlson <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2121; t=1199894680; x=1200758680; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Consensus=20Check=3A=20Conf igure=20ports=20to=09disable=09end=09stationtraffic |Sender:=20; bh=e0iWiGSIp8yKRHnjMNszFKMaIMmebyBMrQy7jMVk3oM=; b=oPePF4m+vKUPgvP0mnhr9b2OFkH8DH5aexwvbwUf4g7+2FRYCUoOnFspf7 hmKjxG5iWZsl74opirRIm9Us8tJhZRWMN827Rv+vqqB352gLtoCpcaaImXB8 IOyX54tq2x;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports to	disable	end	stationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 16:05:35 -0000
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



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09DdV47018893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 9 Jan 2008 05:39:32 -0800 (PST)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m09DdLYe010631; Wed, 9 Jan 2008 07:39:23 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 9 Jan 2008 07:39:21 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 Jan 2008 07:39:19 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports to disable end station traffic
Thread-Index: AchSNmJjj/4azNl4RQ+aBZqwMkmStAAL0+tQABeNhoA=
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "James Carlson" <[e-mail]>
X-OriginalArrivalTime: 09 Jan 2008 13:39:21.0292 (UTC) FILETIME=[0A2E98C0:01C852C5]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m09DdV47018893
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end station traffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 13:39:50 -0000
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  

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Tuesday, January 08, 2008 9:18 PM
> To: James Carlson; Eric Gray
> Cc: [e-mail]; Joe Touch
> Subject: RE: [rbridge] Consensus Check: Configure 
> portstodisable end stationtraffic
> Importance: High
> 
>  
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of James Carlson
> > Sent: Tuesday, January 08, 2008 11:51 AM
> > To: Eric Gray
> > Cc: [e-mail]; 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
> 



Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m092IfbH024743 for <[e-mail]>; Tue, 8 Jan 2008 18:18:43 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.24,259,1196668800"; d="scan'208";a="17636384"
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 08 Jan 2008 18:18:41 -0800
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-plato-6 [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 4782C2382F7; Tue,  8 Jan 2008 18:18:41 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 8 Jan 2008 18:18:39 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Tue, 8 Jan 2008 18:18:11 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure portstodisable	end	stationtraffic
Thread-Index: AchSNmJjj/4azNl4RQ+aBZqwMkmStAAL0+tQ
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "James Carlson" <[e-mail]>, "Eric Gray" <[e-mail]>
X-OriginalArrivalTime: 09 Jan 2008 02:18:39.0213 (UTC) FILETIME=[F267E9D0:01C85265]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m092IfbH024743
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure portstodisable	end	stationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 02:18:54 -0000
Status: RO
Content-Length: 1035

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of James Carlson
> Sent: Tuesday, January 08, 2008 11:51 AM
> To: Eric Gray
> Cc: [e-mail]; 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



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m090C6G4015233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 8 Jan 2008 16:12:07 -0800 (PST)
Received: from [75.214.92.180] (180.sub-75-214-92.myvzw.com [75.214.92.180]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m090BitT001505; Tue, 8 Jan 2008 16:11:45 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 08 Jan 2008 16:11:40 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Eric Gray <[e-mail]>
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4595508A4DA10237401BD43C"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Consensus Check: Configure ports todisable	endstationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 00:12:19 -0000
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"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHhBE9E5f5cImnZrsRAqZoAKCrbNZjfW4DLOUOMLtuvV1MB4JPFwCeKUKx
kTTxiWjB4vTMx5WjcA4++Ic=
=XWQi
-----END PGP SIGNATURE-----

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


Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08Npfui007109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 8 Jan 2008 15:51:42 -0800 (PST)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m08NpdGT005898; Tue, 8 Jan 2008 17:51:39 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 8 Jan 2008 17:51:39 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 8 Jan 2008 17:51:37 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports todisable	endstationtraffic
Thread-Index: AchST15o+t5LFRVORLmAXind8LOkWQAAB9cQ
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "James Carlson" <[e-mail]>
X-OriginalArrivalTime: 08 Jan 2008 23:51:39.0062 (UTC) FILETIME=[692FAD60:01C85251]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m08Npfui007109
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports todisable	endstationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 08 Jan 2008 23:59:08 -0000
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  

> -----Original Message-----
> From: James Carlson [mailto:[e-mail]] 
> Sent: Tuesday, January 08, 2008 2:51 PM
> To: Eric Gray
> Cc: Joe Touch; [e-mail]
> 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              
> <[e-mail]>
> 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
> 



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08KGufL029447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 8 Jan 2008 12:16:58 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m08KGtov024304; Tue, 8 Jan 2008 14:16:55 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 8 Jan 2008 14:16:55 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 8 Jan 2008 14:16:53 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports to disable end stationtraffic
Thread-Index: Acfu8AG2sB8qXAEkTHKan3F795gcpRfSqTvAAMg3aqAANNxR8A==
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 08 Jan 2008 20:16:55.0175 (UTC) FILETIME=[69CA8970:01C85233]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m08KGufL029447
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end stationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 08 Jan 2008 20:23:24 -0000
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  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Monday, January 07, 2008 1:34 PM
> To: [e-mail]
> 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
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08KFBjG029007 for <[e-mail]>; Tue, 8 Jan 2008 12:15:12 -0800 (PST)
Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m08KFACQ009095 for <[e-mail]>; Tue, 8 Jan 2008 20:15:11 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m08KFApj041112 for <[e-mail]>; Tue, 8 Jan 2008 15:15:10 -0500 (EST)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m08JpJ7g009258; Tue, 8 Jan 2008 14:51:19 -0500 (EST)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m08JpFeE009255; Tue, 8 Jan 2008 14:51:15 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 8 Jan 2008 14:51:15 -0500
From: James Carlson <[e-mail]>
To: Eric Gray <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Consensus Check: Configure ports todisable	end	stationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 08 Jan 2008 20:23:11 -0000
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              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08JFtZK008305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 8 Jan 2008 11:15:57 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m08JFqhE020340; Tue, 8 Jan 2008 13:15:52 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 8 Jan 2008 13:15:52 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 8 Jan 2008 13:15:51 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports todisable	end	stationtraffic
Thread-Index: AchRrUKnyPoPSzO4SWa8mTamzPRxqgAXluoQ
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "James Carlson" <[e-mail]>, "Joe Touch" <[e-mail]>
X-OriginalArrivalTime: 08 Jan 2008 19:15:52.0027 (UTC) FILETIME=[E26282B0:01C8522A]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m08JFtZK008305
Cc: [e-mail]
Subject: Re: [rbridge] Consensus Check: Configure ports todisable	end	stationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 08 Jan 2008 19:16:57 -0000
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  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of James Carlson
> Sent: Monday, January 07, 2008 3:39 PM
> To: Joe Touch
> Cc: [e-mail]
> 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              
> <[e-mail]>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m07LWY8R006371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 7 Jan 2008 13:32:35 -0800 (PST)
Received: from [75.214.46.216] (216.sub-75-214-46.myvzw.com [75.214.46.216]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m07LW0bK001742; Mon, 7 Jan 2008 13:32:01 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 07 Jan 2008 13:31:56 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Joe Touch <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5FBBDCCD2ED91F696B3807E9"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Consensus Check: Configure ports to disable	end	stationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2008 21:33:17 -0000
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"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHgppNE5f5cImnZrsRAn9sAJ9dLUJ7JAPIciZjQHwBkC6WkNAvBACgxzkk
L1UPhJwWzsfSU1lHxdEg9kQ=
=YiJ7
-----END PGP SIGNATURE-----

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


Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m07LGQVQ000698 for <[e-mail]>; Mon, 7 Jan 2008 13:16:28 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.24,255,1196668800"; d="scan'208";a="17503789"
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 07 Jan 2008 13:16:26 -0800
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-plato-6 [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 3A01E238305; Mon,  7 Jan 2008 13:16:26 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 7 Jan 2008 13:16:25 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Mon, 7 Jan 2008 13:15:59 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports to disable end stationtraffic
Thread-Index: AchRZH5fPUk9IGXXTj2UfakIKLMcpQADTcKA
References: <[e-mail]><[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Joe Touch" <[e-mail]>
X-OriginalArrivalTime: 07 Jan 2008 21:16:25.0924 (UTC) FILETIME=[8FB5D840:01C85172]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m07LGQVQ000698
Cc: [e-mail]
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end stationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2008 21:17:17 -0000
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

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Monday, January 07, 2008 11:32 AM
> To: Anoop Ghanwani
> Cc: Eastlake III Donald-LDE008; [e-mail]
> 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
> > 
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of Eastlake III
> >> Donald-LDE008
> >> Sent: Monday, January 07, 2008 10:34 AM
> >> To: [e-mail]
> >> 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
> >>
> >> _______________________________________________
> >> rbridge mailing list
> >> [e-mail]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> 
> 



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m07L9E2W027509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 7 Jan 2008 13:09:15 -0800 (PST)
Received: from [75.214.46.216] (216.sub-75-214-46.myvzw.com [75.214.46.216]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m07L8bEq025796; Mon, 7 Jan 2008 13:08:38 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 07 Jan 2008 13:08:34 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: James Carlson <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig018F75FDE7138156AE91D536"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Consensus Check: Configure ports to disable	end	stationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2008 21:09:47 -0000
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"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHgpTSE5f5cImnZrsRAo/KAKCALPERX5qb76GQW7PDpabZGZ8DVgCgyKHH
hYLqyTnd/fCmM5ym8dkJEUM=
=zhm+
-----END PGP SIGNATURE-----

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


Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m07L3Fg7025397 for <[e-mail]>; Mon, 7 Jan 2008 13:03:16 -0800 (PST)
Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m07L3Ev9000943 for <[e-mail]>; Mon, 7 Jan 2008 21:03:15 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m07L3E7Q004703 for <[e-mail]>; Mon, 7 Jan 2008 16:03:14 -0500 (EST)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m07KdS4o005249; Mon, 7 Jan 2008 15:39:28 -0500 (EST)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m07KdRVk005246; Mon, 7 Jan 2008 15:39:27 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 7 Jan 2008 15:39:27 -0500
From: James Carlson <[e-mail]>
To: Joe Touch <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Consensus Check: Configure ports to disable	end	stationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2008 21:03:36 -0000
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              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m07Kiq02016700 for <[e-mail]>; Mon, 7 Jan 2008 12:44:54 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Mon, 7 Jan 2008 15:43:49 -0500
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7702CAA62D@nekter>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports to disableend	stationtraffic
Thread-Index: AchRZkE7xDt45SHISTa3WL4BAkiD0wABxj/A
References: <[e-mail]><[e-mail]>	<[e-mail]><[e-mail]> <[e-mail]>
From: "Caitlin Bestler" <[e-mail]>
To: "Joe Touch" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m07Kiq02016700
Cc: [e-mail]
Subject: Re: [rbridge] Consensus Check: Configure ports to disableend	stationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2008 20:45:45 -0000
Status: RO
Content-Length: 1264

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Joe Touch
> Sent: Monday, January 07, 2008 11:32 AM
> To: Anoop Ghanwani
> Cc: [e-mail]
> 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.




Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m07Ja2wj018181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 7 Jan 2008 11:36:03 -0800 (PST)
Received: from [75.214.46.216] (216.sub-75-214-46.myvzw.com [75.214.46.216]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m07JWRNQ025273; Mon, 7 Jan 2008 11:32:28 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 07 Jan 2008 11:32:24 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Anoop Ghanwani <[e-mail]>
References: <[e-mail]><[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5AC50F7F791749839490C2AC"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end	stationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2008 19:36:48 -0000
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
>> -----Original Message-----
>> From: [e-mail]=20
>> [mailto:[e-mail]] On Behalf Of Eastlake III=20
>> Donald-LDE008
>> Sent: Monday, January 07, 2008 10:34 AM
>> To: [e-mail]
>> 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
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHgn5IE5f5cImnZrsRAsebAKDvfGdZYdxW0rNVsCG1gsCp3Xff+wCgm6yl
WM1T9cYUVbvvSke0dBL7QVU=
=g0dm
-----END PGP SIGNATURE-----

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


Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m07JRjPX014041 for <[e-mail]>; Mon, 7 Jan 2008 11:27:46 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Mon, 7 Jan 2008 14:26:41 -0500
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7702CAA5B1@nekter>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports to disable endstationtraffic
Thread-Index: Acfu8AG2sB8qXAEkTHKan3F795gcpRfSqTvAAMg3aqAAAWJ+gAAAdZBg
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Caitlin Bestler" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m07JRjPX014041
Subject: Re: [rbridge] Consensus Check: Configure ports to disable endstationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2008 19:28:07 -0000
Status: RO
Content-Length: 1160

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anoop Ghanwani
> Sent: Monday, January 07, 2008 11:14 AM
> To: Eastlake III Donald-LDE008; [e-mail]
> 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.




Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m07JEsd6006755 for <[e-mail]>; Mon, 7 Jan 2008 11:14:55 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.24,254,1196668800"; d="scan'208";a="28517219"
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 07 Jan 2008 11:14:54 -0800
Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id F279E2383CD; Mon,  7 Jan 2008 11:14:53 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 7 Jan 2008 11:14:53 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Mon, 7 Jan 2008 11:14:27 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Consensus Check: Configure ports to disable end stationtraffic
Thread-Index: Acfu8AG2sB8qXAEkTHKan3F795gcpRfSqTvAAMg3aqAAAWJ+gA==
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 07 Jan 2008 19:14:53.0881 (UTC) FILETIME=[95506290:01C85161]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m07JEsd6006755
Subject: Re: [rbridge] Consensus Check: Configure ports to disable end stationtraffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2008 19:15:41 -0000
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 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Monday, January 07, 2008 10:34 AM
> To: [e-mail]
> 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
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id m07IaK1v016816 for <[e-mail]>; Mon, 7 Jan 2008 10:36:21 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-12.tower-128.messagelabs.com!1199730979!15655037!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 6926 invoked from network); 7 Jan 2008 18:36:19 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-128.messagelabs.com with SMTP; 7 Jan 2008 18:36:19 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m07IaJk1029082 for <[e-mail]>; Mon, 7 Jan 2008 11:36:19 -0700 (MST)
Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id m07IaIh2014575 for <[e-mail]>; Mon, 7 Jan 2008 12:36:18 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m07IaIYf014563 for <[e-mail]>; Mon, 7 Jan 2008 12:36:18 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 7 Jan 2008 13:36:15 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Consensus Check: Allow GVRP/MVRP
Thread-Index: Acfu8AG2sB8qXAEkTHKan3F795gcpRfSqTvAAMhYmbA=
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-CFilter-Loop: Reflected
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m07IaK1v016816
Subject: [rbridge] Consensus Check: Allow GVRP/MVRP
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2008 18:38:30 -0000
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



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id m07IYOBI015103 for <[e-mail]>; Mon, 7 Jan 2008 10:34:25 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-13.tower-128.messagelabs.com!1199730923!18043241!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 784 invoked from network); 7 Jan 2008 18:35:23 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 7 Jan 2008 18:35:23 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m07IYMes028471 for <[e-mail]>; Mon, 7 Jan 2008 11:34:22 -0700 (MST)
Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id m07IYM7J014942 for <[e-mail]>; Mon, 7 Jan 2008 12:34:22 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id m07IYL8x014928 for <[e-mail]>; Mon, 7 Jan 2008 12:34:21 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 7 Jan 2008 13:34:19 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Consensus Check: Configure ports to disable end station traffic
Thread-Index: Acfu8AG2sB8qXAEkTHKan3F795gcpRfSqTvAAMg3aqA=
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-CFilter-Loop: Reflected
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m07IYOBI015103
Subject: [rbridge] Consensus Check: Configure ports to disable end station traffic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2008 18:37:48 -0000
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



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id m03JDlbB026024 for <[e-mail]>; Thu, 3 Jan 2008 11:13:48 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-5.tower-128.messagelabs.com!1199387626!8829899!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.189.100.101]
Received: (qmail 10184 invoked from network); 3 Jan 2008 19:13:46 -0000
Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-5.tower-128.messagelabs.com with SMTP; 3 Jan 2008 19:13:46 -0000
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m03JDaKk005169 for <[e-mail]>; Thu, 3 Jan 2008 12:13:46 -0700 (MST)
Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id m03JDZNc007044 for <[e-mail]>; Thu, 3 Jan 2008 13:13:35 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id m03JDYX2007025 for <[e-mail]>; Thu, 3 Jan 2008 13:13:34 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 3 Jan 2008 14:13:32 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Consensus Check: Pseudonode suppression
Thread-Index: Acfu8AG2sB8qXAEkTHKan3F795gcpRfSqTvA
References: <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-CFilter-Loop: Reflected
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m03JDlbB026024
Subject: [rbridge] Consensus Check: Pseudonode suppression
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 Jan 2008 19:14:03 -0000
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



Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id m02JU3BU012605 for <[e-mail]>; Wed, 2 Jan 2008 11:30:04 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-8.tower-153.messagelabs.com!1199302202!9710213!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 20983 invoked from network); 2 Jan 2008 19:30:02 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-153.messagelabs.com with SMTP; 2 Jan 2008 19:30:02 -0000
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m02JTq9a020633 for <[e-mail]>; Wed, 2 Jan 2008 12:30:02 -0700 (MST)
Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id m02JTpw1002891 for <[e-mail]>; Wed, 2 Jan 2008 13:29:51 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id m02JToKl002878 for <[e-mail]>; Wed, 2 Jan 2008 13:29:51 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 2 Jan 2008 14:29:49 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Minutes for TRILL at IETF-70 posted
Thread-Index: AchNddbsj5pIgu83T7W3N4Dl8mJ6bQ==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-CFilter-Loop: Reflected
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m02JU3BU012605
Subject: [rbridge] Minutes for TRILL at IETF-70 posted
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 02 Jan 2008 19:30:48 -0000
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      [phone] (work)
 Motorola Laboratories
 111 Locke Drive
 Marlborough, MA 01752 USA
 [e-mail]