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

[xiao.min2]

Hi Greg,

Thank you for the prompt reply.
Please see inline with [XM-5]>>>.

Original


From: GregMirsky 
To: 肖敏10093570;
Cc: aldrin.i...@gmail.com ;nvo3@ietf.org 
;nvo3-cha...@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  wrote:


Hi Greg,

Thanks for the reply.
Please see inline with [XM-4]>>>.

Original

From: GregMirsky 
To: 肖敏10093570;
Cc: Sam Aldrin ;NVO3 
;nvo3-cha...@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  wrote:


Hi Greg,

Thank you for the reply and proposed updates.
Please see inline with [XM-3]>>>.


Original

From: GregMirsky 
To: 肖敏10093570;
Cc: aldrin.i...@gmail.com ;nvo3@ietf.org 
;nvo3-cha...@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 

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

[xiao.min2]

Hi Greg,

Thanks for the reply.
Please see inline with [XM-4]>>>.

Original


From: GregMirsky 
To: 肖敏10093570;
Cc: Sam Aldrin ;NVO3 
;nvo3-cha...@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  wrote:


Hi Greg,

Thank you for the reply and proposed updates.
Please see inline with [XM-3]>>>.


Original

From: GregMirsky 
To: 肖敏10093570;
Cc: aldrin.i...@gmail.com ;nvo3@ietf.org 
;nvo3-cha...@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.







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.







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


Hi Greg,
Thank you for the 

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

[xiao.min2]

Hi Greg,

Thank you for the reply and proposed updates.
Please see inline with [XM-3]>>>.


Original


From: GregMirsky 
To: 肖敏10093570;
Cc: aldrin.i...@gmail.com ;nvo3@ietf.org 
;nvo3-cha...@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.
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"? 
Cheers,
Xiao Min

Regards,
Greg






On Mon, Oct 16, 2023 at 8:07 PM  wrote:


Hi Greg,
Thank you for the reply.
Please see inline with [XM-2]>>>.

Original

From: GregMirsky 
To: 肖敏10093570;
Cc: aldrin.i...@gmail.com ;nvo3@ietf.org 
;nvo3-cha...@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  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 
To: 肖敏10093570;
Cc: aldrin.i...@gmail.com ;nvo3@ietf.org 
;nvo3-cha...@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  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 

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

[xiao.min2]

Hi Greg,
Thank you for the reply.
Please see inline with [XM-2]>>>.

Original


From: GregMirsky 
To: 肖敏10093570;
Cc: aldrin.i...@gmail.com ;nvo3@ietf.org 
;nvo3-cha...@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  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 
To: 肖敏10093570;
Cc: aldrin.i...@gmail.com ;nvo3@ietf.org 
;nvo3-cha...@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  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"? 

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

[xiao.min2]

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 
To: 肖敏10093570;
Cc: aldrin.i...@gmail.com ;nvo3@ietf.org 
;nvo3-cha...@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  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.



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.



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.

Re: [nvo3] John Scudder's No Objection on draft-ietf-nvo3-bfd-geneve-13: (with COMMENT)

[xiao.min2]

Thank you, John!



Xiao Min






Original



From: JohnScudderviaDatatracker 
To: The IESG ;
Cc: draft-ietf-nvo3-bfd-gen...@ietf.org 
;nvo3-cha...@ietf.org 
;nvo3@ietf.org ;matthew.bo...@nokia.com 
;matthew.bo...@nokia.com ;
Date: 2023年09月08日 22:25
Subject: John Scudder's No Objection on draft-ietf-nvo3-bfd-geneve-13: (with 
COMMENT)




John Scudder has entered the following ballot position for
draft-ietf-nvo3-bfd-geneve-13: No Objection
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
for more information about how to handle DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-bfd-geneve/
 
 
 
--
COMMENT:
--
 
Thanks for the updates!___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] John Scudder's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with DISCUSS and COMMENT)

[xiao.min2]

Hi John,






Much appreciated if you may check the latest -13 version and let's know whether 
your DISCUSS is addressed or not. Link as below.


https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-bfd-geneve-13 






Best Regards,


Xiao Min



Original



From: 肖敏10093570
To: JohnScudder ;
Cc: The IESG ;draft-ietf-nvo3-bfd-gen...@ietf.org 
;nvo3-cha...@ietf.org 
;nvo3@ietf.org ;matthew.bo...@nokia.com 
;
Date: 2023年08月16日 14:59
Subject: Re: John Scudder's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with 
DISCUSS and COMMENT)




Hi John,






Thank you for the response.
Please see inline my comments tagged with [XM-2].










From: JohnScudder 
To: 肖敏10093570;
Cc: The IESG ;draft-ietf-nvo3-bfd-gen...@ietf.org 
;nvo3-cha...@ietf.org 
;nvo3@ietf.org ;matthew.bo...@nokia.com 
;
Date: 2023年08月15日 23:26
Subject: Re: John Scudder's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with 
DISCUSS and COMMENT)


Hi Xiao Min,
 
Thanks for your reply. Some further comments in line below.
 
> On Aug 4, 2023, at 4:14 AM, xiao.m...@zte.com.cn wrote:
>  
>  
> Hi John,
>  
>  
>  
> Thank you for the review and thoughtful comments.
>  
> Please see inline.
>  
> Original
> From: JohnScudderviaDatatracker  
> To: The IESG ;
> Cc: draft-ietf-nvo3-bfd-gen...@ietf.org 
> ;nvo3-cha...@ietf.org 
> ;nvo3@ietf.org ;matthew.bo...@nokia.com 
> ;matthew.bo...@nokia.com ;
> Date: 2023年08月04日 03:40
> Subject: John Scudder's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with 
> DISCUSS and COMMENT)
> John Scudder has entered the following ballot position for
> draft-ietf-nvo3-bfd-geneve-12: Discuss
>  
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>  
>  
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
>  
> for more information about how to handle DISCUSS and COMMENT positions.
>  
>  
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-nvo3-bfd-geneve/
>  
>  
>  
> --
> DISCUSS:
> --
>  
> Thanks for this valuable and easy-to-read spec. I have one concern that I'd
> like to have a discussion about; I hope this will be easy to resolve.
> [XM]>>> I believe so. :-)
>  
>  
>  
> There are several places where you use MUST in a way I think is unnecessary,
> you seem to be saying, in effect, "to do Geneve you MUST do Geneve". Most of
> these are harmless IMO (I put some examples in the COMMENT section just in 
> case
> you're unclear what I'm talking about) but there are two that seem problematic
> to me, nearly-identical sentences from Sections 4.1 and 5.1:
>  
>   Then the Destination IP, the UDP destination port and
>the TTL or Hop Limit of the inner IP packet MUST be validated to
>determine whether the received packet can be processed by BFD.
>  
> and
>  
>   Then the UDP destination port and the TTL or Hop Limit
>of the inner IP packet MUST be validated to determine whether the
>received packet can be processed by BFD.
>  
> In both cases, it's unclear to me if you're just saying "Geneve has certain
> validation rules that have to be met before the packet can be passed to the
> upper layer", or if you're introducing a new requirement. In the former case,
> please be more transparent about that, possibly with a citation to the
> validation rules in the underlying spec. You could also consider dropping the
> RFC 2119 MUST. In the latter case, if you're truly introducing a new
> requirement, I think the validation rules need to be spelled out much more
> clearly. (I think it's probably the former case.)
> [XM]>>> It seems a mix of the two cases, and for the former case the 
> underlying spec is RFC 5881.
>  
> Propose to change the text as below.
>  
> OLD
>  
>   Then the Destination IP, the UDP destination port and
>the TTL or Hop Limit of the inner IP packet MUST be validated to
>determine whether the received packet can be processed by BFD.
>  
> and
>  
>   Then the UDP destination port and the TTL or Hop Limit
>of the inner IP packet MUST be validated to determine whether the
>received packet can be processed by BFD.
>  
>  
>  
> NEW
>  
>   Then the Destination IP, the UDP destination port and
>the TTL or Hop Limit of the inner IP packet MUST be validated to
>determine whether the received packet can be processed by BFD,
>i.e., the three field values of the inner IP packet MUST be in compliance  
>with what's defined in Section 4.
 
Destination address and TTL are easy for me to work out from Section 4:
 
  -  Destination IP: IP address of a VAP of the terminating NVE.  If
 the VAP of the terminating NVE has 

Re: [nvo3] Éric Vyncke's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with DISCUSS and COMMENT)

[xiao.min2]

Thank you for clearing your DISCUSS, Eric!






Best Regards,


Xiao Min



Original



From: EricVyncke(evyncke) 
To: 肖敏10093570;
Cc: i...@ietf.org ;draft-ietf-nvo3-bfd-gen...@ietf.org 
;nvo3-cha...@ietf.org 
;nvo3@ietf.org ;matthew.bo...@nokia.com 
;d3e...@gmail.com ;
Date: 2023年08月24日 19:26
Subject: Re: [nvo3] Éric Vyncke's Discuss on draft-ietf-nvo3-bfd-geneve-12: 
(with DISCUSS and COMMENT)




Xiao,


 


The proposed text will address my DISCUSS point indeed. Thanks for the -13 
revision, I am clearing my previous DISCUSS ballot  ;-)


 


Other comments are also OK.


 


Regards


 


-éric


 


 



From: "xiao.m...@zte.com.cn" 
 Date: Wednesday, 23 August 2023 at 11:39
 To: Eric Vyncke 
 Cc: "i...@ietf.org" , "draft-ietf-nvo3-bfd-gen...@ietf.org" 
, "nvo3-cha...@ietf.org" 
, "nvo3@ietf.org" , 
"matthew.bo...@nokia.com" , "d3e...@gmail.com" 

 Subject: Re: [nvo3] Éric Vyncke's Discuss on draft-ietf-nvo3-bfd-geneve-12: 
(with DISCUSS and COMMENT)



 

Hi Eric,


 Thank you for the review and thoughtful comments.

Please see inline.


Original



From: ÉricVynckeviaDatatracker 



To: The IESG ;



Cc: draft-ietf-nvo3-bfd-gen...@ietf.org 
;nvo3-cha...@ietf.org 
;nvo3@ietf.org ;matthew.bo...@nokia.com 
;matthew.bo...@nokia.com 
;d3e...@gmail.com ;



Date: 2023年08月07日 17:56



Subject: [nvo3] Éric Vyncke's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with 
DISCUSS and COMMENT)




Éric Vyncke has entered the following ballot position for
 draft-ietf-nvo3-bfd-geneve-12: Discuss
 
 When responding, please keep the subject line intact and reply to all
 email addresses included in the To and CC lines. (Feel free to cut this
 introductory paragraph, however.)
 
 
 Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
 for more information about how to handle DISCUSS and COMMENT positions.
 
 
 The document, along with other ballot positions, can be found here:
 https://datatracker.ietf.org/doc/draft-ietf-nvo3-bfd-geneve/
 
 
 
 --
 DISCUSS:
 --
 
 
 # Éric Vyncke, INT AD, comments for raft-ietf-nvo3-bfd-geneve-12
 
 Thank you for the work put into this document.
 
 Please find below one blocking DISCUSS points (easy to address), some
 non-blocking COMMENT points (but replies would be appreciated even if only for
 my own education), and some nits.
 
 Special thanks to Matthew Bocci for the shepherd's detailed write-up including
 the WG consensus *and* the justification of the intended status.
 
 Other thanks to Don Eastlake, the Internet directorate reviewer (at my
 request), please consider this int-dir review:
 
https://datatracker.ietf.org/doc/review-ietf-nvo3-bfd-geneve-12-intdir-telechat-eastlake-2023-08-05/
 Don's review was 'not ready', and I concur with him after doing my own review.
 Authors' reply to Don's review will be welcome.
 [XM]>>> I've replied to Don's review and the resolutions to address his 
comments have been confirmed.

 

I hope that this review helps to improve the document,

[XM]>>> Yes, I'm sure about this.

 


Regards,
 
 -éric
 
 # DISCUSS
 
 As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
 DISCUSS ballot is a request to have a discussion on the following topics:
 
 ## Sectin 6
 
 I share Don's issue about having `Geneve provides security` and `Geneve does
 not have any inherent security mechanisms` in the same paragraph. There should
 probably some nuance or limitation in those two assertions to make them
 compatible.
 [XM]>>> The following proposed change has been accepted by Don, is that 
acceptable for you?

OLD
 Geneve provides security between the peers and subject to the issue of 
overload described below.
 NEW
 The IP underlay network and/or the Geneve option can provide security between 
the peers, which are subject to the issue of overload described below.

 


--
 COMMENT:
 --
 
 
 # COMMENTS
 
 ## Section 1
 
 Unsure whether the following text is useful here `The major difference between
 Geneve and VXLAN [RFC7348] is that Geneve supports multi-protocol payload and
 variable length options.`
 [XM]>>> Will remove the text you quoted.

 

I trust the transport ADs for the accuracy of the last paragraph about the


congestion control.

[XM]>>> To avoid possible confusion, I've proposed some editorial changes 
that's been confirmed by Don.

 


## Section 4.1
 
 `the BFD session SHOULD be identified using`, what is the procedure to be
 followed when it is not possible? The I-D should be clear on this.
 [XM]>>> OK. Propose to add some text to the end of this paragraph (both 
Section 4.1 and 5.1).

NEW

If it fails to identify the BFD session, the incoming BFD Control packets MUST 
be dropped, and an
 exception event indicating the 

Re: [nvo3] Zaheduzzaman Sarker's No Objection on draft-ietf-nvo3-bfd-geneve-12: (with COMMENT)

[xiao.min2]

Thank you for the confirmation, Zahed!






Best Regards,


Xiao Min






Original



From: ZaheduzzamanSarker 
To: 肖敏10093570;
Cc: i...@ietf.org ;draft-ietf-nvo3-bfd-gen...@ietf.org 
;nvo3-cha...@ietf.org 
;nvo3@ietf.org ;matthew.bo...@nokia.com 
;
Date: 2023年08月24日 16:42
Subject: Re: [nvo3] Zaheduzzaman Sarker's No Objection on 
draft-ietf-nvo3-bfd-geneve-12: (with COMMENT)





This is much better. Thanks for addressing my comments.

//Zahed




On Thu, Aug 24, 2023 at 9:25 AM  wrote:


Hi Zaheduzzaman,






Thank you for the review and thoughtful comments.


Please see inline.




Original


From: ZaheduzzamanSarkerviaDatatracker 
To: The IESG ;
Cc: draft-ietf-nvo3-bfd-gen...@ietf.org 
;nvo3-cha...@ietf.org 
;nvo3@ietf.org ;matthew.bo...@nokia.com 
;matthew.bo...@nokia.com ;
Date: 2023年08月07日 21:39
Subject: [nvo3] Zaheduzzaman Sarker's No Objection on 
draft-ietf-nvo3-bfd-geneve-12: (with COMMENT)

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-nvo3-bfd-geneve-12: No Objection
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
for more information about how to handle DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-bfd-geneve/
 
 
 
--
COMMENT:
--
 
Thanks for working on this specification. Special thanks to Magnus Westerlund
for identifying an important aspect in his TSVART review and I am happy to see
the resolution in the -11 version of this doc.
 
I have stumbled upon similar clarification issues that John has brought up in
his discuss. It not clear to me how this validation need to be done as written
in Section 5.1
 
 Then the UDP destination port and the TTL or Hop Limit of the inner IP
 packet MUST be validated to determine whether the received packet can be
 processed by BFD.
 
I was expecting pointers for those validation mechanism special to BFD. Can we
be more clear on this?
 [XM]>>> Yes. A new revision has just been posted, attempting to address all 
received comments. Link as below.

https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-bfd-geneve-13

Please check whether this version clarifies the issue.





Best Regards,

Xiao Min

___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Zaheduzzaman Sarker's No Objection on draft-ietf-nvo3-bfd-geneve-12: (with COMMENT)

[xiao.min2]

Hi Zaheduzzaman,






Thank you for the review and thoughtful comments.


Please see inline.




Original



From: ZaheduzzamanSarkerviaDatatracker 
To: The IESG ;
Cc: draft-ietf-nvo3-bfd-gen...@ietf.org 
;nvo3-cha...@ietf.org 
;nvo3@ietf.org ;matthew.bo...@nokia.com 
;matthew.bo...@nokia.com ;
Date: 2023年08月07日 21:39
Subject: [nvo3] Zaheduzzaman Sarker's No Objection on 
draft-ietf-nvo3-bfd-geneve-12: (with COMMENT)


Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-nvo3-bfd-geneve-12: No Objection
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
for more information about how to handle DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-bfd-geneve/
 
 
 
--
COMMENT:
--
 
Thanks for working on this specification. Special thanks to Magnus Westerlund
for identifying an important aspect in his TSVART review and I am happy to see
the resolution in the -11 version of this doc.
 
I have stumbled upon similar clarification issues that John has brought up in
his discuss. It not clear to me how this validation need to be done as written
in Section 5.1
 
 Then the UDP destination port and the TTL or Hop Limit of the inner IP
 packet MUST be validated to determine whether the received packet can be
 processed by BFD.
 
I was expecting pointers for those validation mechanism special to BFD. Can we
be more clear on this?
 [XM]>>> Yes. A new revision has just been posted, attempting to address all 
received comments. Link as below.

https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-bfd-geneve-13

Please check whether this version clarifies the issue.





Best Regards,

Xiao Min

___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Éric Vyncke's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with DISCUSS and COMMENT)

[xiao.min2]

Hi Eric,



Thank you for the review and thoughtful comments.



Please see inline.



Original



From: ÉricVynckeviaDatatracker 
To: The IESG ;
Cc: draft-ietf-nvo3-bfd-gen...@ietf.org 
;nvo3-cha...@ietf.org 
;nvo3@ietf.org ;matthew.bo...@nokia.com 
;matthew.bo...@nokia.com 
;d3e...@gmail.com ;
Date: 2023年08月07日 17:56
Subject: [nvo3] Éric Vyncke's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with 
DISCUSS and COMMENT)


Éric Vyncke has entered the following ballot position for
draft-ietf-nvo3-bfd-geneve-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-bfd-geneve/



--
DISCUSS:
--


# Éric Vyncke, INT AD, comments for raft-ietf-nvo3-bfd-geneve-12

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and some nits.

Special thanks to Matthew Bocci for the shepherd's detailed write-up including
the WG consensus *and* the justification of the intended status.

Other thanks to Don Eastlake, the Internet directorate reviewer (at my
request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-nvo3-bfd-geneve-12-intdir-telechat-eastlake-2023-08-05/
Don's review was 'not ready', and I concur with him after doing my own review.
Authors' reply to Don's review will be welcome.
[XM]>>> I've replied to Don's review and the resolutions to address his 
comments have been confirmed.



I hope that this review helps to improve the document,

[XM]>>> Yes, I'm sure about this.




Regards,

-éric

# DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

## Sectin 6

I share Don's issue about having `Geneve provides security` and `Geneve does
not have any inherent security mechanisms` in the same paragraph. There should
probably some nuance or limitation in those two assertions to make them
compatible.
[XM]>>> The following proposed change has been accepted by Don, is that 
acceptable for you?
OLDGeneve provides security between the peers and subject to the issue of 
overload described below.NEWThe IP underlay network and/or the Geneve option 
can provide security between the peers, which are subject to the issue of 
overload described below.




--
COMMENT:
--


# COMMENTS

## Section 1

Unsure whether the following text is useful here `The major difference between
Geneve and VXLAN [RFC7348] is that Geneve supports multi-protocol payload and
variable length options.`
[XM]>>> Will remove the text you quoted.



I trust the transport ADs for the accuracy of the last paragraph about the

congestion control.
[XM]>>> To avoid possible confusion, I've proposed some editorial changes 
that's been confirmed by Don.




## Section 4.1

`the BFD session SHOULD be identified using`, what is the procedure to be
followed when it is not possible? The I-D should be clear on this.
[XM]>>> OK. Propose to add some text to the end of this paragraph (both Section 
4.1 and 5.1).
NEW

If it fails to identify the BFD session, the incoming BFD Control packets MUST 
be dropped, and anexception event indicating the failure should be reported to 
the management.




## Section 5;1


`MUST be validated to determine` how can the receiving node validate ? Of
course, the reader can guess, but let's be specific.
[XM]>>> OK. John raised the similar issue, and I proposed to change the text as 
below.


OLD


  Then the UDP destination port and the TTL or Hop Limit   of 
the inner IP packet MUST be validated to determine whether the   received 
packet can be processed by BFD.





NEW


  Then the UDP destination port and the TTL or Hop Limit



   of the inner IP packet MUST be validated to determine whether the   received 
packet can be processed by BFD, i.e., the two field values of the   inner IP 
packet MUST be in compliance with what's defined in Section 5 of this document, 
as well as Section 4 of [RFC5881].




What should the receiving node do if this validation fails ?
[XM]>>> Propose to add some text to the end of this paragraph (both Section 4.1 
and 5.1).
NEW


If the validation fails, the received packet MUST NOT be processed by BFD.

Re: [nvo3] INTDIR Review of draft-ietf-nvo3-bfd-geneve-12

[xiao.min2]

Hi Donald,



Many thanks for your confirmation.


I'll incorporate all the agreed changes in the next rev.






Cheers,


Xiao Min





Original



From: DonaldEastlake 
To: 肖敏10093570;
Cc: int-...@ietf.org ;draft-ietf-nvo3-bfd-geneve@ietf.org 
;int-...@ietf.org 
;nvo3-cha...@ietf.org ;nvo3@ietf.org 
;
Date: 2023年08月22日 00:18
Subject: Re: [nvo3] INTDIR Review of draft-ietf-nvo3-bfd-geneve-12




Hi Xiao Min,

OK, with the further tweaks below I considera all my comments to have
been resolved.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Thu, Aug 17, 2023 at 2:54 AM  wrote:
>
> Hi Donald,
>
>
> Thank you for the response.
> Please see inline my comments tagged with [XM-2].
>
> CC'd to nvo3@ietf.org.
>
> Original
> From: DonaldEastlake 
> To: 肖敏10093570;
> Cc: int-...@ietf.org 
> ;draft-ietf-nvo3-bfd-geneve@ietf.org 
> ;int-...@ietf.org 
> ;nvo3-cha...@ietf.org ;
> Date: 2023年08月17日 04:44
> Subject: Re: INTDIR Review of draft-ietf-nvo3-bfd-geneve-12
> Xiao Min,
>
> On Tue, Aug 15, 2023 at 4:30 AM  wrote:
> >
> > Hi Donald,
> >
> > Thanks for your review and thoughtful comments.
> > Please see inline.
> >
> > Original
> > From: DonaldEastlake 
> > To: int-...@ietf.org 
> > ;draft-ietf-nvo3-bfd-geneve@ietf.org 
> > ;
> > Cc: int-...@ietf.org ;nvo3-cha...@ietf.org 
> > ;
> > Date: 2023年08月05日 19:23
> > Subject: INTDIR Review of draft-ietf-nvo3-bfd-geneve-12
> > I am an assigned INT directorate reviewer for
> > . These comments were written primarily
> > for the benefit of the Internet Area Directors. Document editors and
> > shepherd(s) should treat these comments just like they would treat
> > comments from any other IETF contributors and resolve them along with
> > any other Last Call comments that have been received. For more details
> > on the INT Directorate, see
> > https://datatracker.ietf.org/group/intdir/about/
> > .
> >
> > Based on my review, if I was on the IESG I would ballot this document
> > as DISCUSS. I have the following DISCUSS/ABSTAIN level issues:
> >
> > - I do not understand the second half of the last paragraph of Section
> > 1. It says: "BFD for Geneve MUST be used within a TMCE unless BFD is
> > congestion controlled." But then seems to specify that it be
> > congestion controlled inside a TMCE. Would it be simpler to say that
> > BFD for Geneve must always be congestion controlled, if that is what
> > is intended?
> > [XM]>>> The last paragraph of Section 1 was introduced to address comments 
> > from Magnus Westerlund in his Tsvart last call review [1].
> >
> > In Magnus's comments, it says
> >
> > "So I think there are two paths forward. Either restrict the applicability 
> > of
> > this usage to paths where it is known to have provisioned capacity for the 
> > BFD,
> > as noted as required in RFC 5881 applicability statement. The alternative 
> > is to
> > extend BFD to actually have a real congestion control."
> >
> > I agree with Magnus that "have provisioned capacity for the BFD" (as 
> > required in RFC 5881) and "a real congestion control" are two different 
> > things.
> > To avoid confusion, I propose to change the text as below.
> >
> > OLD
> >
> > BFD for Geneve MUST
> > be used within a TMCE unless BFD is congestion controlled.  An
> > operator of a TMCE deploying BFD for Geneve is required to provision
> > the rates at which BFD is transmitted to avoid congestion and false
> > failure detection.
> >
> > NEW
> >
> > BFD for Geneve MUST
> > be used within a TMCE unless BFD is really congestion controlled.  As an 
> > alternative to a real congestion control, an
> > operator of a TMCE deploying BFD for Geneve is required to provision
> > the rates at which BFD is transmitted to avoid congestion and false
> > failure detection.
> >
> > [1] https://mailarchive.ietf.org/arch/msg/nvo3/Gps8423YoowFB0lN2UudpLeGxHk/
>
> OK.
>
> > - The wording in Section 4.1 first paragraph seems confusing and
> >
> > incomplete. (I believe this has been covered in other reviews.)
> > [XM]>>> Yes, this has been covered in John's review.
> >
> >
> > - In the first paragraph of Section 6: How can it be that both "Geneve
> > provides security" and "Geneve does not have any inherent security
> > mechanisms" ?
> > [XM]>>> Propose to change the text as below.
> >
> > OLD
> >
> > Geneve provides security between the peers and subject to the issue of 
> > overload described below.
> >
> > NEW
> >
> > Geneve (through IPsec, DTLS, or other means) provides security between the 
> > peers and subject to the issue of overload described below.
>
> I think you are talking about wrapping Geneve in IPSEC / DTLS / etc. I
> don't see how this is Geneve providing security. It's IPSEC / DTLS /
> etc. providing security for whatever their payload is including where
> that payload is something wrapped in Geneve.
>
> [XM-2]>>> You're right. 

Re: [nvo3] INTDIR Review of draft-ietf-nvo3-bfd-geneve-12

[xiao.min2]

Hi Donald,



Thank you for the response.Please see inline my comments tagged with [XM-2].


CC'd to nvo3@ietf.org.



Original



From: DonaldEastlake 
To: 肖敏10093570;
Cc: int-...@ietf.org ;draft-ietf-nvo3-bfd-geneve@ietf.org 
;int-...@ietf.org 
;nvo3-cha...@ietf.org ;
Date: 2023年08月17日 04:44
Subject: Re: INTDIR Review of draft-ietf-nvo3-bfd-geneve-12


Xiao Min,
 
On Tue, Aug 15, 2023 at 4:30 AM  wrote:
> 
> Hi Donald,
> 
> Thanks for your review and thoughtful comments.
> Please see inline.
> 
> Original
> From: DonaldEastlake  
> To: int-...@ietf.org 
> ;draft-ietf-nvo3-bfd-geneve@ietf.org 
> ;
> Cc: int-...@ietf.org ;nvo3-cha...@ietf.org 
> ;
> Date: 2023年08月05日 19:23
> Subject: INTDIR Review of draft-ietf-nvo3-bfd-geneve-12
> I am an assigned INT directorate reviewer for
> . These comments were written primarily
> for the benefit of the Internet Area Directors. Document editors and
> shepherd(s) should treat these comments just like they would treat
> comments from any other IETF contributors and resolve them along with
> any other Last Call comments that have been received. For more details
> on the INT Directorate, see
> https://datatracker.ietf.org/group/intdir/about/
> .
> 
> Based on my review, if I was on the IESG I would ballot this document
> as DISCUSS. I have the following DISCUSS/ABSTAIN level issues:
> 
> - I do not understand the second half of the last paragraph of Section
> 1. It says: "BFD for Geneve MUST be used within a TMCE unless BFD is
> congestion controlled." But then seems to specify that it be
> congestion controlled inside a TMCE. Would it be simpler to say that
> BFD for Geneve must always be congestion controlled, if that is what
> is intended?
> [XM]>>> The last paragraph of Section 1 was introduced to address comments 
> from Magnus Westerlund in his Tsvart last call review [1].
> 
> In Magnus's comments, it says
> 
> "So I think there are two paths forward. Either restrict the applicability of
> this usage to paths where it is known to have provisioned capacity for the 
> BFD,
> as noted as required in RFC 5881 applicability statement. The alternative is 
> to
> extend BFD to actually have a real congestion control." 
> 
> I agree with Magnus that "have provisioned capacity for the BFD" (as required 
> in RFC 5881) and "a real congestion control" are two different things.
> To avoid confusion, I propose to change the text as below.
> 
> OLD
> 
> BFD for Geneve MUST
> be used within a TMCE unless BFD is congestion controlled.  An
> operator of a TMCE deploying BFD for Geneve is required to provision
> the rates at which BFD is transmitted to avoid congestion and false
> failure detection.
> 
> NEW
> 
> BFD for Geneve MUST
> be used within a TMCE unless BFD is really congestion controlled.  As an 
> alternative to a real congestion control, an
> operator of a TMCE deploying BFD for Geneve is required to provision
> the rates at which BFD is transmitted to avoid congestion and false
> failure detection.
> 
> [1] https://mailarchive.ietf.org/arch/msg/nvo3/Gps8423YoowFB0lN2UudpLeGxHk/
 
OK.
 
> - The wording in Section 4.1 first paragraph seems confusing and
> 
> incomplete. (I believe this has been covered in other reviews.)
> [XM]>>> Yes, this has been covered in John's review.
> 
> 
> - In the first paragraph of Section 6: How can it be that both "Geneve
> provides security" and "Geneve does not have any inherent security
> mechanisms" ?
> [XM]>>> Propose to change the text as below.
> 
> OLD
> 
> Geneve provides security between the peers and subject to the issue of 
> overload described below.
> 
> NEW
> 
> Geneve (through IPsec, DTLS, or other means) provides security between the 
> peers and subject to the issue of overload described below.
 
I think you are talking about wrapping Geneve in IPSEC / DTLS / etc. I
don't see how this is Geneve providing security. It's IPSEC / DTLS /
etc. providing security for whatever their payload is including where
that payload is something wrapped in Geneve.
 [XM-2]>>> You're right. Let me try again.

OLDGeneve provides security between the peers and subject to the issue of 
overload described below.NEWThe IP underlay network and/or the Geneve option 
can provide security between the peers, which are subject to the issue of 
overload described below.




> The following are other issues I found with this document that SHOULD

> be corrected before publication:
> 
> - In section 4, the Inner Ethernet Header MAC addresses are in the
> wrong order. The Destination MAC comes first, followed by the Source
> MAC in an Ethernet header, the opposite of IP.
> [XM]>>> OK. Propose to change the text as below.
> 
> OLD
> 
> Inner Ethernet Header:¶
> Source MAC: MAC address of a VAP of the originating NVE.¶
> Destination MAC: MAC address of a VAP of the terminating NVE.
> 
> NEW
> 
> Inner Ethernet Header:¶
> Destination MAC: MAC address of a VAP of the terminating NVE.
> Source MAC: MAC 

Re: [nvo3] John Scudder's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with DISCUSS and COMMENT)

[xiao.min2]

Hi John,






Thank you for the response.
Please see inline my comments tagged with [XM-2].




Original



From: JohnScudder 
To: 肖敏10093570;
Cc: The IESG ;draft-ietf-nvo3-bfd-gen...@ietf.org 
;nvo3-cha...@ietf.org 
;nvo3@ietf.org ;matthew.bo...@nokia.com 
;
Date: 2023年08月15日 23:26
Subject: Re: John Scudder's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with 
DISCUSS and COMMENT)


Hi Xiao Min,
 
Thanks for your reply. Some further comments in line below.
 
> On Aug 4, 2023, at 4:14 AM, xiao.m...@zte.com.cn wrote:
>  
>  
> Hi John,
>  
>  
>  
> Thank you for the review and thoughtful comments.
>  
> Please see inline.
>  
> Original
> From: JohnScudderviaDatatracker  
> To: The IESG ;
> Cc: draft-ietf-nvo3-bfd-gen...@ietf.org 
> ;nvo3-cha...@ietf.org 
> ;nvo3@ietf.org ;matthew.bo...@nokia.com 
> ;matthew.bo...@nokia.com ;
> Date: 2023年08月04日 03:40
> Subject: John Scudder's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with 
> DISCUSS and COMMENT)
> John Scudder has entered the following ballot position for
> draft-ietf-nvo3-bfd-geneve-12: Discuss
>  
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>  
>  
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
>  
> for more information about how to handle DISCUSS and COMMENT positions.
>  
>  
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-nvo3-bfd-geneve/
>  
>  
>  
> --
> DISCUSS:
> --
>  
> Thanks for this valuable and easy-to-read spec. I have one concern that I'd
> like to have a discussion about; I hope this will be easy to resolve.
> [XM]>>> I believe so. :-)
>  
>  
>  
> There are several places where you use MUST in a way I think is unnecessary,
> you seem to be saying, in effect, "to do Geneve you MUST do Geneve". Most of
> these are harmless IMO (I put some examples in the COMMENT section just in 
> case
> you're unclear what I'm talking about) but there are two that seem problematic
> to me, nearly-identical sentences from Sections 4.1 and 5.1:
>  
>   Then the Destination IP, the UDP destination port and
>the TTL or Hop Limit of the inner IP packet MUST be validated to
>determine whether the received packet can be processed by BFD.
>  
> and
>  
>   Then the UDP destination port and the TTL or Hop Limit
>of the inner IP packet MUST be validated to determine whether the
>received packet can be processed by BFD.
>  
> In both cases, it's unclear to me if you're just saying "Geneve has certain
> validation rules that have to be met before the packet can be passed to the
> upper layer", or if you're introducing a new requirement. In the former case,
> please be more transparent about that, possibly with a citation to the
> validation rules in the underlying spec. You could also consider dropping the
> RFC 2119 MUST. In the latter case, if you're truly introducing a new
> requirement, I think the validation rules need to be spelled out much more
> clearly. (I think it's probably the former case.)
> [XM]>>> It seems a mix of the two cases, and for the former case the 
> underlying spec is RFC 5881.
>  
> Propose to change the text as below.
>  
> OLD
>  
>   Then the Destination IP, the UDP destination port and
>the TTL or Hop Limit of the inner IP packet MUST be validated to
>determine whether the received packet can be processed by BFD.
>  
> and
>  
>   Then the UDP destination port and the TTL or Hop Limit
>of the inner IP packet MUST be validated to determine whether the
>received packet can be processed by BFD.
>  
>  
>  
> NEW
>  
>   Then the Destination IP, the UDP destination port and
>the TTL or Hop Limit of the inner IP packet MUST be validated to
>determine whether the received packet can be processed by BFD,
>i.e., the three field values of the inner IP packet MUST be in compliance  
>with what's defined in Section 4.
 
Destination address and TTL are easy for me to work out from Section 4:
 
  -  Destination IP: IP address of a VAP of the terminating NVE.  If
 the VAP of the terminating NVE has no IP address, then the IP
 address 127.0.0.1 for IPv4 or ::1/128 for IPv6 MUST be used.
 
  -  TTL or Hop Limit: MUST be set to 255
 
Port isn’t explicitly mentioned in Section 4, but I guess this is the relevant 
paragraph:
 
  The fields of the UDP header and the BFD Control packet are
  encoded as specified in [RFC5881].
 
When I look in RFC 5881, I think the relevant requirement is in Section 4:
 
   BFD Control packets MUST be transmitted in UDP packets with
   destination port 3784, within an IPv4 or 

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

[xiao.min2]

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 
To: 肖敏10093570;
Cc: aldrin.i...@gmail.com ;nvo3@ietf.org 
;nvo3-cha...@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  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 
To: NVO3 ;nvo3-cha...@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 

Re: [nvo3] John Scudder's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with DISCUSS and COMMENT)

[xiao.min2]

Hi John,






Thank you for the review and thoughtful comments.


Please see inline.



Original



From: JohnScudderviaDatatracker 
To: The IESG ;
Cc: draft-ietf-nvo3-bfd-gen...@ietf.org 
;nvo3-cha...@ietf.org 
;nvo3@ietf.org ;matthew.bo...@nokia.com 
;matthew.bo...@nokia.com ;
Date: 2023年08月04日 03:40
Subject: John Scudder's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with DISCUSS 
and COMMENT)


John Scudder has entered the following ballot position for
draft-ietf-nvo3-bfd-geneve-12: Discuss
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
for more information about how to handle DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-bfd-geneve/
 
 
 
--
DISCUSS:
--
 
Thanks for this valuable and easy-to-read spec. I have one concern that I'd
like to have a discussion about; I hope this will be easy to resolve.
 [XM]>>> I believe so. :-)




There are several places where you use MUST in a way I think is unnecessary,
you seem to be saying, in effect, "to do Geneve you MUST do Geneve". Most of
these are harmless IMO (I put some examples in the COMMENT section just in case
you're unclear what I'm talking about) but there are two that seem problematic
to me, nearly-identical sentences from Sections 4.1 and 5.1:
 
  Then the Destination IP, the UDP destination port and
   the TTL or Hop Limit of the inner IP packet MUST be validated to
   determine whether the received packet can be processed by BFD.
 
and
 
  Then the UDP destination port and the TTL or Hop Limit
   of the inner IP packet MUST be validated to determine whether the
   received packet can be processed by BFD.
 
In both cases, it's unclear to me if you're just saying "Geneve has certain
validation rules that have to be met before the packet can be passed to the
upper layer", or if you're introducing a new requirement. In the former case,
please be more transparent about that, possibly with a citation to the
validation rules in the underlying spec. You could also consider dropping the
RFC 2119 MUST. In the latter case, if you're truly introducing a new
requirement, I think the validation rules need to be spelled out much more
clearly. (I think it's probably the former case.)
 [XM]>>> It seems a mix of the two cases, and for the former case the 
underlying spec is RFC 5881.

Propose to change the text as below.

OLD


  Then the Destination IP, the UDP destination port and   the 
TTL or Hop Limit of the inner IP packet MUST be validated to   determine 
whether the received packet can be processed by BFD.and  Then 
the UDP destination port and the TTL or Hop Limit   of the inner IP packet MUST 
be validated to determine whether the   received packet can be processed by BFD.




NEW

  Then the Destination IP, the UDP destination port and   the 
TTL or Hop Limit of the inner IP packet MUST be validated to   determine 
whether the received packet can be processed by BFD,   i.e., the three field 
values of the inner IP packet MUST be in compliance 
   with what's defined in Section 4.




and  Then the UDP destination port and the TTL or Hop Limit   
of the inner IP packet MUST be validated to determine whether the   received 
packet can be processed by BFD, i.e., the two field values of the 
   inner IP packet MUST be in compliance with what's defined in Section 5.


--
COMMENT:
--
 
- Please consider expanding "FCS" where used, or glossing it elsewhere.
 [XM]>>> OK. Will add "FCS" to the Abbreviations section.


- This sentence in Sections 4.1 and 5.1,


  The Destination MAC of the inner Ethernet
   frame matches the MAC address of a VAP which is mapped to the same as
   received VNI.
 
has a grammatical problem that prevents me from making sense of it. I *think*
you are missing a noun after "the same", so it should be something like "The
Destination MAC _address_ of the inner Ethernet frame matches the MAC address
of a VAP which is mapped to the same _???_ as _the_ received VNI." 
 
Or maybe some other rewrite is needed, but anyway, it's not clear as it stands.
 [XM]>>> Propose to change this sentence as below.

OLD

  The Destination MAC of the inner Ethernet   frame 
matches the MAC address of a VAP which is mapped to the same as   received VNI.

NEW

  The Destination MAC 

Re: [nvo3] Roman Danyliw's No Objection on draft-ietf-nvo3-bfd-geneve-12: (with COMMENT)

[xiao.min2]

Hi Roman,






Thank you for the review and comment.



I believe a normative "RECOMMENDED" is appropriate. Will incorporate this 
change into the next revision.






Best Regards,


Xiao Min



Original



From: RomanDanyliwviaDatatracker 
To: The IESG ;
Cc: draft-ietf-nvo3-bfd-gen...@ietf.org 
;nvo3-cha...@ietf.org 
;nvo3@ietf.org ;matthew.bo...@nokia.com 
;matthew.bo...@nokia.com ;
Date: 2023年08月02日 05:47
Subject: Roman Danyliw's No Objection on draft-ietf-nvo3-bfd-geneve-12: (with 
COMMENT)


Roman Danyliw has entered the following ballot position for
draft-ietf-nvo3-bfd-geneve-12: No Objection
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
for more information about how to handle DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-bfd-geneve/
 
 
 
--
COMMENT:
--
 
Thank you to Carl Wallace for the SECDIR review.
 
** Section 6
   The BFD
   introduces no security vulnerabilities when run in this manner.
   Considering Geneve does not have any inherent security mechanisms,
   BFD authentication as specified in [RFC5880] is recommended to be
   utilized.
 
Consider if a normative “RECOMMENDED” is appropriate for encouraging the use of 
BFD authentication.___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Secdir last call review of draft-ietf-nvo3-bfd-geneve-11

[xiao.min2]

Hi Carl,






Many thanks for your review and conclusion.


Yes, I believe a reference to RFC5880 and a suggestion to use BFD 
authentication should be added to security section. I'll post a new version 
with these changes after the submission is reopened.






Best Regards,


Xiao Min



Original



From: CarlWallaceviaDatatracker 
To: sec...@ietf.org ;
Cc: draft-ietf-nvo3-bfd-geneve@ietf.org 
;last-c...@ietf.org 
;nvo3@ietf.org ;
Date: 2023年07月11日 18:25
Subject: [nvo3] Secdir last call review of draft-ietf-nvo3-bfd-geneve-11



Reviewer: Carl Wallace
Review result: Ready
 
The draft describes the use of the BFD protocol with Geneve tunnels. The draft
is well-written and clear. As someone not familiar with either BFD or Geneve I
had one question. The security considerations section references RFC8926 but
not RFC5880. Should it reference RFC5880? In particular, the authentication
mechanisms in 5880 seem potentially worth mentioning, even if only to discount
their use.
 
 
___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Opsdir last call review of draft-ietf-nvo3-bfd-geneve-11

[xiao.min2]

Hi Sheng,






Many thanks for your review and conclusion.






Best Regards,


Xiao Min



Original



From: ShengJiangviaDatatracker 
To: ops-...@ietf.org ;
Cc: draft-ietf-nvo3-bfd-geneve@ietf.org 
;last-c...@ietf.org 
;nvo3@ietf.org ;
Date: 2023年07月11日 16:05
Subject: [nvo3] Opsdir last call review of draft-ietf-nvo3-bfd-geneve-11


Reviewer: Sheng Jiang
Review result: Ready
 
Document: draft-ietf-nvo3-bfd-geneve-11
Reviewer: Sheng Jiang
Review Date: 2023-07-11
Review result: Ready
 
I have reviewed this document as part of the OPS directorate's ongoing
effort to review all IETF documents being processed by the IESG. Comments that
are not addressed in last call may be included in AD reviews during the IESG
review. Document editors and WG chairs should treat these comments just like
any other last call comments.
 
This document intents for Standards Track. This document describes the use of
the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Generic
Network Virtualization Encapsulation (Geneve) unicast tunnels used to make up
an overlay network.
 
This document is well-written and NITs free. It is READY for publication.
 
 
___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Gen-ART Last Call review of draft-ietf-nvo3-bfd-geneve-11

[xiao.min2]

Hi Paul,






Many thanks for your review and conclusion.



Best Regards,


Xiao Min



Original



From: PaulKyzivat 
To: draft-ietf-nvo3-bfd-geneve@ietf.org 
;
Cc: General Area Review Team ;last-c...@ietf.org 
;nvo3@ietf.org ;
Date: 2023年07月09日 03:35
Subject: [nvo3] Gen-ART Last Call review of draft-ietf-nvo3-bfd-geneve-11


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.
 
For more information, please see the FAQ at
 
.
 
Document: draft-ietf-nvo3-bfd-geneve-11
Reviewer: Paul Kyzivat
Review Date: 2023-07-11
IETF LC End Date: 2023-07-08
IESG Telechat date: ?
 
Summary:
 
This draft is ready for publication as a Standards Track RFC.
 
___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Tsvart last call review of draft-ietf-nvo3-bfd-geneve-10

[xiao.min2]

Hi Magnus,






Thank you for the prompt reply.


A new version has just been posted to address your comments. Link as below.


https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-bfd-geneve-11


I also cc BFD WG to see if some new ideas can be motivated by your good 
observation.






Best Regards,


Xiao Min




Original



From: MagnusWesterlund 
To: 肖敏10093570;
Cc: tsv-...@ietf.org ;draft-ietf-nvo3-bfd-geneve@ietf.org 
;last-c...@ietf.org 
;nvo3@ietf.org ;
Date: 2023年07月04日 15:59
Subject: Re: [nvo3] Tsvart last call review of draft-ietf-nvo3-bfd-geneve-10


___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

 

Hi Xiao Min,


 


I think that text is mostly fine, I would think that this RECOMMENDED needs to 
be a “MUST unless BFD is congestion controlled”. That later part as a caveat if 
one can actually deploy a BFD congestion control.  


 


I would really recommend routing area to look into this problem of how to 
separate path failures, from on path congestion (especially self inflicted), or 
endpoint overload. Which appears to be the different things desired to be 
separated for BFD.


 


Note, I don’t expect congestion control for BFD to look like TCP at all. I 
would expect it to be something may be fairly slow in reaction, which allows 
BFD in those deployments where it is needed to step down the load on the 
network and the end points to see if the failure to get all/some packets 
through are dependent on the introduced load.


 


Cheers


 


Magnus


 


 




From: xiao.m...@zte.com.cn 
 Date: Tuesday, 4 July 2023 at 08:49
 To: Magnus Westerlund 
 Cc: tsv-...@ietf.org , 
draft-ietf-nvo3-bfd-geneve@ietf.org 
, last-c...@ietf.org 
, nvo3@ietf.org 
 Subject: Re: [nvo3] Tsvart last call review of draft-ietf-nvo3-bfd-geneve-10


Hi Magnus,

 

Thank you for the review and thoughtful comments.

Please see inline.


Original



From: MagnusWesterlundviaDatatracker 



To: tsv-...@ietf.org ;



Cc: draft-ietf-nvo3-bfd-geneve@ietf.org 
;last-c...@ietf.org 
;nvo3@ietf.org ;



Date: 2023年07月03日 17:36



Subject: [nvo3] Tsvart last call review of draft-ietf-nvo3-bfd-geneve-10




Reviewer: Magnus Westerlund
 Review result: Not Ready
 
 This document has been reviewed as part of the transport area review team's
 ongoing effort to review key IETF documents. These comments were written
 primarily for the transport area directors, but are copied to the document's
 authors and WG to allow them to address any issues raised and also to the IETF
 discussion list for information.
 
 When done at the time of IETF Last Call, the authors should consider this
 review as part of the last-call comments they receive. Please always CC
 tsv-...@ietf.org if you reply to or forward this review.
 
 I have reviewed BFD for Geneve (draft-ietf-nvo3-bfd-geneve-10) and have one
 significant point on this protocol. So when BFD was published after quite some
 discussion about the lack of an actual congestion control mechanism in BFD in
 RFC 5880 there was agreement on the following that was included in Section 7 of
 RFC 5880:
 
When BFD is used across multiple hops, a congestion control mechanism
MUST be implemented, and when congestion is detected, the BFD
implementation MUST reduce the amount of traffic it generates.  The
exact mechanism used is outside the scope of this specification, and
the requirements of this mechanism may differ depending on how BFD is
deployed, and how it interacts with other parts of the system (for
example, exponential backoff may not be appropriate in cases where
routing protocols are interacting closely with BFD).
 
 As this usage of BFD although is point to point inside the tunnel, the fact
 that it is a tunnel and can bridge both multisegment L2 and especially IP
 networks means that this document in my view need to define how it fulfills the
 above requirements when using BFD.
 
 I do note the security consideration do note that overload is a factor due to
 multiple path sharing tunnel establishments. So there are apparently risks from
 two types of overlad situations here. First that multiple tunnles between
 endpoints are established. Secondly, that there are congestion due to network
 cross traffic on the paths the tunnels share.
 
 So I think there are two paths forward. Either restrict the applicability of
 this usage to paths where it is known to have provisioned capacity for the BFD,
 as noted as required in RFC 5881 applicability statement. The alternative is to
 extend BFD to actually have a real congestion control. Something I think would
 have benefit all considering how wide spread use there is of BFD over various
 overlay networks that really are ignoring this potential issue.

[XM]>>> I lean to the former one. Propose to add a new paragraph to the last of 
Introduction section.

NEW

As specified in Section 4.2 of [RFC8926], Geneve MUST be used with 

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

[xiao.min2]

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 
To: NVO3 ;nvo3-cha...@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

Re: [nvo3] Tsvart last call review of draft-ietf-nvo3-bfd-geneve-10

[xiao.min2]

Hi Magnus,






Thank you for the review and thoughtful comments.


Please see inline.



Original



From: MagnusWesterlundviaDatatracker 
To: tsv-...@ietf.org ;
Cc: draft-ietf-nvo3-bfd-geneve@ietf.org 
;last-c...@ietf.org 
;nvo3@ietf.org ;
Date: 2023年07月03日 17:36
Subject: [nvo3] Tsvart last call review of draft-ietf-nvo3-bfd-geneve-10


Reviewer: Magnus Westerlund
Review result: Not Ready
 
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.
 
When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this review.
 
I have reviewed BFD for Geneve (draft-ietf-nvo3-bfd-geneve-10) and have one
significant point on this protocol. So when BFD was published after quite some
discussion about the lack of an actual congestion control mechanism in BFD in
RFC 5880 there was agreement on the following that was included in Section 7 of
RFC 5880:
 
   When BFD is used across multiple hops, a congestion control mechanism
   MUST be implemented, and when congestion is detected, the BFD
   implementation MUST reduce the amount of traffic it generates.  The
   exact mechanism used is outside the scope of this specification, and
   the requirements of this mechanism may differ depending on how BFD is
   deployed, and how it interacts with other parts of the system (for
   example, exponential backoff may not be appropriate in cases where
   routing protocols are interacting closely with BFD).
 
As this usage of BFD although is point to point inside the tunnel, the fact
that it is a tunnel and can bridge both multisegment L2 and especially IP
networks means that this document in my view need to define how it fulfills the
above requirements when using BFD.
 
I do note the security consideration do note that overload is a factor due to
multiple path sharing tunnel establishments. So there are apparently risks from
two types of overlad situations here. First that multiple tunnles between
endpoints are established. Secondly, that there are congestion due to network
cross traffic on the paths the tunnels share.
 
So I think there are two paths forward. Either restrict the applicability of
this usage to paths where it is known to have provisioned capacity for the BFD,
as noted as required in RFC 5881 applicability statement. The alternative is to
extend BFD to actually have a real congestion control. Something I think would
have benefit all considering how wide spread use there is of BFD over various
overlay networks that really are ignoring this potential issue.
 [XM]>>> I lean to the former one. Propose to add a new paragraph to the last 
of Introduction section.

NEW

As specified in Section 4.2 of [RFC8926], Geneve MUST be used with 
congestion-controlled traffic 
or within a traffic-managed controlled environment (TMCE) to avoid congestion, 
that requirement 
applies to BFD traffic too. Specifically, considering the complexity and 
immaturity of BFD congestion 
control mechanism, BFD for Geneve is RECOMMENDED to be used within a TMCE. An 
operator of a 
TMCE deploying BFD for Geneve is required to provision the rates at which BFD 
is transmitted to 
avoid congestion and false failure detection.




To conclude I am of the oppinion that this document should not be approved for
publication until this issue of congestion control is handled one way of
another.
 [XM]>>> Please check the proposed new text and let me know whether your 
concern is addressed.
 
 Thanks,

Xiao Min

___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Document shepherd review of draft-ietf-nvo3-bfd-geneve-03

[xiao.min2]

Hi Matthew,




Thank you for the shepherd review and very helpful comments.


I've posted -09 revision attempting to address your comments. Link as below.

https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-bfd-geneve-09 




Best Regards,

Xiao Min



Original



From: MatthewBocci(Nokia) 
To: NVO3 ;draft-ietf-nvo3-bfd-gen...@ietf.org 
;
Date: 2022年11月25日 19:37
Subject: [nvo3] Document shepherd review of draft-ietf-nvo3-bfd-geneve-03


___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

 

Authors,


 


As is customary, here is my review of this draft. The draft is clear and to the 
point – thanks. However, I have a few minor editorial comments that I would 
appreciate if you could address before we progress the draft to the next stage.


 

The text is missing the definitive article (a/the, etc) or plurals (s) in many 
cases. This makes it difficult to read. The introduction is particularly at 
fault, but there are other areas too. Please go through the draft and add these.

There are some cases where you have broken up extremely long sentences with 
many commas, when use of a full stop / period would be more appropriate. This 
also makes the text difficult to parse. Please go through the draft and update 
the text as necessary.



 
 Thanks,


 


Matthew___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

[xiao.min2]

Hi Matthew,






Thank you for concluding the extended WG last call.


I've posted the -08 revision to address all the agreed WG last call comments. 
Link as below.


https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-bfd-geneve-08






Best Regards,


Xiao Min



Original



From: MatthewBocci(Nokia) 
To: NVO3 ;rtg-...@ietf.org ;
Date: 2022年11月17日 17:49
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks




This email concludes the extended WG last call.


 


Authors: Please update the draft as per the  agreed WG last call comments so 
that we can progress to the next steps.


 


Regards


 


Matthew


 



From: Bocci, Matthew (Nokia - GB) 
 Date: Friday, 21 October 2022 at 10:37
 To: NVO3 , rtg-...@ietf.org 
 Subject: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks



NVO3 and BFD working groups,


 


To give more time to review and comment on this draft in the light of the draft 
submission deadline of 24th October, I am extending this WG last call to Friday 
4th November 2022.


 


Please review and post any comments to the NVO3 list (including whether you 
support publication as an RFC).


 


Thanks


 


Matthew___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

[xiao.min2]

Hi Matthew,






Would you please conclude the extended WG LC for draft-ietf-nvo3-bfd-geneve?






Best Regards,


Xiao Min









Original



From: 肖敏10093570
To: ReshadRahman ;
Cc: nvo3@ietf.org ;rtg-...@ietf.org 
;matthew.bo...@nokia.com ;
Date: 2022年11月09日 10:24
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks




Hi Reshad,







Thank you for the quick reply.


Please see inline [XM-2]...

















From: ReshadRahman 
To: 肖敏10093570;
Cc: nvo3@ietf.org ;rtg-...@ietf.org 
;matthew.bo...@nokia.com ;
Date: 2022年11月09日 04:12
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks







Hi Xiao Min,




Thanks for the prompt response. Inline .






On Monday, November 7, 2022, 02:14:05 AM EST, xiao.m...@zte.com.cn 
 wrote:









Hi Reshad,






Thank you for the thorough review and thoughtful comments.


Please see inline...





Best Regards,


Xiao Min



Original



From: ReshadRahman 
To: NVO3 ;rtg-...@ietf.org ;Bocci, Matthew 
(Nokia - GB) ;
Date: 2022年11月07日 00:06
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks




Hi,


- The abstract mentions point-to-point Geneve tunnels. Might be good to add 
"unicast"?


[XM]>>> OK. Will add it in the next revision.


- I don't see it being spelled out that this is single-hop BFD, except the 
reference to RFC 5881 and setting TTL to 255. Might be good to be explicit. 
FWIW RFC 8971 isn't very explicit either...

[XM]>>> OK. Will make it explicit in the next revision.




- RFC 8926 mentions that a Geneve tunnel is unidirectional. Can demand mode be 
used?


[XM]>>> Yes, I think so. Considering both RFC 8971 and RFC 5881 don't mention 
Demand mode, do you see a need to mention it in this document?




 I should have phrased my question better. If a Geneve tunnel is indeed 
unidirectional, was any consideration given to using demand mode so that the 
"receiver" isn't actively sending BFD control packets out of band (since the 
tunnel is unidirectional) to the "sender". But since this is unicast, I think 
you can ignore that.

[XM-2]>>> OK.



 

- Section 4.1 "and use the same way to encapsulate data packets.". So a VAP is 
either IP or ethernet and both VAPs have to use same encaps. What if 1 is v4 
and the other is v6? May need more details on this, either in section 1 or 
section 3.


[XM]>>> Section 4.1 also says "a BFD session can only be established between 
two VAPs that are mapped to the same VNI". I don't believe the case you 
described exists in one VNI, what do you think?




 Ack.


- Section 5: "Virtual Network Identifier (VNI) field SHOULD be set to the VNI 
number that the originating VAP is mapped to.". OOC, why is this a SHOULD and 
not a MUST? Specifically, why would it not be set to the VNI of the originating 
VAP? Section 4.1 mentions same VNI being used between the 2 VAPs.

[XM]>>> The reason is that the originating VAP could also choose to use 
Management VNI. 




 Ah right. I think you may get the same question later in the IETF process, 
so adding this in the document would help. 

[XM-2]>>> OK. Will add this in the document.



- If there is a YANG model for VAPs (not covered in draft-ietf-nvo3-yang-cfg 
which has expired), I would like to see YANG for BFD over Geneve. Not sure 
whether new config is needed, but there will be new operational state (in 
Geneve and in BFD). Whether it's in the same doc or in a separate parallel doc 
is above my pay grade.

[XM]>>> I see. As an author of draft-ietf-nvo3-bfd-geneve, I think the 
potential YANG should be outside the scope.



 Generally/ideally I would prefer to see YANG being done in the same doc. 
But in this case, I think that's not possible.

[XM-2]>>> Thank you for your understanding. If you're interested to write a 
YANG module for this feature, I would like to help. :-)




Best Regards,

Xiao Min





Regards,

Reshad.





Regards,

Reshad.




On Friday, October 21, 2022, 05:37:22 AM EDT, Bocci, Matthew (Nokia - GB) 
 wrote:





NVO3 and BFD working groups,


 


To give more time to review and comment on this draft in the light of the draft 
submission deadline of 24th October, I am extending this WG last call to Friday 
4th November 2022.


 


Please review and post any comments to the NVO3 list (including whether you 
support publication as an RFC).


 


Thanks


 


Matthew___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

[xiao.min2]

Hi Reshad,







Thank you for the quick reply.


Please see inline [XM-2]...









Original



From: ReshadRahman 
To: 肖敏10093570;
Cc: nvo3@ietf.org ;rtg-...@ietf.org 
;matthew.bo...@nokia.com ;
Date: 2022年11月09日 04:12
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks







Hi Xiao Min,




Thanks for the prompt response. Inline .






On Monday, November 7, 2022, 02:14:05 AM EST, xiao.m...@zte.com.cn 
 wrote:









Hi Reshad,






Thank you for the thorough review and thoughtful comments.


Please see inline...





Best Regards,


Xiao Min



Original



From: ReshadRahman 
To: NVO3 ;rtg-...@ietf.org ;Bocci, Matthew 
(Nokia - GB) ;
Date: 2022年11月07日 00:06
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks




Hi,


- The abstract mentions point-to-point Geneve tunnels. Might be good to add 
"unicast"?


[XM]>>> OK. Will add it in the next revision.


- I don't see it being spelled out that this is single-hop BFD, except the 
reference to RFC 5881 and setting TTL to 255. Might be good to be explicit. 
FWIW RFC 8971 isn't very explicit either...

[XM]>>> OK. Will make it explicit in the next revision.




- RFC 8926 mentions that a Geneve tunnel is unidirectional. Can demand mode be 
used?


[XM]>>> Yes, I think so. Considering both RFC 8971 and RFC 5881 don't mention 
Demand mode, do you see a need to mention it in this document?




 I should have phrased my question better. If a Geneve tunnel is indeed 
unidirectional, was any consideration given to using demand mode so that the 
"receiver" isn't actively sending BFD control packets out of band (since the 
tunnel is unidirectional) to the "sender". But since this is unicast, I think 
you can ignore that.

[XM-2]>>> OK.



 

- Section 4.1 "and use the same way to encapsulate data packets.". So a VAP is 
either IP or ethernet and both VAPs have to use same encaps. What if 1 is v4 
and the other is v6? May need more details on this, either in section 1 or 
section 3.


[XM]>>> Section 4.1 also says "a BFD session can only be established between 
two VAPs that are mapped to the same VNI". I don't believe the case you 
described exists in one VNI, what do you think?




 Ack.


- Section 5: "Virtual Network Identifier (VNI) field SHOULD be set to the VNI 
number that the originating VAP is mapped to.". OOC, why is this a SHOULD and 
not a MUST? Specifically, why would it not be set to the VNI of the originating 
VAP? Section 4.1 mentions same VNI being used between the 2 VAPs.

[XM]>>> The reason is that the originating VAP could also choose to use 
Management VNI. 




 Ah right. I think you may get the same question later in the IETF process, 
so adding this in the document would help. 

[XM-2]>>> OK. Will add this in the document.



- If there is a YANG model for VAPs (not covered in draft-ietf-nvo3-yang-cfg 
which has expired), I would like to see YANG for BFD over Geneve. Not sure 
whether new config is needed, but there will be new operational state (in 
Geneve and in BFD). Whether it's in the same doc or in a separate parallel doc 
is above my pay grade.

[XM]>>> I see. As an author of draft-ietf-nvo3-bfd-geneve, I think the 
potential YANG should be outside the scope.



 Generally/ideally I would prefer to see YANG being done in the same doc. 
But in this case, I think that's not possible.

[XM-2]>>> Thank you for your understanding. If you're interested to write a 
YANG module for this feature, I would like to help. :-)




Best Regards,

Xiao Min





Regards,

Reshad.





Regards,

Reshad.




On Friday, October 21, 2022, 05:37:22 AM EDT, Bocci, Matthew (Nokia - GB) 
 wrote:





NVO3 and BFD working groups,


 


To give more time to review and comment on this draft in the light of the draft 
submission deadline of 24th October, I am extending this WG last call to Friday 
4th November 2022.


 


Please review and post any comments to the NVO3 list (including whether you 
support publication as an RFC).


 


Thanks


 


Matthew___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

[xiao.min2]

Hi Reshad,






Thank you for the thorough review and thoughtful comments.


Please see inline...





Best Regards,


Xiao Min



Original



From: ReshadRahman 
To: NVO3 ;rtg-...@ietf.org ;Bocci, Matthew 
(Nokia - GB) ;
Date: 2022年11月07日 00:06
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks




Hi,

- The abstract mentions point-to-point Geneve tunnels. Might be good to add 
"unicast"?

[XM]>>> OK. Will add it in the next revision.


- I don't see it being spelled out that this is single-hop BFD, except the 
reference to RFC 5881 and setting TTL to 255. Might be good to be explicit. 
FWIW RFC 8971 isn't very explicit either...

[XM]>>> OK. Will make it explicit in the next revision.



- RFC 8926 mentions that a Geneve tunnel is unidirectional. Can demand mode be 
used?

[XM]>>> Yes, I think so. Considering both RFC 8971 and RFC 5881 don't mention 
Demand mode, do you see a need to mention it in this document?


- Section 4.1 "and use the same way to encapsulate data packets.". So a VAP is 
either IP or ethernet and both VAPs have to use same encaps. What if 1 is v4 
and the other is v6? May need more details on this, either in section 1 or 
section 3.

[XM]>>> Section 4.1 also says "a BFD session can only be established between 
two VAPs that are mapped to the same VNI". I don't believe the case you 
described exists in one VNI, what do you think?


- Section 5: "Virtual Network Identifier (VNI) field SHOULD be set to the VNI 
number that the originating VAP is mapped to.". OOC, why is this a SHOULD and 
not a MUST? Specifically, why would it not be set to the VNI of the originating 
VAP? Section 4.1 mentions same VNI being used between the 2 VAPs.

[XM]>>> The reason is that the originating VAP could also choose to use 
Management VNI. 


- If there is a YANG model for VAPs (not covered in draft-ietf-nvo3-yang-cfg 
which has expired), I would like to see YANG for BFD over Geneve. Not sure 
whether new config is needed, but there will be new operational state (in 
Geneve and in BFD). Whether it's in the same doc or in a separate parallel doc 
is above my pay grade.

[XM]>>> I see. As an author of draft-ietf-nvo3-bfd-geneve, I think the 
potential YANG should be outside the scope.





Regards,

Reshad.




On Friday, October 21, 2022, 05:37:22 AM EDT, Bocci, Matthew (Nokia - GB) 
 wrote:





NVO3 and BFD working groups,


 


To give more time to review and comment on this draft in the light of the draft 
submission deadline of 24th October, I am extending this WG last call to Friday 
4th November 2022.


 


Please review and post any comments to the NVO3 list (including whether you 
support publication as an RFC).


 


Thanks


 


Matthew___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

[xiao.min2]

Jeff,





Thank you for the quick reply.


Please see inline...



Original



From: JeffreyHaas 
To: 肖敏10093570;
Cc: matthew.bo...@nokia.com ;nvo3@ietf.org 
;rtg-...@ietf.org ;
Date: 2022年11月06日 17:05
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks


Xiao Min,
 
On Sat, Nov 05, 2022 at 01:00:27PM +0800, xiao.m...@zte.com.cn wrote:
> To restate my question, on a given device receiving, for a given VNI, will 
> there ever be multiple sets of the same IP addresses?
>  
> If yes, the addition of the MAC addresses for initial multiplexing makes 
> sense.  Otherwise, perhaps they are unneeded?
> [XM-2]>>> The answer to your first question is Yes. In section 4.1 of this 
> document it says In BFD over Geneve, a BFD session is originated and 
> terminated at
>  VAP, usually one NVE owns multiple VAPs, so multiple BFD sessions may
>  be running between two NVEs, there needs to be a mechanism for
>  demultiplexing received BFD packets to the proper session.
>  Furthermore, due to the fact that [RFC8014] allows for N-to-1 mapping
>  between VAP and VNI at one NVE, multiple BFD sessions between two
>  NVEs for the same VNI are allowed.
 
The BFD for VXLAN procedures would similarly need to apply this type of
demultiplexing.  However, that document didn't list those details.
Perhaps listing them in the geneve document is clearer.

[XM-3]>>> The content of section 4 could similarly apply to BFD for VXLAN. Do 
you see a need for some new text?


That said, if this is the case, shouldn't there also be discussion about the
Inner VLAN tag portion of the Inner Ethernet Header?

[XM-3]>>> I think the answer is no. As I explained, Geneve BFD sessions are 
VAP-based. In one case, the VAP has no idea of the Inner VLAN; In another case, 
the VAP owns a VLAN-to-VNI mapping table, while VNI has been included in the 
demultiplexing fields, there is no need for VLAN.


> What I'm far more puzzled by is the source port demultiplexing step.  
> Thisisn't normal for RFC 5881.  Why is there a desire to add this to initial 
> demultiplexing?
> [XM]>>> In section 4 of RFC 5881 it says  
>  
[...]
 
> If you don't need to explicitly control more than one session between the 
> same VNI, for the same IP address pairs, on the same device, you can simply 
> demultiplex based on the UDP destination port for BFD single hop as per RFC 
> 5881 procedures.
>  
> If you have need for such explicit control, such additional procedure is fine.
>  
>  
> [XM-2]>>> Yes, I believe there is such a need. Furthermore, the provision for 
> source UDP port is optional even if it's included in the demultiplexing 
> fields, because the source UDP port is not the only field for demultiplexing. 
> In other words, if an implementation selects not to configure the source UDP 
> port, but just use the default one, this implementation can still comply with 
> this specification.
 
There normally isn't a default source port - its value is simply expected to
be in the ephemeral port range.

[XM-3]>>> Thank you for the education.


By listing it in the configuration and demultiplexing procedures, it becomes
additional configuration that must be consistent between each side of a BFD
session.

[XM-3]>>> Again, I still think the configuration of the source UDP port is 
optional.




Best Regards,

Xiao Min


---
 
If the NVO3 Working Group is comfortable with all of the requirements for
session configuration, the procedures are fine for BFD.  I believe this
brings me to my final comment, which may be raised by the Area Directors as
well as part of their review: There is no YANG module for this feature.
 
I don't believe the IESG is requiring YANG modules at this time.  BFD for
VXLAN itself doesn't have a YANG module.  However, the creation of such a
module would highlight what the configuration parameters are for this
document.
 
Perhaps the NVO3 group should consider such a YANG module for the future.
 
-- Jeff___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

[xiao.min2]

Jeff,






Thank you for the quick reply.


Please see inline...




Original



From: JeffreyHaas 
To: 肖敏10093570;
Cc: Bocci, Matthew (Nokia - GB) ;nvo3@ietf.org 
;rtg-...@ietf.org ;
Date: 2022年11月04日 19:20
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks




Xiao Min,


On Nov 3, 2022, at 10:52 PM,   
wrote:








: If the BFD packet is received with Your Discriminator equals to 0, the BFD: 
session MUST be identified using the VNI number, and the inner: Ethernet/IP/UDP 
Header, i.e., the source MAC, the source IP, the destination: MAC, the 
destination IP, and the source UDP port number present in the inner: 
Ethernet/IP/UDP header.Not being familiar with Geneve configuration at all, 
I'll presume that withthere is a motivation for using the MAC addresses within 
a given VNI contextin addition to the IP addresses.  If this is clear from 
typical Geneveprocedures, it might be worth a nod to the appropriate section.  
I'll notethat this point of procedure doesn't seem to have a parallel in BFD 
for vxlan.
[XM]>>> Would you please elaborate a bit on the possible nod? As I understand 
it, the reason why there is no a parallel in RFC 8971 is that only one BFD 
session using the management VNI is needed between a pair of VTEPs, so there is 
no demultiplexing procedure needed in RFC 8971.










To restate my question, on a given device receiving, for a given VNI, will 
there ever be multiple sets of the same IP addresses?

If yes, the addition of the MAC addresses for initial multiplexing makes sense. 
 Otherwise, perhaps they are unneeded?
[XM-2]>>> The answer to your first question is Yes. In section 4.1 of this 
document it says In BFD over Geneve, a BFD session is originated and terminated 
at
 VAP, usually one NVE owns multiple VAPs, so multiple BFD sessions may
 be running between two NVEs, there needs to be a mechanism for
 demultiplexing received BFD packets to the proper session.
 Furthermore, due to the fact that [RFC8014] allows for N-to-1 mapping
 between VAP and VNI at one NVE, multiple BFD sessions between two
 NVEs for the same VNI are allowed.






What I'm far more puzzled by is the source port demultiplexing step.  Thisisn't 
normal for RFC 5881.  Why is there a desire to add this to initial 
demultiplexing?
[XM]>>> In section 4 of RFC 5881 it says 

An implementation MAY use
 the UDP port source number to aid in demultiplexing incoming BFD
 Control packets, but ultimately the mechanisms in [BFD] MUST be used
 to demultiplex incoming packets to the proper session.
It seems adding the UDP source port is helpful, what do you think?








It actually can make configuration more difficult.  You must then have 
provisioning for the UDP ports for your sessions on each side of things.  

If you don't need to explicitly control more than one session between the same 
VNI, for the same IP address pairs, on the same device, you can simply 
demultiplex based on the UDP destination port for BFD single hop as per RFC 
5881 procedures.

If you have need for such explicit control, such additional procedure is fine.


[XM-2]>>> Yes, I believe there is such a need. Furthermore, the provision for 
source UDP port is optional even if it's included in the demultiplexing fields, 
because the source UDP port is not the only field for demultiplexing. In other 
words, if an implementation selects not to configure the source UDP port, but 
just use the default one, this implementation can still comply with this 
specification.






Best Regards,


Xiao Min






-- Jeff___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

[xiao.min2]

Jeff,






Thank you for the thorough review and thoughtful comments.


Please see inline...






Best Regards,


Xiao Min



Original



From: JeffreyHaas 
To: Bocci, Matthew (Nokia - GB) ;
Cc: NVO3 ;rtg-...@ietf.org ;
Date: 2022年11月04日 08:11
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks


Matthew,
 
On Fri, Oct 21, 2022 at 09:37:13AM +, Bocci, Matthew (Nokia - GB) wrote:
> NVO3 and BFD working groups,
>  
> To give more time to review and comment on this draft in the light of the 
> draft submission deadline of 24th October, I am extending this WG last call 
> to Friday 4th November 2022.
>  
> Please review and post any comments to the NVO3 list (including whether you 
> support publication as an RFC).
 
Thanks for your patience.  I have reviewed the BFD for geneve draft.  My
comments are below.
 
Section 4:
: Destination IP: IP address of a VAP of the terminating NVE. If the VAP of
: the terminating NVE has no IP address, then the IP address 127.0.0.1 for
: IPv4 or ::1/128 for IPv6 MUST be used.
 
The procedure here is clear.  I suspect that those who have been exposed to
other prior tunnel endpoint destination IP address discussions may note that
more of the "loopback range" has been used.  In particular, the comparable
BFD for vxlan - RFC 8971, Section 3.
 
While I'm not suggesting that the draft change its behavior, the Working
Group may wish to be aware that this may come up as a point of discussion.
 
That said, the IESG has collective amnesia about this point when it shows up
in other proposals so I think you're fine. :-)

[XM]>>> Good observation. You're right that "loopback range" is used in RFC 
8971 while a dedicated loopback address is used in this document. That's an 
intended change. In -00 wg draft, the "loopback range" as RFC 8971 was used, 
and after discussion among the authors, it's realized that a dedicated loopback 
address would facilitate the implementation, so this change. Hope the IESG 
would not object it. :-)




: In BFD over Geneve, a BFD session is originated and terminated at VAP,
: usually one NVE owns multiple VAPs, so multiple BFD sessions may be running
: between two NVEs, there needs to be a mechanism for demultiplexing received
: BFD packets to the proper session
 
The above is a bit of a run-on sentence.  Suggest minor punctuation changes:
 
"In BFD over Geneve, a BFD session is originated and terminated at VAP,
usually one NVE owns multiple VAPs. Since multiple BFD sessions may be running
between two NVEs, there needs to be a mechanism for demultiplexing received
BFD packets to the proper session."

[XM]>>> The changes you suggested look good to me. Will use your text in the 
next revision.


: If the BFD packet is received with Your Discriminator equals to 0, the BFD
: session MUST be identified using the VNI number, and the inner
: Ethernet/IP/UDP Header, i.e., the source MAC, the source IP, the destination
: MAC, the destination IP, and the source UDP port number present in the inner
: Ethernet/IP/UDP header.
 
Not being familiar with Geneve configuration at all, I'll presume that with
there is a motivation for using the MAC addresses within a given VNI context
in addition to the IP addresses.  If this is clear from typical Geneve
procedures, it might be worth a nod to the appropriate section.  I'll note
that this point of procedure doesn't seem to have a parallel in BFD for
vxlan.

[XM]>>> Would you please elaborate a bit on the possible nod? As I understand 
it, the reason why there is no a parallel in RFC 8971 is that only one BFD 
session using the management VNI is needed between a pair of VTEPs, so there is 
no demultiplexing procedure needed in RFC 8971.


What I'm far more puzzled by is the source port demultiplexing step.  This
isn't normal for RFC 5881.  Why is there a desire to add this to initial
demultiplexing?

[XM]>>> In section 4 of RFC 5881 it says 

An implementation MAY use
 the UDP port source number to aid in demultiplexing incoming BFD
 Control packets, but ultimately the mechanisms in [BFD] MUST be used
 to demultiplex incoming packets to the proper session. It seems adding the UDP 
source port is helpful, what do you think?




The same comment on UDP port number holds for section 5.1 for IP
encapsulation.

[XM]>>> OK. I'll take care of section 5.1 too.


-- Jeff___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

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

[xiao.min2]

Hi Anoop,






Thank you for the kind reminder.


Yes, I've noticed there are two places (one in section 4, another in section 5) 
that need to be changed.


Your new text looks better.






Thanks,


Xiao Min



Original



From: AnoopGhanwani 
To: 肖敏10093570;
Cc: nvo3@ietf.org ;
Date: 2022年10月18日 23:24
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for 
draft-ietf-nvo3-bfd-geneve




Hi Xiao Min,

Just to be clear, there are 2 instances of this that need to be changed.  And 
if you're using the text verbatim then please use this modified version:

"Opt Len field MUST be set consistent with the Geneve specification [RFC 8926] 
depending on whether or not options are present in the frame.  The use of 
Geneve options with BFD is beyond the scope of this specification."


Thanks,
Anoop




On Mon, Oct 17, 2022 at 5:55 PM  wrote:


Hi Anoop,






Thanks for your support.


Please see inline...






Best Regards,


Xiao Min



Original


From: AnoopGhanwani 
To: nvo3@ietf.org ;
Date: 2022年10月18日 02:36
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for 
draft-ietf-nvo3-bfd-geneve

___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


I read the draft and support publication as an RFC.

One clarification which I think would be helpful.

What is the motivation for the following:
>>>
Opt Len field SHOULD be set to 0, which indicates there isn't any variable 
length option.
>>>

Obviously if there are no options then it is set to 0.  But if there are 
options present then it needs to be set according to that.  For example, if I 
am running INT over Geneve and I want to have INT headers with the BFD frame, 
then this would need to be non-zero.  Would it be more accurate to say:

"Opt Len field MUST be set consistent with the Geneve spec depending on whether 
or not options are present in the frame.  The use of Geneve options with BFD is 
beyond the scope of this specification."

[XM]>>> This clarification looks fine to me. Will incorporate it into the next 
revision.


Thanks,
Anoop



On Wed, Oct 12, 2022 at 6:56 PM  wrote:


 --Original--
 From: Bocci,Matthew(Nokia-GB) 
 To: NVO3 ;
 Cc: nvo3-cha...@ietf.org 
;draft-ietf-nvo3-bfd-gen...@ietf.org 
;
 Date: 2022年10月06日 18:30
 Subject: [nvo3] Working Group Last Call and IPR Poll for 
draft-ietf-nvo3-bfd-geneve
 ___
 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-bfd-geneve-07 (draft-ietf-nvo3-bfd-geneve-07 - BFD for 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 14th October 2022.
 Regards
 Matthew and Sam
 
 ___
 nvo3 mailing list
 nvo3@ietf.org
 https://www.ietf.org/mailman/listinfo/nvo3___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

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

[xiao.min2]

Hi Anoop,






Thanks for your support.


Please see inline...






Best Regards,


Xiao Min









Original



From: AnoopGhanwani 
To: nvo3@ietf.org ;
Date: 2022年10月18日 02:36
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for 
draft-ietf-nvo3-bfd-geneve




___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


I read the draft and support publication as an RFC.


One clarification which I think would be helpful.


What is the motivation for the following:
>>>
Opt Len field SHOULD be set to 0, which indicates there isn't any variable 
length option.
>>>


Obviously if there are no options then it is set to 0.  But if there are 
options present then it needs to be set according to that.  For example, if I 
am running INT over Geneve and I want to have INT headers with the BFD frame, 
then this would need to be non-zero.  Would it be more accurate to say:


"Opt Len field MUST be set consistent with the Geneve spec depending on whether 
or not options are present in the frame.  The use of Geneve options with BFD is 
beyond the scope of this specification."

[XM]>>> This clarification looks fine to me. Will incorporate it into the next 
revision.



Thanks,
Anoop



On Wed, Oct 12, 2022 at 6:56 PM  wrote:


 --Original--
 From: Bocci,Matthew(Nokia-GB) 
 To: NVO3 ;
 Cc: nvo3-cha...@ietf.org 
;draft-ietf-nvo3-bfd-gen...@ietf.org 
;
 Date: 2022年10月06日 18:30
 Subject: [nvo3] Working Group Last Call and IPR Poll for 
draft-ietf-nvo3-bfd-geneve
 ___
 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-bfd-geneve-07 (draft-ietf-nvo3-bfd-geneve-07 - BFD for 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 14th October 2022.
 Regards
 Matthew and Sam
 
 ___
 nvo3 mailing list
 nvo3@ietf.org
 https://www.ietf.org/mailman/listinfo/nvo3___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

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

[xiao.min2]

As a co-author, I'm not aware of any IPR that applies to this document.


I support the publication of this document as a Standards Track RFC (not 
informational RFC, I suspect it's a typo in the original mail :-)).






Thanks,


Xiao Min










Original



From: Bocci,Matthew(Nokia-GB) 
To: NVO3 ;
Cc: nvo3-cha...@ietf.org 
;draft-ietf-nvo3-bfd-gen...@ietf.org 
;
Date: 2022年10月06日 18:30
Subject: [nvo3] Working Group Last Call and IPR Poll for 
draft-ietf-nvo3-bfd-geneve




___
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-bfd-geneve-07 (draft-ietf-nvo3-bfd-geneve-07 - BFD for 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 14th October 2022.


 


Regards


 


Matthew and Sam___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Rtgdir early review of draft-ietf-nvo3-bfd-geneve-06

[xiao.min2]

For some unknown reason, the attached files can't get to the archive.
I've posted the updated draft for your review.
https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-bfd-geneve-07

Sorry for the inconvenience.

- Xiao Min
--Original--
From: 肖敏10093570
To: s...@stewartbryant.com ;
Cc: rtg-...@ietf.org ;draft-ietf-nvo3-bfd-geneve@ietf.org 
;nvo3@ietf.org ;
Date: 2022年08月11日 15:38
Subject: Re: [nvo3]  Rtgdir early review of draft-ietf-nvo3-bfd-geneve-06
Dear Stewart,

Thanks for your insightful review and comments, especially the proposed text, 
very helpful.
Attached please find the updated draft (working -07 version) addressing your 
comments, and the Diff.
For my responses to your comments, please see inline...

Best Regards,
Xiao Min
--Original--
From: StewartBryantviaDatatracker 
To: rtg-...@ietf.org ;
Cc: draft-ietf-nvo3-bfd-geneve@ietf.org 
;nvo3@ietf.org ;
Date: 2022年08月05日 19:08
Subject: [nvo3] Rtgdir early review of draft-ietf-nvo3-bfd-geneve-06
Reviewer: Stewart Bryant
Review result: Has Issues

I do not see any boilerplate automatically provided in the review tool, so
assume that the standard RTG-dir boilerplate is here.

The protocol described here is simple and will work. It is well written.
[XM]>>> Thank you.

However I do have some concerns about the structure of the document. I think
that the document would be better as either two large sections one describing
the Ethernet payload model and the other describing IP operation, or as an
integrated document (as it is) but with one section describing operation in one
mode and the other describing the differences. The way it is written the reader
has to spend a lot of time looking at the text in adjacent sections/paragraphs
to work out what changed.
[XM]>>> I think your concerns are valid, so I restructured this document, 
attempted to make it more friendly to the reader.

Detailed comments:

132 3. BFD Packet Transmission over Geneve Tunnel

134 Concerning whether the Geneve data packets include an Ethernet frame
135 or an IP packet,
SB> I think that this would be clearer as:
Since the Geneve data packet payload may be either an Ethernet frame or an IP
packet,
[XM]>>> Accepted.

this document defines two formats of BFD packet
136 encapsulation in Geneve. BFD session is originated and terminated at
137 VAP of an NVE, selection of the BFD packet encapsulation is based on
138 how the VAP encapsulates the data packets.

SB> I reads better as “The BFD” and “the VAP”
[XM]>>> Accepted.

SB> I think that it would help the reader if the authors now summarise what is
about to be described. SB> I think you are saying: If the payload is IP, then
we carry BFD over IP in the payload. If the payload is ethernet then the
Ethernet payload becomes IP regardless of what it might normally carry and we
carry BFD over IP in the same manner as we would carry it in the IP payload
case.
[XM]>>> Accepted.

SB> If that was stated (assuming I have it correct) then many readers would
immediately know what follows.



193 The BFD packet MUST be carried inside the inner Ethernet frame of the
194 Geneve packet. The inner Ethernet frame carrying the BFD Control
195 packet has the following format:

197 Ethernet Header:
SB> For clarity that would be better as the "Inner Ethernet Header"
[XM]>>> Accepted.

=

282 Figure 2: Geneve Encapsulation of BFD Control Packet With the
283 Inner IP/UDP Header

SB> I think that this would be a bit clearer if you had a single section
describing the BFD over UDP/IP and then a small section saying how you carry
this directly over Geneve and a sections saying how you carry that UDP/IP over
Ethernet inside Geneve.
[XM]>>> As said above, I restructured this document.

===

319 4. Reception of BFD packet from Geneve Tunnel

321 Once a packet is received, the NVE MUST validate the packet as
322 described in [RFC8926].

324 If the Protocol Type field equals 0x6558 (Ethernet frame), and the
325 Destination MAC of the inner Ethernet frame matches the MAC
326 address of a VAP which is mapped to the same as received VNI, then
327 the Destination IP, the UDP destination port and the TTL or Hop
328 Limit of the inner IP packet MUST be validated to determine
329 whether the received packet can be processed by BFD.

331 If the Protocol Type field equals 0x0800 (IPv4) or 0x86DD (IPv6),
332 and the Destination IP of the inner IP packet matches the IP
333 address of a VAP which is mapped to the same as received VNI, then
334 the UDP destination port and the TTL or Hop Limit of the inner IP
335 packet MUST be validated to determine whether the received packet
336 can be processed by BFD.

SB> This is technically correct, but again it might be simpler for the reader
to have common text and a difference text.
[XM]>>> As said above, I restructured this document.



369 5. Security Considerations

371 Security issues discussed in [RFC5880], [RFC5881], and 

Re: [nvo3] Rtgdir early review of draft-ietf-nvo3-bfd-geneve-06

[xiao.min2]

Dear Stewart,

Thanks for your insightful review and comments, especially the proposed text, 
very helpful.
Attached please find the updated draft (working -07 version) addressing your 
comments, and the Diff.
For my responses to your comments, please see inline...

Best Regards,
Xiao Min
--Original--
From: StewartBryantviaDatatracker 
To: rtg-...@ietf.org ;
Cc: draft-ietf-nvo3-bfd-geneve@ietf.org 
;nvo3@ietf.org ;
Date: 2022年08月05日 19:08
Subject: [nvo3] Rtgdir early review of draft-ietf-nvo3-bfd-geneve-06
Reviewer: Stewart Bryant
Review result: Has Issues

I do not see any boilerplate automatically provided in the review tool, so
assume that the standard RTG-dir boilerplate is here.

The protocol described here is simple and will work. It is well written.
[XM]>>> Thank you.

However I do have some concerns about the structure of the document. I think
that the document would be better as either two large sections one describing
the Ethernet payload model and the other describing IP operation, or as an
integrated document (as it is) but with one section describing operation in one
mode and the other describing the differences. The way it is written the reader
has to spend a lot of time looking at the text in adjacent sections/paragraphs
to work out what changed.
[XM]>>> I think your concerns are valid, so I restructured this document, 
attempted to make it more friendly to the reader.

Detailed comments:

132 3. BFD Packet Transmission over Geneve Tunnel

134 Concerning whether the Geneve data packets include an Ethernet frame
135 or an IP packet,
SB> I think that this would be clearer as:
Since the Geneve data packet payload may be either an Ethernet frame or an IP
packet,
[XM]>>> Accepted.

this document defines two formats of BFD packet
136 encapsulation in Geneve. BFD session is originated and terminated at
137 VAP of an NVE, selection of the BFD packet encapsulation is based on
138 how the VAP encapsulates the data packets.

SB> I reads better as “The BFD” and “the VAP”
[XM]>>> Accepted.

SB> I think that it would help the reader if the authors now summarise what is
about to be described. SB> I think you are saying: If the payload is IP, then
we carry BFD over IP in the payload. If the payload is ethernet then the
Ethernet payload becomes IP regardless of what it might normally carry and we
carry BFD over IP in the same manner as we would carry it in the IP payload
case.
[XM]>>> Accepted.

SB> If that was stated (assuming I have it correct) then many readers would
immediately know what follows.



193 The BFD packet MUST be carried inside the inner Ethernet frame of the
194 Geneve packet. The inner Ethernet frame carrying the BFD Control
195 packet has the following format:

197 Ethernet Header:
SB> For clarity that would be better as the "Inner Ethernet Header"
[XM]>>> Accepted.

=

282 Figure 2: Geneve Encapsulation of BFD Control Packet With the
283 Inner IP/UDP Header

SB> I think that this would be a bit clearer if you had a single section
describing the BFD over UDP/IP and then a small section saying how you carry
this directly over Geneve and a sections saying how you carry that UDP/IP over
Ethernet inside Geneve.
[XM]>>> As said above, I restructured this document.

===

319 4. Reception of BFD packet from Geneve Tunnel

321 Once a packet is received, the NVE MUST validate the packet as
322 described in [RFC8926].

324 If the Protocol Type field equals 0x6558 (Ethernet frame), and the
325 Destination MAC of the inner Ethernet frame matches the MAC
326 address of a VAP which is mapped to the same as received VNI, then
327 the Destination IP, the UDP destination port and the TTL or Hop
328 Limit of the inner IP packet MUST be validated to determine
329 whether the received packet can be processed by BFD.

331 If the Protocol Type field equals 0x0800 (IPv4) or 0x86DD (IPv6),
332 and the Destination IP of the inner IP packet matches the IP
333 address of a VAP which is mapped to the same as received VNI, then
334 the UDP destination port and the TTL or Hop Limit of the inner IP
335 packet MUST be validated to determine whether the received packet
336 can be processed by BFD.

SB> This is technically correct, but again it might be simpler for the reader
to have common text and a difference text.
[XM]>>> As said above, I restructured this document.



369 5. Security Considerations

371 Security issues discussed in [RFC5880], [RFC5881], and [RFC8926]
372 apply to this document.

SB> Does the GTSM security mechanism called up in RFC5881 do anything for you?
SB> The key security mechanism is that BFD has to arrive inside a Geneve packet.
SB> I think the security actually comes from RFC8926 i.e. Geneve itself. The
BFD is then a payload that is carried securely between peers just like any
other payload. If the peers cannot trust each other all bets are off. The
security discussion is RFC5880 and RFC5881 are for when BFD is openly 

Re: [nvo3] Rtgdir early review of draft-ietf-nvo3-bfd-geneve-06

[xiao.min2]

Dear Stewart,

Thanks for your insightful review and comments, especially the proposed text, 
very helpful.
Attached please find the updated draft (working -07 version) addressing your 
comments, and the Diff.
For my responses to your comments, please see inline...

Best Regards,
Xiao Min
--Original--
From: StewartBryantviaDatatracker 
To: rtg-...@ietf.org ;
Cc: draft-ietf-nvo3-bfd-geneve@ietf.org 
;nvo3@ietf.org ;
Date: 2022年08月05日 19:08
Subject: [nvo3] Rtgdir early review of draft-ietf-nvo3-bfd-geneve-06
Reviewer: Stewart Bryant
Review result: Has Issues

I do not see any boilerplate automatically provided in the review tool, so
assume that the standard RTG-dir boilerplate is here.

The protocol described here is simple and will work. It is well written.
[XM]>>> Thank you.

However I do have some concerns about the structure of the document. I think
that the document would be better as either two large sections one describing
the Ethernet payload model and the other describing IP operation, or as an
integrated document (as it is) but with one section describing operation in one
mode and the other describing the differences. The way it is written the reader
has to spend a lot of time looking at the text in adjacent sections/paragraphs
to work out what changed.
[XM]>>> I think your concerns are valid, so I restructured this document, 
attempted to make it more friendly to the reader.

Detailed comments:

132 3.  BFD Packet Transmission over Geneve Tunnel

134Concerning whether the Geneve data packets include an Ethernet frame
135or an IP packet,
SB> I think that this would be clearer as:
Since the Geneve data packet payload may be either an Ethernet frame or an IP
packet,
[XM]>>> Accepted.

this document defines two formats of BFD packet
136encapsulation in Geneve.  BFD session is originated and terminated at
137VAP of an NVE, selection of the BFD packet encapsulation is based on
138how the VAP encapsulates the data packets.

SB> I reads better as “The BFD” and “the VAP”
[XM]>>> Accepted.

SB> I think that it would help the reader if the authors now summarise what is
about to be described. SB> I think you are saying: If the payload is IP, then
we carry BFD over IP in the payload. If the payload is ethernet then the
Ethernet payload becomes IP regardless of what it might normally carry and we
carry BFD over IP in the same manner as we would carry it in the IP payload
case.
[XM]>>> Accepted.

SB> If that was stated (assuming I have it correct) then many readers would
immediately know what follows.



193The BFD packet MUST be carried inside the inner Ethernet frame of the
194Geneve packet.  The inner Ethernet frame carrying the BFD Control
195packet has the following format:

197   Ethernet Header:
SB> For clarity that would be better as the "Inner Ethernet Header"
[XM]>>> Accepted.

=

282Figure 2: Geneve Encapsulation of BFD Control Packet With the
283 Inner IP/UDP Header

SB>  I think that this would be a bit clearer if you had a single section
describing the BFD over UDP/IP and then a small section saying how you carry
this directly over Geneve and a sections saying how you carry that UDP/IP over
Ethernet inside Geneve.
[XM]>>> As said above, I restructured this document.

===

319 4.  Reception of BFD packet from Geneve Tunnel

321Once a packet is received, the NVE MUST validate the packet as
322described in [RFC8926].

324   If the Protocol Type field equals 0x6558 (Ethernet frame), and the
325   Destination MAC of the inner Ethernet frame matches the MAC
326   address of a VAP which is mapped to the same as received VNI, then
327   the Destination IP, the UDP destination port and the TTL or Hop
328   Limit of the inner IP packet MUST be validated to determine
329   whether the received packet can be processed by BFD.

331   If the Protocol Type field equals 0x0800 (IPv4) or 0x86DD (IPv6),
332   and the Destination IP of the inner IP packet matches the IP
333   address of a VAP which is mapped to the same as received VNI, then
334   the UDP destination port and the TTL or Hop Limit of the inner IP
335   packet MUST be validated to determine whether the received packet
336   can be processed by BFD.

SB> This is technically correct, but again it might be simpler for the reader
to have common text and a difference text.
[XM]>>> As said above, I restructured this document.



369 5.  Security Considerations

371Security issues discussed in [RFC5880], [RFC5881], and [RFC8926]
372apply to this document.

SB> Does the GTSM security mechanism called up in RFC5881 do anything for you?
SB> The key security mechanism is that BFD has to arrive inside a Geneve packet.
SB> I think the security 

Re: [nvo3] Poll on progressing draft-ietf-nvo3-encap with missing IPR declaration

[xiao.min2]

Hi Matthew,

I support option (1).

Cheers,
Xiao Min
--Original--
From: Bocci,Matthew(Nokia-GB) 
To: NVO3 ;draft-ietf-nvo3-en...@ietf.org 
;
Cc: Andrew Alston - IETF ;
Date: 2022年07月08日 20:52
Subject: [nvo3] Poll on progressing draft-ietf-nvo3-encap with missing IPR 
declaration
___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

NVo3 WG,
The chairs believe there is consensus to publish draft-ietf-nvo3-encap as an 
informational RFC. However, we are missing an IPR declaration from one of the 
co-authors listed in the Contributors  section.
Despite repeated attempts to contact them over several weeks through multiple 
channels, we have not received an IPR declaration. It is incumbent upon us to 
ask every author and contributor  to declare whether they are aware of any IPR 
that may be applicable to the draft. However, since we have not been unable to 
contact this one co-author, we would like the working group’s input on how to 
proceed by responding to this poll.
These are the potential options:
Remove the individual’s name from the list of contributors, moving it to the 
acknowledgements section, and then request publication of the draft.
Proceed with publication of the draft regardless, with no changes to the 
contributors list.
Do not publish the draft until we receive a response form the individual (which 
may be never).
Please respond to this poll by Friday 22nd July stating whether you support 
option (1), option (2) or option (3).
Best regards,
Matthew and Sam.

___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] WG Last Call for draft-ietf-nvo3-encap-08

[xiao.min2]

I support the publication of this document.

Best Regards,
Xiao Min
--原始邮件--
发件人：Bocci,Matthew(Nokia-GB)
收件人：NVO3;
抄送人：nvo3-cha...@ietf.org;ilango.s.ga...@intel.com;prank...@microsoft.com;Rajeev 
Manur;ta...@marvell.com;mosess...@gmail.com;nordm...@sonic.net;Michael Smith 
(michsmit);Sam Aldrin;Ignas Bagdonas;draft-ietf-nvo3-en...@ietf.org;
日 期 ：2022年05月23日 17:58
主 题 ：[nvo3] WG Last Call for draft-ietf-nvo3-encap-08
___
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-encap-08 (draft-ietf-nvo3-encap-08 - Network  Virtualization 
Overlays (NVO3) Encapsulation Considerations).
We are running a new WG last call as there were a few updates made during the 
RTG DIR review discussions. We are also missing a few IPR declarations from 
contributors, which need to be  made against the WG LC version of the document. 
I have copied the contributors directly.
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.
As a reminder, we are pursuing publication of this document to permanently 
document the experience of one working group in choosing between multiple 
proposed standards track encapsulation  drafts. The idea was that this would 
provide helpful guidance to others in the community going forward.
This poll will run until Monday 6th June 2022.
Regards
Matthew and Sam

___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

[nvo3] Fw:New Version Notification for draft-ietf-nvo3-bfd-geneve-06.txt

[xiao.min2]

Nvo3 Chairs,

The authors believe draft-ietf-nvo3-bfd-geneve is ready for WGLC, appreciate 
your consideration of it.

Best Regards,
Xiao Min
--原始邮件--
发件人：internet-dra...@ietf.org
收件人：Greg Mirsky;Jeff Tantsura;Sam Aldrin;Santosh Pallagatti;肖敏10093570;
日 期 ：2022年05月16日 08:32
主 题 ：New Version Notification for draft-ietf-nvo3-bfd-geneve-06.txt

A new version of I-D, draft-ietf-nvo3-bfd-geneve-06.txt
has been successfully submitted by Xiao Min and posted to the
IETF repository.
Name:draft-ietf-nvo3-bfd-geneve
Revision:06
Title:BFD for Geneve
Document date:2022-05-15
Group:nvo3
Pages:12
URL:
https://www.ietf.org/archive/id/draft-ietf-nvo3-bfd-geneve-06.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-nvo3-bfd-geneve/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-bfd-geneve
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-bfd-geneve-06
Abstract:
This document describes the use of the Bidirectional Forwarding
Detection (BFD) protocol in point-to-point Generic Network
Virtualization Encapsulation (Geneve) tunnels used to make up an
overlay network.
The IETF Secretariat

___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Second Working Group Last call for draft-ietf-nvo3-encap

[xiao.min2]

Hi Matthew and Sam,

I've read the latest version of this draft.
I think this document is valuable and ready for publication.

Best Regards,
Xiao Min

--原始邮件--
发件人：Bocci,Matthew(Nokia-GB)
收件人：NVO3;
抄送人：draft-ietf-nvo3-en...@ietf.org;
日 期 ：2021年07月01日 23:09
主 题 ：[nvo3] Second Working Group Last call for draft-ietf-nvo3-encap
___
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-encap-06.
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.
As a reminder, we are pursuing publication of this document in order to 
permanently document the experience of one working group in choosing between 
multiple proposed standards track  encapsulation drafts. The idea was that this 
would provide helpful guidance to others in the community going forward.
This poll will run until Thursday 15th July 2021.
Regards
Matthew and Sam___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] WG Last call and IPR Poll for draft-ietf-nvo3-yang-cfg-04

[xiao.min2]

I support the publication of this draft.






Best Regards,


Xiao Min









原始邮件



发件人：SamAldrin
收件人：NVO3;draft-ietf-nvo3-yang-...@ietf.org;
日 期 ：2021年03月29日 14:54
主 题 ：[nvo3] WG Last call and IPR Poll for draft-ietf-nvo3-yang-cfg-04




___
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-yang-cfg-04.


 


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 a standards track 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.


 


As a reminder, we are pursuing publication of this document in order to 
permanently document the experience of one working group in choosing between 
multiple proposed standards track encapsulation drafts. The idea was that this 
would provide helpful guidance to others in the community going forward.


 


This poll will run until 12th April 2021.


 


Regards


 


Sam and Matthew___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

[nvo3] Open issues for draft-ietf-nvo3-bfd-geneve

[xiao.min2]

Dear NVO3 WG,






This mail intends to share some open issues for draft-ietf-nvo3-bfd-geneve, and 
ask for your review and comments.



For BFD-over-Ethernet-over-Geneve encap in Figure 1, if the VAP of the 
terminating NVE has no IP address, for IPv6, whether the range 
:::127.0.0.0/104 or the address ::1/128, should be used? Within 
draft-ietf-bfd-vxlan-16 which is in RFC-Editor's Queue, the range 
:::127.0.0.0/104 is used, nevertheless we also heard opinion that the 
address ::1/128 is the only loopback address for IPv6.


For BFD-over-Ethernet-over-Geneve encap in Figure 1, if the VAP of the 
originating NVE has no IP address, whether the IP address of the originating 
NVE, or the address 0.0.0.0 for IPv4 and the address 0:0:0:0:0:0:0:0 for IPv6, 
should be used? In my view, considering the possible address overlap between 
the tenant space and the NVE space, the latter choice seems more secure.


BFD Demand Mode and BFD Echo function, whether there is a requirement to 
support one or both of them? Within draft-ietf-bfd-vxlan-16 which is in 
RFC-Editor's Queue, only BFD asynchronous mode is in the scope, both BFD demand 
mode and BFD echo function are outside the scope.


BFD Discriminator exchange mechanism, whether this draft needs to define a 
mechanism for BFD discriminator exchange? In my view, this mechanism is 
optional, and it can be achieved by EVPN, Geneve-Ping, Configuration, etc.






Best Regards,


Xiao Min___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] WG adoption and IPR poll for draft-xiao-nvo3-bfd-geneve-03

[xiao.min2]

I'll upload the -00 version WG document as the I-D submission tool is reopened.


Many thanks to NVO3 co-chairs and the folks who support the adoption.






Best Regards,



Xiao Min









原始邮件



发件人：Bocci,Matthew(Nokia-GB)
收件人：NVO3;
抄送人：draft-xiao-nvo3-bfd-gen...@ietf.org;
日 期 ：2020年11月09日 18:10
主 题 ：Re: [nvo3] WG adoption and IPR poll for draft-xiao-nvo3-bfd-geneve-03




___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3



This email concludes the WG adoption poll. There is consensus to adopt the 
draft as an NVO3 WG document.


 


Authors: Please upload a new version of the document, changing the name to 
draft-ietf-nvo3-bfd-geneve-00.


 


Regards


 


Matthew


 


 



From:Bocci, Matthew (Nokia - GB) 
Date: Thursday, 15 October 2020 at 16:42
To: NVO3 
Cc: draft-xiao-nvo3-bfd-gen...@ietf.org 
Subject: WG adoption and IPR poll for draft-xiao-nvo3-bfd-geneve-03



This email begins a two-week poll for adoption of 
draft-xiao-nvo3-bfd-geneve-03.txt in the NVO3 working group.


 


Please review the draft and send any comments to the NVO3 list.


 


Please also indicate whether you support adoption of the draft as an NVO3 
working group document.


 


Note that supporting working group adoption indicates that you think the draft 
is headed in the right direction and represents a piece of work that the 
working group should take on and progress. It does not have to be technically 
perfect
 at this stage.


 


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, copying the BESS mailing list. The document will not  progress
 without answers from all of 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 closes on Monday 2nd November 2020.


 


Regards


Matthew and Sam___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] WG adoption and IPR poll for draft-xiao-nvo3-bfd-geneve-03

[xiao.min2]

Hi Matthew and Sam,






I support the adoption of this draft as co-author.


I'm not aware of any relevant IPR.







Best Regards,


Xiao Min



原始邮件



发件人：Bocci,Matthew(Nokia-GB)
收件人：NVO3;
抄送人：draft-xiao-nvo3-bfd-gen...@ietf.org;
日 期 ：2020年10月15日 23:42
主 题 ：[nvo3] WG adoption and IPR poll for draft-xiao-nvo3-bfd-geneve-03


___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3



This email begins a two-week poll for adoption of 
draft-xiao-nvo3-bfd-geneve-03.txt in the NVO3 working group.


 


Please review the draft and send any comments to the NVO3 list.


 


Please also indicate whether you support adoption of the draft as an NVO3 
working group document.


 


Note that supporting working group adoption indicates that you think the draft 
is headed in the right direction and represents a piece of work that the 
working group should take on and progress. It does not have to be technically 
perfect
 at this stage.


 


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, copying the BESS mailing list. The document will not  progress
 without answers from all of 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 closes on Monday 2nd November 2020.


 


Regards


Matthew and Sam___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] WG adoption and IPR poll fordraft-mmbb-nvo3-geneve-oam-04.txt

[xiao.min2]

Hi Matthew and Sam,






I support the adoption of this draft.






Best Regards,


Xiao Min



原始邮件



发件人：Bocci,Matthew(Nokia-GB)
收件人：NVO3;
抄送人：draft-mmbb-nvo3-geneve-...@ietf.org;
日 期 ：2020年10月15日 23:40
主 题 ：[nvo3] WG adoption and IPR poll fordraft-mmbb-nvo3-geneve-oam-04.txt


___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3



This email begins a two-week poll for adoption of 
draft-mmbb-nvo3-geneve-oam-04.txt in the NVO3 working group.


 


Please review the draft and send any comments to the NVO3 list.


 


Please also indicate whether you support adoption of the draft as an NVO3 
working group document.


 


Note that supporting working group adoption indicates that you think the draft 
is headed in the right direction and represents a piece of work that the 
working group should take on and progress. It does not have to be technically 
perfect
 at this stage.


 


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, copying the BESS mailing list. The document will not  progress
 without answers from all of 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 closes on Monday 2nd November 2020.


 


Regards


Matthew and Sam___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] IETF 108 NVO3 minutes uploaded

[xiao.min2]

Hi Yizhou,






Thanks for the excellent minutes.


Alignment between the two presented Geneve OAM drafts is ongoing, hope we can 
draw a right conclusion based on the good discussion at IETF 108.






Best Regards,


Xiao Min



原始邮件



发件人：Liyizhou 
收件人：nvo3@ietf.org ;
抄送人：nvo3-cha...@ietf.org ;
日 期 ：2020年08月05日 14:01
主 题 ：[nvo3] IETF 108 NVO3 minutes uploaded


___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3



Hi all,


 


You may find the minutes at


 


https://www.ietf.org/proceedings/108/minutes/minutes-108-nvo3-00


 


 


Any corrections, please let me know.


 


Regards,


Yizhou___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

[nvo3] Fw:New Version Notification for draft-xiao-nvo3-bfd-geneve-02.txt

[xiao.min2]

NVO3 WG,






Based on the duscussion at IETF 106 and following email exchange, we updated 
this draft to -02 version.


There are two major changes compared to -01 version, as follows:


Remove BFD-over-MPLS-over-Geneve encapsulation. We received a comment that this 
kind of encapsulation is redundant, very likely wouldn't be really used, and we 
accepted that comment.


Resolve one open issue on the mapping between VAP and VNI. The updated text 
reflects the conclusion that RFC 8014 allows for N-to-1 mapping between VAP and 
VNI at one NVE.






Best Regards,


Xiao Min



原始邮件



发件人：internet-dra...@ietf.org 
收件人：肖敏10093570;肖敏10093570;Juniper Networks 
;Gregory Mirsky ;Greg 
Mirsky ;Santosh Pallagatti 
;
日 期 ：2020年02月18日 10:53
主 题 ：New Version Notification for draft-xiao-nvo3-bfd-geneve-02.txt



A new version of I-D, draft-xiao-nvo3-bfd-geneve-02.txt
has been successfully submitted by Xiao Min and posted to the
IETF repository.

Name:draft-xiao-nvo3-bfd-geneve
Revision:02
Title:BFD for Geneve
Document date:2020-02-17
Group:Individual Submission
Pages:11
URL:
https://www.ietf.org/internet-drafts/draft-xiao-nvo3-bfd-geneve-02.txt
Status: https://datatracker.ietf.org/doc/draft-xiao-nvo3-bfd-geneve/
Htmlized:   https://tools.ietf.org/html/draft-xiao-nvo3-bfd-geneve-02
Htmlized:   https://datatracker.ietf.org/doc/html/draft-xiao-nvo3-bfd-geneve
Diff:   https://www.ietf.org/rfcdiff?url2=draft-xiao-nvo3-bfd-geneve-02

Abstract:
   This document describes the use of the Bidirectional Forwarding
   Detection (BFD) protocol in point-to-point Generic Network
   Virtualization Encapsulation (Geneve) tunnels used to make up an
   overlay network.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Question on the mapping between VAP and VNI

[xiao.min2]

NVO3 WG,







Through offline discussion with David Black, the primary author of RFC 8014, we 
concluded that "RFC 8014 was written based on 1-to-1 mapping model, at the same 
time, RFC 8014 allows N-to-1 mapping."



Any other thoughts?






Best Regards,


Xiao Min



原始邮件



发件人：肖敏10093570
收件人：draft-ietf-nvo3-a...@ietf.org ;
抄送人：nvo3@ietf.org ;
日 期 ：2019年11月26日 14:15
主 题 ：Question on the mapping between VAP and VNI




Dear NVO3 Architecture Authors,






Many thanks to the well defined NVO3 architecture.



I have a question on the mapping between VAP and VNI at one NVE, is it a 1-to-1 
mapping or N-to-1 mapping?






In other words, is the following figure which is derived from Figure 2 of 
RFC8014 reasonable?

 | Underlay Network (IP) |
 | |
 +---+
 | |
 | Tunnel Overlay |
 ++-+ +-++
 | +--+---+ | | +---+--+ |
 | | Overlay Module | | | | Overlay Module | |
 | +-++ | | +-++ |
 | | | | | |
 NVE1 | | | | | | NVE2
 | ++---+ | | ++---+ |
 | |VNI1 VNI1 | | | | VNI1 VNI1 | |
 | +-+---+--+ | | +-+---+--+ |
 |VAP1| |VAP2 | |VAP3| |VAP4 |
 ++---+-+ ++---+-+
 | | | |
 ---+---+--+---+
 | | Tenant | |
 ( ' ) ( ' ) ( ' ) ( ' )
 (Ethernet) (IP Routing) (Ethernet) (IP Routing)
 ( _ ) ( _ ) ( _ ) ( _ )
 | | | |
 TSI1| |TSI2 TSI3| |TSI4
 +---+ +---+ +---+ +---+
 |TS1| |TS2| |TS3| |TS4|
 +---+ +---+ +---+ +---+___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

[nvo3] Question on the mapping between VAP and VNI

[xiao.min2]

Dear NVO3 Architecture Authors,






Many thanks to the well defined NVO3 architecture.



I have a question on the mapping between VAP and VNI at one NVE, is it a 1-to-1 
mapping or N-to-1 mapping?






In other words, is the following figure which is derived from Figure 2 of 
RFC8014 reasonable?

 | Underlay Network (IP) |
 | |
 +---+
 | |
 | Tunnel Overlay |
 ++-+ +-++
 | +--+---+ | | +---+--+ |
 | | Overlay Module | | | | Overlay Module | |
 | +-++ | | +-++ |
 | | | | | |
 NVE1 | | | | | | NVE2
 | ++---+ | | ++---+ |
 | |VNI1 VNI1 | | | | VNI1 VNI1 | |
 | +-+---+--+ | | +-+---+--+ |
 |VAP1| |VAP2 | |VAP3| |VAP4 |
 ++---+-+ ++---+-+
 | | | |
 ---+---+--+---+
 | | Tenant | |
 ( ' ) ( ' ) ( ' ) ( ' )
 (Ethernet) (IP Routing) (Ethernet) (IP Routing)
 ( _ ) ( _ ) ( _ ) ( _ )
 | | | |
 TSI1| |TSI2 TSI3| |TSI4
 +---+ +---+ +---+ +---+
 |TS1| |TS2| |TS3| |TS4|
 +---+ +---+ +---+ +---+___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

[nvo3] Fw:New Version Notification for draft-xiao-nvo3-bfd-geneve-01.txt

[xiao.min2]

Hi NVO3 WG,






Based on the discussion that happened in Montreal and on the mailing list, 
we've updated draft-xiao-nvo3-bfd-geneve.


More reviews and comments are always welcome.






Best Regards,


Xiao Min



原始邮件



发件人：internet-dra...@ietf.org 
收件人：肖敏10093570;肖敏10093570;Juniper Networks 
;Gregory Mirsky ;Greg 
Mirsky ;Santosh Pallagatti 
;
日 期 ：2019年10月23日 10:21
主 题 ：New Version Notification for draft-xiao-nvo3-bfd-geneve-01.txt



A new version of I-D, draft-xiao-nvo3-bfd-geneve-01.txt
has been successfully submitted by Xiao Min and posted to the
IETF repository.

Name:draft-xiao-nvo3-bfd-geneve
Revision:01
Title:BFD for Geneve
Document date:2019-10-22
Group:Individual Submission
Pages:13
URL:
https://www.ietf.org/internet-drafts/draft-xiao-nvo3-bfd-geneve-01.txt
Status: https://datatracker.ietf.org/doc/draft-xiao-nvo3-bfd-geneve/
Htmlized:   https://tools.ietf.org/html/draft-xiao-nvo3-bfd-geneve-01
Htmlized:   https://datatracker.ietf.org/doc/html/draft-xiao-nvo3-bfd-geneve
Diff:   https://www.ietf.org/rfcdiff?url2=draft-xiao-nvo3-bfd-geneve-01

Abstract:
   This document describes the use of the Bidirectional Forwarding
   Detection (BFD) protocol in point-to-point Generic Network
   Virtualization Encapsulation (Geneve) tunnels forming up an overlay
   network.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Yes, what I discussed with Anoop was on Greg's option #3.


Respecting BFD over VxLAN, option #2 and #3 both are ok to me, I have no 
preference.


Respecting BFD over Geneve, option #2 and #3 both are ok to me, although I 
personally prefer #3.







Best Regards,


Xiao Min










原始邮件



发件人：AnoopGhanwani 
收件人：Greg Mirsky ;
抄送人：Joel M. Halpern ;Jeffrey Haas 
;Santosh P K ;NVO3 
;draft-ietf-bfd-vx...@ietf.org 
;Dinesh Dutt ;rtg-bfd WG 
;T. Sridhar ;肖敏10093570;Yes
日 期 ：2019年10月23日 07:05
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP





Greg,

I think the draft is fine as is.


I discussion with Xiao Min was about #3 and I see that as unnecessary until we 
have a draft that explains why that is needed in the context of the NVO3 
architecture.


Anoop




On Tue, Oct 22, 2019 at 11:17 AM Greg Mirsky  wrote:


Hi Anoop, et al.,I agree with your understanding of what is being defined in 
the current version of the BFD over VxLAN specification. But, as I understand, 
the WG is discussing the scope before the WGLC is closed. I believe there are 
three options:
single BFD session between two VTEPs

single BFD session per VNI between two VTEPs

multiple BFD sessions per VNI between two VTEPs

The current text reflects #2. Is WG accepts this scope? If not, which option WG 
would accept?



Regards,
Greg




On Tue, Oct 22, 2019 at 2:09 PM Anoop Ghanwani  wrote:



I concur with Joel's assessment with the following clarifications.

The current document is already capable of monitoring multiple VNIs between 
VTEPs.


The issue under discussion was how do we use BFD to monitor multiple VAPs that 
use the same VNI between a pair of VTEPs.  The use case for this is not clear 
to me, as from my understanding, we cannot have a situation with multiple VAPs 
using the same VNI--there is 1:1 mapping between VAP and VNI.


Anoop




On Tue, Oct 22, 2019 at 6:06 AM Joel M. Halpern  wrote:

 From what I can tell, there are two separate problems.
The document we have is a VTEP-VTEP monitoring document.  There is no 
need for that document to handle the multiple VNI case.
If folks want a protocol for doing BFD monitoring of things behind the 
VTEPs (multiple VNIs), then do that as a separate document.   The 
encoding will be a tenant encoding, and thus sesparate from what is 
defined in this document.

Yours,
Joel

On 10/21/2019 5:07 PM, Jeffrey Haas wrote:
> Santosh and others,
> 
> On Thu, Oct 03, 2019 at 07:50:20PM +0530, Santosh P K wrote:
>> Thanks for your explanation. This helps a lot. I would wait for more
>> comments from others to see if this what we need in this draft to be
>> supported based on that we can provide appropriate sections in the draft.
> 
> The threads on the list have spidered to the point where it is challenging
> to follow what the current status of the draft is, or should be.  :-)
> 
> However, if I've followed things properly, the question below is really the
> hinge point on what our encapsulation for BFD over vxlan should look like.
> Correct?
> 
> Essentially, do we or do we not require the ability to permit multiple BFD
> sessions between distinct VAPs?
> 
> If this is so, do we have a sense as to how we should proceed?
> 
> -- Jeff
> 
> [context preserved below...]
> 
>> Santosh P K
>>
>> On Wed, Sep 25, 2019 at 8:10 AM  wrote:
>>
>>> Hi Santosh,
>>>
>>>
>>> With regard to the question whether we should allow multiple BFD sessions
>>> for the same VNI or not, IMHO we should allow it, more explanation as
>>> follows.
>>>
>>> Below is a figure derived from figure 2 of RFC8014 (An Architecture for
>>> Data-Center Network Virtualization over Layer 3 (NVO3)).
>>>
>>>  | Data Center Network (IP)|
>>>  | |
>>>  +-+
>>>   |   |
>>>   |   Tunnel Overlay  |
>>>  ++-+   +-++
>>>  | +--+---+ |   | +---+--+ |
>>>  | |  Overlay Module  | |   | |  Overlay Module  | |
>>>  | +-++ |   | +-++ |
>>>  |   |  |   |   |  |
>>>   NVE1   |   |  |   |   |  | NVE2
>>>  |  ++---+  |   |  ++---+  |
>>>  |  |VNI1 VNI2  VNI1 |  |   |  | VNI1 VNI2 VNI1 |  |
>>>  |  +-+-++---+  |   |  +-+-+-+--+  |
>>>  |VAP1| VAP2|| VAP3 |   |VAP1| VAP2| | VAP3|
>>>  ++-++--+   ++-+-+-+
>>>   | ||   | | |
>>>   | ||   | | |
>>>   | ||   | |  

Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,




Thanks for your reply to my question.

It's clear that we have different views on this case, could you please direct 
me to the text(if any) of RFC/draft that supports your statement?

Any thoughts from others?




Best Regards,

Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月12日 00:00
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Unless they are in the same broadcast domain (which does not appear to the 
case) they would not be in the same VNI.

Anoop




On Fri, Oct 11, 2019 at 2:18 AM  wrote:


Hi Anoop,






In the use case illustrated in below figure, do you think Tenant System1 and 
Tenant System2 can be within the same VN? do you think NVE1 and NVE2 can 
encapsulate the same VNI in the packets sent from Tenant System1 and Tenant 
System2?


 
 . . +--+-+
 . .--|NVE1|
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network .(IP Routing)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System1|
 |NVE2| ++
 | |
 ++
 |
 ( ' )
 (IP Routing)
 ( _ )
 |
 ++
 | Tenant |
 | System2|
 ++




Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月11日 05:33
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Can you provide more detail on your scenario?  I'm having trouble figuring it 
out from the description below.  I need to know what subnets the tenants are in.

Anoop




On Thu, Oct 10, 2019 at 5:00 AM  wrote:


Hi Anoop,






Please see my response inline with [XM].



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月10日 15:47
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


Hi Xiao Min,
In those cases, the term "VN" is used to talk about multiple IP interfaces in a 
VRF.  The different interfaces would have to be different VNIs.

[XM] To be clear, I interpret VNI as Virtual Network Identifier that should be 
present within VxLAN/Geneve header. Do you mean in the case multiple Tenant 
Systems connect to multiple NVEs through IP routing network, different NVEs 
must encapsulate different Virtual Network Identifiers?


In the mixed case (with MPLS and L2 hitting the NVE at different VAPs), I'm not 
sure how it would work in the same VNI.  If you think it's important, I think 
it may be worth writing it up.  If there's enough merit in the use case, we can 
figure out how to run multiple BFD sessions on the same VNI.

[XM] As to the mixed case, I don't know whether there's enough merit, I just 
raise it for discussion because it seems not being prohibited from the NVO3 
architecture point of view.




Anoop







Best Regards,


Xiao Min






On Wed, Oct 9, 2019 at 11:06 PM  wrote:


Hi Anoop,






Normally, it is. While Tenant Systems connect to NVE through IP routing network 
or MPLS forwarding network, it is not.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月10日 05:33
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Normally, I think of a VNI as a broadcast domain.  The only way I can make 
sense of the picture below is to have a separate VNI for each MPLS interface on 
the NVE.

Anoop




On Tue, Oct 8, 2019 at 11:09 PM  wrote:


Hi Anoop,







In this use case there is no forwarding happens between the MPLS and non-MPLS 
parts, would this use case be prohibited?


If the answer is yes, then I agree that all Tenant Systems attached to a common 
NVE MUST share a VAP so long as they connect to the same VN, although in 
RFC8014 it uses "can" but not "MUST". As a result, we should not allow multiple 
BFD sessions for the same VNI between two NVEs.


If the answer is no, then we should allow multiple BFD sessions for the same 
VNI between two NVEs. I personally lean to this answer.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh...pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月09日 06:28
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


Hi Xiao Min,
The picture doesn't have enough information to explain why they are in the same 
VNI, and exactly how forwarding happens between the MPLS and non-MPLS parts.

Anoop




On Tue, Oct 8, 2019 at 12:31 AM  wrote:


Hi Anoop,







I don't know such a draft that describes MPLS over Geneve, but I believe the 
following figure derived from figure 1 of RFC8014 would help, in the following 
figure Tenant System1, 

Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,






In the use case illustrated in below figure, do you think Tenant System1 and 
Tenant System2 can be within the same VN? do you think NVE1 and NVE2 can 
encapsulate the same VNI in the packets sent from Tenant System1 and Tenant 
System2?


 
 . . +--+-+
 . .--|NVE1|
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network .(IP Routing)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System1|
 |NVE2| ++
 | |
 ++
 |
 ( ' )
 (IP Routing)
 ( _ )
 |
 ++
 | Tenant |
 | System2|
 ++




Best Regards,


Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月11日 05:33
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP




Hi Xiao Min,
Can you provide more detail on your scenario?  I'm having trouble figuring it 
out from the description below.  I need to know what subnets the tenants are in.

Anoop




On Thu, Oct 10, 2019 at 5:00 AM  wrote:


Hi Anoop,






Please see my response inline with [XM].



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月10日 15:47
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


Hi Xiao Min,
In those cases, the term "VN" is used to talk about multiple IP interfaces in a 
VRF.  The different interfaces would have to be different VNIs.

[XM] To be clear, I interpret VNI as Virtual Network Identifier that should be 
present within VxLAN/Geneve header. Do you mean in the case multiple Tenant 
Systems connect to multiple NVEs through IP routing network, different NVEs 
must encapsulate different Virtual Network Identifiers?


In the mixed case (with MPLS and L2 hitting the NVE at different VAPs), I'm not 
sure how it would work in the same VNI.  If you think it's important, I think 
it may be worth writing it up.  If there's enough merit in the use case, we can 
figure out how to run multiple BFD sessions on the same VNI.

[XM] As to the mixed case, I don't know whether there's enough merit, I just 
raise it for discussion because it seems not being prohibited from the NVO3 
architecture point of view.




Anoop







Best Regards,


Xiao Min






On Wed, Oct 9, 2019 at 11:06 PM  wrote:


Hi Anoop,






Normally, it is. While Tenant Systems connect to NVE through IP routing network 
or MPLS forwarding network, it is not.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月10日 05:33
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Normally, I think of a VNI as a broadcast domain.  The only way I can make 
sense of the picture below is to have a separate VNI for each MPLS interface on 
the NVE.

Anoop




On Tue, Oct 8, 2019 at 11:09 PM  wrote:


Hi Anoop,







In this use case there is no forwarding happens between the MPLS and non-MPLS 
parts, would this use case be prohibited?


If the answer is yes, then I agree that all Tenant Systems attached to a common 
NVE MUST share a VAP so long as they connect to the same VN, although in 
RFC8014 it uses "can" but not "MUST". As a result, we should not allow multiple 
BFD sessions for the same VNI between two NVEs.


If the answer is no, then we should allow multiple BFD sessions for the same 
VNI between two NVEs. I personally lean to this answer.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh...pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月09日 06:28
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


Hi Xiao Min,
The picture doesn't have enough information to explain why they are in the same 
VNI, and exactly how forwarding happens between the MPLS and non-MPLS parts.

Anoop




On Tue, Oct 8, 2019 at 12:31 AM  wrote:


Hi Anoop,







I don't know such a draft that describes MPLS over Geneve, but I believe the 
following figure derived from figure 1 of RFC8014 would help, in the following 
figure Tenant System1, Tenant System2, Tenant System3 and Tenant System4 are 
assumed belonging to the same VNI, so two BFD sessions for the same VNI need to 
be run between NVE1 and NVE2.

 ++
 +| Tenant |
 ( ' ) | System1|
  ( MPLS ) ++
 . . +--+-+ ( _ )
 . .--|NVE1|---+
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network . (Ethernet)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System2|
 |NVE2| ++
 | |+
 ++ |
 | |
 ( ' ) ( ' )
 ( MPLS ) (Ethernet)
 ( _ ) ( _ )
 | |
 ++ ++
 | Tenant | | Tenant |
 | System3| | System4|
 ++ ++

Re: [nvo3] draft-xiao-nvo3-bfd-geneve-00

[xiao.min2]

Hi Santosh,






Many thanks for your comments.




Please see my response inline with [XM].



原始邮件



发件人：SantoshPK 
收件人：nvo3@ietf.org ;rtg-bfd WG ;
日 期 ：2019年10月04日 01:22
主 题 ：draft-xiao-nvo3-bfd-geneve-00,



Hello Authors,Below are the comments on the draft. 

"[Ed.Note]: Use of O bit is still being discussed in the NVO3 WG, so
 the value is undetermined."
[SPK] In some of the implementation that are using BFD over GENEVE have already 
started using O bit to indicate this is OAM packet and these packets are not 
being forwarded. We may need to set this in the GENEVE header for compatibility 
and have extra information for the new implementation. Any thoughts? 
[XM] Fully agree. In the next revision, will change this sentence to "O bit 
SHOULD be set to 1, which indicates this packet contains a control message."

 "Since multiple BFD sessions may be running between two NVEs, and multiple BFD 
sessions may be originating or terminating at one NVE, there needs to be a 
mechanism for demultiplexing received BFD packets to the proper session."


[SPK] BFD VXLAN https://tools.ietf.org/html/draft-ietf-bfd-vxlan-07 drafts 
there is good discussion going on if we need to define the motivation of the 
draft on what problem it solves if we have BFD per VNI. There are concerns 
about the scalability for the same. While we can still have BFD for subset of 
VNI or we can have BFD per VNI at sedate interval/demand mode and may use P/F 
sequence to poll when required. We can define supporting use case or when P/F 
sequence can be really used for example it can be used when data traffic for a 
given VNI has not been received for some duration. There should also be an 
option to run BFD session for management VNI along with BFD for per VNI. 

[XM] My thoughts are that BFD sessions should be originated and terminated at 
VAP which is defined in RFC8014, and it's still undetermined that whether all 
Tenant Systems attached to a common NVE MUST share a VAP so long as they 
connect to the same VN, which will result in the decision whether we should 
allow multiple BFD sessions for the same VNI, in this respect, we can align the 
statements for both draft-ietf-bfd-vxlan and this draft, alternatively, 
considering the major difference between VxLAN and Geneve that Geneve supports 
multi-protocol payload, we can also make different statements for 
draft-ietf-bfd-vxlan and this draft. Lastly, I don't see much benefit to employ 
P/F sequence here, certainly I'm open to further discussion on it.


 "Since multiple BFD sessions may be running between two NVEs, and multiple BFD 
sessions may be originating or terminating at one NVE, there needs to be a 
mechanism for demultiplexing received BFD packets to the proper session."



[SPK] Above section in subtle way tries to talk about multiple BFD session 
between same pair but again we need to be clear on what is the motivation?

[XM]  As said above, I tend to believe BFD sessions should be originated and 
terminated at VAP, and usually one NVE owns multiple VAPs. In addition, I 
believe the recent discussion over draft-ietf-bfd-vxlan clarifies much of the 
things in this draft too. 




These are my initial thoughts and would like to see good discussion over this 
draft. Please do let me know if you think we need to address them. 

[XM] Thanks again for your good thoughts. I agree that we need to address them, 
in one way or another.




Thanks
Santosh P K 










Best Regards,

Xiao Min___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,






Please see my response inline with [XM].



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月10日 15:47
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


Hi Xiao Min,
In those cases, the term "VN" is used to talk about multiple IP interfaces in a 
VRF.  The different interfaces would have to be different VNIs.

[XM] To be clear, I interpret VNI as Virtual Network Identifier that should be 
present within VxLAN/Geneve header. Do you mean in the case multiple Tenant 
Systems connect to multiple NVEs through IP routing network, different NVEs 
must encapsulate different Virtual Network Identifiers?


In the mixed case (with MPLS and L2 hitting the NVE at different VAPs), I'm not 
sure how it would work in the same VNI.  If you think it's important, I think 
it may be worth writing it up.  If there's enough merit in the use case, we can 
figure out how to run multiple BFD sessions on the same VNI.

[XM] As to the mixed case, I don't know whether there's enough merit, I just 
raise it for discussion because it seems not being prohibited from the NVO3 
architecture point of view.




Anoop







Best Regards,


Xiao Min






On Wed, Oct 9, 2019 at 11:06 PM  wrote:


Hi Anoop,






Normally, it is. While Tenant Systems connect to NVE through IP routing network 
or MPLS forwarding network, it is not.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月10日 05:33
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Normally, I think of a VNI as a broadcast domain.  The only way I can make 
sense of the picture below is to have a separate VNI for each MPLS interface on 
the NVE.

Anoop




On Tue, Oct 8, 2019 at 11:09 PM  wrote:


Hi Anoop,







In this use case there is no forwarding happens between the MPLS and non-MPLS 
parts, would this use case be prohibited?


If the answer is yes, then I agree that all Tenant Systems attached to a common 
NVE MUST share a VAP so long as they connect to the same VN, although in 
RFC8014 it uses "can" but not "MUST". As a result, we should not allow multiple 
BFD sessions for the same VNI between two NVEs.


If the answer is no, then we should allow multiple BFD sessions for the same 
VNI between two NVEs. I personally lean to this answer.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh...pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月09日 06:28
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


Hi Xiao Min,
The picture doesn't have enough information to explain why they are in the same 
VNI, and exactly how forwarding happens between the MPLS and non-MPLS parts.

Anoop




On Tue, Oct 8, 2019 at 12:31 AM  wrote:


Hi Anoop,







I don't know such a draft that describes MPLS over Geneve, but I believe the 
following figure derived from figure 1 of RFC8014 would help, in the following 
figure Tenant System1, Tenant System2, Tenant System3 and Tenant System4 are 
assumed belonging to the same VNI, so two BFD sessions for the same VNI need to 
be run between NVE1 and NVE2.

 ++
 +| Tenant |
 ( ' ) | System1|
  ( MPLS ) ++
 . . +--+-+ ( _ )
 . .--|NVE1|---+
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network . (Ethernet)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System2|
 |NVE2| ++
 | |+
 ++ |
 | |
 ( ' ) ( ' )
 ( MPLS ) (Ethernet)
 ( _ ) ( _ )
 | |
 ++ ++
 | Tenant | | Tenant |
 | System3| | System4|
 ++ ++




Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail...com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月08日 12:15
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Is there a draft that describes MPLS over Geneve?  It sounds like the NVE is an 
MPLS router in this case and if you're using the same VNI as you switch MPLS, 
then it's a one-armed router.  That doesn't change how BFD needs to be run 
between NVEs.

Anoop




On Mon, Oct 7, 2019 at 7:28 PM  wrote:


Hi Anoop,






Sorry for the late response, I just come back from vacation.


The use case is that the network between the VM and the NVE is an MPLS network, 
within which the packet is forwarded basing on MPLS label, but not Ethernet MAC 
address and/or 802.1Q VLAN. When two such kind of MPLS networks need to 
communicate with each other, through a Geneve tunnel, the encap I 

Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,






Normally, it is. While Tenant Systems connect to NVE through IP routing network 
or MPLS forwarding network, it is not.






Best Regards,


Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月10日 05:33
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP




Hi Xiao Min,
Normally, I think of a VNI as a broadcast domain.  The only way I can make 
sense of the picture below is to have a separate VNI for each MPLS interface on 
the NVE.

Anoop




On Tue, Oct 8, 2019 at 11:09 PM  wrote:


Hi Anoop,







In this use case there is no forwarding happens between the MPLS and non-MPLS 
parts, would this use case be prohibited?


If the answer is yes, then I agree that all Tenant Systems attached to a common 
NVE MUST share a VAP so long as they connect to the same VN, although in 
RFC8014 it uses "can" but not "MUST". As a result, we should not allow multiple 
BFD sessions for the same VNI between two NVEs.


If the answer is no, then we should allow multiple BFD sessions for the same 
VNI between two NVEs. I personally lean to this answer.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月09日 06:28
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


Hi Xiao Min,
The picture doesn't have enough information to explain why they are in the same 
VNI, and exactly how forwarding happens between the MPLS and non-MPLS parts.

Anoop




On Tue, Oct 8, 2019 at 12:31 AM  wrote:


Hi Anoop,







I don't know such a draft that describes MPLS over Geneve, but I believe the 
following figure derived from figure 1 of RFC8014 would help, in the following 
figure Tenant System1, Tenant System2, Tenant System3 and Tenant System4 are 
assumed belonging to the same VNI, so two BFD sessions for the same VNI need to 
be run between NVE1 and NVE2.

 ++
 +| Tenant |
 ( ' ) | System1|
  ( MPLS ) ++
 . . +--+-+ ( _ )
 . .--|NVE1|---+
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network . (Ethernet)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System2|
 |NVE2| ++
 | |+
 ++ |
 | |
 ( ' ) ( ' )
 ( MPLS ) (Ethernet)
 ( _ ) ( _ )
 | |
 ++ ++
 | Tenant | | Tenant |
 | System3| | System4|
 ++ ++




Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月08日 12:15
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Is there a draft that describes MPLS over Geneve?  It sounds like the NVE is an 
MPLS router in this case and if you're using the same VNI as you switch MPLS, 
then it's a one-armed router.  That doesn't change how BFD needs to be run 
between NVEs.

Anoop




On Mon, Oct 7, 2019 at 7:28 PM  wrote:


Hi Anoop,






Sorry for the late response, I just come back from vacation.


The use case is that the network between the VM and the NVE is an MPLS network, 
within which the packet is forwarded basing on MPLS label, but not Ethernet MAC 
address and/or 802.1Q VLAN. When two such kind of MPLS networks need to 
communicate with each other, through a Geneve tunnel, the encap I illustrated 
would be used.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年09月28日 05:36
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Thanks for the details about the encap but the use case is not clear.  It might 
help if you explain why its necessary to map a physical Ethernet port and/or 
802.1Q VLAN to the same VNI as an MPLS packet without an L2 header.

Thanks,
Anoop




On Thu, Sep 26, 2019 at 7:50 PM  wrote:


Hi Anoop,






Due to the fact that a variety of Tunnels could be used under the NVO3 
architecture, as an example, below figure illustrates the format of MPLS packet 
over Geneve Tunnel.




 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 Ethernet Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer IPvX Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer UDP Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Geneve Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | | |
 ~ 

Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Joel,






I fully agree to your analysis.


One major difference between VxLAN and Geneve (or VxLAN-GPE) is that VxLAN 
doesn't support multi-protocol payload, and VxLAN only supports payload of 
Ethernet frame. Although VxLAN specification was developed outside NVO3 WG, I 
believe VxLAN may also fall within the NVO3 architecture, and we try to align 
"BFD for VxLAN" and "BFD for Geneve".







Best Regards,


Xiao Min










原始邮件



发件人：JoelM.Halpern 
收件人：Anoop Ghanwani ;肖敏10093570;
抄送人：nvo3@ietf.org ;draft-ietf-bfd-vx...@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月09日 06:31
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP




I will add that from the point of view of VxLAN 9which is the topic), I 
would expect the MPLS packet to arrive in an Ethernet frame, and for 
VxLAN to forward that Ethernet frame.  The VTEP would not seem to even 
need to be aware that the content is MPLS.

Yours,
Joel

On 10/8/2019 6:28 PM, Anoop Ghanwani wrote:
> Hi Xiao Min,
> 
> The picture doesn't have enough information to explain why they are in 
> the same VNI, and exactly how forwarding happens between the MPLS and 
> non-MPLS parts.
> 
> Anoop
> 
> On Tue, Oct 8, 2019 at 12:31 AM  > wrote:
> 
> Hi Anoop,
> 
> 
> I don't know such a draft that describes MPLS over Geneve, but I
> believe the following figure derived from figure 1 of RFC8014 would
> help, in the following figure Tenant System1, Tenant System2, Tenant
> System3 and Tenant System4 are assumed belonging to the same VNI, so
> two BFD sessions for the same VNI need to be run between NVE1 and NVE2.
> 
>  ++
> +| Tenant |
>   ( ' )  | System1|
>     ( MPLS ) ++
>  .  .  +--+-+ ( _ )
>  .  .--|NVE1|---+
>  .  .  ||
>  .  .  +--+-+
>  .  . |
>  .  L3 Overlay  .   ( ' )
>  .Network   . (Ethernet)
>  .  .   ( _ )
>  .  . |
>  ++
> || Tenant |
>   ++ | System2|
>   |NVE2| ++
>   ||+
>   ++|
> |   |
>   ( ' )   ( ' )
> ( MPLS )(Ethernet)
>   ( _ )   ( _ )
> |   |
> ++  ++
> | Tenant |  | Tenant |
> | System3|  | System4|
> ++  ++
> 
> 
> Best Regards,
> 
> Xiao Min
> 
> 原始邮件
> *发件人：*AnoopGhanwani  >
> *收件人：*肖敏10093570;
> *抄送人：*Greg Mirsky  >;did...@gmail.com
>   >;draft-ietf-bfd-vx...@ietf.org
> 
>  >;nvo3@ietf.org
>   >;santosh.pallaga...@gmail.com
>   >;rtg-bfd WG  >;Joel M. Halpern  >;tsrid...@vmware.com
>   >;
> *日 期 ：*2019年10月08日 12:15
> *主 题 ：**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at
> VTEP*
> Hi Xiao Min,
> Is there a draft that describes MPLS over Geneve?  It sounds like
> the NVE is an MPLS router in this case and if you're using the same
> VNI as you switch MPLS, then it's a one-armed router.  That doesn't
> change how BFD needs to be run between NVEs.
> 
> Anoop
> 
> On Mon, Oct 7, 2019 at 7:28 PM  > wrote:
> 
> Hi Anoop,
> 
> 
> Sorry for the late response, I just come back from vacation.
> 
> The use case is that the network between the VM and the NVE is
> an MPLS network, within which the packet is forwarded basing on
> MPLS label, but not Ethernet MAC address and/or 802.1Q VLAN.
> When two such kind of MPLS networks need to communicate with
> each other, through a Geneve tunnel, the encap I illustrated
> would be used.
> 
> 
> Best Regards,
> 
> Xiao Min
> 
> 原始邮件
> *发件人：*AnoopGhanwani  >
> *收件人：*肖敏10093570;
> *抄送人：*Greg Mirsky  >;did...@gmail.com
>    

Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,







In this use case there is no forwarding happens between the MPLS and non-MPLS 
parts, would this use case be prohibited?


If the answer is yes, then I agree that all Tenant Systems attached to a common 
NVE MUST share a VAP so long as they connect to the same VN, although in 
RFC8014 it uses "can" but not "MUST". As a result, we should not allow multiple 
BFD sessions for the same VNI between two NVEs.


If the answer is no, then we should allow multiple BFD sessions for the same 
VNI between two NVEs. I personally lean to this answer.






Best Regards,


Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月09日 06:28
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
The picture doesn't have enough information to explain why they are in the same 
VNI, and exactly how forwarding happens between the MPLS and non-MPLS parts.

Anoop




On Tue, Oct 8, 2019 at 12:31 AM  wrote:


Hi Anoop,







I don't know such a draft that describes MPLS over Geneve, but I believe the 
following figure derived from figure 1 of RFC8014 would help, in the following 
figure Tenant System1, Tenant System2, Tenant System3 and Tenant System4 are 
assumed belonging to the same VNI, so two BFD sessions for the same VNI need to 
be run between NVE1 and NVE2.

 ++
 +| Tenant |
 ( ' ) | System1|
  ( MPLS ) ++
 . . +--+-+ ( _ )
 . .--|NVE1|---+
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network . (Ethernet)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System2|
 |NVE2| ++
 | |+
 ++ |
 | |
 ( ' ) ( ' )
 ( MPLS ) (Ethernet)
 ( _ ) ( _ )
 | |
 ++ ++
 | Tenant | | Tenant |
 | System3| | System4|
 ++ ++




Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月08日 12:15
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Is there a draft that describes MPLS over Geneve?  It sounds like the NVE is an 
MPLS router in this case and if you're using the same VNI as you switch MPLS, 
then it's a one-armed router.  That doesn't change how BFD needs to be run 
between NVEs.

Anoop




On Mon, Oct 7, 2019 at 7:28 PM  wrote:


Hi Anoop,






Sorry for the late response, I just come back from vacation.


The use case is that the network between the VM and the NVE is an MPLS network, 
within which the packet is forwarded basing on MPLS label, but not Ethernet MAC 
address and/or 802.1Q VLAN. When two such kind of MPLS networks need to 
communicate with each other, through a Geneve tunnel, the encap I illustrated 
would be used.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年09月28日 05:36
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Thanks for the details about the encap but the use case is not clear.  It might 
help if you explain why its necessary to map a physical Ethernet port and/or 
802.1Q VLAN to the same VNI as an MPLS packet without an L2 header.

Thanks,
Anoop




On Thu, Sep 26, 2019 at 7:50 PM  wrote:


Hi Anoop,






Due to the fact that a variety of Tunnels could be used under the NVO3 
architecture, as an example, below figure illustrates the format of MPLS packet 
over Geneve Tunnel.




 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 Ethernet Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer IPvX Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer UDP Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Geneve Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | | |
 ~ MPLS Label Stack ~ M
 | | P
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L
 | | S
 | |
 ~ Payload ~ P
 | | K
 | | T
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | FCS |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Note that in NVO3 working group Greg and I have submitted an individual draft 
draft-xiao-nvo3-bfd-geneve, which is used to address BFD over Geneve.

The intention is to make the two drafts draft-ietf-bfd-vxlan and 
draft-xiao-nvo3-bfd-geneve aligned, that is to say, we try to define the 
identical mechanism for 

Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,







I don't know such a draft that describes MPLS over Geneve, but I believe the 
following figure derived from figure 1 of RFC8014 would help, in the following 
figure Tenant System1, Tenant System2, Tenant System3 and Tenant System4 are 
assumed belonging to the same VNI, so two BFD sessions for the same VNI need to 
be run between NVE1 and NVE2.

 ++
 +| Tenant |
 ( ' ) | System1|
  ( MPLS ) ++
 . . +--+-+ ( _ )
 . .--|NVE1|---+
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network . (Ethernet)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System2|
 |NVE2| ++
 | |+
 ++ |
 | |
 ( ' ) ( ' )
 ( MPLS ) (Ethernet)
 ( _ ) ( _ )
 | |
 ++ ++
 | Tenant | | Tenant |
 | System3| | System4|
 ++ ++




Best Regards,


Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月08日 12:15
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP




Hi Xiao Min,
Is there a draft that describes MPLS over Geneve?  It sounds like the NVE is an 
MPLS router in this case and if you're using the same VNI as you switch MPLS, 
then it's a one-armed router.  That doesn't change how BFD needs to be run 
between NVEs.

Anoop




On Mon, Oct 7, 2019 at 7:28 PM  wrote:


Hi Anoop,






Sorry for the late response, I just come back from vacation.


The use case is that the network between the VM and the NVE is an MPLS network, 
within which the packet is forwarded basing on MPLS label, but not Ethernet MAC 
address and/or 802.1Q VLAN. When two such kind of MPLS networks need to 
communicate with each other, through a Geneve tunnel, the encap I illustrated 
would be used.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年09月28日 05:36
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Thanks for the details about the encap but the use case is not clear.  It might 
help if you explain why its necessary to map a physical Ethernet port and/or 
802.1Q VLAN to the same VNI as an MPLS packet without an L2 header.

Thanks,
Anoop




On Thu, Sep 26, 2019 at 7:50 PM  wrote:


Hi Anoop,






Due to the fact that a variety of Tunnels could be used under the NVO3 
architecture, as an example, below figure illustrates the format of MPLS packet 
over Geneve Tunnel.




 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 Ethernet Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer IPvX Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer UDP Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Geneve Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | | |
 ~ MPLS Label Stack ~ M
 | | P
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L
 | | S
 | |
 ~ Payload ~ P
 | | K
 | | T
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | FCS |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Note that in NVO3 working group Greg and I have submitted an individual draft 
draft-xiao-nvo3-bfd-geneve, which is used to address BFD over Geneve.

The intention is to make the two drafts draft-ietf-bfd-vxlan and 
draft-xiao-nvo3-bfd-geneve aligned, that is to say, we try to define the 
identical mechanism for the common part of BFD over VxLAN Tunnel and BFD over 
Geneve Tunnel. For the common part, draft-xiao-nvo3-bfd-geneve would reference 
to draft-ietf-bfd-vxlan, and for the other part specific to Geneve, we'll 
define the specific mechanism in draft-xiao-nvo3-bfd-geneve.




Hope that clarifies.




Best Regards,

Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com 
;bfd-cha...@ietf.org ;
日 期 ：2019年09月26日 23:16
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
I think we would need more detail around the use case below.  What does the 
MPLS packet over Tunnel look like?

Thanks,
Anoop




On Wed, Sep 25, 2019 at 11:37 PM  wrote:


Hi Anoop,






Thanks for your comments.


Considering a scenario where TS1 has an MPLS access (i.e. MPLS-Packet over 
Tunnel between NVEs) to VNI1, TS3 has an Ethernet access (i.e. MAC-Frame over 
Tunnel between NVEs) to VNI1, then how can TS1 and TS3 share one VAP?






Best 

Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,






Sorry for the late response, I just come back from vacation.


The use case is that the network between the VM and the NVE is an MPLS network, 
within which the packet is forwarded basing on MPLS label, but not Ethernet MAC 
address and/or 802.1Q VLAN. When two such kind of MPLS networks need to 
communicate with each other, through a Geneve tunnel, the encap I illustrated 
would be used.






Best Regards,


Xiao Min










原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年09月28日 05:36
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP






Hi Xiao Min,

Thanks for the details about the encap but the use case is not clear.  It might 
help if you explain why its necessary to map a physical Ethernet port and/or 
802.1Q VLAN to the same VNI as an MPLS packet without an L2 header.


Thanks,
Anoop




On Thu, Sep 26, 2019 at 7:50 PM  wrote:



Hi Anoop,






Due to the fact that a variety of Tunnels could be used under the NVO3 
architecture, as an example, below figure illustrates the format of MPLS packet 
over Geneve Tunnel.




 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 Ethernet Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer IPvX Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer UDP Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Geneve Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | | |
 ~ MPLS Label Stack ~ M
 | | P
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L
 | | S
 | |
 ~ Payload ~ P
 | | K
 | | T
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | FCS |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Note that in NVO3 working group Greg and I have submitted an individual draft 
draft-xiao-nvo3-bfd-geneve, which is used to address BFD over Geneve.

The intention is to make the two drafts draft-ietf-bfd-vxlan and 
draft-xiao-nvo3-bfd-geneve aligned, that is to say, we try to define the 
identical mechanism for the common part of BFD over VxLAN Tunnel and BFD over 
Geneve Tunnel. For the common part, draft-xiao-nvo3-bfd-geneve would reference 
to draft-ietf-bfd-vxlan, and for the other part specific to Geneve, we'll 
define the specific mechanism in draft-xiao-nvo3-bfd-geneve.




Hope that clarifies.




Best Regards,

Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com 
;bfd-cha...@ietf.org ;
日 期 ：2019年09月26日 23:16
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP




Hi Xiao Min,
I think we would need more detail around the use case below.  What does the 
MPLS packet over Tunnel look like?

Thanks,
Anoop




On Wed, Sep 25, 2019 at 11:37 PM  wrote:



Hi Anoop,






Thanks for your comments.


Considering a scenario where TS1 has an MPLS access (i.e. MPLS-Packet over 
Tunnel between NVEs) to VNI1, TS3 has an Ethernet access (i.e. MAC-Frame over 
Tunnel between NVEs) to VNI1, then how can TS1 and TS3 share one VAP?






Best Regards,


Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com 
;bfd-cha...@ietf.org ;
日 期 ：2019年09月26日 08:36
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3



>>>

Some people may argue that all Tenant Systems connecting to the same Virtual 
Network MUST share one VAP, if that's true, then VAP1 and VAP3 should merge 
into one VAP and my explanation doesn't work. Copying to NVO3 WG to involve 
more experts, hope for your clarifications and comments.  


>>>

I would be one of those that would argue that they MUST share on VAP if they 
connect to the same Virtual Network.  IMO, the NVO3 arch doc should have been 
clearer about this.

Thanks,
Anoop



On Tue, Sep 24, 2019 at 7:40 PM  wrote:



Hi Santosh,






With regard to the question whether we should allow multiple BFD sessions for 
the same VNI or not, IMHO we should allow it, more explanation as follows...


Below is a figure derived from figure 2 of RFC8014 (An Architecture for 
Data-Center Network Virtualization over Layer 3 (NVO3)).




 | Data Center Network (IP) |
 | |
 +-+
 | |
 | Tunnel Overlay |
 ++-+ 

Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,






Due to the fact that a variety of Tunnels could be used under the NVO3 
architecture, as an example, below figure illustrates the format of MPLS packet 
over Geneve Tunnel.




 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 Ethernet Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer IPvX Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer UDP Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Geneve Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | | |
 ~ MPLS Label Stack ~ M
 | | P
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L
 | | S
 | |
 ~ Payload ~ P
 | | K
 | | T
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | FCS |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Note that in NVO3 working group Greg and I have submitted an individual draft 
draft-xiao-nvo3-bfd-geneve, which is used to address BFD over Geneve.

The intention is to make the two drafts draft-ietf-bfd-vxlan and 
draft-xiao-nvo3-bfd-geneve aligned, that is to say, we try to define the 
identical mechanism for the common part of BFD over VxLAN Tunnel and BFD over 
Geneve Tunnel. For the common part, draft-xiao-nvo3-bfd-geneve would reference 
to draft-ietf-bfd-vxlan, and for the other part specific to Geneve, we'll 
define the specific mechanism in draft-xiao-nvo3-bfd-geneve.




Hope that clarifies.




Best Regards,

Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com 
;bfd-cha...@ietf.org ;
日 期 ：2019年09月26日 23:16
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP




Hi Xiao Min,
I think we would need more detail around the use case below.  What does the 
MPLS packet over Tunnel look like?

Thanks,
Anoop




On Wed, Sep 25, 2019 at 11:37 PM  wrote:



Hi Anoop,






Thanks for your comments.


Considering a scenario where TS1 has an MPLS access (i.e. MPLS-Packet over 
Tunnel between NVEs) to VNI1, TS3 has an Ethernet access (i.e. MAC-Frame over 
Tunnel between NVEs) to VNI1, then how can TS1 and TS3 share one VAP?






Best Regards,


Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com 
;bfd-cha...@ietf.org ;
日 期 ：2019年09月26日 08:36
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3



>>>

Some people may argue that all Tenant Systems connecting to the same Virtual 
Network MUST share one VAP, if that's true, then VAP1 and VAP3 should merge 
into one VAP and my explanation doesn't work. Copying to NVO3 WG to involve 
more experts, hope for your clarifications and comments.  


>>>

I would be one of those that would argue that they MUST share on VAP if they 
connect to the same Virtual Network.  IMO, the NVO3 arch doc should have been 
clearer about this.

Thanks,
Anoop



On Tue, Sep 24, 2019 at 7:40 PM  wrote:



Hi Santosh,






With regard to the question whether we should allow multiple BFD sessions for 
the same VNI or not, IMHO we should allow it, more explanation as follows...


Below is a figure derived from figure 2 of RFC8014 (An Architecture for 
Data-Center Network Virtualization over Layer 3 (NVO3)).




 | Data Center Network (IP) |
 | |
 +-+
 | |
 | Tunnel Overlay |
 ++-+ +-++
 | +--+---+ | | +---+--+ |
 | | Overlay Module | | | | Overlay Module | |
 | +-++ | | +-++ |
 | | | | | |
 NVE1 | | | | | | NVE2
 | ++---+ | | ++---+ |
 | |VNI1 VNI2 VNI1 | | | | VNI1 VNI2 VNI1 | |
 | +-+-++---+ | | +-+-+-+--+ |
 |VAP1| VAP2| | VAP3 | |VAP1| VAP2| | VAP3|
 ++-++--+ ++-+-+-+
 | | | | | |
 | | | | | |
 | | | | | |
 ---+-++---+-+-+---
 | | | Tenant | | |
 TSI1 | TSI2| | TSI3 TSI1| TSI2| |TSI3
 +---+ +---+ +---+ +---+ +---+ +---+
 |TS1| |TS2| |TS3| |TS4| |TS5| |TS6|
 +---+ +---+ +---+ +---+ +---+ +---+
To my understanding, the BFD sessions between NVE1 and NVE2 are actually 
initiated and terminated at VAP of NVE.


If the network operator want to set up one BFD session between VAP1 of NVE1 and 
VAP1of NVE2, at the same time another BFD session between VAP3 of NVE1 and VAP3 
of NVE2, although the two BFD sessions are for the same VNI1, I believe it's 

Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,






Thanks for your comments.


Considering a scenario where TS1 has an MPLS access (i.e. MPLS-Packet over 
Tunnel between NVEs) to VNI1, TS3 has an Ethernet access (i.e. MAC-Frame over 
Tunnel between NVEs) to VNI1, then how can TS1 and TS3 share one VAP?






Best Regards,


Xiao Min










原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com 
;bfd-cha...@ietf.org ;
日 期 ：2019年09月26日 08:36
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP




___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3



>>>

Some people may argue that all Tenant Systems connecting to the same Virtual 
Network MUST share one VAP, if that's true, then VAP1 and VAP3 should merge 
into one VAP and my explanation doesn't work. Copying to NVO3 WG to involve 
more experts, hope for your clarifications and comments.  


>>>



I would be one of those that would argue that they MUST share on VAP if they 
connect to the same Virtual Network.  IMO, the NVO3 arch doc should have been 
clearer about this.


Thanks,
Anoop




On Tue, Sep 24, 2019 at 7:40 PM  wrote:



Hi Santosh,






With regard to the question whether we should allow multiple BFD sessions for 
the same VNI or not, IMHO we should allow it, more explanation as follows...


Below is a figure derived from figure 2 of RFC8014 (An Architecture for 
Data-Center Network Virtualization over Layer 3 (NVO3)).




 | Data Center Network (IP) |
 | |
 +-+
 | |
 | Tunnel Overlay |
 ++-+ +-++
 | +--+---+ | | +---+--+ |
 | | Overlay Module | | | | Overlay Module | |
 | +-++ | | +-++ |
 | | | | | |
 NVE1 | | | | | | NVE2
 | ++---+ | | ++---+ |
 | |VNI1 VNI2 VNI1 | | | | VNI1 VNI2 VNI1 | |
 | +-+-++---+ | | +-+-+-+--+ |
 |VAP1| VAP2| | VAP3 | |VAP1| VAP2| | VAP3|
 ++-++--+ ++-+-+-+
 | | | | | |
 | | | | | |
 | | | | | |
 ---+-++---+-+-+---
 | | | Tenant | | |
 TSI1 | TSI2| | TSI3 TSI1| TSI2| |TSI3
 +---+ +---+ +---+ +---+ +---+ +---+
 |TS1| |TS2| |TS3| |TS4| |TS5| |TS6|
 +---+ +---+ +---+ +---+ +---+ +---+
To my understanding, the BFD sessions between NVE1 and NVE2 are actually 
initiated and terminated at VAP of NVE.


If the network operator want to set up one BFD session between VAP1 of NVE1 and 
VAP1of NVE2, at the same time another BFD session between VAP3 of NVE1 and VAP3 
of NVE2, although the two BFD sessions are for the same VNI1, I believe it's 
reasonable, so that's why I think we should allow it.






Of course, in RFC8014 it also says:

"Note that two different Tenant Systems (and TSIs) attached to a common NVE can 
share a VAP (e.g., TS1 and TS2 in Figure 2) so long as they connect to the same 
Virtual Network."
Some people may argue that all Tenant Systems connecting to the same Virtual 
Network MUST share one VAP, if that's true, then VAP1 and VAP3 should merge 
into one VAP and my explanation doesn't work. Copying to NVO3 WG to involve 
more experts, hope for your clarifications and comments.






Best Regards,


Xiao Min___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Joel,






Thanks for your comments.


I don't think the VNI could own IP address and MAC address, if the BFD messages 
are originated and terminated at the VNI, then what addresses would be used by 
the BFD messages?


As to the VAP, RFC8014 defines it as below:


"On the NVE side, a VAP is a logical network port (virtual or physical) into a 
specific virtual network."
I interpret this definition as that the VAP could own IP address and MAC 
address, so I tend to believe the BFD messages are originated and terminated at 
the VAP.






p.s. I trimmed this mail to meet the size limit, my last mail is too big, which 
results in a warning from rtg-bfd-ow...@ietf.org.






Best Regards,



Xiao Min



原始邮件



发件人：JoelM.Halpern 
收件人：肖敏10093570;
抄送人：rtg-...@ietf.org ;nvo3@ietf.org 
;tsrid...@vmware.com ;bfd-cha...@ietf.org 
;
日 期 ：2019年09月25日 11:00
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


As far as I can tell, the current document we have in front of us is 
explicit that the messages are originated and terminated at the VNI.  If 
you want some other behavior, then we need a document that describes 
that behaviors.

Yours,
Joel

On 9/24/2019 10:39 PM, xiao.m...@zte.com.cn wrote:
> Hi Santosh,
> 
> 
> With regard to the question whether we should allow multiple BFD 
> sessions for the same VNI or not, IMHO we should allow it, more 
> explanation as follows.
> 
> Below is a figure derived from figure 2 of RFC8014 (An Architecture for 
> Data-Center Network Virtualization over Layer 3 (NVO3)).
> 
>  | Data Center Network (IP)|
>  | |
>  +-+
>   |   |
>   |   Tunnel Overlay  |
>  ++-+   +-++
>  | +--+---+ |   | +---+--+ |
>  | |  Overlay Module  | |   | |  Overlay Module  | |
>  | +-++ |   | +-++ |
>  |   |  |   |   |  |
>   NVE1   |   |  |   |   |  | NVE2
>  |  ++---+  |   |  ++---+  |
>  |  |VNI1 VNI2  VNI1 |  |   |  | VNI1 VNI2 VNI1 |  |
>  |  +-+-++---+  |   |  +-+-+-+--+  |
>  |VAP1| VAP2|| VAP3 |   |VAP1| VAP2| | VAP3|
>  ++-++--+   ++-+-+-+
>   | ||   | | |
>   | ||   | | |
>   | ||   | | |
>---+-++---+-+-+---
>   | || Tenant| | |
>  TSI1 | TSI2|| TSI3  TSI1| TSI2| |TSI3
>  +---+ +---+ +---+ +---+ +---+   +---+
>  |TS1| |TS2| |TS3| |TS4| |TS5|   |TS6|
>  +---+ +---+ +---+ +---+ +---+   +---+
> 
> To my understanding, the BFD sessions between NVE1 and NVE2 are actually 
> initiated and terminated at VAP of NVE.
> 
> If the network operator want to set up one BFD session between VAP1 of 
> NVE1 and VAP1of NVE2, at the same time another BFD session between VAP3 
> of NVE1 and VAP3 of NVE2, although the two BFD sessions are for the same 
> VNI1, I believe it's reasonable, so that's why I think we should allow it.
> 
> 
> Of course, in RFC8014 it also says:
> 
> "Note that two different Tenant Systems (and TSIs) attached to a common NVE 
> can share a VAP (e.g., TS1 and TS2 in Figure 2) so long as they connect to 
> the same Virtual Network."
> 
> Some people may argue that all Tenant Systems connecting to the same 
> Virtual Network MUST share one VAP, if that's true, then VAP1 and VAP3 
> should merge into one VAP and my explanation doesn't work. Copying to 
> NVO3 WG to involve more experts, hope for your clarifications and comments.
> 
> 
> Best Regards,
> 
> Xiao Min
> 
> 原始邮件
> *发件人：*SantoshPK 
> *收件人：*Greg Mirsky ;
> *抄送人：*draft-ietf-bfd-vx...@ietf.org 
> ;Dinesh Dutt ;rtg-bfd 
> WG ;Joel M. Halpern ;T. Sridhar 
> ;bfd-cha...@ietf.org ;
> *日 期 ：*2019年09月23日 05:39
> *主 题 ：**Re: BFD over VXLAN: Trapping BFD Control packet at VTEP*
> Greg,
>  Please see inline reply tagged [SPK]. I have added text requested.
> 
> Thanks
> Santosh P K
> 
> On Fri, Aug 16, 2019 at 4:59 AM Greg Mirsky  > wrote:
> 
> Hi Santosh,
> thank you for your comments. Please find my notes in-lined and
> tagged GIM>>.
> 
> Regards,
> Greg
> 
> On Tue, Aug 13, 2019 at 10:24 PM Santosh P K
> mailto:santosh.pallaga...@gmail.com>>
> wrote:
> 
> Greg,
>