Re: WGLC for draft-ietf-bfd-seamless-ip

I support advancing this document to the IESG, and believe it is ready. As co-author, and as a co-statement with Dave Ward, we are not aware of any IPR relating to draft-ietf-bfd-seamless-ip other than what’s already been submitted. Thanks, — Carlos. On May 4, 2015, at 4:23 PM, Jeffrey Haas

Re: Multiple BFD sessions between the same pair of end-points

Hi Reshad, It really depends on what is considered a “path” over which BFD detects faults, and how the initial demux can be done vs. bootstrapped out-of-band. RFC 5881 has the text quoted by Greg, because in that case single-hop initialization procedures can be done (by binding the interface

Re: Multiple BFD sessions between the same pair of end-points

m: Alexander Vainshtein <alexander.vainsht...@ecitele.com > <mailto:alexander.vainsht...@ecitele.com>> > Date: Tuesday, November 3, 2015 at 9:38 AM > To: "Carlos Pignataro (cpignata)" <cpign...@cisco.com > <mailto:cpign...@cisco.com>>, Reshad <rr

Re: [Lime] Call for Adoption: draft-tissa-lime-yang-oam-model-06

Hi, Mahesh, Please find one comment inline. > On Aug 26, 2015, at 9:56 PM, Qin Wu wrote: > > Hi, Mahesh: > -邮件原件- > 发件人: Lime [mailto:lime-boun...@ietf.org] 代表 Mahesh Jethanandani > 发送时间: 2015年8月27日 5:11 > 收件人: Tom Taylor > 抄送: rtg-bfd@ietf.org; l...@ietf.org > 主题:

Re: AD Review of draft-ietf-bfd-seamless-ip

Hi, Alvaro, > On Sep 25, 2015, at 12:49 PM, Alvaro Retana (aretana) > wrote: > > Please consider merging this document into draft-ietf-bfd-seamless-base. Where have I heard this before? :-) In addition to my perspective on your review of the -base document, one additional

Re: AD Review of draft-ietf-bfd-seamless-ip

Alvaro, Thanks again — Closing the loop, please see inline. > On Sep 27, 2015, at 7:16 PM, Alvaro Retana (aretana) <aret...@cisco.com> > wrote: > > On 9/27/15, 4:54 PM, "Carlos Pignataro (cpignata)" <cpign...@cisco.com > <mailto:cpign...@cisco.com>>

Re: Working group status

Jeff, In addition to this document that Loa points out, there are other related documents in other WGs: 02 Mar 2015 draft-ietf-isis-sbfd-discriminatortxtpdf xml html 23 Jul 2015 draft-ietf-l2tpext-sbfd-discriminator txtpdf xml html 23 Mar 2015

Re: AD Review of draft-ietf-bfd-seamless-base

> On Dec 8, 2015, at 9:40 AM, jh...@pfrc.org wrote: > > On Tue, Dec 08, 2015 at 02:36:29PM +, Alvaro Retana (aretana) wrote: >> On 12/6/15, 4:09 AM, "Santosh P K" wrote: >> Unless I missed something, Carlos [1] didn't reply to #1: how are the use >> cases satisfied?

Re: AD Review of draft-ietf-bfd-seamless-base

Thanks Alvaro for the response — please see inline. > On Dec 8, 2015, at 11:14 AM, Alvaro Retana (aretana) <aret...@cisco.com> > wrote: > > On 12/8/15, 10:12 AM, "Carlos Pignataro (cpignata)" <cpign...@cisco.com > <mailto:cpign...@cisco.com>> > w

Re: AD Review of draft-ietf-bfd-seamless-base

Manav, Thanks for the discussion. Let's not cripple the spec before its out. Saying "let's update 5 RFCs when I understand the use case" is not forward compatibility and artificially constrain the spec :-) Please find some comments inline. Thumb typed by Carlos Pignataro. Excuze

Re: AD Review of draft-ietf-bfd-seamless-base

Thanks Manav and Les, and sorry for the delay in pitching in. I like the proposal below with one difference: 1. Instead of removing, let's say it's for future study, leave the current use case but say this spec allows for one only. 2. And 3. Yes! Thanks! Thumb typed by Carlos Pignataro. Excuze

Re: AD Review of draft-ietf-bfd-seamless-base

Thanks Manav! Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Dec 23, 2015, at 23:44, Manav Bhatia > wrote: > 1. Remove the multiple sessions terminating on the same target example from > the use-case document. > 2. Change the

Re: AD Review of draft-ietf-bfd-seamless-base

Hi! Happy New Year! I strongly agree with Les' perspective here, as that was also the way I was trying to write the spec. As we design a spec, it is important that we, simultaneously: 1. Provide future growth capability and forward compatibility, and not corner ourselves being too stringent

Re: I-D Action: draft-ietf-bfd-seamless-base-08.txt

Hi, BFD WG, As part of the AD Review of draft-ietf-bfd-seamless-base , Alvaro provided a very thorough and most useful review — thanks much Alvaro! The full set of comments is at

Re: Advancing S-BFD

Álvaro, Thanks for the response! — please see inline. > On Mar 18, 2016, at 4:31 PM, Alvaro Retana (aretana) <aret...@cisco.com> > wrote: > > On 3/18/16, 9:25 AM, "Carlos Pignataro (cpignata)" <cpign...@cisco.com> > wrote: > > Carlos: > &

Re: Ben Campbell's Discuss on draft-ietf-bfd-seamless-ip-04: (with DISCUSS and COMMENT)

Hi, Ben, Many thanks for this review and raising these issues, please see inline. > On May 3, 2016, at 5:00 PM, Ben Campbell wrote: > > Ben Campbell has entered the following ballot position for > draft-ietf-bfd-seamless-ip-04: Discuss > > When responding, please keep the

Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT)

Hi, Alia, Thanks for your review and for bringing up these issues — please see inline. > On May 2, 2016, at 5:24 PM, Alia Atlas wrote: > > Alia Atlas has entered the following ballot position for > draft-ietf-bfd-seamless-base-09: Discuss > > When responding, please keep

Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-ip-04: (with DISCUSS)

Hi Alia, Thanks for the review and for these! Please see inline. > On May 2, 2016, at 6:26 PM, Alia Atlas wrote: > > Alia Atlas has entered the following ballot position for > draft-ietf-bfd-seamless-ip-04: Discuss > > When responding, please keep the subject line intact

Re: Mirja Kühlewind's Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS)

Hi, Mirja, What is an uncontrolled packet in an IP network, and what entity controls controlled ones? :-) More seriously, please see inline. > On May 3, 2016, at 5:35 AM, Mirja Kuehlewind wrote: > > Mirja Kühlewind has entered the following ballot position for >

Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT)

ck resolution! > I'll clear my discuss assuming that you will submit the updated version very > very soon. > > Regards, > Alia > > On Tue, May 3, 2016 at 12:13 PM, Carlos Pignataro (cpignata) > <cpign...@cisco.com <mailto:cpign...@cisco.com>> wrote: > Hi,

Re: Problematic text in RFC 5882

Hi Sasha, That’s correct, an editorial mis-expansion of the acronym LSP. It should be “Link State Packet”. Thanks, — Carlos. On Sep 20, 2016, at 4:27 AM, Alexander Vainshtein > wrote: Hi all, I have found the

Re: Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017)

Jeff and Reshad, Yes, I support BFD WG adoption of draft-sonal-bfd-secure-sequence-numbers-00. Thanks! — Carlos. > On Apr 17, 2017, at 5:35 PM, Jeffrey Haas wrote: > > Working Group, > > As part of our discussion at the Working Group session at IETF 98 in > Chicago, Sonal

Re: [Technical Errata Reported] RFC5884 (5085)

"The Sender's Handle is filled in by the sender and returned unchanged by the receiver in the echo reply (if any)." Though English is my third language, I interpret "if any" in that sentence as clear indication that the echo reply may not be sent ever. Regards, Gre

Re: [Technical Errata Reported] RFC5884 (5085)

Jeff, WG, I believe there is one additional consideration — please see inline. On Aug 11, 2017, at 1:39 PM, Jeffrey Haas > wrote: [Note that I have adjusted the addresses in the headers to try to catch the RFC authors' current accounts.] The 5884 interop

Re: [Technical Errata Reported] RFC5884 (5085)

Greg, > On Aug 11, 2017, at 2:12 PM, Greg Mirsky wrote: > > Re-sending to the corrected list (apologies for duplicates). > > Dear All, > I suggest to reject this proposal. The current text is clear and the > mechanics of bootstrapping BFD session over MPLS LSP is well

Re: A question about RFC5884

e no problem to process as described in RFC5884. BTW, RFC5884 does not specify which reply mode will be used :) Best regards, Mach From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com] Sent: Monday, July 17, 2017 6:58 AM To: Reshad Rahman (rrahman) Cc: Mach Chen; Ashesh Mishra; rtg-

Re: A question about RFC5884

Greg, Pointer? Thanks, Sent from my iPad On Jul 17, 2017, at 9:34 AM, Greg Mirsky > wrote: Hi Mach, et. al, I recall that this question was discussed some time ago and the clarification came from the original authors of the BFD protocol.

Re: A question about RFC5884

y Discriminator field in the BFD session packets sent by the egress LSR. Regards, Greg On Mon, Jul 17, 2017 at 8:02 AM, Carlos Pignataro (cpignata) <cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote: Greg, Pointer? Thanks, Sent from my iPad On Jul 17, 2017, at 9:34 AM, Greg Mi

Re: WGLC for BFD Multipoint documents (ending July 14, 2017)

Greg, How would that help interoperability? Seems like it would not matter, hence not mention is appropriate... Sent from my iPad On Jul 7, 2017, at 9:17 PM, Greg Mirsky > wrote: Hi Santosh, et. al, another note, question on IP/UDP

Re: A question about RFC5884

Hi, I also agree with the conclusion of this thread in regards to what RFC 5884 says. However, can that be in conflict with RFC 8029's procedures, in which the reply might be expected? https://tools.ietf.org/html/rfc8029#section-4.4 There is certainly no need to carry any information in an

Re: WGLC for BFD Multipoint documents (ending July 14, 2017)

dback. Most of this feedback seems to be of the nature of minor edits. Is it your opinion this document is ready to advance after these issues are addressed? -- Jeff On Tue, Jun 27, 2017 at 02:56:22PM +0000, Carlos Pignataro (cpignata) wrote: Just one comment on these two documents, in regards

Re: WGLC for BFD Multipoint documents (ending July 14, 2017)

Thanks, Santosh! On Jul 6, 2017, at 12:49 PM, Santosh P K <santosh.pallaga...@gmail.com<mailto:santosh.pallaga...@gmail.com>> wrote: 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 Pignata

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

another reason why FECs are being defined at: https://tools.ietf.org/html/draft-ietf-mpls-spring-lsp-ping-02 Hope that helps, — Carlos. PS: As I find this repetitive, this is my last email on the subject. > Regards, > Greg > > On Wed, May 10, 2017 at 1:01 PM, Carlos Pignataro (c

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

use such abbreviation neither do draft-ietf-mpls-bfd-directed :) Google also seems to be pretty clueless about it. Just curious as you keep using this term in each email :) Thx, R. On Wed, May 10, 2017 at 9:24 PM, Carlos Pignataro (cpignata) <cpign...@cisco.com<mailto:cpign...@cisc

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

Greg, This document seems to say “use “Do not Reply” reply mode, and even if you reply do not use the BFD Disc TLV, because it is not used. Wouldn’t it be simpler to say “follow RFC 8029, and the ingress does not care about the BFD Disc TLV in the reply”? This would not suddenly make

Re: WGLC for BFD Multipoint documents (last round)

