From nobody Wed May 15 13:53:11 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEEF120124 for ; Wed, 15 May 2019 13:53:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155795359003.30483.990485963928541297.idtracker@ietfa.amsl.com> Date: Wed, 15 May 2019 13:53:10 -0700 From: IETF Secretariat Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 20:53:10 -0000 Changed milestone "Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard", resolved as "Done". URL: https://datatracker.ietf.org/wg/bfd/about/ From nobody Thu May 16 08:30:15 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7265120181; Thu, 16 May 2019 08:30:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rrahman@cisco.com, rtg-bfd@ietf.org, martin.vigoureux@nokia.com, bfd-chairs@ietf.org Subject: bfd - New Meeting Session Request for IETF 105 X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155802061377.19724.8454815746970928411.idtracker@ietfa.amsl.com> Date: Thu, 16 May 2019 08:30:13 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 15:30:14 -0000 A new meeting session request has just been submitted by Reshad Rahman, a Chair of the bfd working group. --------------------------------------------------------- Working Group Name: Bidirectional Forwarding Detection Area Name: Routing Area Session Requester: Reshad Rahman Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 25 Conflicts to Avoid: First Priority: idr grow rtgwg bess lisp netmod netconf Second Priority: bier spring mpls teas pals sfc Third Priority: ccamp People who must be present: Jeffrey Haas Reshad Rahman Martin Vigoureux Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri May 17 09:44:30 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0422A1200B2; Fri, 17 May 2019 09:44:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-vxlan-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <155811146191.26250.12715823833150103059@ietfa.amsl.com> Date: Fri, 17 May 2019 09:44:22 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 16:44:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF. Title : BFD for VXLAN Authors : Santosh Pallagatti Sudarsan Paragiri Vengada Prasad Govindan Mallik Mudigonda Greg Mirsky Filename : draft-ietf-bfd-vxlan-07.txt Pages : 10 Date : 2019-05-17 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-07 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 17 12:49:36 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B56812006B; Fri, 17 May 2019 12:49:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" Subject: Last Call: (BFD for VXLAN) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: draft-ietf-bfd-vxlan@ietf.org, Jeffrey Haas , jhaas@pfrc.org, rtg-bfd@ietf.org, martin.vigoureux@nokia.com, bfd-chairs@ietf.org Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155812257436.26319.10114692868500612908.idtracker@ietfa.amsl.com> Date: Fri, 17 May 2019 12:49:34 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 19:49:35 -0000 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) From nobody Tue May 21 00:28:48 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBCF1201CA; Tue, 21 May 2019 00:28:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder_via_Datatracker?= To: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-vxlan.all@ietf.org, ietf@ietf.org Subject: Opsdir last call review of draft-ietf-bfd-vxlan-07 X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= Message-ID: <155842371303.2459.12357511675299405749@ietfa.amsl.com> Date: Tue, 21 May 2019 00:28:33 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 07:28:34 -0000 Reviewer: Jürgen Schönwälder Review result: Has Issues I only have a very limited understanding of VXLAN ands BFD technology. Hence, some of my question may look odd to the insiders. - RFC 7348 defining VXLAN is informational, why would BFD for VXLAN be standards track? - Section 2.1 "Terminology" expands acronyms but it does say where these "terms" are actually defined. Some pointers to the relevant RFCs may be useful. - Section 3 starts talking about VNI numbers but acronym VNI has not been introduced before. I assume VNI = VXLAN Network Identifier. - I am not familiar with VXLAN but I wonder how the endpoints addresses are obtained in practice. This BFD document says for example "The details of how the MAC address of the destination VTEP is obtained are outside the scope of this document." Well, OK, but how does this work? Is there a document where this is explained? Well, I am actually less concerned about how the inner address is obtained, I think I am more urgently missing how the VTEP determines the remote tunnel endpoint address. - Why do you need a special MAC address? The text says I can use this address or the address of the destination VTEP but there is no reasoning when to use what or why a dedicated address is needed. - What is a 'reasonable upper bound' on the number of BFD sessions that can be created between the same pair of VTEPs? 1? 2? 8? 64? 256? 4096? How does the choice of this upper bound impact security? - Which BFD mode is assumed to be used, asynchronous or demand? Or does this not matter for this usage of BFD, i.e., both work just fine and will be interoperable? - Why is echo BFD outside the scope of this document? Can I just turn on echo mode or will extra specifications be needed? From nobody Thu May 23 15:06:39 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A002C12014E; Thu, 23 May 2019 15:06:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Joel Halpern via Datatracker To: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-vxlan.all@ietf.org, ietf@ietf.org Subject: Rtgdir last call review of draft-ietf-bfd-vxlan-07 X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Joel Halpern Message-ID: <155864919758.8626.11137277913302380197@ietfa.amsl.com> Date: Thu, 23 May 2019 15:06:37 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 22:06:38 -0000 Reviewer: Joel Halpern Review result: Has Issues Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: ddraft-ietf-bfd-vxlan-07 Reviewer: your-name Review Date: date IETF LC End Date: date-if-known Intended Status: copy-from-I-D Summary: This document does not appear to be ready for publication as a Proposed Standard RFC. Major issues: The scoping of the BFD usage is unclear. In places, this looks like it is intended to be used by the underlay service provider, who will monitor the connectivity between VTEPs. In other places it seems to be aimed at monitoring individual VNIs. This is made worse when the packet format is laid out. The inner packet is an Ethernet Packet with an IP packet (with UDP, with BFD). This means that it is a tenant packet. The IP address is a tenant IP. But the diagram shows this as being the IP address of the VTEP. Which is not a tenant entity. There is further confusion as to whether the processing is driven by the VNI the packet arrived with, or the VNI is ignored. Minor Issues: N/A Nits: N/A From nobody Mon May 27 13:35:29 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CEC12016E; Mon, 27 May 2019 13:35:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-vxlan.all@ietf.org, ietf@ietf.org Subject: Genart last call review of draft-ietf-bfd-vxlan-07 X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <155898931713.535.11384466531705238791@ietfa.amsl.com> Date: Mon, 27 May 2019 13:35:17 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 20:35:18 -0000 Reviewer: Erik Kline Review result: On the Right Track I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-bfd-vxlan-07 Reviewer: Erik Kline Review Date: 2019-05-27 IETF LC End Date: 2019-05-31 IESG Telechat date: Not scheduled for a telechat Summary: If my understanding is correct (which it may well not be), this document places restrictions on the inner Ethernet and IP layer deployment that previously may not have been present. My reading if this document is that the outer IP header and the inner IP header have the same VTEP src and dst IPs. The outer and inner Ethernet headers have the same source MAC and may have the same dst MAC. Is this correct? If so, this would mean that the VTEP's MAC address (or the special dest MAC) cannot be used within the VXLAN network (or at least not on the same host. Similarly, it appears that the VTEP's IP addresses are no longer free to be used within the encapsulated VXLAN VNI. Do I understand this correctly? Was this always the case? If there is a document defining restrictions that VTEPs place on the inner VXLAN segment, that might be good to reference. Failing that, I think I would like to see some discussion of alternatives that were rejected with reasons behind their rejection. One possible solution might be to use "impossible" Ethernet addresses and "impossible" IP addresses in the inner packet. For example, a source IP address of all ones or all zeros would be very unlikely to ever be a valid IP packet. I'm not 100% sure, but I suspect that a source MAC of all ones would also never really be treated as valid. Clever use of multicast IP and Ethernet addresses in the source fields might also be sufficient to render the inner packet "invalid" in the sense that it would never collide with legitimate traffic. If I have misread this document, or VTEPs are already placing constraints on the inner VXLAN environment similar to those above, then this review should instead be treated as "Ready with Nits". Major issues: Only my concern/misunderstanding described above. Minor issues: None. Nits/editorial comments: * The document generally does a really good job of Expanding Acronyms At First Use (EAAFU) -- very much appreciated. In section 1 though, NVE is used without accompanying expansion, I think. * There is no 4.2 so maybe sections 4 and 4.1 could just be section 4. From nobody Thu May 30 08:47:04 2019 Return-Path: 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 A82E812010F for ; Wed, 29 May 2019 17:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ne8rMY-IPmjX for ; Wed, 29 May 2019 17:51:26 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58CC1200D7 for ; Wed, 29 May 2019 17:51:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 31303B81B17; Wed, 29 May 2019 17:51:23 -0700 (PDT) To: manav.bhatia@alcatel-lucent.com, mach@huawei.com, sboutros@cisco.com, mbinderb@cisco.com, jhaas@juniper.net, db3546@att.com, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, jhaas@pfrc.org, rrahman@cisco.com Subject: [Editorial Errata Reported] RFC7130 (5741) X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: anoop@alumni.duke.edu, rtg-bfd@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190530005123.31303B81B17@rfc-editor.org> Date: Wed, 29 May 2019 17:51:23 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Thu, 30 May 2019 08:47:03 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 00:51:29 -0000 The following errata report has been submitted for RFC7130, "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5741 -------------------------------------- Type: Editorial Reported by: Anoop Ghanwani Section: 1 Original Text ------------- While there are native Ethernet mechanisms to detect failures (802.1ax, .3ah) Corrected Text -------------- While there are native Ethernet mechanisms to detect failures (802.1AX, 802.3ah) Notes ----- ax should be capitalized. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7130 (draft-ietf-bfd-on-lags-04) -------------------------------------- Title : Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces Publication Date : February 2014 Author(s) : M. Bhatia, Ed., M. Chen, Ed., S. Boutros, Ed., M. Binderberger, Ed., J. Haas, Ed. Category : PROPOSED STANDARD Source : Bidirectional Forwarding Detection Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu May 30 08:47:11 2019 Return-Path: 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 5519E120118 for ; Wed, 29 May 2019 17:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 B8ctLfz9OqxB for ; Wed, 29 May 2019 17:54:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 412071200D7 for ; Wed, 29 May 2019 17:54:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0535EB81C46; Wed, 29 May 2019 17:54:49 -0700 (PDT) To: manav.bhatia@alcatel-lucent.com, mach@huawei.com, sboutros@cisco.com, mbinderb@cisco.com, jhaas@juniper.net, db3546@att.com, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, jhaas@pfrc.org, rrahman@cisco.com Subject: [Editorial Errata Reported] RFC7130 (5742) X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: anoop@alumni.duke.edu, rtg-bfd@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190530005449.0535EB81C46@rfc-editor.org> Date: Wed, 29 May 2019 17:54:49 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Thu, 30 May 2019 08:47:03 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 00:54:54 -0000 The following errata report has been submitted for RFC7130, "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5742 -------------------------------------- Type: Editorial Reported by: Anoop Ghanwani Section: 2.3 Original Text ------------- Micro-BFD packets SHOULD always be sent untagged. However, when the LAG is operating in the context of IEEE 802.1q or IEEE 802.qinq, Corrected Text -------------- Micro-BFD packets SHOULD always be sent untagged. However, when the LAG is operating in the context of IEEE 802.1Q or IEEE 802.1ad, Notes ----- q should be capitalized. The IEEE standard for QinQ is IEEE 802.1ad. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7130 (draft-ietf-bfd-on-lags-04) -------------------------------------- Title : Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces Publication Date : February 2014 Author(s) : M. Bhatia, Ed., M. Chen, Ed., S. Boutros, Ed., M. Binderberger, Ed., J. Haas, Ed. Category : PROPOSED STANDARD Source : Bidirectional Forwarding Detection Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri May 31 12:38:24 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3516120189; Fri, 31 May 2019 12:38:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Olivier Bonaventure via Datatracker To: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-vxlan.all@ietf.org, ietf@ietf.org Subject: Tsvart last call review of draft-ietf-bfd-vxlan-07 X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Olivier Bonaventure Message-ID: <155933149484.6565.7386019489022348116@ietfa.amsl.com> Date: Fri, 31 May 2019 12:38:14 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 19:38:15 -0000 Reviewer: Olivier Bonaventure Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. I have only limited knowledge of VXLAN and do not know all subtleties of BFD. This review is thus more from a generalist than a specialist in this topic. Major issues Section 4 requires that " Implementations SHOULD ensure that the BFD packets follow the same lookup path as VXLAN data packets within the sender system." Why is this requirement only relevant for the lookup path on the sender system ? What does this sentence really implies ? Is it a requirement that the BFD packets follow the same path as the data packet for a given VXLAN ? I guess so. In this case, the document should discuss how Equal Cost Multipath could affect this. Minor issues Section 1 You write "The asynchronous mode of BFD, as defined in [RFC5880], can be used to monitor a p2p VXLAN tunnel." Why do you use the word can ? It is a possibility or a requirement ? NVE has not been defined before and is not in the terminology. This entire section is not easy to read for an outsider. Section 3 VNI has not been defined Figure 1 could take less space Section 4 I do not see the benefits of having one paragraph in Section 4 followed by only Section 4.1 Section 4.1 The document does not specify when a dedicated MAC address or the MAC address of the destination VTEP must be used. This could affect the interoperability of implementations. Should all implementations support both the dedicated MAC address and the destination MAC address ? It is unclear from this section whether IPv4 inside IPv6 and the opposite should be supported or not. Section 5. If the received packet does not match the dedicated MAC address nor the MAC address of the VTEP, should the packet be silently discarded or treated differently ? Section 5.1 Is this a modification to section 6.3 of RFC5880 ? This is not clear Section 9 The sentence " Throttling MAY be relaxed for BFD packets based on port number." is unclear.