BFD for Geneve
draft-ietf-nvo3-bfd-geneve-13

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-nvo3-bfd-geneve and RFC 9521, changed IESG state to RFC Published)

[Ballot comment]
Thanks for addressing my previous blocking DISCUSS ballot at:
https://mailarchive.ietf.org/arch/msg/nvo3/gZrWMNTBpJEUzrR9uv74eaAQFoE/

The -13 also implements suggestions to improve the text. Very much appreciated.

Regards

-éric

[Ballot comment]
I'd like to thank Sheng Jiang for the OpsDir review -- https://datatracker.ietf.org/doc/review-ietf-nvo3-bfd-geneve-11-opsdir-lc-jiang-2023-07-11/

Other than supporting John and Eric's DISCUSS, and also thinking that Zahed's comment is more of a discuss, I don't have anything to add...

[Ballot comment]
Thanks for working on this specification. Special thanks to Magnus Westerlund for identifying an important aspect in his TSVART review and I am happy to see the resolution in the -11 version of this doc.

I have stumbled upon similar clarification issues that John has brought up in his discuss. It not clear to me how this validation need to be done as written in Section 5.1

    Then the UDP destination port and the TTL or Hop Limit of the inner IP packet MUST be validated to determine whether the received packet can be processed by BFD.

I was expecting pointers for those validation mechanism special to BFD. Can we be more clear on this?

[Ballot comment]
Thanks for working on this specification. Special thanks to Magnus Westerlund for identifying an important aspect in his TSVART review and I am happy to see the resolution in the -11 version of this doc.

I have stumbled up similar clarification issues that John has brought up in his discuss. It not clear to me how this validation need to be done as written in Section 5.1

    Then the UDP destination port and the TTL or Hop Limit of the inner IP packet MUST be validated to determine whether the received packet can be processed by BFD.

I was expecting pointers for those validation mechanism special to BFD. Can we be more clear on this?

[Ballot discuss]

# Éric Vyncke, INT AD, comments for raft-ietf-nvo3-bfd-geneve-12

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Matthew Bocci for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Other thanks to Don Eastlake, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-nvo3-bfd-geneve-12-intdir-telechat-eastlake-2023-08-05/
Don's review was 'not ready', and I concur with him after doing my own review. Authors' reply to Don's review will be welcome.

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## Sectin 6

I share Don's issue about having `Geneve provides security` and `Geneve does not have any inherent security mechanisms` in the same paragraph. There should probably some nuance or limitation in those two assertions to make them compatible.

[Ballot comment]

# COMMENTS


## Section 1

Unsure whether the following text is useful here `The major difference between Geneve and VXLAN [RFC7348] is that Geneve supports multi-protocol payload and variable length options.`

I trust the transport ADs for the accuracy of the last paragraph about the congestion control.

## Section 4.1

`the BFD session SHOULD be identified using`, what is the procedure to be followed when it is not possible? The I-D should be clear on this.

## Section 5;1

`MUST be validated to determine` how can the receiving node validate ? Of course, the reader can guess, but let's be specific.

What should the receiving node do if this validation fails ?

## Section 6

Suggest to specify what "enough" means in ` are enough for the pair of NVEs`.

# NITS

## Section 1

s/an other device/another device/

s/p2p Geneve tunnel/P2P Geneve tunnel/ or expand `p2p`

[Ballot comment]
# GEN AD review of draft-ietf-nvo3-bfd-geneve-12

CC @larseggert

Thanks to Paul Kyzivat for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/qhzwtKgxklVyNtwYV_BDFkZLx4E).

## Nits

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.

### Grammar/style

#### "Table of Contents", paragraph 1
```
(Network Virtualization Edge) or an other device acting as a Geneve tunnel
                                  ^^^^^^^^
```
This word is normally spelled as one.

#### Section 1, paragraph 2
```
FC7348] is that Geneve supports multi-protocol payload and variable length op
                                ^^^^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 3, paragraph 1
```
words, an outer IPv6 header accompanied with an inner IPv4 header and an ou
                            ^^^^^^^^^^^^^^^^
