Re: [Idr] draft on virtual aggregation

[Paul Francis <[e-mail]>]

Dan, these are good comments.   My replies inline.

PF

> -----Original Message-----
> From: Daniel Ginsburg [mailto:[e-mail]]
> Sent: Wednesday, July 09, 2008 11:09 AM
> To: Paul Francis
> Cc: [e-mail]
> Subject: Re: [Idr] draft on virtual aggregation
> 
> 
> Paul,
> 
> I made another pass through the draft and I have few more comments, if
> you don't mind.
> 
> Section 3.2.2.2:
>  > The LOCAL_PREF attribute is optional.
> 
> A small nit. As per RFC4271, section 5.1.5, LOCAL_PREF is included in
> all iBGP updates, so it can't be optional.

Ok.

> 
>  >    4.  If a packet is received at the APR whose best match is the VP
>  >        (i.e. it matches the VP but not any sub-prefixes within the
> VP),
>  >        then the packet MUST be discarded (see Section 3.2.2.1).
> 
> Some ASes relay on default route to route some traffic while carrying
> [almost] full BGP table. One of notable examples is so called
> "disconnected backbone" setup. If virtual aggregation is implemented as
> described, it would break default route forwarding.

Good catch, we forgot about this case.  One observation here is that if the
router with the default is legacy, then it can probably run outside the scope
of this spec...that is, it doesn't make tunnels or anything...it just
defaults to the "backbone", which can be running VA.  Another observation is
that, if it is running VA, then it doesn't really need the default
approach...it can use VA to shrink its FIB (which has the advantage that it
can still advertise the full DFRT with its external peers).

I think nevertheless you can run VA and still have the default, though not
sure why you'd do this.  My understanding of disconnected backbone is that
you need to be pretty careful about which routers use the default....i.e.
only routers that connect to customers that themselves don't require the
complete DFRT, and don't transit traffic that isn't to or from said customer.
So as long as this is still the case, I'd think you could use a default route
in combination with VA, in which case the "MUST be discarded" clause is too
strict.  (Actually, if I think about it, it is probably unnecessarily strict
in the first place.)

> 
> Section 3.2.2.3:
>  >    The router MUST advertise the VP to its iBGP peers.  The router
> MUST
>  >    NOT advertise the VP to eBGP peers.  (This should go without
> saying,
>  >    since the Extended Communities T bit is set to be non-
> transitive.)
> 
> T-bit will only prevent extcommunity from propagating to eBGP
> neighbors.
> The prefix itself still will be advertised. I think NO_EXPORT should be
> always attached to VP as a safety measure.

You mean, the T-bit will cause the border router to strip the ext-community
attribute from the route, and then send the route over eBGP?  I guess that
makes sense.  So we definitely need the NO_EXPORT attribute as well.  Will
fix. 

> 
> 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...

> 
> 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.

PF

> 
> --
> dg

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr