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