Hi Greg,
As long as the inner MAC address is such that the packet is trapped to the
CPU, it should be fine for use as an inner MAC is it not? Stating that is
better than trying to force a management VNI. What if someone wants to test
connectivity on a specific VNI? I would not pick a loopback IP a
e cases you've
listed? What am I missing? Define VNI 1 as a possible use, not VNI 0. I
objected to VNI 0 because there are too many switching siicon out there and
some of them will not be able to handle this scenario.
Dinesh
>
> Regards,
> Greg
>
> On Wed, Jul 31, 2019 at 12:03 P
VNIs:
NEW TEXT:
An operator MUST select a VNI number to be used as Management VNI.
Management VNI number MUST NOT be one of the tenant's VNIs to prevent
sending VXLAN packets received on Management VNI to a tenant. VNI number 1
is RECOMMENDED as the default for Management VNI.
On Wed, Jul 3
n the inner IP header (see
> attached email). Could you please comment on that aspect?
>
> Regards,
> Reshad.
>
> I understand that RFC 7348 maybe is not clear on that issue. I'd like to
> understand how the existing implementations behave, process VXLAN header
>
OAM, e.g. CCM frames. The reason to use 127/8 for IPv4, and
>>> > 0:0:0:0:0::7F00:0/104 for IPv6 is to safeguard from leaking
>>> > Ethernet frames with BFD Control packet to a tenant.
>>> > You've suggested using a MAC address to trap the
not
> even a problem I understand, since all the VNI between an ingress and
> egress VTEP share fate.
>
> Yours,
> Joel
>
> On 8/2/2019 1:44 PM, Dinesh Dutt wrote:
> > Thanks for verifying this. On Linux and hardware routers that I'm aware
> > of (Cisco circa 2012 and
I am reading your various emails correctly Dinesh (and I may have
> > missed something) you are trying to use the MAC address because you
> > want
> > to be able to send these BFD packets over arbitrary VNI to monitor
> the
> > VNI. That is not a require
reg proposed meets the needs, and
> does so in a way that is consistent with VxLAN.
>
> Yours,
> Joel
>
> On 8/2/2019 8:30 PM, Dinesh Dutt wrote:
> > What is the stated purpose of this BFD session? The VTEP reachability is
> > determined by the underlay, I don&#
; tenants, and which VNI it has allocated. In contrast, it does not know
> which IP addresses or MAC adddresses teh tenant is using or may plan to
> use.
>
> Yours,
> Joel
>
> On 8/2/2019 6:41 PM, Dinesh Dutt wrote:
> > The assumption of an IP address within any VNI is sus
What I mean is "How do you infer that it excludes the case I'm talking
about?".
Dinesh
On Fri, Aug 2, 2019 at 5:41 PM Dinesh Dutt wrote:
> The abstract reads this: "
>
> This document describes the use of the Bidirectional Forwarding
>Detection (BFD) pr
d those
packets ever go through a firewall though? In any case, maybe suggest the
use of those addresses with a statement that this is how LSP does it, but
that other MAC/IP pairs are possible as long as the conditions of the
endpoint owning the MAC/IP was honored.
Dinesh
>
> Regards,
> Greg
&
on
>is realized as the set of concatenated OAM domains, e.g., VM1-1 - IP1
>-- IP2 - VM2-1, then the BFD session over VXLAN between VTEPs SHOULD
>follow the procedures described in Section 6.8.17 [RFC5880].
> I've attached the current working version of the draft.
>
&g
address of the inner IP packet MUST be selected from
> the range 127/8 for IPv4, and for IPv6 from the range
> 0:0:0:0:0::7F00:0/104. The TTL value in the inner IP header MUST be set
> to 1.
>
> Regards,
> Greg
>
> On Sun, Aug 4, 2019 at 9:07 AM Dinesh Dutt wrote:
>
e pair of VTEPs.
> Please review the changes to Sections 4 and 6 and share your feedback,
> suggestions, and questions.
>
> Regards,
> Greg
>
> On Mon, Aug 5, 2019 at 6:03 PM Dinesh Dutt wrote:
>
>>
>>
>> On Mon, Aug 5, 2019 at 5:56 PM Greg Mirsky wrote:
>&
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
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 what
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
t 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 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
do
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
wrote:
I have the same feeling as Anoop. Greg, can you please point me
to the latest
ome text on the
> firewall interaction. Any other contributions are welcome and greatly
> appreciated.
>
> Regards,
> Greg
>
> > On Wed, Oct 23, 2019 at 3:54 PM Dinesh Dutt wrote:
> > > Looks good to me Greg. I see that the text around the use of the inner IP
&g
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 destina
While I agree that there are no tenant MACs on a management VNI, I'm
loathe to introduce another forwarding behavior, one that's
VNI-specific. MUST use a MAC thats owned by the VTEP is all that's
required. All VTEPs, existing and past work with this, because that's
the VTEP decapsulate and forw
o not
see is why we want to require it? Using those would seem to
complicate configuring BFD, since as far as I know those addresses
are not known to remote VTEPs.
Yours,
Joel
On 11/3/2019 11:07 PM, Dinesh Dutt wrote:
While I agree that there are no tenant MACs on a management VNI, I'm
I didn't suggest the use of a multicast MAC, any MAC would be fine in
the management VNI since there can be no tenant VMs on a management
VNI. I was recommending specifying a unicast MAC.
Santosh, as I mentioned to Joel, I don't want to add additional
forwarding requirements--such as VNI-speci
r the Management VNI comes very close to requesting the assignment
of the MAC for the Management VNI.
Regards,
Greg
On Mon, Nov 4, 2019 at 9:36 AM Dinesh Dutt wrote:
I didn't suggest the use of a multicast MAC, any MAC would be fine
in the management VNI since there can be no tenant VM
sure about the value of the statement
> >>
> An implementation MAY use VNI number 1 as the
> default value for the Management VNI.
> >>
> What prompted this, and if we need to recommend a value, why not 0?
>
> Thanks,
> Anoop
>
> > On Tue, Nov 5,
26 matches
Mail list logo
