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