Hi Selvakumar,
a packet can be identified as a BFD Control message by the value of the
destination UDP port field. The intention of the text you've quoted is
to suggest that if the received by VTEP packet has been identified as a
BFD control packet it SHOULD NOT be forwarded to a tenant. What to do
with such packet? I believe it must be silently dropped.
Does it make sense?
Regards,
Greg
On Wed, Oct 30, 2019 at 1:36 PM Selvakumar Sivaraj <ssiva...@juniper.net
<mailto:ssiva...@juniper.net>> wrote:
Greg,____
__ __
>Section 5.____
>If the Destination MAC of the inner Ethernet frame doesn't____
> match any of VTEP's MAC addresses, then the processing of the____
> received VXLAN packet MUST follow the procedures described in____
> Section 4.1 [RFC7348].____
>BFD Control packets with unknown MAC address MUST NOT be____
> forwarded to VMs.____
__ __
If the packet doesn’t match VTEP mac address, the packet is
forwarded based on Section 4.1 [RFC7348]. What is the assumption
behind this statement “BFD Control packets with unknown MAC address
MUST NOT be forwarded to VMs”? ____
__ __
Thanks,____
Selvakumar____
__ __
__ __
*From: *nvo3 <nvo3-boun...@ietf.org <mailto:nvo3-boun...@ietf.org>>
on behalf of Greg Mirsky <gregimir...@gmail.com
<mailto:gregimir...@gmail.com>>
*Date: *Wednesday, October 30, 2019 at 1:08 PM
*To: *Dinesh Dutt <did...@gmail.com <mailto:did...@gmail.com>>
*Cc: *NVO3 <n...@ietf.org <mailto:n...@ietf.org>>,
"draft-ietf-bfd-vx...@ietf.org
<mailto:draft-ietf-bfd-vx...@ietf.org>"
<draft-ietf-bfd-vx...@ietf.org
<mailto:draft-ietf-bfd-vx...@ietf.org>>, Anoop Ghanwani
<an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>>, Santosh P K
<santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com>>, Jeffrey Haas <jh...@pfrc.org
<mailto:jh...@pfrc.org>>, rtg-bfd WG <rtg-bfd@ietf.org
<mailto:rtg-bfd@ietf.org>>, "Joel M. Halpern" <j...@joelhalpern.com
<mailto:j...@joelhalpern.com>>, "T. Sridhar" <tsrid...@vmware.com
<mailto:tsrid...@vmware.com>>, "xiao.m...@zte.com.cn
<mailto:xiao.m...@zte.com.cn>" <xiao.m...@zte.com.cn
<mailto:xiao.m...@zte.com.cn>>
*Subject: *Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at
VTEP____
__ __
Dear All, ____
thank you for your comments, suggestions that have made the
discussion the most helpful to the Editors. I've tried to reflect
your comments in the updates listed below:____
* on the inner destination IP address:____
OLD TEXT:____
Destination IP: IP address MUST NOT be of one of tenant's IP
addresses. IP address MAY be selected from the range
127/8 for
IPv4, for IPv6 - from the range 0:0:0:0:0:FFFF:7F00:0/104.____
NEW TEXT:____
Destination IP: IP address MUST NOT be of one of tenant's IP
addresses. The IP address SHOULD be selected from the
range 127/8
for IPv4, for IPv6 - from the range 0:0:0:0:0:FFFF:7F00:0/104.
Alternatively, the destination IP address MAY be set to VTEP's
IP address.____
* firewall. Appended Section 3 Deployment with the following
paragraph:____
As per Section 4, the inner destination IP address SHOULD be set to
one of the loopback addresses (127/8 range for IPv4 and
0:0:0:0:0:FFFF:7F00:0/104 range for IPv6). There could be a
firewall
configured on VTEP to block loopback addresses if set as the
destination IP in the inner IP header. It is RECOMMENDED to allow
addresses from the loopback range through a firewall only if it is
used as the destination IP address in the inner IP header, and the
destination UDP port is set to 3784 [RFC5881].____
__ __
Regarding the use of VNI 0 as the Management VNI. In Section 6 has
been noted:____
An implementation MAY support the use of the Management
VNI as control and management channel between VTEPs. The selection
of the VNI number of the Management VNI MUST be controlled through
management plane. An implementation MAY use VNI number 1 as the
default value for the Management VNI.____
__ __
Attached, please find the updated working version and the diff to
-07.____
Editors much appreciate your comments, suggestions, abd help to have
the new version uploaded before the cut-off deadline.____
__ __
Regards,____
Greg____
__ __
On Wed, Oct 30, 2019 at 4:46 AM Dinesh Dutt <did...@gmail.com
<mailto:did...@gmail.com>> wrote:____
__ __
On Wed, Oct 30, 2019 at 11:40 AM, Anoop Ghanwani
<an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>> wrote:
____
Hi Dinesh, ____
__ __
Your earlier comment was about silicon, that's why I
discussed only the trapping issue. As far as software goes,
IP stacks would typically discard packets received from a
non-loopback interface if the packet's address is in 127/8.
I am not sure a traditional IP stack can play here because
even on Tx, we have the same MAC for reaching all remote
VTEPs. It seems to me the BFD module would have to be
working directly with L2 frames coming off the tunnel. Kind
of like if we were running LLDP between the VTEPs.____
__ __
Hi Anoop, ____
__ __
My earlier comment was indeed about silicon, but the packet has
to go through the software stack as well once it gets to the
CPU. Linux-based solutions such as Linux servers or Cumulus
Linux or maybe even SONIC will need to have a valid IP address
to process the packet. Given that 127/8 is already mandated by
MPLS BFD, sticking with that is better than ignoring the IP
address. This is why I agreed with Jeffrey Haas' comment about
SHOULD be set. ____
__ __
Dinesh
____
__ __
Thanks,____
Anoop____
__ __
On Tue, Oct 29, 2019 at 10:02 PM Dinesh Dutt
<did...@gmail.com <mailto:did...@gmail.com>> wrote:____
Trapping to the CPU would be fine based on MAC DA. But
once there, a self-respecting network stack would look
at the IP header to decide what to do. Ignoring it on
receive may not be an option,
Dinesh____
On Oct 30, 2019, 10:26 AM +0530, Anoop Ghanwani
<an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>>,
wrote:
____
Hi Dinesh, ____
__ __
What would break? If messages are trapped to CPU
based on the MAC DA, what is the problem?____
__ __
On the flip side, there are implementations running
BFD today which use different addresses as specified
here:____
http://www.openvswitch.org/support/dist-docs/vtep.5.html
<https://urldefense.com/v3/__http:/www.openvswitch.org/support/dist-docs/vtep.5.html__;!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D8TPFzme$>____
>>>__ __
*bfd_config_local* *:* *bfd_dst_ip*: optional string____
Set to an IPv4 address to set the IP
address that is expected as____
destination for received BFD
packets. The default is____
*169.254.1.0*.____
>>>__ __
__ __
Thanks,____
Anoop____
__ __
On Tue, Oct 29, 2019 at 7:01 PM Dinesh Dutt
<did...@gmail.com <mailto:did...@gmail.com>> wrote:____
I suspect silicon implementations will have a
problem with saying that they can be set to
anything and MUST be ignored on reception. Your
logic is sound, it's just that I fear you'll
break many existing implementations. I recommend
sticking with the 127/8 address for this case.____
__ __
Dinesh____
On Tue, Oct 29, 2019 at 9:15 PM, Joel M. Halpern
<j...@joelhalpern.com
<mailto:j...@joelhalpern.com>> wrote:
____
In all the discussion about what VNI to use
and multiple VNI support, I lsot track.
Sorry. Still, the earlier documents did not
specify the IP to use. That does NOT mean
that we are required in later revisions of
the document to allow anything the client
wants. Having said that, we could add text
saying that since the IP address in the BFD
request in VNI 0 is effectively meaningless,
it can be set to any value on transmission
and must be ignored on reception. As far as
I can tell, it is definitional that the VtEP
does not have any assigned IP address for
VNI 0, so we can't expect that address.
Yours, Joel On 10/29/2019 11:10 AM, Anoop
Ghanwani wrote: ____
Hi Joel, Yes, existing implementations
use VNI 0 for BFD over VXLAN. Here are
a couple of references:
https://www.juniper.net/documentation/en_US/junos/topics/concept/sdn-ovsdb-bfd-nsx.html
https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-740091.html#_Toc18013665
<https://urldefense.com/v3/__https:/www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-740091.html*_Toc18013665__;Iw!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D-WWtRSX$>
I guess this document has been evolving
and I have not kept up with it. The
version I had reviewed and commented on
originally allowed for VNI 0. The -04
version of the draft has this:
https://tools.ietf.org/html/draft-ietf-bfd-vxlan-04#section-7
<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bfd-vxlan-04*section-7__;Iw!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D1ZHtv2T$>
What version are you referring to?
Thanks, Anoop On Mon, Oct 28, 2019 at
12:55 PM Joel M. Halpern
<j...@joelhalpern.com
<mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com>> wrote: You
are saying that there are existing
implementations using VNI 0 for this?
Given that previous versions of the spec
explicitly disallowed VNI 0, I am having
trouble with your objecting that a spec
for how to run over VNI 0 breask
existing implementations. Note that when
there is a good technical reason, the
IETF does change Internet Drafts in ways
that break early implementations. That
is the price of standardization. Yours,
Joel On 10/28/2019 2:30 PM, Anoop
Ghanwani wrote: > Hi Joel, > > Writing
the spec in that way would make the
current, inter-operable > implementation
of multiple vendors non-compliant with
the spec. > > Thanks, > Anoop > > On
Mon, Oct 28, 2019 at 11:07 AM Joel M.
Halpern <j...@joelhalpern.com
<mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com> >
<mailto:j...@joelhalpern.com
<mailto:j...@joelhalpern.com>>> wrote: >
> I assumed this was only for the
case where a tenant VNI was being used.
> > For the 0 VNI (which is what I
prefer), always (MUST) use the loopback
> address. There are no addresses
assigned to the VTEP in that space. >
There is no IRB in that space. > >
Yours, > Joel > > On
10/28/2019 1:58 PM, Anoop Ghanwani
wrote: > > Joel, > > > >
Are we going to qualify this by VNI?
There's a bunch of > implementations
> > out there that don't use a
tenant IP or a loopback with VNI 0--they
> > simply repeat the underlay IP
in the inner IPDA. > > > >
Thanks, > > Anoop > > > >
On Mon, Oct 28, 2019 at 10:46 AM Joel M.
Halpern > <j...@joelhalpern.com
<mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com
<mailto:j...@joelhalpern.com>> > >
<mailto:j...@joelhalpern.com
<mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com
<mailto:j...@joelhalpern.com>>>> wrote:
> > > > I can live with
saying that you SHOULD use loopback, and
MAY > instead > > use >
> an IP address in the customer
space known to be owned by the VTEP >
> device > > when such
exists. > > > > Yours, >
> Joel > > > > On
10/28/2019 1:32 PM, Anoop Ghanwani
wrote: > > > Hi Joel, >
> > > > > Perhaps we
need to say use of an address owned by
the device > > containing >
> > the VTEP. > > > >
> > Or are you suggesting that
the use of the loopback address >
space > > is a MUST? >
> > > > > Anoop > >
> > > > On Mon, Oct 28,
2019 at 10:22 AM Joel M. Halpern >
> <j...@joelhalpern.com
<mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com
<mailto:j...@joelhalpern.com>> >
<mailto:j...@joelhalpern.com
<mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com
<mailto:j...@joelhalpern.com>>> > >
> <mailto:j...@joelhalpern.com
<mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com
<mailto:j...@joelhalpern.com>> >
<mailto:j...@joelhalpern.com
<mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com
<mailto:j...@joelhalpern.com>>>>> wrote:
> > > > > >
There is something I am missing in
your assumption > about IRB. >
> > > > > As I
understand VxLAN, the VTEP is under the
control > of the > >
operator. > > > As such,
it is a pure bridge. If you run IRB
behind > it, that > > is
fine. > > > Yes, an
operator may offer IRB. But as I
understand it, > >
conceptually, > > > in
terms of the VxLAN architecture the IRB
is an entity > > behind the >
> > VTEP, > > >
not part of the VTEP. > >
> > > > Yours, > >
> Joel > > > >
> > On 10/28/2019 12:23 PM,
Anoop Ghanwani wrote: > > >
> Santosh, > > > > >
> > > Does it have to be
a MUST? What if I am running > IRB
and there > > > are IP >
> > > addresses per VNI
assigned to the VTEPs? Why can the >
> operator not > > >
> choose to use those? > >
> > > > > > Anoop >
> > > > > >
> On Mon, Oct 28, 2019 at 7:51 AM
Santosh P K > > > >
<santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com>
<mailto:santosh.pallaga...@gmail.com> >
<mailto:santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com>>
> >
<mailto:santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com> >
<mailto:santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com>>>
> > >
<mailto:santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com> >
<mailto:santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com>>
> >
<mailto:santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com> >
<mailto:santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com>>>>
> > >
<mailto:santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com> >
<mailto:santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com>>
> >
<mailto:santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com> >
<mailto:santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com>>>
> > >
<mailto:santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com> >
<mailto:santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com>>
> >
<mailto:santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com> >
<mailto:santosh.pallaga...@gmail.com
<mailto:santosh.pallaga...@gmail.com>>>>>>
wrote: > > > > > >
> > Dinesh, Anoop et all,
> > > > Lets
us know if this text works for 127/8 >
> address range? > >
> > > > > >
[proposed text for firewall] > >
> > > > > >
"As per section 4 inner destination IP
address > MUST be > > set
to > > > 127/8 > >
> > address. There may be
firewall configured on > VTEP to >
> block 127/8 > > >
> address range if set as
destination IP in inner IP > >
header. It is > > > >
recommended to allow 127/8 range
address through > > firewall
only if > > > > 127/8
IP address is set as destination address
> in inner IP > > >
header." > > > > >
> > > > > > >
In section 4 we are talking about
using 127/8 > and not > >
really > > > giving >
> > > reason why. I
think we should have text as RFC 5884 >
> has mentioned > >
> > with below text. > >
> > > > > >
[From RFC 5884] > > >
> "The motivation for using the
address range > 127/8 is > >
the same as > > > >
specified in Section 2.1 of [RFC4379]
> > > >
<https://tools.ietf.org/html/rfc4379#section-2.1 <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4379*section-2.1__;Iw!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D1QXo1ID$>>. > > This is an > > > > exception to the behavior defined in [RFC1122 > > > > <https://tools.ietf.org/html/rfc1122 <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc1122__;!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D7jd9cRn$>>]." > > > > > > > > > > > > > > > > Thanks > > > > Santosh P K > > > > > > > > > > > > > > > > On Thu, Oct 24, 2019 at 1:24 AM Dinesh Dutt > > <did...@gmail.com <mailto:did...@gmail.com> <mailto:did...@gmail.com> <mailto:did...@gmail.com <mailto:did...@gmail.com>> > <mailto:did...@gmail.com <mailto:did...@gmail.com> <mailto:did...@gmail.com <mailto:did...@gmail.com>>> > > > <mailto:did...@gmail.com <mailto:did...@gmail.com> <mailto:did...@gmail.com <mailto:did...@gmail.com>> > <mailto:did...@gmail.com <mailto:did...@gmail.com> <mailto:did...@gmail.com <mailto:did...@gmail.com>>>> > > > > <mailto:did...@gmail.com <mailto:did...@gmail.com> > <mailto:did...@gmail.com <mailto:did...@gmail.com>> <mailto:did...@gmail.com <mailto:did...@gmail.com> > <mailto:did...@gmail.com <mailto:did...@gmail.com>>> > > <mailto:did...@gmail.com <mailto:did...@gmail.com> <mailto:did...@gmail.com <mailto:did...@gmail.com>> > <mailto:did...@gmail.com <mailto:did...@gmail.com> <mailto:did...@gmail.com <mailto:did...@gmail.com>>>>>> wrote: > > > > > > > > Looks good to me Greg. I see that the text > around > > the use > > > of the > > > > inner IP address as also quite acceptable. Will > > you add any > > > > words about the firewall? > > > > > > > > Dinesh > > > > > > > > On Wed, Oct 23, 2019 at 8:36 PM, Greg Mirsky > > > > <gregimir...@gmail.com <mailto:gregimir...@gmail.com> <mailto:gregimir...@gmail.com> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>> > > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>>> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>> > > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>>>> > > > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>>> > > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>>>>>> wrote: > > > >> Hi Dinesh, et al., > > > >> please check the updated version that > removed the > > > reference to > > > >> Hypervisor in the text and Figure 1. > > > >> > > > >> Regards, > > > >> Greg > > > >> > > > >> On Wed, Oct 23, 2019 at 10:47 AM Santosh P K > > > >> <santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com> <mailto:santosh.pallaga...@gmail.com> > <mailto:santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com>> > > <mailto:santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com> > <mailto:santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com>>> > > > <mailto:santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com> > <mailto:santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com>> > > <mailto:santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com> > <mailto:santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com>>>> > > > >> <mailto:santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com> > <mailto:santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com>> > > <mailto:santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com> > <mailto:santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com>>> > > > <mailto:santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com> > <mailto:santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com>> > > <mailto:santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com> > <mailto:santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com>>>>>> wrote: > > > >> > > > >> Dinesh, > > > >> Please see my inline comments [SPK] > > > >> > > > >> > > > >> - In section 3, there's a sentence > that > > is: "BFD > > > >> packets intended for a Hypervisor > VTEP MUST > > > NOT..". I > > > >> recommend getting rid of the word > > "Hypervisor" ashe > > > >> logic applies to any VTEP. > > > >> > > > >> [SPK] Thanks for comments. We will > change this. > > > >> > > > >> - You already explained the > precedence of > > the use of > > > >> 127/8 address in the inner header in > > MPLS. I have no > > > >> specific comments in that area. I have > > only two > > > >> questions: > > > >> - Has anybody verified that the > use of > > 127/8 > > > >> address (and the right MAC) works with > > existing > > > >> implementations, including the silicon > > ones? If this > > > >> doesn't work there, is it worth > adding the > > > possibilit > > > >> y of another address, one that is > owned > > by the > > > VTEP node? > > > >> > > > >> - Do we know if Firewalls stop > such VXLAN > > > packets? > > > >> I ask this because VXLAN has an IP > header > > and I > > > don't > > > >> know if firewalls stop packets > with 127/8 > > in the > > > inner > > > >> header. If not, is it worth adding a > > sentence to say > > > >> that firewalls allow such > packets? The > > use of a > > > >> non-127/8 address may alleviate > this case > > as well. > > > >> > > > >> [SPK] I think we may need to add the text > > about firewall > > > >> as some checks in firewall will be > there if > > they are not > > > >> already using MPLS OAM which has inner IP > > header with > > > >> 127/8 address range. > > > >> > > > >> > > > >> The rest of the draft looks good > to me, > > > >> > > > >> Dinesh > > > >> > > > >> On Wed, Oct 23, 2019 at 7:58 AM, > Greg Mirsky > > > >> <gregimir...@gmail.com <mailto:gregimir...@gmail.com> <mailto:gregimir...@gmail.com> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>> > > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>>> >
> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>>>> > > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>>> > > > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>>>>>> > > > >> wrote: > > > >>> Hi Dinesh, > > > >>> I greatly appreciate your comments. > > Please heave a > > > >>> look at the attached copy of the > working > > > version and > > > >>> its diff to -07 (latest in the > datatracker). > > > >>> > > > >>> Regards, > > > >>> Greg > > > >>> > > > >>> On Tue, Oct 22, 2019 at 9:52 PM > Dinesh Dutt > > > >>> <did...@gmail.com <mailto:did...@gmail.com> <mailto:did...@gmail.com> > <mailto:did...@gmail.com <mailto:did...@gmail.com>> > > <mailto:did...@gmail.com <mailto:did...@gmail.com> <mailto:did...@gmail.com <mailto:did...@gmail.com>>> > <mailto:did...@gmail.com <mailto:did...@gmail.com> <mailto:did...@gmail.com <mailto:did...@gmail.com>> > > <mailto:did...@gmail.com <mailto:did...@gmail.com> <mailto:did...@gmail.com <mailto:did...@gmail.com>>>> > > > <mailto:did...@gmail.com <mailto:did...@gmail.com> <mailto:did...@gmail.com <mailto:did...@gmail.com>> > <mailto:did...@gmail.com <mailto:did...@gmail.com> <mailto:did...@gmail.com <mailto:did...@gmail.com>>> > > <mailto:did...@gmail.com <mailto:did...@gmail.com> <mailto:did...@gmail.com <mailto:did...@gmail.com>> > <mailto:did...@gmail.com <mailto:did...@gmail.com> <mailto:did...@gmail.com <mailto:did...@gmail.com>>>>>> wrote: > > > >>> > > > >>> I have the same feeling as Anoop. > > Greg, can you > > > >>> please point me to the latest > draft > > so that > > > I can > > > >>> quickly glance through it to be > > doubly sure, > > > >>> > > > >>> Dinesh > > > >>> > > > >>> On Wed, Oct 23, 2019 at 4:35 AM, > > Anoop Ghanwani > > > >>> <an...@alumni.duke.edu <mailto:an...@alumni.duke.edu> <mailto:an...@alumni.duke.edu> > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>> > > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu> <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>>> > > > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu> > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>> <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu> > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>>>> > > > >>> <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu> > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>> > > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu> <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>>> > > > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu> > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>> > > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu> > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>>>>>> wrote: > > > >>>> 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 > > > >>>> <gregimir...@gmail.com <mailto:gregimir...@gmail.com> <mailto:gregimir...@gmail.com> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>> > > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>>> > > > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>>>> > > > >>>> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>> > > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>>> > > > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>> > > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com> > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>>>>>> 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: > > > >>>> > > > >>>> 1. single BFD session > between > > two VTEPs > > > >>>> 2. single BFD session > per VNI > > between > > > two VTEPs > > > >>>> 3. 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 > <an...@alumni.duke.edu <mailto:an...@alumni.duke.edu> <mailto:an...@alumni.duke.edu> <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>> > > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu> <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>>> > > > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu> > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>> <mailto:an...@alumni.duke.edu
<mailto:an...@alumni.duke.edu> > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>>>> > > > >>>> > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu> <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>> > > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu> <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>>> > > > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu> > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>> > > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu> > <mailto:an...@alumni.duke.edu <mailto:an...@alumni.duke.edu>>>>>> 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 > > <j...@joelhalpern.com <mailto:j...@joelhalpern.com> <mailto:j...@joelhalpern.com> <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>> > <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com> <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>>> > > > <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com> > <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>> <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com> > <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>>>> > > > >>>> > <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com> <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>> > > <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com> <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>>> > > > <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com> > <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>> <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com> > <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>>>>>> > > 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 > > > >>>> > <xiao.m...@zte.com.cn <mailto:xiao.m...@zte.com.cn> <mailto:xiao.m...@zte.com.cn> <mailto:xiao.m...@zte.com.cn <mailto:xiao.m...@zte.com.cn>> > > <mailto:xiao.m...@zte.com.cn <mailto:xiao.m...@zte.com.cn> <mailto:xiao.m...@zte.com.cn <mailto:xiao.m...@zte.com.cn>>> > > > <mailto:xiao.m...@zte.com.cn <mailto:xiao.m...@zte.com.cn> > <mailto:xiao.m...@zte.com.cn <mailto:xiao.m...@zte.com.cn>> <mailto:xiao.m...@zte.com.cn <mailto:xiao.m...@zte.com.cn> > <mailto:xiao.m...@zte.com.cn <mailto:xiao.m...@zte.com.cn>>>> > > > >>>> > > <mailto:xiao.m...@zte.com.cn <mailto:xiao.m...@zte.com.cn> <mailto:xiao.m...@zte.com.cn <mailto:xiao.m...@zte.com.cn>> > <mailto:xiao.m...@zte.com.cn <mailto:xiao.m...@zte.com.cn> <mailto:xiao.m...@zte.com.cn <mailto:xiao.m...@zte.com.cn>>> > > > <mailto:xiao.m...@zte.com.cn <mailto:xiao.m...@zte.com.cn> > <mailto:xiao.m...@zte.com.cn <mailto:xiao.m...@zte.com.cn>> <mailto:xiao.m...@zte.com.cn <mailto:xiao.m...@zte.com.cn> > <mailto:xiao.m...@zte.com.cn <mailto: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 > > > >>>> > > > >>>> > > > _______________________________________________ > > > >>>> nvo3 mailing list > > > >>>> n...@ietf.org <mailto:n...@ietf.org> <mailto:n...@ietf.org> <mailto:n...@ietf.org <mailto:n...@ietf.org>> > <mailto:n...@ietf.org <mailto:n...@ietf.org> <mailto:n...@ietf.org <mailto:n...@ietf.org>>> > > <mailto:n...@ietf.org <mailto:n...@ietf.org> <mailto:n...@ietf.org <mailto:n...@ietf.org>> > <mailto:n...@ietf.org <mailto:n...@ietf.org> <mailto:n...@ietf.org <mailto:n...@ietf.org>>>> <mailto:n...@ietf.org <mailto:n...@ietf.org> > <mailto:n...@ietf.org <mailto:n...@ietf.org>> > > <mailto:n...@ietf.org <mailto:n...@ietf.org> <mailto:n...@ietf.org <mailto:n...@ietf.org>>> > > > <mailto:n...@ietf.org <mailto:n...@ietf.org> <mailto:n...@ietf.org <mailto:n...@ietf.org>> > <mailto:n...@ietf.org <mailto:n...@ietf.org> <mailto:n...@ietf.org <mailto:n...@ietf.org>>>>> > > > >>>> https://www.ietf.org/mailman/listinfo/nvo3 <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/nvo3__;!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70Dwxv3b_a$> > > > >>>> > > > > > >____
