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

From: Alvaro Retana <[email-masked]>
Date: Tue, 17 Aug 2021 15:19:26 +0000

On July 21, 2021 at 7:42:42 PM, [email-masked] wrote:

Greg:

Hi!

Thanks for the update!!

I have some comments in-line.  I am also attaching (below) a review of
-06, which mostly contains minor issues and nits related to
new/updated text.

The main item I would like WG input on is the generalization of the
mechanism.  In short, bootstrapping the BFD session is the main focus
of this document; I don't see a reason to avoid generalizing its use
to other scenarios.  We already agree on the wider applicability --
the incremental changes needed to generalize the text is far less than
the process it will take to do it later.

Mike: as Shepherd/Chair, please start a conversation in the WG as
needed.  Please take a look at the discussion below.

Thanks!

Alvaro.

...
> Sender: AlvaroRetana
...
> This document specifies two things: (1) a Hello option to help the
> tail bootstrap the BFD session, and, (2) the actions that the tail
> takes when a failure is detected. The former is common to all cases,
> while the latter depends on the role of the head with respect to the
> tail. The actions are basically an acceleration of what would
> naturally happen (if BFD was not used and the failure detection was
> "slow"). Is this a fair characterization of the document?

GIM>> Yes, absolutely correct.

...
> Are there other cases that could use this mechanism to track? I can
> think of a couple of cases: monitor PIM neighbors that send Joins, RPF
> neighbors, Assert winners... As with the DR case, for example, these
> cases don't require actions beyond an acceleration. It would be ideal
> if the document could cover these cases, and possibly others, in a
> generic way -- I can't think of good phrasing with now, but I'm sure
> you can. ;-)

GIM>> I agree that the defined PIM Hello BFD Discriminator option can be used
GIM>> by not only PIM DR/BDR nodes. Indeed, there are other use cases where a
GIM>> faster detection will improve the convergence in the control plane and
GIM>> minimize the negative impact on the multicast data plane. These use
GIM>> cases may be covered in the future.

Maybe I'm missing something obvious, and would like to understand what. :-)

The Hello option helps the tail bootstrap a BFD session, correct?  If
so, there's nothing in that description about the function of the tail
(or the head).  The point that I'm trying to make above is that the
only thing that BFD is providing any use case is faster detection of a
failure (which is very significant, of course!), so regardless of the
application or function of the tail/head, the operation can be
generalized.  Is this not true?  What am I missing?

To be more specific, the description in §2.1 (Using P2MP BFD in PIM
DR/BDR Monitoring) is a generic description, and not one that only
applies to a DR/BDR.  In fact, the text says that any node "regardless
of its role, MAY become a head of a p2mp BFD session" -- which means
that it is up to the tail to monitor it or not.

The last two paragraphs in §2.1 do mention the DR/BDR function, but
they could easily be generalized:

OLD>
   If the tail detects a MultipointHead failure [RFC8562], it MUST
   delete the corresponding neighbor state.  If the failed head was the
   DR (or BDR), the DR (or BDR) election mechanism in [RFC7761] or
   [I-D.ietf-pim-dr-improvement] is followed.

   If the head ceases to include the BFD Discriminator PIM Hello option
   in its PIM-Hello message, tails MUST close the corresponding
   MultipointTail BFD session.  Thus the tail stops using BFD to monitor
   the head and reverts to the procedures defined in [RFC7761] and
   [I-D.ietf-pim-dr-improvement].

NEW>
   If the tail detects a MultipointHead failure [RFC8562], it MUST
   delete the corresponding neighbor state.  If the head ceases to
   include the BFD Discriminator PIM Hello option in its PIM-Hello
   message, tails MUST close the corresponding MultipointTail BFD
   session.  In both cases, the tail continues to follow the
   specification related to the function of the head.

GIM>> As I think of it, one aspect would be homogeneity of p2mp BFD
GIM>> capability throughout the domain. In other words, what happens if some
GIM>> PIM nodes don't support the BFD Discriminator option and do not use
GIM>> p2mp BFD? What their slow (regular) convergence impact other nodes? But
GIM>> that, I think, is for further discussion, work. Would you agree?

I don't.

In fact, this is a very important deployment point that I had
overlooked.  If the support is not homogeneous, then some parts of the
network will converge (to the new state) faster than others. As with
unicast routing I think the main effect may be longer than expected
inconsistency, but not worst than without BFD.  The specific effect
relates to the use case...but because the deployment would be
localized (the DR and other routers on the LAN, for example), then any
negative effect of not supporting BFD (i.e. behaving as today) would
be localized.

Thank you for bringing this up.  If you consider the effect
significant for a specific case then please add a couple of sentences.

...
> 183 3.1. Using P2MP BFD in PIM DR/BDR Monitoring
...
> 229 If the head ceased to include BFD TLV in its PIM-Hello message, tails
> 230 MUST close the corresponding MultipointTail BFD session. Thus the
> 231 tail stops using BFD to monitor the head and reverts to the
> 232 procedures defined in [RFC7761] and [I-D.ietf-pim-dr-improvement].
...
> [major] Let me see if I understand: if the head doesn't use the BFD
> hello option anymore then the tail can gracefully stop using BFD.
> IOW, this way the BFD session does not expire and result in the DR
> being declared dead. Is that it?

GIM>> Yes, that is what we've intended - revert to "slow" detection.

> Given that the BFD session can be bootstrapped at the tail by manually
> configuring the corresponding discriminator, it seems that stopping
> the use of the BFD hello option may not result in the expected
> outcome. ???

GIM>> Yes, the head's My Discriminator value can be provisioned using the
GIM>> management plane. If that is the case, then I think this document is not
GIM>> applicable as the head and leaves use RFC 8562 without any additions.

The problem is that the text now says this:

   If the head ceases to include the BFD Discriminator PIM Hello option
   in its PIM-Hello message, tails MUST close the corresponding
   MultipointTail BFD session.  Thus the tail stops using BFD to monitor
   the head...

s/MUST/SHOULD   Provisioning the node is the exception, so the action
should be recommended and not required.

...
> 288 5. Security Considerations
...
> 299 An implementation that supports this specification SHOULD use a
> 300 mechanism to control the maximum number of BFD sessions that can be
> 301 active at the same time.
>
> [major] rfc8562 already requires "protective measures to prevent an
> infinite number of MultipointTail sessions from being created". It
> is then not needed for this document to recommend anything that is
> required elsewhere.

GIM>> Done.

??  You left the paragraph in.

> [major] What new security risks are introduced by the mechanism in
> this draft? In general, a rogue node can stop sending or delay BFD
> packets causing the tail to conclude that the head is down: the DR/BDR
> may change causing instability. I was surprised that rfc8562 did not
> mention the interaction risk, but rfc5880 already does. I feel that
> something needs to be mentioned specific to this document, even if it
> is highlighted that the risk is not new.

GIM>> Then that "rogue" node is the PIM DR/BDR, not a man-in-the-middle. And
GIM>> the attack is by making the p2mp BFD session expire on leaves while
GIM>> still periodically sending PIM Hello. AFAIK, since PIM DR/BDR election
GIM>> takes several Hello cycles, I don't think that that behavior will affect
GIM>> the multicast service. Perhaps I'm missing something, please advise.

Yes, the problem is that §2.1 says that the tail "MUST delete the
corresponding neighbor state".  This results in the DR not being
elected for a while.

I see what you mean: if the DR is still there then the election will
probably elect it again.  However, in the meantime the DR may not
think it is the DR anymore if the other routers in the LAN start a new
DR election. (??)   Please add the explanation (or something like it)
to make it clear that the risk is mitigated by the "double set of
hellos".

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.

...
> 310 7.1. Normative References
> ..
> 327 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
> 328 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
> 329 DOI 10.17487/RFC5881, June 2010,
> 330 .
>
> [minor] This reference can be Informative.

