Re: [bess] Murray Kucherawy's No Objection on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Murray,
thank you for the suggested text that makes our intention is crystal clear.
I've updated the text and used your text in the second place:
OLD TEXT:
   o  SHOULD delete the P2MP BFD session associated with the P-tunnel;
NEW TEXT:
   o  the P2MP BFD session associated with the P-tunnel MUST be deleted.
      The session MAY be deleted after some configurable delay, which
      should have a reasonable default.

And s/SHOULD/MAY/ in Section 4.2:
   When a PE receives a C-multicast route for a particular (C-S, C-G),
   and the RT carried in the route results in importing the route into a
   particular VRF on the PE, if the route carries the Standby PE BGP
   Community, then the PE that supports this specification performs as
   follows:

      when the PE determines (the use of the particular method to detect
      the failure is outside the scope of this document) that C-S is not
      reachable through some other PE (more details are in Section 4.3),
      the PE MAY install VRF PIM state corresponding to this Standby BGP
      C-multicast route (the result will be that a PIM Join message will
      be sent to the CE towards C-S, and that the PE will receive (C-S,
      C-G) traffic), and the PE MAY forward (C-S, C-G) traffic received
      by the PE to other PEs through a P-tunnel rooted at the PE.

Would these updates address your concerns?

Regards,
Greg

On Fri, Dec 18, 2020 at 6:09 PM Murray S. Kucherawy <[e-mail]>
wrote:

>
>
> On Thu, Dec 17, 2020 at 8:57 PM Greg Mirsky <[e-mail]> wrote:
>
>>
>> I can't quite parse the first sentence of Section 3.1.1.  Maybe this will
>>> help:
>>>
>>> OLD:
>>>
>>>    A condition to consider that the status of a P-tunnel is Up is that
>>>    the root of the tunnel, as determined in the x-PMSI Tunnel attribute,
>>>    is reachable through unicast routing tables.
>>>
>>> NEW:
>>>
>>>    When determining whether the status of a P-tunnel is Up, a condition
>>>    to consider is whether the root of the tunnel, as determined in the
>>>    x-PMSI Tunnel attribute, is reachable through unicast routing tables.
>>>
>> GIM>> Thank you for the suggested text, it is much clearer. I might
>> propose a small re-wording to get the following:
>> NEW TEXT:
>>
>> When determining if the status of a P-tunnel is Up,
>> a condition to consider is whether the root of the tunnel,
>> as specified in the x-PMSI Tunnel attribute, is reachable
>> through unicast routing tables.
>>
>> What do you think?
>>
>
> Yep, that's better.
>
>
>>> Section 3.1.2 has a similar concern.
>>>
>> GIM>> I agree and propose the following update:
>> OLD TEXT:
>>     A condition to consider a tunnel status as Up can be that the last-
>>    hop link of the P-tunnel is Up.
>> NEW TEXT:
>>    When determining if the status of a P-tunnel is Up, a condition to
>>    consider is whether the last-hop link of the P-tunnel is Up.
>>
>
> Looks good.
>
>
>>> Why is that a SHOULD and not a MUST in Section 3.1.6.1?
>>
>> GIM>> The thinking, as I recall, was that the operator might re-enable
>> P-tunnel tracking, and not deleting the p2mp BFD session(s) might make an
>> implementation to resume tracking faster. Though the gain might be
>> negligent for a single BFD session, but if the same PE is the root for
>> multiple multicast trees, such behavior might be useful. But thinking about
>> that now, we might give the same flexibility and still use MUST. Please
>> review the following update:
>> OLD TEXT:
>>   o  the P2MP BFD session SHOULD be deleted.
>> NEW TEXT:
>>    o  the P2MP BFD session MUST be deleted.  The session MAY be deleted
>>       after some of time.  If an implementation uses a timer to delay
>>       the cleanup, it MUST allow the configuration of the delay
>>       interval, and use a reasonable default value.
>>
>
> Taking my own run at it; either is fine:
>
> o the P2MP BFD session MUST be deleted.  The session MAY be deleted after
> some configurable delay, which should have a reasonable default.
>
>
>> Same question about
>>> 3.1.6.2,
>>
>> GIM>> I think that it was the same reasoning. Would applying the update
>> as above be helpful?
>>
>
> Sure.
>
>
>>
>>> and the ones in 4.2.
>>
>> GIM>> I think these two SHOULDs could have been MAYs but not MUSTs. In
>> fact, the text that follows uses MAY and then it is used to illustrate what
>> constitutes "cold root standby", "warm root standby, and "hot root
>> standby". The latter is the case when both SHOULD are followed.
>> Do you think that is reasonable?
>>
>
> My concern generally is just this:
>
> Or, if they are correctly SHOULDs, you might
>>> consider giving some guidance to the reader about when one might go about
>>> deviating from the advice given, since SHOULD offers a choice.
>>>
>>
> If you feel that your suggestion resolves that concern, I'm happy.
>
> -MSK
>