Re: draft-ietf-bfd-optimizing-authentication-13 nits

> On Jan 20, 2024, at 7:45 PM, Alan DeKok wrote: > > On Jan 19, 2024, at 7:14 PM, Mahesh Jethanandani > wrote: >> In my mind, and my co-authors can correct me if my understanding is >> incorrect, I do not see "optimized auth" as a choice between "NULL-auth" and >> "secure-sequence" numbers

Re: draft-ietf-bfd-optimizing-authentication-13 nits

Correction for the pedants on the list. :-) > On Jan 21, 2024, at 3:37 PM, Jeffrey Haas wrote: > > > A reasonable procedure for an implementation of ISAAC is verifying that the > contents do not vary. For the BFD state machinery, any changes to those > fields is expected

Re: draft-ietf-bfd-optimizing-authentication-13 nits

Alan, > On Jan 21, 2024, at 8:09 PM, Alan DeKok wrote: > > On Jan 21, 2024, at 3:43 PM, Jeffrey Haas wrote: >>> i would lean towards forbidding "simple password", unless it uses a >>> different password than is used for the stronger authentication met

Re: draft-ietf-bfd-optimizing-authentication-13 nits

> On Jan 21, 2024, at 8:23 PM, Alan DeKok wrote: > > (removing optimizing authentication) > >> On Jan 21, 2024, at 3:37 PM, Jeffrey Haas wrote: >> I'd not pushed for those details to be spelled out because the only >> legitimate way an implementati

Re: draft-ietf-bfd-optimizing-authentication-13 nits

Mahesh, > On Jan 22, 2024, at 5:15 PM, Mahesh Jethanandani > wrote: > >> On Jan 19, 2024, at 4:14 PM, Mahesh Jethanandani > > wrote: >> At the same time, if 'secure-seq-num' is configured as ’true’, the sequence >> number is generated as defined by I-D.ietf-bfd

Re: I-D Action: draft-ietf-bfd-stability-11.txt

Authors, Thanks for the refresh on the stability document as we work toward winding up the authentication feature bundle. A few comment from the update using the id-nits line numbering: On Mon, Jan 22, 2024 at 04:50:53PM -0800, internet-dra...@ietf.org wrote: > Internet-Draft draft-ietf-bfd-stab

Re: draft-ietf-bfd-optimizing-authentication-13 nits

Mahesh, > On Jan 23, 2024, at 1:18 PM, Mahesh Jethanandani > wrote: > > I am proposing two config variables that I think that are pertinent to > optimized configuration, and I can put a small YANG model that augments BFD > YANG model to demonstrates it. They are: > > - optimized-auth flag:

Re: draft-ietf-bfd-optimizing-authentication-13 nits

Mahesh, I don't think we're too far off from each other's perspective. > On Jan 23, 2024, at 9:15 PM, Mahesh Jethanandani > wrote: > >> On Jan 23, 2024, at 10:30 AM, Jeffrey Haas > <mailto:jh...@pfrc.org>> wrote: > > I see that there is

Re: draft-ietf-bfd-optimizing-authentication-13 nits

> On Jan 25, 2024, at 6:39 PM, Mahesh Jethanandani > wrote: > >> On Jan 24, 2024, at 12:19 PM, Jeffrey Haas > <mailto:jh...@pfrc.org>> wrote: > Ok. I have added a couple of leafs. One is called ‘up-auth-type’ which is of > type iana-bfd-types:auth-type that

BFD for large packets

d@ietf.org Subject: I-D Action: draft-ietf-bfd-large-packets-03.txt Internet-Draft draft-ietf-bfd-large-packets-03.txt is now available. It is a work item of the Bidirectional Forwarding Detection (BFD) WG of the IETF. Title: BFD Encapsulated in Large Packets Authors: Jeffrey Haas

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

12:09:02PM -0800, internet-dra...@ietf.org wrote: > Internet-Draft draft-ietf-bfd-large-packets-05.txt is now available. It is a > work item of the Bidirectional Forwarding Detection (BFD) WG of the IETF. > >Title: BFD Encapsulated in Large Packets > Authors: Jeffrey Haas >

Re: Optimizing Authentication - periodic re-authentication

Reshad, > On Jan 30, 2024, at 12:28 AM, Rahman wrote: > > Jeff, good catch. > > We can document both ways, ie we can let implementations decide which of the > 2 methods below they prefer? Or is the concern that this will cause a DISCUSS? Mahesh has proposed the fix for the next rev in this pu

Re: [mpls] Review of draft-mirsky-mpls-bfd-bootstrap-clarify

+bfd WG. Some original comments to Adrian were: https://mailarchive.ietf.org/arch/msg/rtg-bfd/SYouXfNrVyKHErqacOuM2fICzMc/ Apparently, Greg didn't consider this worth holding his peace over. https://www.rfc-editor.org

Re: bfd - Not having a session at IETF 119

While the session request tool downgraded our area director into one of the chairs, it's our intention to not meet at the upcoming IETF 119 in Brisbane. Current status of the working group is on the wiki: https://wiki.ietf.org/en/group/bfd It's our hope that

Re: bfd - Not having a session at IETF 119

> On Feb 5, 2024, at 1:12 AM, > wrote: > Just one small update to the wiki, the title of > draft-ietf-bfd-unaffiliated-echo has been changed from "Unaffiliated BFD Echo > Function" to "Unaffiliated BFD Echo" since -03 version. > > Fixed. :-) -- Jeff

BFD authentication package

Working Group, There's been a lot of behind the scenes work in github to try to get our bundle of authentication features completed. As of today: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-13

Re: BFD authentication package

Mahesh correctly points out that opt-13 is the 2022 version. The updated version from the recent github work should be published hopefully soon. -- Jeff (need. more. caffeine...) > On Feb 5, 2024, at 10:06 AM, Jeffrey Haas wrote: > > Working Group, > > There's been

Re: I-D Action: draft-ietf-bfd-optimizing-authentication-14.txt

Reshad, > On Feb 5, 2024, at 4:18 PM, Reshad Rahman > wrote: > > Hi, > > I've provided some comments to the authors privately, sharing them here to > restart/continue the discussion on the WG alias. > > My main technical concern is in the changes to BFD auth mode: when > transitioning to N

Attacking BFD with NULL auth

My thought over first cup of caffeine for the morning: You can have an active attacker attack a session using NULL auth and knock over a BFD session. This is counter to the usual "silly" attack of keeping BFD Up. Presume the session is in the Up state between A and B and using NULL auth. The

Re: Attacking BFD with NULL auth

John, > On Feb 6, 2024, at 11:00 AM, John Scudder wrote: > > You’re assuming either an on-LAN attacker (and therefore, that BFD is being > used on a multiaccess medium) or multihop BFD here, I take it? Because RFC > 5881 tells me GTSM is required if there’s no other authentication. Correct.

Re: Attacking BFD with NULL auth

Reshad, > On Feb 6, 2024, at 11:51 AM, Reshad Rahman wrote: > > Jeff, you mention below that NULL auth with sequence numbers is impractical > to use for optimizing authentication. I agree that NULL auth doesn't help > with an active attacker, but it still gives protection against "random" >

Re: Attacking BFD with NULL auth

Reshad, > On Feb 7, 2024, at 12:21 PM, Reshad Rahman wrote: > >> ISAAC works for active attacks but I don't understand why no-auth still >> works, no-auth is weaker than NULL auth: you don't need to be an active >> attacker to knock over a session with no-auth? > > With no-auth, the only thi

Re: Attacking BFD with NULL auth

> On Feb 7, 2024, at 12:48 PM, Reshad Rahman wrote: > > Jeff, > > "No authentication also thus means you can't attack the system by sending a > sequence number". > > I agree. But you don't need a seq number with no auth, you just attack by > sending a packet to take the session down. That's

Resolving lingering issues with BFD authentication drafts

Here's an attempt to provide a path to resolve the lingering issues in the authentication drafts. Core lingering issues: - The NULL auth method is attackable, but still potentially useful for the stability procedures. - The optimization procedures currently can have BFD go Up with the initial

Re: Resolving lingering issues with BFD authentication drafts

