[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
> 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.
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.
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.
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.
--
dg
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr