[rbridge] Pseudonode minimization thoughts...

[Radia Perlman]

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
>