Re: Tsvart last call review of draft-ietf-bfd-vxlan-07

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Thu, 20 June 2019 01:31 UTC

Return-Path: <cpignata@cisco.com>
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 3855E1201D8; Wed, 19 Jun 2019 18:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=jG8+GZeC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zcUcciob
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 KvTpPJJKiq_N; Wed, 19 Jun 2019 18:31:41 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D908120189; Wed, 19 Jun 2019 18:31:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20236; q=dns/txt; s=iport; t=1560994301; x=1562203901; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sdLI6nD+8M0uvuooqVIRuUcqRtyrUnsAdUpEsTrG0yI=; b=jG8+GZeC4uj53Tpd1C4kIBYLzmqSueqgTdnx/5bH4oqSsrm4/F5ZAs6o A0BdJuceQM2qoYI6czqo+1IAcsNsgQctYCO/NkL4QkDZ0ANl7U3qUHcrE OIEKsQ1y9DID22Ftal4s2oW81/AAuviERIauCMNmht1rwKTdFAKLZe8qs 0=;
IronPort-PHdr: =?us-ascii?q?9a23=3ASWiG5x36X+8ihdpIsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQAlX6I/jjcyUSF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAAC94Apd/5JdJa1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBVQUBAQsBgUNQA2pVIAQLKAqEDINHA45ggleJRY1xgS4UgRADVAkBAQE?= =?us-ascii?q?MAQEjCgIBAYRAAheCQSM2Bw4BAwEBBAEBAgEFbYo3DIVKAQEBAwESEREMAQE?= =?us-ascii?q?lBAkFAQQLAgEIGAICJgICAh8RFRACBA4FIoMAAYFqAw4PAQIMom0CgTiIX3G?= =?us-ascii?q?BMYJ5AQEFhQENC4IQAwaBDCgBhHCEJIEegSsXgUA/gRABJx+CTD6CGkcBAQI?= =?us-ascii?q?BgSoBAQsHAQkVGBUMAoJQMoImi3QtgXIujUCMfiw+CQKCEYZIiR8Eg2gbgie?= =?us-ascii?q?HBoQKhWCCUoFLlEGBaopRgwgCBAIEBQIOAQEFgVcELWdxcBU7KgGCQT6CAws?= =?us-ascii?q?Yg02FFIU+AXIBgSiLTA8XgQsBgSABAQ?=
X-IronPort-AV: E=Sophos;i="5.63,394,1557187200"; d="scan'208";a="578066144"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jun 2019 01:31:39 +0000
Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x5K1VdD4032678 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Jun 2019 01:31:39 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Jun 2019 20:31:39 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Jun 2019 20:31:38 -0500
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 19 Jun 2019 21:31:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sdLI6nD+8M0uvuooqVIRuUcqRtyrUnsAdUpEsTrG0yI=; b=zcUcciobTsAsQ49XtVkbRwouOe5FRixX5eGXZPceqArf7r48hK9eD6io7jRfHPZiUX+zq2VrRVEizsjYzxW/c0IjghgEwlvfLIogDnngyq3Q6NpXHkloNriyxNFUz88tqKHHIfwdo+xvEp1hm62nCfvBvaBzWnqYu27dmyDtaV8=
Received: from BL0PR11MB3028.namprd11.prod.outlook.com (20.177.204.138) by BL0PR11MB3489.namprd11.prod.outlook.com (20.177.206.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.13; Thu, 20 Jun 2019 01:31:32 +0000
Received: from BL0PR11MB3028.namprd11.prod.outlook.com ([fe80::ec33:f4c1:227a:fcb3]) by BL0PR11MB3028.namprd11.prod.outlook.com ([fe80::ec33:f4c1:227a:fcb3%5]) with mapi id 15.20.1987.014; Thu, 20 Jun 2019 01:31:32 +0000
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: "tsv-art@ietf.org" <tsv-art@ietf.org>, rtg-bfd WG <rtg-bfd@ietf.org>, "draft-ietf-bfd-vxlan.all@ietf.org" <draft-ietf-bfd-vxlan.all@ietf.org>, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>, IETF list <ietf@ietf.org>
Subject: Re: Tsvart last call review of draft-ietf-bfd-vxlan-07
Thread-Topic: Tsvart last call review of draft-ietf-bfd-vxlan-07
Thread-Index: AQHVJMqh+O1Bih53oEC7haZ3x5KaoKajsLYAgAAPSACAAAYzgA==
Date: Thu, 20 Jun 2019 01:31:32 +0000
Message-ID: <8237FE8D-937E-4BCB-B1A3-89C2B3CDC51C@cisco.com>
References: <155933149484.6565.7386019489022348116@ietfa.amsl.com> <CA+RyBmXu-F0cWDkBydE_aJaVpUv=k1otqUCc7NdRW4pnBK3tgA@mail.gmail.com> <14822B96-D3C6-495E-8661-198068F72ABA@cisco.com> <CA+RyBmUMbW=B3FNmqiQNmMLM27f9G+MeRL5MrAnCd04EP3vmrQ@mail.gmail.com>
In-Reply-To: <CA+RyBmUMbW=B3FNmqiQNmMLM27f9G+MeRL5MrAnCd04EP3vmrQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.104.11)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com;
x-originating-ip: [173.38.117.68]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1795be73-86b5-431c-d92d-08d6f51f06b7
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BL0PR11MB3489;
x-ms-traffictypediagnostic: BL0PR11MB3489:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <BL0PR11MB3489D13816BEBE06CBAAFE94C7E40@BL0PR11MB3489.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0074BBE012
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(396003)(346002)(39860400002)(136003)(189003)(199004)(51444003)(86362001)(81156014)(6306002)(26005)(8676002)(229853002)(76116006)(73956011)(66946007)(6512007)(64756008)(6486002)(33656002)(186003)(66476007)(66556008)(76176011)(6436002)(305945005)(6916009)(99286004)(256004)(7736002)(53546011)(6506007)(4326008)(66446008)(102836004)(6246003)(14444005)(5024004)(53936002)(8936002)(66066001)(14454004)(6116002)(3846002)(30864003)(966005)(57306001)(81166006)(50226002)(1411001)(54906003)(68736007)(5660300002)(478600001)(316002)(71190400001)(71200400001)(446003)(25786009)(486006)(11346002)(2616005)(36756003)(476003)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB3489; H:BL0PR11MB3028.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: z3EDCIQ9YxP5oCw5lqWMHU+64UIDCwhsI7lleyeuOUVaEWQbRqklIF6yHsYZL/ZfjP7VY/l7ESjf7BXAdzOKmtQkh/bYcYYetS40Cgpu/G2UsFTxGLqwVp7qMD4TDjtSgrWZieIgIw/LX+UazwVSBDpjdJXWwLBwZL9L/riMjNBfdW959QJ2kWUoL3YOw0S30EwMMdjZIVmJyH8WIlNOI0yxXsAbU2hrD8qze1l1TlsJNIXF3C/PcvLBdd2m4pebLlQYpWn0x5PWFtxhU71QOzXJHB5lWTc3X4cBeQAqqbMbJj3fN5D9+31y4Q4EETw7p1Vqzcimi0J69O5NPEGDy1g/aAUxr+IjDKkOMn3Xbi88cUme0JtFE1qAFUOdiSLMevdOs1Ey7+Qr1idYooqbofiozcn8CbJwj60nCaNMnQs=
Content-Type: text/plain; charset="utf-8"
Content-ID: <606C5F6132D3B14CB38CF26F3E019EDB@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1795be73-86b5-431c-d92d-08d6f51f06b7
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2019 01:31:32.3887 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: cpignata@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3489
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/5EJkC7F71lQOoJfIf7QRr32Y1tA>
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: Thu, 20 Jun 2019 01:31:45 -0000

