Re: [Technical Errata Reported] RFC5884 (5085)

l packets to the ingress LSR with the Your Discriminator field* > > * set to the local discriminator of the ingress LSR. The ingress LSR* > > * uses this to demultiplex the BFD session.* > > > > * The egress LSR follows the procedures defined in [RFC 8029] to > d

Re: [Technical Errata Reported] RFC5884 (5085)

t; As some of the co-authors have clarified in further emails, inclusion of > BFD discriminator in the LSP-Ping request does not change LSP-Ping’s basic > function. So, the egress must send a reply. This is what the erratum > clarifies. > > > > -- > > Balaji Rajagopalan &g

Re: [Technical Errata Reported] RFC5884 (5085)

Control packets to the ingress LSR with the Your Discriminator field* > > * set to the local discriminator of the ingress LSR. The ingress LSR* > > * uses this to demultiplex the BFD session.* > > > > * The egress LSR follows the procedures defined in [RFC 8029

Re: [Technical Errata Reported] RFC5884 (5085)

ursday, 17 August 2017 at 8:45 AM > *To: *"Carlos Pignataro (cpignata)" , Balaji > Rajagopalan , Greg Mirsky , > Jeffrey Haas > *Cc: *Kireeti Kompella , Thomas Nadeau < > tnad...@lucidvision.com>, "rtg-bfd@ietf.org" , "Reshad > Rahman (rrahman)&q

Re: draft-nitish-vrrp-bfd

Hi Thibault, thank you for your interest in the draft, much appreciated. Please don't be discouraged that it lapsed, we can fix it easily. I think that authors had similar to your idea when we've started thinking about BFD supporting VRRP. And like you we haven't found any reference in existing doc

Re: draft-nitish-vrrp-bfd

t; > https://www.google.com/patents/US20170005915 > > > > We are going to submit a draft with the p2p BFD so that we can continue > working on the Draft. > > There was lot of interest last time as well, just because of the IPR claim > we had stopped the work. >

Re: [Technical Errata Reported] RFC5884 (5085)

RFC to comment/decide whether BFD-disc > can be removed from the reply. > > - Rules to specify handling of mismatch between BFD-disc in the > LSP-Ping reply & the BFD session > > > > -- > > Balaji Rajagopalan > > > > > > *From: *Gre

Fwd: New Version Notification for draft-mirsky-bfd-p2mp-vrrp-use-case-01.txt

com> A new version of I-D, draft-mirsky-bfd-p2mp-vrrp-use-case-01.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-bfd-p2mp-vrrp-use-case Revision: 01 Title: Bidirectional Forwarding Detection (BFD) for Multi

Re: [Technical Errata Reported] RFC5884 (5085)

Greg I am not so sure about. > > > >Les > > > > > > *From:* Kireeti Kompella [mailto:kire...@juniper.net] > *Sent:* Wednesday, October 04, 2017 12:06 PM > *To:* Les Ginsberg (ginsberg) ; Mach Chen < > mach.c...@huawei.com>; Carlos Pignataro (cpignata) ;

Fwd: New Version Notification for draft-spallagatti-bfd-vxlan-06.txt

agatti < santosh.pallaga...@gmail.com> A new version of I-D, draft-spallagatti-bfd-vxlan-06.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-spallagatti-bfd-vxlan Revision: 06 Title: BFD for VXLAN Document date: 2017

Fwd: New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt

anh...@zte.com.cn> A new version of I-D, draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-mpls-bfd-bootstrap-clarify Revision: 00 Title: Clarifying Use of LSP Ping to Bootstr

Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt

Pignataro, car...@cisco.com > > *“Sometimes I use big words that I do not fully understand, to make myself > sound more photosynthesis."* > > On Oct 18, 2017, at 8:50 AM, Greg Mirsky wrote: > > Dear All, > this new document proposes clarification of two questio

Fwd: New Version Notification for draft-mirsky-bfd-mpls-demand-02.txt

has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-bfd-mpls-demand Revision: 02 Title: BFD in Demand Mode over Point-to-Point MPLS LSP Document date: 2017-10-23 Group: Individual Submission Pages: 5 URL

Updates to draft-mirsky-bfd* drafts.

Dear All, updated versions of drafts first presented in Prague have been published: - BFD in Demand Mode over Point-to-Point MPLS LSP - Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPL

Re: Service Redundancy using BFD

Hi Ankur, usually this problem, as I understand it from the document, is handled by the special protection coordination protocol as, for example, in RFC 6378 or G.8031. PSC or APS reflect roles of working and protecting paths and communicate over the protecting path. Regards, Greg On Mon, Nov 27

Re: Service Redundancy using BFD

Hi Ashesh, I believe that the abstract of RFC 5880 is very clear of what is the goal of BFD: This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding

Re: Service Redundancy using BFD

e. This notification will allow > non-preemptive services to continue to run on the node that didn’t fail. > > Thanks, > > Sami > From: Greg Mirsky > Date: Tuesday, November 28, 2017 at 8:16 AM > To: Ankur Dubey > Cc: "rtg-bfd@ietf.org" , Reshad Rahman < >

Re: Service Redundancy using BFD

Hi Sami, would C have BFD sessions to A and B respectively or it use anycast address? The more I look at the use case, the more I think of VRRP ;) Regards, Greg On Tue, Nov 28, 2017 at 2:15 PM, Sami Boutros wrote: > > Hi Ashesh, > > The topology is more like the following: > > A <—\ > |

Re: Service Redundancy using BFD

the link to C using any mechanisms not only BFD. > > The picture below is for illustration, A and B themselves can be providing > services (L4 to L7), this could include Firewall, NAT, LoadBalancer etc.. > > Thanks, > > Sami > From: Greg Mirsky > Date: Tuesday, November 28, 2017

Re: Service Redundancy using BFD

> > > I agree with you that 5880 was clear in its scope at the time, but that > should not inform the entire scope of BFD in the future. > > > > Ashesh > > > > *From: *Greg Mirsky > *Date: *Tuesday, November 28, 2017 at 5:06 PM > *To: *Ashesh Mishra > *

Fwd: New Version Notification for draft-mirsky-spring-bfd-03.txt

t-mirsky-spring-bfd-03.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-spring-bfd Revision: 03 Title: Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane Document d

Re: IPR call for draft-nitish-vrrp-bfd-p2p

Dear Chris, et. al, as co-author I'm not aware of any IPR that is applicable to the current version of draft-nitish-vrrp-bfd-p2p. Regards, Greg On Thu, Dec 14, 2017 at 10:44 AM, Chris Bowers wrote: > RTGWG, > > draft-nitish-vrrp-bfd-p2p is currently an individual draft. Before > conducting > a

Re: [Technical Errata Reported] RFC5884 (5085)

> Deborah > > > > > > *From:* Kireeti Kompella [mailto:kire...@juniper.net] > *Sent:* Wednesday, December 13, 2017 3:54 PM > *To:* BRUNGARD, DEBORAH A > *Cc:* Balaji Rajagopalan ; Greg Mirsky < > gregimir...@gmail.com>; Jeffrey Haas ; Carlos Pignataro > (cpignata) ; g

Re: WGLC for BFD Multipoint documents (last round)

ressed: > https://www.ietf.org/mail-archive/web/rtg-bfd/current/msg03475.html > > Thanks, > > Sent from my iPad > > On Dec 15, 2017, at 5:15 PM, Greg Mirsky wrote: > > Dear All, > attached please find diffs and the updated version of the > draft-ietf-bfd-multipoint

Re: Service Redundancy using BFD

But please keep in mind that we are > proposing 2 aspects here as mentioned above, and we feel the out-lived > aspect in the diag field will be a very handy feature that can help > redundancy. > > Thanks, > > Sami > > > > >-- Jeff > > > > > >On Tue, Nov 2

Re: [Technical Errata Reported] RFC7880 (5211)

ollowing errata report has been submitted for RFC7880, > "Seamless Bidirectional Forwarding Detection (S-BFD)". > > -- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5211 > > --

BFD WG Call For Adoption draft-spallagatti-bfd-vxlan

Hi Jeff, Reashad, et. al,as co-author I support the adoption of draft-spallagatti-bfd-vxlan. Happy New Year to All! Regards,Greg The BFD WG has placed draft-spallagatti-bfd-vxlan in state "Call For Adoption By WG Issued" IETF Secretariat Thu, 21 December 2017 15:15 UTCShow header

Re: WG adoption poll for draft-nitish-vrrp-bfd-p2p

Hi, yes/support as co-author. Regards, Greg On Wed, Jan 10, 2018 at 1:23 PM, Chris Bowers wrote: > RTGWG, > > This email starts the two week WG adoption poll for > draft-nitish-vrrp-bfd-p2p. > > https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd-p2p/ > > Please indicate whether you support

Re: WGLC for BFD Multipoint documents (last round)

frc.org> wrote: > > Greg, > > On Tue, Dec 19, 2017 at 02:17:02PM -0800, Greg Mirsky wrote: > > Hi Carlos and Jeff, > > thank you for responding so expediently. I think we've reached the > rough > > consensus. Attached are the diffs for

Re: WGLC for BFD Multipoint documents (last round)

ing if instead it should be removed > from MP draft (always 1 in there) and kept as new state variable in > active-tail? > > > > Regards, > > Reshad. > > > > *From: *"Reshad Rahman (rrahman)" > *Date: *Tuesday, January 16, 2018 at 9:32 AM

Re: WGLC for BFD Multipoint documents (last round)

ahman (rrahman) wrote: > Hi Greg, > > > > I am fine with the change below. > > > > Regards, > > Reshad. > > > > *From: *Greg Mirsky > *Date: *Tuesday, January 16, 2018 at 2:20 PM > *To: *"Reshad Rahman (rrahman)" > *Cc: *"Carlos P

Re: IPR poll for multipoint drafts

Hi Reshad, I'm not aware of any IPR related either to draft-ietf-bfd-multipoint or draft-ietf-bfd-multipoint-active-tail. Regards, Greg On Tue, Jan 16, 2018 at 3:03 PM, Reshad Rahman (rrahman) wrote: > > > > > All, > > > > Are you aware of any IPR that applies to draft-ietf-bfd-multipoint and

Re: WGLC for BFD Multipoint documents (last round)

> For the active-tail draft I haven’t completed my review of -06 yet: there > are parts which aren’t clear to me and I don’t know yet if this is because > there’s something missing in the document or whether it’s just lack of > understanding on my part. > > > > Regards, > >

Re: WGLC for BFD Multipoint documents (last round)

forgot to mention that last week I did the shepherd write-up for both > drafts. > > > > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ > shepherdwriteup/ > > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint- > active-tail/shepherdwriteup/ > > > > Regar

Re: WGLC for BFD Multipoint documents (last round)

ever to indicate a change in the packets, >MultipointHead sessions MUST send packets with the P bit set. >MultipointTail sessions/ > > GIM2>> Or should it be 'However, to indicate a change in the packets, MultipointHead MUST send packets with the P bit set.'? &

Re: WGLC for BFD Multipoint documents (last round)

“MUST send packets with *the* P bit set.”? > > > > Regards, > > Reshad. > > > > *From: *Greg Mirsky > *Date: *Saturday, January 27, 2018 at 11:38 PM > > *To: *"Reshad Rahman (rrahman)" > *Cc: *"Carlos Pignataro (cpignata)" , Jeffrey Haas &l

Re: WGLC for BFD Multipoint documents (last round)

thors : Dave Katz Dave Ward Santosh Pallagatti Greg Mirsky Filename: draft-ietf-bfd-multipoint-13.txt Pages : 18 Date: 2018-01-30 Abstract: This doc

Re: WGLC for BFD Multipoint documents (last round)

eshad Rahman (rrahman) wrote: > Hi Greg, > > Please see inline . > > Regards, > Reshad. > > > On 2018-01-30, 10:47 PM, "Greg Mirsky" wrote: > > Hi Reshad, > thank you for your detailed review of > draft-ietf-bfd-multipoint-active-tail and c

Re: WGLC for BFD Multipoint documents (last round)

ound on the > number of MultipointTail sessions that can be created, with the > upper bound potentially being computed based on the number of > multicast streams that the system is expecting. > > On 2018-01-30, 10:23 PM, "Greg Mirsky" wrote: > > Hi Reshad, e

Re: WGLC for BFD Multipoint documents (last round)

rote: > > Hi Reshad, > > thank you for your consideration. I've came across what looks as simple > editorial change. Appreciate your comment. > > In the second paragraph of section 4.8 Packet consumption on tails the > following > > For multipoint LSPs, wh

Re: IPR call for draft-mirsky-bfd-p2mp-vrrp-use-case

Hi Chris, et. al, I'm co-author of the draft-mirsky-bfd-p2mp-vrrp-use-case. In regard to the IPR related to this draft I'd like to note: - I don't know of any other IPR On Tue, Feb 20, 2018 at 8:36 AM, Chris Bowers wrote: > RTGWG, > > draft-mirsky-bfd-p2mp-vrrp-use-case is currently an indi

Re: IPR call for draft-mirsky-bfd-p2mp-vrrp-use-case

Apologies for sending it unfinished. Please see below. On Tue, Feb 20, 2018 at 8:59 AM, Greg Mirsky wrote: > Hi Chris, et. al, > I'm co-author of the draft-mirsky-bfd-p2mp-vrrp-use-case. In regard to > the IPR related to this draft I'd like to note: > >- I don

Re: Call for topics - IETF 101, London

Hi Jeff, Reshad, et. al, thank you for the opportunity to present and discuss new BFD works in London. I'd like to propose the following topics: - use of BFD Demand mode in BFD over MPLS p2p LSP (based on draft-mirsky-bfd-mpls-demand); - non-IP encapsulation of BFD control packet over p2m

Re: IPR declarations for draft-ietf-bfd-yang

I am not aware of any IPR related to this document. Regards, Greg On Tue, Mar 6, 2018 at 6:47 AM, Jeffrey Haas wrote: > As part of the shepherd writeup, we're required to confirm whether or not > there are any IPR disclosures on the BFD Yang module. > > Authors, please respond to this thread, c

Couple questions on draft-chen-bfd-unsolicited

Dear Authors, thank you for bringing your proposal to the discussion at BFD meeting in London. I have couple questions: - which BFD mode, Asynchronous or Demand, you envision to be used by the Unsolicited BFD; - if you consider the Demand mode to be used by the active BFD peer from the

Some questions on the BFD Performance draft

Dear Authors, I've read the new draft and have some questions that I would like us to discuss: - which of BFD modes, Async, Demand or Echo, you envision to be used by this new TLV; - what interval between the BFD control packets with BFD Performance TLV would you use; - the BFD Perf

Couple comments on draft-ali-spring-bfd-sr-policy

Dear Authors, I've read the new draft and would appreciate your consideration of my comments and questions: - if I understand correctly, you prefer using S-BFD in SR domain over use of the base BFD. Without arguing with your choice, I'll note that the title of the draft doesn't reflect yo

Re: [internet-dra...@ietf.org: I-D Action: draft-haas-bfd-large-packets-00.txt]

Hi Jeff, thank you for bringing up for discussion this interesting proposal. A question and a comment ahead of the meeting to save us time: - which applications will benefit from monitoring path MTU (PMTU) rather from using PMTU discovery and updating the value; - note that "The Don't Fra

Re: Couple comments on draft-ali-spring-bfd-sr-policy

ar 20, 2018 at 4:42 PM, Ketan Talaulikar (ketant) wrote: > Hi Greg, > > > > Thanks for your review and comments. Please check inline below for > responses. > > > > > > *From:* Greg Mirsky > *Sent:* 20 March 2018 08:57 > *To:* draft-ali-spring-bfd-sr-pol...@i

Re: Couple comments on draft-ali-spring-bfd-sr-policy

levant to other > signalled circuits and TE paths like RSVP-TE or MPLS-TP, but they do not > seem appropriate for SR Policies to me. > > > > Thanks, > > Ketan > > > > *From:* Greg Mirsky > *Sent:* 20 March 2018 16:58 > *To:* Ketan Talaulikar (ketant) >

Re: Couple comments on draft-ali-spring-bfd-sr-policy

; > There is no change in BFD mechanism proposed at all but still appreciate > the viewpoints of the BFD WG on this debate. However, the authors of > draft-ali-spring-bfd-sr-policy request that the analysis be done with SR > architecture in mind and not just bringing in concepts fr

Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt

t still don’t see how it > can cause any harm, and any implementation which interprets the > discriminator in the echo reply differently is buggy IMHO. > > > > Regards, > > Reshad (hat off). > > > > *From: *Rtg-bfd on behalf of "Reshad Rahman > (rrahman)" > *

Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt

pecifying. Are you aware of any > implementation attempting to do that? > > > > There’s no text for that comparison – why would an implementation do that? > > > > Thanks, > > > > Carlos. > > > > *From: *Greg Mirsky > *Date: *Thursday, March 22, 2018 at 12:18 P

Re: IETF 101 - draft minutes

Kudos to the notetaker who braved the technical obstacles and masterfully captured all the details of the discussions that at times we quite fast paced. Regards, Greg On Wed, Mar 28, 2018 at 6:47 PM, Jeffrey Haas wrote: > Working Group, > > The draft minutes have been uploaded to the data track

Re: WGLC BFD Authentication Drafts

Dear WG Chairs, et. al, I cannot support WG LC for draft-ietf-bfd-optimizing-authentication as my comments at BFD WG meeting dating back to IETF-98 still not have been addressed nor even there was an attempt to address. As I've a

Re: Tuning BFD session times

Hi Asheh, thank you for very detailed explanation of the scenarios that had motivated this work. Couple questions to help me better understand the use cases: - if understand the first scenario, you propose to use BFD to measure the propagation delay as it is the main component that influence

Re: WGLC BFD Authentication Drafts

Hi Asheh, thank you for taking time to review the minutes from BFD WG meeting at IETF-98. I don't think that we had enough time to discuss in details my question: Greg Mirsky: One of the possible modes when the session is up is to use authentication with periodic timer trigger? I'd bre

Re: Tuning BFD session times

would not be advisable. I believe that active measurement methods allow reasonably accurate measurements that can be properly interpreted based on representative statistics of test sessions. Alternatively, hybrid measurement methods, e.g. Alternate Marking, may be used. > > Cheers. > > &g

Re: WGLC BFD Authentication Drafts

esolved in the definitive manner > before the draft moved to WGLC.* > > > > *[AM] This line should be removed and the preceding text should indicate > that the parameters for authentication should be configured on the session > end-points. * > > > > Regards, > Ashesh > &g

Re: WGLC BFD Authentication Drafts

gt; followed by a stream of unauthenticated frames. > > > > Hope that addresses the gap that you presented. > > > > Ashesh > > > > *From: *Greg Mirsky > *Date: *Tuesday, April 3, 2018 at 8:35 PM > > *To: *Ashesh Mishra > *Cc: *Jeffrey Haas , "rtg-bfd@

Re: AD review of draft-ietf-bfd-multipoint-14

