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

["Alvaro Retana (aretana)" <[e-mail]>]

On 5/5/16, 11:36 AM, "Alvaro Retana (aretana)" <[e-mail]> 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.


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


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

   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.