Dear Greg, It appears these comments are not addressed: https://www.ietf.org/mail-archive/web/rtg-bfd/current/msg03475.html Best, Sent from my iPad On Dec 15, 2017, at 11:05 AM, Greg Mirsky > wrote: Dear All, attached please find diff and

Re: WGLC for BFD Multipoint documents (last round)

Hi, Greg, It seems the comments regarding bfd.SessionType are not addressed: 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

Re: [Technical Errata Reported] RFC7880 (5211)

As a co-author of RFC 7880, I disagree with the report below, and recommend Rejecting this Erratum. S-BFD uses the BFD state variables, and “bfd.SessionType” is applicable with finer granularity than “Not S-BFD”. Some details at.

Re: WGLC for BFD Multipoint documents (last round)

can change the name to bfd.SessionTopology. Greatly appreciate comments, suggestions. Let's make holiday presents to our AD! Regards, Greg On Fri, Dec 15, 2017 at 10:02 PM, Carlos Pignataro (cpignata) <cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote: Hi, Greg, It seems the comm

Re: [mpls] Fwd: New Version Notification for draft-mirsky-spring-bfd-03.txt

Dear Greg, Since there had been no responses to the few emails you had sent to the three lists (MPLS, SPRING, RTG-BFD) about various versions of this draft, here’s some high-level thoughts. I hope these are clear and useful. In this email you mention BFD as the Target WG, the document file

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

Greg, Please find one late follow-up inline. On Jun 4, 2018, at 10:23 PM, Greg Mirsky mailto:gregimir...@gmail.com>> wrote: 8/ Incremental deployment Section 4.4.1. "New State Variable Values" defines bfd.SessionType = PointToPoint as well as a couple of Multipoint alternatives. Presumably

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

Jeff, On Jul 2, 2018, at 2:09 PM, Jeffrey Haas mailto:jh...@pfrc.org>> wrote: Carlos, On Tue, Jun 26, 2018 at 05:17:20AM +, Carlos Pignataro (cpignata) wrote: [...] I do not believe the question was whether S-BFD or any other protocol followed the behavior. It’s a question

Re: WGLC for BFD Multipoint documents (last round)

osed changes to BFD Multipoint and BFD Multipoint with active tails drafts (attached). Regards, Greg On Mon, Jan 15, 2018 at 8:25 PM, Carlos Pignataro (cpignata) <cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote: Reshad, Greg, Indeed, it seems the content of the section i

Re: WGLC for BFD Multipoint documents (last round)

Hi, Greg, When looking for this specific sentence, I got a chance to scan through the document a bit. It seems to me there are still a number of editorials and potentially non-editorials to be fixed. Looking at S4.8 only: BFD packets received on tails for an IP multicast group MUST be

Re: WGLC for BFD Multipoint documents (last round)

missed your comment. Please find my follow-up updates under GIM2>> tag. I've attached diff to highlight the changes. Regards, Greg On Tue, Feb 13, 2018 at 3:37 PM, Carlos Pignataro (cpignata) <cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote: Hi, Greg, On Feb 11, 2018, at 9

Re: WGLC for BFD Multipoint documents (last round)

ections only, which triggered these coarse set of comments. Please find my responses in-lined tagged GIM>>. More inline. Regards, Greg On Thu, Feb 8, 2018 at 7:19 PM, Carlos Pignataro (cpignata) <cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote: Hi, Greg, When looking for

Re: The BFD WG has placed draft-spallagatti-bfd-vxlan in state "Call For Adoption By WG Issued"

Hi, I read through draft-spallagatti-bfd-vxlan-06 and support its adoption as a BFD WG document. I do have some comments and questions, which might require follow-up but neither of which is blocking on adoption. These questions can be discussed by the WG after a potential adoption. 1.

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

om>> Date: Tuesday, March 20, 2018 at 5:49 PM To: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, "Carlos Pignataro (cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>> Cc: "m...@ietf.org<mailto:m...@ietf.org>" <

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

ind my answers in-line tagged GIM>>. Regards, Greg On Thu, Oct 25, 2018 at 9:04 PM Carlos Pignataro (cpignata) mailto:cpign...@cisco.com>> wrote: Xiao, Scanning through the draft, two questions: 1. What is the underlying mechanism to check liveness such that Demand can be used? http

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

Hi Xiao, Thanks much for the quick response! Please find my follow ups: 1. Sorry if I was not clear. Yes, RFC 5880 lists exemplary possible mechanisms to glean continued connectivity but requires the use of one. My question is: which mechanisms does this draft propose? Could it please be

Re: WGLC for draft-ietf-bfd-vxlan, ending November 9

+1. Support publication as this is useful and technically sound. I do not understand why [I-D.ietf-bfd-multipoint] is a Normative reference, or frankly a reference at all. I do not think there’s a need to reference every potential thin outside scope. Thanks, — Carlos Pignataro On Oct 22,

Re: [mpls] (no subject)

Hi, Cc BFD WG It would be useful to understand the use case motivation or applicability of this draft, other than it can be done. I’m also increasingly concerned by confusing scope and definition of specifications. For example:

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

Xiao, Scanning through the draft, two questions: 1. What is the underlying mechanism to check liveness such that Demand can be used? https://tools.ietf.org/html/rfc5880#section-6.6 Demand mode requires that some other mechanism is used to imply continuing connectivity between the two

Re: [mpls] MPLS WG adoption call for draft-mirsky-mpls-p2mp-bfd

8 at 8:47 PM Carlos Pignataro (cpignata) mailto:cpign...@cisco.com>> wrote: Hi, Cc BFD WG It would be useful to understand the use case motivation or applicability of this draft, other than it can be done. GIM>> The motivation can be seen in the following (from another draft that

Re: [mpls] MPLS WG adoption call for draft-mirsky-mpls-p2mp-bfd

ards, Greg On Tue, Nov 6, 2018 at 12:11 AM Carlos Pignataro (cpignata) mailto:cpign...@cisco.com>> wrote: Hi Greg, Many thanks for your response and suggestions! Please see inline. On Nov 2, 2018, at 6:13 AM, Greg Mirsky mailto:gregimir...@gmail.com>> wrote: Hi Carlos, thank you for

Re: [mpls] MPLS WG adoption call for draft-mirsky-mpls-p2mp-bfd

pinion, unsatisfactorily answered. Please find the new comments in-line tagged GIM3>>. Regards, Greg On Wed, Nov 7, 2018 at 8:52 PM Carlos Pignataro (cpignata) mailto:cpign...@cisco.com>> wrote: [Greg, Loa, responding to both on this single email reply] Hi, Loa, On Nov 6, 2018, at 1:49

Re: Tsvart last call review of draft-ietf-bfd-vxlan-07

xplore and define how the Echo mode of BFD is used over > VXLAN tunnels. > See above. > Will review and respond to the remaining questions soon. Thank you. The "remaining questions" are still all the questions below :-) Best, Carlos. > > Regards, > Greg >

Re: Tsvart last call review of draft-ietf-bfd-vxlan-07

Hi, I have not reviewed this draft before, but triggered by this email, and briefly scanning through a couple of sections, it is unclear to me how some of the mechanics work. There are some major issues with the Mac usage and association, as Joel Halpern mentioned in his Rtg Dir review. And,

Re: Tsvart last call review of draft-ietf-bfd-vxlan-07

as BFD is concerned (single hop VXLAN tunnel). Since RFC 5881 defines Echo for single hop, can you please elaborate (in the document) why is out of scope or how it can work? Best, Carlos. Will respond to other questions in a separate mail. Regards, Greg On Thu, Jun 20, 2019 at 10:31 AM Carlos

Re: Level of standardization of the Echo mode of BFD [Re: Tsvart last call review of draft-ietf-bfd-vxlan-07]

Jun 20, 2019 at 11:09 AM Carlos Pignataro (cpignata) mailto:cpign...@cisco.com>> wrote: Hello, Greg, Please see inline. On Jun 19, 2019, at 9:58 PM, Greg Mirsky mailto:gregimir...@gmail.com>> wrote: Hello Carlos, thank you for the expedient clarification. To your questions on demultip

Re: Level of standardization of the Echo mode of BFD [Re: Tsvart last call review of draft-ietf-bfd-vxlan-07]

e thread in a direction that diverges from resolution. I have not suggested that any document includes anything. My comment is: what is the reason why BFD Echo is out of scope? Technically, this is a single hop at the VXLAN level for BFD. Best, Carlos. > > Regards, > Greg > > On

Re: Level of standardization of the Echo mode of BFD [Re: Tsvart last call review of draft-ietf-bfd-vxlan-07]

n Wed, Jul 3, 2019 at 9:35 AM Carlos Pignataro (cpignata) mailto:cpign...@cisco.com>> wrote: Hello, Greg, Before you asked about RFC 5884, now RFC 5885, neither of which are references in draft-ietf-bfd-vxlan-07. Your new request is: > I hope that you can help me to answer a question

Re: Tsvart last call review of draft-ietf-bfd-vxlan-07

Hi, Jeff, On Jul 1, 2019, at 4:41 PM, Jeffrey Haas mailto:jh...@pfrc.org>> wrote: Carlos, On Jun 19, 2019, at 10:09 PM, Carlos Pignataro (cpignata) mailto:cpign...@cisco.com>> wrote: This packet loop may not be practical for several encapsulations and thus is

Re: Level of standardization of the Echo mode of BFD [Re: Tsvart last call review of draft-ietf-bfd-vxlan-07]

n RFC 5885, would that address your concern? > > Regards, > Greg > > On Fri, Jun 21, 2019 at 5:19 PM Carlos Pignataro (cpignata) > wrote: > Hello, Greg, > > Thank you for having split this thread. I’ll note for ease of tracking that > this specific issue is iss

Re: BFD Echo mode coverage in BFD for VXLAN

that documenting the applicability of the Echo mode in BFD over VXLAN is useful? Regards, Greg On Wed, Aug 7, 2019 at 6:18 PM Carlos Pignataro (cpignata) mailto:cpign...@cisco.com><mailto:cpign...@cisco.com>> wrote: Dear Greg, The option of replacing the existing text fo

Re: Progress draft-ietf-mpls-bfd-directed

Hello, Greg, Although there is no question in your message, let me reply with a different perspective. I find the creation of an Operational Considerations self-contained section to be a misguided approach, since this whole document should largely concern itself with operational

Re: WGLC for draft-ietf-bfd-large-packets

Thanks for the reminder, Reshad. I support publication of this document, short and useful. I only have one comment in regards to: It is also worthy of note that even if an implementation can function with larger transport PDUs, that additional packet size may have impact on BFD

Re: WGLC for draft-ietf-bfd-large-packets

Hi, Mahesh, On Sep 13, 2019, at 12:13 AM, Mahesh Jethanandani mailto:mjethanand...@gmail.com>> wrote: Hi Carlos, On Sep 12, 2019, at 7:56 PM, Carlos Pignataro (cpignata) mailto:cpign...@cisco.com>> wrote: Thanks for the reminder, Reshad. I support publication of this doc

Re: BFD Echo mode coverage in BFD for VXLAN

Dear Greg, The option of replacing the existing text for something more ambiguous and implicit does not seem like progress in my humble opinion. The spec ends up with the same capabilities, but the text is more obscure. I do not support that option. My recommendation for your consideration

Re: Draft agenda posted for IETF 105

Jeff, Reshad, > On Jul 18, 2019, at 12:12 PM, Jeffrey Haas wrote: > > Working Group, > > Here's the draft agenda for IETF 105. > > https://datatracker.ietf.org/meeting/105/materials/agenda-105-bfd > > Please note we are reserving the end of the session for discussion about BFD > v2. We are

Re: Draft agenda posted for IETF 105

Jeff, > On Jul 22, 2019, at 10:28 AM, Jeffrey Haas wrote: > > [largely speaking as an individual contributor] > > Carlos, > > On Mon, Jul 22, 2019 at 01:44:46PM +0000, Carlos Pignataro (cpignata) wrote: >>> On Jul 18, 2019, at 12:12 PM, Jeffrey Haas wrote: &g

