Moin,
> The intent is to document observed behavior and its consequences and
> to provide operational guidance. The references to prepending beyond
> 5 ASNs reflect commonly observed practice and outcomes rather than a
> hard threshold.
I mean, technically, I can get behind the 5. But there may-be-
cases(tm). And, i think, most really bad (as in: long) prepends are
more in the direction of "result of error".
> If there isn't consensus to publish as a BCP perhaps we should move
> it to Informational.
Even for informational, i currently find the document a bit confusing,
and skipping details sometimes, while being overly verbose other times.
For example, see Sec. 3.2:
"""
The percentage of the IPv4 table that is prepended-to-all is growing at
0.5% per year. The IPv6 table is growing slower at 0.2% per year. The
reasons for using prepend-to-all appears to be due to 1) the AS
forgetting to remove the prepending for one of its transit providers
when it is no longer needed and 2) the AS attempting to de-prioritize
traffic from transit providers over settlement-free peers and 3) there
are simply a lot of errors in BGP routing. Consider the prepended AS
path below:
64496 64501 64501 64510 64510 64501 64510 64501 64501 64510 64510
64501 64501 64510
The prepending here involves a mix of two distinct ASNs (64501 and
64510) with the last two digits transposed.
"""
1) is "operational error over time"; You won't fix that by telling
people not to do it.
2) I do this myself. Heck, i even do this in iBGP to signal to my DS
that a route comes from another PoP/region.
3) Yes, there are errors. However, my understanding is that the above
would include two major errors:
- Inconsistent(!) Prepending
- Split-Brain operation ingesting own routes and doing
redistribution based on prefix lists. Multiple weird times.
--
Also, for a BCP, Section 5 is missing BCP14 language, which I would
expect.
--
There is some guidance in Section 5 I like, and some I don't or am
missing. Also, I disagree with "Don't prepend ASNs that you don't own",
at least on import; I tend to prepend peers/upstreams for inbound that
I want to de-prioritize for outbound traffic, but use the neighbors ASN
then to not conflict with own prepending, e.g., in iBGP (to make intra-
AS PoP distance more transparent).
If I would have to condense Section 5, I would probably make it:
* To not expand AS_PATHs unnecessarily, operators SHOULD try to limit
prepends to a maximum of 5. Specific operational requirements MAY
necessitate longer prepends, especially internally, but then operators
SHOULD consider evaluating alternative options for TE, e.g., using BGP
(large) communities for traffic steering. If prepending is ineffective,
operators should consult their neighbors to assess whether these use TE
techniques that overwrite AS_PATH length as a selection criterion,
e.g., local preferences.
* Prepends on exported prefixes SHOULD only be used if these can have
an impact on traffic engineering, e.g., by multi-homed ASes. Single
homed ASes, even with multiple interconnected PoPs but with the same
transit provider in each SHOULD instead use the MED to steer traffic
with their single upstream.
* Operators MUST NOT have prepended another ASN than their own when
exporting prefixes in eBGP
* When operators import prefixes, they SHOULD only prepend their own
ASN on that session. However, depending on operational needs, they MAY
also use the peer's ASN <!-- I recon this may be controversial. ;-) -->
* Prepending MUST NOT lead to a loop in the AS_PATH of a prefix
--
The head part of the document is generally interesting, but I am not
sure whether he really adds to the document (in a BCP form); It rather
pulls the document on a tangent (hijacks) than dealing with some cases
where prepending can be held wrong.
With best regards,
Tobias
--
Univ.Prof. Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M [email protected]
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
