Subject: Re: draft-ietf-bfd-vxlan IESG status

From: Jeffrey Haas <[email-masked]>
Date: Tue, 16 Jun 2020 17:10:57 -0400

[Apologies on further delay.  The best way to cause unexpected work is to
offer a personal deadline to have something done.]

Greg and the IESG,

This update is vs. version -12 of the draft.

General summary: Almost ready to go.  Multiple issues are resolved.  Pending
items flagged here should be addressed.  Once addressed, we'll ask the IESG
to take this up again.

On Mon, Jan 27, 2020 at 05:17:05PM -0500, Jeffrey Haas wrote:
> Much like the BFD Working Group discussion on the BFD for vxlan feature, the
> IESG review for the draft has reached a stage where it is difficult to
> determine what the related actions are.  (IESG take note for tools
> discussion!)
> 
> This email is an attempt to kick the conversation back into gear.
> 
> My notes here are based on the current status of the document tracked here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ballot/
> 
> My comments on the draft are based on the -10 version of the draft as
> currently published.
> 
> ---
> 
> Open Issue 1: Discussion on TTL/Hop Limit = 1
> 
> Proposed Action: Greg has proposed text he will send to the working group
> suggesting GTSM procedures be utilized.  The expected concern is how this
> impacts existing implementations.

This issue is resolved.

> 
> ---
> 
> Open Issue 2: Document Status should be Informational rather than Proposed
> Standard.
> 
> Proposed Action: Greg should make the document Informational.  Prior WG
> discussion suggested that we don't really care what level it should be at,
> and had actually requested IESG guidance long ago via our AD.

This action is pending.

> ---
> 
> Open Issue 3: dst IP/MAC assignment procedures for inner VXLAN headers.
> (DISCUSS via Benjamin K.)  Specifically per-VNI form rather than strictly
> VTEP-to-VTEP mode.
> 
> Issue Comment 1 (Benjamin K.): This is "a namespace grab in what is
> essentially the tenant's namespace".
> 
> Issue Comment 2 (Jeff H.): Joel Halpern flagged this repeatedly as well as
> part of directorate review.
> 
> Issue Comment 3 (Benjamin K.): "management VNI does not suffer from this
> namespacing issue".
> 
> Issue Comment 4 (Jeff H./Benjamin K.): The concept of a "management VNI" is
> not supported by existing standards work, but is accepted as a common
> implementation behavior.
> 
> Issue Comment 5: A significant exploration of this set of issues is
> documented in the following thread:
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/SfXfu3pCh9BxaRFrXbEOgGt6xjE/
> 
> Proposed Action: Limit the Internet-Draft's applicability to verifying
> connectivity to the management VNI.  "All other uses of the specification to
> test toward other vxlan endpoints are out of scope."
> 
> In reviewing the thread, my reading of the comments from Santosh, Anoop, and
> Dinesh are effectively "don't break existing implementations".  There is
> acknowledge among those in the discusssion that numbering space collisions
> between the protocol codepoints chosen to run as endpoints for the BFD for
> vxlan session and the tenant space are undesirable.  It is generally agreed
> in the thread (IMO) that for the "management VNI" case that this is not
> problematic, although the details of provisioning are still specific to the
> implementation.  
> 
> By setting the case aside where a test to a specific VTEP may have tenant
> namespace collisions, the document can be cleaned of a lot of unnecessary
> edge cases that are difficult to generally resolve.  Implementations that
> may choose to permit sessions to non-management VNIs will have need to
> resolve how to deal with collisions.  

The suggested action was taken.  The document now refers only to the
management VNI, and offers a default value for that VNI number.
This should resolve a significant number of issues.

> 
> ---
> 
> Open Issue 4: "multicast service node" text (COMMENT via Benjamin K.)
> 
> Proposed Action: Incorporate suggested text from Benjamin K. to clarify text
> in -10.

This issue is resolved.

> ---
> 
> Open Issue 5: Comma parsing issue (COMMENT via Benjamin K.)
> 
> Proposed Action: Accept Benjamin's suggested changes.  (RFC Editor will win
> the day here though!)

This action is pending.

