Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
Jeff, Martin, Rob, Warren,
Any guidance on this? As mentioned below, I favour having the YANG model in the
same document. If we go that way, the question then is whether the document is
informational or not.
Regards,
Reshad (no hat).
On 2020-08-19, 11:04 AM, "tom petch" wrote:
At the end
From: Les Ginsberg (ginsberg)
Sent: 19 August 2020 15:42
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.
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
> -Original Message-
> From: tom petch
> Sent: Wednesday, August 19, 2020 1:54 AM
>
> From: Rtg-bfd on behalf of Les Ginsberg
> (ginsberg)
> Sent: 19 August 2020 06:44
>
> 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.
>
>
> 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
>
>
> 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 toget
Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
At the end From: Les Ginsberg (ginsberg) Sent: 19 August 2020 15:42 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. 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 > -Original Message- > From: tom petch > Sent: Wednesday, August 19, 2020 1:54 AM > > From: Rtg-bfd on behalf of Les Ginsberg > (ginsberg) > Sent: 19 August 2020 06:44 > > 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. > > > 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 > > > 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
RE: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
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 > -Original Message- > From: tom petch > Sent: Wednesday, August 19, 2020 1:54 AM > To: Les Ginsberg (ginsberg) ; Jeff Tantsura > ; Reshad Rahman (rrahman) > > Cc: rtg-bfd@ietf.org > Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 > August, 2020) > > From: Rtg-bfd on behalf of Les Ginsberg > (ginsberg) > Sent: 19 August 2020 06:44 > > 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. > > > 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 > > > 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>" b...@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 t
Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
From: Rtg-bfd on behalf of Les Ginsberg (ginsberg) Sent: 19 August 2020 06:44 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. 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 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>" 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>" 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<mailto: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 BF
RE: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
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>" 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>" 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<mailto: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 ha
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) 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)
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<mailto: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
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: > > 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)
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>" 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<mailto: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
Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
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)
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<mailto: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
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-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 > >
Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
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) > 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 >
RE: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
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
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
FWD: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
I requested additional internal review from my colleagues who work on Juniper's BFD implementation. Please find his comments attached. -- Jeff ---8<--- cut here --->8-- Date: Mon, 17 Aug 2020 16:11:05 -0400 From: Raj Chetan Boddireddy Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020) > On Aug 5, 2020, at 7:38 AM, Raj Chetan Boddireddy wrote: > > Hi Jeff, > > Please find comments below: > > > o When BFD is used to keep track of the "liveness" of the nexthop of > > static routes. Although only one side may need the BFD > > functionality, currently both sides need to be involved in > > specific configuration and coordination and in some cases static > > routes are created unnecessarily just for BFD. > (1) Unsolicited BFD may not be desired since we end-up running BFD detection > timers on both peers and ideal mechanism for this case would require running > detect timers only on the device tracking nexthop of the static route and > trigger the necessary repair when this fails. SBFD seems more apt for this > case. > > When the passive side receives a BFD Control packet from the active > > side with 0 as the "remote-discriminator", and it does not find an > > existing session with the same source address as in the packet and > > "unsolicited BFD" is allowed on the interface by local policy, it > > SHOULD then create a matching BFD session toward the active side > (2) Linklocal and unnumbers address can be spread across multiple interfaces, > existing session must be looked with both source-address and interface id to > uniquely identify a session IMO. > > > > procedure for bringing up, maintaining and tearing down the BFD > > session. If the BFD session fails to get established within certain > > specified time, or if an established BFD session goes down, 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. > (3) We could infer that a system participating in a passive role may also > seize sending BFD Down packets after the session transitions out of Up state. > In which case, the benefit of detecting one-way failures sooner will be lost. > If we could send only a select few packets to notify the peer of this > transition and we may need to wait for a predetermined duration during > teardown. New passive BFD session can be spawned only after this teardown > duration has expired. > > > > The "Passive role" may change to the "Active role" when a local > > client registers for the same BFD session, and from the "Active role > > " to the "Passive role " when there is no longer any locally > > registered client for the BFD session. > (4) When IGP protocol unsubscribes to a BFD session (in the presence of > unsolicited passive mode config), shouldn’t we handle this as an AdminDown? > Having a passive role may prevent this. > If the sessions transitions to a passive role, then we may create a > scenario where both end-points for the BFD session take the passive role. > Ex: > -R0 (IGP + Passive BFD) Active-role R1 (IGP + Passive > BFD)Active-role > -R0 (Passive BFD) Passive-role R1 (IGP + > Passive BFD)Active-role > At this point ideally we need R0 to send AdminDown to R1 which may not be the > case if it transitions to Passive role. > > -R0 (Passive BFD) Passive-role R1 (Passive > BFD) Passive-role > Furthermore both R0 and R1 may assume passive role and the session may lie in > this state until it flaps. > > > > o Limit the feature to specific interfaces, and to a single-hop BFD > > with "TTL=255" [RFC5082]. In addition make sure the source > > address of an incoming BFD packet belongs to the subnet of the > > interface from which the BFD packet is received. > (5) Restricting this feature only to interfaces with matching subnet will > restrict this feature for unnumbered interfaces and link-local addresses. > > Thanks & Regards, > Raj Chetan > ---8<--- cut here --->8--
Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
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 On Tue, Aug 4, 2020 at 6:10 AM 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. > > Please send your comments to the mailing list whether you think this work > is > ready to advance to the IESG or not. > > -- Jeff & Reshad > >
Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
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)" wrote: 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" 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. Please send your comments to the mailing list whether you think this work is ready to advance to the IESG or not. -- Jeff & Reshad
Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
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" 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. Please send your comments to the mailing list whether you think this work is ready to advance to the IESG or not. -- Jeff & Reshad
