Subject: Re: [pim] Martin Vigoureux's Discuss on draft-ietf-pim-bfd-p2mp-use-case-09: (with DISCUSS and COMMENT)

From: Martin Vigoureux <[email-masked]>
Date: Wed, 1 Dec 2021 14:47:40 +0100

Hi Greg,

thank you. Please see in-line.

regards,
martin

Le 2021-11-27 à 3:18, Greg Mirsky a écrit :
> Hi Martin,
> thank you for the review and comments. Please find my notes in-lined 
> below under the GIM>> tag. Attached is the diff highlighting all the 
> updates.
> 
> Regards,
> Greg
> 
> On Fri, Nov 26, 2021 at 6:14 AM Martin Vigoureux via Datatracker 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Martin Vigoureux has entered the following ballot position for
>     draft-ietf-pim-bfd-p2mp-use-case-09: Discuss
> 
>     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/blog/handling-iesg-ballot-positions/
>     for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/draft-ietf-pim-bfd-p2mp-use-case/
> 
> 
> 
>     ----------------------------------------------------------------------
>     DISCUSS:
>     ----------------------------------------------------------------------
> 
>     Hi,
> 
>     thank you for your work. I have two points I'd like to discuss with you:
> 
>     1/
>     You write:
>         If the value of the OptionLength field is not equal to 4, the BFD
>         Discriminator PIM Hello option is considered malformed, and the
>         receiver MUST stop processing PIM Hello options.
>     Do you mean ignore all other options that would be in the PIM Hello
>     message?
>     I rapidly skimmed through 7761 and could not find such requirement
>     nor an
>     indication that documents defining new Hello options would have to
>     define how
>     to treat options when at least one is malformed. It may be that I
>     simply failed
>     to find the relevant text in PIM specs but I'd nevertheless
>     appreciate if you
>     could elaborate a bit on this.
> 
> GIM>> The reason to stop processing PIM Hello options that may follow 
> the BFD Discriminator option was that if an option is malformed, then 
> parsing data that follows might be unpredictable.
Understood. That makes sense. But if it make sense here I guess it does 
for all Hello options. I'm surprised this is not in 7761.

> 
> 
>     2/
>     Twice you write that a PIM-SM router MAY/can become a head. First
>     time in 2nd
>     paragraph of 2.1, and the second time in 2.2. "become" gives a sense of
>     automation, meaning without human intervention, and this is apparently
>     confirmed by section 2.2 where becoming a head is driven by the node
>     becoming a
>     GDR. 
> 
> GIM>> In the course of changes in the network, a PIM-SM router can 
> become DR and, as a result, MultipointHead, because it was configured as 
> the eligible to be a DR/head. An operator chooses the DR_priority 
> assigned to the PIM-SM router.
> 
>     The issue I have is that 8562 is pretty explicit about the fact that the
>     transition to Up state for a head is administratively controlled.
>     You take
>     great care in reusing that word (The head router administratively
>     sets the
>     bfd.SessionState to Up in the MultipointHead session) but I'm not
>     sure this is
>     sufficient to make this an administratively driven action. Maybe
>     it's simply a
>     discussion about the meaning of "administratively", but according to the
>     understanding I have of this word (which is influenced by the
>     typical use of it
>     in router implementations), it seems to me that this document
>     departs from 8562. 
> 
> GIM>> My interpretation of the use "administratively" is closer to 
> "outside of BFD". Consider the following text from Section 5,3 RFC 8562:
>      MultipointHead sessions cannot fail (since they are controlled
>      administratively).
> Indeed, MultipointHead session cannot fail from BFD perspective as a 
> MultipointTail is prohibited from sending BFD Control packets to the 
> head. Thus, all changes in MultipointHead's BFD state machine are 
> outside the BFD system, i.e., administrative to BFD.
I agree with the outside of BFD aspect, but to me "administratively" 
goes beyond and implies "performed by a network administrator". 
According to your definition, anything could turn on or off 
MultipointHead BFD.
> 
> 
>     Thank you
> 
> 
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
> 
>     additionally, here are some minor comments:
> 
>         it precisely characterizes deployment scenarios for PIM-SM over
>     a LAN
>         segment.
>     What do you mean here? I couldn't find any mention of PIM-SM over a
>     LAN segment
>     in RFC8562.
> 
> GIM>> I agree, the wording is not clear. I propose the following update:
> OLD TEXT:
>     [RFC8562] extends the BFD base specification
>     [RFC5880] for multipoint and multicast networks, and it precisely
>     characterizes deployment scenarios for PIM-SM over a LAN segment.
> NEW TEXT:
>     [RFC8562] extends the BFD base specification
>     [RFC5880] for multipoint and multicast networks, which matches the
>     deployment scenarios for PIM-SM over a LAN segment.
> I hope that improves the text. What do you think?
ok with that, thanks.
> 
> 
>         HeadDiscriminator: equals the value of My Discriminator
>         ([RFC5880]) allocated by the head.
>     I would specify here that it MUST always be present and MUST NOT be
>     zero.
> 
>         The head MUST include the BFD Discriminator option in its Hello
>         messages, and it MUST include a 4-byte HeadDiscriminator with a
>     value
>         other than zero.
>     Should this more precisely be written as:
>         The head MUST include the BFD Discriminator PIM Hello option in its
>         PIM Hello messages, and it MUST include a 4-byte HeadDiscriminator
>         with a value other than zero.
>     If you implement the change I have suggested above then you could
>     remove the
>     second part of the sentence.
> 
> GIM>> In Section 2.1 the following text seems close to your suggestion:
>     The head MUST include the BFD Discriminator option in its Hello
>     messages, and it MUST include a 4-byte HeadDiscriminator with a value
>     other than zero.
> Do you consider the text in Section 2.1 is sufficient?
My point is exactly about that text, and my proposal was to make it more 
precise.

