[rbridge] Pseudonode minimization thoughts...

[Radia Perlman]

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
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>   
>