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
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
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>> 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>>> 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>>>> 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>>>>> 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>>>>>> 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>.
> > This is an
> > > > exception to the behavior defined in
[RFC1122
> > > > <https://tools.ietf.org/html/rfc1122>]."
> > > >
> > > >
> > > >
> > > > 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>>>>>> 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>>>>>> 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>>>>>> 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>>>>>>
> > > >> 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>>>>>> 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>>>>>> 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>>>>>> 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>>>>>> 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>>>>>>
> > 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>>>>>>
> > 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>>>>>
> > > >>>> https://www.ietf.org/mailman/listinfo/nvo3
> > > >>>>
> > >
> >
>
