Subject: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

From: Jeffrey Haas <[email-masked]>
Date: Tue, 4 Aug 2020 09:21:22 -0400

Working Group,

https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/

With apologies to the authors of BFD unsolicited, this document is past due
for Working Group Last Call.  The primary holdup on the document had been
last minute interaction with the RFC Editor with regard to its impact on the
BFD Yang model.  That work had completed some time ago.  (The Yang model,
however, is still lingering in MISREF state.)

This begins a last call period ending on 16 August.

Please send your comments to the mailing list whether you think this work is
ready to advance to the IESG or not.

-- Jeff & Reshad

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 4 Aug 2020 14:09:12 +0000

I've read the document (more than once) and support publication. It is a very simple BFD extension that simplifies deployment for the use cases enumerated in the "Introduction". 

I have one editorial comments: 

    Can you use phasing other than "initiates BFD control packets"? Perhaps, "initiates a new BFD session" or "begins sending BFD control packets"? 

Thanks,
Acee 

On 8/4/20, 9:10 AM, "Rtg-bfd on behalf of Jeffrey Haas" <[email-masked] on behalf of [email-masked]> wrote:

    Working Group,

    -- Jeff & Reshad

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 4 Aug 2020 17:45:11 +0000

Note that I also reviewed the YANG model for the extensions and don't have any issues. I was a little surprised to see two features but I can't see a better way to support global configuration AND/OR interface configuration. 

On 8/4/20, 10:09 AM, "Acee Lindem (acee)" <[email-masked]> wrote:

    Thanks,
    Acee 

        Working Group,

        -- Jeff & Reshad

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 4 Aug 2020 15:38:53 -0700

Dear Authors, et al.,
thank you for this well-written document. The mechanism described in the
draft is, in my opinion, useful and will save considerable efforts of the
operator. I have several questions and comments listed below:

   - Would the introduction of Unsolicited mode make this draft updating
   RFC 5881?
   - I didn't find any new values of BFD parameters that distinguish an
   unsolicited BFD session from the "classic single-hop" session. Do you think
   such a distinction could be useful to an operator?
   - In Section 2 stated

   On the passive side, the "unsolicited BFD" SHOULD be configured
   explicitly on an interface.

Does that imply that it MAY be configured node-wide? I think it would be
helpful to explicitly list the alternative option.

   - The fourth paragraph in Section 2 explains the handling of the first
   BFD control packet with Your Discriminator == 0, i.e., "it does not find an
   existing session with the same source address". What happens if the
   matching BFD session has been found?
   - A BFD session then created "based on the source address and
   destination address". Does that mean that there will be only one session
   with the same source address despite different destination addresses
   listed? If that is the case, could the BFD session be associated only with
   the source IP address of the received BFD control packet?
   - Between creating the BFD session (above) and

   It would
   then start sending the BFD Control packets and perform necessary
   procedure for bringing up, maintaining and tearing down the BFD
   session.

the local BFD system assigns My Discriminator to the session. Though it is
standard (RFC 5880) step, it might be useful to mention it.

   - Does "an established BFD session goes down" mean the state is Down and
   only Down or it also includes AdminDown state?
   - Furter stated

   the
   passive side would stop sending BFD Control packets and delete the
   BFD session created until the BFD Control packets is initiated by the
   active side again.

Probably some normative language be helpful to replace "would". And is the
stop applied immediately or after some grace period? The same question
about the deletion of BFD parameters and the FSM (probably this is left to
the implementation).

   - I'd admit got confused by the last paragraph in Section 2:

  The "Passive role" may change to the "Active role" when a local
   client registers for the same BFD session ...

Is it normative MAY? Does that mean that the unsolicited BFD cannot be in
passive role if it has a local client registered? But what I wonder is how
these transitions affect the operation. What happens if both BFD systems
are passive after changes in the clients registered? Or both are active?

   - Section 5.1 appears to only RECOMMEND setting TTL to 255 while RFC
   5881 says that TTL MUST be set to 255. What could be the case for not
   setting TTL to 255?
   - Nits:
      - s/"Discriminator"/"My Discriminator"
      - s/does not initiates/does not initiate/
      - s/"remote-discriminator"/"Your Discriminator"/

Regards,
Greg

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 Aug 2020 16:45:11 -0400

> This begins a last call period ending on 16 August.

The last call period has ended with a few comments from Greg and Raj that
should be addressed before we continue.

It'd also be helpful to hear from additional reviewers before we advance
this document.

-- Jeff

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 18 Aug 2020 03:35:49 +0000

Sorry to be tardy in responding...

As I stated almost 2 years ago when this draft was introduced:

a)The problem the draft is addressing is real and the solution useful

