Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-oam-07

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> wrote:

> Hi Greg,
>
>
> Thank you for the prompt reply.
>
> Please see inline with [XM-5]>>>.
> Original
> *From: *GregMirsky <[e-mail]>
> *To: *肖敏10093570;
> *Cc: *[e-mail] <[e-mail]>;[e-mail] <
> [e-mail]>;[e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;
> *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
> [e-mail]
> 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 <[e-mail]> wrote:
>
>> Hi Greg,
>>
>>
>> Thanks for the reply.
>>
>> Please see inline with [XM-4]>>>.
>> Original
>> *From: *GregMirsky <[e-mail]>
>> *To: *肖敏10093570;
>> *Cc: *Sam Aldrin <[e-mail]>;NVO3 <[e-mail]>;
>> [e-mail] <[e-mail]>;
>> [e-mail] <[e-mail]
>> >;
>> *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 <[e-mail]> wrote:
>>
>>> Hi Greg,
>>>
>>>
>>> Thank you for the reply and proposed updates.
>>>
>>> Please see inline with [XM-3]>>>.
>>>
>>>
>>> Original
>>> *From: *GregMirsky <[e-mail]>
>>> *To: *肖敏10093570;
>>> *Cc: *[e-mail] <[e-mail]>;[e-mail] <
>>> [e-mail]>;[e-mail] <[e-mail]>;
>>> [e-mail] <[e-mail]
>>> >;
>>> *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
>>> [e-mail]
>>> 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 <[e-mail]> wrote:
>>>
>>>> Hi Greg,
>>>>
>>>>
>>>> Thank you for the reply.
>>>>
>>>> Please see inline with [XM-2]>>>.
>>>> Original
>>>> *From: *GregMirsky <[e-mail]>
>>>> *To: *肖敏10093570;
>>>> *Cc: *[e-mail] <[e-mail]>;[e-mail] <
>>>> [e-mail]>;[e-mail] <[e-mail]>;
>>>> [e-mail] <
>>>> [e-mail]>;
>>>> *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 <[e-mail]> 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 <[e-mail]>
>>>>> *To: *肖敏10093570;
>>>>> *Cc: *[e-mail] <[e-mail]>;[e-mail] <
>>>>> [e-mail]>;[e-mail] <[e-mail]>;
>>>>> [e-mail] <
>>>>> [e-mail]>;
>>>>> *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
>>>>> [e-mail]
>>>>> 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 <[e-mail]> 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 <[e-mail]>
>>>>>> *To: *肖敏10093570;
>>>>>> *Cc: *[e-mail] <[e-mail]>;[e-mail] <
>>>>>> [e-mail]>;[e-mail] <[e-mail]>;
>>>>>> [e-mail] <
>>>>>> [e-mail]>;
>>>>>> *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
>>>>>> [e-mail]
>>>>>> 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 <[e-mail]> 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 <[e-mail]>
>>>>>>> *To: *NVO3 <[e-mail]>;[e-mail] <
>>>>>>> [e-mail]>;[e-mail] <
>>>>>>> [e-mail]>;
>>>>>>> *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
>>>>>>> [e-mail]
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>