[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures
Tony Li wrote:
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, is
clearly control plane.
However, when BGP is used in an opaque manner to pass information
that doesn't go into local FIB, it then
isn'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.
I agree.
However, the angel (rather than devil) is in the details.
If the opaque data is orders of magnitude smaller, it's less of a concern.
Ditto if it is possible to ensure non-head-of-line blocking between the
two streams.
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 updates
end-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.
Yep. It's far from overlooked - I'd even go so far as to say, there's
work to be done on the control plane methods,
and on the OS models used (e.g. real-time with maximum delays on
operations.)
Add one interesting twist to that:
If you combine effectively static RLOC->EID info, with RLOC
reachability which is propagated as an opaque
item 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.
Let me expound on this some more...
If the ETRs were announcing only *negative* information (as opaque
data), the semantics would also change.
In the case of a local upstream link failure:
The end-site ETR (or mesh of ETRs) would announce local unavailability
of RLOC(s) upstream via links that are *not* down.
This would be a *sender* rather than *receiver* model for state
detection, announcement, and propagation.
There are risks, of course - a complete site outage would not have state
announced, and would globally appear "up", falsely.
But, at the same time, that consequence would be moot, as the site would
be completely unreachable. :-)
Failures further upstream than the PE-CE link are not likely to induce
full outages.
Only the aggregate itself need be affected if ISP upstream links fail,
and then only in the DFZ,
*not* the opaque data.
Since only link-down state (on RLOC links) needs to be captured and
flooded, the optimum condition (no failures) would be
expressed via the empty set. (!!)
And the locality and scalability have nice characteristics. No shared
fate on link failures, only one update (and one opaque data entry)
are generated by *any* single failure *anywhere*.
The biggest hit would likely occur if a CLEC (remember those?) lost a
bunch of fibre.
In general, this scales by the probability of outages, rather than the
size of the deployed networks or the size of the DFZ.
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.
No, definitely not.
I'd rather characterize and model it, and see if it plays well with
others. :-)
Brian D
--
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