```
The usual collocation for "accompany" is "by", not "with". (Also elsewhere.)

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
Thanks for this valuable and easy-to-read spec. I have one concern that I'd like to have a discussion about; I hope this will be easy to resolve.

There are several places where you use MUST in a way I think is unnecessary, you seem to be saying, in effect, "to do Geneve you MUST do Geneve". Most of these are harmless IMO (I put some examples in the COMMENT section just in case you're unclear what I'm talking about) but there are two that seem problematic to me, nearly-identical sentences from Sections 4.1 and 5.1:

                  Then the Destination IP, the UDP destination port and
  the TTL or Hop Limit of the inner IP packet MUST be validated to
  determine whether the received packet can be processed by BFD.

and

                  Then the UDP destination port and the TTL or Hop Limit
  of the inner IP packet MUST be validated to determine whether the
  received packet can be processed by BFD.

In both cases, it's unclear to me if you're just saying "Geneve has certain validation rules that have to be met before the packet can be passed to the upper layer", or if you're introducing a new requirement. In the former case, please be more transparent about that, possibly with a citation to the validation rules in the underlying spec. You could also consider dropping the RFC 2119 MUST. In the latter case, if you're truly introducing a new requirement, I think the validation rules need to be spelled out much more clearly. (I think it's probably the former case.)

[Ballot comment]
- Please consider expanding "FCS" where used, or glossing it elsewhere.

- This sentence in Sections 4.1 and 5.1,

                              The Destination MAC of the inner Ethernet
  frame matches the MAC address of a VAP which is mapped to the same as
  received VNI. 
 
has a grammatical problem that prevents me from making sense of it. I *think* you are missing a noun after "the same", so it should be something like "The Destination MAC _address_ of the inner Ethernet frame matches the MAC address of a VAP which is mapped to the same _???_ as _the_ received VNI."

Or maybe some other rewrite is needed, but anyway, it's not clear as it stands.

- Here are a few examples where I think you have MUSTs that may be unnecessary, as referenced in my DISCUSS. I don't insist on any changes related to these, I'm just providing them for your information.

                                                              The Outer
  IP/UDP and Geneve headers MUST be encoded by the sender as defined in
  [RFC8926].

("MUST be" could be "are"; occurs 2x in the doc)

      Opt Len field MUST be set consistent with the Geneve specification

(This could be "The usage of the Opt Len field is specified in [RFC8926], and depends on whether or not", etc; occurs 2x in the doc)

  Once a packet is received, the NVE MUST validate the packet as
  described in [RFC8926].
 
(Could be "... the NVE validates..."; occurs 2x in the doc)

[Ballot comment]
Thank you to Carl Wallace for the SECDIR review.

** Section 6 
  The BFD
  introduces no security vulnerabilities when run in this manner.
  Considering Geneve does not have any inherent security mechanisms,
  BFD authentication as specified in [RFC5880] is recommended to be
  utilized.
 
Consider if a normative “RECOMMENDED” is appropriate for encouraging the use of BFD authentication.

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

The IANA Functions Operator has reviewed draft-ietf-nvo3-bfd-geneve-11, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-07-11):

From: The IESG
To: IETF-Announce
CC: andrew-ietf@liquid.tech, draft-ietf-nvo3-bfd-geneve@ietf.org, matthew.bocci@nokia.com, nvo3-chairs@ietf.org, nvo3@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (BFD for Geneve) to Proposed Standard


The IESG has received a request from the Network Virtualization Overlays WG
(nvo3) to consider the following document: - 'BFD for Geneve'
  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 2023-07-11. 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


  This document describes the use of the Bidirectional Forwarding
  Detection (BFD) protocol in point-to-point Generic Network
  Virtualization Encapsulation (Geneve) unicast tunnels used to make up
  an overlay network.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-nvo3-bfd-geneve/



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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document represents broad consensus in the working group. It has been developed over several years and discussed in the WG numerous times.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

None.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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.)

None indicated.


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The are numerous known implementations of BFD over tunnels e.g. MPLS LSPs, and there are known implementations of Geneve.
Although there is no formal record of implementations of BFD over Geneve, this draft does not make any changes to the BFD state machine and
simply describes how it should be encapsulated.



## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document describes how to encapsulate BFD over Geneve. The design of BFD is typically handled by the BFD working group, and therefore
the draft was cross-reviewed with that working group at last call time. No other WG reviews are required.

The draft was subject to a RTG DIR early review, which concluded that it was ready.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.


No formal expert reviews are required.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

n/a

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

n/a

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, the document is ready. I have performed by usual shepherd's review, and made a number of editorial comments
to improve the readability of the draft. These have been addressed by the authors.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?


No issues identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This is appropriate because specific procedures are mandated in order to enable interoperability.
This status is reflected in the datatracker. The document header also indicates that it is intended for the Standards Track.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The WG last call included an IPR Poll. All authors indicated that they are not aware of any applicable IPR.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

The document passes I-D Nits.
There is one minor issue as follows:
== There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be changed.
However, I could not find which instance it was referring to.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The references are appropriately categorised.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?


none

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

no

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

no

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

no

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The draft does not request any actions from IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new registries.




[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document represents broad consensus in the working group. It has been developed over several years and discussed in the WG numerous times.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

None.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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.)

None indicated.


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The are numerous known implementations of BFD over tunnels e.g. MPLS LSPs, and there are known implementations of Geneve.
Although there is no formal record of implementations of BFD over Geneve, this draft does not make any changes to the BFD state machine and
simply describes how it should be encapsulated.



## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document describes how to encapsulate BFD over Geneve. The design of BFD is typically handled by the BFD working group, and therefore
the draft was cross-reviewed with that working group at last call time. No other WG reviews are required.

The draft was subject to a RTG DIR early review, which concluded that it was ready.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.


No formal expert reviews are required.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

n/a

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

n/a

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, the document is ready. I have performed by usual shepherd's review, and made a number of editorial comments
to improve the readability of the draft. These have been addressed by the authors.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?


No issues identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This is appropriate because specific procedures are mandated in order to enable interoperability.
This status is reflected in the datatracker. The document header also indicates that it is intended for the Standards Track.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The WG last call included an IPR Poll. All authors indicated that they are not aware of any applicable IPR.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

The document passes I-D Nits.
There is one minor issue as follows:
== There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be changed.
However, I could not find which instance it was referring to.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The references are appropriately categorised.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?


none

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

no

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

no

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

no

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The draft does not request any actions from IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new registries.




[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/