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

[Martin Vigoureux <[e-mail]>]

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