> ---
> 
> Open Issue 6: "Section 3, MUST NOT be forwarded to a VM" (COMMENT via
> Benjamin K.)
> 
> Proposed Action: The fate of this issue is tied to Open Issue 3.
> If the proposal is limited solely to management VNI, this text is not
> relevant and may be deleted.

This action is still open.  

> ---
> 
> Open Issue 7: "::FFFF:7F00:0/104 IPv6 range" (COMMENT via Benjamin K.)
> 
> Proposed Action: I believe this issue's fate is similarly tied to Open Issue 3.
> If the proposal is limited solely to management VNI, this text is not
> relevant and may be deleted.

This action is still pending. 

> ---
> 
> Open Issue 8: "Section 4: MUST ensure that the BFD Control packet is not
> forwarded to a tenant but is processed locally at the remote VTEP" (COMMENT
> via Benjamin K.)
> 
> Proposed Action: I believe this issue's fate is similarly tied to Open Issue 3.
> If the proposal is limited solely to management VNI, this text is not
> relevant and may be deleted.

This action is still pending and perhaps requires further discussion.

Benjamin's point was:
"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."

The motivation here was that when this specification was intended to address
a fully generalized BFD for vxlan for arbitrary VNIs, there was a strong
need to say "do not forward the BFD traffic to the tenant".

For the now default scenario of only the management VNI, this text may be
adequate.  Benjamin should look at the current document and decide if the
scenario is still of concern.

> ---
> 
> Open Issue 9: "Destination MAC: This MUST NOT be of one of tenant's MAC
> addresses." (COMMENT via Benjamin K.)
> 
> Proposed Action: I believe this issue's fate is similarly tied to Open Issue 3.
> If the proposal is limited solely to management VNI, this text is not
> relevant and may be deleted.

In -12, we now have the following text:
"Destination MAC: since a Management VNI is the VNI that does
not have any tenants, the value of this field is not analyzed
by the receiving VTEP."

For the management VNI, this text is true.  However, it likely requires a
value that is described in the specification.

Proposed solution: A MAC value should be chosen that is well known and the
text would become:

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

SHOULD might need to be MUST.  Since a partial motivation for permitting the
flexibility in the specification to NOT use the management VNI is desired,
MUST might be inappropriate.

> ---
> 
> Open Issue 10: "The details of how the MAC address is obtained are outside
> the scope of this document." (COMMENT via Benjamin K.)
> 
> Proposed Action: None.  Reason 1: If we go with only the management VNI,
> provisioning remains an easy answer.  Reason 2: If we go with VNI-to-VNI
> mode, it's not unreasonable for the environment to claim a MAC address.
> This is no different than a switch itself.  Collisions would be handled via
> updated configuration.

This issue is resolved by only describing the management VNI.

> ---
> 
> Open Issue 11: "dst IP header MUST NOT be one of tenant's" (COMMENT via Benjamin
> K.)
> 
> Comment 1 (Jeff H.): The loopback range as a destination would serve to
> catch BFD traffic in either VNI-to-VNI or VTEP-to-VTEP mode.  I think this
> is more clearly understood after the IESG reviewed the existing mechanisms
> using the loopback address range in existing RFCs.
> 
> Proposed Action: I believe this issue's fate is similarly tied to Open Issue 3.
> If the proposal is limited solely to management VNI, this text is not
> relevant and may be deleted.

In the current text for -12, the host loopback range serves to provide the
necessary mechanism.  Given the restricted scope of the the management VNI,
I believe the unchanged text is sufficient.

> ---
> 
> Open Issue 12: "Section 5, BFD dst mac collision with tenant" (COMMENT via
> Benjamin K.)
> 
> Proposed Action: I believe this issue's fate is similarly tied to Open Issue 3.
> If the proposal is limited solely to management VNI, this text is not
> relevant and may be deleted.

I believe the text in -12 describing only the management VNI resolves this
issue.

> ---
> 
> Open Issue 13: "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." (COMMENT via Benjamin K.)
> 
> Proposed Action: Provide reference to RFC 5880/5881 sections covering
> existing BFD procedure.  Do not copy and paste from them.

The text in -12 is:

"Validation of TTL / Hop Limit of the inner IP packet, as long as the
related considerations for BFD control packet demultiplexing and
authentication, is performed as described in Section 5 [RFC5881]."