I know you moved it...but now that you added a reference to it in §2.3
then we need it to be Normative.  Sorry.

...
> [End of review -05.]

[Start -06]
[Line numbers from idnits.]

...
129	2.  BFD Discriminator PIM Hello Option
...
153	   If the value of the OptionLength field is not equal to 4, the BFD
154	   Discriminator PIM Hello option is considered malformed, and the
155	   receiver MUST stop processing PIM Hello options.  If the value of the
156	   My Discriminator field equals zero, then the BFD Discriminator PIM
157	   Hello option MUST be considered invalid, and the receiver MUST ignore
158	   it.  The receiver SHOULD log the notification regarding the malformed
159	   or invalid BFD Discriminator Hello option under the control of a
160	   throttling logging mechanism.

[major] "MUST stop processing PIM Hello options"

Stop in the current Hello message?  Should it ignore all the options
or just the ones after this one?  In all future Hello messages?

I haven't thought about this enough, but there could be an effect on
other functionality.  What is that effect?  I couldn't find anywhere a
general way to handle malformed Hello options -- did I miss it?

[nit] s/log the notification/log a notification

162	2.1.  Using P2MP BFD in PIM DR/BDR Monitoring
...
169	   If a PIM-SM router is configured to monitor the head by using p2mp
170	   BFD, referred to through this document as 'tail', receives PIM-Hello
171	   packet with BFD Discriminator PIM Hello option, the tail MAY create a
172	   p2mp BFD session of type MultipointTail, as defined in [RFC8562].

[minor] s/router is configured/router that is configured

[nit] s/receives PIM-Hello packet with BFD Discriminator/receives a
PIM-Hello packet with the BFD Discriminator

...
188	   If the head ceases to include the BFD Discriminator PIM Hello option
189	   in its PIM-Hello message, tails MUST close the corresponding
190	   MultipointTail BFD session.  Thus the tail stops using BFD to monitor
191	   the head and reverts to the procedures defined in [RFC7761] and
192	   [I-D.ietf-pim-dr-improvement].

[minor] "...MUST close the corresponding MultipointTail BFD session"

It might be a good thing adding that the PIM state is not affected by
this action.

194	2.2.  P2MP BFD in PIM DR Load Balancing

196	   [RFC8775] specifies the PIM Designated Router Load Balancing (DRLB)
197	   functionality.  Any PIM router that advertises the DRLB-Cap Hello
198	   Option can become the head of a p2mp BFD session, as specified in
199	   Section 2.1.  The head router administratively sets the
200	   bfd.SessionState to Up in the MultipointHead session [RFC8562] only
201	   if it is a Group Designated Router (GDR) Candidate, as specified in
202	   Sections 5.5 and 5.6 of [RFC8775].  If the router is no longer the
203	   GDR, then it MUST shut down following the procedures described in
204	   Section 5.9 [RFC8562].  For each GDR Candidate that includes BFD
205	   Discriminator option in its PIM Hello, the PIM DR creates a
206	   MultipointTail session [RFC8562].  PIM DR demultiplexes BFD sessions
207	   based on the value of the My Discriminator field and the source IP
208	   address.  If PIM DR detects a failure of one of the sessions, it MUST
209	   remove that router from the GDR Candidate list and immediately
210	   transmit a new DRLB-List option.

[] Continuing with my theme of generalizing this specification...
This section says everything that the last section already specified
in a generic way.  IOW, it is not really needed.

There is one thing that this paragraph adds: "If the router is no
longer the GDR, then it MUST shut down following the procedures
described in Section 5.9 [RFC8562]."   Yes, shutting down the BFD
session is important, but so is not including the BFD Discriminator
option in the Hello anymore.  As with everything else, this part can
also be generalized:

   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 MUST shut down
   the BFD session following the procedures described in Section 5.9
   [RFC8562].

212	2.3.  Multipoint BFD Encapsulation

214	   The MultipointHead of a p2mp BFD session when transmitting BFD
215	   Control packet:

[nit] s/packet/packets

