Hi Brian, On Jan 8, 2008, at 4:06 PM, Brian Dickson wrote:
Reachability from "pure" BGP, which needs to converge and which feeds the FIB, e.g. the DFZ prefixes, isclearly control plane.However, when BGP is used in an opaque manner to pass information that doesn't go into local FIB, it thenisn't a convergence or control plane issue.
Not necessarily.Gedanken experiment: Suppose that a BGP speaker interleaves BGP update messages containing DFZ prefixes with one full minutes worth of 'opaque' data. Does this have an effect on the control plane? Two minutes? Ten?
The control plane is concerned with responsiveness.
If, for example, reachability on RLOC->EID mappings were passed as opaque elements via BGP, the only impact outside of xTRs would be the memory consumption and bandwidth associated with passing the updatesend-to-end.
And processing power, and delay. Remember that the control plane *is* a control loop, and changing the time constants of that control loop *do* change the characteristics of the control plane.
Consuming state in other applications also takes away from the state that can be devoted to the control plane.
Add one interesting twist to that:If you combine effectively static RLOC->EID info, with RLOC reachability which is propagated as an opaqueitem to xTRs, that might have good scaling characteristics.What I'm thinking of is, have aggregators suppress the more- specifics, but when a more-specific goes away,pass the *un*-reachability "hole" as an opaque item.It would be of interest almost exclusively to xTRs, and the scalability would depend on "what is down",rather than "what is out there". And it would do so without directly affecting the DFZ.
Yet still with an indirect effect. Please don't ignore it. Tony -- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg