BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional Forwarding Detection (S-BFD)
draft-ietf-idr-bgp-ls-sbfd-extensions-10

[Ballot comment]
Hi,

My only comment doesn't directly relate to the content in the document, but I would like to check whether any new YANG data nodes are required to configure, enable, or manage this extension and if so that they are being tracked by the WG chairs, or via another document so that they don't get forgotten.

And a +1 on 6 authors on a 7 page document seeming excessive.

Regards,
Rob

[Ballot comment]
Thanks to the authors for this specification.  I found the document to be clear concise and easy to understand - and had no issues adding this into our own LS implementation based on the document text.

[Ballot comment]
I have the same question about the size of the author list as others have raised.

A very minor suggestion: The current Section 1.1 really belongs as 2.1, IMHO.

[Ballot comment]
Thank you for this document -- I found it clear and easy to read.

Also, much thanks to Dan for the great OpsDir review - https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ls-sbfd-extensions-07-opsdir-lc-romascanu-2022-04-20/

[Ballot comment]
** Section 6.

The TLV introduced in this document is used to propagate IGP defined
  information ([RFC7883] and [RFC7883]).  The TLV represents
  information used to set up S-BFD sessions.  The IGP instances
  originating this information are assumed to support any required
  security and authentication mechanisms (as described in [RFC7883] and
  [RFC7883]) to prevent any security issues when propagating the
  information into BGP-LS.

-- I also share John Scudder’s reservation about this text.  In addition to his assessment that the second part of the last sentence over-promises, I believe the first part needs refinement as well.  I think were primarily talking about RFC5304 and RFC5310 so let’s also be precise about the security properties in question.  Perhaps:
NEW
The IGP instances originating this information are assumed to support the authentication mechanisms described in [RFC7883].

-- Editorial.  Why is [RFC7883] cited as “[RFC7883] and [RFC7883]”?

[Ballot comment]
Note that two styles of tables are used in the document. One uses:

          +------------+--------------------------+---------------+

The other uses:

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The authors should pick whichever one they prefer. If no strong preference, I encourage you to pick the first style :)

Note that the note about early code point should probably be removed.

[Ballot comment]
Thanks for working on this specification.

I will have to agree with some of the fellow ADs that number of authors is overwhelmingly large for such an small specification which clearly goes beyond the recommendation on the # of authors.

[Ballot comment]
Like Lars, I also found the author list to be fairly remarkable, almost one author per page. Many hands make light work, they say.

There is one sentence in the Security Considerations section that I think overpromises:

                                                  The IGP instances
  originating this information are assumed to support any required
  security and authentication mechanisms (as described in [RFC7883] and
  [RFC7883]) to prevent any security issues when propagating the
  information into BGP-LS.

"To prevent *any* security issues" is quite a promise! I'm sure it's not what you mean, I expect you mean something more like "and therefore the security properties of those underlying mechanisms are assumed". Probably if you just dropped everything from there on, so just ended with "[RFC7883])" the text would be complete and accurate.

: As required by RFC 4858, this is the current template for the Document
: Shepherd Write-Up. Changes are expected over time.
:
: This version is dated 1 November 2019.
:
: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
:    Standard, Informational, Experimental, or Historic)? Why is this the
:    proper type of RFC? Is this type of RFC indicated in the title page header?

Type of RFC:
  Proposed Standard.

Why:
  Proposes extensions to RFC7752 for a new BGP-LS code points for Node
  Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs.

: (2) The IESG approval announcement includes a Document Announcement
:    Write-Up. Please provide such a Document Announcement Write-Up. Recent
:    examples can be found in the "Action" announcements for approved
:    documents.  The approval announcement contains the following sections:

Technical Summary:
  Seamless Bidirectional Forwarding Detection (S-BFD) defines a simplified
  mechanism to use Bidirectional Forwarding Detection (BFD) with large
  portions of negotiation aspects eliminated, thus providing benefits such
  as quick provisioning as well as improved control and flexibility to
  network nodes initiating the path monitoring.  The link-state routing
  protocols (IS-IS and OSPF) have been extended to advertise the Seamless
  BFD (S-BFD) Discriminators.

  This draft defines an extension to the BGP Link-state address-family to
  carry the S-BFD Discriminators information in a new BGP-LS Attribute TLV
  called the S-BFD Discriminators TLV.

Working Group Summary:

: Was there anything in WG process that is worth noting?

No, some minor additions.

Please note that the revision of RFC7752 is progressing.

WG consensus:
  The document generated little interest outside of the usual interested
  parties for BGP-LS related technologies on the IDR list.  The extension
  defined in this document is simple, and appropriate signaling for the
  S-BFD mechanism state that is required.

  The shepherd is also a co-chair of the BFD Working Group and confirms that
  the extension is appropriate for that technology.

Document Quality:

Implementations at:
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-sbfd-extensions%20implementations
  [Note - only one implementation listed here at Nokia.
  Check with Huawei and Cisco for their implementations]

Personnel:
  Who is the Document Shepherd: Jeffrey Haas
  Who is the Responsible Area Director: Alvaro Retana

: (3) Briefly describe the review of this document that was performed by the
:    Document Shepherd.  If this version of the document is not ready for
:    publication, please explain why the document is being forwarded to the
:    IESG.

The document is of high quality and in need of only minor grammar or syntax
changes to utilize the terminology of dependent RFCs appropriately.

: (4) Does the document Shepherd have any concerns about the depth or breadth
:    of the reviews that have been performed?

No.  The document is clear.
There are 6 authors in the document, but each author provided
a portion of the writing and implementation details. 

: (5) Do portions of the document need review from a particular or from
:    broader perspective, e.g., security, operational complexity, AAA, DNS,
:    DHCP, XML, or internationalization? If so, describe the review that
:    took place.

This document was brought to the attention of the BFD Working Group during
its lifetime.  No formal request has been made to the BFD Working Group.
The shepherd is a co-chair of BFD and finds the encodings in this document
suitable for the use of the base S-BFD RFC.

Further review can be sought, if desired by the IESG.

: (6) Describe any specific concerns or issues that the Document Shepherd has
:    with this document that the Responsible Area Director and/or the IESG
:    should be aware of? For example, perhaps he or she is uncomfortable
:    with certain parts of the document, or has concerns whether there
:    really is a need for it. In any event, if the WG has discussed those
:    issues and has indicated that it still wishes to advance the document,
:    detail those concerns here.

The ordering of the Discriminators is of potential interest and concern as
it is under-specified.  Adding normative text addressing this concern has
the potential to have impact on existing deployments of this mechanism.

This issue was discussed during shepherd review.  It is agreed that the
documented behavior is consistent with that of the IGP extensions.

: (7) Has each author confirmed that any and all appropriate IPR disclosures
:    required for full conformance with the provisions of BCP 78 and BCP 79
:    have already been filed. If not, explain why?

Zhenbin Li
https://mailarchive.ietf.org/arch/msg/idr/R0T3U5AT5nG8BhOGotvEBwZosfQ/

Shunwan Zhuang
https://mailarchive.ietf.org/arch/msg/idr/gM8Y7TLdVZXzKk6LXRe37VNph3A/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/IosPDPgSqRSUGnwkAc9eP_d3MCg/

Sam Aldrin
https://mailarchive.ietf.org/arch/msg/idr/bH3X_poL4sy9gyGmBMTRGS3kVP8/

Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/idr/fM1PlfroxyWnLOlIvvBud2BWZ0k/

Greg Mirsky
https://mailarchive.ietf.org/arch/msg/idr/TUyhdR5Dqm_u-Ft420BI10CKB0Q/

: (8) Has an IPR disclosure been filed that references this document?
:    If so, summarize any WG discussion and conclusion regarding the IPR
:    disclosures.

No IPR.

: (9) How solid is the WG consensus behind this document?
:    Does it represent the strong concurrence of a few individuals, with
:    others being silent, or does the WG as a whole understand and agree
:    with it?

Normal active participants sent in support posts.

: (10) Has anyone threatened an appeal or otherwise indicated extreme
:      discontent?  If so, please summarise the areas of conflict in
:      separate email messages to the Responsible Area Director. (It should
:      be in a separate email because this questionnaire is publicly
:      available.)

No threats or discontent over this document.

: (11) Identify any ID nits the Document Shepherd has found in this
:      document.  (See http://www.ietf.org/tools/idnits/ and the
:      Internet-Drafts Checklist).  Boilerplate checks are not enough; this
:      check needs to be thorough. )

Nits are all related to document being published in the prior year. 
No other nits.

: (12) Describe how the document meets any required formal review criteria,
:      such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The IANA code point for the attribute defined in this document is vs. a
Specification Required registry and has passed requirements for early
review.


: (13) Have all references within this document been identified as either
:      normative or informative?

Yes.

Shepherd review of the current published document, version -04, might be
able to use a few additional informative references for clarity.

: (14) Are there normative references to documents that are not ready for
:    advancement or are otherwise in an unclear state?  If such normative
:    references exist, what is the plan for their completion?

No.

; (15) Are there downward normative references references (see RFC 3967)? If
:      so, list these downward references to support the Area Director in
:      the Last Call procedure.

No.

: (16) Will publication of this document change the status of any existing
:      RFCs?  Are those RFCs listed on the title page header, listed in the
:      abstract, and discussed in the introduction?  If the RFCs are not
:      listed in the Abstract and Introduction, explain why, and point to
:      the part of the document where the relationship of this document to
:      the other RFCs is discussed. If this information is not in the
:      document, explain why the WG considers it unnecessary.

No.

: (17) Describe the Document Shepherd's review of the IANA considerations
:      section, especially with regard to its consistency with the body of
:      the document. Confirm that all protocol extensions that the document
:      makes are associated with the appropriate reservations in IANA
:      registries. Confirm that any referenced IANA registries have been
:      clearly identified. Confirm that newly created IANA registries
:      include a detailed specification of the initial contents for the
:      registry, that allocations procedures for future registrations are
:      defined, and a reasonable name for the new registry has been
:      suggested (see RFC 8126).

