IETF 94 - initial agenda posted

Working Group, A draft agenda has been posted to the datatracker for the upcoming session in Yokohama. We technically have 20 minutes still available and thus could accommodate potentially another presentation or extended presentation and discussion on the prior topics. However, I would like to

Reminder, WGLC in progress

I know it is not the traditional "read all the drafts the week before IETF", but this is a reminder that BFD Multipoint (and the active tail draft) as well as the BFD MPLS MIB document are in WGLC. Please comment on them! -- Jeff

[i.goy...@alcatel-lucent.com: WGLC for draft-ietf-l2tpext-sbfd-discriminator]

FYI: - Forwarded message from Ignacio Goyret - Date: Mon, 19 Oct 2015 09:39:28 -0700 From: Ignacio Goyret To: l2tp...@ietf.org Cc: draft-ietf-l2tpext-sbfd-discrimina...@tools.ietf.org, bfd-cha...@tools.ietf.org Subject: WGLC for draft-ietf-l2tpext-sbfd-discriminator Hi group, This e

Re: New BFD Co-Chair

Nobo, On Wed, Oct 28, 2015 at 12:49:48PM +0900, Nobo Akiya wrote: > Hello BFDers, > > It has been my honor to work with so many smart & creative folks in this > WG. However, I have decided that I need to continue my focus in different > areas with my new journey. I will miss many of you guys, and

IETF 94 - Yokohama

Working Group, The current agenda is posted with no changes aside from noting that we have a new co-chair: https://datatracker.ietf.org/meeting/94/agenda/bfd/ Presenters: You are responsible for getting me your slides in .ppt or .pdf format no later than Monday afternoon. Ideally we'd like to s

BFD Yang and LIME

If you have interest in BFD Yang, please note that there is a discussion on it that will be happening in context of the LIME meeting. This is happening 15:20-16:50, Monday Afternoon session II. -- Jeff - https://tools.ietf.org/wg/lime/agenda?item=agenda-94-lime.html Agenda : version 1.2

Fwd: NomCom 2015 - Second Request for feedback

If you're at IETF, you can provide feedback directly to the members of the nomcom either through the webform, their office hours or look for people with orange dots. -- Jeff > Begin forwarded message: > > From: NomCom Chair 2015 > Subject: NomCom 2015 - Second Request for feedback > Date: No

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

Greg, > On Nov 3, 2015, at 11:26 AM, Gregory Mirsky > wrote: > > Dear All, > I think that this paragraph from Section 2 of RFC 5881 prohibits multiple > single-hop BFD sessions between the same pair of end points: >Each BFD session between a pair of systems MUST traverse a separate >ne

Re: WGLC BFD Multipoint (with active tail)

together. This last call closes with no consensus to advance the documents. We can revisit this next year. -- Jeff and Reshad On Mon, Oct 05, 2015 at 02:20:59PM -0400, Jeffrey Haas wrote: > BFD Working Group, > > This starts an extended Working Group Last Call for the following documents

Re: WGLC for draft-ietf-bfd-mpls-mib

