Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures

[Brian Dickson <briand@ca.afilias.info>]

PAPADIMITRIOU Dimitri wrote:
> tony, 
>
>   
> > > Well, we're here because of the concern that BGP4 updates 
> > > will become prohibitive as multihoming expands, aren't we?
> > >       
> > Nope.  We're here because routing convergence will continue to  
> > degrade as the number of prefixes scales.  There are multiple 
> > reasons  
> > for the scaling issue, and BGP is irrelevant to the scaling problem,  
> > as the scaling of the information content is independent of the  
> > delivery mechanism.
> >     
>
> as convergence gets affected by approaches that are not preserving the
> locality principle due to the ITR-ETR relationship they involve (see
> also e-mail from Yakov along the same line) 
>
> -> how are they positioned as fulfilling the initial design goals ?
>   
What is interesting, is observing what is really control-plane, versus 
carried via control-plane mechanisms.

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.

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.

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.

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.

Thoughts?

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