Hello, Greg,

> On Jun 19, 2019, at 9:09 PM, Greg Mirsky <gregimirsky@gmail.com>; wrote:
> 
> Hi Carlos,
> thank you for reminding of our continued discussion with Joel. We are seeking comments from VXLAN experts and much appreciate if you have insights on VXLAN to share.
> I've got some clarifying questions before I can respond to you.

Sure.

> To which stage of the three-way handshake you refer as "initial demultiplexing"? I couldn't find this term in RFC 5880.

“Initial demultiplexing" is a well-known term in BFD, referring to the "demultiplexing of the initial packets", BFD Control packet with YourDisc being zero.

In RFC 5880, see Section 6.3.
https://tools.ietf.org/html/rfc5880#section-6.3

   The method of demultiplexing the initial packets (in which Your
   Discriminator is zero) is application dependent, and is thus outside
   the scope of this specification.

Since initial demultiplexing is indeed application specific, different for one-hop versus multi-hop and dependent upon whether a single or multiple sessions are allowed between a pair of endpoints, I added below two other relevant citations, from application specific BFD specs:
1. https://tools.ietf.org/html/rfc5883#section-4 
2. https://tools.ietf.org/html/rfc5882#section-6


> Regarding the applicability of the Echo mode, thank you for pointing to the need for stricter terminology, the Echo mode, as defined in RFC 5880, is underspecified and it will require additional standardization.

