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.
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.
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.
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.
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. BTW, "the test packet is experiences network
treatment" has nit.
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/).
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
