Hello All,
New version of BFD multipoint document has been submitted. There are no
text change and it is only refresh.
Thanks
Santosh P K
-- Forwarded message --
From:
Date: Tue, Dec 12, 2017 at 10:17 AM
Subject: New Version Notification for draft-ietf-bfd-multipoint-11.txt
Hello All,
New version of BFD multipoint tail document has been submitted. There
are no text change and it is only refresh.
Thanks
-- Forwarded message --
From:
Date: Tue, Dec 12, 2017 at 10:30 AM
Subject: New Version Notification for
draft-ietf-bfd-multipoint-active-tail-05.t
I support for WG adoption.
On Thu, Dec 28, 2017 at 7:16 AM, Zhangmingui (Martin) <
zhangmin...@huawei.com> wrote:
> The use case is meaningful and the document is neatly organized. Support
> for adoption.
>
>
>
> Thanks,
>
> Mingui
>
>
>
> *From:* Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] *On Beh
As author of this draft I support this draft to. E adopted as working group
draft.
On Jan 20, 2018 5:31 AM, "Acee Lindem (acee)" wrote:
> Hi Jeff,
> I finally read this draft and support WG adoption (even though I’m NOT a
> fan of VXLAN, I realize it is a popular deployment scenario).
> Thanks,
I am not aware of any IPR.
On Jan 20, 2018 2:33 AM, "Dave Katz" wrote:
> I’m not aware of any relevant IPR.
>
> —Dave
>
> On Jan 16, 2018, at 4:03 PM, Reshad Rahman (rrahman)
> wrote:
>
>
>
> All,
>
> Are you aware of any IPR that applies to draft-ietf-bfd-multipoint and
> draft-ietf-bfd-multi
I am not aware of any IPR for this document.
Thanks
Santosh P K
On Mar 6, 2018 9:39 PM, "Mahesh Jethanandani"
wrote:
> I am not aware of any IPR related to this document.
>
> Mahesh Jethanandani
> mjethanand...@gmail.com
>
> > On Mar 6, 2018, at 6:47 AM, Jeffr
I am unaware of any IPR for this document.
On Fri, Oct 19, 2018, 12:33 PM Srihari Raghavan (srihari)
wrote:
> Read through the draft and support the same.
>
> Thanks
> Srihari
> -Original Message-
> From: Jeffrey Haas
> Sent: Thursday, October 18, 2018 03:44
> To: rtg-bf
Schwarz,
Just curious to know why do you have this use case? I mean why not use
CFM itself?
Thanks
Santosh P K
On Sat, Jun 8, 2019 at 2:17 PM Schwarz Albrecht (ETAS/ESY1) <
albrecht.schw...@etas.com> wrote:
> Thanks Sasha, Jeff & Stewart for your reply!
>
> OK, understood
VTEP mac
3. Inner IP TTL set to 1 to avoid forwarding of packet via inner IP
address.
Thoughts?
Thansk
Santosh P K
On Wed, Jul 31, 2019 at 9:20 AM Greg Mirsky wrote:
> Hi Dinesh,
> thank you for your consideration of the proposal and questions. What would
> you see as the scope of te
Joel,
Thanks for your inputs. I checked implementation within Vmware. Perhaps
I should have been more clear about MAC address space while checking
internally. I will cross check again for the same and get back on this
list.
Thanks
Santosh P K
On Wed, Jul 31, 2019 at 10:54 AM Joel M. Halpern
physical MAC address as inner MAC to ensure packets get terminated at VTEP
itself.
Thanks
Santosh P K
On Wed, Jul 31, 2019 at 11:00 AM Santosh P K
wrote:
> Joel,
>Thanks for your inputs. I checked implementation within Vmware. Perhaps
> I should have been more clear about MAC address sp
e able to demux packet. We need to consider
VNI as well if we have multiple BFD session between same pair of VTEP.
Thanks
Santosh P K
On Fri, Aug 9, 2019 at 4:27 AM Greg Mirsky wrote:
> Dinesh, thank you for your help, much appreciated.
>
> Hi Joel and Sridhar,
> could you please c
I support all three documents.
On Wed, Sep 11, 2019 at 9:22 AM Ashesh Mishra
wrote:
> As author, I support all three drafts.
>
> On Sep 10, 2019, at 7:13 PM, Manav Bhatia wrote:
>
> I support all 3 documents.
>
> On Tue, Aug 27, 2019 at 8:45 PM Jeffrey Haas wrote:
>
>> Working Group,
>>
>> As
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
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
>&
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
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
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
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
Hello,
Please see my inline comments tagged [SPK].
On Tue, Dec 17, 2019 at 1:35 PM Jürgen Schönwälder via Datatracker <
nore...@ietf.org> wrote:
> Reviewer: Jürgen Schönwälder
> Review result: Has Nits
>
> I have only a limited understanding of VXLAN and BFD technology.
> Hence, some of my q
Hello All,
A new version of draft for BFD-stablity is here for review. Changes
include addressing shepherd comments as provided here.
https://datatracker.ietf.org/doc/draft-ietf-bfd-stability/shepherdwriteup/.
Please also see attached diff.
Thanks
Santosh P K
-- Forwarded message
Reshad,
Thanks again. I will address these comments.
Thanks
Santosh P K
On Fri, Jul 24, 2020 at 8:13 AM Reshad Rahman (rrahman)
wrote:
> Hi Santosh,
>
>
>
> Thanks for addressing the comments.
>
>
>
> General: NULL authentication TLV is still used, sho
h a sedated interval. So not sure why you
mention it is not clear in RFC 5880.
Secondly if we do not need BFD async then it need not be BFD echo it can be
any packet which is has destination IP set to self IP can do that job isn't
it?
Thanks
Santosh P K
On Tue, Aug 4, 2020 at 6:34 PM Jeffre
Reshad,
>
>
>
> *From: *Rtg-bfd on behalf of "Reshad Rahman
> (rrahman)"
> *Date: *Thursday, July 23, 2020 at 10:43 PM
> *To: *Santosh P K , "rtg-bfd@ietf.org" <
> rtg-bfd@ietf.org>
> *Subject: *Re: New Version Notification for
> dr
I have refreshed stability draft. Diff from the previous version is
attached.
-- Forwarded message -
From:
Date: Thu, Jan 14, 2021 at 3:28 PM
Subject: New Version Notification for draft-ietf-bfd-stability-07.txt
To: Ankur Saxena , Ashesh Mishra <
mishra.ash...@gmail.com>, Mach Che
Hi Reshad,
Sure I will address these comments too.
Thanks
Santosh P K
On Sun, Jan 31, 2021 at 4:56 AM Reshad Rahman wrote:
> Hi Santosh,
>
>
>
> Thanks for making the changes and addressing my comments.
>
>
>
> Nits:
>
>1. Null was changed to NULL
yed
tuned.
> 4) How would this impact the scale of the BFD protocol?
Do you mean scale impact in steady state?
Thanks
Santosh P K
Marc,
Thanks for your comments. Draft was expiring and hence we updated draft
without any changes. This week we will upload document with changes we have
discussed.
Thanks
Santosh P K
sent from handheld device.
On May 3, 2015 7:27 AM, Marc Binderberger wrote:
Hello authors of BFD
Hello All,
A new BFD for VXLAN draft has been submitted. Please do review and get back
to us with any comments/feedback.
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
Sure. Will reissue the draft.
Thanks
Santosh P K
> -Original Message-
> From: Jeffrey Haas [mailto:jh...@pfrc.org]
> Sent: Tuesday, May 05, 2015 1:35 AM
> To: rtg-bfd@ietf.org; Santosh P K
> Subject: WG adoption of draft-spallagatti-bfd-multipoint-active-tail
>
Yes, support.
Thanks
Santosh P K
> -Original Message-
> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Tuesday, May 05, 2015 1:51 AM
> To: rtg-bfd@ietf.org
> Subject: WGLC for draft-ietf-bfd-seamless-base
>
> Working Group,
>
Support.
> -Original Message-
> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Tuesday, May 05, 2015 5:50 AM
> To: rtg-bfd@ietf.org
> Subject: WGLC-redeux for draft-ietf-bfd-seamless-use-case (was Re: Mail
> regarding draft-ietf-bfd-seamless-use-case)
>
Support.
> -Original Message-
> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Tuesday, May 05, 2015 1:54 AM
> To: rtg-bfd@ietf.org
> Subject: WGLC for draft-ietf-bfd-seamless-ip
>
> Working Group,
>
> This begins a two week Working Group Last Call for
ix typos in the document.
Hmmm I did this exercise :) will do it again.
Thanks
Santosh P K
> -Original Message-
> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Santosh P K
> Sent: Monday, May 04, 2015 10:55 PM
> To: rtg-bfd@ietf.org
> Subject: FW: Ne
e can discuss on this point.
Thanks
Santosh P K
> -Original Message-
> From: Santosh P K [mailto:santos...@juniper.net]
> Sent: Wednesday, May 06, 2015 11:08 AM
> To: Vengada Prasad Govindan (venggovi); rtg-bfd@ietf.org
> Subject: RE: New Version Notification for draft-spa
uot;1"
>in the draft.
VM's will use normal Async BFD so will use TTL 255.
>6. Since we are using a destination UDP port of 3784, shouldn't the TTL be 255
>to be consistent with the RFC 5880?
Section 7 of RFC 5884 also mentions use of IP TTL set to 1 whereas UDP port
Hello All,
I have republished BFD multipoint active tail document as suggested by
chairs without any changes in text. Please do review and get back to me with
any comments/feedback.
Thanks
Santosh P K
> -Original Message-
> From: internet-dra...@ietf.org [mailto:intern
Hello All,
New version of BFD multipoint has been published. Changes includes as below.
1. Corrected references in the document.
2. Addressed review comments given by Nobo.
Please review new version and get back with comments/feedback.
Thanks
Santosh P K
> -Original Mess
Hello Greg, Prasad and MALLIK,
Thanks for review comments. I will go through your review comments and get
back on this in some time.
Thanks
Santosh P K
From: Gregory Mirsky [mailto:gregory.mir...@ericsson.com]
Sent: Saturday, May 09, 2015 10:16 AM
To: Vengada Prasad Govindan (venggovi
I am not aware for IPR related to S-BFD documents.
Thanks
Santosh P K
> -Original Message-
> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Thursday, May 21, 2015 7:30 PM
> To: rtg-bfd@ietf.org
> Subject: Status of WGLCs
>
> The
> Please suggest your thoughts on making the above text better.
Thanks
Santosh P K
> -Original Message-
> From: Vengada Prasad Govindan (venggovi) [mailto:vengg...@cisco.com]
> Sent: Wednesday, May 20, 2015 6:12 PM
> To: Santosh P K; draft-ietf-bfd-rfc5884-clarificat
> to be VxLAN encapsulated?
BFD packet should not be routed and hence the use of non-routable address in
inner IP address. With the help of VXLAN header (VNI) we should be able to
associate the BFD packet with a tunnel.
Thanks
Santosh P K
> -Original Message-
> From: S
over the same tunnel?
I do not see a case where we need multiple BFD session between IP pair when BFD
session terminates at VTEP itself.
Thanks
Santosh P K
-Original Message-
From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Vengada Prasad
Govindan (venggovi)
Sent: Frid
comments.
Thanks
Santosh P K
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Wednesday, June 10, 2015 2:19 PM
> To: Mach Chen; Ankur Saxena; Mahesh Jethanandani; Santosh P K; Santosh P
> K; Ankur Saxena; Ashesh Mishra; Peng
Jeff,
I have BFD over VXLAN to present in coming IETF. I have plans presenting
this both in Nov3 and BFD working group.
Thanks
Santosh P K
> -Original Message-
> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Tuesday, June 16, 2015 3:3
should put in more
details on this. The whole purpose of using AUTH TLV for this mechanism is
because we want this to work along with normal authentication. I will add more
text on how auth and this mechanism can work together.
Thanks
Santosh P K
>
> -- Jeff
>
>
packet need not carry any
timestamp. Did I answer your question?
Thanks
Santosh P K
From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudi...@cisco.com]
Sent: Friday, June 12, 2015 2:03 PM
To: Santosh P K; rtg-bfd@ietf.org
Subject: Re: New Version Notification for draft-ashesh-bfd-stability-03.txt
Hi,
I
I have read the latest revision document and I support this draft to move
forward.
Thanks
Santosh P K
> -Original Message-
> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of internet-
> dra...@ietf.org
> Sent: Tuesday, June 16, 2015 8:36 PM
> To: i-d-annou..
ience, I agree this is perhaps very useful.
>
Yes, we have not got much attention in NVO3 WG.
Thanks
Santosh P K
unning proactive OAM between NV edge to NV edge
per VNI. This is an individual draft for now.
Thanks
Santosh P K
> -Original Message-
> From: Shahram Davari [mailto:dav...@broadcom.com]
> Sent: Thursday, June 25, 2015 8:18 PM
> To: Santosh P K; Gregory Mirsky; Vengada Pras
ddress that part.
Thanks
Santosh P K
>
> -Original Message-
> From: Gregory Mirsky [mailto:gregory.mir...@ericsson.com]
> Sent: Monday, June 29, 2015 1:51 PM
> To: Shahram Davari; Vengada Prasad Govindan (venggovi)
> Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K
ress so that BFD can be forwarded to VM from VTEP.
>
We are not trying to address VM to VM connectivity check as I believe that does
not really need any changes and BFD as it is should run. Proposal is from VTEP
to VTEP.
Thanks
Santosh P K
> -Original Message-
> From: Rtg-
There can be few VTEPs who might have capabilities to multicast the packet. In
such a scenario VTEP will send that packet to service node and service node
will do a multicast on its behalf.
Thanks
Santosh P K
From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of S. Davari
Sent: Monday
-DA would
be MAC of the destination VTEP or dedicated MAC address.
Thanks
Santosh P K
> -----Original Message-
> From: Santosh P K [mailto:santos...@juniper.net]
> Sent: Tuesday, June 30, 2015 2:13 AM
> To: Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggo
Shahram,
> You can do (1) today. Why do you need a standard?
>
1) with BFD terminating on VTEP needs changes. For example how a BFD is demuxed
when it comes with your_disc = 0. What should be inner MAC-DA, inner dst-IP
changes. So we need to specify in document.
Thanks
Santo
s what we are talking
about in the draft, maybe we are much more clear in the next version of the
draft which will be published soon.
Thanks
Santosh P K
>
> -Original Message-
> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Shahram
> Davari
> Sent:
e a unicast communication right?
Thanks
Santosh P K
From: Shahram Davari [mailto:dav...@broadcom.com]
Sent: Wednesday, July 01, 2015 6:55 AM
To: Santosh P K; S. Davari; rtg-bfd@ietf.org
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt
Santosh,
Is the BFD you
h is talking more about those. Will publish the second version of
draft in couple of days.
Thanks
Santosh P K
>
>
>
> >
> > -Original Message-
> > From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Shahram
> > Davari
> > Sent:
Hello All,
We had a good discussion on this draft earlier in WG. We have addressed
few comments that we discussed and have republished the draft. Please get back
with more review comments.
Thanks
Santosh P K
> -Original Message-
> From: internet-dra...@ietf.org [mailto:in
Nobo and Sharram,
I am bit confused did you mean MAC-DA of the receiver VTEP? How would
sender VTEP solve the problem?
Thanks
Santosh P K
From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of S. Davari
Sent: Friday, July 10, 2015 6:52 PM
To: Nobo Akiya
Cc: Reshad Rahman (rrahman
/html/rfc5880#section-6.3
We don’t need to really use any other fields as we would have exchanged the
discr using LSP ping. I might have misunderstood your question and would like
to be corrected.
Thanks
Santosh P K
From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of
peng.sha
Sharam,
True but here it is 5884 and for 5884 (MPLS BFD) we do bootstrapping using
LSP ping and that exchange discr right? So you should ideally not receive any
BFD packet with your_disc = 0.
Thanks
Santosh P K
From: S. Davari [mailto:davar...@yahoo.com]
Sent: Friday, July 17, 2015 9:51 AM
discr for BFD
session for same LSP in case of ECMP? Can you please explain more in detail
what is the scenario? I might have missed some basic thing here.
Thanks
Santosh P K
From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudi...@cisco.com]
Sent: Friday, July 17, 2015 10:45 AM
To: Santosh P K; S
Hmm ok so this question is during bootstrapping time when LSP ping echo packet
is received with BFD discriminator TLV not when BFD packet is received. In that
case source IP address can be used.
Thanks
Santosh P K
From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
Sent: Friday, July
A new version of multipoint BFD has been submitted. No technical changes are
made, only acknowledgments section has been added.
Thanks
Santosh P K
> -Original Message-
> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of internet-
> dra...@ietf.org
> Sent: Wedne
ng on this and see if we reach any conclusion.
>
>
> For the document, you are a bit short on the motivation side, IMHO. Saying
> "Main use case of BFD for VXLAN is for tunnel connectivity check. There are
> other use cases such as [...]" and then saying more about th
Jeff,
I think " draft-ymbk-idr-rs-bfd " already a working group document?
Thanks
Santosh P K
> -Original Message-
> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Saturday, September 19, 2015 2:16 AM
> To: rtg-bfd@ietf.
Jeff,
We would like to present BFD VXLAN. This has not been presented in any of
the WG till now.
Thanks
Santosh P K
> -Original Message-
> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Friday, October 02, 2015 11:15 PM
> To: rtg-
s a key to identify initial BFD
packet.
Thanks
Santosh P K
From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Gregory Mirsky
Sent: Tuesday, November 03, 2015 7:57 AM
To: rtg-bfd@ietf.org
Subject: Multiple BFD sessions between the same pair of end-points
Dear All,
I think that this para
BFD session for an
interface. The case where we are struggling in Yang is for multihop BFD
session.
Thanks
Santosh P K
From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Gregory Mirsky
Sent: Tuesday, November 03, 2015 7:57 AM
To: rtg-bfd@ietf.org
Subject: Multiple BFD sessions
Carlos,
OOB for multihop is not there and it is out of scope of RFC. Having said that
there are bunch of extension to IGP already which carries BFD discriminator
which could be leveraged for OOB for MH BFD session.
Thanks
Santosh P K
From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of
New version of multipoint tail document has been updated. There has been no
change in the content of this draft. Please go get back if there are any review
comments.
Thanks
Santosh P K
> -Original Message-
> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of internet-
Reshad,
I have read this document and I do support this document. But I think there
are few things to consider in this document. It needs to clearly highlight how
to handle interval change from non-aggressive interval to aggressive interval.
Thanks
Santosh P K
From: Rtg-bfd [mailto:rtg-bfd
ate the AUTH and when to start again may be with P/F negotiation?
Thanks
Santosh P K
From: Mahesh Jethanandani [mailto:mjethanand...@gmail.com]
Sent: Wednesday, November 25, 2015 11:06 PM
To: Santosh P K
Cc: Reshad Rahman (rrahman) ; rtg-bfd@ietf.org;
draft-mahesh-bfd-authenticat...@ietf.
Alvaro,
Please see my inline comments tagged [SPK]. I will send diff and updated
draft after all the received review comments are addressed.
Thanks
Santosh P K
> -Original Message-
> From: Alvaro Retana (aretana) [mailto:aret...@cisco.com]
> Sent: Tuesday, December 08,
Marc,
Thanks for your valuable comments :). Please see my inline comments tagged
[SPK].
Thanks
Santosh P K
> -Original Message-
> From: Marc Binderberger [mailto:m...@sniff.de]
> Sent: Monday, December 14, 2015 1:33 PM
> To: Alvaro Retana ; Santosh P K
> ; draft-ietf
Hello All,
I will be using my alternative mail id for IETF communications. Please use
santosh.pallaga...@gmail.com for further communication.
Thanks
Santosh P K
support.
On Tue, Apr 18, 2017 at 7:07 AM, Manav Bhatia wrote:
> Support
>
> --
> Sent from a mobile device
>
> On Apr 18, 2017 3:02 AM, "Jeffrey Haas" wrote:
>
>> Working Group,
>>
>> https://tools.ietf.org/html/draft-ashesh-bfd-stability-05
>>
>> The authors of BFD Stability (draft-ashesh-bfd-
Hello All,
Sorry for delay in refreshing multi point tail document. There is no
change in the text.
Thanks
Santosh P K
-- Forwarded message --
From:
Date: Tue, Apr 25, 2017 at 12:42 PM
Subject: New Version Notification for draft-ietf-bfd-multipoint-
active-tail-04.txt
To
Hello All,
Refresh of BFD multipoint document. There is no change in text.
Thanks
Santosh P K
-- Forwarded message --
From:
Date: Tue, Apr 25, 2017 at 12:53 PM
Subject: New Version Notification for draft-ietf-bfd-multipoint-10.txt
To: Dave Katz , David Ward , Santosh
Hello Carlos,
Thanks for your review comments. Please see inline [SPK].
Thanks
Santosh P K
On Tue, Jun 27, 2017 at 8:26 PM, Carlos Pignataro (cpignata) <
cpign...@cisco.com> wrote:
> Just one comment on these two documents, in regards to the state
> variables:
>
> http
Hello Greg,
Thanks for your comments. Please see my reply inline tagged[ SPK].
Thanks
Santosh P K
On Tue, Jul 4, 2017 at 1:02 AM, Greg Mirsky wrote:
> Dear Authors, WG chairs, et. al,
> please kindly consider my comments to the latest version of the draft as
> part of WGLC:
>
I read it as Local discriminator assigned for a BDS session is optional in
echo reply that is being sent in response to LSP ping echo. I don't think
RFC 5884 is not talking about echo reply being optional.
Thanks
Santosh P K
On Sun, Jul 16, 2017 at 7:28 PM, Mach Chen wrote:
> Hi BFDers
I am not aware of any IPR.
Thanks
Santosh P K
On Tue, Mar 4, 2025 at 3:56 PM Reshad Rahman wrote:
> I am not aware of any IPR on these 3 documents.
>
> Regards,
> Reshad,
>
> On Tuesday, March 4, 2025 at 10:51:59 AM GMT+4, Reshad Rahman 40yahoo@dmarc.ietf.org> wrot
87 matches
Mail list logo