217	      MUST set TTL or Hop Limit value to 255 (Section 5 [RFC5881]);

[major] "MUST set...RFC5881"   This action is already required in an
RFC that this document depends on, please don't specify the behavior
again.  I understand that rfc5682 can be used in multi-hop scenarios,
but rfc5881 is the source here.    s/MUST/must

...
222	3.  IANA Considerations
...
227	   +=============+================+===================+===============+
228	   | Value Name  | Length Number  | Name Protocol     | Reference     |
229	   +=============+================+===================+===============+
230	   | TBA         | 4              | BFD Discriminator | This document |
231	   |             |                | Option            |               |
232	   +-------------+----------------+-------------------+---------------+

[major] Please use the same field names as in the registry: Value,
Length, Name, Reference

[EoR -06]

---

From: Michael McBride <[email-masked]>
Date: Wed, 18 Aug 2021 05:53:25 +0000

Hi Greg,

Please consider either 1) dropping the "use-case" from the draft name and keep it a specific pim-bfd-p2mp solution and less generalized or 2) keeping the existing name and make it more generalized with more use cases as Alvaro suggests. 

I'll ping the bfd chairs and cc you to ensure they are in the loop.

Thanks,
mike

-----Original Message-----2021-02-04-Network TMT Meetings : https://efutureway.sharepoint.com/teams/NetworkLabTMT/Shared Documents/General/Network Lab TMT Meeting/February 4 2021 Meeting/2021-02-04-Network TMT Meetings.pptx?web=1G
From: pim <[email-masked]> On Behalf Of Alvaro Retana
Sent: Tuesday, August 17, 2021 8:19 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05

Greg:

Hi!

Thanks for the update!!

I have some comments in-line.  I am also attaching (below) a review of -06, which mostly contains minor issues and nits related to new/updated text.

The main item I would like WG input on is the generalization of the mechanism.  In short, bootstrapping the BFD session is the main focus of this document; I don't see a reason to avoid generalizing its use to other scenarios.  We already agree on the wider applicability -- the incremental changes needed to generalize the text is far less than the process it will take to do it later.

Mike: as Shepherd/Chair, please start a conversation in the WG as needed.  Please take a look at the discussion below.

Thanks!

Alvaro.

...
...

...
> generic way -- I can't think of good phrasing with now, but I'm sure 

GIM>> I agree that the defined PIM Hello BFD Discriminator option can be 
GIM>> used by not only PIM DR/BDR nodes. Indeed, there are other use 
GIM>> cases where a faster detection will improve the convergence in the 
GIM>> control plane and minimize the negative impact on the multicast 
GIM>> data plane. These use cases may be covered in the future.

The Hello option helps the tail bootstrap a BFD session, correct?  If so, there's nothing in that description about the function of the tail (or the head).  The point that I'm trying to make above is that the only thing that BFD is providing any use case is faster detection of a failure (which is very significant, of course!), so regardless of the application or function of the tail/head, the operation can be generalized.  Is this not true?  What am I missing?

To be more specific, the description in §2.1 (Using P2MP BFD in PIM DR/BDR Monitoring) is a generic description, and not one that only applies to a DR/BDR.  In fact, the text says that any node "regardless of its role, MAY become a head of a p2mp BFD session" -- which means that it is up to the tail to monitor it or not.

The last two paragraphs in §2.1 do mention the DR/BDR function, but they could easily be generalized:

OLD>

NEW>

GIM>> As I think of it, one aspect would be homogeneity of p2mp BFD 
GIM>> capability throughout the domain. In other words, what happens if 
GIM>> some PIM nodes don't support the BFD Discriminator option and do 
GIM>> not use p2mp BFD? What their slow (regular) convergence impact 
GIM>> other nodes? But that, I think, is for further discussion, work. Would you agree?

I don't.