IANA has provided an early registration for the code point required for this
document.  The registration remains appropriate and can be stably assigned
using this RFC-to-be as a reference.

: (18) List any new IANA registries that require Expert Review for future
:      allocations.  Provide any public guidance that the IESG would find
:      useful in selecting the IANA Experts for these new registries.

No new registries.  Early allocation on code point.

: (19) Describe reviews and automated checks performed by the Document
:      Shepherd to validate sections of the document written in a formal
:      language, such as XML code, BNF rules, MIB definitions, YANG modules,
:      etc.

This document includes none of these items for review.

: (20) If the document contains a YANG module, has the module been checked
:      with any of the recommended validation tools
:      (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax
:      and formatting validation?  If there are any resulting errors or
:      warnings, what is the justification for not fixing them at this time?
:      Does the YANG module comply with the Network Management Datastore
:      Architecture (NMDA) as specified in RFC8342?

No Yang modules at this time.

[Ballot comment]
The document has six authors, which exceeds the recommended author limit. Has
the sponsoring AD agreed that this is appropriate? (Especially since this
document is very short.)

-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3, paragraph 7
-      of 4 octets for each additional discriminator.
-      ^^
+      by 4 octets for each additional discriminator.
+      ^^

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-idr-bgp-ls-sbfd-extensions-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs registry on the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page located at:

https://www.iana.org/assignments/bgp-ls-parameters/

the temporary registration:

TLV Code Point: 1032
Description: S-BFD Discriminators TLV
IS-IS TLV/Sub-TLV:
Reference: [ RFC-to-be ]

will be made permanent and the reference changed to [ RFC-to-be ].

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-04-27):

From: The IESG
To: IETF-Announce
CC: aretana.ietf@gmail.com, draft-ietf-idr-bgp-ls-sbfd-extensions@ietf.org, idr-chairs@ietf.org, idr@ietf.org, jhaas@juniper.net, jhaas@pfrc.org, jie.dong@huawei.com, shares@ndzh.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (BGP Link-State Extensions for Seamless BFD) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'BGP Link-State Extensions for Seamless
BFD'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-04-27. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Seamless Bidirectional Forwarding Detection (S-BFD) defines a
  simplified mechanism to use Bidirectional Forwarding Detection (BFD)
  with large portions of negotiation aspects eliminated, thus providing
  benefits such as quick provisioning as well as improved control and
  flexibility to network nodes initiating the path monitoring.  The
  link-state routing protocols (IS-IS and OSPF) have been extended to
  advertise the Seamless BFD (S-BFD) Discriminators.

  This document defines extensions to the BGP Link-state address-family
  to carry the S-BFD Discriminators' information via BGP.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-sbfd-extensions/



No IPR declarations have been submitted directly on this I-D.

: As required by RFC 4858, this is the current template for the Document
: Shepherd Write-Up. Changes are expected over time.
:
: This version is dated 1 November 2019.
:
: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
:    Standard, Informational, Experimental, or Historic)? Why is this the
:    proper type of RFC? Is this type of RFC indicated in the title page header?

Type of RFC:
  Proposed Standard.

Why:
  Proposes extensions to RFC7752 for a new BGP-LS code points for Node
  Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs.

: (2) The IESG approval announcement includes a Document Announcement
:    Write-Up. Please provide such a Document Announcement Write-Up. Recent
:    examples can be found in the "Action" announcements for approved
:    documents.  The approval announcement contains the following sections:

Technical Summary:
  Seamless Bidirectional Forwarding Detection (S-BFD) defines a simplified
  mechanism to use Bidirectional Forwarding Detection (BFD) with large
  portions of negotiation aspects eliminated, thus providing benefits such
  as quick provisioning as well as improved control and flexibility to
  network nodes initiating the path monitoring.  The link-state routing
  protocols (IS-IS and OSPF) have been extended to advertise the Seamless
  BFD (S-BFD) Discriminators.

  This draft defines an extension to the BGP Link-state address-family to
  carry the S-BFD Discriminators information in a new BGP-LS Attribute TLV
  called the S-BFD Discriminators TLV.

Working Group Summary:

: Was there anything in WG process that is worth noting?

No, some minor additions.

Please note that the revision of RFC7752 is progressing.

WG consensus:
  The document generated little interest outside of the usual interested
  parties for BGP-LS related technologies on the IDR list.  The extension
  defined in this document is simple, and appropriate signaling for the
  S-BFD mechanism state that is required.

  The shepherd is also a co-chair of the BFD Working Group and confirms that
  the extension is appropriate for that technology.

Document Quality:

Implementations at:
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-sbfd-extensions%20implementations
  [Note - only one implementation listed here at Nokia.
  Check with Huawei and Cisco for their implementations]

Personnel:
  Who is the Document Shepherd: Jeffrey Haas
  Who is the Responsible Area Director: Alvaro Retana

: (3) Briefly describe the review of this document that was performed by the
:    Document Shepherd.  If this version of the document is not ready for
:    publication, please explain why the document is being forwarded to the
:    IESG.

The document is of high quality and in need of only minor grammar or syntax
changes to utilize the terminology of dependent RFCs appropriately.

: (4) Does the document Shepherd have any concerns about the depth or breadth
:    of the reviews that have been performed?

No.  The document is clear.

: (5) Do portions of the document need review from a particular or from
:    broader perspective, e.g., security, operational complexity, AAA, DNS,
:    DHCP, XML, or internationalization? If so, describe the review that
:    took place.

This document was brought to the attention of the BFD Working Group during
its lifetime.  No formal request has been made to the BFD Working Group.
The shepherd is a co-chair of BFD and finds the encodings in this document
suitable for the use of the base S-BFD RFC.

Further review can be sought, if desired by the IESG.

: (6) Describe any specific concerns or issues that the Document Shepherd has
:    with this document that the Responsible Area Director and/or the IESG
:    should be aware of? For example, perhaps he or she is uncomfortable
:    with certain parts of the document, or has concerns whether there
:    really is a need for it. In any event, if the WG has discussed those
:    issues and has indicated that it still wishes to advance the document,
:    detail those concerns here.

The ordering of the Discriminators is of potential interest and concern as
it is under-specified.  Adding normative text addressing this concern has
the potential to have impact on existing deployments of this mechanism.

This issue was discussed during shepherd review.  It is agreed that the
documented behavior is consistent with that of the IGP extensions.

: (7) Has each author confirmed that any and all appropriate IPR disclosures
:    required for full conformance with the provisions of BCP 78 and BCP 79
:    have already been filed. If not, explain why?

Zhenbin Li
https://mailarchive.ietf.org/arch/msg/idr/R0T3U5AT5nG8BhOGotvEBwZosfQ/

Shunwan Zhuang
https://mailarchive.ietf.org/arch/msg/idr/gM8Y7TLdVZXzKk6LXRe37VNph3A/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/IosPDPgSqRSUGnwkAc9eP_d3MCg/

Sam Aldrin
https://mailarchive.ietf.org/arch/msg/idr/bH3X_poL4sy9gyGmBMTRGS3kVP8/

Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/idr/fM1PlfroxyWnLOlIvvBud2BWZ0k/

Greg Mirsky
https://mailarchive.ietf.org/arch/msg/idr/TUyhdR5Dqm_u-Ft420BI10CKB0Q/

: (8) Has an IPR disclosure been filed that references this document?
:    If so, summarize any WG discussion and conclusion regarding the IPR
:    disclosures.

No IPR.

: (9) How solid is the WG consensus behind this document?
:    Does it represent the strong concurrence of a few individuals, with
:    others being silent, or does the WG as a whole understand and agree
:    with it?

Normal active participants sent in support posts.

: (10) Has anyone threatened an appeal or otherwise indicated extreme
:      discontent?  If so, please summarise the areas of conflict in
:      separate email messages to the Responsible Area Director. (It should
:      be in a separate email because this questionnaire is publicly
:      available.)

No threats or discontent over this document.

: (11) Identify any ID nits the Document Shepherd has found in this
:      document.  (See http://www.ietf.org/tools/idnits/ and the
:      Internet-Drafts Checklist).  Boilerplate checks are not enough; this
:      check needs to be thorough. )

Nits are all related to document being published in the prior year. 
No other nits.

: (12) Describe how the document meets any required formal review criteria,
:      such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The IANA code point for the attribute defined in this document is vs. a
Specification Required registry and has passed requirements for early
review.


: (13) Have all references within this document been identified as either
:      normative or informative?

Yes.

Shepherd review of the current published document, version -04, might be
able to use a few additional informative references for clarity.

: (14) Are there normative references to documents that are not ready for
:    advancement or are otherwise in an unclear state?  If such normative
:    references exist, what is the plan for their completion?

No.

; (15) Are there downward normative references references (see RFC 3967)? If
:      so, list these downward references to support the Area Director in
:      the Last Call procedure.

No.

: (16) Will publication of this document change the status of any existing
:      RFCs?  Are those RFCs listed on the title page header, listed in the
:      abstract, and discussed in the introduction?  If the RFCs are not
:      listed in the Abstract and Introduction, explain why, and point to
:      the part of the document where the relationship of this document to
:      the other RFCs is discussed. If this information is not in the
:      document, explain why the WG considers it unnecessary.

No.

: (17) Describe the Document Shepherd's review of the IANA considerations
:      section, especially with regard to its consistency with the body of
:      the document. Confirm that all protocol extensions that the document
:      makes are associated with the appropriate reservations in IANA
:      registries. Confirm that any referenced IANA registries have been
:      clearly identified. Confirm that newly created IANA registries
:      include a detailed specification of the initial contents for the
:      registry, that allocations procedures for future registrations are
:      defined, and a reasonable name for the new registry has been
:      suggested (see RFC 8126).

IANA has provided an early registration for the code point required for this
document.  The registration remains appropriate and can be stably assigned
using this RFC-to-be as a reference.

: (18) List any new IANA registries that require Expert Review for future
:      allocations.  Provide any public guidance that the IESG would find
:      useful in selecting the IANA Experts for these new registries.

No new registries.  Early allocation on code point.

: (19) Describe reviews and automated checks performed by the Document
:      Shepherd to validate sections of the document written in a formal
:      language, such as XML code, BNF rules, MIB definitions, YANG modules,
:      etc.

This document includes none of these items for review.

: (20) If the document contains a YANG module, has the module been checked
:      with any of the recommended validation tools
:      (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax
:      and formatting validation?  If there are any resulting errors or
:      warnings, what is the justification for not fixing them at this time?
:      Does the YANG module comply with the Network Management Datastore
:      Architecture (NMDA) as specified in RFC8342?

No Yang modules at this time.

: As required by RFC 4858, this is the current template for the Document
: Shepherd Write-Up. Changes are expected over time.
:
: This version is dated 1 November 2019.
:
: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
:    Standard, Informational, Experimental, or Historic)? Why is this the
:    proper type of RFC? Is this type of RFC indicated in the title page header?

Type of RFC:
  Proposed Standard.

Why:
  Proposes extensions to RFC7752 for a new BGP-LS code points for Node
  Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs.

: (2) The IESG approval announcement includes a Document Announcement
:    Write-Up. Please provide such a Document Announcement Write-Up. Recent
:    examples can be found in the "Action" announcements for approved
:    documents.  The approval announcement contains the following sections:

Technical Summary:
  Seamless Bidirectional Forwarding Detection (S-BFD) defines a simplified
  mechanism to use Bidirectional Forwarding Detection (BFD) with large
  portions of negotiation aspects eliminated, thus providing benefits such
  as quick provisioning as well as improved control and flexibility to
  network nodes initiating the path monitoring.  The link-state routing
  protocols (IS-IS and OSPF) have been extended to advertise the Seamless
  BFD (S-BFD) Discriminators.

  This draft defines an extension to the BGP Link-state address-family to
  carry the S-BFD Discriminators information in a new BGP-LS Attribute TLV
  called the S-BFD Discriminators TLV.

Working Group Summary:

: Was there anything in WG process that is worth noting?

No, some minor additions.

Please note that the revision of RFC7752 is progressing.

WG consensus:
  The document generated little interest outside of the usual interested
  parties for BGP-LS related technologies on the IDR list.  The extension
  defined in this document is simple, and appropriate signaling for the
  S-BFD mechanism state that is required.

  The shepherd is also a co-chair of the BFD Working Group and confirms that
  the extension is appropriate for that technology.

Document Quality:

Implementations at:
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-sbfd-extensions%20implementations
  [Note - only one implementation listed here at Nokia.
  Check with Huawei and Cisco for their implementations]

Personnel:
  Who is the Document Shepherd: Jeffrey Haas
  Who is the Responsible Area Director: Alvaro Retana

: (3) Briefly describe the review of this document that was performed by the
:    Document Shepherd.  If this version of the document is not ready for
:    publication, please explain why the document is being forwarded to the
:    IESG.

The document is of high quality and in need of only minor grammar or syntax
changes to utilize the terminology of dependent RFCs appropriately.

: (4) Does the document Shepherd have any concerns about the depth or breadth
:    of the reviews that have been performed?

No.  The document is clear.

: (5) Do portions of the document need review from a particular or from
:    broader perspective, e.g., security, operational complexity, AAA, DNS,
:    DHCP, XML, or internationalization? If so, describe the review that
:    took place.

This document was brought to the attention of the BFD Working Group during
its lifetime.  No formal request has been made to the BFD Working Group.
The shepherd is a co-chair of BFD and finds the encodings in this document
suitable for the use of the base S-BFD RFC.

Further review can be sought, if desired by the IESG.

: (6) Describe any specific concerns or issues that the Document Shepherd has
:    with this document that the Responsible Area Director and/or the IESG
:    should be aware of? For example, perhaps he or she is uncomfortable
:    with certain parts of the document, or has concerns whether there
:    really is a need for it. In any event, if the WG has discussed those
:    issues and has indicated that it still wishes to advance the document,
:    detail those concerns here.

The ordering of the Discriminators is of potential interest and concern as
it is under-specified.  Adding normative text addressing this concern has
the potential to have impact on existing deployments of this mechanism.

This issue was discussed during shepherd review.  It is agreed that the
documented behavior is consistent with that of the IGP extensions.

: (7) Has each author confirmed that any and all appropriate IPR disclosures
:    required for full conformance with the provisions of BCP 78 and BCP 79
:    have already been filed. If not, explain why?

Zhenbin Li
https://mailarchive.ietf.org/arch/msg/idr/R0T3U5AT5nG8BhOGotvEBwZosfQ/

Shunwan Zhuang
https://mailarchive.ietf.org/arch/msg/idr/gM8Y7TLdVZXzKk6LXRe37VNph3A/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/IosPDPgSqRSUGnwkAc9eP_d3MCg/

Sam Aldrin
https://mailarchive.ietf.org/arch/msg/idr/bH3X_poL4sy9gyGmBMTRGS3kVP8/

Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/idr/fM1PlfroxyWnLOlIvvBud2BWZ0k/

Greg Mirsky
https://mailarchive.ietf.org/arch/msg/idr/TUyhdR5Dqm_u-Ft420BI10CKB0Q/

: (8) Has an IPR disclosure been filed that references this document?
:    If so, summarize any WG discussion and conclusion regarding the IPR
:    disclosures.

No IPR.

: (9) How solid is the WG consensus behind this document?
:    Does it represent the strong concurrence of a few individuals, with
:    others being silent, or does the WG as a whole understand and agree
:    with it?

Normal active participants sent in support posts.

: (10) Has anyone threatened an appeal or otherwise indicated extreme
:      discontent?  If so, please summarise the areas of conflict in
:      separate email messages to the Responsible Area Director. (It should
:      be in a separate email because this questionnaire is publicly
:      available.)

No threats or discontent over this document.

: (11) Identify any ID nits the Document Shepherd has found in this
:      document.  (See http://www.ietf.org/tools/idnits/ and the
:      Internet-Drafts Checklist).  Boilerplate checks are not enough; this
:      check needs to be thorough. )

Nits are all related to document being published in the prior year. 
No other nits.

: (12) Describe how the document meets any required formal review criteria,
:      such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The IANA code point for the attribute defined in this document is vs. a
Specification Required registry and has passed requirements for early
review.


: (13) Have all references within this document been identified as either
:      normative or informative?

Yes.

Shepherd review of the current published document, version -04, might be
able to use a few additional informative references for clarity.

: (14) Are there normative references to documents that are not ready for
:    advancement or are otherwise in an unclear state?  If such normative
:    references exist, what is the plan for their completion?

No.

; (15) Are there downward normative references references (see RFC 3967)? If
:      so, list these downward references to support the Area Director in
:      the Last Call procedure.

No.

: (16) Will publication of this document change the status of any existing
:      RFCs?  Are those RFCs listed on the title page header, listed in the
:      abstract, and discussed in the introduction?  If the RFCs are not
:      listed in the Abstract and Introduction, explain why, and point to
:      the part of the document where the relationship of this document to
:      the other RFCs is discussed. If this information is not in the
:      document, explain why the WG considers it unnecessary.

No.

: (17) Describe the Document Shepherd's review of the IANA considerations
:      section, especially with regard to its consistency with the body of
:      the document. Confirm that all protocol extensions that the document
:      makes are associated with the appropriate reservations in IANA
:      registries. Confirm that any referenced IANA registries have been
:      clearly identified. Confirm that newly created IANA registries
:      include a detailed specification of the initial contents for the
:      registry, that allocations procedures for future registrations are
:      defined, and a reasonable name for the new registry has been
:      suggested (see RFC 8126).

IANA has provided an early registration for the code point required for this
document.  The registration remains appropriate and can be stably assigned
using this RFC-to-be as a reference.

: (18) List any new IANA registries that require Expert Review for future
:      allocations.  Provide any public guidance that the IESG would find
:      useful in selecting the IANA Experts for these new registries.

No new registries.  Early allocation on code point.

: (19) Describe reviews and automated checks performed by the Document
:      Shepherd to validate sections of the document written in a formal
:      language, such as XML code, BNF rules, MIB definitions, YANG modules,
:      etc.

This document includes none of these items for review.

: (20) If the document contains a YANG module, has the module been checked
:      with any of the recommended validation tools
:      (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax
:      and formatting validation?  If there are any resulting errors or
:      warnings, what is the justification for not fixing them at this time?
:      Does the YANG module comply with the Network Management Datastore
:      Architecture (NMDA) as specified in RFC8342?

No Yang modules at this time.

: As required by RFC 4858, this is the current template for the Document
: Shepherd Write-Up. Changes are expected over time.
:
: This version is dated 1 November 2019.
:
: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
:    Standard, Informational, Experimental, or Historic)? Why is this the
:    proper type of RFC? Is this type of RFC indicated in the title page header?

Type of RFC:
  Proposed Standard.

Why:
  Proposes extensions to RFC7752 for a new BGP-LS code points for Node
  Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs.

: (2) The IESG approval announcement includes a Document Announcement
:    Write-Up. Please provide such a Document Announcement Write-Up. Recent
:    examples can be found in the "Action" announcements for approved
:    documents.  The approval announcement contains the following sections:

Technical Summary:
  Seamless Bidirectional Forwarding Detection (S-BFD) defines a simplified
  mechanism to use Bidirectional Forwarding Detection (BFD) with large
  portions of negotiation aspects eliminated, thus providing benefits such
  as quick provisioning as well as improved control and flexibility to
  network nodes initiating the path monitoring.  The link-state routing
  protocols (IS-IS and OSPF) have been extended to advertise the Seamless
  BFD (S-BFD) Discriminators.

  This draft defines an extension to the BGP Link-state address-family to
  carry the S-BFD Discriminators information in a new BGP-LS Attribute TLV
  called the S-BFD Discriminators TLV.

Working Group Summary:

: Was there anything in WG process that is worth noting?

No, some minor additions.

Please note that the revision of RFC7752 is progressing.

WG consensus:
  The document generated little interest outside of the usual interested
  parties for BGP-LS related technologies on the IDR list.  The extension
  defined in this document is simple, and appropriate signaling for the
  S-BFD mechanism state that is required.

  The shepherd is also a co-chair of the BFD Working Group and confirms that
  the extension is appropriate for that technology.

Document Quality:

Implementations at:
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-sbfd-extensions%20implementations
  [Note - only one implementation listed here at Nokia.
  Check with Huawei and Cisco for their implementations]

Personnel:
  Who is the Document Shepherd: Jeffrey Haas
  Who is the Responsible Area Director: Alvaro Retana

: (3) Briefly describe the review of this document that was performed by the
:    Document Shepherd.  If this version of the document is not ready for
:    publication, please explain why the document is being forwarded to the
:    IESG.

The document is of high quality and in need of only minor grammar or syntax
changes to utilize the terminology of dependent RFCs appropriately.

There is one item being flagged as part of shepherd review in need of
discussion by the authors and Working Group - ordering of the Discriminators
in the new TLV.  The shepherd believes this detail will not take long to
resolve.

: (4) Does the document Shepherd have any concerns about the depth or breadth
:    of the reviews that have been performed?

No.  The document is clear.

: (5) Do portions of the document need review from a particular or from
:    broader perspective, e.g., security, operational complexity, AAA, DNS,
:    DHCP, XML, or internationalization? If so, describe the review that
:    took place.

This document was brought to the attention of the BFD Working Group during
its lifetime.  No formal request has been made to the BFD Working Group.
The shepherd is a co-chair of BFD and finds the encodings in this document
suitable for the use of the base S-BFD RFC.

Further review can be sought, if desired by the IESG.

: (6) Describe any specific concerns or issues that the Document Shepherd has
:    with this document that the Responsible Area Director and/or the IESG
:    should be aware of? For example, perhaps he or she is uncomfortable
:    with certain parts of the document, or has concerns whether there
:    really is a need for it. In any event, if the WG has discussed those
:    issues and has indicated that it still wishes to advance the document,
:    detail those concerns here.

The ordering of the Discriminators is of potential interest and concern as
it is under-specified.  Adding normative text addressing this concern has
the potential to have impact on existing deployments of this mechanism.

: (7) Has each author confirmed that any and all appropriate IPR disclosures
:    required for full conformance with the provisions of BCP 78 and BCP 79
:    have already been filed. If not, explain why?

Zhenbin Li
https://mailarchive.ietf.org/arch/msg/idr/R0T3U5AT5nG8BhOGotvEBwZosfQ/

Shunwan Zhuang
https://mailarchive.ietf.org/arch/msg/idr/gM8Y7TLdVZXzKk6LXRe37VNph3A/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/IosPDPgSqRSUGnwkAc9eP_d3MCg/

Sam Aldrin
https://mailarchive.ietf.org/arch/msg/idr/bH3X_poL4sy9gyGmBMTRGS3kVP8/

Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/idr/fM1PlfroxyWnLOlIvvBud2BWZ0k/

Greg Mirsky
https://mailarchive.ietf.org/arch/msg/idr/TUyhdR5Dqm_u-Ft420BI10CKB0Q/

: (8) Has an IPR disclosure been filed that references this document?
:    If so, summarize any WG discussion and conclusion regarding the IPR
:    disclosures.

No IPR.

: (9) How solid is the WG consensus behind this document?
:    Does it represent the strong concurrence of a few individuals, with
:    others being silent, or does the WG as a whole understand and agree
:    with it?

Normal active participants sent in support posts.

: (10) Has anyone threatened an appeal or otherwise indicated extreme
:      discontent?  If so, please summarise the areas of conflict in
:      separate email messages to the Responsible Area Director. (It should
:      be in a separate email because this questionnaire is publicly
:      available.)

No threats or discontent over this document.

: (11) Identify any ID nits the Document Shepherd has found in this
:      document.  (See http://www.ietf.org/tools/idnits/ and the
:      Internet-Drafts Checklist).  Boilerplate checks are not enough; this
:      check needs to be thorough. )

Nits are all related to document being published in the prior year. 
No other nits.

: (12) Describe how the document meets any required formal review criteria,
:      such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The IANA code point for the attribute defined in this document is vs. a
Specification Required registry and has passed requirements for early
review.


: (13) Have all references within this document been identified as either
:      normative or informative?

Yes.

Shepherd review of the current published document, version -04, might be
able to use a few additional informative references for clarity.

: (14) Are there normative references to documents that are not ready for
:    advancement or are otherwise in an unclear state?  If such normative
:    references exist, what is the plan for their completion?

No.

; (15) Are there downward normative references references (see RFC 3967)? If
:      so, list these downward references to support the Area Director in
:      the Last Call procedure.

No.