Reshad, > On Feb 25, 2024, at 5:31 PM, Reshad Rahman wrote: > > Jeff, overall this looks to be a good way forward, it addresses the main > concern I had expressed. Excellent. > On Friday, February 23, 2024, 04:32:55 PM EST, Jeffrey Haas > wrote: > - The optimization

Re: Resolving lingering issues with BFD authentication drafts

Reshad, > On Feb 29, 2024, at 2:36 PM, Reshad Rahman wrote: > > Jeff, > > The only thing I am still a bit hesitant about is delaying the notification > to the BFD clients (that the session is up) until we've successfully moved to > the optimized mode. It's not the actual delay, which should

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

ill go down if the peer does not support > large BFD packets. > A security section for the YANG is needed, and the impact of setting leaf > pdu-size (as stated above).  Done! -- Jeff > Regards,Reshad. > On Tuesday, January 30, 2024, 03:13:03 PM EST, Jeffrey Haas > wrote:

BFD at IETF 120?

Working Group, IETF 120 will be happening in Vancouver in July. For the last several sessions, we've not had a need to meet as we were slowly working through our lingering working group items. https://wiki.ietf.org/group/bfd/current-activities

Fwd: Nomcom 2024-2025 Second Call For Volunteers

Please consider volunteering for the IETF nomination committee. -- Jeff > Begin forwarded message: > > From: NomCom Chair 2024 > Subject: Nomcom 2024-2025 Second Call For Volunteers > Date: May 20, 2024 at 8:43:09 AM EDT > To: "IETF Announcement List" > Reply-To: nomcom-chair-2...@ietf.org >

Re: I-D Action: draft-ietf-bfd-secure-sequence-numbers-15.txt

Reshad, With this last update from Alan, we've completed the lingering work to be able to move the authentication cluster of documents forward. Shall we move on to working group last call? -- Jeff > On May 20, 2024, at 6:56 PM, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-bf

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

Mach, Thanks for the comment. I believe it's the case that the abbreviations that haven't been expanded fall under the RFC Editor's well known abbreviations: https://www.rfc-editor.org/materials/abbrev.expansion.txt Note the category with the asterisk (*) character that they are fine with not

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

> On May 21, 2024, at 2:40 AM, Les Ginsberg (ginsberg) > wrote: > > Sooo…this was a real “blast-from-the-past” for me. > Over four years went by with no public updates – and in looking at the diffs > between the latest version and V2 (which is where the discussion ended for > me) it seems th

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

Thanks, Robert. As you note, the document notes the existing issues, and the existing room for vendor ability to deal with this in implementations. Reshad and I have briefly chatted about ecmp considerations may be appropriate work for BFD to pursue as a new task. -- Jeff > On May 9, 2024,

Re: Yangdoctors last call review of draft-ietf-bfd-large-packets-07

Jürgen, On Wed, May 22, 2024 at 11:32:05AM +0200, Jürgen Schönwälder wrote: > On Mon, May 13, 2024 at 06:37:15PM +, Jeff Haas wrote: > > How about the following? > > > > description > > - "The padded PDU size for the encapsulated BFD control packets. > > - The minimum size is

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

Greg, On Tue, May 21, 2024 at 05:08:15PM -0700, Greg Mirsky wrote: > Dear Authors et al., > thank you for delivering a well-written and useful specification. I support > the publication of the draft. One minor note on wording used in Section > 4.3. I interpret "both sides of an interface", "each s

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

Action: draft-ietf-bfd-large-packets-08.txt Internet-Draft draft-ietf-bfd-large-packets-08.txt is now available. It is a work item of the Bidirectional Forwarding Detection (BFD) WG of the IETF. Title: BFD Encapsulated in Large Packets Authors: Jeffrey Haas Albert Fu Name

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

ports A YANG Data Model for Routing [RFC8349], and >YANG Data Model for Bidirectional Forwading Detection (BFD) >[RFC9314]. > > file "ietf-bfd-la...@-mm-dd.yang" > INSERT_TEXT_FROM_FILE(../bin/ietf-bfd-la...@-mm-dd.yang,69) > > > On

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

Reshad, On Wed, May 22, 2024 at 08:12:47PM +, Reshad Rahman wrote: > - Section 4.2: do we need 2119 language for the following paragraph and > should the should be a MUST? >In the case multiple BFD clients desire to test the same BFD >endpoints using different bfd.PaddedPduSize parame

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

Reshad, > On May 23, 2024, at 12:47 PM, Reshad Rahman wrote: >> On Wednesday, May 22, 2024, 06:21:50 PM EDT, Jeffrey Haas >> wrote: >> On Wed, May 22, 2024 at 08:12:47PM +, Reshad Rahman wrote: >> > - Section 4.2: do we need 2119 language for the following

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

> On May 23, 2024, at 3:10 PM, Reshad Rahman wrote: > Good with me, I'll approve the PR. These comments addressed in -10. -- Jeff

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

Hopefully this addresses Alan's comments: https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-large-packets-11 -- Jeff > On May 27, 2024, at 3:26 PM, Reshad Rahman > wrote: > > Authors, I believe you have respo

Re: WGLC for the 3 BFD auth documents and IPR check

Since I'm now an author on optimizing authentication: I'm not aware of any applicable IPR. -- Jeff > On Jun 3, 2024, at 9:29 PM, Reshad Rahman > wrote: > > BFD WG, > > This email starts a 2 week Working Group Last Call for the following 3 > documents, please review and provide comments by

Fwd: Nomcom 2024-2025 Third Call For Volunteers

> Begin forwarded message: > > From: NomCom Chair 2024 > Subject: Nomcom 2024-2025 Third Call For Volunteers > Date: June 6, 2024 at 1:55:22 PM EDT > To: "IETF Announcement List" > Cc: i...@ietf.org > Reply-To: nomcom-chair-2...@ietf.org > > The IETF tools development team identified an error

Re: Secdir early review of draft-ietf-bfd-large-packets-11

Joseph, Thanks for the review. Unfortunately, I think your comments run contrary to the entire nature of the draft. :-) > On Jun 7, 2024, at 10:43 AM, Joseph Salowey via Datatracker > wrote: > The document is well written and fairly simple. Referencing the previous > security considerations

Re: Secdir early review of draft-ietf-bfd-stability-13

Christian, Thanks for your review. Some of my comments will overlap those from Alan. On Fri, Jun 07, 2024 at 09:54:57PM -0700, Christian Huitema via Datatracker wrote: > The authentication sequence number is a 32 bit field. Such numbers can roll > over, either after a long duration session or d

Re: Secdir early review of draft-ietf-bfd-stability-13

Christian, On Mon, Jun 10, 2024 at 05:11:17PM -0700, Christian Huitema wrote: > On 6/10/2024 9:22 AM, Jeffrey Haas wrote: > >For our authentication purposes, without the presence of some sort of > >computed digest across the packet, NULL authentication means that an active > &

Re: Secdir early review of draft-ietf-bfd-stability-13

Christian, On Tue, Jun 11, 2024 at 11:36:13AM -0700, Christian Huitema wrote: > On 6/11/2024 7:03 AM, Jeffrey Haas wrote: > >And again, sequence rollover for replay has the presumption that you're > >using exactly the same contents for the BFD PDU. The procedures fo

Re: Secdir early review of draft-ietf-bfd-stability-13