> 
> 
>         For the tail to
>         correctly demultiplex BFD [RFC8562], the source address, and My
>         Discriminator values of the BFD packets MUST be the same as those of
>         the HeadDiscriminator in the PIM Hello message.
>     This is not fully clear. Do you mean:
>         For the tail to
>         correctly demultiplex BFD [RFC8562], the source address and My
>         Discriminator of the BFD packets MUST be the same as the source
>         address and the HeadDiscriminator, respectively, of the PIM Hello
>         message.
> 
> GIM>> Thank you the suggestion. I've updated the draft accordingly.
> 
> 
>     s/The document/This document/
> 
> GIM>> Thank you. Done.
There is another instance in the Ack

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 7 Dec 2021 16:00:17 -0500

On December 1, 2021 at 8:48:00 AM, Martin Vigoureux wrote:

Martin/Greg:

Hi!

I took a look at the second DISCUSS point -- please see below.

...
> > 2/
> > Twice you write that a PIM-SM router MAY/can become a head. First time in
> > 2nd paragraph of 2.1, and the second time in 2.2. "become" gives a sense
> > of automation, meaning without human intervention, and this is apparently
> > becoming a GDR.
> > transition to Up state for a head is administratively controlled.  You
> > take great care in reusing that word (The head router administratively
> > sets the bfd.SessionState to Up in the MultipointHead session) but I'm not > > sure this is sufficient to make this an administratively driven action.
> > Maybe it's simply a discussion about the meaning of "administratively",
> > but according to the understanding I have of this word (which is
> > influenced by the typical use of it in router implementations), it seems
> > to me that this document departs from 8562.
> >

I typically interpret "administratively" the same way: some type of
explicit action (e.g., configuration) exists from the network
administrator.

Of the two cases you point out, the first one mentions configuration
by the operator, from §2.1:

   Note that any PIM-SM router, regardless of its role, MAY become a
   head of a p2mp BFD session.  To control the volume of BFD control
   traffic on a shared media segment, an operator should carefully
   select PIM-SM routers configured as a head of a p2mp BFD session.

The second case (§2.2), as Greg mentioned above, does assume an
indirect action: the operator determines which routers can become a
GDR (rfc8775).

   Any PIM router that advertises the DRLB-Cap Hello Option can become
   the head of a p2mp BFD session, as specified in Section 2.1.  The head
   router administratively sets the bfd.SessionState to Up in the
   MultipointHead session [RFC8562] only if it is a Group Designated Router
   (GDR) Candidate, as specified in Sections 5.5 and 5.6 of [RFC8775].

I believe that even though the action is not directly applied to the
BFD configuration, the conditional trigger results from an
administrative action.

This interpretation doesn't directly answer your concern about the
meaning of the "administratively" term in BFD.  As you pointed out,
this document reuses the term from rfc8562, but that document doesn't
provide more clarity.

So I checked the base BFD spec (rfc5880).  It introduces the term, but
it is also unclear about the expectations. :-(  The only additional
clue I found is this text from §6.8.16/rfc5880 (Administrative
Control):

   If signaling is received from outside BFD that the underlying path
   has failed, an implementation MAY administratively disable the
   session with the diagnostic Path Down.

This sentence is clear that the administrative action doesn't have to
come directly from the operator.   IOW, even if "administratively" is
not explicitly defined/scoped, this sentence indicates that the intent
of rfc5880 was to include indirect/conditional events.

What now?  I think that the lack of clarity in the use of
"administratively" should be pointed out to the bfd WG -- they can
then discuss and, if needed, clarify the terminology/intent.  I don't
think we should hold this document up.

Thanks!

Alvaro.

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 10 Dec 2021 16:47:56 +0100

Alvaro,

thanks. That paragraph from 5880 convinced me.
I've cleared my DISCUSS.

Greg, Thank you for the updates you did in response to my other points.

-m

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 10 Dec 2021 08:50:56 -0800

Hi Martin,
thank you for your comments and the discussion. All helped making the
document better.

Regards,
Greg

On Fri, Dec 10, 2021 at 7:48 AM Martin Vigoureux <[email-masked]>
wrote:

> >>> sets the bfd.SessionState to Up in the MultipointHead session) but I'm
> not > > sure this is sufficient to make this an administratively driven
> action.