Internet-Drafts@xxxxxxxx <Internet-Drafts@xxxxxxxx> wrote:
> Title : The AS_HOPCOUNT Path Attribute
> Author(s) : T. Li, et al.
> Filename : draft-ietf-idr-as-hopcount-00.txt
> A URL for this Internet-Draft is:
> This document describes the AS hopcount path attribute for BGP. This
> is an optional, transitive path attribute that is designed to help
> limit the distribution of routing information in the Internet.
I thoroughly agree it should be optional transitive.
However, IMHO, we have an obligation to carefully consider the effects
of passing such an attribute through BGP speakers which don't recognize
Thus, I would much prefer that BGP speakers which recognize it
MUST NOT modify it -- their action should be limited to discarding the
NLRI based upon it.
This implies that it should contain a number which is the maximum
"path length" to which the NLRI is intended to propagate (with clear
definition of how to count this "path length". (I am agnostic on
whether this should equal AS_Path_Length, a count of different ASs
in the AS_Path, or something else entirely.)
Several other issues jump out at me:
- if there is to be any interaction with the NO_EXPORT community
attribute, we should carefully consider what is appropriate if the
NO_EXPORT is added after the AS_HOPCOUNT by a BGP speaker which
does not understand AS_HOPCOUNT.
- I'm slightly nervous about specifying the use of a 4-byte AS number
for BGP speakers which recognize AS_HOPCOUNT but not 4-byte AS numbers.
(At worst, though, this is a documentation issue.)
- The interaction with ATOMIC_AGGREGATE introduces a potential for some
issues. I quite understand the suggestion (it's not a MUST or SHOULD)
that the BGP speaker which introduces the AS_HOPCOUNT on a more-specific
NLRI put ATOMIC-AGGREGATE on the less-specific (without the AS_HOPCOUNT).
This does seem far safer than hoping some other BGP speaker will add it,
but there's a nagging doubt... I need to think about it more.
John Leslie <john@xxxxxxx>
Idr mailing list