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

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Wed, 16 Dec 2020 21:48:45 -0800

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.

Section 3.1.2 has a similar concern.

Why is that a SHOULD and not a MUST in Section 3.1.6.1?  Same question about
3.1.6.2, and the ones in 4.2.  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.

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 17 Dec 2020 20:57:43 -0800

Hi Murray,
thank you for the review, comments, and helpful suggestions. Please find my
answers and notes below tagged by GIM>>.

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/
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
GIM>> Thank you, updated per your suggestion.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Dec 2020 18:08:49 -0800

On Thu, Dec 17, 2020 at 8:57 PM Greg Mirsky <[email-masked]> wrote:

> GIM>> Thank you for the suggested text, it is much clearer. I might
> propose a small re-wording to get the following:
> NEW TEXT:
>

Yep, that's better.

>    consider is whether the last-hop link of the P-tunnel is Up.

Looks good.

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

> GIM>> I think that it was the same reasoning. Would applying the update as

Sure.

> Do you think that is reasonable?

My concern generally is just this:

>> deviating from the advice given, since SHOULD offers a choice.
If you feel that your suggestion resolves that concern, I'm happy.

-MSK

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 18 Dec 2020 18:31:57 -0800

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 <[email-masked]>
wrote:

>> GIM>> I think that it was the same reasoning. Would applying the update
>> as above be helpful?
>>
>
> Sure.
>
>
>>
>>> and the ones in 4.2.
>>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Dec 2020 18:49:45 -0800

Hi Greg,

Just to be clear, this is purely a suggestion on my part that might improve
the document.  It's not a DISCUSS, so you're not obligated to indulge my
suggestions unless you think they're a worthwhile improvement.

Yes, those all look good to me.  For the 4.2 changes, I might suggest a
slightly different presentation:

NEW:

When a PE supporting this specification receives a C-multicast route for a
particular (C-S, C-G) for which all of the following are true:

o the RT carried in the route results in importing the route into a
particular VRF on the PE;

o the route carries the Standby PE BGP Community; and

o the PE determines (via a method of failure detection that is outside the
scope of this document) that C-S is not reachable through some other PE
(more details are in Section 4.3),

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

-MSK

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 18 Dec 2020 19:00:19 -0800

Hi Murray,
I feel that our discussion and changes helped to make the document clearer,
improved it.
And I like the manner you've re-worked text in Section 4.2. I'll use it.

Regards,
Greg

On Fri, Dec 18, 2020 at 6:49 PM Murray S. Kucherawy <[email-masked]>
wrote:

> Hi Greg,
>
> Just to be clear, this is purely a suggestion on my part that might
> improve the document.  It's not a DISCUSS, so you're not obligated to
> indulge my suggestions unless you think they're a worthwhile improvement.
>