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 review, comments, and helpful suggestions. Please find my
answers and notes below tagged by GIM>>.

Regards,
Greg

On Wed, Dec 16, 2020 at 9:48 PM Murray Kucherawy via Datatracker <
[e-mail]> wrote:

> Murray Kucherawy has entered the following ballot position for
> draft-ietf-bess-mvpn-fast-failover-13: No Objection
>
> 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-bess-mvpn-fast-failover/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I concur with Barry's point about the definitions in Section 2.2.
>
> 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?

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

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

Same question about
> 3.1.6.2,

GIM>> I think that it was the same reasoning. Would applying the update as
above be helpful?


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

> 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.
>
> I think in Sections 7.2 and 7.3, you don't need "this document" references
> for
> unassigned things.
>
GIM>> Thank you, updated per your suggestion.