Re:draft-xiao-nvo3-bfd-geneve-00

<xiao.min2@zte.com.cn> Fri, 11 October 2019 09:04 UTC

Return-Path: <xiao.min2@zte.com.cn>
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 A4F24120043; Fri, 11 Oct 2019 02:04:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 9KXJ2SbfPn7i; Fri, 11 Oct 2019 02:04:31 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4900D120020; Fri, 11 Oct 2019 02:04:30 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id 363CC962344C33F8C3B5; Fri, 11 Oct 2019 17:04:28 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 26EC15BE42064EEEE327; Fri, 11 Oct 2019 17:04:28 +0800 (CST)
Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl2.zte.com.cn with SMTP id x9B938OL004843; Fri, 11 Oct 2019 17:03:09 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid201; Fri, 11 Oct 2019 17:03:06 +0800 (CST)
Date: Fri, 11 Oct 2019 17:03:06 +0800 (CST)
X-Zmail-TransId: 2afa5da0454a10ce2def
X-Mailer: Zmail v1.0
Message-ID: <201910111703067650761@zte.com.cn>
In-Reply-To: <CACi9rdsDot_UXWN9F4qJevCOpd15TFRXibPAP2=Xrq0-Xm_2Hw@mail.gmail.com>
References: CACi9rdsDot_UXWN9F4qJevCOpd15TFRXibPAP2=Xrq0-Xm_2Hw@mail.gmail.com
Mime-Version: 1.0
From: <xiao.min2@zte.com.cn>
To: <santosh.pallagatti@gmail.com>
Cc: <nvo3@ietf.org>, <rtg-bfd@ietf.org>
Subject: =?UTF-8?B?UmU6ZHJhZnQteGlhby1udm8zLWJmZC1nZW5ldmUtMDA=?=
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn x9B938OL004843
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/8aW7m9zZyqGSLqTDi9fgGyrjGJA>
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: Fri, 11 Oct 2019 09:04:35 -0000

Hi Santosh,






Many thanks for your comments.




Please see my response inline with [XM].



原始邮件



发件人:SantoshPK <santosh.pallagatti@gmail.com>
收件人:nvo3@ietf.org <nvo3@ietf.org>;rtg-bfd WG <rtg-bfd@ietf.org>rg>;
日 期 :2019年10月04日 01:22
主 题 :draft-xiao-nvo3-bfd-geneve-00,



Hello Authors,    Below are the comments on the draft. 

"[Ed.Note]: Use of O bit is still being discussed in the NVO3 WG, so
 the value is undetermined."
[SPK] In some of the implementation that are using BFD over GENEVE have already started using O bit to indicate this is OAM packet and these packets are not being forwarded. We may need to set this in the GENEVE header for compatibility and have extra information for the new implementation. Any thoughts? 
[XM] Fully agree. In the next revision, will change this sentence to "O bit SHOULD be set to 1, which indicates this packet contains a control message."

 "Since multiple BFD sessions may be running between two NVEs, and multiple BFD sessions may be originating or terminating at one NVE, there needs to be a mechanism for demultiplexing received BFD packets to the proper session."


[SPK] BFD VXLAN https://tools.ietf.org/html/draft-ietf-bfd-vxlan-07 drafts there is good discussion going on if we need to define the motivation of the draft on what problem it solves if we have BFD per VNI. There are concerns about the scalability for the same. While we can still have BFD for subset of VNI or we can have BFD per VNI at sedate interval/demand mode and may use P/F sequence to poll when required. We can define supporting use case or when P/F sequence can be really used for example it can be used when data traffic for a given VNI has not been received for some duration. There should also be an option to run BFD session for management VNI along with BFD for per VNI. 

[XM] My thoughts are that BFD sessions should be originated and terminated at VAP which is defined in RFC8014, and it's still undetermined that whether all Tenant Systems attached to a common NVE MUST share a VAP so long as they connect to the same VN, which will result in the decision whether we should allow multiple BFD sessions for the same VNI, in this respect, we can align the statements for both draft-ietf-bfd-vxlan and this draft, alternatively, considering the major difference between VxLAN and Geneve that Geneve supports multi-protocol payload, we can also make different statements for draft-ietf-bfd-vxlan and this draft. Lastly, I don't see much benefit to employ P/F sequence here, certainly I'm open to further discussion on it.


 "Since multiple BFD sessions may be running between two NVEs, and multiple BFD sessions may be originating or terminating at one NVE, there needs to be a mechanism for demultiplexing received BFD packets to the proper session."



[SPK] Above section in subtle way tries to talk about multiple BFD session between same pair but again we need to be clear on what is the motivation?

[XM]  As said above, I tend to believe BFD sessions should be originated and terminated at VAP, and usually one NVE owns multiple VAPs. In addition, I believe the recent discussion over draft-ietf-bfd-vxlan clarifies much of the things in this draft too. 




These are my initial thoughts and would like to see good discussion over this draft. Please do let me know if you think we need to address them. 

[XM] Thanks again for your good thoughts. I agree that we need to address them, in one way or another.




Thanks
Santosh P K 










Best Regards,

Xiao Min