Subject: [Idr] Jari Arkko's Discuss on draft-ietf-idr-route-oscillation-stop-03: (with DISCUSS and COMMENT)

From: "Jari Arkko" <[email-masked]>
Date: Thu, 05 May 2016 02:55:56 -0700

Jari Arkko has entered the following ballot position for
draft-ietf-idr-route-oscillation-stop-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-route-oscillation-stop/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for writing this document on this important issue.

I want to recommend its approval as an RFC and will do so 
shortly, but a Gen-ART review from Paul Kyzivat 
inspired me to read the document, and I have 
some comments. I'm not necessarily looking for 
document changes, but I am looking for some responses 
to Paul's or my comments, to make sure we all agree
that we are doing this right.

Specifically,

> A detailed description of how these oscillations can occur
> can be found in [RFC3345]; the description of how a node would
> locally detect such condition is outside the scope of this document.

I am not an expert on this topic, but I'd like to understand the nature
of such detection algorithms. How hard problem is that? What is
required?
I'm not looking for specifying or even referring to the algorithm here,
but
it would be beneficial at least for this reader to understand the nature
of the class of solutions referred to here. Are solutions
algorithmically
computable? Heuristic? Dependent on specific configurations?
Vendor solutions exist but aren't documented.

> When the ADD-PATH Capability is also received from
> the IBGP peer with the "Send/Receive" field set to 1 (receive
> multiple paths) or 3 (send/receive multiple paths) for the same <AFI,
> SAFI>, then the following procedures shall be followed:
> 
> If the peer is a route reflection client, the route reflector SHOULD
> advertise to the peer the Group Best Paths (or the Available Paths)
> received from its non-client IBGP peers.  Depending on the
> configuration, the route reflector MAY also advertise to the peer the
> Group Best Paths (or the Available Paths) received from its clients.

I am picking this text excerpt as an example.

Like Paul, some of this language makes me slightly uncomfortable,
and it would be good to understand what the aim is. If the intent
is to describe a procedure that can be followed and fully specified,
the expectations on the text are different from an informative
description of the kinds of things an implementation could do.

In the above text, there's quite a lot of imprecision. That may
be fine, but I wanted to check that this is the case.

For instance, why is a "shall" (and in lowercase) followed by
a set of "SHOULD"s and "MAY"s? Is there any guidance on
when the "SHOULD"s should be followed? There seems to
be thinking behind, could that be documented? What kind
of configuration issues affect the decisions?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 5 May 2016 15:36:51 +0000

On 5/5/16, 5:55 AM, "Jari Arkko" <[email-masked]> wrote:

Jari:

Hi!

As explained in rfc3345, there are specific conditions when the
oscillation may happen: multi-tier RR/confederation + receiving MED from
more than one peer.  The oscillation itself is not hard to detect (simply
look for routes that constantly change), the confirmation that it is MED
oscillation requires at least realizing that the MED is changing with the
routes.

>of configuration issues affect the decisions?

Yes, I see what you mean.  I think that at the time we wrote the text we
were probably thinking in terms of "SHOULD" because this is one of the
options (Group Best Paths vs All the Paths), but within that option we can
be more precise.

We will work on clarifying and get back to you -- I'm traveling, so it
might take a couple of days.

Thanks!

Alvaro.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 5 May 2016 13:10:23 -0400

> might take a couple of days.

Thanks.

Jari

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 23 May 2016 21:55:31 +0000

On 5/5/16, 11:36 AM, "Alvaro Retana (aretana)" <[email-masked]> wrote:

Jari:

Hi!  Took me longer than I thought...

Please see below and let me know if you think it is clearer -- I'll then
include it in the next version.

Thanks!

Alvaro.

>might take a couple of days.

OLD>
5.1.  Route Reflection

   Depending on the configuration, for a particular <AFI, SAFI> a route
   reflector SHOULD include the <AFI, SAFI> with the "Send/Receive"
   field set to 2 (send multiple paths) or 3 (send/receive multiple
   paths) in the ADD-PATH Capability [I-D.ietf-idr-add-paths] advertised
   to an IBGP peer.  When the ADD-PATH Capability is also received from
   the IBGP peer with the "Send/Receive" field set to 1 (receive
   multiple paths) or 3 (send/receive multiple paths) for the same <AFI,
   SAFI>, then the following procedures shall be followed:

   If the peer is a non-client, the route reflector SHOULD advertise to
   the peer the Group Best Paths (or the Available Paths) received from
   its clients.

5.2.  Confederation

   Depending on the configuration, for a particular <AFI, SAFI> a
   confederation ASBR SHOULD include the <AFI, SAFI> with the "Send/
   Receive" field set to 2 (send multiple paths) or 3 (send/receive
   multiple paths) in the ADD-PATH Capability [I-D.ietf-idr-add-paths]
   advertised to an IBGP peer, and to a confederation external peer.
   When the ADD-PATH Capability is also received from the IBGP peer or
   the confederation external peer with the "Send/Receive" field set to
   1 (receive multiple paths) or 3 (send/receive multiple paths) for the
   same <AFI, SAFI>, then the following procedures shall be followed:

   If the peer is internal, the confederation ASBR SHOULD advertise to
   the peer the Group Best Paths (or the Available Paths) received from
   its confederation external peers.

   If the peer is confederation external, the confederation ASBR SHOULD
   advertise to the peer the Group Best Paths (or the Available Paths)
   received from its IBGP peers.

NEW>
5.1.  Route Reflection

   For a particular <AFI, SAFI> a route reflector MUST include the <AFI,
   SAFI> with the "Send/Receive" field set to 2 (send multiple paths) or
   3 (send/receive multiple paths) in the ADD-PATH Capability
   [I-D.ietf-idr-add-paths] advertised to an IBGP peer.  When the ADD-
   PATH Capability is also received from the IBGP peer with the "Send/
   Receive" field set to 1 (receive multiple paths) or 3 (send/receive
   multiple paths) for the same <AFI, SAFI>, then the following
   procedures apply:

   If the peer is a route reflection client, the route reflector MUST
   advertise to the peer the Group Best Paths (or the Available Paths)
   received from its non-client IBGP peers.  The route reflector MAY
   also advertise to the peer the Group Best Paths (or the Available
   Paths) received from its clients.

   If the peer is a non-client, the route reflector MUST advertise to
   the peer the Group Best Paths (or the Available Paths) received from
   its clients.

5.2.  Confederation

   For a particular <AFI, SAFI> a confederation ASBR MUST include the
   <AFI, SAFI> with the "Send/Receive" field set to 2 (send multiple
   paths) or 3 (send/receive multiple paths) in the ADD-PATH Capability
   [I-D.ietf-idr-add-paths] advertised to an IBGP peer, and to a
   confederation external peer.  When the ADD-PATH Capability is also
   received from the IBGP peer or the confederation external peer with
   the "Send/Receive" field set to 1 (receive multiple paths) or 3
   (send/receive multiple paths) for the same <AFI, SAFI>, then the
   following procedures apply:

   If the peer is internal, the confederation ASBR MUST advertise to the
   peer the Group Best Paths (or the Available Paths) received from its
   confederation external peers.

   If the peer is confederation external, the confederation ASBR MUST
   advertise to the peer the Group Best Paths (or the Available Paths)
   received from its IBGP peers.