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 your comments and the discussion. All helped making the
document better.

Regards,
Greg

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

> 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
>
> Le 2021-12-07 à 22:00, Alvaro Retana a écrit :
> > 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
> >>> 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.
> >
> > 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.
> >
>