b)There are implementations which have already addressed this problem with no interoperability issues

c)I do not see that any changes have been made to the BFD protocol (e.g. RFC 5881)

Therefore, I think this should go forward - but as Informational.

   Les

> -----Original Message-----
> From: Rtg-bfd <[email-masked]> On Behalf Of Jeffrey Haas
> Sent: Monday, August 17, 2020 1:45 PM
> To: [email-masked]
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16
> August, 2020)
>

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 17 Aug 2020 20:44:44 -0700

I support this document with exactly same points Les’s made, it should progress as informational.

Regards,
Jeff

> On Aug 17, 2020, at 20:36, Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 18 Aug 2020 11:43:35 +0200

Hi Les,

While shifting to Informational would be perhaps ok protocol wise - isn't
it common practice in IETF that any draft (or at least most of them) which
define a YANG model is a Standards Track document ?

I hope you are not suggesting to split this one into two :).

Thx,
R.

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 18 Aug 2020 11:24:01 +0000

Indeed, draft-chen-bfd-unsolicited was informational and with the addition of the YANG module draft-ietf-bfd-unsolicted was changed to standards track.

Regards,
Reshad (no hat).

From: Rtg-bfd <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Tuesday, August 18, 2020 at 5:44 AM
To: "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

Hi Les,

While shifting to Informational would be perhaps ok protocol wise - isn't it common practice in IETF that any draft (or at least most of them) which define a YANG model is a Standards Track document ?

Thx,
R.

On Tue, Aug 18, 2020 at 5:36 AM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:
Sorry to be tardy in responding...

   Les

> From: Rtg-bfd <[email-masked]<mailto:[email-masked]>> On Behalf Of Jeffrey Haas
> To: rtg-bfd@ietf..org<mailto:[email-masked]>

---

From: tom petch <[email-masked]>
Date: Tue, 18 Aug 2020 16:25:55 +0000

From: Rtg-bfd <[email-masked]> on behalf of Jeffrey Haas <[email-masked]>
Sent: 17 August 2020 21:45

<tp>
As an additional reviewer (I think I have the right I-D:-)

The authors of the I-D have different affiliations to the editors of the YANG module

The Abstract/Introduction make no mention of a YANG module

There is no statement whether or not the module is NMDA compliant

The tree diagrams would be easier to validate if there some text, two or three sentences saying what they were trying to do, so that it could be checked whether or not the YANG does so

The tree diagrams could do with a reference to the RFC that explains the symbols

The titles used in the references for this I-D and to a lesser extent that of bfd-yang are not the titles I see for the I-D

YANG features should have a reference

revision 2019-06-26

Unless and until IANA considerations register a YANG module, there is no YANG module

security considerations mentions access control - I am unsure whether this is access control in general or YANG NACM or both

YANG Security is out of date - TLS 1.2? No way.

bfd-yang is MISREF because of mpls-base-yang which has just undergone a significant revision on the penultimate day of IETF Last Cal; probably ok but I plan to check later this week i.e. I advise not rushing into publication just yet

Tom Petchl

-- Jeff

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 18 Aug 2020 23:49:12 +0000

So, I won’t prolong what is now becoming an administrative discussion – except to say:

If the standards part of the document is the YANG model, then the draft should be renamed to indicate that it is a YANG document – and the description of the implementation behavior (Section 2 mostly) is just there as supportive context.
Otherwise, we have a case of the tail wagging the dog…

But, I leave it to others to decide what to do.

For me, the most important thing is that the content is good.
It might be good to have a statement in the draft that specifies no protocol changes are introduced – which I gather will be discussed as part of reviewing Greg’s comments.

   Les

From: Reshad Rahman (rrahman) <rrahman=[email-masked]>
Sent: Tuesday, August 18, 2020 4:24 AM
To: Robert Raszuk <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

Regards,
Reshad (no hat).

From: Rtg-bfd <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 18, 2020 at 5:44 AM
To: "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

Hi Les,

Thx,
R.

   Les

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 18 Aug 2020 18:01:14 -0700

IMHO - It isn’t right that presence of YANG defines document’  designation track. The common practice is that if the draft in question doesn’t require any protocol changes it should aim for Informational track (or BCP).
https://ietf.org/standards/process/informational-vs-experimental/

I’d rather have 2 separate documents. In general, given that YANG documents life cycle is quite different from that of protocol ones, it is perhaps a good practice to keep them separate.
I have included Martin (Routing AD for BFD)

Cheers,
Jeff
On Aug 18, 2020, 4:24 AM -0700, Reshad Rahman (rrahman) <rrahman=[email-masked]>, wrote:
> On Tue, Aug 18, 2020 at 5:36 AM Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:
> > quote_type
> > > To: rtg-bfd@ietf..org

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 19 Aug 2020 02:37:59 +0000

Hi Jeff and Les,

In general I  prefer to have the 2 together (here’s the protocol details and here’s how it’s managed), IMHO there’s benefit in having the 2 together since the YANG discussions are happening while we’re in the thick of the protocol discussions. I am actually not keen to end up with 2 docs, RFC XXX and RFC YYYY: YANG for XXXX with 2 different lifecycles, by the time the YANG is done people aren’t interested anymore because the protocol spec is done.  I brought this up some time ago with RTG AD and OPS AD, but I don’t think there was any conclusion.

In this specific case, I agree that there’s no protocol changes. So with 2 documents, are you proposing that the BFD spec should be informational and the YANG standards track? Or both informational? If it’s the latter, I’d rather they be in the same doc.

Regards,
Reshad ( no hat).
From: Jeff Tantsura <[email-masked]>
Date: Tuesday, August 18, 2020 at 9:01 PM
To: Robert Raszuk <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, "Reshad Rahman (rrahman)" <[email-masked]>, Martin Vigoureux <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

Cheers,
Jeff

Regards,
Reshad (no hat).

Hi Les,

Thx,
R.

c)I do not see that any changes have been made to the BFD protocol (e.g.. RFC 5881)

   Les

> > BFD Yang model.  That work had completed some time ago..  (The Yang
> model,

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 18 Aug 2020 20:08:45 -0700

An informational document that also has a  management/YANG part included would IMHO be the right outcome.

Regards,
Jeff

> On Aug 18, 2020, at 19:38, Reshad Rahman (rrahman) <[email-masked]> wrote:
> 
> 
> Hi Jeff and Les,
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 19 Aug 2020 05:44:30 +0000

I would prefer this as well – but if that violates some YANG process in the IETF please do make sure the draft clearly states that there are no protocol changes.

   Les

From: Jeff Tantsura <[email-masked]>
Sent: Tuesday, August 18, 2020 8:09 PM
To: Reshad Rahman (rrahman) <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Martin Vigoureux <[email-masked]>; [email-masked]
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

On Aug 18, 2020, at 19:38, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jeff and Les,

Regards,
Reshad ( no hat).
From: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 18, 2020 at 9:01 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>, "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>, Martin Vigoureux <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

Cheers,
Jeff
On Aug 18, 2020, 4:24 AM -0700, Reshad Rahman (rrahman) <rrahman=[email-masked]<mailto:rrahman=[email-masked]>>, wrote:

Regards,
Reshad (no hat).

Hi Les,

Thx,
R.

   Les

---

From: tom petch <[email-masked]>
Date: Wed, 19 Aug 2020 08:54:12 +0000

From: Rtg-bfd <[email-masked]> on behalf of Les Ginsberg (ginsberg) <ginsberg=[email-masked]>
Sent: 19 August 2020 06:44

<tp>
The YANG will need a Normative Reference to the other document, AFAICT, so making the other document Informative just introduces complications to the process,

Tom Petch

   Les

Hi Jeff and Les,

Regards,
Reshad ( no hat).

Cheers,
Jeff

Regards,
Reshad (no hat).

Hi Les,

Thx,
R.

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 19 Aug 2020 14:42:43 +0000

Tom -

I defer to chairs/AD in this matter - but here is my understanding of the distinction between Normative and Informative References.
From https://www.rfc-editor.org/policy.html#policy.refs 

" Within an RFC, references to other documents fall into two general categories: "normative" and "informative". Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. An informative reference is not normative; rather, it only provides additional information. For example, an informative reference might provide background or historical information. Informative references are not required to implement the technology in the RFC."

To me what this means is that it is the role of the referenced document in the document in which the reference appears which determines its category - not whether the referenced document itself is Informational or Standard.
So an Informational RFC could be necessary to understand a standards track document - in which case it SHOULD be a Normative Reference.
Similarly, a Standards RFC could be merely informational in its role as a reference and therefore be an Informative Reference.

Of course what Jeff and I are suggesting is that there be one document which includes both YANG and the descriptive text of the functionality and that this be Informational.
The more relevant question seems to be whether it is a violation of IETF Policy to have YANG defined in an Informational RFC.

??

   Les

> From: tom petch <[email-masked]>
> Sent: Wednesday, August 19, 2020 1:54 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>; Jeff Tantsura
> <[email-masked]>; Reshad Rahman (rrahman)
> <[email-masked]>
> Cc: [email-masked]
> From: Rtg-bfd <[email-masked]> on behalf of Les Ginsberg
> (ginsberg) <ginsberg=[email-masked]>
> I would prefer this as well – but if that violates some YANG process in the
> IETF please do make sure the draft clearly states that there are no protocol
> changes.
> 
> <tp>
> The YANG will need a Normative Reference to the other document, AFAICT,
> so making the other document Informative just introduces complications to
> the process,
> 
> Tom Petch
> 
> 
> 
> 
> 
>    Les
> 
> 
> Cc: Robert Raszuk <[email-masked]>; Les Ginsberg (ginsberg)
> <[email-masked]>; Martin Vigoureux <[email-masked]>;
> [email-masked]
> On Aug 18, 2020, at 19:38, Reshad Rahman (rrahman)
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
> Hi Jeff and Les,
> 
> In general I  prefer to have the 2 together (here’s the protocol details and
> here’s how it’s managed), IMHO there’s benefit in having the 2 together
> since the YANG discussions are happening while we’re in the thick of the
> protocol discussions. I am actually not keen to end up with 2 docs, RFC XXX
> and RFC YYYY: YANG for XXXX with 2 different lifecycles, by the time the
> YANG is done people aren’t interested anymore because the protocol spec is
> done.  I brought this up some time ago with RTG AD and OPS AD, but I don’t
> think there was any conclusion.
> 
> In this specific case, I agree that there’s no protocol changes. So with 2
> documents, are you proposing that the BFD spec should be informational and
> the YANG standards track? Or both informational? If it’s the latter, I’d rather
> they be in the same doc.
> 
> Regards,
> Reshad ( no hat).
> From: Jeff Tantsura
> <[email-masked]<mailto:[email-masked]>>
> To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>, "Les
> Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>,
> "Reshad Rahman (rrahman)"
> <[email-masked]<mailto:[email-masked]>>, Martin Vigoureux
> <[email-masked]<mailto:[email-masked]>>
> IMHO - It isn’t right that presence of YANG defines document’  designation
> track. The common practice is that if the draft in question doesn’t require any
> protocol changes it should aim for Informational track (or BCP).
> I’d rather have 2 separate documents. In general, given that YANG
> documents life cycle is quite different from that of protocol ones, it is
> perhaps a good practice to keep them separate.
> On Aug 18, 2020, 4:24 AM -0700, Reshad Rahman (rrahman)
> <rrahman=[email-masked]<mailto:rrahman=40cisco.com@dmar
> c.ietf.org>>, wrote:
> 
> 
> Indeed, draft-chen-bfd-unsolicited was informational and with the addition
> of the YANG module draft-ietf-bfd-unsolicted was changed to standards
> track.
> 
> Regards,
> Reshad (no hat).
> 
> From: Rtg-bfd <[email-masked]<mailto:rtg-bfd-
> [email-masked]>> on behalf of Robert Raszuk
> <[email-masked]<mailto:[email-masked]>>
> To: "Les Ginsberg (ginsberg)"
> <ginsberg=[email-masked]<mailto:ginsberg=40cisco.com@dmar
> c.ietf.org>>
> While shifting to Informational would be perhaps ok protocol wise - isn't it
> common practice in IETF that any draft (or at least most of them) which
> On Tue, Aug 18, 2020 at 5:36 AM Les Ginsberg (ginsberg)
> <ginsberg=[email-masked]<mailto:[email-masked]
> >> wrote:
> > From: Rtg-bfd <[email-masked]<mailto:rtg-bfd-
> [email-masked]>> On Behalf Of Jeffrey Haas

---

From: tom petch <[email-masked]>
Date: Wed, 19 Aug 2020 15:03:43 +0000

<tp>
At the end

From: Les Ginsberg (ginsberg) <[email-masked]>
Sent: 19 August 2020 15:42

Tom -

<tp>
I agree with your characterisation of Normative and Informative.

With split documents, then it seems clear to me that there would be a Normative Reference from the YANG document to the non-YANG one since it is impossible to make sense of the YANG one without understanding the use of the BFD protocol. If the non-YANG one is Informational, then you have a downref from one to the other which is more work for the AD and IESG which I would seek to avoid.

I went through YANG and YANG Guidelines and there is no explicit statement that a Normative YANG module (which this one clearly is AFAICT) must be in a Standards Track I-D but there are plenty of places where that is implicit, the alternatives being e.g. the document of another SDO versus IETF Standards track with no consideration of IETF not on the Standards track so I think that a single Informational document is also more work for the AD to push through the IESG.

Which leaves a single Standards Track document as the best alternative IMHO with text to allay the concerns expressed here about the absence of changes to the protocol.

I would see Ops AD as the authority on this , the one who has to convince the IESG of the correctness of the WG decision, to make the presence of a YANG module the deciding factor; I cannot recall it arising before. YMMV

Tom Petch
.
??

   Les