Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-oam-07
Greg Mirsky <gregimirsky@gmail.com> Wed, 22 November 2023 17:14 UTC
Return-Path: <gregimirsky@gmail.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330CFC151081; Wed, 22 Nov 2023 09:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.863
X-Spam-Level:
X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjdrhRRdSMKM; Wed, 22 Nov 2023 09:14:23 -0800 (PST)
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D399C15106F; Wed, 22 Nov 2023 09:14:23 -0800 (PST)
Received: by mail-yb1-xb30.google.com with SMTP id 3f1490d57ef6-d9ca471cf3aso6552572276.2; Wed, 22 Nov 2023 09:14:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700673262; x=1701278062; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=48WEi/+IcmlkZzNKCSPddKNxUfmW7edlCofeqyVF0Ws=; b=lXNa9ddGmn7i/w4UQ4tDfT3nf0S4Uok0ypx5wxqasua9xOZhe7+6ikpiUF805ycRf+ tw6kn83paOQMl8uM/v7bOmrln4zCmlujJdHL8QFCx7QfORg83bodq8t1gU38x3GdYtRI qc3VPuX2Vb74NytTOVCMbHdWaQ5DDtC1EuILbma1ESJKCCsKjaXejtrYsFd7A594y68o Tpgsq7M/sT9tnnLbxBxklUUufmTnxi1EiXHscCl2oi5nyjgfejqr3g+l1wKKYeLxcAYY jS9ZZjezIjy6/JgzWNE7Kqh7oBaD1QkCADCEVNYDAs4ZlnXIhvekmzbUoJKEiA+xe0mU Q/PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700673262; x=1701278062; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=48WEi/+IcmlkZzNKCSPddKNxUfmW7edlCofeqyVF0Ws=; b=xDL2wWiGaLDSqfEkcZrwEu1pCmiCLHiVRio0fg1CH/IH9m9D10MYEv9YFFC5PL2jNq blW15Vu3yC8sikQXq941Qk1TO9Cdxb5Rm5ek4SEE/HrAGFzCWE9jOtPvW+gF7F/BH8Q2 XYaJKUWwMb3tG39MIm6zssi1A596GvF3d7vXcCCQIYoL0Zx1+f2c7iUwfO3F6UWE7HHg UeeWpR7aEpDPlpschXVpjJ/6mocSk6HxGwTEo70d46GJuDPR1lxf+FrGhH/yPEougJyf uJ3JZ3CoN616m2ng30pQRgKhec/iQCZdyzQsJSAE9j+Cv3t9HuOkZpWm+uNo2fHghFw2 4XOQ==
X-Gm-Message-State: AOJu0Yx9kQqjkvJWLAProbJzFgSsuxzPjL4f/YtvC7c5Hk4rqgx4m2oi UDHeqE7oVM7CyhsNm9PLtcMdoh1gyLPiHmj/JIc=
X-Google-Smtp-Source: AGHT+IHgLMRuPP09+hX7K9iGcHk1tUdfcMyzobnax4lBiqXzmOetbSUx6T2pLWIe5RPvg58/ThZsMXkN9OeQ08J3aZ8=
X-Received: by 2002:a05:6902:11cc:b0:da0:659f:c4fe with SMTP id n12-20020a05690211cc00b00da0659fc4femr3930865ybu.8.1700673259770; Wed, 22 Nov 2023 09:14:19 -0800 (PST)
MIME-Version: 1.0
References: <CA+RyBmUQV_pe+vpmj3TUcebFjrGyvrYX9_TdbonS+imSN5dP9w@mail.gmail.com> <202311201446110425046@zte.com.cn>
In-Reply-To: <202311201446110425046@zte.com.cn>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 22 Nov 2023 09:14:07 -0800
Message-ID: <CA+RyBmXtCTPZt3OZZV8Z2Wq3f=rLT5T7s9VZCRiynqiMp6h-AQ@mail.gmail.com>
To: xiao.min2@zte.com.cn
Cc: aldrin.ietf@gmail.com, nvo3@ietf.org, nvo3-chairs@ietf.org, draft-ietf-nvo3-geneve-oam@ietf.org
Content-Type: multipart/mixed; boundary="000000000000877e7a060ac0d9e1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/wlWM5DHSh8HHOfax9xJIeSvhJM4>
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-oam-07
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Nov 2023 17:14:27 -0000
Hi Xiao Min, thank you for your patience and detailed explanation of your concerns. Please find my notes below tagged GIM4>>. Attached, please find the updated working version of the draft. Regards, Greg On Sun, Nov 19, 2023 at 10:56 PM <xiao.min2@zte.com.cn> wrote: > Hi Greg, > > > Thanks for the reply. > > Please see inline with [XM-4]>>>. > Original > *From: *GregMirsky <gregimirsky@gmail.com> > *To: *肖敏10093570; > *Cc: *Sam Aldrin <aldrin.ietf@gmail.com>;NVO3 <nvo3@ietf.org>; > nvo3-chairs@ietf.org <nvo3-chairs@ietf.org>; > draft-ietf-nvo3-geneve-oam@ietf.org <draft-ietf-nvo3-geneve-oam@ietf.org>; > *Date: *2023年11月18日 06:56 > *Subject: **Re: [nvo3] Working Group Last Call and IPR Poll for > draft-ietf-nvo3-geneve-oam-07* > Hi Xiao Min, > thank you for your thorough review. Please find my notes below tagged > GIM3>>. Attached, please find the updated working version . > > Regards, > Greg > > On Mon, Oct 30, 2023 at 11:49 PM <xiao.min2@zte.com.cn> wrote: > >> Hi Greg, >> >> >> Thank you for the reply and proposed updates. >> >> Please see inline with [XM-3]>>>. >> >> >> Original >> *From: *GregMirsky <gregimirsky@gmail.com> >> *To: *肖敏10093570; >> *Cc: *aldrin.ietf@gmail.com <aldrin.ietf@gmail.com>;nvo3@ietf.org < >> nvo3@ietf.org>;nvo3-chairs@ietf.org <nvo3-chairs@ietf.org>; >> draft-ietf-nvo3-geneve-oam@ietf.org <draft-ietf-nvo3-geneve-oam@ietf.org >> >; >> *Date: *2023年10月26日 10:43 >> *Subject: **Re: [nvo3] Working Group Last Call and IPR Poll for >> draft-ietf-nvo3-geneve-oam-07* >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> Hi Xiao Min, >> thank you for your thoughtful consideration of the proposed changes and >> the proposed update. I've accepted your idea with a minor editorial >> modification: >> OLD TEXT: >> In the first case, a communication problem between Network >> Virtualization Edge (NVE) device A and NVE C was observed. The >> underlay, e.g., IP network, forwarding is working well but the Geneve >> connection is unstable for all tenants of NVE A and NVE C. >> Troubleshooting and localization of the problem can be done >> irrespective of the VNI value. >> NEW TEXT: >> In the first case, consider when a communication problem >> between Network Virtualization Edge (NVE) device A and NVE C exists. >> Upon the investigation, the operator discovers that the forwarding in >> the underlay, e.g., the IP network, is working well. Still, the >> Geneve connection is unstable for all NVE A and NVE C tenants. >> Detection, troubleshooting, and localization of the problem can be >> done irrespective of the VNI value. >> [XM-3]>>> It looks good to me. >> >> >> I hope that you agree with the new version. Attached, please find the new >> working version of the draft and the diff highlighting all the updates. >> >> [XM-3]>>> It seems some of my previous comments are missed. Repeat them >> as below. >> >> In Section 2, it says "In the latter case, the test packet MUST use the same Geneve encapsulation as the data packet (except for the value in the Protocol Type field [RFC8926]), including the value in the Virtual Network Identifier (VNI) field." Why does it say "except for the value in the Protocol Type field [RFC8926]"? I don't think so. >> >> GIM3>> If the value of the Protocol Type field indicates Ethernet payload > (0x6558), then IPv4 or IPv6 encapsulated OAM packets must be identified by > a different respective values in the Protocol Type field. Wou;d you agree? > > [XM-4]>>> I suspect that you confuse the second case with the first case. > In the sentence I quoted, the context is "In the latter case", i.e., the > second case, in this case whether the Protocol Type or the VNI would be the > same between the test packet and the data packet. Please refer > to draft-ietf-nvo3-bfd-geneve. > GIM4>> I clearly missed the context. Thanks for pointing it out to me. I think that the sentence can be removed altogether. WDYT? > >> In Section 2.1, it says "The ICMP echo reply is encapsulated in Geneve as specified in Section 2.2...", that's incorrect, do you mean Section 3? >> >> GIM3>> I think that the reference to Section 2.2 is correct as that > section defines the encapsulation of an OAM packet in Geneve using the > Management VNI. Section 3 only lists references to the relevant RFCs. > > [XM-4]>>> Note that the title of Figure 2 of Section 2.2 is "Geneve IP/UDP > Encapsulation of an Active OAM Packet", however the ICMP echo reply is > *NOT* a UDP-based OAM packet. > GIM4>> This part has changed, and the updated text is as follows: NEW TEXT: Active OAM over a Management VNI in the Geneve network uses an IP encapsulation. Protocols such as BFD [RFC5880] or STAMP [RFC8762] use UDP transport. The destination UDP port number in the inner UDP header (Figure 2) identifies the OAM protocol. I think that the text above includes IP and IP/UDP encapsulations of active OAM in Geneve. To emphasize that, I propose updating the caption of Figure 2 as follows: OLD TEXT: Geneve IP/UDP Encapsulation of an Active OAM Packet NEW TEXT: An Example of Geneve IP/UDP Encapsulation of an Active OAM Packet WDYT? > > In Section 2.2, it says "Active OAM in Geneve network uses an IP encapsulation", lacking the context of the Management VNI case. >> >> GIM3>> Would the following update make that clear: > OLD TEXT: > Active OAM in Geneve network uses an IP encapsulation. > NEW TEXT: > Active OAM over a Management VNI in the Geneve network uses an IP > encapsulation. > > [XM-4]>>> It looks good to me. > > > Best Regards, > > Xiao Min > > > In Section 2.2, it says "The UDP source port can be used to provide entropy...", I don't think so. >> >> GIM3>> I agree, this is unnecessary as active OAM will use the same > entropy mechanisms as the Geneve data flow. > >> In Section 2.2, it says "Destination IP: IP address MUST NOT be of one of tenant's IP addresses. The IP address MUST be set to the loopback address 127.0.0.1/32 for IPv4, or the loopback address ::1/128 for IPv6 [RFC4291]." Now that "the IP address MUST be set to the loopback address", why does it need to say "IP address MUST NOT be of one of tenant's IP addresses"? >> >> GIM3>> Thank you for pointing that out. I agree, "MUST NOT" is > unnecessary as "MUST be set to the loopback address" is sufficient. > >> >> Cheers, >> >> Xiao Min >> >> >> Regards, >> Greg >> >> On Mon, Oct 16, 2023 at 8:07 PM <xiao.min2@zte.com.cn> wrote: >> >>> Hi Greg, >>> >>> >>> Thank you for the reply. >>> >>> Please see inline with [XM-2]>>>. >>> Original >>> *From: *GregMirsky <gregimirsky@gmail.com> >>> *To: *肖敏10093570; >>> *Cc: *aldrin.ietf@gmail.com <aldrin.ietf@gmail.com>;nvo3@ietf.org < >>> nvo3@ietf.org>;nvo3-chairs@ietf.org <nvo3-chairs@ietf.org>; >>> draft-ietf-nvo3-geneve-oam@ietf.org <draft-ietf-nvo3-geneve-oam@ietf.org >>> >; >>> *Date: *2023年10月12日 22:01 >>> *Subject: **Re: [nvo3] Working Group Last Call and IPR Poll for >>> draft-ietf-nvo3-geneve-oam-07* >>> Hi Xiao Min, >>> thank you for your clarifications and detailed questions. Please find my >>> notes below tagged by GIM2>>. Also, attached in the new working version and >>> diff highlighting updates. >>> >>> Regards, >>> Greg >>> >>> On Sat, Oct 7, 2023 at 9:46 AM <xiao.min2@zte.com.cn> wrote: >>> >>>> Hi Greg, >>>> >>>> >>>> Many thanks for your consideration of my comments. >>>> >>>> I noticed that a new -08 version has been posted, so my further >>>> comments would be based on the latest revision. >>>> >>>> Please see inline. >>>> Original >>>> *From: *GregMirsky <gregimirsky@gmail.com> >>>> *To: *肖敏10093570; >>>> *Cc: *aldrin.ietf@gmail.com <aldrin.ietf@gmail.com>;nvo3@ietf.org < >>>> nvo3@ietf.org>;nvo3-chairs@ietf.org <nvo3-chairs@ietf.org>; >>>> draft-ietf-nvo3-geneve-oam@ietf.org < >>>> draft-ietf-nvo3-geneve-oam@ietf.org>; >>>> *Date: *2023年09月22日 09:09 >>>> *Subject: **Re: [nvo3] Working Group Last Call and IPR Poll for >>>> draft-ietf-nvo3-geneve-oam-07* >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> >>>> Hi Xiao Min, >>>> thank you for your detailed comments and thoughtful suggestions. Please >>>> find my notes below tagged GIM>>. Attached are the new working version of >>>> the draft and the diff highlighting the updates. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Mon, Aug 14, 2023 at 7:12 PM <xiao.min2@zte.com.cn> wrote: >>>> >>>>> Hi Greg, >>>>> >>>>> >>>>> Thanks for taking my suggestions into account. I believe this document >>>>> is on the right way. >>>>> >>>>> Still, I want to extract some text from the working version for >>>>> further discussion. >>>>> >>>>> In section 2.1, it says "Encapsulation of test packets for both cases >>>>> is discussed in Section 2.2." >>>>> >>>>> As I've said before, the OAM over Geneve encap defined in section 2.2 >>>>> applies *only* to the Management VNI, i.e., the first case. >>>>> >>>> GIM>> I agree and removed this new sentence appending the following >>>> sentence to the paragraph that introduces the Management VNI: >>>> NEW TEXT: >>>> Encapsulation of >>>> >>>> test packets using the Management VNI is discussed in Section 2.2. >>>> >>>> [XM]>>> Thank you. Except for this sentence in Section 2.1, there are >>>> still some sentences in Section 1 that seems confusing to me, e.g., it says >>>> "note that the IP encapsulation of OAM applies to those Virtual Network >>>> Identifiers (VNIs) that support the use of the necessary values of the >>>> Protocol Type field in the Geneve header". Could you please go through the >>>> whole document to make all the statements consistent? Some references >>>> to draft-ietf-nvo3-bfd-geneve and draft-xiao-nvo3-pm-geneve may be added to >>>> help the reader understand the difference between the Management VNI case >>>> and the really deployed VNI case. >>>> >>> GIM2>> Would the following edit of the text in Section 1 make the text >>> clear: >>> OLD TEXT: >>> Also, >>> note that the IP encapsulation of OAM applies to those Virtual >>> Network Identifiers (VNIs) that support the use of the necessary >>> values of the Protocol Type field in the Geneve header, i.e., >>> Ethertypes for IPv4 or IPv6. It does not apply to VNIs that lack >>> that support, e.g., VNIs that only support Ethernet Ethertypes. >>> Analysis and definition of other types of OAM encapsulation in Geneve >>> are outside the scope of this document. >>> NEW TEXT: >>> The IP >>> encapsulation of Geneve OAM defined in this document applies to an >>> overlay service by way of introducing a Management Virtual >>> Network Identifier (VNI) that could be used in combination with >>> various values of the Protocol Type field in the Geneve header, i.e., >>> Ethertypes for IPv4 or IPv6. Analysis and definition of other types >>> of OAM encapsulation in Geneve are outside the scope of this >>> document. >>> >>> [XM-2]>>> various values? It looks only two values, i.e., Ethertypes for >>> IPv4 or IPv6. >>> >>> >>> Could you highlight other cases that can benefit from a clarification? >>> >>> [XM-2]>>> In Section 2, it says >>> >>> "In the latter case, the test packet MUST use the same Geneve encapsulation as the data packet (except for the value in the Protocol Type field [RFC8926]), including the value in the Virtual Network Identifier (VNI) field." >>> Why does it say "except for the value in the Protocol Type field [RFC8926]"? I don't think so. >>> In Section 2.1, it says "The ICMP echo reply is encapsulated in Geneve as specified in Section 2.2...", that's incorrect, do you mean Section 3? >>> In Section 2.2, it says "Active OAM in Geneve network uses an IP encapsulation", lacking the context of the Management VNI case. >>> In Section 2.2, it says "The UDP source port can be used to provide entropy...", I don't think so. >>> In Section 2.2, it says >>> " Destination IP: IP address MUST NOT be of one of tenant's IP addresses. The IP address MUST be set to the loopback address 127.0.0.1/32 for IPv4, or the loopback address ::1/128 for IPv6 [RFC4291]." >>> Now that "the IP address MUST be set to the loopback address", why does it need to say "IP address MUST NOT be of one of tenant's IP addresses"? >>> >>> >>>> In section 1, the definition of VAP is introduced, and the only use of >>>>> it is within section 2.2, it says "Source IP: IP address of the originating >>>>> VAP". >>>>> >>>>> I'm a bit confused, to my understanding the VAP is irrelevant to the >>>>> test on Management VNI, the Source IP should be set to the IP address of >>>>> the originating NVE but not the originating VAP. >>>>> >>>> GIM>> Thank you for pointing that out to me. I removed the references >>>> to VAP in the document and updated the text accordingly. >>>> >>>> [XM]>>> Thanks. >>>> >>>> >>>> In section 2.1, it says "The Management VNI SHOULD be terminated on the >>>>> tenant-facing side of the Geneve encap/decap functionality, not the >>>>> DC-network-facing side (per definitions in Section 4 of [RFC8014]) so that >>>>> Geneve encap/decap functionality is included in its scope." >>>>> >>>>> I'm not sure this statement is accurate. The Management VNI is a >>>>> specific VNI not really deployed at the tenant-facing side, so it seems >>>>> impossible to be terminated on the tenent-facing side. >>>>> >>>> GIM>> You are right. The Management VNI is a logical construct and, as >>>> such, where it is terminated is also a logical entity. By pointing out >>>> where the termination of the Management VNI happens, the document provides >>>> useful information to an implementer. That information is important to >>>> ensure that Geneve encap/decap functionality is exercised by an active OAM. >>>> >>>> [XM]>>> OK. >>>> >>>> >>>> In section 1, it says "IP encapsulation conforms to these requirements >>>>> and is a suitable encapsulation of active OAM protocols in a Geneve overlay >>>>> network." >>>>> >>>>> I'm not sure this statement is comprehensive. For the first case >>>>> (Management VNI) discussed in section 2.1, I agree that IP encapsulation is >>>>> enough, but for the second case, Ethernet encapsulation is also needed, >>>>> which is clearly specified in draft-ietf-nvo3-bfd-geneve. >>>>> >>>> GIM>> I agree that the IP encapsulation using the Management VNI >>>> addresses the first of two scenarios analyzed in Section 2.1. But I don't >>>> think that it does not conform to the requirements listed in Section 2. >>>> Could you help me by identifying which of five requirements cannot be >>>> fulfilled by the IP encapsulation using the Management VNI? >>>> >>>> [XM]>>> REQ#1. As you indicated above, Management VNI is a logical >>>> construct, not the VNI really deployed at the NVE, and considering that the Ethernet >>>> over Geneve encap is the most popular one, I don't think a strict fate >>>> sharing can be fulfilled by the IP encapsulation using the Management VNI. >>>> >>> GIM2>> By using the Management VNI, in my opinion, we ensure the fate >>> sharing of an active Geneve OAM with Geneve overlay service. I agree that >>> the Management VNI may not be the most useful method to monitor an Ethernet >>> service over the Geneve tunnel. I think that is clear from the text of the >>> document. >>> >>> [XM-2]>>> OK, it's up to you. I reserve my suggestion to change the >>> quoted text. >>> >>>> >>>> In section 2.1, it says "The second case requires that a test packet be >>>>> transmitted using the VNI value for the traffic that is encountering >>>>> problems and the test packet is experiences network treatment as the >>>>> tenant's packets." >>>>> >>>>> I'm not sure this statement is accurate, "that is encountering >>>>> problems" seems applicable to ICMP Ping but not applicable to BFD, because >>>>> BFD itself is used to detect traffic problems. >>>>> >>>> GIM>> I think that the goal of BFD is well described in the Abstract of >>>> RFC 5880: >>>> This document describes a protocol intended to detect faults in the >>>> bidirectional path between two forwarding engines, including >>>> interfaces, data link(s), and to the extent possible the forwarding >>>> engines themselves, with potentially very low latency. >>>> >>>> From this definition I conclude that BFD detects faults, i.e., problems >>>> in the elements listed in the Abstract. Would you agree? >>>> >>>> [XM]>>> Let me elaborate a bit more. This sentence in Section 2.1 >>>> implies that in the second case a test packet is transmitted only when the >>>> traffic is encountering problems, IMHO that's not the case, take BFD as an >>>> example, in the second case the BFD Control packets should be transmitted >>>> from the beginning, but not after detecting some traffic problems. >>>> >>> GIM2>> Thank you for helping me to understand your concern. I hope I >>> get it now. Would the following update make the message unambiguous and >>> acceptable: >>> OLD TEXT: >>> The second case requires that a test packet be transmitted using the >>> VNI value for the traffic that is encountering problems and the test >>> packet experiences network treatment as the tenant's packets. Detail >>> of that use case are outside the scope of this specification. >>> NEW TEXT: >>> >>> [XM-2]>>> I don't know what's wrong, but it seems your NEW TEXT >>> disappeared. The good thing is that I can see it from your attached Diff >>> file, and that's fine to me. At the same time, I propose to change the text >>> in Section 2.1 as below. >>> >>> OLD TEXT >>> >>> In the first case, a communication problem between Network Virtualization Edge (NVE) device A and NVE C was observed. The underlay, e.g., IP network, forwarding is working well but the Geneve connection is unstable for all tenants of NVE A and NVE C. Troubleshooting and localization of the problem can be done irrespective of the VNI value. >>> NEW TEXT >>> In the first case, a communication problem between Network Virtualization Edge (NVE) device A and NVE C *exists*. The underlay, e.g., IP network, forwarding is working well but the Geneve connection is unstable for all tenants of NVE A and NVE C. *Detection,* troubleshooting and localization of the problem can be done irrespective of the VNI value. >>> >>> Cheers, >>> Xiao Min >>> >>> >>>> Cheers, >>>> >>>> Xiao Min >>>> >>>> >>>> BTW, "the test packet is experiences network treatment" has nit. >>>>> >>>> GIM>> Thank you for catching it. Fixed. >>>> >>>>> >>>>> Best Regards, >>>>> >>>>> Xiao Min >>>>> Original >>>>> *From: *GregMirsky <gregimirsky@gmail.com> >>>>> *To: *肖敏10093570; >>>>> *Cc: *aldrin.ietf@gmail.com <aldrin.ietf@gmail.com>;nvo3@ietf.org < >>>>> nvo3@ietf.org>;nvo3-chairs@ietf.org <nvo3-chairs@ietf.org>; >>>>> draft-ietf-nvo3-geneve-oam@ietf.org < >>>>> draft-ietf-nvo3-geneve-oam@ietf.org>; >>>>> *Date: *2023年08月07日 06:12 >>>>> *Subject: **Re: [nvo3] Working Group Last Call and IPR Poll for >>>>> draft-ietf-nvo3-geneve-oam-07* >>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> nvo3@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>>> >>>>> Hi Xiao Min, >>>>> thank you for your suggestions. I've updated the draft to address your >>>>> concern. Please let me know if you agree with the changes highlighted in >>>>> the attached diff (the working version also includes updates that address >>>>> the editorial updates suggested by Donald Eastlake). >>>>> >>>>> Regards, >>>>> Greg >>>>> >>>>> On Tue, Jul 4, 2023 at 1:12 AM <xiao.min2@zte.com.cn> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> >>>>>> I support progressing this document to publication. >>>>>> >>>>>> At the same time, I strongly suggest the authors to rethink about the >>>>>> scope of this document. >>>>>> >>>>>> This document introduces two cases of using active OAM protocols for >>>>>> Geneve, the first case is to use the Management VNI, and the second case is >>>>>> to use the VNIs really deployed in the NVE, that's fine to me. However, >>>>>> it's said that the OAM encapsulation defined in Section 2.2 can be used for >>>>>> both cases, I don't think so. As specified in draft-ietf-nvo3-bfd-geneve, >>>>>> in order to use the VNIs really deployed, VAP based OAM solution is >>>>>> necessary, i.e., the MAC/IP address of VAP must be used as long as it's >>>>>> available, and then the VNI can be identified through VAP-to-VNI mapping. >>>>>> Besides, for the second case, both Ethernet over Geneve encap and IP over >>>>>> Geneve encap are needed. So with that said, the OAM encap defined in >>>>>> Section 2.2 can be slightly tweaked to be applicable to the first case >>>>>> only, and the OAM encap for the second case can be made outside the scope >>>>>> of this document. >>>>>> >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Xiao Min >>>>>> Original >>>>>> *From: *SamAldrin <aldrin.ietf@gmail.com> >>>>>> *To: *NVO3 <nvo3@ietf.org>;nvo3-chairs@ietf.org <nvo3-chairs@ietf.org >>>>>> >;draft-ietf-nvo3-geneve-oam@ietf.org < >>>>>> draft-ietf-nvo3-geneve-oam@ietf.org>; >>>>>> *Date: *2023年06月28日 14:27 >>>>>> *Subject: **[nvo3] Working Group Last Call and IPR Poll for >>>>>> draft-ietf-nvo3-geneve-oam-07* >>>>>> _______________________________________________ >>>>>> nvo3 mailing list >>>>>> nvo3@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>>>> >>>>>> This email begins a two-week working group last call for >>>>>> draft-ietf-nvo3-geneve-oam-07 >>>>>> >>>>>> (https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve-oam/ >>>>>> <https://datatracker.ietf.org/doc/draft-ietf-nvo3-bfd-geneve/>). >>>>>> >>>>>> >>>>>> >>>>>> Please review the draft and post any comments to the NVO3 working >>>>>> group list. If you have read the latest version of the draft but have no >>>>>> comments and believe it is ready for publication as an informational RFC, >>>>>> please also indicate so to the WG email list. >>>>>> >>>>>> >>>>>> >>>>>> We are also polling for knowledge of any undisclosed IPR that applies >>>>>> to this document, to ensure that IPR has been disclosed in compliance with >>>>>> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >>>>>> >>>>>> If you are listed as an Author or a Contributor of this document, >>>>>> please respond to this email and indicate whether or not you are aware of >>>>>> any relevant undisclosed IPR. The Document won't progress without answers >>>>>> from all the Authors and Contributors. >>>>>> >>>>>> >>>>>> >>>>>> Currently there are no IPR disclosures against this document. >>>>>> >>>>>> >>>>>> >>>>>> If you are not listed as an Author or a Contributor, then please >>>>>> explicitly respond only if you are aware of any IPR that has not yet been >>>>>> disclosed in conformance with IETF rules. >>>>>> >>>>>> >>>>>> >>>>>> This poll will run until Friday 12th July 2023. >>>>>> >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> >>>>>> >>>>>> Sam and Matthew >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
- [nvo3] Working Group Last Call and IPR Poll for d… Sam Aldrin
- Re: [nvo3] Working Group Last Call and IPR Poll f… Matthew Bocci (Nokia)
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky
- Re: [nvo3] Working Group Last Call and IPR Poll f… Donald Eastlake
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky
- Re: [nvo3] Working Group Last Call and IPR Poll f… xiao.min2
- Re: [nvo3] Working Group Last Call and IPR Poll f… Jeff Tantsura
- Re: [nvo3] Working Group Last Call and IPR Poll f… Gyan Mishra
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky
- Re: [nvo3] Working Group Last Call and IPR Poll f… xiao.min2
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky
- Re: [nvo3] Working Group Last Call and IPR Poll f… xiao.min2
- Re: [nvo3] Working Group Last Call and IPR Poll f… Mach Chen
- Re: [nvo3] Working Group Last Call and IPR Poll f… Sam Aldrin
- Re: [nvo3] Working Group Last Call and IPR Poll f… Santosh P K
- Re: [nvo3] Working Group Last Call and IPR Poll f… Sami Boutros
- Re: [nvo3] Working Group Last Call and IPR Poll f… Black, David
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky
- Re: [nvo3] Working Group Last Call and IPR Poll f… xiao.min2
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky
- Re: [nvo3] Working Group Last Call and IPR Poll f… xiao.min2
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky
- Re: [nvo3] Working Group Last Call and IPR Poll f… xiao.min2
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky
- Re: [nvo3] Working Group Last Call and IPR Poll f… xiao.min2
- Re: [nvo3] Working Group Last Call and IPR Poll f… Santosh P K
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky