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

From: David Meyer <[email-masked]>
Date: Wed, 15 Sep 2004 10:03:55 -0700

Folks

	This note starts the WG Last Call (WGLC) for comments on 
	draft-ietf-grow-bgp-med-considerations-02.txt, 
	"BGP MED Considerations". It can be found on 
	
	ftp://ftp.ietf.org/internet-drafts/draft-ietf-grow-bgp-med-considerations-02.txt

	Please review the document carefully, and send your
	feedback to the list.  Please also indicate whether or
	not you believe that this document is ready to go to the
	IESG. 

	This WGLC will end on 01 Oct 2004 at 1200 PDT (UTC/GMT-7). 

	Thanks,

	Dave & Geoff

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 23 Sep 2004 09:46:56 +0300 (EEST)

> 	not you believe that this document is ready to go to the

I don't believe this is yet ready to move forward, but possibly could
after a revision or two; in summary, I have two concerns:

 1) it seems that some topics may be worth revisiting at least to see 
if they are still valid.

 2) the editorial side needs a slight brush-up (including the removal
of direct quotes in section 1.1).

More in detail below.

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.

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

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

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

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.

5.  References

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

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

   This document is a product of an individual.  Comments are solicited
   and should be addressed to the author(s).

==> not really... :) just remove this ?

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

   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.

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

   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.

   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.

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

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Danny McPherson <[email-masked]>
Date: Mon, 27 Sep 2004 13:25:59 -0600

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

Comments inline.

-danny

> substantial

I'll clean up the wording..

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

> adjacent ASs is only needed for confederations, or...?

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

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

> ==> is this still sufficiently relevant as-is ?

Yes, in deployed systems, very much so..

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

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

OK..

> ==> update to the newer boilerplate..

Will do.

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

OK.

> The same applies to the next quote.

I'll look into these.

> ==> that's a slightly unpopular way to spell a potato.

Opps, meant to fix this as well.  Done.

> please put in a more explicit pointer.

I'll fix..

> paragraphs, and the justification that follows.

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

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

Heh, yeah, still waiting on that :-)

God feedback, thanks Pekka.

-danny