: (16) Will publication of this document change the status of any existing
:      RFCs?  Are those RFCs listed on the title page header, listed in the
:      abstract, and discussed in the introduction?  If the RFCs are not
:      listed in the Abstract and Introduction, explain why, and point to
:      the part of the document where the relationship of this document to
:      the other RFCs is discussed. If this information is not in the
:      document, explain why the WG considers it unnecessary.

No.

: (17) Describe the Document Shepherd's review of the IANA considerations
:      section, especially with regard to its consistency with the body of
:      the document. Confirm that all protocol extensions that the document
:      makes are associated with the appropriate reservations in IANA
:      registries. Confirm that any referenced IANA registries have been
:      clearly identified. Confirm that newly created IANA registries
:      include a detailed specification of the initial contents for the
:      registry, that allocations procedures for future registrations are
:      defined, and a reasonable name for the new registry has been
:      suggested (see RFC 8126).

IANA has provided an early registration for the code point required for this
document.  The registration remains appropriate and can be stably assigned
using this RFC-to-be as a reference.

: (18) List any new IANA registries that require Expert Review for future
:      allocations.  Provide any public guidance that the IESG would find
:      useful in selecting the IANA Experts for these new registries.

No new registries.  Early allocation on code point.

: (19) Describe reviews and automated checks performed by the Document
:      Shepherd to validate sections of the document written in a formal
:      language, such as XML code, BNF rules, MIB definitions, YANG modules,
:      etc.

This document includes none of these items for review.

: (20) If the document contains a YANG module, has the module been checked
:      with any of the recommended validation tools
:      (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax
:      and formatting validation?  If there are any resulting errors or
:      warnings, what is the justification for not fixing them at this time?
:      Does the YANG module comply with the Network Management Datastore
:      Architecture (NMDA) as specified in RFC8342?

No Yang modules at this time.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Type of RFC:  Proposed standard
Why:  proposes extensions to RFC7752  for a new BGP-LS Attribute TLV called the S-BFD

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  Seamless Bidirectional Forwarding Detection (S-BFD) defines a
  simplified mechanism to use Bidirectional Forwarding Detection (BFD)
  with large portions of negotiation aspects eliminated, thus providing
  benefits such as quick provisioning as well as improved control and
  flexibility to network nodes initiating the path monitoring.  The
  link-state routing protocols (IS-IS and OSPF) have been extended to
  advertise the Seamless BFD (S-BFD) Discriminators.

  This draft defines an extension to the BGP Link-state address-family to
  carry the S-BFD Discriminators information in a
    new BGP-LS Attribute TLV called the S-BFD
  Discriminators TLV.

Working Group Summary:

Was there anything in WG process that is worth noting?
No - some minor additions.
Please note that the revision of RFC7752 is progressing.

WG consensus
(TBD) - normal participants

Document Quality:

Implementations at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-sbfd-extensions%20implementations
[Note - only one implementation listed here at Nokia.
Check with Huawei and Cisco for their implementations]

Personnel:

Who is the Document Shepherd:  Jeff Haas
Who is the Responsible Area Director: Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd.
If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
(TBD)

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
(TBD)

(5) Do portions of the document need review from a particular or from broader perspective, e.g.,
security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
(TBD) - Does BFD WG need to review

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
(TBD)

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Zhenbin Li
https://mailarchive.ietf.org/arch/msg/idr/R0T3U5AT5nG8BhOGotvEBwZosfQ/

  Shunwan Zhuang
https://mailarchive.ietf.org/arch/msg/idr/gM8Y7TLdVZXzKk6LXRe37VNph3A/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/IosPDPgSqRSUGnwkAc9eP_d3MCg/

Sam Aldrin
https://mailarchive.ietf.org/arch/msg/idr/bH3X_poL4sy9gyGmBMTRGS3kVP8/

Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/idr/fM1PlfroxyWnLOlIvvBud2BWZ0k/

Greg Mirsky
https://mailarchive.ietf.org/arch/msg/idr/TUyhdR5Dqm_u-Ft420BI10CKB0Q/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR.

(9) How solid is the WG consensus behind this document?
Does it represent the strong concurrence of a few individuals,
with others being silent, or does the WG as a whole understand and agree with it?

Normal active participants sent in support posts.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages
to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No threats or discontent over this document.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough. )

Nits - TBD

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
(TBD) - Early reviews of RTG-DIR, OPS-DIR, SEC-DIR requested

(13) Have all references within this document been identified as either normative or informative?
(TBD)

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the plan for their completion?
(TBD)

(15) Are there downward normative references references (see RFC 3967)? I
f so, list these downward references to support the Area Director in the Last Call procedure.
(TBD)

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction?
If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the
document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

(TBD) - none as far as I can tell.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

(TBD)

(18) List any new IANA registries that require Expert Review for future allocations.
Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.  Early allocation on code point.

(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as
XML code, BNF rules, MIB definitions, YANG modules, etc.

(20) If the document contains a YANG module, has the module been
checked with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation?
If there are any resulting errors or warnings, what is the justification for not fixing them at this time?
Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No Yang modules at this time.