[rbridge] Pseudonode minimization thoughts...

[Les Ginsberg (ginsberg)]

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