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

["Murray S. Kucherawy" <[e-mail]>]

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