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?
>
>> 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.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 Working Group G. Mirsky
Internet-Draft Ericsson
Intended status: Standards Track S. Boutros
Expires: 25 May 2024 Ciena
D. Black
Dell EMC
S. Pallagatti
VMware
22 November 2023
OAM for use in GENEVE
draft-ietf-nvo3-geneve-oam-09
Abstract
This document lists a set of general requirements for active OAM
protocols in the Geneve overlay network. Based on the requirements,
IP encapsulation for active Operations, Administration, and
Maintenance protocols in Geneve protocol is defined. Considerations
for using ICMP and UDP-based protocols are discussed.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 25 May 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
Mirsky, et al. Expires 25 May 2024 [Page 1]
Internet-Draft OAM in GENEVE November 2023
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document . . . . . . . . . . . . 3
1.1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3
2. Active OAM Protocols in Geneve Networks . . . . . . . . . . . 3
2.1. Defect Detection and Troubleshooting in Geneve Network with
Active OAM . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. OAM Encapsulation in Geneve . . . . . . . . . . . . . . . 6
3. Echo Request and Echo Reply in Geneve Tunnel . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Additional Considerations for OAM Encapsulation Method
in Geneve . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Geneve [RFC8926] is intended to support various scenarios of network
virtualization. In addition to carrying multi-protocol payload,
e.g., Ethernet, IPv4/IPv6, the Geneve message includes metadata.
Operations, Administration, and Maintenance (OAM) protocols support
fault management and performance monitoring functions necessary for
comprehensive network operation. Active OAM protocols, as defined in
[RFC7799], use specially constructed packets that are injected into
the network. To ensure that the measured performance metric or the
detected failure of the transport layer are related to a particular
Geneve flow, it is critical that these test packets share fate with
overlay data packets for that flow when traversing the underlay
network.
A set of general requirements for active OAM protocols in the Geneve
overlay network is listed in Section 2. IP encapsulation conforms to
these requirements and is a suitable encapsulation of active OAM
protocols in a Geneve overlay network. Active OAM in a Geneve
overlay network are exchanged between two Geneve tunnel endpoints,
which may be an NVE (Network Virtualization Edge) or another device
acting as a Geneve tunnel endpoint. For simplicity, NVE is used to
Mirsky, et al. Expires 25 May 2024 [Page 2]
Internet-Draft OAM in GENEVE November 2023
represent the Geneve tunnel endpoint. Please refer to [RFC7365] and
[RFC8014] for detailed definitions and descriptions of NVE. The IP
encapsulation of Geneve OAM defined in this document applies to an
overlay service by 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.
1.1. Conventions used in this document
1.1.1. Acronyms
Geneve Generic Network Virtualization Encapsulation
NVO3 Network Virtualization Overlays
OAM Operations, Administration, and Maintenance
VNI Virtual Network Identifier
1.1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Active OAM Protocols in Geneve Networks
OAM protocols, whether part of fault management or performance
monitoring, are intended to provide reliable information that can be
used to detect a failure, identify the defect and localize it, thus
helping to identify and apply corrective actions to minimize the
negative impact on service. Several OAM protocols are used to
perform these functions; these protocols require demultiplexing at
the receiving instance of Geneve. To improve the accuracy of the
correlation between the condition experienced by the monitored Geneve
tunnel and the state of the OAM protocol the OAM encapsulation is
required to comply with the following requirements:
REQ#1: Geneve OAM test packets MUST share the fate with data
traffic of the monitored Geneve tunnel, i.e., be in-band with the
monitored traffic, follow the same overlay and transport path as
packets with data payload, in the forward direction, i.e. from
ingress toward egress endpoint(s) of the OAM test.
Mirsky, et al. Expires 25 May 2024 [Page 3]
Internet-Draft OAM in GENEVE November 2023
An OAM protocol MAY be used to monitor the particular Geneve tunnel
as a whole. In that case, test packets could be fate-sharing with a
sub-set of tenant flows transported over the Geneve tunnel. If the
goal is to monitor the condition experienced by the flow of a
particular tenant, the test packets MUST be fate-sharing with that
specific flow in the Geneve tunnel. Both scenarios are discussed in
detail in Section 2.1.
REQ#2: Encapsulation of OAM control message and data packets in
underlay network MUST be indistinguishable from the underlay
network IP forwarding point of view.
REQ#3: Presence of OAM control message in Geneve packet MUST be
unambiguously identifiable to Geneve functionality, e.g., at
endpoints of Geneve tunnels.
REQ#4: OAM test packets MUST NOT be forwarded to a tenant system.
A test packet generated by an active OAM protocol, either for a
defect detection or performance measurement, according to REQ#1, MUST
be fate-sharing with the tunnel or data flow being monitored. In an
environment where multiple paths through the domain are available,
underlay transport nodes can be programmed to use characteristic
information to balance the load across known paths. It is essential
that test packets follow the same route, i.e., traverses the same set
of nodes and links, as a data packet of the monitored flow. Thus,
the following requirement to support OAM packet fate-sharing with the
data flow:
REQ#5: It MUST be possible to express entropy for underlay Equal
Cost Multipath in the Geneve encapsulation of OAM packets.
2.1. Defect Detection and Troubleshooting in Geneve Network with Active
OAM
Figure 1 presents an example of a Geneve domain. In this section, we
consider two scenarios of active OAM being used to detect and
localize defects in the Geneve network.
Mirsky, et al. Expires 25 May 2024 [Page 4]
Internet-Draft OAM in GENEVE November 2023
+--------+ +--------+
| Tenant +--+ +----| Tenant |
| VNI 28 | | | | VNI 35 |
+--------+ | ................ | +--------+
| +----+ . . +----+ |
| | NVE|--. .--| NVE| |
+--| A | . . | B |---+
+----+ . . +----+
/ . .
/ . Geneve .
+--------+ / . Network .
| Tenant +--+ . .
| VNI 35 | . .
+--------+ ................
|
+----+
| NVE|
| C |
+----+
|
|
=====================
| |
+--------+ +--------+
| Tenant | | Tenant |
| VNI 28 | | VNI 35 |
+--------+ +--------+
Figure 1: An example of a Geneve domain
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.
In the second case, traffic on VNI 35 between NVE A and NVE B has no
problems, as on VNI 28 between NVE A and NVE C. But traffic on VNI
35 between NVE A and NVE C experiences problems, for example,
excessive packet loss.
The first case can be detected and investigated using any VNI value,
whether it connects tenant systems or not; however, to conform to
REQ#4 (Section 2) OAM test packets SHOULD be transmitted on a VNI
that doesn't have any tenants. Such a Geneve tunnel is dedicated to
Mirsky, et al. Expires 25 May 2024 [Page 5]
Internet-Draft OAM in GENEVE November 2023
carrying only control and management data between the tunnel
endpoints, hence it is referred to as a Geneve control channel and
that VNI is referred to as the Management VNI. A configured VNI MAY
be used to identify the control channel, but it is RECOMMENDED that
the default value 1 be used as the Management VNI. Encapsulation of
test packets using the Management VNI is discussed in Section 2.2.
The control channel of a Geneve tunnel MUST NOT carry tenant data.
As no tenants are connected using the control channel, a system that
supports this specification, MUST NOT forward a packet received over
the control channel to any tenant. A packet received over the
control channel MAY be forwarded if and only if it is sent onto the
control channel of the a concatenated Geneve tunnel. 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. This approach causes an
active OAM packet, e.g., an ICMP echo request, to be decapsulated in
the same fashion as any other received Geneve packet. In this
example, the resulting ICMP packet is handed to NVE's local
management functionality for the processing which generates an ICMP
echo reply. The ICMP echo reply is encapsulated in Geneve as
specified in Section 2.2. for forwarding back to the NVE that sent
the echo request. One advantage of this approach is that a repeated
ping test could detect an intermittent problem in Geneve encap/decap
hardware, which would not be tested if the Management VNI were
handled as a "special case" at the DC-network-facing interface.
The second case is when a test packet is transmitted using the VNI
value associated with the monitored service flow. By doing that, the
test packet experiences network treatment as the tenant's packets.
Details of that use case are outside the scope of this specification.
2.2. OAM Encapsulation in Geneve
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. This approach is
well-known and has been used, for example, in MPLS networks
[RFC8029]. To use IP encapsulation for an active OAM protocol the
Protocol Type field of the Geneve header MUST be set to the IPv4
(0x0800) or IPv6 (0x86DD) value.
Mirsky, et al. Expires 25 May 2024 [Page 6]
Internet-Draft OAM in GENEVE November 2023
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Outer IPvX Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Outer UDP Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Geneve Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Inner IPvX Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Inner UDP Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Active OAM Packet ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: An Example of Geneve IP/UDP Encapsulation of an Active
OAM Packet
Inner IP header:
Destination IP: 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].
Source IP: IP address of the NVE.
TTL or Hop Limit: MUST be set to 255 per [RFC5082].
3. Echo Request and Echo Reply in Geneve Tunnel
ICMP and ICMPv6 ([RFC0792] and [RFC4443] respectively) provide
required on-demand defect detection and failure localization. ICMP
control messages immediately follow the inner IP header encapsulated
in Geneve. ICMP extensions for Geneve networks use mechanisms
defined in [RFC4884].
Mirsky, et al. Expires 25 May 2024 [Page 7]
Internet-Draft OAM in GENEVE November 2023
4. IANA Considerations
This document has no requirements for IANA. This section can be
removed before the publication.
5. Security Considerations
As part of a Geneve network, active OAM inherits the security
considerations discussed in [RFC8926]. Additionally, a system MUST
provide control to limit the rate of Geneve OAM packets punted to the
Geneve control plane for processing in order to avoid overloading
that control plane.
OAM in GENEVE packets uses the General TTL Security Mechanism
[RFC5082] and any packet received with an inner TTL / Hop Count other
than 255 MUST be discarded.
6. Acknowledgments
The authors express their appreciation to Donald E. Eastlake 3rd for
his suggestions that improved the readability of the document.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Mirsky, et al. Expires 25 May 2024 [Page 8]
Internet-Draft OAM in GENEVE November 2023
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/info/rfc8926>.
7.2. Informative References
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
DOI 10.17487/RFC4884, April 2007,
<https://www.rfc-editor.org/info/rfc4884>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for Data Center (DC) Network
Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
2014, <https://www.rfc-editor.org/info/rfc7365>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
Mirsky, et al. Expires 25 May 2024 [Page 9]
Internet-Draft OAM in GENEVE November 2023
[RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T.
Narten, "An Architecture for Data-Center Network
Virtualization over Layer 3 (NVO3)", RFC 8014,
DOI 10.17487/RFC8014, December 2016,
<https://www.rfc-editor.org/info/rfc8014>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
Two-Way Active Measurement Protocol", RFC 8762,
DOI 10.17487/RFC8762, March 2020,
<https://www.rfc-editor.org/info/rfc8762>.
Appendix A. Additional Considerations for OAM Encapsulation Method in
Geneve
Several other options for OAM encapsulation were considered. Those
are listed in the Appendix solely for informational purposes. These
options were discarded in favor of the approach described in the main
body of this document.
A Protocol Type field might be used to demultiplex active OAM
protocols directly. Such method avoids the use of additional
intermediate header but requires that each active OAM protocol be
assigned unique identifier from the Ether Types registry maintained
by IANA.
The alternative to using the Protocol Type directly is to use a shim
that, in turn, identifies the OAM Protocol and, optionally, includes
additional information. [RFC5586] defines how the Generic Associated
Channel Label (GAL) can be used to identify that the Associated
Channel Header (ACH), defined in [RFC4385], immediately follows the
Bottom-of-the-Stack label. Thus, the MPLS Generic Associated Channel
can be identified, and protocols are demultiplexed based on the
Channel Type field's value. Number of channel types, e.g., for
continuity check and performance monitoring, already have been
defined and are listed in IANA MPLS Generalized Associated Channel
Types (including Pseudowire Associated Channel Types) registry. The
value of the Protocol Type field in the Geneve header MUST be set to
MPLS to use this approach. The Geneve header MUST be immediately
followed by the GAL label with the S flag set to indicate that GAL is
the Bottom-of-the-stack label. Then ACH MUST follow the GAL label
and the value of the Channel Type identifies which of active OAM
protocols being encapsulated in the packet.
Mirsky, et al. Expires 25 May 2024 [Page 10]
Internet-Draft OAM in GENEVE November 2023
Authors' Addresses
Greg Mirsky
Ericsson
Email: gregimir...@gmail.com
Sami Boutros
Ciena
Email: sbout...@ciena.com
David Black
Dell EMC
176 South Street
Hopkinton, MA, 01748
United States of America
Email: david.bl...@dell.com
Santosh Pallagatti
VMware
Email: santosh.pallaga...@gmail.com
Mirsky, et al. Expires 25 May 2024 [Page 11]
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
