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

[Greg Mirsky <[e-mail]>]

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 <
[e-mail]> 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.

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

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

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


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