Skip to main content

Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN)
draft-ietf-bfd-vxlan-16

Revision differences

Document history

Date Rev. By Action
2020-12-10
16 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-12-01
16 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-11-15
16 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-11-03
16 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-11-03
16 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-11-03
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-11-03
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-11-03
16 (System) IANA Action state changed to In Progress from On Hold
2020-11-02
16 (System) IANA Action state changed to On Hold from In Progress
2020-10-29
16 (System) RFC Editor state changed to EDIT
2020-10-29
16 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-10-29
16 (System) Announcement was received by RFC Editor
2020-10-29
16 (System) IANA Action state changed to In Progress
2020-10-29
16 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-10-29
16 Amy Vezza IESG has approved the document
2020-10-29
16 Amy Vezza Closed "Approve" ballot
2020-10-29
16 Amy Vezza Ballot approval text was generated
2020-10-28
16 Martin Vigoureux Intended Status changed to Informational from Proposed Standard
2020-10-28
16 Martin Vigoureux IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2020-10-26
16 Greg Mirsky New version available: draft-ietf-bfd-vxlan-16.txt
2020-10-26
16 (System) New version approved
2020-10-26
16 (System) Request for posting confirmation emailed to previous authors: Mallik Mudigonda , Greg Mirsky , Santosh Pallagatti , Sudarsan Paragiri , Vengada Govindan
2020-10-26
16 Greg Mirsky Uploaded new revision
2020-10-03
15 Erik Kline
[Ballot comment]
doc{draft-ietf-bfd-vxlan-15}
ballot{Abstain}


[[ comments ]]

I was tempted to ballot Discuss, but I'm not sure about re-opening old
discussions into which …
[Ballot comment]
doc{draft-ietf-bfd-vxlan-15}
ballot{Abstain}


[[ comments ]]

I was tempted to ballot Discuss, but I'm not sure about re-opening old
discussions into which I've no insight (it all happened before my tenure).


[ sections 3,5 ]

* I agree with Eric Vyncke's concerns about the use of ::ffff:127.0.0.0/104
  space.  This is not especially well-motivated, nor do I think the use of
  127.0.0.0/8 is particularly well-motivated.

  In IPv6, 2001::/23 is reserved for IETF protocol assignments and in my
  opinion this is an example of where that should be used.

  There is also still plenty of space to carve out from 192.0.0.0/24 for
  internal tunnel uses like this.

  Alternatively, a better approach might be for each VTEP to allocate their
  own IPv4 and/or IPv6 link-local addresses and uses these addresses for
  whatever traffic is to be sent within the data plane.  If the VTEPs use
  inner Ethernet headers for this traffic, then this would seem to make
  more sense to me.

[ section 9 ]

* It's not clear that the security of a prohibition on routers is sufficiently
  motivating securit when the packet is logically "switched" because it's on
  the same (effectively) VLAN.  The same router forwarding prohibition applies
  to link-local IP addresses and these could be used instead.

* What prevents a machine like VM1-1 from crafting a packet with the magic
  destination MAC and src & dst IPs from the magic range?  Should there be
  text about not forwarding any packets from VMs toward the magic dst MAC?
2020-10-03
15 Erik Kline [Ballot Position Update] New position, Abstain, has been recorded for Erik Kline
2020-10-02
15 Robert Wilton
[Ballot comment]
Hi,

This document seems pretty straight forward to me.  A few, non blocking, comments:

Assigning a single unicast MAC address seems slightly odd …
[Ballot comment]
Hi,

This document seems pretty straight forward to me.  A few, non blocking, comments:

Assigning a single unicast MAC address seems slightly odd in that it isn't globally unique, but I can't think of any good alternative.

  At the same time, a service layer BFD session may be used between the
  tenants of VTEPs IP1 and IP2 to provide end-to-end fault management
  (this use case is outside the scope of this document).  In such a
  case, for VTEPs BFD Control packets of that session are
  indistinguishable from data packets.
 
"for VTEPs BFD Control" => "for VTEPS, the BFD Control"

        Ethernet Header:

        Destination MAC: A Management VNI, which does not have any
        tenants, will have no dedicated MAC address for decapsulated
        traffic.  The value (TBD1) SHOULD be used in this field.

        Source MAC: MAC address associated with the originating VTEP.
       

Should the TypeOrLen field in the Ethernet header also be specified (presumably set to IPv4 or IPv6)?

Regards,
Rob
2020-10-02
15 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-10-01
15 Greg Mirsky New version available: draft-ietf-bfd-vxlan-15.txt
2020-10-01
15 (System) New version approved
2020-10-01
15 (System) Request for posting confirmation emailed to previous authors: Sudarsan Paragiri , Santosh Pallagatti , Greg Mirsky , Mallik Mudigonda , Vengada Govindan
2020-10-01
15 Greg Mirsky Uploaded new revision
2020-09-29
14 Benjamin Kaduk
[Ballot comment]
Thank you for the discussions around my discuss point, and the ensuing changes
resulting from the discussions!  My apologies that I was tardy …
[Ballot comment]
Thank you for the discussions around my discuss point, and the ensuing changes
resulting from the discussions!  My apologies that I was tardy in re-reviewing after
the updates were made.

I think the core issues have been resolved, but do have a couple comments on the -14:

Section 3 says:

                  Separate BFD sessions can be established between the
  VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100
  and 200).  Using a BFD session to monitor a set of VXLAN VNIs between
  the same pair of VTEPs might help to detect and localize problems
  caused by misconfiguration.  An implementation that supports this
  specification MUST be able to control the number of BFD sessions that
  can be created between the same pair of VTEPs.  [...]

While the first two sentences are probably true, they are arguably out
of scope for this document, since Section 6 says that BFD control
packets on non-management VNI is outside the scope of this
specification.  The third sentence is quite surprising in the context of
this document only defining BFD for the management VNI, since multiple
BFD sessions on the same VNI seem redundant.

Section 5

        Destination MAC: A Management VNI, which does not have any
        tenants, will have no dedicated MAC address for decapsulated
        traffic.  The value [TBD1] SHOULD be used in this field.

