[rbridge] Pseudonode minimization thoughts...

[mike shand]

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