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

["Joel M. Halpern" <[e-mail]>]

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