draft has expired. -- Jeff On Mon, Oct 05, 2015 at 02:26:31PM -0400, Jeffrey Haas wrote: > BFD Working Group, > (cc'ing MPLS) > > This begins an extended Working Group Last Call for > draft-ietf-bfd-mpls-mib, BFD Management Information Base (MIB) extensions > for MPLS and

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

On Wed, Nov 04, 2015 at 12:48:44AM +, Reshad Rahman (rrahman) wrote: > > > Hi all, > > Thanks Alex and Carlos. Since RFC5883 doesn’t preclude having multiple BFD > sessions for MH, I think that the operational model for BFD IP MH should > allow for multiple sessions between 2 endpoints (sa

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

Marc, On Wed, Nov 04, 2015 at 01:20:17AM -0800, Marc Binderberger wrote: > I'm not too deep into YANG et al., so I apologize upfront for this email :-) > . I understand YANG is about configuration but are we trying to find a common > way to reflect the various (CLI-)configurations that are out i

IETF 94 candiate minutes

Thanks to Ignas and Reshad for taking minutes and to Reshad for consolidating them. Please forward addendums or corrections to the mailing list by end of day Friday. - Forwarded message from "Reshad Rahman (rrahman)" - Tuesday, November 3, 2015 10:30 - 11:30 Morning session I

Taking BFD to full standard (was Re: IETF 94 candiate minutes)

Marc, On Tue, Nov 17, 2015 at 10:55:21PM -0800, Marc Binderberger wrote: > > [Jeff Haas]: BFD has been pretty stable for several years. We potentially > > can take BFD to full standard then. This needs to do errata, implementation > > reports, etc. Question to WG - do you think that BFD should b

Re: Taking BFD to full standard (was Re: IETF 94 candidate minutes)

Sasha, On Wed, Nov 18, 2015 at 12:47:18PM +, Alexander Vainshtein wrote: > Does not moving to full standard require an implementation survey and posting > its results as a draft (to be progressed to an Informational RFC)? An implementation survey is likely still required. Whether it would b

Re: Request for WG adoption of draft-mahesh-bfd-authentication

On Tue, Nov 24, 2015 at 06:46:40AM +, Gregory Mirsky wrote: > I'd like to share comment by Security AD Stephen Farrell on a work that is > directly related to BFD, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf (hope it > is OK to raise security awareness in BFD community): > > There was a proposa

Re: Request for WG adoption of draft-mahesh-bfd-authentication

On Wed, Nov 25, 2015 at 01:57:36PM +0800, Dacheng Zhang wrote: > Great! Let us update that draft and discuss it in the next IETF meeting. And please work with the authors for the optimization draft. I believe that's the core enabling technology for stronger authentication. -- Jeff

Re: Request for WG adoption of draft-mahesh-bfd-authentication

Rajeev, On Thu, Nov 26, 2015 at 05:35:31AM +, Rajeev G Nair (rajeenai) wrote: > Questions:- > Q1) Doesn't acceptance of non-auth packets dictates state of the session > (e.g. Keep it still up UP) ? > > There are a few aspects of the proposal that mitigate such a situation. The > scenario yo

Re: Request for WG adoption of draft-mahesh-bfd-authentication

Rajeev, On Thu, Dec 03, 2015 at 10:16:27PM +, Rajeev G Nair (rajeenai) wrote: > >No particular offense to you or others on this point, but I must state > >something: I've always found the idea of the attack of keeping BFD *up* to > >be silly. :-) > > > >In general, BFD is used for fast-failove

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

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? I'm looking forward to an updated version of > I-D.ietf-bfd-seamless-use-case which m

Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt

[Wearing my BFD co-chair hat.] On Mon, Jan 18, 2016 at 06:38:40PM +, Chris Bowers wrote: > One might also consider doing this work in the BFD WG to take advantage of > the concentration of BFD expertise there. However, since the main content > of the document deals with VRRP behavior and defi

[rfc-edi...@rfc-editor.org: RFC 7726 on Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs)]

Congratulations to the Working Group on another RFC! As always, thank you to all of the members driving this effort. -- Jeff - Forwarded message from rfc-edi...@rfc-editor.org - Date: Fri, 29 Jan 2016 14:57:03 -0800 (PST) From: rfc-edi...@rfc-editor.org To: ietf-annou...@ietf.org, rfc-d

Re: [Errata Held for Document Update] RFC5880 (4410)

I do not believe the errata in question is necessary. Section 6.8.4 covers the calculation of the detection interval. After the start of a poll, the remote system may take some time to respond to the poll and set the Final bit. During that time, it is permissable to send Async packets following t

Re: Advancing S-BFD

On Fri, Mar 18, 2016 at 08:31:08PM +, Alvaro Retana (aretana) wrote: > I had asked the WG to consider not publishing > draft-ietf-bfd-seamless-use-case [A], but after a lengthy exchange with > the authors and a discussion at IETF 94, the WG decided to "give another > chance to the authors" [B].

Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

Working Group, These documents reasonably extend the existing BFD on LAG mechanism and would be reasonably in charter for BFD to pick up. Greg, given that adoption seems a reasonable course, could you and the other co-authors state whether there's any known IPR on these documents? -- Jeff > O

Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

Greg (and Jeff T.): On Mon, Apr 04, 2016 at 10:31:30PM +, Gregory Mirsky wrote: > Hi Jeff, > we have not expected this question that early ☺ > Yes, there’s IPR associated with these drafts that would be properly > disclosed after the meeting. The ADs have been prodding us extra hard about IP

Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

