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

[Les Ginsberg (ginsberg)]

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 
Sent: Tuesday, August 18, 2020 8:09 PM
To: Reshad Rahman (rrahman) 
Cc: Robert Raszuk ; Les Ginsberg (ginsberg) 
; Martin Vigoureux ; 
rtg-bfd@ietf.org
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 
August, 2020)

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) 
mailto:rrah...@cisco.com>> 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 
: YANG for  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 mailto:jefftant.i...@gmail.com>>
Date: Tuesday, August 18, 2020 at 9:01 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>, "Les Ginsberg 
(ginsberg)" mailto:ginsb...@cisco.com>>, "Reshad Rahman 
(rrahman)" mailto:rrah...@cisco.com>>, Martin Vigoureux 
mailto:martin.vigour...@nokia.com>>
Cc: "rtg-bfd@ietf.org" 
mailto:rtg-bfd@ietf.org>>
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 
August, 2020)

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) 
mailto:rrahman=40cisco@dmarc.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 mailto:rtg-bfd-boun...@ietf.org>> on 
behalf of Robert Raszuk mailto:rob...@raszuk.net>>
Date: Tuesday, August 18, 2020 at 5:44 AM
To: "Les Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Cc: "rtg-bfd@ietf.org" 
mailto:rtg-bfd@ietf.org>>
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 ?

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

Thx,
R.

On Tue, Aug 18, 2020 at 5:36 AM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
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 mailto:rtg-bfd-boun...@ietf.org>> On 
> Behalf Of Jeffrey Haas
> Sent: Monday, August 17, 2020 1:45 PM
> To: rtg-...@ietf..org
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16
> August, 2020)
>
> On Tue, Aug 04, 2020 at 09:21:22AM -0400, Jeffrey Haas wrote:
> > 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.
>
> The last call period has ended with a few comments from Greg and Raj that
> 

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

[Jeff Tantsura]

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)  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 
> : YANG for  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 
> Date: Tuesday, August 18, 2020 at 9:01 PM
> To: Robert Raszuk , "Les Ginsberg (ginsberg)" 
> , "Reshad Rahman (rrahman)" , Martin 
> Vigoureux 
> Cc: "rtg-bfd@ietf.org" 
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 
> 16 August, 2020)
>  
> 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) 
> , 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  on behalf of Robert Raszuk 
> 
> Date: Tuesday, August 18, 2020 at 5:44 AM
> To: "Les Ginsberg (ginsberg)" 
> Cc: "rtg-bfd@ietf.org" 
> 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 ? 
>  
> I hope you are not suggesting to split this one into two :). 
>  
> Thx,
> R.
>  
> On Tue, Aug 18, 2020 at 5:36 AM Les Ginsberg (ginsberg) 
>  wrote:
> 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  On Behalf Of Jeffrey Haas
> > Sent: Monday, August 17, 2020 1:45 PM
> > To: rtg-...@ietf..org
> > Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 
> > 16
> > August, 2020)
> >
> > On Tue, Aug 04, 2020 at 09:21:22AM -0400, Jeffrey Haas wrote:
> > > 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.
> >
> > 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

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

[Reshad Rahman (rrahman)]

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 
: YANG for  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 
Date: Tuesday, August 18, 2020 at 9:01 PM
To: Robert Raszuk , "Les Ginsberg (ginsberg)" 
, "Reshad Rahman (rrahman)" , Martin 
Vigoureux 
Cc: "rtg-bfd@ietf.org" 
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 
August, 2020)

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) 
, 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  on behalf of Robert Raszuk 

Date: Tuesday, August 18, 2020 at 5:44 AM
To: "Les Ginsberg (ginsberg)" 
Cc: "rtg-bfd@ietf.org" 
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 ?

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

Thx,
R.

On Tue, Aug 18, 2020 at 5:36 AM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
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 mailto:rtg-bfd-boun...@ietf.org>> On 
> Behalf Of Jeffrey Haas
> Sent: Monday, August 17, 2020 1:45 PM
> To: rtg-...@ietf..org
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16
> August, 2020)
>
> On Tue, Aug 04, 2020 at 09:21:22AM -0400, Jeffrey Haas wrote:
> > 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.
>
> 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

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

[Jeff Tantsura]

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) 
, 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  on behalf of Robert Raszuk 
> 
> Date: Tuesday, August 18, 2020 at 5:44 AM
> To: "Les Ginsberg (ginsberg)" 
> Cc: "rtg-bfd@ietf.org" 
> 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 ?
>
> I hope you are not suggesting to split this one into two :).
>
> Thx,
> R.
>
> On Tue, Aug 18, 2020 at 5:36 AM Les Ginsberg (ginsberg) 
>  wrote:
> > quote_type
> > 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  On Behalf Of Jeffrey Haas
> > > Sent: Monday, August 17, 2020 1:45 PM
> > > To: rtg-...@ietf..org
> > > Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited 
> > > (ending 16
> > > August, 2020)
> > >
> > > On Tue, Aug 04, 2020 at 09:21:22AM -0400, Jeffrey Haas wrote:
> > > > 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.
> > >
> > > 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

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

[Les Ginsberg (ginsberg)]

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) 
Sent: Tuesday, August 18, 2020 4:24 AM
To: Robert Raszuk ; Les Ginsberg (ginsberg) 

Cc: rtg-bfd@ietf.org
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 
August, 2020)

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 mailto:rtg-bfd-boun...@ietf.org>> on 
behalf of Robert Raszuk mailto:rob...@raszuk.net>>
Date: Tuesday, August 18, 2020 at 5:44 AM
To: "Les Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Cc: "rtg-bfd@ietf.org" 
mailto:rtg-bfd@ietf.org>>
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 ?

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

Thx,
R.

On Tue, Aug 18, 2020 at 5:36 AM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
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 mailto:rtg-bfd-boun...@ietf.org>> On 
> Behalf Of Jeffrey Haas
> Sent: Monday, August 17, 2020 1:45 PM
> To: rtg-...@ietf..org
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16
> August, 2020)
>
> On Tue, Aug 04, 2020 at 09:21:22AM -0400, Jeffrey Haas wrote:
> > 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.
>
> 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

Re: Conclusion of the discussion on draft-mirsky-bfd-mpls-demand?

[Jeffrey Haas]

Greg,

Thank you for your patience.

On Thu, Jul 30, 2020 at 09:00:38AM -0700, Greg Mirsky wrote:
> Dear All,
> I much appreciate it if you can share the conclusion of the discussion of
> the draft-mirsky-bfd-mpls-demand.
> 
> Regards,
> Greg

The BFD Working Group chairs and Area Director have reviewed
draft-mirsky-bfd-mpls-demand.  The chairs had originally issued a working group
adoption call without having read the document.  Upon review, it was
determined that the majority of the text in the draft mostly restated
existing BFD Demand mode procedure. 

The chairs apologize for not having done sufficient vetting prior to
starting the adoption process and causing the confusion that followed.

The majority of the draft covers a re-statement of existing BFD procedure
and obscures the potential request for normative protocol changes.  This
response is split into two sections: The first portion covers procedure that
is a restatement of RFC 5880 Demand behaviors with a few possible
non-intended variances.  The second portion covers a potential change to
BFD Demand behavior and may be reason to continue working group discussion.

It's noted that a likely motivation for this draft comes from the following
statement in RFC 5884, §6 "Session Establishment":

#   A BFD session is bootstrapped using LSP Ping.  This specification
#   describes procedures only for BFD asynchronous mode.  BFD demand mode
#   is outside the scope of this specification. 

While "outside the scope", the procedures for exercising Demand mode are
covered largely in detail in RFC 5880.

--

In the following response, ':' blockquotes are from
draft-mirsky-bfd-mpls-demand and '#' blockquotes are from the cited RFC.

The text of the document and the matching procedures from RFC 5880 follow:

: 3.  Use of the BFD Demand Mode
: 
:[RFC5880] defines that the Demand mode MAY be:
: 
:o  asymmetric, i.e. used in one direction of a BFD session;
: 
:o  switched to and from without bringing BFD session to Down state
:   through using a Poll Sequence.

RFC 5880 §6 "Demand Mode" reads:
#   Demand mode MAY be enabled or disabled at any time, independently in
#   each direction, by setting or clearing the Demand (D) bit in the BFD
#   Control packet, without affecting the BFD session state.  Note that
#   the Demand bit MUST NOT be set unless both systems perceive the
#   session to be Up (the local system thinks the session is Up, and the
#   remote system last reported Up state in the State (Sta) field of the
#   BFD Control packet).
#
#   When the transmitted value of the Demand (D) bit is to be changed,
#   the transmitting system MUST initiate a Poll Sequence in conjunction
#   with changing the bit in order to ensure that both systems are aware
#   of the change.

The poll sequence is defined in RFC 5880 §5 "The Poll Sequence":
#   A Poll Sequence consists of a system sending periodic BFD Control
#   packets with the Poll (P) bit set.  When the other system receives a
#   Poll, it immediately transmits a BFD Control packet with the Final
#   (F) bit set, independent of any periodic BFD Control packets it may
#   be sending (see section 6.8.7).  When the system sending the Poll
#   sequence receives a packet with Final, the Poll Sequence is
#   terminated, and any subsequent BFD Control packets are sent with the
#   Poll bit cleared.  A BFD Control packet MUST NOT have both the Poll
#   (P) and Final (F) bits set.

:For the case of BFD over MPLS LSP, ingress Label switching Edge
:Router (LER) usually acts as Active BFD peer and egress LER acts as
:Passive BFD peer.  The Active peer bootstraps the BFD session by
:using LSP ping.  Once the BFD session is in Up state the ingress LER
:that supports this specification MUST switch to the Demand mode by
:setting Demand (D) bit in its Control packet and initiating a Poll
:Sequence.  If the egress LER supports this specification it MUST
:respond with the Final (F) bit set in its BFD Control packet sent to
:the ingress LER and ceases further transmission of periodic BFD
:control packets to the ingress LER.

The procedure above is covered by core RFC 5880 procedures as above.  The
one item of interest here not part of the specification is "MUST switch".
Effectively, an optional procedure normally covered by configuration mode or
application profile is mandated by this document.

:In this state BFD peers MAY remain as long as the egress LER is in Up
:state.  The ingress LER MAY check liveness of the egress LER by
:setting the Poll flag.  The egress LER will respond by transmitting
:BFD control packet with the Final flag set.  If the ingress LER
:doesn't receive BFD packet with the Final flag from its peer after
:the predetermined period of time, default wait time 

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

[tom petch]

From: Rtg-bfd  on behalf of Jeffrey Haas 

Sent: 17 August 2020 21:45

On Tue, Aug 04, 2020 at 09:21:22AM -0400, Jeffrey Haas wrote:
> 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.

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.


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

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

[Reshad Rahman (rrahman)]

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  on behalf of Robert Raszuk 

Date: Tuesday, August 18, 2020 at 5:44 AM
To: "Les Ginsberg (ginsberg)" 
Cc: "rtg-bfd@ietf.org" 
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 ?

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

Thx,
R.

On Tue, Aug 18, 2020 at 5:36 AM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
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 mailto:rtg-bfd-boun...@ietf.org>> On 
> Behalf Of Jeffrey Haas
> Sent: Monday, August 17, 2020 1:45 PM
> To: rtg-...@ietf..org
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16
> August, 2020)
>
> On Tue, Aug 04, 2020 at 09:21:22AM -0400, Jeffrey Haas wrote:
> > 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.
>
> 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

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

[Robert Raszuk]

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.

On Tue, Aug 18, 2020 at 5:36 AM Les Ginsberg (ginsberg)  wrote:

> 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  On Behalf Of Jeffrey Haas
> > Sent: Monday, August 17, 2020 1:45 PM
> > To: rtg-bfd@ietf.org
> > Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited
> (ending 16
> > August, 2020)
> >
> > On Tue, Aug 04, 2020 at 09:21:22AM -0400, Jeffrey Haas wrote:
> > > 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.
> >
> > 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
>
>