While this normative language seems like the appropriate level of
stringency, I do find myself wondering what other value might be used
and why.  (This, of course, need not be answered in the document, though
it could be if the answer is known and useful.)
2020-09-29
14 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2020-08-03
14 Jeffrey Haas
: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
: Standard, Informational, Experimental, or Historic)? Why is this the proper
: …
: (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?

Informational.

: (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:

This document describes the use of the Bidirectional Forwarding
Detection (BFD - RFC 5880) protocol in Virtual eXtensible Local Area Network
(VXLAN) overlay networks.

: Working Group Summary:

This document has received community review with opportunities to comment in
relevant working groups such as BFD, NVO3, and BESS.  It is of interest to
parties that operate VXLAN networks and wish to provide continuity checks for
tunnels interconnecting virtual machines in such networks.

: Was there anything in WG process that is worth noting? For example, was there
: controversy about particular points or were there decisions where the consensus
: was particularly rough?

In spite of significant discussion prior to submitting this document to the
IESG, there was much commentary as part of IESG review.

A substantial amount of review commentary was generated by the original text
related to what VNI is being tested using this protocol extension.  The
majority of this commentary was the result of the security considerations
related to how a tenant VNI may benefit from this feature.  In particular,
how does the protocol attempt to avoid hijacking tenant MAC addresses and
necessary IP addressing of the encapsulated BFD packets.

As part of addressing this issue, the Working Group decided to reduce the
general scope of the feature in this document to validating reachability to
the management VNI.  This removed the related security considerations for
the more general mechanism in the proposal.  It should be noted that the
encapsulation format remains flexible enough that testing non-management
VNIs remains feasible, but is now out of scope for this document.

While VXLAN implementations appear to regularly have forms of "management
VNIs", this concept does not appear in the VXLAN architecture documents.
The consensus in this document is that VNI number 1 would be the default VNI
for the management VNI number.

Since the management VNI did not have a well known Destination MAC address,
the proposal in this document was that one would be allocated from the IANA
pool for unicast MAC addresses for this purpose.

The internal Destination IP address, using the ::ffff:127.0.0.0/104 network
in a fashion similar to the MPLS LSP Ping feature required extensive
discussion with the IESG.  While this usage is well understood in MPLS OAM
functionality, it was controversial with one of the reivewing Area Directors. 
However, that AD's DISCUSS was removed after long discussion.

The TTL/Hop Limit value and the application of GTSM (RFC 5082) as per BFD
core procedural documents was discussed and the document moved to use that
procedure even in encapsulated traffic.

A final note is that issue tracking became challenging during this review
and that the IETF would be well served by re-tooling IESG commentary to
include an issue tracker as part of the core infrastructure.

: Document Quality:
:
: Are there existing implementations of the protocol? Have a significant number
: of vendors indicated their plan to implement the specification? Are there any
: reviewers that merit special mention as having done a thorough review, e.g.,
: one that resulted in important changes or a conclusion that the document had no
: substantive issues? If there was a MIB Doctor, Media Type or other expert
: review, what was its course (briefly)? In the case of a Media Type review, on
: what date was the request posted?

At the time of working group last call, there are two known implementations of
this mechanism.  No special reviewers were required for this document.

: Personnel:
:
: Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Jeffrey Haas, BFD co-chair.
Responsible Area Director: Martin Vigoreux.

: (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.

This document has been through working group review and has received and
incorporated commentary.  Additionally, feedback was solicited within NVO3 and
BESS.  BESS feedback was suggested after WGLC had concluded at the
recommendation of one of the NVO3 reviewers, Anoop Ghanwani, since BESS
provides protocol extensions for provisioning networks related to this
mechanism.

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

No.

: (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.

The Destination MAC address assignment still requires review from the IANA
Designated Experts.  Multiple attempts to reach them were made during
document 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.

No concerns.

: (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?

Yes.

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

There exists an IPR disclosure, #3193, from Cisco.  This IPR was disclosed
prior to last call and is not seen as an obstacle to document publication.

: (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?

The feedback on the document was solid.  Core participants of the working group
provided feedback on this document.  Additionally, it received review from
parties that normally do not provide last call feedback.

: (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.

: (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.

No nits.

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

The IANA considerations requesting a unicast MAC will require Expert Review as
part of IANA assignment.

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

Yes.

: (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. 

Previously, when the document was targeted for Proposed Standard, there was
an issue with the core VXLAN documents having Informational status.
However, it was the consensus of the Working Group to change the status of
this proposal to match it as Informational.

: (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 5226).

The document has one request to IANA for assignment of a unicast MAC
address. This request requires review from a Designated Expert.

: (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.

None.

: (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, etc.

N/A

-- Jeff Haas
2020-07-28
14 Greg Mirsky New version available: draft-ietf-bfd-vxlan-14.txt
2020-07-28
14 (System) New version accepted (logged-in submitter: Greg Mirsky)
2020-07-28
14 Greg Mirsky Uploaded new revision
2020-07-22
13 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document and its update. I have cleared one of my DISCUSS point about TTL = …
[Ballot comment]
Thank you for the work put into this document and its update. I have cleared one of my DISCUSS point about TTL = Hop Limit not being 255.

But, the authors and I are in an impasse about the use of IPv4-mapped IPv6 addresses but I do not want to block the document. I change my ballot to "ABSTAIN" in the sense of "I oppose this document but understand that others differ and am not going to stand in the way of the others".

BTW, I understood that the use a prefix rather than /32 or /128 was to allow for entropy (to explore multiple ECMP/LAG paths).
BTW2, the right wording is "IPv4-mapped IPv6 address" and not "IPv4-mapped IPv4 address" as written twice in the document.

Did you (or actually the authors) also investigate the use of the:
- ::/0 : unspecified address
- 100::/8 the discard prefix used for RTBH RFC 6666
- or even requesting a block out of the 2001::/23 (reserved for IETF special use)

Previous COMMENTs for archive as they were on revision -09

RFC 5881 (BFD) states that it applies to IPv4/IPv6 tunnels, may I infer that this document is only required to address the Ethernet encapsulation ? I.e. specifying the Ethernet MAC addresses?

-- Section 3 --
At first sight, I was surprized by having a BFD session per VXLAN VNI as it will create some scalability issue, but, I assume that this is to detect misconfiguration as well. If so, perhaps worth mentionnig the reasoning behind?

In "the inner destination IP address SHOULD" it is unclear whether it is in the all BFD packets, or only the request one or ... ?

-- Section 4 --
While probably defined in RFC7348, should "FCS" be renamed as "Outer Ethernet FCS" for consistency with the "Outer Ethernet Header" in figure 2 ?

Why not using the Source MAC address as the Destination MAC address ? This would ensure that there is no conflict at the expense of "forcing" the transmission of the frame even if addressed to itself.

Please consider rewriting the section about TTL/Hop Limit as it is not easy to parse/read.

-- Section 9 --

This section is mainly about IPv4 (RFC 1812). Please address IPv6 as well in the explanation of packet not being forwarding when addressed to 127/8
2020-07-22
13 Éric Vyncke [Ballot Position Update] Position for Éric Vyncke has been changed to Abstain from Discuss
2020-07-14
13 Éric Vyncke
[Ballot discuss]

Thank you for the work put into this document and its update. I have cleared one of my DISCUSS point avout TTL = …
[Ballot discuss]

Thank you for the work put into this document and its update. I have cleared one of my DISCUSS point avout TTL = Hop Limit not being 255. All other DISCUSS points remain esp the use of IPv4-mapped IPv6 addresses rather than the IPv6 loopback ::1/128.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 3 --
IPv4-mapped IPv6 addresses are only to be used inside a host and should never be transmitted in real packets (including packets inside a tunnel) see section 4.2 of RFC 4038 (even if informational). As other IESG reviewers, I wonder why ::1/128 is not used?

BTW, the right wording is "IPv4-mapped IPv6 address" and not "IPv4-mapped IPv4 address" as written twice in the document.

-- Section 8 --
The document specifies no IANA actions while the shepherd write-up talks about a IANA action.
==> please update the shepherd's report accordingly.
2020-07-14
13 Éric Vyncke
[Ballot comment]
Those COMMENTs were on revision -09, so, they may not apply anymore

== COMMENTS ==

RFC 5881 (BFD) states that it applies to …
[Ballot comment]
Those COMMENTs were on revision -09, so, they may not apply anymore

== COMMENTS ==

RFC 5881 (BFD) states that it applies to IPv4/IPv6 tunnels, may I infer that this document is only required to address the Ethernet encapsulation ? I.e. specifying the Ethernet MAC addresses?

-- Section 3 --
At first sight, I was surprized by having a BFD session per VXLAN VNI as it will create some scalability issue, but, I assume that this is to detect misconfiguration as well. If so, perhaps worth mentionnig the reasoning behind?

In "the inner destination IP address SHOULD" it is unclear whether it is in the all BFD packets, or only the request one or ... ?

-- Section 4 --
While probably defined in RFC7348, should "FCS" be renamed as "Outer Ethernet FCS" for consistency with the "Outer Ethernet Header" in figure 2 ?

Why not using the Source MAC address as the Destination MAC address ? This would ensure that there is no conflict at the expense of "forcing" the transmission of the frame even if addressed to itself.

Please consider rewriting the section about TTL/Hop Limit as it is not easy to parse/read.

-- Section 9 --

This section is mainly about IPv4 (RFC 1812). Please address IPv6 as well.
2020-07-14
13 Éric Vyncke Ballot comment and discuss text updated for Éric Vyncke
2020-07-06
13 Greg Mirsky New version available: draft-ietf-bfd-vxlan-13.txt
2020-07-06
13 (System) New version approved
2020-07-06
13 (System) Request for posting confirmation emailed to previous authors: Greg Mirsky , Mallik Mudigonda , Vengada Govindan , Sudarsan Paragiri , Juniper Networks
2020-07-06
13 Greg Mirsky Uploaded new revision
2020-06-17
12 Alvaro Retana [Ballot comment]
[Thank you for addressing my DISCUSS.]
2020-06-17
12 Alvaro Retana [Ballot Position Update] Position for Alvaro Retana has been changed to No Objection from Discuss
2020-05-25
12 Greg Mirsky New version available: draft-ietf-bfd-vxlan-12.txt
2020-05-25
12 (System) New version approved
2020-05-25
12 (System) Request for posting confirmation emailed to previous authors: Vengada Govindan , Juniper Networks , Mallik Mudigonda , Greg Mirsky , Sudarsan Paragiri
2020-05-25
12 Greg Mirsky Uploaded new revision
2020-05-04
11 Greg Mirsky New version available: draft-ietf-bfd-vxlan-11.txt
2020-05-04
11 (System) New version accepted (logged-in submitter: Greg Mirsky)
2020-05-04
11 Greg Mirsky Uploaded new revision
2020-01-08
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-01-08
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-01-08
10 Greg Mirsky New version available: draft-ietf-bfd-vxlan-10.txt
2020-01-08
10 (System) New version approved
2020-01-08
10 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Vengada Govindan , Mallik Mudigonda , Juniper Networks , Sudarsan Paragiri
2020-01-08
10 Greg Mirsky Uploaded new revision
2019-12-19
09 Amy Vezza IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-12-19
09 Suresh Krishnan [Ballot comment]
Support Eric's DISCUSS on the IPv6 destination address and would like to see this clarified and resolved.
2019-12-19
09 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-12-18
09 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-12-17
09 Alvaro Retana
[Ballot discuss]
I support Eric's DISCUSS point about the TTL, but I want to go a step further because this document contradicts rfc5881, which …
[Ballot discuss]
I support Eric's DISCUSS point about the TTL, but I want to go a step further because this document contradicts rfc5881, which is clear about the TTL setting (from §5):

  If BFD authentication is not in use on a session, all BFD Control
  packets for the session MUST be sent with a Time to Live (TTL) or Hop
  Limit value of 255.  All received BFD Control packets that are
  demultiplexed to the session MUST be discarded if the received TTL or
  Hop Limit is not equal to 255.  A discussion of this mechanism can be
  found in [GTSM].
 
  If BFD authentication is in use on a session, all BFD Control packets
  MUST be sent with a TTL or Hop Limit value of 255.  All received BFD
  Control packets that are demultiplexed to the session MAY be
  discarded if the received TTL or Hop Limit is not equal to 255.  If
  the TTL/Hop Limit check is made, it MAY be done before any
  cryptographic authentication takes place if this will avoid
  unnecessary calculation that would be detrimental to the receiving
  system.


OTOH, Section 4 of this document specifies:

    TTL or Hop Limit: MUST be set to 1 to ensure that the BFD
    packet is not routed within the Layer 3 underlay network.  This
    addresses the scenario when the inner IP destination address is
    of VXLAN gateway and there is a router in underlay which
    removes the VXLAN header, then it is possible to route the
    packet as VXLAN  gateway address is routable address.

Not wanting the packet to be routed in the underlay sounds like a reasonable justification -- but I couldn't find the specification in rfc7348 about "a router in underlay which removes the VXLAN header".  Maybe I missed it...

Independent of VXLAN, the conflict with rfc5881 remains -- given the text above, it seems to me that it would be ok if the TTL was set to 1 if authentication is is use, but this document doesn't talk about requiring authentication.
2019-12-17
09 Alvaro Retana
[Ballot comment]
I also support Ben's DISCUSS.

Non-blocking comments:

(1) §3: "...a service layer BFD session may be used between the tenants of VTEPs IP1 …
[Ballot comment]
I also support Ben's DISCUSS.

Non-blocking comments:

(1) §3: "...a service layer BFD session may be used between the tenants of VTEPs IP1 and IP2..."  Just to be clear, the use of BFD in a "service layer session" is out of scope of this document, right?  It might be nice to say so.

(2) §3: "As per Section 4, the inner destination IP address SHOULD be..."  If the specification is already in Section 4, then there doesn't seem to be a need to repeat it.  It might make more sense to put the text about a potential firewall there.

(3) §4: "...SHOULD ensure that the BFD packets follow the same lookup path as VXLAN data packets within the sender system."  What is a "lookup path"?  When would it be ok to not ensure it?  BTW, a better Normative statement might me (something like): MUST follow the same lookup path...

(4) §4: "The MAC address MAY be configured, or it MAY be learned via a control plane protocol. The details of how the MAC address is obtained are outside the scope of this document."  The Normative MAYs are really just stating a fact, and out of scope any way.  s/MAY/may

(5) §5: "If the Destination MAC of the inner Ethernet frame doesn't match any of VTEP's MAC addresses, then the processing of the received VXLAN packet MUST follow the procedures described in Section 4.1 [RFC7348]."  §4.1 of rfc7348 is about Unicast VM-to-VM Communication -- which makes me think that if the procedures from that section are followed then the BFD packet may be forwarded to a VM, which seems to be in contradiction with this statement (from §3): "BFD packets intended for a VTEP MUST NOT be forwarded to a VM as a VM may drop BFD packets leading to a false negative."  What am I missing?

(6) Related to the last point, the following sentences also mention that BFD packets MUST NOT be forwarded to VMs...but with qualifications:

§5: "If the BFD session is using the Management VNI (Section 6), BFD Control packets with unknown MAC address MUST NOT be forwarded to VMs."

§6: "All VXLAN packets received on the Management VNI MUST be processed locally and MUST NOT be forwarded to a tenant."

The difference between these 2 statements and the one from §3 is that they seem to be intended only when using the Management VNI...but it would seem that the general statement applies there too, right?  IOW, the specific statements about the Management VNIs are simply affirming what was already said more generally in §3, right? 

(7) Nits:

s/of VXLAN gateway and there is a router in underlay/of the VXLAN gateway and there is a router in the underlay

s/VTEP MUST validate/the VTEP MUST validate

s/then BFD session/then the BFD session
2019-12-17
09 Alvaro Retana [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana
2019-12-17
09 Warren Kumari
[Ballot comment]
I support Benjamin and Eric's DISCUSSES - I considered holding a DISCUSS on the "loopback address" terminology and formatting (which was also noted …
[Ballot comment]
I support Benjamin and Eric's DISCUSSES - I considered holding a DISCUSS on the "loopback address" terminology and formatting (which was also noted in the excellent OpsDir review by Jürgen Schönwälder), but think that Eric can carry it.

In addition, like Jurgen, I think it would be helpful to have pointers to where terms are defined - the "Terminology" section isn't really terminology, but rather just an acronym expansion section.
2019-12-17
09 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2019-12-17
09 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2019-12-17
09 Éric Vyncke
[Ballot discuss]

Thank you for the work put into this document.

I fully second Adam's COMMENT that should be fixed before publication (IMHO this is …
[Ballot discuss]

Thank you for the work put into this document.

I fully second Adam's COMMENT that should be fixed before publication (IMHO this is a DISCUSS).

Answers to my COMMENTs below will be welcome, even if those COMMENTs are not blocking.

As usual, an answer to the DISCUSS is required to clear my DISCUSS though.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

May be I am not familiar enough with BFD, but, RFC 5881 (the one defining BFD) specifies the use of TTL = Hop Limit = 255.. Why this document uses a value of 1 ?

-- Section 3 --
IPv4-mapped IPv6 addresses are only to be used inside a host and should never be transmitted in real packets (including packets inside a tunnel) see section 4.2 of RFC 4038 (even if informational). As other IESG reviewers, I wonder why ::1/128 is not used?

-- Section 8 --
The document specifies no IANA actions while the shepherd write-up talks about a IANA action.

-- Section 9 --
This section is only about IPv4 (TTL and RFC 1812). Please address IPv6 as well.
2019-12-17
09 Éric Vyncke
[Ballot comment]
== COMMENTS ==

RFC 5881 (BFD) states that it applies to IPv4/IPv6 tunnels, may I infer that this document is only required to …
[Ballot comment]
== COMMENTS ==

RFC 5881 (BFD) states that it applies to IPv4/IPv6 tunnels, may I infer that this document is only required to address the Ethernet encapsulation ? I.e. specifying the Ethernet MAC addresses?

-- Section 3 --
At first sight, I was surprized by having a BFD session per VXLAN VNI as it will create some scalability issue, but, I assume that this is to detect misconfiguration as well. If so, perhaps worth mentionnig the reasoning behind?

In "the inner destination IP address SHOULD" it is unclear whether it is in the all BFD packets, or only the request one or ... ?

-- Section 4 --
While probably defined in RFC7348, should "FCS" be renamed as "Outer Ethernet FCS" for consistency with the "Outer Ethernet Header" in figure 2 ?

Why not using the Source MAC address as the Destination MAC address ? This would ensure that there is no conflict at the expense of "forcing" the transmission of the frame even if addressed to itself.

Please consider rewriting the section about TTL/Hop Limit as it is not easy to parse/read.

-- Section 9 --
It is unclear to me (see also Ben's comment) what is the 'attack vector' of sending packets with TTL=1 ?
2019-12-17
09 Éric Vyncke [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke
2019-12-17
09 Jürgen Schönwälder Request for Telechat review by OPSDIR Completed: Has Nits. Reviewer: Jürgen Schönwälder. Sent review to list.
2019-12-16
09 Adam Roach
[Ballot comment]
Thanks for the work that everyone has put into this document. I have
a couple of relatively important, related comments that should be …
[Ballot comment]
Thanks for the work that everyone has put into this document. I have
a couple of relatively important, related comments that should be
taken into account prior to publication.

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

§3:

>  As per Section 4, the inner destination IP address SHOULD be set to
>  one of the loopback addresses (127/8 range for IPv4 and
>  0:0:0:0:0:FFFF:7F00:0/104 range for IPv6).

Please consider reformatting this IPv6 address according to the recommendations
of RFC 5952 (paying particular attention to sections 4.2.1, 4.3, and 5):

::ffff:127.0.0.0/104

It's also worth noting that, as a practical matter, modern operating systems do
not seem to bind to anything in the IPv4-mapped range assigned to IPv4 loopback:

Linux:

  ~$ ping6 ::ffff:127.0.0.1
  PING ::ffff:127.0.0.1(::ffff:127.0.0.1) 56 data bytes
  ^C
  --- ::ffff:127.0.0.1 ping statistics ---
  14 packets transmitted, 0 received, 100% packet loss, time 13316ms

MacOS:

  ~$ ping6 ::ffff:127.0.0.1
  PING6(56=40+8+8 bytes) ::ffff:127.0.0.1 --> ::ffff:127.0.0.1
  ping6: sendmsg: Invalid argument
  ping6: wrote ::ffff:127.0.0.1 16 chars, ret=-1


It is not clear to me whether this poses an issue for your intended usage.

In any case, please do not refer to ::ffff:127.0.0.0/104 as "loopback
addresses": IPv6 has only one loopback address defined (::1). The range
you cite is best described as "IPv4-mapped IPv4 loopback addresses."
Alternately -- and this is probably better -- use "::1/128" instead of
"::ffff:127.0.0.0/104" for the inner IP header destination address.

As an aside, I share Benjamin's unease around the use of loopback addresses
in this fashion. It may be worth noting that IETF protocols can reserve
addresses in the 192.0.0.0/24 and 2001::/23 blocks if necessary, and such
reserved addresses won't ever correspond to a valid destination.

(There is corresponding text in section 4 that all of the preceding pertains
to as well)

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

§9:

>  This document recommends using an address from the Internal host
>  loopback addresses (127/8 range for IPv4 and
>  0:0:0:0:0:FFFF:7F00:0/104 range for IPv6) as the destination IP
>  address in the inner IP header.  Using such address prevents the
>  forwarding of the encapsulated BFD control message by a transient
>  node in case the VXLAN tunnel is broken as according to [RFC1812]:
>
>    A router SHOULD NOT forward, except over a loopback interface, any
>    packet that has a destination address on network 127.  A router
>    MAY have a switch that allows the network manager to disable these
>    checks.  If such a switch is provided, it MUST default to
>    performing the checks.

In addition to the comments above about IPv6 address formatting, the
improper use of "loopback" terminology as it applies to IPv6, and
concerns about using localhost: it's worth noting that this text in
RFC 1812 refers to IPv4 routers -- RFC 8504 has no equivalent language,
and so the use of ::ffff:127.0.0.0/104 implies no special router handling.
::1 *probably* does, at least as a practical matter.
2019-12-16
09 Adam Roach Ballot comment text updated for Adam Roach
2019-12-16
09 Adam Roach
[Ballot comment]
Thanks for the work that everyone has put into this document. I have
a couple of relatively important, related comments that should be …
[Ballot comment]
Thanks for the work that everyone has put into this document. I have
a couple of relatively important, related comments that should be
taken into account prior to publication.

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

§3:

>  As per Section 4, the inner destination IP address SHOULD be set to
>  one of the loopback addresses (127/8 range for IPv4 and
>  0:0:0:0:0:FFFF:7F00:0/104 range for IPv6).

Please consider reformatting this IPv6 address according to the recommendations
of RFC 5952 (paying particular attention to sections 4.2.1, 4.3, and 5):

::ffff:127.0.0.0/104

It's also worth noting that, as a practical matter, modern operating systems do
not seem to bind to anything in the IPv4-mapped range assigned to IPv4 loopback:

Linux:

  ~$ ping6 ::ffff:127.0.0.1
  PING ::ffff:127.0.0.1(::ffff:127.0.0.1) 56 data bytes
  ^C
  --- ::ffff:127.0.0.1 ping statistics ---
  14 packets transmitted, 0 received, 100% packet loss, time 13316ms

MacOS:

  ~$ ping6 ::ffff:127.0.0.1
  PING6(56=40+8+8 bytes) ::ffff:127.0.0.1 --> ::ffff:127.0.0.1
  ping6: sendmsg: Invalid argument
  ping6: wrote ::ffff:127.0.0.1 16 chars, ret=-1


It is not clear to me whether this poses an issue for your intended usage.

In any case, please do not refer to ::ffff:127.0.0.0/104 as "loopback
addresses": IPv6 has only one loopback address defined (::1). The range
you cite is best described as "IPv4-mapped IPv4 loopback addresses."
Alternately -- and this is probably better -- use "::1/128" instead of
"::ffff:127.0.0.0/104" for the inner IP header destination address.

As an aside, I share Benjamin's unease around the use of loopback addresses
in this fashion. It may be worth noting that IETF protocols can reserve
addresses in the 192.0.0.0/24 and 2001::/23 blocks if necessary, and such
reserved addresses won't ever correspond to a valid destination.

(There is corresponding text in section 4 that all of the preceding pertains
to as well)

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

§9:

>  This document recommends using an address from the Internal host
>  loopback addresses (127/8 range for IPv4 and
>  0:0:0:0:0:FFFF:7F00:0/104 range for IPv6) as the destination IP
>  address in the inner IP header.  Using such address prevents the
>  forwarding of the encapsulated BFD control message by a transient
>  node in case the VXLAN tunnel is broken as according to [RFC1812]:
>
>    A router SHOULD NOT forward, except over a loopback interface, any
>    packet that has a destination address on network 127.  A router
>    MAY have a switch that allows the network manager to disable these
>    checks.  If such a switch is provided, it MUST default to
>    performing the checks.

In addition to the comments above about IPv6 address formatting, the
improper use of "loopback" terminology as it applies to IPv6, and
concerns about using localhost, it's worth noting that this text in
RFC 1812 refers to IPv4 routers -- RFC 8504 has no equivalent language,
and so the use of ::ffff:127.0.0.0/104 implies no special router handling.
2019-12-16
09 Adam Roach Ballot comment text updated for Adam Roach
2019-12-16
09 Adam Roach [Ballot Position Update] Position for Adam Roach has been changed to No Objection from No Record
2019-12-16
09 Adam Roach
[Ballot comment]
Thanks for the work that everyone has put into this document. I have
a couple of relatively important, related comments that should be …
[Ballot comment]
Thanks for the work that everyone has put into this document. I have
a couple of relatively important, related comments that should be
taken into account prior to publication.

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

>  As per Section 4, the inner destination IP address SHOULD be set to
>  one of the loopback addresses (127/8 range for IPv4 and
>  0:0:0:0:0:FFFF:7F00:0/104 range for IPv6).

Please consider reformatting this IPv6 address according to the recommendations
of RFC 5952 (paying particular attention to sections 4.2.1, 4.3, and 5):

::ffff:127.0.0.0/104

It's also worth noting that, as a practical matter, modern operating systems do
not seem to bind to anything in the IPv4-mapped range assigned to IPv4 loopback:

Linux:

  ~$ ping6 ::ffff:127.0.0.1
  PING ::ffff:127.0.0.1(::ffff:127.0.0.1) 56 data bytes
  ^C
  --- ::ffff:127.0.0.1 ping statistics ---
  14 packets transmitted, 0 received, 100% packet loss, time 13316ms

MacOS:

  ~$ ping6 ::ffff:127.0.0.1
  PING6(56=40+8+8 bytes) ::ffff:127.0.0.1 --> ::ffff:127.0.0.1
  ping6: sendmsg: Invalid argument
  ping6: wrote ::ffff:127.0.0.1 16 chars, ret=-1


It is not clear to me whether this poses an issue for your intended usage.

In any case, please do not refer to ::ffff:127.0.0.0/104 as "loopback
addresses": IPv6 has only one loopback address defined (::1). The range
you cite is best described as "IPv4-mapped IPv4 loopback addresses."
Alternately -- and this is probably better -- use "::1/128" instead of
"::ffff:127.0.0.0/104" for the inner IP header destination address.

As an aside, I share Benjamin's unease around the use of loopback addresses
in this fashion. It may be worth noting that IETF protocols can reserve
addresses in the 192.0.0.0/24 and 2001::/23 blocks if necessary, and such
reserved addresses won't ever correspond to a valid destination.

(There is corresponding text in section 4 that all of the preceding pertains
to as well)

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

§9:

>  This document recommends using an address from the Internal host
>  loopback addresses (127/8 range for IPv4 and
>  0:0:0:0:0:FFFF:7F00:0/104 range for IPv6) as the destination IP
>  address in the inner IP header.  Using such address prevents the
>  forwarding of the encapsulated BFD control message by a transient
>  node in case the VXLAN tunnel is broken as according to [RFC1812]:
>
>    A router SHOULD NOT forward, except over a loopback interface, any
>    packet that has a destination address on network 127.  A router
>    MAY have a switch that allows the network manager to disable these
>    checks.  If such a switch is provided, it MUST default to
>    performing the checks.

In addition to the comments above about IPv6 address formatting, the
improper use of "loopback" terminology as it applies to IPv6, and
concerns about using localhost, it's worth noting that this text in
RFC 1812 refers to IPv4 routers -- RFC 8504 has no equivalent language,
and so the use of ::ffff:127.0.0.0/104 implies no special router handling.
2019-12-16
09 Adam Roach Ballot comment text updated for Adam Roach
2019-12-16
09 Barry Leiba
[Ballot comment]
I support Ben’s DISCUSS.  In addition, I have a number of editorial comments.

General: there are a lot of missing or incorrect articles, …
[Ballot comment]
I support Ben’s DISCUSS.  In addition, I have a number of editorial comments.

General: there are a lot of missing or incorrect articles, making the document harder to read than it should be.  It would be good to fix that.  If you let the RFC Editor fix it, it will require careful review during AUTH48 to make sure it’s correct.

— Abstract —
The phrase “forming up” is odd; I suggest just “forming”.

— Section 3 —

  BFD packets intended for a VTEP MUST
  NOT be forwarded to a VM as a VM may drop BFD packets leading to a
  false negative.

This needs two commas: one before “as” and one before “leading”.  And what does “leading to a false negative” mean here?  I don’t understand.

  It is RECOMMENDED to allow
  addresses from the loopback range through a firewall only if it is
  used as the destination IP address in the inner IP header, and the
  destination UDP port is set to 3784 [RFC5881].

I THINK the antecedent for “it” is meant to be “addresses from the loopback range”, though because of the number mismatch it looks like the antecedent is “a firewall”.  One fix is to change “addresses” to “an address”, correcting the number error, but that leaves the ambiguity.  Maybe betterto make it “only if they are used as destination IP addresses”.  Also, remove the comma.

That fixes the sentence as written, but I also agree with Ben’s comment that this might need more significant rewording.

— Section 4 —

  BFD packet MUST be encapsulated and sent to a remote VTEP as
  explained in this section.

This needs to be either “A BFD packet” or “BFD packets” and “VTEPs”.

        The MAC address MAY be
        configured, or it MAY be learned via a control plane protocol.

Are those the only two choices?  As both “MAY” are optional, as written it allows for others.  I suggest not using BCP 14 key words here, and instead saying, “The MAC address is either configured or learned via a control plane protocol.”

        This
        addresses the scenario when the inner IP destination address is
        of VXLAN gateway and there is a router in underlay which
        removes the VXLAN header, then it is possible to route the
        packet as VXLAN  gateway address is routable address.

This sentence is too fractured for me to make any sense of it, so I can’t suggest a fix.  Please fix it.  It looks like Ben made more sense of it than I could, so maybe his suggestion will work.

— Section 5 —

  received VXLAN packet MUST follow the procedures described in
  Section 4.1 [RFC7348].

This needs to say “Section 4.1 of [RFC7348].”
2019-12-16
09 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2019-12-16
09 Erik Kline Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Erik Kline. Sent review to list.
2019-12-16
09 Roman Danyliw
[Ballot comment]
I support Ben Kaduk’s DISCUSS position.

* Section 9. Per “The document requires setting the inner IP TTL to 1, which could be …
[Ballot comment]
I support Ben Kaduk’s DISCUSS position.

* Section 9. Per “The document requires setting the inner IP TTL to 1, which could be used as a DDoS attack vector”, could you please clarify what part(s) of the notional architecture would be impacted (e.g., physical, virtual; and how)?

* Section 9. Per:
  Thus the implementation MUST have
  throttling in place to control the rate of BFD Control packets sent
  to the control plane.  On the other hand, over-aggressive throttling
  of BFD Control packets may become the cause of the inability to form
  and maintain BFD session at scale.  Hence, throttling of BFD Control
  packets SHOULD be adjusted to permit BFD to work according to its
  procedures.

I’m having difficulty parsing the guidance above – it points out the need to throttle and the ramifications of doing so.  Per the last sentence, could you please clarify how the throttling should be calibrated.

* Section 9.  Per “this specification does not raise any additional security issues beyond those of the specifications referred to in the list of normative references”, I recommend being clearer which references you mean (i.e., I’m assuming you don’t mean RFC2119, RFC8174, etc.)

* Editorial Nits:
- Abstract. s/forming up/used to form/

- Section 9. s/such address/such an address/
2019-12-16
09 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2019-12-16
09 Benjamin Kaduk
[Ballot discuss]
I have a few points that I think merit IESG discussion.

(1) I see that several directorate reviewers expressed unease at the
destination …
[Ballot discuss]
I have a few points that I think merit IESG discussion.

(1) I see that several directorate reviewers expressed unease at the
destination (IP and) MAC address assignment procedure for the inner
VXLAN headers, and appreciate that there was extensive on-list
discussion (more than I could follow).  That said, I failed to find a
clear statement of why the current text is believed to be safe, and in
fact my reading of the current text is that the described procedure is
*not* safe.  Pointers to key parts of the WG discusison would be more
than welcome!

To take something of a high-level view of my concerns, if we think of
the VXLAN as being a tunnel between VTEPs that carry encapsulated tenant
traffic, then what we're trying to do is roughly like BFD between VTEPs,
but we want to get fault-detection over as broad a coverage as we can
(the "outermost part of the tunnel"), so we want to have the option of
per-VNI BFD instead of just endpoint-to-endpoint (VTEP-to-VTEP).
However, we end up having to do this by trying to insert a thin filter
into the tenant's address space (i.e., the inner VXLAN header) and pick
out the specific stream of BFD traffic that we're introducing.  This is,
in some sense, a namespace grab in what is conceptually the tenant's
namespace, and we have to be careful that what we do is either
guaranteed to not impact the tenant or well-documented and
compartmentalized (akin to the "well-known URIs").

I've made comments at several places in the document that are more
directly tied to specific pieces of text, but in general, if we assume
that the tenant can add/remove new addresses at will within their VXLAN
abstration, then any attempt to preconfigure by mutual agreement the BFD
addresses to use at the VTEPs or to use the VTEP's normal (outer)
address as the sentinel value seems subject to the tenant coming in and
subsequently trying to use that address, leading to (some of) the
tenant's traffic getting silently filtered and interpreted by the VTEP.
If we were using domain names as identifiers, we could allocate
something under .arpa or similar, but I think our options are more
limited when numerical addresses are used.

The option suggested by the rtg-dir reviewer of always using the
management VNI does not suffer from this namespacing issue, though I
recognize that it does reduce the scope over which fault-detection is
available, for the cases when different VNIs' traffic are routed or
handled differently.

(2) Section 6 says:

                                                        The selection
  of the VNI number of the Management VNI MUST be controlled through
  management plane.  An implementation MAY use VNI number 1 as the
  default value for the Management VNI.  All VXLAN packets received on
  the Management VNI MUST be processed locally and MUST NOT be
  forwarded to a tenant.

It seems like the management VNI concept is something that would apply
to the entire VXLAN deployment and not just to the BFD-using portions;
is this already defined somewhere (in which case we should reference
it), or is it new with this document?  In the latter case wouldn't it be
an update to the core VXLAN spec?  (I note that there are some
procedural hoops to jump through for an IETF-stream document to update
an ISE-stream document...)
2019-12-16
09 Benjamin Kaduk
[Ballot comment]
Section 1

  In the case where a Multicast Service Node (MSN) (as described in
  Section 3.3 of [RFC8293]) resides …
[Ballot comment]
Section 1

  In the case where a Multicast Service Node (MSN) (as described in
  Section 3.3 of [RFC8293]) resides behind a Network Virtualization
  Endpoint (NVE), the mechanisms described in this document apply and
  can, therefore, be used to test the connectivity from the source NVE
  to the MSN.

I'm not sure that I'm parsing "resides behind" properly.  Is the idea
that the multicast traffic starts off at a tenant-system source, hits a
NVE gateway to enter the VXLAN, traverses the VXLAN a bit before getting
to the MSN, and is replicated from the MSN to various NVE termini?  I
think I'd be less confused if this was described as "participates in the
VXLAN" or "is part of the virtualized environment", as the current
"behind" wording makes me think of a firewall-like topology where the
NVE behind which the MSN resides will be decapsulating traffic.

  This document describes the use of Bidirectional Forwarding Detection
  (BFD) protocol to enable monitoring continuity of the path between
  VXLAN VTEPs, performing as Network Virtualization Endpoints, and/or
  availability of a replicator multicast service node.

All the commas here potentially make the parsing ambiguous; assuming
that the "performing as Network Virtualization Endpoints" is just
describing the VXLAN VTEPs, I'd suggest do drop the first comma and
instead join those clauses with "that are".

Section 3

  between the same pair of VTEPs.  BFD packets intended for a VTEP MUST
  NOT be forwarded to a VM as a VM may drop BFD packets leading to a
  false negative.  This method is applicable whether the VTEP is a

[This "MUST NOT" is a very strict requirement, so we have to be sure that
it's achievable without disruption to tenant traffic, per the Discuss
point]

  At the same time, a service layer BFD session may be used between the
  tenants of VTEPs IP1 and IP2 to provide end-to-end fault management.
  In such case, for VTEPs BFD Control packets of that session are
  indistinguishable from data packets.

nit(?): I suggest s/indistinguishable from/regular/ -- the tenants' BFD
sessions are just regular data to the VXLAN infrastructure, though IIUC
a VTEP could, if so inclined, peek inside and "distinguish" them from
non-BFD tenant data based on on heuristics and packet format.

  0:0:0:0:0:FFFF:7F00:0/104 range for IPv6).  There could be a firewall
  configured on VTEP to block loopback addresses if set as the
  destination IP in the inner IP header.  It is RECOMMENDED to allow
  addresses from the loopback range through a firewall only if it is
  used as the destination IP address in the inner IP header, and the
  destination UDP port is set to 3784 [RFC5881].

I think we should reword this to make it clear that the default behavior
is still "block all incoming traffic with loopback destination" and that
the exception is tightly scoped to the encapsulated VXLAN traffic
discussed in this document and the specific destination port *and when
BFD has been configured for the VTEP*.  I note that well-known ports are
not reserved ports, and we have no guarangee that only a BFD
implementation would be listening on port 3784.
I think the rewording would include some phrasing like "RECOMMENDED that
the only firewall exception to allow incoming traffic with destination
address from the loopback range is when [...]", and of course, mention
the need to have BFD configured.

Section 4

  VXLAN packet.  The choice of Destination MAC and Destination IP
  addresses for the inner Ethernet frame MUST ensure that the BFD
  Control packet is not forwarded to a tenant but is processed locally
  at the remote VTEP.  [...]

This has to be 100% reliable, and I think we need to provide some
example mechanism that has that property even if we don't mandate that
it be the only allowed mechanism.

        Destination MAC: This MUST NOT be of one of tenant's MAC
        addresses.  The destination MAC address MAY be the address

But the tenant can start using new MAC addresses at any time!  How is
BFD-over-VXLAN going to dynamically detect and avoid that?

        associated with the destination VTEP.  The MAC address MAY be
        configured, or it MAY be learned via a control plane protocol.
        The details of how the MAC address is obtained are outside the
        scope of this document.

This all talks about the MAC address being relatively static
configuration, but per above, I don't think that's safe in the face of a
MUST-level requirement to avoid conflicting with tenant MAC addresses.

      IP header:

        Destination IP: IP address MUST NOT be of one of tenant's IP
        addresses.  The IP address SHOULD be selected from the range
        127/8 for IPv4, for IPv6 - from the range
        0:0:0:0:0:FFFF:7F00:0/104.  Alternatively, the destination IP
        address MAY be set to VTEP's IP address.

As for MAC addresses, can't the tenant start using new ones at any time?
Loopback is mostly safe in that the tenant generally shouldn't expect
incoming traffic to that destination address ... but what if the tenant
is also using a BFD scheme that expects incoming (single-hop) packets to
loopback as an exception to RFC 1122?
nit: please use a parallel grammatical construction for describing the
IPv4 and IPv6 recommended behavior.

        TTL or Hop Limit: MUST be set to 1 to ensure that the BFD
        packet is not routed within the Layer 3 underlay network.  This
        addresses the scenario when the inner IP destination address is
        of VXLAN gateway and there is a router in underlay which
        removes the VXLAN header, then it is possible to route the
        packet as VXLAN  gateway address is routable address.

nit: the grammar here is a bit wonky; I think the following preserves
the meaning with better grammar:

%        TTL or Hop Limit: MUST be set to 1 to ensure that the BFD
%        packet is not routed within the Layer 3 underlay network.  This
%        addresses the scenario where the inner IP destination address is
%        that of a VXLAN gateway and there is a router in the underlay
%        that removes the VXLAN header; in such cases it is possible for
%        the packet to be routed, as the VXLAN gateway's address is a
%        routable address.

Section 5

  Once a packet is received, VTEP MUST validate the packet.  If the
  Destination MAC of the inner Ethernet frame matches one of the MAC
  addresses associated with the VTEP the packet MUST be processed
  further.  If the Destination MAC of the inner Ethernet frame doesn't

What prevents the scenario where the MAC address associated with the
VTEP is also in use by the tenant?

  match any of VTEP's MAC addresses, then the processing of the
  received VXLAN packet MUST follow the procedures described in
  Section 4.1 [RFC7348].  If the BFD session is using the Management
  VNI (Section 6), BFD Control packets with unknown MAC address MUST
  NOT be forwarded to VMs.

nit: either "an unknown" or "MAC addresses"

  The UDP destination port and the TTL of the inner IP packet MUST be
  validated to determine if the received packet can be processed by
  BFD.

Can you give a pointer to or description of what this validation
consists of?

Section 5.1

  case of VXLAN, the VNI number identifies that logical link.  If BFD
  packet is received with non-zero Your Discriminator, then BFD session
  MUST be demultiplexed only with Your Discriminator as the key.

nits: "If a BFD packet", "then the BFD session"

Section 6

  In most cases, a single BFD session is sufficient for the given VTEP
  to monitor the reachability of a remote VTEP, regardless of the
  number of VNIs.  When the single BFD session is used to monitor the
  reachability of the remote VTEP, an implementation SHOULD choose any
  of the VNIs.  An implementation MAY support the use of the Management

nit: I feel like this is trying to say that the choice is arbitrary and it
doesn't matter which one is picked, but "SHOULD choose any of" is more
of a recommendation to make a choice than guidance on how to make that
choice, as written.

Section 9

I think we need to discuss the risk/potential consequences of a VTEP
failing to properly filter BFD traffic and incorrectly passing it
through to the tenant.

Relatedly, I'd also consider discussing the case of a mixed deployment
where one peer attempts to speak BFD-VXLAN to a peer that does not
implement that mechanism.

  The document requires setting the inner IP TTL to 1, which could be
  used as a DDoS attack vector.  Thus the implementation MUST have

An attack vector on what part of the system?
2019-12-16
09 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-12-16
09 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2019-12-12
09 Tero Kivinen Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Shawn Emery. Submission of review completed at an earlier date.
2019-12-12
09 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-12-10
09 Mirja Kühlewind
[Ballot comment]
UPDATE: I didn't not see a reply to the original issue raised by the TSV-ART review (Thanks Olivier!). Please have a lock and …
[Ballot comment]
UPDATE: I didn't not see a reply to the original issue raised by the TSV-ART review (Thanks Olivier!). Please have a lock and provide a response. I don't think this raises discuss level but I think some clarifications would be good!


This document describes the use of BFD in VXLAN, however, it does not specify any new protocol elements or extension. Therefore I would expect such a document to be informational. The shepherd write-up doesn't give any additional information about why this doc is PS.
2019-12-10
09 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2019-12-10
09 Mirja Kühlewind
[Ballot comment]
This document describes the use of BFD in VXLAN, however, it does not specify any new protocol elements or extension. Therefore I would …
[Ballot comment]
This document describes the use of BFD in VXLAN, however, it does not specify any new protocol elements or extension. Therefore I would expect such a document to be informational. The shepherd write-up doesn't give any additional information about why this doc is PS.
2019-12-10
09 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-12-09
09 Tero Kivinen Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Shawn Emery.
2019-12-05
09 Jean Mahoney Request for Telechat review by GENART is assigned to Erik Kline
2019-12-05
09 Jean Mahoney Request for Telechat review by GENART is assigned to Erik Kline
2019-12-05
09 Tero Kivinen Request for Telechat review by SECDIR is assigned to Shawn Emery
2019-12-05
09 Tero Kivinen Request for Telechat review by SECDIR is assigned to Shawn Emery
2019-12-05
09 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Jürgen Schönwälder
2019-12-05
09 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Jürgen Schönwälder
2019-12-04
09 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2019-12-03
09 Cindy Morgan Placed on agenda for telechat - 2019-12-19
2019-12-03
09 Martin Vigoureux Ballot has been issued
2019-12-03
09 Martin Vigoureux [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux
2019-12-03
09 Martin Vigoureux Created "Approve" ballot
2019-12-03
09 Martin Vigoureux IESG state changed to IESG Evaluation from Waiting for Writeup
2019-12-03
09 Martin Vigoureux Ballot writeup was changed
2019-12-02
09 Jeffrey Haas Revisions done, and ready for IESG review again.
2019-12-02
09 Jeffrey Haas Tag Other - see Comment Log set.
2019-11-29
09 Greg Mirsky New version available: draft-ietf-bfd-vxlan-09.txt
2019-11-29
09 (System) New version approved
2019-11-29
09 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Vengada Govindan , Mallik Mudigonda , Juniper Networks , Sudarsan Paragiri
2019-11-29
09 Greg Mirsky Uploaded new revision
2019-11-01
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-11-01
08 Greg Mirsky New version available: draft-ietf-bfd-vxlan-08.txt
2019-11-01
08 (System) New version approved
2019-11-01
08 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Vengada Govindan , Mallik Mudigonda , Juniper Networks , Sudarsan Paragiri
2019-11-01
08 Greg Mirsky Uploaded new revision
2019-07-01
08 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Vengada Govindan , Mallik Mudigonda , Juniper Networks , Sudarsan Paragiri
2019-07-01
08 Greg Mirsky Uploaded new revision
2019-05-31
07 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Shawn Emery.
2019-05-31
07 Olivier Bonaventure Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Olivier Bonaventure. Sent review to list.
2019-05-31
07 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-05-27
07 Erik Kline Request for Last Call review by GENART Completed: On the Right Track. Reviewer: Erik Kline. Sent review to list.
2019-05-23
07 Joel Halpern Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Joel Halpern. Sent review to list.
2019-05-23
07 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2019-05-23
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shawn Emery
2019-05-23
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shawn Emery
2019-05-22
07 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Joel Halpern
2019-05-22
07 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Joel Halpern
2019-05-22
07 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2019-05-22
07 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-bfd-vxlan-07. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-bfd-vxlan-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 IANA Unicast 48-bit MAC Addresses registry on the IANA MAC Address Block registry page located at:

https://www.iana.org/assignments/ethernet-numbers/

a single, new address will be allocated as follows:

Addresses: [ TBD-at-Registration ]
Usage: BFD for VXLAN
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

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.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-05-22
07 Wesley Eddy Request for Last Call review by TSVART is assigned to Olivier Bonaventure
2019-05-22
07 Wesley Eddy Request for Last Call review by TSVART is assigned to Olivier Bonaventure
2019-05-22
07 David Black Assignment of request for Last Call review by TSVART to David Black was rejected
2019-05-22
07 Wesley Eddy Request for Last Call review by TSVART is assigned to David Black
2019-05-22
07 Wesley Eddy Request for Last Call review by TSVART is assigned to David Black
2019-05-21
07 Jean Mahoney Request for Last Call review by GENART is assigned to Erik Kline
2019-05-21
07 Jean Mahoney Request for Last Call review by GENART is assigned to Erik Kline
2019-05-21
07 Jürgen Schönwälder Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Jürgen Schönwälder. Sent review to list.
2019-05-20
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder
2019-05-20
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder
2019-05-17
07 Amy Vezza IANA Review state changed to IANA - Review Needed
2019-05-17
07 Amy Vezza
The following Last Call announcement was sent out (ends 2019-05-31):

From: The IESG
To: IETF-Announce
CC: draft-ietf-bfd-vxlan@ietf.org, Jeffrey Haas , jhaas@pfrc.org, rtg-bfd@ietf.org, …
The following Last Call announcement was sent out (ends 2019-05-31):

From: The IESG
To: IETF-Announce
CC: draft-ietf-bfd-vxlan@ietf.org, Jeffrey Haas , jhaas@pfrc.org, rtg-bfd@ietf.org, martin.vigoureux@nokia.com, bfd-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (BFD for VXLAN) to Proposed Standard


The IESG has received a request from the Bidirectional Forwarding Detection
WG (bfd) to consider the following document: - 'BFD for VXLAN'
  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
ietf@ietf.org mailing lists by 2019-05-31. 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 Virtual eXtensible Local
  Area Network (VXLAN) tunnels forming up an overlay network.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3193/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks (Informational - Independent Submission Editor stream)



2019-05-17
07 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2019-05-17
07 Martin Vigoureux Requested Last Call review by RTGDIR
2019-05-17
07 Martin Vigoureux Last call was requested
2019-05-17
07 Martin Vigoureux Last call announcement was generated
2019-05-17
07 Martin Vigoureux Ballot approval text was generated
2019-05-17
07 Martin Vigoureux Ballot writeup was generated
2019-05-17
07 Martin Vigoureux IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2019-05-17
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-05-17
07 Greg Mirsky New version available: draft-ietf-bfd-vxlan-07.txt
2019-05-17
07 (System) New version approved
2019-05-17
07 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Vengada Govindan , Mallik Mudigonda , Sudarsan Paragiri , Juniper Networks , bfd-chairs@ietf.org
2019-05-17
07 Greg Mirsky Uploaded new revision
2019-05-02
06 Martin Vigoureux IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2019-03-12
06 Martin Vigoureux IESG state changed to AD Evaluation from Publication Requested
2019-01-02
06 Jeffrey Haas
: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
: Standard, Informational, Experimental, or Historic)? Why is this the proper
: …
: (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?

Standards Track.

: (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:

This document describes the use of the Bidirectional Forwarding
Detection (BFD - RFC 5880) protocol in Virtual eXtensible Local Area Network
(VXLAN) overlay networks.

: Working Group Summary:

This document has received community review with opportunities to comment in
relevant working groups such as BFD, NVO3, and BESS.  It is of interest to
parties that operate VXLAN networks and wish to provide continuity checks for
tunnels interconnecting virtual machines in such networks.

: Was there anything in WG process that is worth noting? For example, was there
: controversy about particular points or were there decisions where the consensus
: was particularly rough?

: Document Quality:
:
: Are there existing implementations of the protocol? Have a significant number
: of vendors indicated their plan to implement the specification? Are there any
: reviewers that merit special mention as having done a thorough review, e.g.,
: one that resulted in important changes or a conclusion that the document had no
: substantive issues? If there was a MIB Doctor, Media Type or other expert
: review, what was its course (briefly)? In the case of a Media Type review, on
: what date was the request posted?

At the time of working group last call, there are two known implementations of
this mechanism.  No special reviewers were required for this document.

: Personnel:
:
: Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Jeffrey Haas, BFD co-chair.
Responsible Area Director: Martin Vigoreux.

: (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.

This document has been through working group review and has received and
incorporated commentary.  Additionally, feedback was solicited within NVO3 and
BESS.  BESS feedback was suggested after WGLC had concluded at the
recommendation of one of the NVO3 reviewers, Anoop Ghanwani, since BESS
provides protocol extensions for provisioning networks related to this
mechanism.

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

No.

: (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.

No.

: (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.

No concerns.

: (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?

Yes.

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

There exists an IPR disclosure, #3193, from Cisco.  This IPR was disclosed
prior to last call and is not seen as an obstacle to document publication.

: (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?

The feedback on the document was solid.  Core participants of the working group
provided feedback on this document.  Additionally, it received review from
parties that normally do not provide last call feedback.

: (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.

: (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.

No nits.

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

The IANA considerations requesting a unicast MAC will require Expert Review as
part of IANA assignment.

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

Yes.

: (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.

Yes.  This document refers to the VXLAN Framework document, RFC 7348, which has
Informational Status.  Since this document is intended to address that
framework, such a reference is appropriate.

: (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 5226).

There is a typo in the IANA considerations that shall be corrected prior to
IESG submission which is intended to identify the IANA Unicast 48-bit MAC
Address registry.  Assignment from this registry requires Expert Review.

: (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.

None.

: (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, etc.

N/A

-- Jeff Haas
2019-01-02
06 Jeffrey Haas Responsible AD changed to Martin Vigoureux
2019-01-02
06 Jeffrey Haas IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-01-02
06 Jeffrey Haas IESG state changed to Publication Requested from I-D Exists
2019-01-02
06 Jeffrey Haas IESG process started in state Publication Requested
2019-01-02
06 Jeffrey Haas Changed consensus to Yes from Unknown
2019-01-02
06 Jeffrey Haas Intended Status changed to Proposed Standard from None
2019-01-02
06 Jeffrey Haas
: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
: Standard, Informational, Experimental, or Historic)? Why is this the proper
: …
: (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?

Standards Track.

: (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:

This document describes the use of the Bidirectional Forwarding
Detection (BFD - RFC 5880) protocol in Virtual eXtensible Local Area Network
(VXLAN) overlay networks.

: Working Group Summary:

This document has received community review with opportunities to comment in
relevant working groups such as BFD, NVO3, and BESS.  It is of interest to
parties that operate VXLAN networks and wish to provide continuity checks for
tunnels interconnecting virtual machines in such networks.

: Was there anything in WG process that is worth noting? For example, was there
: controversy about particular points or were there decisions where the consensus
: was particularly rough?

: Document Quality:
:
: Are there existing implementations of the protocol? Have a significant number
: of vendors indicated their plan to implement the specification? Are there any
: reviewers that merit special mention as having done a thorough review, e.g.,
: one that resulted in important changes or a conclusion that the document had no
: substantive issues? If there was a MIB Doctor, Media Type or other expert
: review, what was its course (briefly)? In the case of a Media Type review, on
: what date was the request posted?

At the time of working group last call, there are two known implementations of
this mechanism.  No special reviewers were required for this document.

: Personnel:
:
: Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Jeffrey Haas, BFD co-chair.
Responsible Area Director: Martin Vigoreux.

: (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.

This document has been through working group review and has received and
incorporated commentary.  Additionally, feedback was solicited within NVO3 and
BESS.  BESS feedback was suggested after WGLC had concluded at the
recommendation of one of the NVO3 reviewers, Anoop Ghanwani, since BESS
provides protocol extensions for provisioning networks related to this
mechanism.

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

No.

: (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.

No.

: (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.

No concerns.

: (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?

Yes.

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

There exists an IPR disclosure, #3193, from Cisco.  This IPR was disclosed
prior to last call and is not seen as an obstacle to document publication.

: (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?

The feedback on the document was solid.  Core participants of the working group
provided feedback on this document.  Additionally, it received review from
parties that normally do not provide last call feedback.

: (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.

: (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.

No nits.

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

The IANA considerations requesting a unicast MAC will require Expert Review as
part of IANA assignment.

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

Yes.

: (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.

Yes.  This document refers to the VXLAN Framework document, RFC 7348, which has
Informational Status.  Since this document is intended to address that
framework, such a reference is appropriate.

: (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 5226).

There is a typo in the IANA considerations that shall be corrected prior to
IESG submission which is intended to identify the IANA Unicast 48-bit MAC
Address registry.  Assignment from this registry requires Expert Review.

: (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.

None.

: (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, etc.

N/A

-- Jeff Haas
2019-01-02
06 Jeffrey Haas Notification list changed to Jeffrey Haas <jhaas@pfrc.org>
2019-01-02
06 Jeffrey Haas Document shepherd changed to Jeffrey Haas
2018-12-26
06 Greg Mirsky New version available: draft-ietf-bfd-vxlan-06.txt
2018-12-26
06 (System) New version approved
2018-12-26
06 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Vengada Govindan , Mallik Mudigonda , Sudarsan Paragiri , Juniper Networks
2018-12-26
06 Greg Mirsky Uploaded new revision
2018-12-21
05 Jeffrey Haas IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-12-19
05 Greg Mirsky New version available: draft-ietf-bfd-vxlan-05.txt
2018-12-19
05 (System) New version approved
2018-12-19
05 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Vengada Govindan , Mallik Mudigonda , Sudarsan Paragiri , Juniper Networks
2018-12-19
05 Greg Mirsky Uploaded new revision
2018-11-23
04 Greg Mirsky New version available: draft-ietf-bfd-vxlan-04.txt
2018-11-23
04 (System) New version approved
2018-11-23
04 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Vengada Govindan , Mallik Mudigonda , Sudarsan Paragiri , Juniper Networks
2018-11-23
04 Greg Mirsky Uploaded new revision
2018-10-17
03 Jeffrey Haas IETF WG state changed to In WG Last Call from WG Document
2018-10-08
03 Greg Mirsky New version available: draft-ietf-bfd-vxlan-03.txt
2018-10-08
03 (System) New version approved
2018-10-08
03 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Vengada Govindan , Mallik Mudigonda , Sudarsan Paragiri , Juniper Networks
2018-10-08
03 Greg Mirsky Uploaded new revision
2018-08-18
02 Greg Mirsky New version available: draft-ietf-bfd-vxlan-02.txt
2018-08-18
02 (System) New version approved
2018-08-18
02 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Vengada Govindan , Mallik Mudigonda , Sudarsan Paragiri , Juniper Networks
2018-08-18
02 Greg Mirsky Uploaded new revision
2018-08-06
01 Greg Mirsky New version available: draft-ietf-bfd-vxlan-01.txt
2018-08-06
01 (System) New version approved
2018-08-06
01 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Vengada Govindan , Mallik Mudigonda , Sudarsan Paragiri , Juniper Networks
2018-08-06
01 Greg Mirsky Uploaded new revision
2018-07-28
00 (System) Document has expired
2018-05-24
Jenny Bui Posted related IPR disclosure: Cisco's Statement about IPR related to draft-ietf-bfd-vxlan
2018-01-24
00 Jeffrey Haas This document now replaces draft-spallagatti-bfd-vxlan instead of None
2018-01-24
00 Greg Mirsky New version available: draft-ietf-bfd-vxlan-00.txt
2018-01-24
00 (System) WG -00 approved
2018-01-24
00 Greg Mirsky Set submitter to "Greg Mirsky ", replaces to draft-spallagatti-bfd-vxlan and sent approval email to group chairs: bfd-chairs@ietf.org
2018-01-24
00 Greg Mirsky Uploaded new revision