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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> 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
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> 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
> > > <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>> 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
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
> > > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>> 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
> > > <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>> 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
> > >> <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>
> > >> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>> 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
> > >> <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>>>
> > >> 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
> > >>> <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>> 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
> > >>> <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
> > >>> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>> 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
> > >>>> <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
> > >>>>
<mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>> 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
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
> > >>>>
<mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>> 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
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
> > >>>>
<mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>>>
> 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
> > >>>>
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
> > >>>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>>>
> 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
> > >>>> [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>
> > >>>> https://www.ietf.org/mailman/listinfo/nvo3
> > >>>>
> >
>
