Jeff,
Sorry for delayed response. I was on vacation and returned today and
trying to catch up with discussion here. Please see my inline response
[SPK].
On Wed, Oct 30, 2019 at 2:23 AM Jeffrey Haas wrote:
> Santosh,
>
> On Mon, Oct 28, 2019 at 10:24:06PM +0530, Santosh P K wrote:
> > "As
I do assume there is no chance of forwarding the packet. The reason for
specifying it is to be clear what the VTEP is expected to do in that
case. (Which does mean the text has marginal, but non-zero value.)
Yours,
Joel
On 10/31/2019 12:33 PM, Anoop Ghanwani wrote:
What is the definition of
What is the definition of management VNI? Is it that there is no VAP
corresponding to that VNI or something else? If there is no VAP, then
there is no chance of forwarding such packets anyway.
Anoop
On Thu, Oct 31, 2019 at 9:22 AM Jeffrey Haas wrote:
> I also agree with Joel.
>
> -- Jeff
>
>
I also agree with Joel.
-- Jeff
> On Oct 31, 2019, at 11:59 AM, Joel M. Halpern wrote:
>
> Explicitly restricting the discard behavior to the management VNI takes care
> of my concern.
>
> Thank you,
> Joel
>
> On 10/31/2019 11:48 AM, Greg Mirsky wrote:
>> Hi Jeff,
>> thank you for the
Explicitly restricting the discard behavior to the management VNI takes
care of my concern.
Thank you,
Joel
On 10/31/2019 11:48 AM, Greg Mirsky wrote:
Hi Jeff,
thank you for the detailed clarification of your questions. Please find
my follow-up notes in-lined tagged GIM2>>.
Regards,
Greg
Hi Jeff,
thank you for the detailed clarification of your questions. Please find my
follow-up notes in-lined tagged GIM2>>.
Regards,
Greg
On Wed, Oct 30, 2019 at 2:14 PM Jeffrey Haas wrote:
> Greg,
>
> On Wed, Oct 30, 2019 at 01:58:30PM -0700, Greg Mirsky wrote:
> > On Wed, Oct 30, 2019 at
Greg,
On Wed, Oct 30, 2019 at 01:58:30PM -0700, Greg Mirsky wrote:
> On Wed, Oct 30, 2019 at 1:27 PM Jeffrey Haas wrote:
>
> > Greg,
> >
> > From the updated text:
> >
> > "At the same time, a service layer BFD session may be used between the
> > tenants of VTEPs IP1 and IP2 to provide
That sounds very dangerous. If a VTEP receives a packet with an unknown
MAC address on a VNI associated with a user, it could well have any UDP
port value. The BFD port value is NOT magically reserved on end systems
that are not running BFD. (We gave up on reserved ports long ago.)
Yours,
I presume that most silicon implementations of VxLAN VTEPs do not have
any logic for trapping out BFD packets under any circumstances. While
some may have been built anticipating this draft, we have to assume that
many will not be able to support this. So it goes when you add features
to a
On Wed, Oct 30, 2019 at 2:26 AM, Jeffrey Haas wrote:
Santosh,
On Mon, Oct 28, 2019 at 10:24:06PM +0530, Santosh P K wrote:
"As per section 4 inner destination IP address MAY be set to 127/8
address.
There could be firewall configured on VTEP to block 127/8 address
range if
set as
Santosh,
On Mon, Oct 28, 2019 at 10:24:06PM +0530, Santosh P K wrote:
> "As per section 4 inner destination IP address MAY be set to 127/8 address.
> There could 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
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
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
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
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
wrote:
> I assumed this was only for the case where a tenant VNI was being used.
>
> For
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
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
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
wrote:
> There is something I am missing in your assumption about IRB.
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
wrote:
> Dinesh, Anoop et all,
> Lets us know if this text works for
Hi Santosh,
That looks better and I'd be OK with that.
However, I think it would be better if we did something like:
Destination IP: See Section xx.
Where section xx contains the complete description about setting the
destination IP including:
- Use of the underlay VTEP address for VNI 0.
-
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
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
Hi Dinesh,
many thanks for your time, the expertise you've kindly shared on this
discussion.
I believe that Santosh has volunteered ;) to provide some text on the
firewall interaction. Any other contributions are welcome and greatly
appreciated.
Regards,
Greg
On Wed, Oct 23, 2019 at 3:54 PM
You're welcome Greg. I'm glad my input was useful,
Dinesh
On Oct 24, 2019, 1:33 AM +0530, Greg Mirsky , wrote:
> Hi Dinesh,
> many thanks for your time, the expertise you've kindly shared on this
> discussion.
> I believe that Santosh has volunteered ;) to provide some text on the
> firewall
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
wrote:
Hi Dinesh, et al.,
please check the updated version that removed the reference
Thanks Joel.
I see the issue. In the case of IRB, the VTEP will likely have IP
addresses assigned from the tenant space for each VNI. But if there is no
IRB, then it could be a problem. Thus far, my assumption had been that the
underlay address would be used and that the inner addresses would
人：AnoopGhanwani
收件人：Greg Mirsky ;
抄送人：Joel M. Halpern ;Jeffrey Haas
;Santosh P K ;NVO3
;draft-ietf-bfd-vx...@ietf.org
;Dinesh Dutt ;rtg-bfd WG
;T. Sridhar ;肖敏10093570;Yes
日 期 ：2019年10月23日 07:05
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Greg,
I think the draft
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 wrote:
> Hi Anoop, et al.,
> I agree
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.
> -
Anoop,
I guess there were multiple discussion over this should we have inner
TTL as 1 or destination IP address as 127/8 range so that if packet gets
exposed in underlay it should not be routed via underlay to VTEP.
Thanks
Santosh P K
On Wed, Oct 23, 2019 at 11:40 AM Anoop Ghanwani
wrote:
>
Anoop, you refer to "the destination VTEP's IP address". Since this is
a field inside the Ethernet header inside the VxLAN header, what VTEP
assigned IP address? The customer (whose address space this is in may
not be using IP. Or may be using IP and presumably has NOT assigned an
IP
Hi Greg,
The part about the use of 127/8 address appears to be a new thing
introduced in the version of the draft that is as of yet unpublished. What
was the motivation for the change? Previously, the DA was simply set to
the destination VTEP's IP address which seemed fine.
Anoop
On Tue, Oct
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
wrote:
Greg,
I think the draft is fine as is.
I discussion with Xiao Min was about #3 and I
Greg,
Two comments, one minor and one maybe not.
- 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.
- You already explained the precedence of the use of 127/8
t ; draft-ietf-bfd-vx...@ietf.org; NVO3
> ; Santosh P K ; Jeffrey Haas
> ; rtg-bfd WG ; T. Sridhar
> ; xiao.m...@zte.com.cn
> Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
>
> I do not understand the value of option 2.
> Which is why I asked i
oel,
I'm a tad frustrated that we're rehashing this discussions all over
again. I specifically explained all the questions that were raised at
that time. Let me try one last time.
1. BFD for VTEP is only useful for testing VXLAN plumbing, not the
underlay itself.
2. So, the question is
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
Oops, sorry for misspelling your name Joel,
Dinesh
On Wed, Oct 23, 2019 at 1:47 AM, Dinesh Dutt wrote:
oel,
I'm a tad frustrated that we're rehashing this discussions all over
again. I specifically explained all the questions that were raised at
that time. Let me try one last time.
1.
Hi Joel,
RFC 7348 suggests using information from the inner packet to calculate the
value to be used in the Source UDP port number:
- Source Port: It is recommended that the UDP source port number
be calculated using a hash of fields from the inner packet --
one example
Hi Joel,
if the underlay may balance VXLAN between two VTEPs using VNI in addition
to other fields, then Option 2 has a certain value in my opinion.
Regards,
Greg
On Tue, Oct 22, 2019 at 3:06 PM Joel M. Halpern wrote:
> I do not understand the value of option 2.
> Which is why I asked in my
I do not understand the value of option 2.
Which is why I asked in my initial review to move to option 1.
And option 2 requires stealing MAC addresses from the users, which seems
to me to be a very bad thing that option 1 avoids.
Yours,
Joel
On 10/22/2019 2:17 PM, Greg Mirsky wrote:
Hi
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
;
抄送人：draft-ietf-bfd-vx...@ietf.org ;n...@ietf.org
;rtg-bfd WG ;
日 期 ：2019年10月12日 00:00
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Hi Xiao Min,
Unless they are in the same broadcast domain (which does not appear to the
case) they would not be in the same VNI.
Anoop
bnets the tenants
> are in.
>
> Anoop
>
> On Thu, Oct 10, 2019 at 5:00 AM wrote:
>
>> Hi Anoop,
>>
>>
>> Please see my response inline with [XM].
>> 原始邮件
>> *发件人：*AnoopGhanwani
>> *收件人：*肖敏10093570;
>> *抄送人：*draft-ietf-bfd-vx...@i
原始邮件
发件人：AnoopGhanwani
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;n...@ietf.org
;rtg-bfd WG ;
日 期 ：2019年10月11日 05:33
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Hi Xiao Min,
Can you provide more detail on your scenario? I'm having trouble figuring it
out
gt; 原始邮件
> *发件人：*AnoopGhanwani
> *收件人：*肖敏10093570;
> *抄送人：*draft-ietf-bfd-vx...@ietf.org ;
> n...@ietf.org ;rtg-bfd WG ;
> *日 期 ：*2019年10月10日 15:47
> *主 题 ：**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP*
> ___
> nv
:33
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Hi Xiao Min,
Normally, I think of a VNI as a broadcast domain. The only way I can make
sense of the picture below is to have a separate VNI for each MPLS interface on
the NVE.
Anoop
On Tue, Oct 8, 2019 at 11:09 PM
NVE through IP routing
> network or MPLS forwarding network, it is not.
>
>
> Best Regards,
>
> Xiao Min
> 原始邮件
> *发件人：*AnoopGhanwani
> *收件人：*肖敏10093570;
> *抄送人：*draft-ietf-bfd-vx...@ietf.org ;
> n...@ietf.org ;rtg-bfd WG ;
> *日 期 ：*2019年10月10日 05:33
> *主 题 ：**R
Hi Anoop,
Please see my response inline with [XM].
原始邮件
发件人：AnoopGhanwani
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;n...@ietf.org
;rtg-bfd WG ;
日 期 ：2019年10月10日 15:47
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
>>| System3| | System4|
>>++ ++
>>
>>
>> Best Regards,
>>
>> Xiao Min
>> 原始邮件
>> *发件人：*AnoopGhanwani
>> *收件人：*肖敏10093570;
>> *抄送人：*Greg Mirsky ;did...@gmail.com <
>> did...@gmail.com
ietf.org
> <mailto:n...@ietf.org> <mailto:n...@ietf.org>>;santosh.pallaga...@gmail.com
> <mailto:santosh.pallaga...@gmail.com> <mailto:santosh.pallaga...@gmail.com>>;rtg-bfd WG <mailto:rtg-bfd@ietf.org>>;Joel M. Halpern &
,
Xiao Min
原始邮件
发件人：AnoopGhanwani
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com
;draft-ietf-bfd-vx...@ietf.org
;n...@ietf.org
;santosh.pallaga...@gmail.com
;rtg-bfd WG ;Joel M. Halpern
;tsrid...@vmware.com ;
日 期 ：2019年10月09日 06:28
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Co
n...@ietf.org ;
> santosh.pallaga...@gmail.com ;rtg-bfd WG <
> rtg-bfd@ietf.org>;Joel M. Halpern ;
> tsrid...@vmware.com ;
> *日 期 ：*2019年10月08日 12:15
> *主 题 ：**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP*
> Hi Xiao Min,
> Is there a draft that describes MPLS
10093570;
抄送人：Greg Mirsky ;did...@gmail.com
;draft-ietf-bfd-vx...@ietf.org
;n...@ietf.org
;santosh.pallaga...@gmail.com
;rtg-bfd WG ;Joel M. Halpern
;tsrid...@vmware.com ;
日 期 ：2019年10月08日 12:15
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Hi Xiao Min,
Is there a draft
l.com <
> did...@gmail.com>;draft-ietf-bfd-vx...@ietf.org <
> draft-ietf-bfd-vx...@ietf.org>;n...@ietf.org ;
> santosh.pallaga...@gmail.com ;rtg-bfd WG <
> rtg-bfd@ietf.org>;Joel M. Halpern ;
> tsrid...@vmware.com ;
> *日 期 ：*2019年09月28日 05:36
> *主 题 ：**Re: [nvo3
...@gmail.com
;rtg-bfd WG ;Joel M. Halpern
;tsrid...@vmware.com ;
日 期 ：2019年09月28日 05:36
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Hi Xiao Min,
Thanks for the details about the encap but the use case is not clear. It might
help if you explain why its necessary to map
anwani
> *收件人：*肖敏10093570;
> *抄送人：*Greg Mirsky ;did...@gmail.com <
> did...@gmail.com>;draft-ietf-bfd-vx...@ietf.org <
> draft-ietf-bfd-vx...@ietf.org>;n...@ietf.org ;
> santosh.pallaga...@gmail.com ;rtg-bfd WG <
> rtg-bfd@ietf.org>;Joel M. Halpern ;
> tsrid...@vmwa
rg
;n...@ietf.org
;santosh.pallaga...@gmail.com
;rtg-bfd WG ;Joel M. Halpern
;tsrid...@vmware.com
;bfd-cha...@ietf.org ;
日 期 ：2019年09月26日 23:16
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Hi Xiao Min,
I think we would need more detail around the use case below. What does the
0;
> *抄送人：*Greg Mirsky ;did...@gmail.com <
> did...@gmail.com>;draft-ietf-bfd-vx...@ietf.org <
> draft-ietf-bfd-vx...@ietf.org>;n...@ietf.org ;
> santosh.pallaga...@gmail.com ;rtg-bfd WG <
> rtg-bfd@ietf.org>;Joel M. Halpern ;
> tsrid...@vmware.com ;bfd-cha...@ietf.org <
Min
原始邮件
发件人：AnoopGhanwani
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com
;draft-ietf-bfd-vx...@ietf.org
;n...@ietf.org
;santosh.pallaga...@gmail.com
;rtg-bfd WG ;Joel M. Halpern
;tsrid...@vmware.com
;bfd-cha...@ietf.org ;
日 期 ：2019年09月26日 08:36
主 题 ：Re: [nvo3] BFD over VXLAN
limit, my last mail is too big, which
results in a warning from rtg-bfd-ow...@ietf.org.
Best Regards,
Xiao Min
原始邮件
发件人：JoelM.Halpern
收件人：肖敏10093570;
抄送人：rtg-bfd@ietf.org ;n...@ietf.org
;tsrid...@vmware.com ;bfd-cha...@ietf.org
;
日 期 ：2019年09月25日 11:00
主 题 ：Re: [nvo3] BFD
>>>
Some people may argue that all Tenant Systems connecting to the same
Virtual Network MUST share one VAP, if that's true, then VAP1 and VAP3
should merge into one VAP and my explanation doesn't work. Copying to NVO3
WG to involve more experts, hope for your clarifications and comments.
>>>
I
62 matches
Mail list logo
