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

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

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