Re: [RTG-DIR] [Idr] RtgDir review: draft-ietf-idr-route-oscillation-stop-00

[Antoni Przygienda <[e-mail]>]

Uff, lost all the context after 5 months of having been on it.  Lez take it to the beer bar @ yokohama and you enlighten me. Some of the stuff you write I agree with, some I lost context && need reconstruction. I only hope that meantime no one shipped an 'almost-never-not-compare-med'  knob to complicate discussion further ;-) ...

--- tony


There are basically two types of people. People who accomplish things, and people who claim to have accomplished things. The first group is less crowded.<http://www.brainyquote.com/quotes/quotes/m/marktwain393535.html>
~~~ Mark Twain<http://www.brainyquote.com/quotes/quotes/m/marktwain393535.html>

From: Alvaro Retana (aretana) [mailto:[e-mail]]
Sent: Wednesday, October 07, 2015 1:42 PM
To: Antoni Przygienda; [e-mail]
Cc: [e-mail]; [e-mail]; idr wg ([e-mail])
Subject: Re: [Idr] RtgDir review: draft-ietf-idr-route-oscillation-stop-00

On 5/26/15, 9:36 PM, "Antoni Przygienda" <[e-mail]<mailto:[e-mail]>> wrote:

[Author hat on.]

Tony:

Hi!

It took me a while to get to this..

I just posted an update with clarifications that I think address your points.   Responses to your comments inline.   I'm just leaving in pieces where we have additional comments.

Thanks!

Alvaro.




Network Working Group                                          D. Walton
Internet-Draft                                          Cumulus Networks
Intended status: Standards Track                               A. Retana

PRZ> I would like to question whether this is a standards Track document ?
PRZ> It looks to me more BCP than Standards track. It relies on peers
PRZ> supporting on optional capability and then it only SHOULDs the
PRZ> intended behavior. In fact there is not a single normative MUST in
PRZ> the whole document.

I don't think you don't need MUSTs, or even any rfc2119 language for a document to be a standard.

Personally I don't think this is a BCP; it basically specifies how the MED oscillations can be resolved..so I think it should remain on the Standards Track.

Having said that, if the chairs/AD have any guidance they want us to follow, then we will.

. . .
   These paths can be advertised using the mechanism described in ADD-
   PATH [I-D.ietf-idr-add-paths] for advertising multiple paths.

PRZ> I suggest to indicate in the document that all routers in AD MUST be
PRZ> configured to behave consistently when comparing MEDs
PRZ> (i.e. always-compare-med, missing-as-worst and so on need to be
PRZ> consistent).
PRZ> There seems to me a hidden assumption
PRZ> in the document
PRZ> albeit likely obvious for the skilled in the art that
PRZ> always-compare-med is used here (and in fact the overall behavior
PRZ> simulates deterministic-MED?) but IMO it must be mentioned what the
PRZ> assumptions are. Especially for routers that want to the RRC but
PRZ> do NOT support add-path e.g.
PRZ> that they are sometimes employed to fix some of
PRZ> those issues and need to be considered.

>From the discussion in rfc3345 (where the oscillations are described), always-compare-med is actually ruled out because it defeats the purpose of setting the MED.  Missing-as-worst is the default from rfc4271..so we're not making any assumptions of what knobs are configured beyond the default.

OTOH, yes, deterministic-MED is pretty much what is described in section 4 (Advertise the Group Best Paths) as part of the solution.

I added some clarification on assumptions.

. . .


4.  Advertise the Group Best Paths

   The term neighbor-AS for a route refers to the neighboring AS from
   which the route was received.  The calculation of the neighbor-AS is
   specified in Sect. 9.1.2.2 of [RFC4271], and Section 7.2 of
   [RFC5065].  By definition the MED is comparable only among routes
   with the same neighbor-AS.

PRZ> We all know this can be violated by vendor specific configs and
PRZ> merits mentioning as reference to 4456 again since this is a very
PRZ> 'practical deployment'

It must be late..I'm missing the reference to 4456 when talking about changes in the default behavior.

PRZ> targeted draft. In fact this draft should reference how two best
PRZ> routes to same prefix via two different ASes (two group best paths
PRZ> to same prefix) should be resolved or ECMP'ed.

I know that many implementations support that type of ECMP.  However, that is not an issue specific to this draft or even ADD-PATH.

If we (the WG) ever wanted to document that internal behavior (similar to just regular ECMP) it should be in a separate draft.

There is no change to the resolution (finding the bestpath) of two group best paths.


. . .

 PRZ> This needs specification WHAT is advertised to the peers not supporting
PRZ> add-path? if we follow today's behavior, it would be any
PRZ> of the best-group paths broken on IGP metric.
PRZ> I think it is worth mentioning that if ANY of the involved RRs does
PRZ> not support add-path, the solution COULD loop again using IGP as tie-breaker
PRZ> for routes from different ASes.
PRZ>
PRZ> Or is one of the restrictions this draft suggests
PRZ> that all RRs MUST be
PRZ> add-path capable ?

Yes, we're assuming that the solution can be deployed because all routers that need to support ADD-PATH. I think that assumption is clear in the text as it mentions several times that the solution is based on it.  We didn't look at partial deployments.

. . .