In all the discussion about what VNI to use and multiple VNI support,
I lsot track. Sorry. Still, the earlier documents did not specify the
IP to use. That does NOT mean that we are required in later revisions
of the document to allow anything the client wants. Having said that,
we could add text saying that since the IP address in the BFD request
in VNI 0 is effectively meaningless, it can be set to any value on
transmission and must be ignored on reception. As far as I can tell,
it is definitional that the VtEP does not have any assigned IP address
for VNI 0, so we can't expect that address. Yours, Joel On 10/29/2019
11:10 AM, Anoop Ghanwani wrote:
Hi Joel, Yes, existing implementations use VNI 0 for BFD over
VXLAN. Here are a couple of references:
https://www.juniper.net/documentation/en_US/junos/topics/concept/sdn-ovsdb-bfd-nsx.html
https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-740091.html#_Toc18013665
I guess this document has been evolving and I have not kept up
with it. The version I had reviewed and commented on originally
allowed for VNI 0. The -04 version of the draft has this:
https://tools.ietf.org/html/draft-ietf-bfd-vxlan-04#section-7 What
version are you referring to? Thanks, Anoop On Mon, Oct 28, 2019
at 12:55 PM Joel M. Halpern <[email protected]
<mailto:[email protected]> <mailto:[email protected]>> wrote:
You are saying that there are existing implementations using VNI 0
for this? Given that previous versions of the spec explicitly
disallowed VNI 0, I am having trouble with your objecting that a
spec for how to run over VNI 0 breask existing implementations.
Note that when there is a good technical reason, the IETF does
change Internet Drafts in ways that break early implementations.
That is the price of standardization. Yours, Joel On 10/28/2019
2:30 PM, Anoop Ghanwani wrote: > Hi Joel, > > Writing the spec in
that way would make the current, inter-operable > implementation
of multiple vendors non-compliant with the spec. > > Thanks, >
Anoop > > On Mon, Oct 28, 2019 at 11:07 AM Joel M. Halpern
<[email protected] <mailto:[email protected]>
<mailto:[email protected]> > <mailto:[email protected]
<mailto:[email protected]>>> wrote: > > 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 > <[email protected]
<mailto:[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 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]
<mailto:[email protected]>> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>> > > >
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>> >
<mailto:[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]
<mailto:[email protected]>>> > > >
<mailto:[email protected]
<mailto:[email protected]> >
<mailto:[email protected]
<mailto:[email protected]>> > >
<mailto:[email protected]
<mailto:[email protected]> >
<mailto:[email protected]
<mailto:[email protected]>>>> > > >
<mailto:[email protected]
<mailto:[email protected]> >
<mailto:[email protected]
<mailto:[email protected]>> > >
<mailto:[email protected]
<mailto:[email protected]> >
<mailto:[email protected]
<mailto:[email protected]>>> > > >
<mailto:[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]
<mailto:[email protected]>>> > > >
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>> >
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> > >
> > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]> >
<mailto:[email protected] <mailto:[email protected]>>> > >
<mailto:[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] <mailto:[email protected]>>> >
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>> >
> <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>> > > >
<mailto:[email protected] <mailto:[email protected]> >
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]> >
<mailto:[email protected] <mailto:[email protected]>>> >
> <mailto:[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]
<mailto:[email protected]>>> > > >
<mailto:[email protected]
<mailto:[email protected]> >
<mailto:[email protected]
<mailto:[email protected]>> > >
<mailto:[email protected]
<mailto:[email protected]> >
<mailto:[email protected]
<mailto:[email protected]>>>> > > > >>
<mailto:[email protected]
<mailto:[email protected]> >
<mailto:[email protected]
<mailto:[email protected]>> > >
<mailto:[email protected]
<mailto:[email protected]> >
<mailto:[email protected]
<mailto:[email protected]>>> > > >
<mailto:[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] <mailto:[email protected]>>> >
> > <mailto:[email protected]
<mailto:[email protected]> > <mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected]
<mailto:[email protected]> > <mailto:[email protected]
<mailto:[email protected]>>>> > >
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>> >
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> >
> > <mailto:[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]
<mailto:[email protected]>>> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>> > > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>> > > >
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>> >
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> > >
<mailto:[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]
<mailto:[email protected]>>> > > >
<mailto:[email protected] <mailto:[email protected]> >
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]> >
<mailto:[email protected] <mailto:[email protected]>>>>
> > > >>> <mailto:[email protected]
<mailto:[email protected]> > <mailto:[email protected]
<mailto:[email protected]>> > >
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> >
> > <mailto:[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]
<mailto:[email protected]>>> > > >
<mailto:[email protected] <mailto:[email protected]> >
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]> >
<mailto:[email protected] <mailto:[email protected]>>>>
> > > >>>> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>> > >
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> >
> > <mailto:[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] <mailto:[email protected]>>> >
> > <mailto:[email protected]
<mailto:[email protected]> > <mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected]
<mailto:[email protected]> > <mailto:[email protected]
<mailto:[email protected]>>>> > > > >>>> >
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>> >
> <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>> > > >
<mailto:[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]
<mailto:[email protected]>>> > > >
<mailto:[email protected] <mailto:[email protected]> >
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]> >
<mailto:[email protected] <mailto:[email protected]>>>> >
> > >>>> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>> > >
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> >
> > <mailto:[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] <mailto:[email protected]>>> >
> > <mailto:[email protected]
<mailto:[email protected]> > <mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected]
<mailto:[email protected]> > <mailto:[email protected]
<mailto:[email protected]>>>> > > > >>>> >
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>> >
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> >
> > <mailto:[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]
<mailto:[email protected]>>> > > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>> <mailto:[email protected]
<mailto:[email protected]> > <mailto:[email protected]
<mailto:[email protected]>> > > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>> > > > <mailto:[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 > > >
>>>> > > > > > >
