Hi Xiao Min, thank you for your kind consideration of the proposed updates to address your concerns. I have one question logged below under the GIM5>> tag.
Regards, Greg On Thu, Nov 23, 2023 at 12:39 AM <xiao.m...@zte.com.cn> wrote: > Hi Greg, > > > Thank you for the prompt reply. > > Please see inline with [XM-5]>>>. > Original > *From: *GregMirsky <gregimir...@gmail.com> > *To: *肖敏10093570; > *Cc: *aldrin.i...@gmail.com <aldrin.i...@gmail.com>;nvo3@ietf.org < > nvo3@ietf.org>;nvo3-cha...@ietf.org <nvo3-cha...@ietf.org>; > draft-ietf-nvo3-geneve-...@ietf.org <draft-ietf-nvo3-geneve-...@ietf.org>; > *Date: *2023年11月23日 01:14 > *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 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.m...@zte.com.cn> wrote: > >> Hi Greg, >> >> >> Thanks for the reply. >> >> Please see inline with [XM-4]>>>. >> Original >> *From: *GregMirsky <gregimir...@gmail.com> >> *To: *肖敏10093570; >> *Cc: *Sam Aldrin <aldrin.i...@gmail.com>;NVO3 <nvo3@ietf.org>; >> nvo3-cha...@ietf.org <nvo3-cha...@ietf.org>; >> draft-ietf-nvo3-geneve-...@ietf.org <draft-ietf-nvo3-geneve-...@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.m...@zte.com.cn> wrote: >> >>> Hi Greg, >>> >>> >>> Thank you for the reply and proposed updates. >>> >>> Please see inline with [XM-3]>>>. >>> >>> >>> Original >>> *From: *GregMirsky <gregimir...@gmail.com> >>> *To: *肖敏10093570; >>> *Cc: *aldrin.i...@gmail.com <aldrin.i...@gmail.com>;nvo3@ietf.org < >>> nvo3@ietf.org>;nvo3-cha...@ietf.org <nvo3-cha...@ietf.org>; >>> draft-ietf-nvo3-geneve-...@ietf.org <draft-ietf-nvo3-geneve-...@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? > > [XM-5]>>> That's fine to me. > >> >>> 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? > > [XM-5]>>> This is a Standards Track document, not Informational one. So if > the intention is to include both IP and IP/UDP encapsulations of active OAM > in Geneve in Section 2.2, then I suggest you to add a new > figure illustrating the IP encapsulation of active OAM in Geneve explicitly. > GIM5>> I believe that a reader experienced in the subject would be able to properly deduce raw IP encapsulation based on the example displayed in Figure 2.2 since the IP/UDP encapsulation doesn't use anything UDP-specific. Perhaps our Shepherd or someone from the group would kindly share their opinion on whether an additional figure is helpful. > > Cheers, > > Xiao Min > >> >> 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.m...@zte.com.cn> wrote: >>> >>>> Hi Greg, >>>> >>>> >>>> Thank you for the reply. >>>> >>>> Please see inline with [XM-2]>>>. >>>> Original >>>> *From: *GregMirsky <gregimir...@gmail.com> >>>> *To: *肖敏10093570; >>>> *Cc: *aldrin.i...@gmail.com <aldrin.i...@gmail.com>;nvo3@ietf.org < >>>> nvo3@ietf.org>;nvo3-cha...@ietf.org <nvo3-cha...@ietf.org>; >>>> draft-ietf-nvo3-geneve-...@ietf.org < >>>> draft-ietf-nvo3-geneve-...@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.m...@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 <gregimir...@gmail.com> >>>>> *To: *肖敏10093570; >>>>> *Cc: *aldrin.i...@gmail.com <aldrin.i...@gmail.com>;nvo3@ietf.org < >>>>> nvo3@ietf.org>;nvo3-cha...@ietf.org <nvo3-cha...@ietf.org>; >>>>> draft-ietf-nvo3-geneve-...@ietf.org < >>>>> draft-ietf-nvo3-geneve-...@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.m...@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 <gregimir...@gmail.com> >>>>>> *To: *肖敏10093570; >>>>>> *Cc: *aldrin.i...@gmail.com <aldrin.i...@gmail.com>;nvo3@ietf.org < >>>>>> nvo3@ietf.org>;nvo3-cha...@ietf.org <nvo3-cha...@ietf.org>; >>>>>> draft-ietf-nvo3-geneve-...@ietf.org < >>>>>> draft-ietf-nvo3-geneve-...@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.m...@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.i...@gmail.com> >>>>>>> *To: *NVO3 <nvo3@ietf.org>;nvo3-cha...@ietf.org < >>>>>>> nvo3-cha...@ietf.org>;draft-ietf-nvo3-geneve-...@ietf.org < >>>>>>> draft-ietf-nvo3-geneve-...@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 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
