[rbridge] Pseudonode minimization thoughts...
Radia Perlman
Radia.Perlman at sun.com
Thu Jan 31 20:31:01 PST 2008
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: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
>>
> 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
>>>>>> rbridge at postel.org
>>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> rbridge at postel.org
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>>
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
More information about the rbridge
mailing list