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