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 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.

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.

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
>>>>
>>>>
>>>>
>>>
>>
>