Christian, Reshad, > On Jun 13, 2024, at 12:41 PM, Christian Huitema wrote: > On 6/13/2024 8:46 AM, Reshad Rahman wrote: >> Was there any consideration to change the procedure to increment the >> loss count so that if we get 1-3-2-4, we increment loss count when we >> receive 3 (2 is deemed l

Re: Secdir early review of draft-ietf-bfd-optimizing-authentication-16

Stephen, Thanks for your review. On Jun 17, 2024, at 9:54 AM, Stephen Farrell via Datatracker wrote: > > Generally the idea seems to be to avoid spending CPU on hashing except for > cases where the > state changes, and with periodic checks that BFD auth is still working. That > seems like an

Re: draft-ietf-bfd-secure-sequence-numbers (WGLC for the 3 BFD auth documents and IPR check)

> On Jun 13, 2024, at 2:49 PM, Alan DeKok wrote: > > On Jun 13, 2024, at 11:04 AM, Reshad Rahman > wrote: > >> Section 6 >> >> - "The Auth Type field MUST be set to TBD1 (Meticulous Keyed ISAAC)". There >> is no IANA registration for just ISAAC anymore, so it will be one of the 2 >> aut

Re: draft-ietf-bfd-optimizing-authentication (WGLC for the 3 BFD auth documents and IPR check)

draft-ietf-bfd-optimizing-authentication-17 has been published with the comments to date addressed. -- Jeff > On Jun 19, 2024, at 2:51 PM, Jeffrey Haas wrote: > > Reshad, > > The pending changes covered in addressing your comments are currently in this > github pul

Re: [secdir] Secdir early review of draft-ietf-bfd-optimizing-authentication-16

Christian, > On Jul 1, 2024, at 3:38 PM, Christian Huitema wrote: > > The issue of selective authentication is interesting. After reviewing > draft-ietf-bfd-stability-13, we had some discussion of attacks made possible > by spoofing BFD packets, and specifically spoofing their sequence number

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

Éric, I'm deep in the last stages of getting some important day-job stuff out the door, so the edits may linger for a little bit. But let me at least answer the questions portion. Note that this draft's text is checked into github as noted in the datatracker. Many of your edits could have av

IETF 92 - Get your slides in!

Working Group, http://www.ietf.org/proceedings/92/agenda/agenda-92-bfd We meet very early during IETF 92. Now is a *great* time to send the chairs your slides to post. -- Jeff

[rfc-edi...@rfc-editor.org: RFC 7492 on Analysis of Bidirectional Forwarding Detection (BFD) SecurityAccording to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines]

Thanks to the reviewers in BFD for supporting this KARP work. -- Jeff - Forwarded message from rfc-edi...@rfc-editor.org - Date: Wed, 18 Mar 2015 13:05:11 -0700 (PDT) From: rfc-edi...@rfc-editor.org To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org Subject

Candidate minutes for IETF92 BFD session

https://www.ietf.org/proceedings/92/minutes/minutes-92-bfd Please review and send comments. -- Jeff and Nobo

BFD generic crypto/sha documents

https://datatracker.ietf.org/doc/draft-ietf-bfd-hmac-sha/ https://datatracker.ietf.org/doc/draft-ietf-bfd-generic-crypto-auth/ The following documents have expired and could use a refresh. Mail to the document aliases have yielded multiple bounces. :-) -- Jeff

Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications

The BFD mailing list has been quiet since shortly after IETF 92. We have a number of documents that seem stable and ready to advance. This email begins a two week Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications-01, Clarifications to RFC 5884. This last call will end on May 15.

WG adoption of draft-spallagatti-bfd-multipoint-active-tail

Working Group, Nobo and I discussed the disposition of draft-spallagatti-bfd-multipoint-active-tail. Since the document was a fork of content from an adopted Working Group document and is intended for Proposed Standard, we are summarily adopting the draft. Santosh, please re-issue the draft a

Re: S-BFD Document Status

Carlos, Sorry, I appear to have missed this via mail glitch. Nobo brought my attention to this message. > Hi, BFD Chairs, > > The first set of S-BFD documents (-base, -ip, and -use-cases) have been > stable for a while. > > Looking at the Milestones [1], the WG is past due on submitting these

WGLC for draft-ietf-bfd-seamless-base

Working Group, This is to start a two week Working Group Last Call for draft-ietf-bfd-seamless-base, Seamless Bidirectional Forwarding Detection (S-BFD) [-base]. This WGLC ends on May 15. Please indicate to the mailing list whether you believe this document is ready to advance. Simultaneously,

WGLC for draft-ietf-bfd-seamless-ip

Working Group, This begins a two week Working Group Last Call for draft-ietf-bfd-seamless-ip, Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS. This WGLC ends on May 15. Simultaneously, this also is a request for statements of IPR related to this draft. Authors, pleas

WGLC-redeux for draft-ietf-bfd-seamless-use-case (was Re: Mail regarding draft-ietf-bfd-seamless-use-case)

Working Group, As of the prior last call, we were slightly short of support to progress the document and little review. The chairs decision was that in light of the more extensive review from Eric Gray, we had enough coverage to progress the document. In order to give the working group a chance

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

Authors, we still need your IPR declarations. On Mon, May 04, 2015 at 04:20:50PM -0400, Jeffrey Haas wrote: > Working Group, > > This is to start a two week Working Group Last Call for > draft-ietf-bfd-seamless-base, Seamless Bidirectional Forwarding Detection > (S-BFD) [-base].

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

Authors, we still need your IPR declarations. On Mon, May 04, 2015 at 04:23:54PM -0400, Jeffrey Haas wrote: > Working Group, > > This begins a two week Working Group Last Call for > draft-ietf-bfd-seamless-ip, Seamless Bidirectional Forwarding Detection > (S-BFD) for IPv4, IPv6

Re: Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications

o the document moving forward. -- Jeff On Mon, May 04, 2015 at 03:58:05PM -0400, Jeffrey Haas wrote: > The BFD mailing list has been quiet since shortly after IETF 92. We have a > number of documents that seem stable and ready to advance. > > This email begins a two week Working Gr

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

On Fri, May 15, 2015 at 04:23:12PM -0400, Jeffrey Haas wrote: > Authors, we still need your IPR declarations. Which also teaches me to be careful about emptying my inbox prior to response. Note that there is a Cisco IPR filed on seamless bfd: https://datatracker.ietf.org/ipr/2595/ Note t

Status of WGLCs

The S-BFD documents - use cases, base and IP - have passed WGLC. However, there are authors who still haven't made their IPR attestations. Thus the S-BFD documents are in a holding pattern until we get these last attestations. For draft-ietf-bfd-rfc5884-clarifications, we still haven't gotten

[nomcom-chair-2...@ietf.org: Third and FINAL call for volunteers, Nomcom 2015-2016]

I did a stint on nomcom not that long ago. If you've ever been curious about some of the deep details about how IETF operates, you'll get your fill. You'll also help choose our leadership for open terms. -- Jeff - Forwarded message from NomCom Chair 2015 - Date: Mon, 15 Jun 2015 02:5

Re: FW: New Version Notification for draft-ashesh-bfd-stability-03.txt

Santosh, Thanks for the update. A few comments upon my most recent reading of the draft: - Please consider starting the auth-key-id at 1 rather than 0 and leave 0 reserved. - You don't document the sender timestamp format. :-) Going back to prior discussion from the Working Group, you probab

IETF 93, shall we meet?

Working Group, IETF 93 is proving to be very popular, and the IETF has more requests for timeslots than can be possibly served from the pool of available ones. I had registered the WG for its usual 1 hour session a few weeks ago. Given the competition for scheduling, I must ask you all this ques

Re: IETF 93, shall we meet?

Santosh, On Tue, Jun 16, 2015 at 01:40:52PM +, Santosh P K wrote: > Jeff, >I have BFD over VXLAN to present in coming IETF. I have plans presenting > this both in Nov3 and BFD working group. Thus far, yours is the only real presentation request. Your proposal is pretty straight forward

IETF-93 BFD canceled

Working Group, We were a bit short of material that required discussion at the upcoming IETF session in Prague. Thus, I have canceled the meeting. I will be contacting Working Group members that have active work for status to be either added to the conference proceedings or posted to the WG wiki

List email etiquette and size warnings

This is where I perilously begin to look like an old man shaking his cane at the crowd saying, "back in my day..." IETF mail runs on a fairly simple plain-text mail redirection service. Our expected content is the contents of the message. The mailer intentionally limits the size of messages.

Re: S-BFD Documents Progress?

Carlos, On Fri, Jul 10, 2015 at 01:51:28AM +, Carlos Pignataro (cpignata) wrote: > The first set of S-BFD documents finished WG LC about 2 months ago. > > However, they are still in “WG Doc” or “In WGLC” state, with no shepherd > assigned and no write-up [1] [2] [3]; their related Milestones

Re: S-BFD Documents Progress?

On Fri, Jul 10, 2015 at 06:30:03PM +, Carlos Pignataro (cpignata) wrote: > > > On Jul 10, 2015, at 10:32 AM, Jeffrey Haas wrote: > > > >> What is the target timeline for submitting these to the IESG? > > > > Likely the next day or so. > > Thank

BFD Yang working group adoption

This is to announce the intent to adopt the work by the BFD Yang design team as a BFD Working Group document. This work is already in scope of our charter. https://datatracker.ietf.org/doc/draft-zheng-bfd-yang/ Per discussion with the team, we believe the draft is good enough shape to start to i

BFD Yang document

[Wearing my chair hat.] This concludes the closed design team portion of the BFD Yang work. Thanks to all of the members of the design team that got us this far! Continuing discussion on the Yang module should happen on the BFD mailing list. The members of the design team may continue to hold t

Fwd: Publication has been requested for draft-ietf-bfd-rfc5884-clarifications-02

The shepherd writeup for the RFC 5884 clarifications document has been done and the document has been submitted to the IESG for publication. Thanks to all of the authors for their work. -- Jeff and Nobo - Forwarded message from Jeffrey Haas - Date: Tue, 01 Sep 2015 13:30:32 -0700 From

[nomcom-chair-2...@ietf.org: NomCom 2015: Second call for nominations]

- Forwarded message from NomCom Chair 2015 - Date: Fri, 11 Sep 2015 08:19:03 -0700 From: NomCom Chair 2015 To: IETF Announcement List Cc: wgcha...@ietf.org Subject: NomCom 2015: Second call for nominations This is the SECOND call for nominations for the 2015-2016 nomcom. The 2015-16

draft-ietf-bfd-mpls-mib-06 (was Re: Comments on draft-ietf-bfd-mpls-mib-05)

other items are below and at least need reply. Beyond addressing these two items, what are the authors' beliefs about the state of the MIB? Ready for Last Call and/or MIB Doctor review? On Tue, Dec 30, 2014 at 12:25:39PM -0500, Jeffrey Haas wrote: > The bfdMplsSessPerfTable consists

BFD Multipoint documents - ready to progress?

The BFD multipoint documents, including the active-tail document, have been stable for a while. Are the documents ready to progress to WGLC? Any implementors of multipoint willing to say their implementations match the document? -- Jeff

Working group status

The working group has been quiet. Certainly I've been a bit distracted, and Nobo even more so! I've taken this opportunity to prod a few document authors to move their work along. I've also spent some time updating the WG wiki with current perceived WG status. If you have a BFD document, pl

Re: draft-ietf-bfd-mpls-mib-06 (was Re: Comments on draft-ietf-bfd-mpls-mib-05)

Venkat, On Sat, Sep 19, 2015 at 01:40:51AM -0700, Venkatesan Mahalingam wrote: > On Fri, Sep 18, 2015 at 10:43 AM, Jeffrey Haas wrote: > > > Authors of the BFD MPLS MIB, > > > > Thanks for addressing the majority of my comments during MIB review. Only > > a >

Re: Working group status

LOa, On Sat, Sep 19, 2015 at 12:28:22PM +0200, Loa Andersson wrote: > Thanks for this, I think you have one more bfd related document in the > PALS wg; > > draft-ietf-pals-seamless-vccv-00 > Seamless BFD for VCCV Thanks. This one was under "Non-WG S-BFD Documents of Interest". -- Jeff

Re: Working group status

On Mon, Sep 21, 2015 at 11:29:30AM +, Santosh P K wrote: > Jeff, >I think " draft-ymbk-idr-rs-bfd " already a working group document? Thanks for catching that, Santosh. And that reminds me I own the other authors more text. :-) -- Jeff

Re: Working group status

Carlos, On Mon, Sep 21, 2015 at 01:45:32PM +, Carlos Pignataro (cpignata) wrote: > 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 dr

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

[wearing my WG chair hat] On Sun, Sep 27, 2015 at 07:13:11PM -0700, Marc Binderberger wrote: > Hello everyone, > > not a chair of the VFD WG but I remember we made the conscious decision to > _split_ the fundamentals/principles ("base") from some nitty-gritty details > like the transport mechan

Re: AD Review of draft-ietf-bfd-seamless-use-case

Sam (and to a bigger extent, Alvaro), On Fri, Sep 25, 2015 at 11:48:19AM -0700, aldrin ietf wrote: > > Coming back to this specific document.. I’m asking the WG to consider not > > publishing, not telling it what to do. In fact, if you look at the WG > > charter, even though there is a specifi

Re: AD Review of draft-ietf-bfd-rfc5884-clarifications-02

Thanks, Prasad. The phrase "the straw that broke the camel's back" isn't supposed to apply to Internet-drafts. (Some of which are very heavy when printed!) Get better! -- Jeff > On Oct 2, 2015, at 11:58 AM, Vengada Prasad Govindan (venggovi) > wrote: > > Apologies for the delayed respons

Re: AD Review of draft-ietf-bfd-seamless-use-case

Loa, On Wed, Sep 30, 2015 at 12:46:58PM +0800, Loa Andersson wrote: > >Adopting the document within the WG basically means the working group "owns" > >the document and that we're motivated to get work on it done. This includes > >things like tracking it via a milestone. > > We talk about this as

Re: Fwd: New Version Notification for draft-mahesh-bfd-authentication-01.txt

Mahesh, Thanks for the update to the document. Here are a few comments on it. On Tue, Sep 29, 2015 at 11:09:46PM -0700, Mahesh Jethanandani wrote: > This version of the draft addresses concerns that were raised in IETF 92. > The change is to carry a sequence number in every packet of BFD. Carryi

Call for presentation topics for IETF-94, Yokohama

Working Group, I have requested a short slot, 1/2 hour, for IETF-94 since we haven't met for a while. If you have any desire to present before the group, please send mail to the list. If we expand past the short time slot, we can request a longer slot; we're often given more time than we ask any

Re: New Version Notification for draft-mahesh-bfd-authentication-01.txt

Mahesh, On Fri, Oct 02, 2015 at 01:54:19PM -0700, Mahesh Jethanandani wrote: > > A place where I think the document needs to be more proscriptive is about > > *when* you use the more aggressive crypto. As I was working through the > > possible modes, it almost seems as if anything that is intende