Re: IETF-106 agenda?

2019/11/01 午後4:27、Greg Mirsky mailto:gregimir...@gmail.com>>のメール: Hi Jeff, et al., I think that it will be of interest to the group to get an update on the draft-mirmin-bfd-extended. We've added details on the use of the Padding TLV. Also, would appreciate the opportunity to discuss the

Re: Éric Vyncke's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)

Hi, Éric, Regarding you first DISCUSS element, I had brought up the same issue. See the 2nd point at https://mailarchive.ietf.org/arch/msg/rtg-bfd/BL9Ob66Yxie4wX13yZJELbYPLJs Thanks, Carlos. 2019/12/17 午前3:51、Éric Vyncke via Datatracker mailto:nore...@ietf.org>>のメール: Éric Vyncke has

Re: Éric Vyncke's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)

Hi, Jeff, Thanks for the dailogue and please see inline some follow-ups. > 2019/12/19 午後3:38、Jeffrey Haas のメール: > > Carlos, > > On Thu, Dec 19, 2019 at 08:12:56PM +, Carlos Pignataro (cpignata) wrote: >>> 2019/12/19 午後1:06、Jeffrey Haas のメール: > > Interes

Re: Éric Vyncke's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)

Hi, Jeff, > 2019/12/19 午後1:06、Jeffrey Haas のメール: > > Carlos, > > On Thu, Dec 19, 2019 at 03:22:28AM +, Carlos Pignataro (cpignata) wrote: >>> 2019/12/18 午後4:41、Jeffrey Haas のメール: >>> But given that point, what precisely is the objection to the inner IP heade

Re: Éric Vyncke's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)

00, Carlos Pignataro (cpignata) wrote: > Hi, Éric, > > Regarding you first DISCUSS element, I had brought up the same issue. See the 2nd point at https://mailarchive.ietf.org/arch/msg/rtg-bfd/BL9Ob66Yxie4wX13yZJELbYPLJs > > Thanks, > > Carlos.

Re: Éric Vyncke's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)

Hi, Jeff, > 2019/12/18 午後4:41、Jeffrey Haas のメール: > > Carlos, > > On Wed, Dec 18, 2019 at 09:28:30PM +, Carlos Pignataro (cpignata) wrote: >> The TTL of 1 recommended for RFC 4379 / RFC 8029 S4.3 is because if the MPLS >> packet is mis-routed, or there's a

Re: New Version Notification for draft-ietf-bfd-vxlan-11.txt

and mgmt VNI. Assuming that was clear... helpful and constructive suggestions. Thanks. That was the intent, but only for the TTL/HL change. Please find my answers in-line tagged GIM>>. Regards, Greg On Mon, May 4, 2020 at 5:49 PM Carlos Pignataro (cpignata) wrote: Dear Greg, I have not c

Re: New Version Notification for draft-ietf-bfd-vxlan-11.txt

Dear Greg, I have not checked the diff and the new text regarding the Eth MAC and mgmt VNI. However, these diffs also include a change that you did not mention: TTL / Hop Limit handling, which is one of the comments I had made. In that context, thank you very much! since this update partially

Re: New Version Notification for draft-ietf-bfd-vxlan-11.txt

hat long sentence into two. * Acknowledgments Thank you. I'll thoroughly look through all the relevant discussion threads in the mail archive. Sounds good. Thanks, Carlos. Regards, Greg On Mon, May 4, 2020 at 7:52 PM Carlos Pignataro (cpignata) mailto:cpign...@cisco.com>> wrote: D

Re: New Version Notification for draft-ietf-bfd-vxlan-12.txt

Thank you, Greg. I only looked at the update to the last paragraph of Section 6. Reading through the last paragraph of Section 6, the text is not fully clear. There are a few nits, including a missing article, /as long as/as well as/, /is/are/, and missing preposition which results in an