Subject: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05

From: Alvaro Retana <[email-masked]>
Date: Fri, 10 Sep 2021 21:37:20 +0200

Greg:

Hi!

Please submit a new version — I’ll take a look at the details then.

Thanks!

Alvaro.

On September 9, 2021 at 8:09:24 PM, Greg Mirsky ([email-masked])
wrote:

Hi Alvaro,
I've updated the working version to follow your comments. I've removed
references to DR/BDR and, as a result, the reference to
draft-ietf-pim-dr-improvement. As you've pointed out in comments, a tail
detects the failure of the head and then follows procedures defined in RFC
7661 as if that was the failure in PIM Hello protocol. I've decided to
leave the section about the use of p2mp in PIM DR Load Balancing as that
mechanism is defined in RFC 8775, well after RFC 7661 was published.
Attached, please find the new working version of the draft and the diff
that highlights all changes.

I greatly appreciate your feedback.

Regards,
Greg

On Wed, Aug 25, 2021 at 3:27 PM <[email-masked]> wrote:

> Hi Alvaro,
>
> thank you for the clarification. I see your point much clearer now,
> notably regarding references to BDR's behavior. I'll take the time to
> update the draft accordingly and get back with the updated version. Many
> thanks for your patience and the most helpful suggestions.
>
> Regards,
>
> Greg Mirsky
>
>
> Sr. Standardization Expert
> 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D
> Institute/Wireline Product Operation Division
>
>
>
> E: [email-masked]
> www.zte.com.cn
> Original Mail
> *Sender: *AlvaroRetana
> *To: *gregory mirsky10211915;
> *CC: [email-masked];[email-masked];
> [email-masked];[email-masked];
> *Date: *2021/08/25 13:54
> *Subject: **Re:[pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05*
> On August 23, 2021 at 11:34:50 PM, [email-masked] wrote:
>
>
> Greg:
>
> Hi!
>
> > thank you for your review, comments, and suggestions. I'm working on
> > updating the document and preparing the -07 version. I have a question
>
> > related to the scope of the draft. You have identified the essential part of
> > the proposal -  a new PIM Hello option to bootstrap a p2mp BFD session.
>
> > Indeed, any PIM  router can use it for advertising its My Discriminator to
>
> > other PIM routers on the shared segment. Then, as I can imagine, depending
>
> > on the role of that PIM router and the configuration on each neighbor, the
> > state of the advertising PIM router can be monitored. After detecting the
> > failure of the monitored router, we can expect that the monitoring PIM
>
> > router will take the same actions as if the failure was detected according
> > to RFC 7761.
>
> Right.
>
>
>
> > Thus, it does appear that for all possible uses of p2mp BFD in PIM-SM, all
> > that is needed is the new PIM Hello option and reference to the
> > corresponding section in RFC 7761.
>
> In general, there's no need to point at specific sections.  In all
> cases the BFD timeout indicates a neighbor failure and rfc7761 is
> clear about what to do in that case.
>
>
>
> > But there might still be value in analyzing each case of using p2mp BFD in
>
> > PIM-SM separately (even as a small informational document), as you've noted
> > in:
> >
> > In the general case... If tracking the sender of a Join, for example,
> > the effect would be more significant: an outage would exist until the
> > next Join is received.
>
> Honestly, I think that's about the extent of the additional analysis:
> a sentence or two.  IOW, I don't think there's value in a separate
> document that would just cover that (specially when compared to the
> effort of going through the process, etc.).
>
>
>
>
> > Would you agree that the scope of this document includes the definition of
>
> > a new PIM Hello option BFD Discriminator to bootstrap a p2mp BFD session and
> > a description of using that option monitoring PIM DR/BDR as a use case
> > example?
>
> Well -- that's the point that I've been trying to make: the
> applicability is general, the additional considerations (if any) are
> minimal, etc..
>
> I would like the scope of this document to be the definition of the
> new Hello option + a general description of the applicability to PIM
> (all of PIM, not just the DR).   An example is ok.
>
> Just one more thing.  In my comments I keep ignoring the BDR because
> the documents that define it are not done yet and I would like to
> avoid holding up the publication of this draft.  Note that the general
> applicability description (if made general enough) would cover the BDR
> function as well -- after all the BDR is also a PIM router that others
> can monitor.
>
>
> If I'm still not being clear, I think we should plan on a f2f
> conversation.  Please take a look at my calendar:
> https://doodle.com/mm/alvaroretana/book-a-time
>
>
> Thanks!
>
> Alvaro.
>
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 10 Sep 2021 13:08:10 -0700

Hi Alvaro,
thank you. I've uploaded the new version
<https://datatracker.ietf.org/doc/html/draft-ietf-pim-bfd-p2mp-use-case>
that includes all updates.

Regards,
Greg

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 14 Sep 2021 18:39:42 +0000

On September 9, 2021 at 8:09:24 PM, Greg Mirsky wrote:

Greg:

Hi!

> 7661 as if that was the failure in PIM Hello protocol. I've decided to leave
> the section about the use of p2mp in PIM DR Load Balancing as that mechanism
> is defined in RFC 8775, well after RFC 7661 was published.

That's ok.

As I mentioned before, I think the part about the head not performing
the function it started with should be generalized into §2.1 -- here's
the text I'm suggesting as the penultimate paragraph:

   If the head is no longer serving the function that prompted it
   to be monitored, then it MUST cease including the BFD Discriminator
   PIM Hello option in its PIM-Hello message, and it SHOULD shut down
   the BFD session following the procedures described in Section 5.9
   [RFC8562].

I also still have a couple of items (see below) to talk about.  I am
starting the IETF LC, so you can take them as LC comments.

Thanks!

Alvaro.

(1) I think that this text in §2.1 is still problematic:

187	   If the head ceases to include the BFD Discriminator PIM Hello option
188	   in its PIM-Hello message, tails MUST close the corresponding
189	   MultipointTail BFD session without affecting the PIM state in any
190	   way.  Thus the tail stops using BFD to monitor the head and reverts
191	   to the procedures defined in [RFC7761].

The problem is that the BFD session may not have been started using
the PIM Hello Option -- maybe it was manually provisioned, for
example.  If that is the case then requiring (MUST) to close the
session ignores the manual configuration.  I think the action should
be recommended (SHOULD) instead.

(2) Security Considerations.  Let's add an introductory paragraph (or
at least a couple of sentences) to justify why there are no additional
security considerations.  Something following this structure:

   This document defines a way to accelerate the detection of a PIM
   failure by using BFD.  The operation of either protocol is not
   changed.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 14 Sep 2021 15:39:08 -0700

Hi Alvaro,
thank you for your feedback and suggestions. I'll start the new working
version and will update it based on your comments. Looking forward to
hearing from other LC reviewers.

Regards,
Greg

On Tue, Sep 14, 2021 at 11:39 AM Alvaro Retana <[email-masked]>
wrote:

> leave