Re: [Idr] draft on virtual aggregation

[Paul Francis <francis at cs.cornell.edu>]

inline

> -----Original Message-----
> From: Daniel Ginsburg [mailto:dg at ot-e.biz]
> Sent: Tuesday, July 15, 2008 11:43 AM
> To: Paul Francis
> Cc: idr at ietf.org
> Subject: Re: [Idr] draft on virtual aggregation
> 
> On 10.07.2008 16:44 Paul Francis wrote:
> 
> >> Section 4.2:
> >> There're some possible externally visible traffic engineering
> issues.
> >> AS
> >> with VA deployed might choose different exit points as compared to
> AS
> >> without VA.
> >> These issues are similar to that of route reflectors deployments.
> >
> > I don't see why VA would choose a different exit point.  VA doesn't
> change
> > the BGP decision process at all.  If a router selected a particular
> next-hop
> > without VA, it would select the same next-hop with VA.  Perhaps what
> you mean
> > is the following?
> >
> > Say you had the following topology:
> >
> > A--B--C--|--X
> >    |
> >    D-----|--Y
> >
> > where X and Y are external peers.  In the case without VA, A gets a
> packet,
> > picks X as the exit, forwards the packet to B, which decides to pick
> Y as the
> > next hop (can this happen?).  If this is VA, however, once A picks X,
> it
> > tunnels the packet to X, so B can't divert it to a different exit.
> If this
> > case occurs, then you are right that VA can cause a change in exit...
> >
> 
> Yes, it can happen. Assume the following link metrics:
> 
>       1
> A--B---C--|--X
>     |
>     |10
>     |
>     D------|--Y
> 
> Without VA, A would choose X as the exit point, D would choose Y. Now
> with VA, D is APR. D still chooses Y, but A doesn't carry a specific
> route and tunnels packets to D, and the packets now exit to Y.

Ok.

> 
> >> Section 4.3:
> >>  >    Likewise, routers can bootstrap VA by first bringing up the
> IGP,
> >> then
> >>  >    establish LSPs, then establish routes to all required sub-
> >> prefixes,
> >>  >    and then finally advertise VPs.
> >>
> >> Hmm, wouldn't delayed VP advertisement require non-APR routers to
> >> temporary install all the specific prefixes? If so, FIB overflow
> might
> >> occur. Some platforms react badly to such cases (i.e. overloading
> CPU,
> >> starving routing protocols and possibly crash), so it may
> destabilize
> >> the network.
> >
> > Very nice catch!  I think the only good way to fix this is to require
> that
> > all VA routers be statically configured with the complete set of VPs.
> It is
> > easy to conjure up scenarios where a router simply won't know all the
> VPs at
> > the point in time at which it needs to start loading up its FIB.  If
> the
> > router statically knows all the VPs, then it has a basis for deciding
> which
> > FIB entries to suppress, and avoiding FIB overflow.
> >
> 
> Hmm, now if both APRs and non-APR are statically configured with VPs,
> what's left to the proposed protocol extension?

Heh!  Will have to think about this.  But maybe in fact we don't need the
extension.  For instance, say an ISP wants to configure a new VP.  It would
first configure the APRs for that VP, which would start advertising the VP
route (without the new attribute, but with NO_EXPORT).  Subsequently, it
could reconfigure the non-APRs (one by one) so that they now know that the VP
is in fact a VP, and could start suppressing sub-prefixes...off-hand seems
ok...

PF

> 
> 
> > PF
> >
> >> --
> >> dg
> 
> 
> --
> dg

_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr