Hello All,
We have submitted new BFD for VXLAN draft Please review and get back to us
with your comments.
Thanks
Santosh P K
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Monday, May 04, 2015 9:29 PM
> To: Basil Saji;
me on some L2 interface.
[SPK] If inner VTEP is not L3 capable then BFD should not be established. BFD
will be applicable to VTEP's which are L3 aware.
Thanks
Santosh P K
>
>
> On Mon, 4 May 2015 16:13:54 +, Santosh P K wrote:
> > Hello All,
> >We ha
the transparent L2 service one would expect
> from VxLAN.
>
I agree with this. We don't want to go filter way. I think your suggestion of
setting MAC address for VTEP to process L3 packet would be right thing to do.
>
> Not sure I understand the draft yet :-)
I think you do
We would like to get slot for BFD for VXLAN
ID Title> BFD for VXLAn
URL> https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-00
Presenter> Santosh/Prasad
Requested time> 15 minutes
Thanks
Santosh P K
> -Original Message-
> From: nvo3 [mailto:nvo3-boun...@ietf
vation?
These are my initial thoughts and would like to see good discussion over
this draft. Please do let me know if you think we need to address them.
Thanks
Santosh P K
___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
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
gt;>>
>>>> On Tue, Oct 22, 2019 at 6:06 AM Joel M. Halpern
>>>> wrote:
>>>>
>>>>> From what I can tell, there are two separate problems.
>>>>> The document we have is a VTEP-VTEP monitoring document. There is no
>&
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>].&q
ss through firewall only if inner IP header's destination IP is
set to 127/8 IP address."
Thanks
Santosh P K
On Mon, Oct 28, 2019 at 9:53 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
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
and reach the CPU.
Thanks
Santosh P K
On Mon, Nov 4, 2019 at 11:35 AM Dinesh Dutt wrote:
> Hi Joel,
>
> I'm comfortable if we fixed a MAC addresss such as 0a:0a:0a:0a:0a:0a (or
> whatever else) for the maagement VNI. That fixes the additional burden of
> configuring BFD fo
Anoop,
Thanks for your comments. For non-managment VNI why do we need to have
multicast MAC address for backward compatibility for existing
implementation or there are any use cases such that we can avoid learning
of remote end VTEP?
Thanks
Santosh P K
On Mon, Nov 4, 2019 at 10:41 AM Anoop
comment on this before we can make these
changes to draft.
Thanks
Santosh P K
On Mon, Nov 4, 2019 at 8:30 PM Anoop Ghanwani wrote:
> Hi Santosh,
>
> I'm not aware of any implementation that uses a multicast MAC for this.
> The closest thing that I'm aware of that helps
Support the document as co-author. Not aware of any IPR.
Thanks
Santosh P K
On Tue, Oct 27, 2020 at 7:23 AM Boutros, Sami wrote:
> Support as a co-author.
>
>
>
> Not aware of any ipr.
>
>
>
> Thanks,
>
>
>
> Sami
>
> *From: *"Bocci, Matthew (
Hello Matthew, Sam, et all,
I support the adoption of the document as co-author.
Thanks
Santosh P K
On Thu, Oct 15, 2020 at 9:10 PM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:
> This email begins a two-week poll for adoption of
> draft-mmbb-nvo3-geneve-oam-04.txt
Hello Matthew,
Sorry for the late reply. I support this document as co-author.
Thanks
Santosh P K
On Thu, Oct 15, 2020 at 9:12 PM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:
> This email begins a two-week poll for adoption of
> draft-xiao-nvo3-bfd-geneve-03.txt
Hello Matthew,
I forgot to mention IPR in my last mail. I support this document and I
am not aware any IPR.
Thanks
Santosh P K
On Mon, Nov 9, 2020 at 11:41 AM Santosh P K
wrote:
> Hello Matthew,
>Sorry for the late reply. I support this document as co-author.
>
> Thanks
&
Hello Matthew, Sam et all,
I missed responding to IPR. I am not aware of any IPR relevant.
Thanks
Santosh P K
On Fri, Oct 30, 2020 at 7:02 PM Santosh P K
wrote:
> Hello Matthew, Sam, et all,
>
> I support the adoption of the document as co-author.
>
> Thanks
> Santosh P
Hello All,
As a co-autor, I am not aware of any IPR that applies to this draft. I
support publication of this document as Standard-track RFC.
Thanks
Santosh P K
On Mon, Oct 10, 2022 at 7:05 PM Greg Mirsky wrote:
> Hi Matthew, et al.,
> I believe that the document is ready for publicat
I have read the latest version of the document. It is good to publish.
Thanks
Santosh P K
On Sat, Jul 22, 2023 at 4:18 AM Sam Aldrin wrote:
> Closing the last call for draft
> https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve-oam/
>
> Authors please address the comments
I am not aware of any IPR claims.
Thanks
Santosh P K
On Mon, Jul 24, 2023 at 10:44 AM Santosh P K
wrote:
> I have read the latest version of the document. It is good to publish.
>
> Thanks
> Santosh P K
>
> On Sat, Jul 22, 2023 at 4:18 AM Sam Aldrin wrote:
>
>> Clos
21 matches
Mail list logo
