draft-ietf-bfd-vxlan IESG status
Jeffrey Haas <jhaas@pfrc.org> Mon, 27 January 2020 22:12 UTC
Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5F03A0F32; Mon, 27 Jan 2020 14:12:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjbvxgkg-n3y; Mon, 27 Jan 2020 14:11:58 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 260623A0F31; Mon, 27 Jan 2020 14:11:51 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id B68E61E2F7; Mon, 27 Jan 2020 17:17:05 -0500 (EST)
Date: Mon, 27 Jan 2020 17:17:05 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: iesg@ietf.org
Cc: Greg Mirsky <gregimirsky@gmail.com>, bfd-chairs@ietf.org, draft-ietf-bfd-vxlan@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>
Subject: draft-ietf-bfd-vxlan IESG status
Message-ID: <20200127221705.GB17622@pfrc.org>
References: <157660542458.26499.3977878811671361973.idtracker@ietfa.amsl.com> <CA+RyBmUPCrj_ahxa098vj__niNndjbOJEccA-KwoopgKp5C51Q@mail.gmail.com> <CAMMESszAax2AjRvw4wSS1ydBsDhEepyz3XASach46rxzGknX4g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMMESszAax2AjRvw4wSS1ydBsDhEepyz3XASach46rxzGknX4g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/WmHLpLkL0OT_PVmPC-XTlDi7b4M>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jan 2020 22:12:03 -0000
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. --- 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. --- 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. --- Open Issue 4: "multicast service node" text (COMMENT via Benjamin K.) Proposed Action: Incorporate suggested text from Benjamin K. to clarify text in -10. --- 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!) --- 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. --- 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. --- 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. --- 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. --- 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. --- 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. --- 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. --- 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. --- Open Issue 14: "nits ... then the BFD session" (COMMENT via Benjamin K.) Proposed Action: Accept grammar correction. --- 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. --- 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. --- (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. --- 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. --- Open Issue 19: "Section 4...FCS" (COMMENT via Eric V.) Proposed Action: Accept suggested change to "Outer Ethernet FCS"? --- 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. --- (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." --- (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. --- (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" --- 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? --- (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. --- Open Issue 26: "loopback range through a firewall" (COMMENT via Barry L.) Proposed Action: Accept suggested rewording. --- Open Issue 27: "Section 4...addresses the scenario" (COMMENT via Barry L.) Proposed Action: This sentence needs to be reworded. --- (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
- Alvaro Retana's Discuss on draft-ietf-bfd-vxlan-0… Alvaro Retana via Datatracker
- Re: Alvaro Retana's Discuss on draft-ietf-bfd-vxl… Greg Mirsky
- Re: Alvaro Retana's Discuss on draft-ietf-bfd-vxl… Alvaro Retana
- Re: draft-ietf-bfd-vxlan IESG status Greg Mirsky
- Re: draft-ietf-bfd-vxlan IESG status Greg Mirsky
- draft-ietf-bfd-vxlan IESG status Jeffrey Haas
- Re: draft-ietf-bfd-vxlan IESG status Greg Mirsky
- Re: draft-ietf-bfd-vxlan IESG status Alvaro Retana
- Re: draft-ietf-bfd-vxlan IESG status Greg Mirsky
- Re: draft-ietf-bfd-vxlan IESG status Jeffrey Haas
- Re: draft-ietf-bfd-vxlan IESG status Greg Mirsky
- Re: draft-ietf-bfd-vxlan IESG status Benjamin Kaduk
- Re: draft-ietf-bfd-vxlan IESG status Alvaro Retana
- Re: draft-ietf-bfd-vxlan IESG status Greg Mirsky
- Re: draft-ietf-bfd-vxlan IESG status Jeffrey Haas
- Re: draft-ietf-bfd-vxlan IESG status Alvaro Retana
- Re: draft-ietf-bfd-vxlan IESG status Greg Mirsky
- Re: draft-ietf-bfd-vxlan IESG status Greg Mirsky
- BFD for vxlan Destination MAC field (was Re: draf… Jeffrey Haas
- Re: draft-ietf-bfd-vxlan IESG status Jeffrey Haas
- Re: BFD for vxlan Destination MAC field (was Re: … Greg Mirsky
- Re: BFD for vxlan Destination MAC field (was Re: … Greg Mirsky
- Re: BFD for vxlan Destination MAC field (was Re: … Greg Mirsky
- Re: BFD for vxlan Destination MAC field (was Re: … Donald Eastlake
- Re: BFD for vxlan Destination MAC field (was Re: … Jeffrey Haas
- Re: BFD for vxlan Destination MAC field (was Re: … Greg Mirsky
- Re: BFD for vxlan Destination MAC field (was Re: … Jeffrey Haas
- Re: BFD for vxlan Destination MAC field (was Re: … Donald Eastlake
- Re: BFD for vxlan Destination MAC field (was Re: … Greg Mirsky