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

[[e-mail]]

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: [e-mail] 
www.zte.com.cn






Original Mail



Sender: AlvaroRetana
To: gregory mirsky10211915;
CC: [e-mail];[e-mail];[e-mail];[e-mail];
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, [e-mail] 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.