This text is slightly awkward English, but I believe covers the intent.
I suggest rewording this to:

"The received packet's inner IP payload is then validated according to
Sections 4 and 5 in [RFC5881]."

> ---
> 
> Open Issue 14: "nits ... then the BFD session" (COMMENT via Benjamin K.)
> 
> Proposed Action: Accept grammar correction.

This issue is no longer relevant in -12.

> ---
> 
> Open Issue 15: "Section 6" (COMMENT via Benjamin K.)
> 
> Proposed Action: I believe this issue's fate is similarly tied to Open Issue 3.
> If the proposal is limited solely to management VNI, this text is not
> relevant and may be deleted.  In particular, this section attempts to
> justify VNI-to-VNI mode poorly.  

This issue is no longer relevant in -12.

> ---
> 
> Open Issue 16: "Section 9" regarding mis-forwarding/filtering of BFD traffic
> toward tenant (COMMENT via Benjamin K.)
> 
> Proposed Action: I believe this issue's fate is similarly tied to Open Issue 3.
> If the proposal is limited solely to management VNI, this text is not
> relevant and may be deleted.

I believe the new text, describing only the management VNI, obviates this
comment.

> ---
> 
> (Alvaro's DISCUSSes are covered by the above.)
> 
> (Alvaro acknowledged that his COMMENTS were cleared on December 25, 2019)
> 
> (Eric V's DISCUSS points are covered by prior open points regarding:
>  - TTL (see Open Issue 1)
>  - Mapped IPv6 addresses were covered in discussion with IESG about existing
>    RFC behavior for this range.
>  - The mismatch between document IANA action and shepherd writeup is an
>    artifact of document changes since the shepherd writeup had happened.
>    The document currently has no open IANA actions.
>  - Section 9 issues about TTL were addressed in -09 of the document.)
> 
> ---
> 
> Open Issue 17: "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?" (COMMENT via
> Eric V.)
> 
> Comment 1 (Jeff H.): RFC 5881 addresses single-hop "that is associated with
> an incoming interface".  vxlan requires additional demultiplexing based on
> packet contents and thus the comment is not fully applicable.  This document
> (draft-ietf-bfd-vxlan) is intended to cover the vxlan protocol encapsulation
> for BFD.
> 
> Proposed Action: No action required.

No action was taken.

> ---
> 
> Open Issue 18: "BFD session per VXLAN VNI" (COMMENT via Eric V.)
> 
> Proposed Action: I believe this issue's fate is similarly tied to Open Issue 3.
> If the proposal is limited solely to management VNI, this text is not
> relevant and may be deleted.

This issue should be resolved by only describing the management VNI in -12.

> ---
> 
> Open Issue 19: "Section 4...FCS" (COMMENT via Eric V.)
> 
> Proposed Action: Accept suggested change to "Outer Ethernet FCS"?

This action is pending.

> ---
> 
> Open Issue 20: "using the src mac as the dst mac" (COMMENT via Eric V.)
> 
> Proposed Action: ?  I'm unclear what the proposal and comment is here.

It is unclear what action was requested.

> ---
> 
> (TTL issues noted by Eric V. addressed in Open Issue 1.)
> 
> ---
> 
> Open Issue 21: "throttling of BFD control packets" (COMMENT via Roman D.)
> 
> Proposed Action: The section on throttling is written in a confusing manner
> and is in need of a re-write.
> 
> In particular, what's unclear is what is doing the throttling and why?  If
> the comment is intended to say that some forms of rate-limiting of the vxlan
> traffic between two systems is in place that it may impact BFD, it should
> say that.  And perhaps once said, omit giving "advice".  "If it hurts, don't
> do that."

These issues were addressed by referring to existing security considerations
in RFCs 5880, 5881, and 7348.

> ---
> 
> (COMMENTS from Roman D. addressed in -10 and earlier:
>  - citing specific security considerations applicability
>  - nits
> )
> 
> (COMMENT from Suresh K. covered in open issues above.)
> 
> (COMMENT from Warren K. regardig loopback network range discussed above.)
> 
> ---
> 
> Open Issue 22: "terminology isn't" (COMMENT via Warren K.)
> 
> Proposed Action: Either rename the section "acronyms used in this document"
> or expand the section to cover the terminology.

This action is still pending.

> ---
> 
> (Mirja K. indirects a number of issues to "See Olivier's TSV-ART review",
> which is present in this message:
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/y3xDkvpT-ZodhcaBRHNOSDVByA8/)
> 
> Open Issue 23: "follow same lookup path needs more explanation"
> 
> Proposed Action: Add a sentence explaining that this is to ensure that the
> encapsulated BFD traffic requires following the equivalent data path to
> protect the resource"

Section 5 now contains:
"BFD packets MUST be encapsulated and sent to a remote VTEP as
explained in this section.  Implementations SHOULD ensure that the
BFD packets follow the same forwarding path as VXLAN data packets
within the sender system."

I believe this addresses the issue.

> ---
> 
> Open Issue 24: "Discuss ECMP considerations" (TSV-ART via Olivier B.)
> 
> Comment 1 (Jeff H.): I believe this came up in the message thread, but base
> BFD also has similar unclear ECMP behaviors.  The working group has avoided
> trying to standardize anything regarding ECMP since it gets very
> implementation specific.  Some vendors will go out of their way to do things
> to mitigate ECMP considerations when BFD is in place; others simply ignore
> it.
> 
> Proposed Action: Unclear.  None?

No action has been taken here.  I believe this is appropriate.

> ---
> 
> (Minor issues report by Olivier B. that have been addressed in -10 or
>  earlier:
>  - p2p vxlan tunnel wording
>  - VNI has been added to section 2.1
>  - "figure 1 could take less space" - not addressed.
>  - section 4 flattened to remove unnecessary sub-sections
>  - "dedicated mac" address no longer in current versions of document
>  - "v4 in v6 / v6 in v4, etc." - intentionally unspecified since arbitrary
>    encapsulations are supported by specification.  Implementations may have
>    specific limitations.
>  - "section 5 dedicated mac" no longer in the document
>  - "decapsulation procedure reference" I believe has been clarified.)
> 
> (Mirja's comment on status is covered by Open Issue 2)
> 
> (Comments from Barry L. addressed:
>  - "forming up"
>  - bfd packet/vtep packets/vteps plurality agreement.
>  - "may be configured" clarified.
>  - Section 4.1 "of")
> 
> ---
> 
> Open Issue 25: "leading to a false negative" (COMMENT via Barry L.)
> 
> Proposed Action: The underlying concern in this sentence is that BFD packets
> must not be mis-delivered to VMs since there will be no BFD machinery
> present in that VM to execute the BFD procedures and thus sessions will
> drop.  Possible action is to simply delete this sentence since it
> prematurely anticipates procedures later described in the document.

This action is still pending.

> 
> ---
> 
> Open Issue 26: "loopback range through a firewall" (COMMENT via Barry L.)
> 
> Proposed Action: Accept suggested rewording.

This action is still pending.

> ---
> 
> Open Issue 27: "Section 4...addresses the scenario" (COMMENT via Barry L.)
> 
> Proposed Action: This sentence needs to be reworded.

This issue is addressed by referring to GTSM mechanisms per other
discussion.

> ---
> 
> (Comments from Adam R. addressed:
>  - Form of ipv6 mapped address.
>  - Usage of loopback network  addresses compared to prior RFCs discussed in
>    thread with IESG.)
> 
> 
> 
> 
> 
> -- Jeff

>From jhaas as part of reviewing -12:

---

Section 7 should be rewritten as:
7. BFD Echo Function

Support for the BFD Echo function [RFC5880], Section 3.2, is outside the
scope of this document.

--- 

There remain a few minor English article agreement issues in the text, but
these can be deferred to the RFC Editor's preference for resolution.

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 16 Jun 2020 18:05:01 -0700

Hi Jeff,
thank you for providing continued support and guidance. Please find my
notes in-lined under tag GIM>>. Attached are the new working version and
its diff to -12. There are two remaining Open Issues - 7 and 9. I much
appreciate your considerations and suggestions.

Regards,
Greg

> > and had actually requested IESG guidance long ago via our AD.
GIM>> Done

> > Proposed Action: Accept Benjamin's suggested changes.  (RFC Editor will
GIM>> Followed Benjamin's suggestion and replaced come with "that are":
   This document describes the use of Bidirectional Forwarding Detection
   (BFD) protocol to enable monitoring continuity of the path between
   VXLAN VTEPs that are performing as Network Virtualization Endpoints,
   and/or availability of a replicator MSN using a Management VNI
   (Section 4).

> This action is still open.
GIM>> Deleted the sentence.

> This action is still pending.
GIM>> There are two references to this IPv6 range. I think that the
document should give a recommendation on what address to use as the
destination IP address. As we've discussed with  Adam Roach, only ::ffff:
127.0.0.1/128 has host loopback meaning in IPv6. I propose to change
throughout the text from "one of the addresses from IPv6 range" to "::ffff:
127.0.0.1/128 for IPv6".

> scenario is still of concern.
GIM>> No changes for now.

> MUST might be inappropriate.
GIM>> Accepted the suggested text. I agree that the flexibility to not use
the Management VNI is permitted in the specification and thus SHOULD in the
text is consistent with that scenario. How would we pick the MAC address?

> I believe the unchanged text is sufficient.
GIM>> Thank you.

> Sections 4 and 5 in [RFC5881]."
GIM>> This text is the result of my discussion with Carlos. I'm accepting
Jeff's proposal and hope Carlos will agree.

> > Proposed Action: Accept suggested change to "Outer Ethernet FCS"?
GIM>> In Figure 2 s/Outer FCS/Outer Ethernet FCS/

> This action is still pending.
GIM>> Change the title of the sub-section s/Terminology/Acronyms/

> This action is still pending.
GIM>> The sentence is now removed in response to Open Issue 6.

> This action is still pending.
GIM>> I think that Barry's comment has been already captured in the -12.
Barry wrote:
 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.
The current text:
   It is RECOMMENDED to allow
   addresses from the loopback range through a firewall only if they are
   used as the destination IP addresses in the inner IP header and the
   destination UDP port is set to 3784 [RFC5881].

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 16 Jun 2020 21:42:40 -0700

Hi Jeff,

A big "thank you!" for continuing to track the many issues, I think I have
a sense for the effort involved, but it makes a huge difference.
Since I was mentioned, a couple comments inline.

> This should resolve a significant number of issues.

Indeed, I think that simplifies things on many fronts.

> scenario is still of concern.

I will defer looking at the document until the other couple things are
ready, but I'm pretty confident that this should be fine.  The normal
mechanisms used to keep the management VNI's traffic out of tenant systems
will suffice to keep BFD traffic out of tenant systems, so there shouldn't
be a need to specify additional mechanism here.

> have no dedicated MAC address for decapsulated traffic.  The value X:X:X:X:X

s/no/one/ or s/no/a/?

> MUST might be inappropriate.

IIRC there was mentioned way upstream a range of MAC addresses that we can
make allocations from and the procedure to do so.  Personally I would
prefer MUST but I have a creative enough imagination that I won't object to
SHOULD.

> I believe the unchanged text is sufficient.

That sounds right; I'm pretty sure that concerns over destination IP only
came into play when we were using non-management VNIs.

Thanks again,

Ben

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 17 Jun 2020 09:37:42 -0700

On June 16, 2020 at 5:01:57 PM, Jeffrey Haas wrote:

Hi!

...
> > impacts existing implementations.

As I had mentioned before [1], the use of 255 should reference
rfc5881: the requirement is one from the base spec, not a new one
here.

Suggestion>

   TTL or Hop Limit: MUST be set to 255 in accordance with [RFC5881].

I am clearing my DISCUSS.

Thanks!!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/rtg-bfd/aiJW3KjYevY83wEDwVj488FSVl0/

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 17 Jun 2020 11:40:41 -0700

Hi Alvaro,
thank you for the suggestion. I have a question. The current version
references RFC 5082:
         TTL or Hop Limit: MUST be set to 255 in accordance with the
         Generalized TTL Security Mechanism [RFC5082].
RFC 5881, while stating the requirement for the TTL or Hop Limit value,
refers to RFC 5082 as the text that explains the benefits of using 255 on a
single IP link. In both documents, RFC 5082 is listed as a normative
reference. Would using RFC 5082 be acceptable or you suggest changing it to
RFC 5881?

Regards,
Greg

On Wed, Jun 17, 2020 at 9:37 AM Alvaro Retana <[email-masked]>
wrote:

> [1]
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/aiJW3KjYevY83wEDwVj488FSVl0/
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 17 Jun 2020 15:52:14 -0400

Greg,

> On Jun 16, 2020, at 9:05 PM, Greg Mirsky <[email-masked]> wrote:

[...]

Sorry, the issue is from the IESG ballot at https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ballot/:

>    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
> 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*.

So, the question is what should be done about packet drop or firewalls?

My opinion is one possible action for this is to drop the text.  For this feature to work, traffic will be arriving with packets destined to these well known ranges.  If you want the feature to work, they must be permitted to come through.  Rather than mention "if you have it", the related actions are implied by things necessary to implement it.

>> Proposed solution: A MAC value should be chosen that is well known and th=
> e
>> text would become:
>> 
>> flexibility in the specification to NOT use the management VNI is desired=
> ,

I am out of my area of expertise and I was hoping someone in the IESG can offer a fix. :-)  I am copying Donald Eastlake since he's the designated expert for the IANA MAC address block.

Donald, review of the thread may be useful, but tersely the need is to have a well known MAC address that can be placed in this vxlan PDU that is literally a placeholder of "not to be used for forwarding".  The packet arrives at the endpoint and, if not immediately accepted, would be dropped.

If there is no well known MAC that could be used for such a behavior, perhaps an address from the IANA block may be used?

While I suspect the IANA mac documentation range could be used, IANA may not appreciate that.

-- Jeff

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 17 Jun 2020 12:59:39 -0700

Greg:

Rfc5881 already specifies using GTSM…this document depends on rfc5881, so
the reference should be the BFD behavior.

Alvaro.

On June 17, 2020 at 2:40:52 PM, Greg Mirsky ([email-masked]) wrote:

Hi Alvaro,

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 17 Jun 2020 13:36:13 -0700

Hi Alvaro,
thank you for the clarification. I will update the reference by using the
text you've suggested.

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 17 Jun 2020 14:12:02 -0700

Hi Jeff,
thank you for the additional details. I've top-posted the discussion thread
regarding a firewall, VTEP, and drop rules. I recall that the relevant text
was suggested based on deployment experience. I will try to update it along
the suggested lines:

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.

Would the following update make it clearer:
OLD TEXT:
  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 they are
   used as the destination IP addresses in the inner IP header and the
   destination UDP port is set to 3784 [RFC5881].
NEW TEXT:
  If a firewall
   configured on VTEP packets with their destination IP addresses in the
   inner IP header set to one of the loopback addresses listed above will be
   dropped.  To allow BFD work as described in this specification, it is
   RECOMMENDED to use an exception rule to allow addresses from the
   loopback range through a firewall only if they are used as the
   destination IP addresses in the inner IP header and the destination
   UDP port is set to 3784 [RFC5881].
Also, would splitting this text into a paragraph help to keep clear?

If the proposed update is not better than the current text, let's remove it
altogether.

Regards,
Greg

On Wed, Jun 17, 2020 at 12:52 PM Jeffrey Haas <[email-masked]> wrote:

> Sorry, the issue is from the IESG ballot at
> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ballot/:
>
> My opinion is one possible action for this is to drop the text.  For this
> feature to work, traffic will be arriving with packets destined to these
> well known ranges.  If you want the feature to work, they must be permitted
> to come through.  Rather than mention "if you have it", the related actions
> are implied by things necessary to implement it.
>
>
>
> >
> >>>
> I am out of my area of expertise and I was hoping someone in the IESG can
> offer a fix. :-)  I am copying Donald Eastlake since he's the designated
> expert for the IANA MAC address block.
>
> Donald, review of the thread may be useful, but tersely the need is to
> have a well known MAC address that can be placed in this vxlan PDU that is
> literally a placeholder of "not to be used for forwarding".  The packet
> arrives at the endpoint and, if not immediately accepted, would be dropped.
>
> If there is no well known MAC that could be used for such a behavior,
> perhaps an address from the IANA block may be used?
>