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

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

Ping!



On 5/23/16, 5:55 PM, "Alvaro Retana (aretana)" <[e-mail]> wrote:

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