No. BFD Echo is not underspecified in RFC 5880.

Please read S5: https://tools.ietf.org/html/rfc5880#section-5

   BFD Echo packets are sent in an encapsulation appropriate to the
   environment.  See the appropriate application documents for the
   specifics of particular environments.


BFD Echo is application dependent. 

Therefore, for example, single-hop BFD in RFC 5881 specifies BFD Echo for that application.

Hence, my question stands: why is this draft claiming BFD Echo is out of scope for this BFD application document?


> Future drafts may explore and define how the Echo mode of BFD is used over VXLAN tunnels.
> 

See above.

> Will review and respond to the remaining questions soon.

Thank you. 

The "remaining questions" are still all the questions below :-)

Best,

Carlos.

> 
> Regards,
> Greg
> 
> 
> On Thu, Jun 20, 2019 at 9:14 AM Carlos Pignataro (cpignata) <cpignata@cisco.com>; wrote:
> Hi,
> 
> I have not reviewed this draft before, but triggered by this email, and briefly scanning through a couple of sections, it is unclear to me how some of the mechanics work.
> 
> There are some major issues with the Mac usage and association, as Joel Halpern mentioned in his Rtg Dir review.
> 
> And, additionally, please consider the following comments and questions:
> 
> 
> 1. Underspecification for initialization and initial demultiplexing.
> 
> This document allows multiple BFD sessions between a single pair of VTEPs:
> 
>    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.
> 
> The implication of this is that BFD single-hop initialization procedures will not work. Instead, there is a need to map the initial demultiplexing.
> 
> This issue is explained in RFCs 5882 and 5883: https://tools.ietf.org/html/rfc5883#section-4 and https://tools.ietf.org/html/rfc5882#section-6
> 
> Section 5.1 says:
> 
>    For such packets, the BFD session MUST be identified
>    using the inner headers, i.e., the source IP, the destination IP, and
>    the source UDP port number present in the IP header carried by the
>    payload of the VXLAN encapsulated packet.  The VNI of the packet
>    SHOULD be used to derive interface-related information for
>    demultiplexing the packet.
> 
> But this does not really explain how to do the initial demultiplexing. Does each BFD session need to have a separate inner source IP address? Or source UDP port? And how ofter are they recycled or kept as state? How are these mapped?
> Equally importantly, which side is Active?
> And what if there’s a race condition with both sides being Active and setting up redundant sessions?
> 
> 1.b. By the way, based on this, using S-BFD [RFC 7880] might be easier to demux.
> 
> 
> 2. Security
> 
> This document says that the TTL in the inner packet carrying BFD is set to 1. However, RFC 5880 says to use GTSM [RFC 5082], i.e., a value of 255..
> 
> Why is GTSM not used here?
> 
> 
> 3. ECMP and fate-sharing under-specification:
> 
> Section 4.1. says:
> 
>    The Outer IP/UDP
>    and VXLAN headers MUST be encoded by the sender as defined in
>    [RFC7348].
> 
> 
> And RFC 7348 says:
> 
>       -  Source Port:  It is recommended that the UDP source port number
>          be calculated using a hash of fields from the inner packet --
>          one example being a hash of the inner Ethernet frame's headers.
>          This is to enable a level of entropy for the ECMP/load-
>          balancing of the VM-to-VM traffic across the VXLAN overlay.
>          When calculating the UDP source port number in this manner, it
>          is RECOMMENDED that the value be in the dynamic/private port
>          range 49152-65535 [RFC6335].
> 
> 
> Based on this, depending on the hashing calculation, the outer source UDP port can be different leading to different ECMP treatment. Does something else need to be specified here in regards to the outer UDP source port?
> 
> 
> 4. Section 7 says that “ Support for echo BFD is outside the scope of this document”. 
> 
> Assuming this means “BFD Echo mode”, why is this out of scope? If this is a single logical hop underneath VXLAN, what’s preventing the use of Echo? Echo’s benefits are huge.
> 
> 
> 5. Terminology
> 
>    Implementations SHOULD ensure that the BFD
>    packets follow the same lookup path as VXLAN data packets within the
>    sender system.
> 
> What is a “look up path within a sender system”?
> 
> 
> 6. Deployment scenarios
> 
> S3 says:
>    Figure 1 illustrates the scenario with two servers, each of them
>    hosting two VMs.  The servers host VTEPs that terminate two VXLAN
> […]
>                      Figure 1: Reference VXLAN Domain
> 
> 
> However, RFC 7348 Figure 3 lists that as one deployment scenario, not as “the scenario” and “The Reference VXLAN Domain”.
> 
> Best,
> 
> Carlos.
> 
>> On Jun 17, 2019, at 12:58 AM, Greg Mirsky <gregimirsky@gmail.com>; wrote:
>> 
>> Hi Oliver,
>> thank you for your thorough review, clear and detailed questions. My apologies for the delay to respond. Please find my answers below in-line tagged GIM>>.
>> 
>> Regards,
>> Greg
>> 
>> On Fri, May 31, 2019 at 12:38 PM Olivier Bonaventure via Datatracker <noreply@ietf.org>; wrote:
>> 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 ?
>> GIM>> RFC 5880 set the scope of the fault detection of BFD protocol as 
>>    ... the bidirectional path between two forwarding engines, including
>>    interfaces, data link(s), and to the extent possible the forwarding
>>    engines themselves ...
>> The requirement aimed to the forwarding engine of a BFD system that transmits BFD control packets over VXLAN tunnel.
>> 
>> 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.
>> GIM>> I think that ECMP environment is more likely to be experienced by a transit node in the underlay. If the BFD session is used to monitor the specific underlay path, then, I agree, we should explain that using the VXLAN payload information to draw path entropy may cause data and BFD packets following different underlay routes. But, on the other hand, that is the case for OAM and fault detection in all overlay networks in general.
>> 
>> 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 ?
>> GIM>> In principle, BFD Demand mode may be used to monitor p2p paths as well, I agree, will re-word to more assertive:
>>  The asynchronous mode of BFD, as defined in [RFC5880],
>>  is used to monitor a p2p VXLAN tunnel.
>> 
>> NVE has not been defined before and is not in the terminology.
>> GIM>> Will add to the Terminology and expand as:
>> NVE        Network Virtualization Endpoint 
>> 
>> This entire section is not easy to read for an outsider.
>> 
>> Section 3
>> 
>> VNI has not been defined
>> GIM>> Will add to the Terminology section:
>> VNI    VXLAN Network Identifier (or VXLAN Segment ID)
>> 
>> Figure 1 could take less space
>> GIM>> Yes, can make it bit denser. Would the following be an improvement?
>>  
>>       +------------+-------------+
>>       |        Server 1          |
>>       | +----+----+  +----+----+ |
>>       | |VM1-1    |  |VM1-2    | |
>>       | |VNI 100  |  |VNI 200  | |
>>       | |         |  |         | |
>>       | +---------+  +---------+ |
>>       | Hypervisor VTEP (IP1)    |
>>       +--------------------------+
>>                             |
>>                             |   +-------------+
>>                             |   |   Layer 3   |
>>                             +---|   Network   |
>>                                 +-------------+
>>                                     |
>>                                     +-----------+
>>                                                 |
>>                                          +------------+-------------+
>>                                          |    Hypervisor VTEP (IP2) |
>>                                          | +----+----+  +----+----+ |
>>                                          | |VM2-1    |  |VM2-2    | |
>>                                          | |VNI 100  |  |VNI 200  | |
>>                                          | |         |  |         | |
>>                                          | +---------+  +---------+ |
>>                                          |      Server 2            |
>>                                          +--------------------------+
>> 
>> 
>> Section 4
>> 
>> I do not see the benefits of having one paragraph in Section 4 followed by only
>> Section 4.1
>> GIM>> Will merge Section 4.1 into 4 with minor required re-wording:
>> 4.  BFD Packet Transmission over VXLAN Tunnel
>> 
>>    BFD packet MUST be encapsulated and sent to a remote VTEP as
>>    explained in this section.  Implementations SHOULD ensure that the
>>    BFD packets follow the same lookup path as VXLAN data packets within
>>    the sender system.
>> 
>>    BFD packets are encapsulated in VXLAN as described below.  The VXLAN
>>    packet format is defined in Section 5 of [RFC7348].  The Outer IP/UDP
>>    and VXLAN headers MUST be encoded by the sender as defined in
>>    [RFC7348].
>> 
>> 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 ?
>> GIM>> After further discussion, authors decided to remove the request for the dedicated MAC address allocation. Only the MAC address of the remote VTEP must be used as the destination MAC address in the inner Ethernet frame. Please check the attached diff between the -07 and the working versions or the working version of the draft.
>> 
>> It is unclear from this section whether IPv4 inside IPv6 and the opposite
>> should be supported or not.
>> GIM>> Any combination of outer IPvX and inner IPvX is possible.
>> 
>> 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 ?
>> GIM>> As I've mentioned earlier, authors have decided to remove the use of the dedicated MAC address for BFD over VXLAN.
>> 
>> Section 5.1
>> 
>> Is this a modification to section 6.3 of RFC5880 ? This is not clear
>> GIM>> I think that this section is not modification but the definition of the application-specific procedure that is outside the scope of RFC 5880:
>>    The method of demultiplexing the initial packets (in which Your
>>    Discriminator is zero) is application dependent, and is thus outside
>>    the scope of this specification.
>> 
>> Section 9
>> 
>> The sentence " Throttling MAY be relaxed for BFD packets
>>    based on port number." is unclear.
>> GIM>> Yes, thank you for pointing to this. The updated text, in the whole paragraph, is as follows:
>> NEW TEXT:
>>    The document requires setting the inner IP TTL to 1, which could be
>>    used as a DDoS attack vector.  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.
>> <draft-ietf-bfd-vxlan-08.txt><Diff_ draft-ietf-bfd-vxlan-07.txt - draft-ietf-bfd-vxlan-08.txt.html>
>