In fact, this is a very important deployment point that I had overlooked.  If the support is not homogeneous, then some parts of the network will converge (to the new state) faster than others. As with unicast routing I think the main effect may be longer than expected inconsistency, but not worst than without BFD.  The specific effect relates to the use case...but because the deployment would be localized (the DR and other routers on the LAN, for example), then any negative effect of not supporting BFD (i.e. behaving as today) would be localized.

Thank you for bringing this up.  If you consider the effect significant for a specific case then please add a couple of sentences.

...
...
...

> the use of the BFD hello option may not result in the expected 

GIM>> Yes, the head's My Discriminator value can be provisioned using 
GIM>> the management plane. If that is the case, then I think this 
GIM>> document is not applicable as the head and leaves use RFC 8562 without any additions.

s/MUST/SHOULD   Provisioning the node is the exception, so the action should be recommended and not required.

...
...
> infinite number of MultipointTail sessions from being created". It is 
> then not needed for this document to recommend anything that is 
> required elsewhere.

GIM>> Done.

> is highlighted that the risk is not new.

GIM>> Then that "rogue" node is the PIM DR/BDR, not a man-in-the-middle. 
GIM>> And the attack is by making the p2mp BFD session expire on leaves 
GIM>> while still periodically sending PIM Hello. AFAIK, since PIM 
GIM>> DR/BDR election takes several Hello cycles, I don't think that 
GIM>> that behavior will affect the multicast service. Perhaps I'm missing something, please advise.

Yes, the problem is that §2.1 says that the tail "MUST delete the corresponding neighbor state".  This results in the DR not being elected for a while.

I see what you mean: if the DR is still there then the election will probably elect it again.  However, in the meantime the DR may not think it is the DR anymore if the other routers in the LAN start a new DR election. (??)   Please add the explanation (or something like it) to make it clear that the risk is mitigated by the "double set of hellos".

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.

...
> [minor] This reference can be Informative.

I know you moved it...but now that you added a reference to it in §2.3 then we need it to be Normative.  Sorry.

...

[Start -06]

...

Stop in the current Hello message?  Should it ignore all the options or just the ones after this one?  In all future Hello messages?

I haven't thought about this enough, but there could be an effect on other functionality.  What is that effect?  I couldn't find anywhere a general way to handle malformed Hello options -- did I miss it?

[nit] s/receives PIM-Hello packet with BFD Discriminator/receives a PIM-Hello packet with the BFD Discriminator

...

It might be a good thing adding that the PIM state is not affected by this action.

[] Continuing with my theme of generalizing this specification...
This section says everything that the last section already specified in a generic way.  IOW, it is not really needed.

There is one thing that this paragraph adds: "If the router is no longer the GDR, then it MUST shut down following the procedures described in Section 5.9 [RFC8562]."   Yes, shutting down the BFD session is important, but so is not including the BFD Discriminator option in the Hello anymore.  As with everything else, this part can also be generalized:

[nit] s/packet/packets

[major] "MUST set...RFC5881"   This action is already required in an RFC that this document depends on, please don't specify the behavior again.  I understand that rfc5682 can be used in multi-hop scenarios, but rfc5881 is the source here.    s/MUST/must

...

[major] Please use the same field names as in the registry: Value, Length, Name, Reference

[EoR -06]

_______________________________________________
pim mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C4991bb6e1f8e4635227908d9619273ce%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637648103926840231%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=nXv4LlXKLq4non3MhuQorFPGCxqfKTv59xLFOW0Gge4%3D&amp;reserved=0

---

From: <[email-masked]>
Date: Fri, 20 Aug 2021 08:37:35 +0800 (CST)

Hi Mike and Alvaro,

thank you for your comments and suggestions. We'll proceed with option 1. I have a question on the appropriate way of removing "use-case" from the name of the draft. Should we upload it as draft-ietf-pim-bfd-p2mp-00 and mark it as the replacement of draft-ietf-pim-bfd-p2mp-use-case?

What would you suggest?

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: MichaelMcBride
To: Alvaro Retana;gregory mirsky10211915;
CC: [email-masked];[email-masked];[email-masked];[email-masked];
Date: 2021/08/17 22:54
Subject: RE: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05

