Solutions for BGP Persistent Route Oscillation
draft-ietf-idr-route-oscillation-stop-04

The abstract and introduction should explain terms that are not commonly used (such as MED). BGP is a fine term to use without expansion.

Jon mitchell performed the opsdir review against 02

I have reviewed draft-ietf-idr-route-oscilliation-02 as part of the
Operational directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written with the
intent of improving the operational aspects of the IETF drafts. Comments
that are not addressed in last call may be included in AD reviews during
the IESG review.  Document editors and WG chairs should treat these
comments just like any other last call comments.

I found the document is clear and Ready w/Issues (primarily last
paragraph of this review).

This is a Informational draft from the IDR WG which describes the
necessary set of paths that have to be advertised in order to stop
BGP persistent route oscillation due to the MED attribute. 

Nits/suggestions:

Abstract - I don't think it's required to put caveats in the abstract,
this is well covered in the introduction and the text, consider removing
the last sentence parenthesized content.

Introduction - paragraph 2, strike the word clearly, s/"right"/necessary,
consider finishing last sentence with "to prevent the condition."

paragraph 3, first sentence - s/present/describe (easier to understand
due to only one definition)

paragraph 4, last sentence - s/is/are

Section 3 - consider renaming section header to "Advertise All the
Available Paths", even though all is somewhat redundant, it aligns with
previous text, internal text, and addpath-guidelines description.

Section 4 - paragraph 2 - I let this slip by the first time around but
tried to get them to soften the language about intra-cluster metrics
versus inter-cluster metrics in RFC 4456, but maybe it's worth softening
the language here about it.  An obvious alternative topology of using
larger intra-cluster metrics than inter-cluster metrics also is
sufficient to prevent route oscillation in the case where all BGP
NEXT_HOP's are coming from clients in the cluster (so that a large
intra-cluster link metric is included in the calculation in either
case).  This is sometimes deployed by providers that want to ensure
intra-cluster links are depreferenced versus WAN links for transit
traffic.  As simple of a sentence as, or any technique that prefers
intra-cluster to inter-cluster clients from the perspective of the same
clusters route reflector, would be sufficient to describe what is
necessary to prevent oscillation.  A reference to RFC 4451 may be useful
as well which also discusses MED deployment considerations.

Section 5 - add-path guidelines draft seems to be a useful reference
here that describes the various implementation approaches of ADD-PATH
including the two required to stop MED-induced oscillation?

Section 6, last sentence - as an operator, I disagree that what appears
to be a recommendation (am I misreading this sentence?) for greater
utilizing MED in the decision making process is being done here.  MED as
is described by this draft often causes more issues than it solves as
seems evident by the necessity of this draft.  In fact, if the
recommendation instead was to flatten MED to the same value everywhere
or compare MED's between AS's (an often deployed knob which is not IETF
documented AFAIK), you can rule out the case of MED-induced oscillation
w/o the necessary enhancements proposed by this document.  I believe
this is clearly spelled out in RFC3345 as well (see section 2.3 and
3.2).  It's not clear to me that this sentence is even factually
correct, and would cause a reduction of the number of group best paths
that need to be advertised, maybe this is making some wider assumption
of how MED's are assigned by the peer networks?

Cheers,

Jon

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

- abstract: use of so many acronyms here is a pity, be good
to expand or not use some of 'em

- intro: "MED attribute" is not mentioned in RFC4271, at
least not obviously enough to find with a grep;-) I had to
search for "multi" to figure out that you meant the
MULTI_EXIT_DISC thing, so maybe point at 5.1.4 in 4271 to
be nice?

- intro: It'd also be nice to provide a reference for the
"almost all of the known" claim for readers who aren't
familiar with such examples. (And I do mean "nice" and not
"necessary":-)