Greg, This is more of a general comment on discussions from the development from RFC 7130 than any specific comment on your draft. On Fri, Apr 08, 2016 at 11:43:18AM -0700, Greg Mirsky wrote: > yes, link local multicast may be used in MC-LAG scenario. The draft states > that it MAY be used whil

Re: Replace "seamless" with "stateless"

On Tue, May 03, 2016 at 03:08:18PM +0530, Manav Bhatia wrote: > I am also with Les -- it'll make a great story to tell the kids some day on > what we were sniffing when we came up with "seamless" ! :-) > > Matter closed. Lets move on to addressing the IESG comments now. For the record, the reason

IETF 96 - shall we meet?

IETF 96 will be convening in Berlin July 17-22. BFD has not met recently, but our face to face meetings are driven by the need to advance work via in-person discussion. The chairs' perceived status of the Working Group is tracked on our wiki: https://wiki.tools.ietf.org/wg/bfd/trac/wiki Most of

Re: IETF 96 - shall we meet?

On Wed, May 11, 2016 at 12:35:46PM -0400, Jeffrey Haas wrote: > If you believe you have an agenda item that's cause for the Working Group to > meet, please respond to this thread. With in and out of thread responses, I think we have enough agenda items to meet. I have requested

Re: IETF 96 - shall we meet?

Mahesh, On Wed, May 11, 2016 at 09:58:45AM -0700, Mahesh Jethanandani wrote: > > - Optimizing BFD Authentication - needs further discussion with security > > minded IETFers. > > And possibly a presentation in one of the other security focused WG?? Could the authors please kick off the necessary

Re: IETF 96 - shall we meet?

On Fri, May 13, 2016 at 04:23:21PM -0400, Jeffrey Haas wrote: > On Wed, May 11, 2016 at 12:35:46PM -0400, Jeffrey Haas wrote: > > If you believe you have an agenda item that's cause for the Working Group to > > meet, please respond to this thread. > > With in and out of

NomCom 2016-2017 Call for Volunteers

BFD, If you've ever wanted to get more involved in IETF, nomcom is an excellent way to do so. They're looking for volunteers! -- The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random

De-chartering draft-ietf-bfd-mpls-mib

BFD and MPLS Working Groups, Back in November of last year, BFD polled to see what should become of the chartered work for a MIB providing MPLS extensions for the base BFD MIB. At that time, we didn't find any support for bringing the MIB forward for last call. Interest in MIBs has obviously bee

Re: RFC 7880 on Seamless Bidirectional Forwarding Detection (S-BFD)

Congratulations to the working group on RFCs 7880-7886 for Seamless BFD. This wraps up a very large bit of Working Group work. -- Jeff On Tue, Jul 12, 2016 at 05:48:04PM -0700, rfc-edi...@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > >

IETF 96 - Agenda

Working Group, A tentative agenda has been posted: https://datatracker.ietf.org/meeting/96/agenda/bfd/ -- Jeff

Candidate minutes for the IETF-96 (Berlin) BFD meeting

Working Group, https://www.ietf.org/proceedings/96/minutes/minutes-96-bfd Ignas Bagdonas did his usual immaculate job at taking minutes for our session in Berlin. Please review them for correctness and content. The deadline for comments is this Friday, July 29. -- Jeff & Reshad

Re: WG adoption poll on draft-nitish-vrrp-bfd-04

Greg, Section 4 (of version -04) only deals with p2mp BFD and section 3 provides a unicast solution. If your employer can issue an appropriate clarification that section 3 is not covered, it's possible the draft might be able to proceed. Procedures in section 4 can always be covered in a diff

Re: Request to review "Security enhancments for BFD packet's sequence number"

On Thu, Feb 23, 2017 at 10:12:51PM -0800, Mahesh Jethanandani wrote: > What Sonal means to ask if for folks to review the draft. > > https://tools.ietf.org/html/draft-sonal-bfd-secure-sequence-numbers-00.txt > > The abstract of which reads: > > This document describes a security enhancement

Re: New Version Notification for draft-ietf-bfd-optimizing-authentication-02.txt

This update is scheduled to be discussed at the upcoming session at IETF-98 in Chicago. The likely discussion is whether the new draft from Sonal should be specifically tied to the advancement of the optimization draft. Our prior discussion with Alan had suggested some concern about the sequenc

Adoption request for draft-tanmir-rtgwg-bfd-mc-lag

We had presentations on draft-tanmir-rtgwg-bfd-mc-lag-(mpls|ip) during IETF 96. This work covers multi-chassis forms of BFD-on-LAG, similar to RFC 7130. After that presentation, the sense of the room was that this work was something the WG would like to adopt. This e-mail begins a formal adoption

Re: Correcting BFD Echo model

[continuing the top-posting heresy to preserve context] Greg, Our schedule is relatively open right now, and this matter is esoteric enough that it probably warrants a slide for the majority of the Working Group to follow this issue. Would you prepare a slide or two to use as a discussion point?

Re: I-D Action: draft-ietf-bfd-yang-05.txt

Authors, Thanks for continued work on the yang module. It does appear it's approaching a good level of maturity! I have a few comments from my recent read-through. I'd like to encourage other members of the Working Group to review the module. I'd also like to encourage the authors to reach out

Re: Correcting BFD Echo model

> On Mar 24, 2017, at 3:09 PM, Greg Mirsky wrote: > > Hi Carlos, > indeed, the RFC 5880 does explain that the rate of BFD control packets > transmitted in Async mode may be reduced when Echo is activated. If anyone is > familiar with such implementation, I'd be glad to learn and discuss how th

Draft minutes for IETF 98, Chicago

Working Group, Thank you for your patience for the minutes and action items from the Working Group session in Chicago. The draft minutes are available at the following: https://www.ietf.org/proceedings/98/minutes/minutes-98-bfd-00 Please submit any proposed edits to the minutes by this Friday,

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

Working Group, As part of our discussion at the Working Group session at IETF 98 in Chicago, Sonal Agarwal presented "Secure BFD Sequence Numbers" (draft-sonal-bfd-secure-sequence-numbers-00). This work complements a problem space the Security area had asked us to address as part of the work on o

Adoption call for draft-ashesh-bfd-stability (ends April 30, 2017)

Working Group, https://tools.ietf.org/html/draft-ashesh-bfd-stability-05 The authors of BFD Stability (draft-ashesh-bfd-stability), presented their latest changes at IETF 98 in Chicago and have requested working group adoption. Please indicate your support or lack of support to the mailing list.

Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017)

Working Group, https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00 https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-mpls/ The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for IP and MPLS have requested BFD working group adoption for their drafts. Thes

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

ly-To: LuHuang mailto:hlisn...@yahoo.com>> > Date: Monday, April 17, 2017 at 9:19 PM > To: Jeffrey Haas mailto:jh...@pfrc.org>>, > "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" > mailto:rtg-bfd@ietf.org>> > Cc: Reshad mailto:rrah...@cisco.com>>, "So

Adoption calls in progress, please respond (target April 30, 2017)

Working Group, This is a reminder we have adoption calls in progress for the following documents: draft-tanmir-rtgwg-bfd-mc-lag-* draft-sonal-bfd-secure-sequence-numbers draft-ashesh-bfd-stability The adoption call is scheduled to end on April 30. It'd be good to get further feedback on whethe

Draft of interest to BFD WG - draft-li-idr-bgp-ls-sbfd-extensions

The following draft is of interest to the BFD group. It carries S-BFD discriminators in BGP-LS. Quick note to the authors: You did well in avoiding code point squatting, but left one artifact in there. Type - S-BFD Discriminator TLV Type (11) :-) -- Jeff - Forwarded message from IETF S

Re: Questions related to single-hop IP BFD over IPv6

Sasha, On Thu, May 18, 2017 at 02:13:51PM +, Alexander Vainshtein wrote: > I have several questions dealing with single-hop IP BFD sessions over IPv6. > So far I have failed to find clear answers to these questions in RFC > 5881. > > > 1. Is it po

Re: IETF OSPF YANG and BFD Configuration

this and it took some time to make the decision. > > Regards, > Reshad (as individual contributor). > > From: Mahesh Jethanandani > mailto:mjethanand...@gmail.com>> > Date: Thursday, May 18, 2017 at 5:34 PM > To: "Acee Lindem (acee)" mailto:a...@cisco.com>>

WG not meeting at IETF-99 (Prague)

Working Group, BFD will not be meeting at IETF-99 in Prague. There's however the usual room for side meetings relating to BFD. We do have active items for the Working Group to provide feedback on. The chairs would love it if we moved progress forward on these: draft-ietf-bfd-yang draft-ietf-bf

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

Working Group, https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04 The BFD Multipoint documents have been stable for some time. Prior discussion at meetings has suggested we have an implementation for the main protocol c

Re: IETF OSPF YANG and BFD Configuration

Mahesh, On Mon, Jun 19, 2017 at 03:11:25PM -0700, Mahesh Jethanandani wrote: > > On Jun 19, 2017, at 11:57 AM, Jeffrey Haas wrote: > > Where we run into some issues are the cases highlighted: when the sessions > > don't share common properties, how should the protoco

Re: IETF OSPF YANG and BFD Configuration

Acee, On Mon, Jun 19, 2017 at 10:10:43PM +, Acee Lindem (acee) wrote: > I don’t really feel there is a strong requirement to support different > timers values per protocol even though several implementations allow > different protocol specific values to be configured (with varying > behaviors)

Re: IETF OSPF YANG and BFD Configuration

Les, On Tue, Jun 20, 2017 at 02:25:12PM +, Les Ginsberg (ginsberg) wrote: > > Different protocols have different survivability requirements. An IGP may > > very well want sub-second timers, potentially for repair behaviors. BGP may > > want fast failover, but may be fine with second level gr

Re: IETF OSPF YANG and BFD Configuration

tations that permit such configuration, potentially at protocol scope. It also doesn't fit the future-proofing thought. -- Jeff > > Regards, > Greg > > On Mon, Jun 19, 2017 at 1:57 PM, Jeffrey Haas wrote: > > > [Long delayed response.] > > > > Reshad p

Re: IETF OSPF YANG and BFD Configuration

On Tue, Jun 20, 2017 at 02:48:51PM -0500, Greg Mirsky wrote: > Hi Jeff, > thank you for the great summary of the discussion, helps me to catch the > wave. > I'm skeptical that there's realistic scenario where two BFD systems will be > requested to run multiple BFD single-hop session between them ov

Re: I-D Action: draft-ietf-bfd-yang-06.txt

Thanks authors for the edits on the BFD yang module. This gets us a significant step closer to alignment with the rest of IETF for network instancing. I'd like to encourage the working group to provide feedback on this issue and also the changes in the module. As noted in another thread, we stil

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

org/html/draft-ietf-bfd-multipoint-10#section-4.4.1 > > bfd.SilentTail > > Thanks! > > — Carlos. > > > On Jun 19, 2017, at 3:39 PM, Jeffrey Haas > mailto:jh...@pfrc.org>> wrote: > > Working Group, > > https://tools.ietf.org/html/draft-ietf-

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

twork by suggesting that > MultipointTail sessions created only for known combination of > MultipointHead and My Discriminator. Such information MAY be learned > from out-of-band and mechanisms are outside the scope of this > document. > > > Regards, > > Gre

Re: I-D Action: draft-ietf-bfd-yang-06.txt

On Fri, Jul 28, 2017 at 03:58:06PM -0700, Mahesh Jethanandani wrote: > The changes are done and pushed to GitHub. Use the grouping client-cfg-parms. Question: For implementations that use Echo mode, is that something the protocol client configuration impacts or is it chosen by the system automatic

Re: I-D Action: draft-ietf-bfd-yang-06.txt

On Sun, Jul 30, 2017 at 05:14:28PM +, Yingzhen Qu wrote: > Please see attached ospf bfd module. Base ospf module also needs to be > updated to remove the bfd enable leaf. ISIS model need to do the same change, > ietf-isis-bfd.yang will look the same as ietf-ospf-bfd.yang. > > Please let me k

Re: A question about RFC5884

On Tue, Jul 18, 2017 at 10:25:38AM +, Carlos Pignataro (cpignata) wrote: > I had not suggested it, but I think that idea has merit. If there are enough > updates needed to the spec based on additional running-code learning, or > ambiguities that are causing interoperable confusion, the net of

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

on of the base multipoint spec. Once we've received that review, we can continue in our deliberations. -- Jeff On Mon, Jun 19, 2017 at 03:39:29PM -0400, Jeffrey Haas wrote: > Working Group, > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 > https://tools.ietf.o

Re: Fwd: I-D Action: draft-chen-bfd-unsolicited-01.txt

Working Group, This draft was briefly mentioned as part of the IDR WG presentation on RS-BFD that I am a co-author on. That presentation is supposed to be linked here, but is not coming up. Hopefully it's a transient error: https://datatracker.ietf.org/meeting/99/materials/slides-99-idr-03-idr-

Re: I-D Action: draft-ietf-bfd-yang-06.txt

Mahesh, > On Jul 31, 2017, at 4:26 PM, Mahesh Jethanandani > wrote: > > Jeff, > >> On Jul 31, 2017, at 10:05 AM, Jeffrey Haas wrote: >> >> On Fri, Jul 28, 2017 at 03:58:06PM -0700, Mahesh Jethanandani wrote: >>> The changes are done and pushed t

Re: I-D Action: draft-ietf-bfd-yang-06.txt

Ashesh, On Mon, Jul 31, 2017 at 09:39:57PM +, Ashesh Mishra wrote: > From what I understand, the echo intervals have an inverse relationship with > their control interval counterparts. Faster echo allows for slower control > frame rate. So they are necessarily different values. That said, ha

Re: I-D Action: draft-ietf-bfd-yang-06.txt

Mahesh, On Mon, Jul 31, 2017 at 05:17:34PM -0700, Mahesh Jethanandani wrote: > > My point, unless my very quick glance at the module mislead me, is that you > > can't configure to use echo mode - if it's supported - in the grouping > > imported by the IGPs. > > In the current model, it is model

Re: I-D Action: draft-ietf-bfd-yang-06.txt

On Tue, Aug 01, 2017 at 08:33:38AM -0700, Mahesh Jethanandani wrote: > > I'm ambivalent. This depends really on real world behavior. > > > > As we saw from some brief googling yesterday on Cisco IOS/IOS-XR docs, that > > implementation doesn't appear to expose echo intervals as a separably > > co

Re: I-D Action: draft-ietf-bfd-yang-06.txt

On Tue, Aug 01, 2017 at 05:52:01PM -0700, Mahesh Jethanandani wrote: > I will be uploading the changes shortly. Are we at the point where we should look at the model contents again? -- Jeff

Re: [Technical Errata Reported] RFC5884 (5085)