Hi Greg,

 
Thanks,
mike

Greg:
 
Hi!
 
Thanks for the update!!

 

Thanks!
 
Alvaro.

....
> Sender: AlvaroRetana
....

....

 

 
OLD> 

NEW> 

 
I don't.

....
> 183 3.1. Using P2MP BFD in PIM DR/BDR Monitoring
....
> 232 procedures defined in [RFC7761] and [I-D.ietf-pim-dr-improvement].
....

 

 

....
> 288 5. Security Considerations
....
 
GIM>> Done.

 

 

....

....

[Start -06]
 
....
....

 

....

....

 

 

 
[nit] s/packet/packets

....
....

[EoR -06]

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 20 Aug 2021 16:12:01 +0000

On August 18, 2021 at 1:53:29 AM, Michael McBride wrote:

Mike:

Hi!

I just saw Greg's response -- and it prompted me to go back to your
message.  In short, it is not clear to me what the difference is
between the options you proposed.

> Please consider either 1) dropping the "use-case" from the draft name and
> keep it a specific pim-bfd-p2mp solution and less generalized or 2) keeping
> the existing name and make it more generalized with more use cases as Alvaro
> suggests.

The name of the draft in unfortunate because it is a specification,
not an use case.  But it is just a name.  In the grand scheme of
things, the title of the document, which Greg has already changed to
"The Use of BFD for Multipoint Networks in PIM-SM", is much more
important.  IOW, changing the name won't solve anything at this point.
[OTOH, it will create confusion because a new name implies a new
document which hasn't been adopted, WGLC'd, etc..]

The part that I don't understand is what does "a specific pim-bfd-p2mp
solution" mean to you?   The way I read the document, there is only
one BFD p2mp solution for PIM: use the new Hello Option to bootstrap
the tail (rfc8562).  IOW, this is not an option -- and I don't see how
it could be "less generalized".   But I wonder if we're talking about
the same thing...?

The generalization part that I suggested to Greg, and where I would
appreciate more discussion, is as follows:

The document says that "any PIM-SM router, regardless of its role, MAY
become a head of a p2mp BFD session", so I believe there is no need to
constrain the application of BFD to monitoring the DR (as currently
written).  The action taken after a failure is detected is simply to
follow the base spec (rfc7761) -- there are no other changes!

As you can tell from the thread, we are in agreement that other use
cases are possible: monitor a downstream router that sent a Join, for
example.  Monitoring that router is within the scope of this document
because "any PIM-SM router, regardless of its role, MAY become a head
of a p2mp BFD session", and the resulting action is already specified
in rfc7761.

The net effect of generalizing the application of BFD is probably a
shorter document (no need to be specific about the DR, or any other
role) and maybe a couple of additional sentences about any
considerations related to a false positive (which will likely be the
result of misconfiguration or a rogue router).

I hope this is clearer -- sorry if it wasn't before.

Alvaro.

---

From: <[email-masked]>
Date: Tue, 24 Aug 2021 11:34:36 +0800 (CST)

Hi Alvaro,

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

next Join is received.

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?

Regards,

Greg Mirsky

Original Mail

Sender: AlvaroRetana
To: gregory mirsky10211915;
CC: [email-masked];[email-masked];[email-masked];[email-masked];
Date: 2021/08/17 08:19
Subject: Re:[pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05

Greg:
 
Hi!
 
Thanks for the update!!

 

Thanks!
 
Alvaro.

....
....

....

 

 
OLD> 

NEW> 

 
I don't.

....
....
....

 

 

....
....
 
GIM>> Done.

 

 

....

....

[Start -06]
 
....

 

 

....

 

 

 
[nit] s/packet/packets

....

[EoR -06]

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 25 Aug 2021 13:53:57 -0700

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

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: <[email-masked]>
Date: Thu, 26 Aug 2021 06:26:50 +0800 (CST)

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

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

Greg:
 
Hi!

Right.

 

 

Thanks!
 
Alvaro.