Re: grow: WGLC for draft-ietf-grow-bgp-med-considerations-02.txt

[Danny McPherson <[e-mail]>]

Pekka,
Good feedback, thanks for taking the time to review.

Comments inline.

-danny

On Sep 23, 2004, at 12:46 AM, Pekka Savola wrote:

> substantial
> -----------
>
>    If one transit provider uses hot potato routing and another uses 
> cold
>    potato, traffic between the two tends to be more symmetric.
>    Depending on the business relationships, if one provider has more
>    capacity or a significantly less congested backbone network, then
>    that provider may use cold potato routing.  An example of widespread
>    use of cold potato routing was the NSF funded NSFNET backbone and 
> NSF
>    funded regional networks in the mid 1990s.
>
> ==> this begs the question of "what about hot-potato - hot-potato or
> cold-potato -cold-potato".  It seems to be implicit that these are
> likely asymmetric, but that may not need to be the case, especially
> with the latter.  This should probably be spelled out.

I'll clean up the wording..

>    As a result of implementation inconsistencies and protocol revision
>    variances, many network operators today explicitly reset all MED
>    values on ingress to conform to their internal routing policies
>    (i.e., to include policy that requires that MED values of 0 and
>    2^32-1 NOT be used in configurations, whether the MEDs are directly
>    computed or configured), so as to not have to rely on all their
>    routers having the same missing-MED behavior.
>
> ==> I was slightly confused by this, esp. 'reset', and the text on MED
> values of 0 and 2^32-1.  The point just is that the network operators
> ensure to map a missing MED to MED=0 in ingress if they use MEDs at
> all (at least that's what we do -- I fail to see any reason to avoid
> MED=0, because it doesn't cause problems.  The missing MED does.).

And if they don't use MEDs, they does this implicitly by
setting all the MED values the same on ingress to the AS.
That was the point.  I'll look to clean it up.

>    Comparing MEDs between differing adjacent autonomous systems (which
>    will be discussed in later sections), or not utilizing MEDs at all,
>    significantly decreases the probability of introducing potential
>    route oscillation conditions into the network.
>
> ==> it should be clearer that comparing meds between different
> adjacent ASs is only needed for confederations, or...?

Could be confederation sub-ASes, or discrete ASes, if you know
what you're doing..

> ==> Actually, I think you should re-read the doc with 'comparing MEDs
> and ASs' in mind.  It seems that in different sections
> (implementation/protocol vs deployment) there are different kinds of
> advice what seems to be the best thing to do.  These probably need a
> bit aligning or at least some applicability if the recommendations to
> different people are different.

The recommendations to different people aren't different, but I
do understand your point.  I'll see if there's any better way
to align.

> 2.7.  Temporal Route Selection
>
>    Some implementations have had bugs which lead to temporal behavior 
> in
>    MED-based best path selection.  These usually involved methods used
>    to store the oldest route along with ordering routes for MED in
>    earlier implementations that cause non-deterministic behavior on
>    whether the oldest route would truly be selected or not.
>
> ==> is this still sufficiently relevant as-is ?

Yes, in deployed systems, very much so..

> 3.1.  Comparing MEDs Between Different Autonomous Systems
>
>    Although the MED was meant to only be used when comparing paths
>    received from different external peers in the same AS, many
>    implementations provide the capability to compare MEDs between
>    different autonomous systems as well.
>
> ==> this might also say that as the operators often use
> local-preference to select the external preferences (primary,
> secondary upstreams, peers, customers, etc.), using MED instead of
> local-pref would lead to a pretty inconsistent distribution of best
> routes as MED is compared only after the AS_PATH length.

All depends on your routing policy.  It does seem that most
operators seem to employ LOCAL_PREF as the primary path selection
attribute, but when it's equal, (which it very often is for similar
peer grops) they may even be using MEDs and not know it..
I'll spell something further out here.

>
> 5.  References
>
> ==> needs to be split to normative and informative.

OK..

> editorial
> ---------
>
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026.
>
> ==> update to the newer boilerplate..

Will do.

>
>    This document is a product of an individual.  Comments are solicited
>    and should be addressed to the author(s).
>
> ==> not really... :) just remove this ?

Yeah, that's from before we found a home in GROW.

>    The BGP MUTLI_EXIT_DISC (MED) attribute, formerly known as the
>
> ==> s/MUTLI/MULTI/

OK.

>
>    The BGP MUTLI_EXIT_DISC (MED) attribute, formerly known as the
>    INTER_AS_METRIC, is currently defined in section 5.1.4 of [BGP4], as
>    follows:
>
> ==> This is out-of-date (compared to -25).  Because the BGP draft
> might still change a bit, I'd rather remove the direct quote, but try
> to summarize it yourself someone, and provide a normative reference to
> the spec.
>
> The same applies to the next quote.

I'll look into these.

> ==> the mention of 'INTER_AS_METRIC' can probably be removed here as
> well.. it has been long.

> 1.2.  MEDs and Potatoes
>
> ==> that's a slightly unpopular way to spell a potato.

Opps, meant to fix this as well.  Done.

>    Comparing MEDs between differing adjacent autonomous systems (which
>    will be discussed in later sections),
>
> ==> it was in the previous section..., and later in sect 3.1 ? --
> please put in a more explicit pointer.

I'll fix..

>    Multiple unfeasible routes can be advertised in a single BGP Update
>    message.  In addition, one or more feasible routes can be advertised
>    in a single Update message so long as all prefixes share a common
>    attribute set.
>
>    The BGP4 protocol permits advertisement of multiple prefixes with a
>    common set of path attributes to be advertised in a single update
>    message, this is commonly referred to as "update packing".  When
>    possible, update packing is recommended as it provides a mechanism
>    for more efficient behavior in a number of areas, to include:
> [...]
>
> ==> there appears to be some amount of duplication of text with these
> paragraphs, and the justification that follows.

OK, i'll look at cleaning it up..

>
>   [MFN/Ixia Monitoring Project] Vijay to Provide Pointer.
>
> ==> vijay....?

Heh, yeah, still waiting on that :-)

God feedback, thanks Pekka.

-danny

_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/