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

From: Martin Vigoureux via Datatracker <[email-masked]>
Date: Fri, 26 Nov 2021 06:14:41 -0800

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.

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

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.

   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.

   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.

s/The document/This document/

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 26 Nov 2021 18:18:26 -0800

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

> https://datatracker.ietf.org/doc/draft-ietf-pim-bfd-p2mp-use-case/
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.

> 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

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.

> Thank you
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?

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

>    address and the HeadDiscriminator, respectively, of the PIM Hello
GIM>> Thank you the suggestion. I've updated the draft accordingly.

> s/The document/This document/
GIM>> Thank you. Done.