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

[Anoop Ghanwani <[e-mail]>]

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