Re: Call for presentation topics for IETF-94, Yokohama

On Fri, Oct 02, 2015 at 01:44:48PM -0400, Jeffrey Haas wrote: > I have requested a short slot, 1/2 hour, for IETF-94 since we haven't met > for a while. If you have any desire to present before the group, please > send mail to the list. We have a tentative time-slot for Tuesday m

RE: Call for presentation topics for IETF-94, Yokohama

Greg points out that I can't read. Looks like we're doing split-meeting sessions. 1 hr should be plenty of time for us unless we're *really* busy. :-) -- Jeff - Forwarded message from Gregory Mirsky - Date: Mon, 5 Oct 2015 16:30:55 + From: Gregory Mirsky T

WGLC BFD Multipoint (with active tail)

BFD Working Group, This starts an extended Working Group Last Call for the following documents: draft-ietf-bfd-multipoint draft-ietf-bfd-multipoint-active-tail This Last Call will end after IETF week at the upcoming IETF-94 in Yokohama, Japan. It gives us plenty of time to discuss any open issue

WGLC for draft-ietf-bfd-mpls-mib

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 MPLS-TP Networks. The authors have indicated that this document is ready for advancement. Please indicate whether you believ

Re: Brian Haberman's No Objection on draft-ietf-bfd-rfc5884-clarifications-03: (with COMMENT)

On Wed, Oct 14, 2015 at 07:38:27AM -0700, Brian Haberman wrote: > -- > COMMENT: > -- > > Just a question on this draft... Given its status as clarifying (and > up

Re: Brian Haberman's No Objection on draft-ietf-bfd-rfc5884-clarifications-03: (with COMMENT)

On Wed, Oct 14, 2015 at 10:53:11AM -0400, Brian Haberman wrote: > On 10/14/15 10:45 AM, Jeffrey Haas wrote: > > On Wed, Oct 14, 2015 at 07:38:27AM -0700, Brian Haberman wrote: > >> -

<    1   2   3   4   5   6   >