Hi Martin, thank you for your thorough review, thoughtful comments and kind words. Please find my answers to your questions in-line and tagged GIM>>. Regards, Greg On Tue, Apr 17, 2018 at 8:06 AM, Martin Vigoureux < martin.vigour...@nokia.com> wrote: > [resend, wrong bfd wg address in first atte

Re: AD review of draft-ietf-bfd-multipoint-14

pdate whenever you can. > Thx > > -m > > > Le 2018-04-17 à 20:40, Greg Mirsky a écrit : >> >> Hi Martin, >> I have not ignored that comment but missed to ack its acceptance. Two >> other outstanding questions: >> >> * the text, that I've misin

Re: AD review of draft-ietf-bfd-multipoint-14

the session is created, according to the rules in Section 4.13 > I might have parsed 4.13 (and subsections) too quickly but I did not find > any rule regarding the initalization of this variable. Is that indeed the > case? If so then I would suggest to simply remove the pointer. > >

Fwd: New Version Notification for draft-ietf-bess-mvpn-fast-failover-03.txt

8:24 AM Subject: New Version Notification for draft-ietf-bess-mvpn-fast-failover-03.txt To: Gregory Mirsky , Thomas Morin < thomas.mo...@orange-ftgroup.com>, Robert Kebler A new version of I-D, draft-ietf-bess-mvpn-fast-failover-03.txt has been successfully submitted by Greg Mirsky and

Re: WGLC BFD Authentication Drafts

ext in the draft to suggest tracking the number of > consecutive discarded authentication frames. When that counter hits the > detect multiplier, the session is marked oper-down. Is that a more > reasonable solution? > > > > Ashesh > > > > *From: *Greg Mirsky

Re: RtgDir review: draft-ietf-bfd-multipoint-16

Now with corrected BFD WG list. On Mon, May 14, 2018 at 11:15 AM, Greg Mirsky wrote: > Hi Michael, > thank you for your thorough review, thoughtful and detailed comments and > suggestions. > Please find my answers, notes in-line tagged GIM>>. > > Regards, > Greg >

Re: RtgDir review: draft-ietf-bfd-multipoint-16

Hi Michael, thank you for the most expedient response. Both updates are in the new working version. Regards, Greg On Mon, May 14, 2018 at 3:58 PM, Michael Richardson wrote: > > Greg Mirsky wrote: > > The text that follows the first sentence in section 4.13.1 is the > &

Fwd: New Version Notification for draft-mirsky-bfd-p2mp-vrrp-use-case-02.txt

Jeff Tantsura < jefftant.i...@gmail.com> A new version of I-D, draft-mirsky-bfd-p2mp-vrrp-use-case-02.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-bfd-p2mp-vrrp-use-case Revision: 02 Title: Bidirectional

Re: RtgDir review: draft-ietf-bfd-multipoint-16

If so, please clarify this in the doc; if not, please correct me. > > Thanks > -m > > Le 2018-05-15 à 1:09, Greg Mirsky a écrit : > >> Hi Michael, >> thank you for the most expedient response. Both updates are in the new >> working version. >> >> Reg

Re: [Tsv-art] Tsvart last call review of draft-ietf-bfd-multipoint-16

#x27;t usually comment on them while > the authors and reviewers are still chatting. But, on one point ... > > On Tue, May 29, 2018 at 5:23 AM Bob Briscoe wrote: > >> Greg, >> >> On 26/05/18 20:49, Greg Mirsky wrote: >> > > [snip] > >> NEW TEXT:

Re: Tsvart last call review of draft-ietf-bfd-multipoint-16

Hi Bob, thank you for further clarifications and the new ideas. Please find my follow-up in-line and tagger GIM2>>. I'll check for nits and grammar and will publish the new version shortly. Regards, Greg On Tue, May 29, 2018 at 3:22 AM, Bob Briscoe wrote: > Greg, > > >

Re: Tsvart last call review of draft-ietf-bfd-multipoint-16

uld be better to switch the order of the paras. > > > Otherwise, I think my comments are becoming increasingly less useful, so > I'll stop. I don't know enough about the whole ecosystem around this draft > to be any more helpful, I think. > > > Bob > > > O

Re: [IANA #1112479] Last Call: (BFD Multipoint Active Tails.) to Proposed Standard

With corrected BFD WG address. On Sun, Jun 17, 2018 at 5:57 PM, Greg Mirsky wrote: > Hi Sabrina, > thank you for the review of the draft. Indeed, no IANA actions requested > in this specification. We'll keep the IANA Considerations section in place > upon publication if RFC

Re: [Tsv-art] Tsvart last call review of draft-ietf-bfd-multipoint-16

her of the first two cases have a vulnerability in certain > cases, it ought to be described in the draft, even if the vulnerability is > confined to a specific set of circumstances. > > > Bob > > > On 11/06/18 19:14, Greg Mirsky wrote: > > Hi Bob, > thank you for

Fwd: New Version Notification for draft-mirsky-bfd-mpls-demand-03.txt

, draft-mirsky-bfd-mpls-demand-03.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-bfd-mpls-demand Revision: 03 Title: BFD in Demand Mode over Point-to-Point MPLS LSP Document date: 2018-06-19 Group: Individual

Re: working group adoption poll for draft-mirsky-bfd-p2mp-vrrp-use-case

Yes, support WG adoption as co-author Regards, Greg On Wed, Jun 20, 2018 at 9:46 AM, Chris Bowers wrote: > RTGWG, > > The authors of draft-mirsky-bfd-p2mp-vrrp-use-case have requested > that RTGWG adopt this draft as a WG document. > https://datatracker.ietf.org/doc/draft-mirsky-bfd-p2mp-vrrp-u

Fwd: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt

at 9:51 AM Subject: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt To: Gregory Mirsky A new version of I-D, draft-mirsky-rtgwg-oam-identify-00.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-rtgwg-oam-ide

Re: Genart last call review of draft-ietf-bfd-multipoint-active-tail-09

Hi Linda, thank you for the review and your kind words, much appreciated. If an end-point during the p2mp BFD session never responded to the head's multicast poll it is unknown to the head and cannot be reported as "inactive tail". I can imagine that if the head has been given the list of the tail

Re: [Int-area] Fwd: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt

rbert wrote: > On Thu, Jun 28, 2018 at 1:34 PM, Greg Mirsky > wrote: > > Dear All, > > I hope that this new draft (yes, that's what I wanted to send the first > > time) will be of interest to those working on overlay encapsulations. > > Appreciate y

Re: Genart last call review of draft-ietf-bfd-multipoint-active-tail-09

FD seems requires more support of the network, > isn’t it? > > > > Linda > > > > *From:* Greg Mirsky [mailto:gregimir...@gmail.com] > *Sent:* Friday, June 29, 2018 11:45 AM > *To:* Linda Dunbar > *Cc:* gen-...@ietf.org; rtg-bfd@ietf.org; IETF list ; > draft-i

Re: Alexey Melnikov's No Objection on draft-ietf-bfd-multipoint-18: (with COMMENT)

Hi Alexey, thank you for the review and your kind words. Will change to "can" and publish in the next version. Regards, Greg On Sat, Jun 30, 2018 at 8:16 AM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-bfd-multipoint-18: No Objection > >

Re: WGLC BFD Authentication Drafts

ore unauthenticated or meticulously authenticated frames being discarded, > causing the receiver to bring the session down. > > Cheers. > > On Apr 9, 2018, at 12:39 PM, Greg Mirsky wrote: > > Hi Ashesh, > thank you for your response to my questions.. I think I need some mo

Re: WGLC BFD Authentication Drafts

e session, because a change in > the state of the session requires those frames to be authenticated by the > sender, and for those frames to be marked valid by the receiver. > > Cheers. > > > On Jul 2, 2018, at 11:06 AM, Greg Mirsky wrote: > > Hi Mahesh, > you've

Re: Ben Campbell's No Objection on draft-ietf-bfd-multipoint-18: (with COMMENT)

Hi Ben, thank you for your review and helpful comments. I propose the following updates: Abstract NEW TEXT: This document updates RFC 5880. Introduction OLD TEXT: The Bidirectional Forwarding Detection protocol [RFC5880] specifies a method for verifying unicast connectivity between a pair

Re: Ben Campbell's Discuss on draft-ietf-bfd-multipoint-active-tail-09: (with DISCUSS and COMMENT)

Hi Ben, thank you for the review and your comments. Please find my answers in-line tagged GIM>>. Regards, Greg On Mon, Jul 2, 2018 at 6:21 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-bfd-multipoint-active-tail-09: Discuss > > When responding

Re: Adam Roach's No Objection on draft-ietf-bfd-multipoint-18: (with COMMENT)

Hi Adam, thank you for the review and helpful comments. Please find my answers in-line tagged GIM>>. Regards, Greg On Mon, Jul 2, 2018 at 7:50 PM, Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-bfd-multipoint-18: No Objection > > When responding, pleas

Re: Adam Roach's No Objection on draft-ietf-bfd-multipoint-active-tail-09: (with COMMENT)

Hi Adam, thank you for the review. Will certainly work with Ben to reach the acceptable solution. Please find my answer to your question below tagged GIM>>. Regards, Greg On Mon, Jul 2, 2018 at 8:38 PM, Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-bf

Re: Mirja Kühlewind's Discuss on draft-ietf-bfd-multipoint-18: (with DISCUSS)

Hi Mirja, thank you for the review and your comments. Please find my answers in-line and tagged GIM>>. Regards, Greg On Tue, Jul 3, 2018 at 11:31 AM, Mirja Kühlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-bfd-multipoint-18: Discuss > > When respondin

Re: Mirja Kühlewind's No Objection on draft-ietf-bfd-multipoint-active-tail-09: (with COMMENT)

Hi Mirja, thank you for the review and comments. Please find my answers in-line tagged GIM>>. Regards, Greg On Tue, Jul 3, 2018 at 2:40 PM, Mirja Kühlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-bfd-multipoint-active-tail-09: No Objection > > When re

Re: Mirja Kühlewind's Discuss on draft-ietf-bfd-multipoint-18: (with DISCUSS)

) wrote: > Hi Greg, > > just one thing quickly > > > Am 05.07.2018 um 21:27 schrieb Greg Mirsky : > > > > 2) See sec 7 of RFC 8085 > > "When BFD is used across multiple hops, a congestion control mechanism > >MUST be implemented, and when congestion

Re: Eric Rescorla's No Objection on draft-ietf-bfd-multipoint-18: (with COMMENT)

Hi Eric, thank you for the review and your thoughtful comments. Please find my answers in-line tagged GIM>>. Regards, Greg On Tue, Jul 3, 2018 at 4:58 PM, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-bfd-multipoint-18: No Objection > > When res

Re: Eric Rescorla's No Objection on draft-ietf-bfd-multipoint-active-tail-09: (with COMMENT)

Hi Eric, thank you for the review and detailed comments. Please find my answers in-line tagged GIM>>. Regards, Greg On Tue, Jul 3, 2018 at 5:17 PM, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-bfd-multipoint-active-tail-09: No Objection > > Whe

Re: Tsvart telechat review of draft-ietf-bfd-multipoint-18

d the receiver." > > How can this mechanism verify connectivity, but not be used in the context > of > connectivity verification in the transport network? > > The email response from Greg Mirsky (coauthor) was: > >>This draft defines the base specification for multipoin

Re: Warren Kumari's No Objection on draft-ietf-bfd-multipoint-18: (with COMMENT)

Hi Warren, thank you for your kind words and helpful comments. Please find my answers in-line tagged GIM>>. Regards, Greg On Wed, Jul 4, 2018 at 9:53 AM, Warren Kumari wrote: > Warren Kumari has entered the following ballot position for > draft-ietf-bfd-multipoint-18: No Objection > > When resp

Re: Alvaro Retana's No Objection on draft-ietf-bfd-multipoint-18: (with COMMENT)

Hi Alvaro, thank you for the review and your comments. Please find my answers in-line tagged GIM>>. Regards, Greg On Wed, Jul 4, 2018 at 11:56 AM, Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-bfd-multipoint-18: No Objection > > When responding,

Re: Ben Campbell's Discuss on draft-ietf-bfd-multipoint-active-tail-09: (with DISCUSS and COMMENT)

appreciate your consideration and comments. Regards, Greg On Wed, Jul 4, 2018 at 2:48 PM, Greg Mirsky wrote: > Hi Ben, > thank you for the review and your comments. Please find my answers in-line > tagged GIM>>. > > Regards, > Greg > > On Mon, Jul 2, 2018 at 6:21 PM, Ben Campb

Fwd: New Version Notification for draft-ietf-bfd-vxlan-01.txt

allik Mudigonda < mmudi...@cisco.com>, Sudarsan Paragiri , Vengada Prasad Govindan , Santosh Pallagatti < santosh.pallaga...@gmail.com> A new version of I-D, draft-ietf-bfd-vxlan-01.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: dra

Fwd: I-D Action: draft-ietf-bfd-vxlan-02.txt

gonda Greg Mirsky Filename: draft-ietf-bfd-vxlan-02.txt Pages : 10 Date: 2018-08-18 Abstract: This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in Virtual eXtensible Local Area Network (VXLAN) ov

Re: Fwd: I-D Action: draft-ietf-bfd-vxlan-02.txt

MUST >be validated > > We all understand what you mean but I first stumbled: Ethernet frames have > no > TTL. You mean (of course) the inner IP packet - why not writing it? ;-) > GIM>> Agreed. Would s/inner Ethernet/inner IP packet/ address it? > > > > An

Fwd: New Version Notification for draft-ietf-bfd-vxlan-03.txt

Notification for draft-ietf-bfd-vxlan-03.txt To: Gregory Mirsky , Mallik Mudigonda < mmudi...@cisco.com>, Sudarsan Paragiri , Vengada Prasad Govindan , Santosh Pallagatti < santosh.pallaga...@gmail.com> A new version of I-D, draft-ietf-bfd-vxlan-03.txt has been successfully submitted by Gre

  1   2   3   4   >