[Note that I have adjusted the addresses in the headers to try to catch the RFC authors' current accounts.] The 5884 interop issue keeps bubbling up. Balaji submitted an errata, which provides us with a good place to start technical discussion. Please note I also spent some time off-list discus

BFD WGLC on BFD multipoint features (trill)

Trill WG, I was recently reminded that trill has an interest in the BFD multipoint features. (C.f. RFC 7175.) The BFD Multipoint features are in extended working group last call. Your input on the documents is solicited: https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 https://tools.ie

Re: I-D Action: draft-ietf-bfd-yang-06.txt

> On Aug 14, 2017, at 11:24 AM, Reshad Rahman (rrahman) > wrote: > > I am gradually catching up to emails so I may not have absorbed all the > emails I have gone through yetŠ. > > Regarding echo config, we agreed in Chicago to remove the echo config > based on the fact that implementations of

Re: Rtgdir last call review of draft-ietf-bfd-unaffiliated-echo-11

> On Sep 27, 2024, at 4:44 AM, xiao.m...@zte.com.cn wrote: > > Section 4, question... > > Could an attacker interpose themselves between the two nodes and perform > loopback? Loopback is an easy function with no requirement to generate > any additional security, so it is easier than impersonati

Re: [Last-Call] Secdir last call review of draft-ietf-bfd-unaffiliated-echo-11

Note that I agree wholeheartedly with this analysis. The scenario Stephen points out is a reflection attack, and thus potentially has a role in obscuring the attacker, but it is NOT an amplification attack. The device providing the looping service is simply acting as a forwarding router. The

Re: Alternate AD review of draft-ietf-bfd-large-packets-11

[Response to original mail to track the main points.] Thanks for your patience for this next update. My responses here will be reflected in an updated version that will ship in parallel with this email. > On Aug 14, 2024, at 7:58 AM, Eric Vyncke (evyncke) wrote: > > Dear BFD, dear authors, >

Re: UDP Guidelines and draft-ietf-bfd-unaffiliated-echo-12

Gorry, > On Oct 16, 2024, at 3:02 AM, Gorry Fairhurst wrote: > > On 15/10/2024 22:11, Jeffrey Haas wrote: >> Gorry, >> >> On Tue, Oct 15, 2024 at 05:26:04PM +0100, Gorry Fairhurst wrote: >>> I have a few comments, but i am not a routing expert, so I'm

Re: [Last-Call] Tsvart telechat review of draft-ietf-bfd-unaffiliated-echo-12

Brian, > On Oct 16, 2024, at 1:31 AM, Brian Trammell (IETF) wrote: > > hi Erik, > > Thanks for the clarifications. Xiao, please take this reply as a reply to > your own request for an amendment to this review; tl;dr the recommendations > to the authors, WG, and IESG change in their details b

Re: Roman Danyliw's Discuss on draft-ietf-bfd-unaffiliated-echo-12: (with DISCUSS and COMMENT)

Roman, On Wed, Oct 16, 2024 at 06:24:10AM -0700, Roman Danyliw via Datatracker wrote: > -- > DISCUSS: > -- > > (For the BFD WG chairs and responsible AD) This do

Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unaffiliated-echo-12: (with DISCUSS and COMMENT)

Zahed, > On Oct 18, 2024, at 1:19 PM, Zaheduzzaman Sarker > wrote: > > Perhaps the following: > >All Operational Considerations from [RFC5880] apply. Since this > mechanism leverages existing BFD machinery, particularly periodic pacing of > traffic based on configuration, there's no real

Re: Mahesh Jethanandani's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT)

Mahesh, > On Oct 16, 2024, at 7:23 PM, Mahesh Jethanandani > wrote: > >> On Oct 16, 2024, at 12:15 PM, Jeffrey Haas > <mailto:jh...@pfrc.org>> wrote: >> >> Mahesh, >> >> >>> On Oct 16, 2024, at 2:41 PM, Mahesh Jethanandani >&

Re: [Last-Call] Tsvart telechat review of draft-ietf-bfd-unaffiliated-echo-12

Brian, > On Oct 16, 2024, at 3:05 PM, Brian Trammell (IETF) wrote: > Okay, I get it now. > > That’s *weird*, or certainly weird enough to my layer-4-addled brain that I > didn’t get it on my admittedly relatively quick pass through 5880, and it > still fits fairly uncomfortably in my worldvi

Re: Mahesh Jethanandani's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT)

Mahesh, > On Oct 16, 2024, at 2:41 PM, Mahesh Jethanandani > wrote: >> It specifies the use of the Unaffiliated BFD Echo over >>IPv4 and IPv6 for a single IP hop. The reason why it cannot be used for >> multihop paths is that the Unaffiliated BFD Echo packets would be looped >> back by t

Re: Alternate AD review of draft-ietf-bfd-large-packets-11

Thanks, Reshad. Éric, I think this means all outstanding items are addressed and we can progress the document to the next step? -- Jeff > On Oct 15, 2024, at 11:17 AM, Reshad Rahman wrote: > > Eric, Jeff, > > > On Friday, October 11, 2024 at 12:00:39 PM EDT, Jeff

Re: [Last-Call] Tsvart telechat review of draft-ietf-bfd-unaffiliated-echo-12

Brian, > On Oct 16, 2024, at 1:39 PM, Brian Trammell (IETF) wrote: >> On 16 Oct 2024, at 18:54, Erik Auerswald wrote: >> On Wed, Oct 16, 2024 at 12:28:46PM -0400, Jeffrey Haas wrote: >> Every described abuse scenario that works with Unaffiliated BFD Echo also >> work

Re: Alternate AD review of draft-ietf-bfd-large-packets-11

Éric, The following edits are ready for submission. Confirm these are what you want in -13 and they'll go out. -- Jeff > On Oct 17, 2024, at 2:29 AM, Eric Vyncke (evyncke) wrote: > > Jeff and other authors, > > Thanks for your patience on this one. > > Except for the point below EVY2>,

Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unaffiliated-echo-12: (with DISCUSS and COMMENT)

Zahed, > On Oct 17, 2024, at 8:52 AM, Zaheduzzaman Sarker via Datatracker > wrote: > -- > DISCUSS: > -- > > Thanks for working on this specificaition. This is

Re: [Last-Call] Tsvart telechat review of draft-ietf-bfd-unaffiliated-echo-12

draft-ietf-bfd-unaffiliated-echo, U-BFD is applicable in, for > example, VXLAN, what would happen to the looped packet? I seems like it > will be routed through the underlay network. AFAICS, that is not part of > BFD Echo function per RFC 5880. > > Regards, > Greg > > On We

Re: [Last-Call] Tsvart telechat review of draft-ietf-bfd-unaffiliated-echo-12

to n (254?). All other packets MUST be > discarded, but MAY be logged applying a rate limit to not overload the > logging system. > > Cheers, > Adrian > > From: Jeffrey Haas > Sent: 17 October 2024 20:18 > To: Greg Mirsky > Cc: Brian Trammell (IETF) ; Erik Au

Re: [Last-Call] Tsvart telechat review of draft-ietf-bfd-unaffiliated-echo-12

re > U-BFD specification is prudent and future-proof. > > Regards, > Greg > > On Thu, Oct 17, 2024 at 12:18 PM Jeffrey Haas <mailto:jh...@pfrc.org>> wrote: > Greg, > > Would you be satisfied to update the text to say this applies to RFC 5881 > IPv4/IPv6 sing

Re: Tsvart telechat review of draft-ietf-bfd-unaffiliated-echo-12

validating a packet by the remote system.Regards,GregOn Tue, Oct 15, 2024 at 2:17 PM Jeffrey Haas <jh...@pfrc.org> wrote:Greg, On Tue, Oct 15, 2024 at 01:54:04PM -0700, Greg Mirsky wrote: > Hi Brian, et al, > I share your concern regarding U-BFD proliferation on the Internet. F

Re: UDP Guidelines and draft-ietf-bfd-unaffiliated-echo-12

Gorry, On Tue, Oct 15, 2024 at 05:26:04PM +0100, Gorry Fairhurst wrote: > I have a few comments, but i am not a routing expert, so I'm maybe > misisng context on the intended use, and why this is a good thing to > allow > > I did not find a description of why this was needed. Like many IETF

Re: Tsvart telechat review of draft-ietf-bfd-unaffiliated-echo-12

Greg, On Tue, Oct 15, 2024 at 01:54:04PM -0700, Greg Mirsky wrote: > Hi Brian, et al, > I share your concern regarding U-BFD proliferation on the Internet. For > example, > https://datatracker.ietf.org/doc/draft-lin-bfd-path-consistency-over-sr/ > discusses using U-BFD over SR Policies, SRv6 and S

Re: Roman Danyliw's Discuss on draft-ietf-bfd-unaffiliated-echo-12: (with DISCUSS and COMMENT)

Roman, > On Oct 17, 2024, at 11:20 AM, Roman Danyliw wrote: > > Hi Jeff! > > Thanks for the analysis of the situation. > > The top line message I'm getting from your response is that > draft-ietf-bfd-unaffiliated-echo not being in scope of the BFD charter is not > in dispute, the question

Fwd: [121all] Final reminder - IETF 121 post-meeting survey

Please consider responding to the meeting survey. -- Jeff > Begin forwarded message: > > From: IETF Executive Director > Subject: [121all] Final reminder - IETF 121 post-meeting survey > Date: November 17, 2024 at 3:32:50 PM EST > To: 121...@ietf.org > > While IETF 121 Dublin is still fresh i

Re: Let's not forget about draft-ietf-bfd-unaffiliated-echo

Éric, As best I can tell, Zahed has token from last set of text Xiao Min proposed. It's worth repeated (again, and again...) that this mechanism has been not only shipping but has existed in commodity vendor silicon for some time. IMNSHO, Zahed's concerns are inappropriate. If this profile of

Re: Next steps after IETF Last Call of draft-ietf-bfd-large-packets

Éric, On Mon, Dec 09, 2024 at 04:49:32PM +, Eric Vyncke (evyncke) wrote: > Thanks for the super-fast reaction and the -14, which addresses most of the > points below (I am also unclear about Jürgen’s points tbh, I hoped that you > would know more). https://mailarchive.ietf.org/arch/msg/yang

<    1   2   3   4   5   6   >