Re: Progressing BFD unsolicited (failure thereof:-)

[Largely for the WG mail list archive.] > On Nov 26, 2021, at 7:26 AM, t petch wrote: > > On 15/10/2021 20:18, Jeffrey Haas wrote: >> I encourage the Working Group to review the draft and the comments to date. >> After resolving them, I believe we're ready to have a sh

Liaison statement to BBF re: TR-146 and draft-ietf-bfd-unaffiliated-echo

Greetings, The IETF Bidirectional Forwarding Detection (BFD) Working Group has begun work on "Unaffiliated BFD Echo Function". This work is happening in the Internet-Draft draft-ietf-bfd-unaffiliated-echo.[1] The BFD protocol (IETF RFC 5880, etc.) is used as a service in routers and other IP gat

Re: Progressing BFD unsolicited (failure thereof:-)

efix between YANG > > module and IANA Considerations are all based on YANG Guidelines where I > > would expect that BCP to trump the discussions of co-authors, whereas my > > comment on a seeming mismatch of references to authors is, of course, up > > to the authors:-) >

Re: Publication has been requested for draft-ietf-bfd-unsolicited-09

Working Group, BFD Unsolicted has been sent off to the IESG. Thank you for your diligence in reviewing this document. Thanks especially to Tom Petch for sticking through the long review cycle. -- Jeff On Mon, Dec 06, 2021 at 06:21:01AM -0800, Jeffrey Haas via Datatracker wrote: > Jeff

Working Group Last Call on BFD YANG model, RFC 9127-bis ending 20 December, 2021

Working Group, While some explanation is required, the request to the Working Group is very simple: Please review this minor update to the recently published BFD YANG module and offer your comments whether we should head to rapid publication. This last call ends 20 December. --- The history: Th

Re: Working Group Last Call on BFD YANG model, RFC 9127-bis ending 20 December, 2021

Rahman wrote: > > Should RFC9127-bis obsolete RFC9127? > > Regards, > Reshad. > > On Tuesday, December 7, 2021, 08:43:44 AM EST, Jeffrey Haas > wrote: > > > Working Group, > > While some explanation is required, the request to the Working Group is very >

Re: Working Group Last Call on BFD YANG model, RFC 9127-bis ending 20 December, 2021

Tom, On Tue, Dec 07, 2021 at 05:22:41PM +, t petch wrote: > On 07/12/2021 13:43, Jeffrey Haas wrote: > >Working Group, > > > >While some explanation is required, the request to the Working Group is very > >simple: Please review this minor update to the recently p

Re: Working Group Last Call on BFD YANG model, RFC 9127-bis ending 20 December, 2021

Tom, On Wed, Dec 08, 2021 at 09:30:02AM +, t petch wrote: > All the instances of the text string '9127' that appear in the I-D > 9127-bis and most of which need to be changed to the text string > ''. I stopped counting when I got to forty. Thanks for clarifying. I've opened a new issue

Re: Working Group Last Call on BFD YANG model, RFC 9127-bis ending 20 December, 2021

Tom, On Wed, Dec 08, 2021 at 04:24:27PM +, t petch wrote: > On 08/12/2021 12:58, Jeffrey Haas wrote: > >>The IANA Considerations are now a nonsense; I think that IANA need > >>consulting on what they want to do about whatever happens and > >>9127-bis revising ac

Re: Working Group Last Call on BFD YANG model, RFC 9127-bis ending 20 December, 2021

Tom, On Thu, Dec 09, 2021 at 05:04:24PM +, t petch wrote: > On 08/12/2021 17:47, Jeffrey Haas wrote: > >That said, where I think you're leading the discussion is that the > >simplest fix may be to simply re-issue the ietf-bfd-types module > >since that's our

Re: Working Group Last Call on BFD YANG model, RFC 9127-bis ending 20 December, 2021

tes to the BFD document. On Fri, Dec 10, 2021 at 04:47:05PM +, t petch wrote: > On 09/12/2021 21:58, Jeffrey Haas wrote: > >Tom, > > > >On Thu, Dec 09, 2021 at 05:04:24PM +, t petch wrote: > >>On 08/12/2021 17:47, Jeffrey Haas wrote: > >>>That said,

Re: MPLS wg aoption poll on on draft-mirsky-mpls-p2mp-bfd

The MPLS working group can't hear you over here. :-) -- Jeff (kindly examine the headers of your replies...) > On Dec 13, 2021, at 6:23 PM, Jeff Tantsura wrote: > > Yes/support > > Cheers, > Jeff > >> On Dec 13, 2021, at 14:53, Loa Andersson wrote: >> >> draft-mirsky-mpls-p2mp-bfd

Re: RFC 9127-bis question - impact of reference clauses in an import statement

[Note - re-send to fix bfd list address issue.] On Tue, Dec 21, 2021 at 10:13:13AM +, t petch wrote: > End of WG LC and I await a consensus call from the chairs. And Happy Holidays to you as well! > I see three options. The worst one is the present I-D, neither > flesh nor fowl. > > Publis

Working Group Last Call on BFD YANG model - round 2, RFC 9127-bis ending 14 January, 2022

Working Group, This begins a second round of Working Group Last Call on the RFC 9127-bis work. As a reminder, this is primarily to address making the YANG grouping for client-cfg-parms have its timers made conditional on a feature supporting them. This avoids implementors of importing models f

Re: Working Group Last Call on BFD YANG model - round 2, RFC 9127-bis ending 14 January, 2022

Just a reminder that WGLC for this ends on Friday. Your review is greatly appreciated. -- Jeff On Wed, Jan 05, 2022 at 02:17:43PM -0500, Jeffrey Haas wrote: > Working Group, > > This begins a second round of Working Group Last Call on the RFC 9127-bis > work. > > As a

Re: Working Group Last Call on BFD YANG model - round 2, RFC 9127-bis ending 14 January, 2022

This ends the Working Group Last Call for draft-ietf-bfd-rfc9127-bis. The document has been submitted to the IESG for publication. Thank you all for your efforts on this document. -- Jeff On Tue, Jan 11, 2022 at 04:36:40PM -0500, Jeffrey Haas wrote: > Just a reminder that WGLC for this ends

Re: Rtgdir last call review of draft-ietf-bfd-unsolicited-09

Henning, Thank you for your comments on this draft. On Fri, Jan 14, 2022 at 04:29:48AM -0800, Henning Rogge via Datatracker wrote: > I have two nits with the document... > > 1st, I would like a clarification which/how many (all?) security measurements > you consider mandatory... if you (as an ex

Re: [Last-Call] Yangdoctors last call review of draft-ietf-bfd-rfc9127-bis-01

If an implementation, for whatever reason, couldn't support the items that were covered under the new if-feature, they would have already deviated them away. An implementation now has the option to not advertise the feature for that case. It may also perversely choose to continue to apply a dev

Re: [Last-Call] Yangdoctors last call review of draft-ietf-bfd-rfc9127-bis-01

Tom, > On Feb 9, 2022, at 12:07 PM, t petch wrote: > > On 07/02/2022 17:42, Jeffrey Haas wrote: >> If an implementation, for whatever reason, couldn't support the items that >> were covered under the new if-feature, they would have already deviated them >>

Re: [Last-Call] Yangdoctors last call review of draft-ietf-bfd-rfc9127-bis-01

> On Feb 10, 2022, at 5:58 AM, tom petch wrote: > > Second, you may be right that no implementations exist but what if, in a few > years time, an implementor looks at the two versions, sees one that is > horribly complicated with a Cartesian explosion of YANG feature and sees no > reason not

Re: [Last-Call] Yangdoctors last call review of draft-ietf-bfd-rfc9127-bis-01

Jan, I'm clearly not speaking for Mahesh here. > On Feb 11, 2022, at 9:08 AM, Jan Lindblad (jlindbla) > wrote: > OLD: > This revision is non-backwards-compatible with the previous revision. > > NEW: > This revision is non-backwards compatible with the > previous version of th

Re: Some comments to the authors of draft-ietf-bfd-unsolicited

On Sun, Feb 27, 2022 at 04:24:35PM +, Reshad Rahman wrote: > > On Sunday, February 20, 2022, 05:09:22 PM EST, Greg Mirsky > > wrote: > >- The document uses the normative language and is on the Standard track. > > At the same time, the behavior of the passive BFD system is entirely loca

Re: Some comments to the authors of draft-ietf-bfd-unsolicited

Greg, > On Feb 27, 2022, at 7:54 PM, Greg Mirsky wrote: > > Hi Jeff, > of course, the WG can send the document IESG on its current track. What is > not clear to me is what is being standardized by the document. It appears > that everything described is a local behavior that does not affect any

Re: Some comments to the authors of draft-ietf-bfd-unsolicited

Greg, Not speaking for the authors here, but: > On Feb 28, 2022, at 10:34 AM, Greg Mirsky wrote: > > GIM>> Thinking of what might had confused me, I feel that it may be the use > of "passive role" that was already described in Section 6.1 RFC 5880 >

Re: Some comments to the authors of draft-ietf-bfd-unsolicited

Greg, On Mon, Feb 28, 2022 at 09:34:19AM -0800, Greg Mirsky wrote: > it is also my impression that the concept described in the draft is > different from the Passive role as defined in RFC 5880. I think that needs > to be clearly explained in the draft and, it seems to be helpful to even > use ano

Re: Some comments to the authors of draft-ietf-bfd-unsolicited

Greg, On Tue, Mar 01, 2022 at 08:41:50AM -0800, Greg Mirsky wrote: > In the unsolicited draft: > - The passive side is not sending packets. > - It is waiting for an incoming session. > > In my understanding, that is already defined in Section 6.1 RFC 5880: >A system taking the >Passive ro

bfd-unsolicited, possible RFC 5880 ambiguity for passive mode

Working Group, Greg Mirsky brought to our attention that we may have an undefined edge case covering Passive mode in RFC 5880. This discussion is partially a result of prior analysis about Demand mode, but Demand mode is not the relevant detail here. Presuming Greg's observation is correct, this

Fwd: Seeking volunteers for NomCom

Serving on nomcom is a rewarding way to learn more about how the IETF as a whole functions while helping the IETF find its leadership for the next term. Please consider participating! -- Jeff > Begin forwarded message: > > From: NomCom Chair 2022 > Subject: Seeking volunteers for NomCom > D

[ch...@ietf.org: New version of the "Tao of the IETF" published]

A new version of the Tao of the IETF is available. While most Working Group participants are familiar with the Tao, it's a worthy re-read. -- Jeff - Forwarded message from IETF Chair - Date: Fri, 9 Sep 2022 17:27:50 +0300 From: IETF Chair To: ietf-annou...@ietf.org Subject: New vers

Fwd: Directorate Early Reviews

> Begin forwarded message: > > From: Andrew Alston - IETF > Subject: Directorate Early Reviews > Date: October 12, 2022 at 3:29:38 AM EDT > To: "rtg-cha...@ietf.org" > Resent-From: > Resent-To: res...@yahoo.com, slitkows.i...@gmail.com, > daniele.ceccare...@ericsson.com, manka...@cisco.com,

Re: A missing read/write attribute in RFC 9314?

On Mon, Oct 17, 2022 at 06:01:05PM +, Reshad Rahman wrote: > Hi Sasha, > Apologies for the delay. > Yes this config knob is not present in RFC9314. I don't think it's something > we did not add on purpose, afair it's something we missed.  I'm going to offer a contrary view. Given that it ma

Re: [EXTERNAL] Re: A missing read/write attribute in RFC 9314?

Sasha, On Wed, Oct 19, 2022 at 08:07:06PM +, Alexander Vainshtein wrote: > And I have not encountered implementations by other vendors that support this > option (with or without the knob in question). My guess (FWIW) is that this > would make an implementation much more complicated while th

Re: [EXTERNAL] A missing read/write attribute in RFC 9314?

Xiao Min, Thank you for researching this. That brings the count of implementations that don't support such behavior to at least two. -- Jeff > On Oct 19, 2022, at 11:23 PM, > wrote: > > Jeff, Sasha, Reshad, et al., > > > > Please see inline... > > > > Best Regards, > > Xiao Min >

Re: A missing read/write attribute in RFC 9314?

> On Oct 19, 2022, at 3:24 PM, Jeffrey Haas wrote: > > I think what this work looks like is: > 1. Survey of implementations to see whether they do this behavior, and what > their knob is, if so. I have confirmed that Juniper's implementation does not support the behavio

Re: A missing read/write attribute in RFC 9314?

[In an attempt to close this thread, replying to my older message...] On Wed, Oct 19, 2022 at 03:24:57PM -0400, Jeffrey Haas wrote: > On Mon, Oct 17, 2022 at 06:01:05PM +, Reshad Rahman wrote: > > Hi Sasha, > > Apologies for the delay. > > Yes this config knob is not

Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

Matthew, On Fri, Oct 21, 2022 at 09:37:13AM +, Bocci, Matthew (Nokia - GB) wrote: > NVO3 and BFD working groups, > > To give more time to review and comment on this draft in the light of the > draft submission deadline of 24th October, I am extending this WG last call > to Friday 4th Novemb

Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

Xiao Min, > On Nov 3, 2022, at 10:52 PM, > wrote: >> : If the BFD packet is received with Your Discriminator equals to 0, the BFD >> : session MUST be identified using the VNI number, and the inner >> : Ethernet/IP/UDP Header, i.e., the source MAC, the source IP, the >> destination >> : MAC,

Re: A missing read/write attribute in RFC 9314?

ate: 2022年11月04日 07:17 > Subject: Re: A missing read/write attribute in RFC 9314? > [In an attempt to close this thread, replying to my older message...] > > On Wed, Oct 19, 2022 at 03:24:57PM -0400, Jeffrey Haas wrote: > > On Mon, Oct 17, 2022 at 06:01:05PM +, Reshad Rahm

Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

Xiao Min, On Sat, Nov 05, 2022 at 01:00:27PM +0800, xiao.m...@zte.com.cn wrote: > To restate my question, on a given device receiving, for a given VNI, will > there ever be multiple sets of the same IP addresses? > > If yes, the addition of the MAC addresses for initial multiplexing makes > sen

Re: Regarding resetting bfd.LocalDiag back to No Diagnostic (RFC 5880)

FWIW, my own reading through the text comes to similar conclusion. The transition for the state machine would be an appropriate place to reset the LocalDiag back to No Diagnostic. Glancing at part of Juniper's implementation, it seems we'll reset the Diag when the session returns to Up. It migh

Segment routing profiles for BFD

As commented at the mic during the IETF 115 spring session, there are currently 5 documents covering BFD profiles for various segment routing technologies. One is adopted, the other four have yet to be adopted. I have assembled a list of the documents as part of the regular BFD wiki maintenance:

Re: Lars Eggert's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

Lars, [Speaking in role as chair/shepherd and not author.] On Mon, Dec 12, 2022 at 06:27:25AM -0800, Lars Eggert via Datatracker wrote: > ## Discuss > > ### Section 7.1, paragraph 3 > ``` > The same security considerations and protection measures as those > described in [RFC5880] and [

Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

Zahed, [Speaking as chair/shedpherd, not an author.] On Wed, Dec 14, 2022 at 11:32:46AM -0800, Zaheduzzaman Sarker via Datatracker wrote: > DISCUSS: > -- > > Thanks for working on this specification. > > Thanks to Magnus Weste

Re: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

[Speaking as chair and shepherd, not an author] Rob, On Mon, Dec 12, 2022 at 09:03:18AM -0800, Robert Wilton via Datatracker wrote: > DISCUSS: [...] > Please see my comments below for more details, but I'm balloting discuss on 3 > points: (1) The document is somewhat unclear as to whether the con

Re: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

Rob, On Mon, Dec 19, 2022 at 11:37:12AM +, Rob Wilton (rwilton) wrote: > You are correct that in the case that the client has not configured an entry > in "... bfd:bfd/ip-sh/interfaces" then this list element does not exist, and > hence it seems that the global value would take effect. > >

Re: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

Rob, On Tue, Dec 20, 2022 at 11:58:03AM +, Rob Wilton (rwilton) wrote: > (1) If the user configures: > > bfd/ip-sh/unsolicited/min-interval = 1000 > > And no entries exist bfd/ip-sh/unsolicited/interfaces then all sessions have > a min-interval of 1000. This is fine and expected. > > >

Re: [Technical Errata Reported] RFC5880 (7240)

Dave, Just as a reminder, the context for why this errata is being discussed is this inquiry: https://mailarchive.ietf.org/arch/msg/rtg-bfd/YIeCo-nQicI_OIcVncYaJM5Zz6c/ More below: > On Feb 17, 2023, at 12:04 PM, Dave Katz > wrote: >> On Feb 17, 2023, at 8:47 AM, Reshad Rahman >

Re: [Technical Errata Reported] RFC5880 (7240)

to update or obsolete the old >> behavior. This is one of the pointy bits of our process, that RFCs document >> the consensus at a moment in time, not the evolving consensus. >> >> Thanks, >> >> —John >> >> [1] >> https://www.ietf.org/about

Re: [Technical Errata Reported] RFC5880 (7240)

bout pedantic >> coders. If the WG actually approves anything that reads the value of the >> diag field, I guess they can address all of the anomalies and hope for the >> best… >> >> —Dave >> >>> On Feb 22, 2023, at 2:30 PM, Jeffrey Haas wrote: >

Re: Alvaro Retana's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

Alvaro, On Dec 14, 2022, at 10:11 AM, Alvaro Retana via Datatracker wrote: > > > -- > COMMENT: > -- > > (1) The Introduction makes several claims that must b

Re: Alvaro Retana's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

> On Mar 21, 2023, at 7:18 AM, Alvaro Retana wrote: > > > Ok -- then, why even mention multihop? The text should either > indicate that the document only applies to single hop, or explain the > security risks. [...] > The comparison then seems out of place and unnecessary. > > > Note tha

WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

Working Group, https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/ The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC. The draft, in my opinion, is in fairly good shape. However, since it functions via looping packets back to itself and trying to exercise the

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

Note that the draft is currently expired and will be refreshed when the IETF 116 restrictions permit that to happen. -- Jeff > On Mar 21, 2023, at 12:02 PM, Jeffrey Haas wrote: > > Working Group, > > https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/ >

Comments on draft-ietf-bfd-unaffiliated-echo-05

Authors, Some comments on version -05: 16 Abstract 18 Bidirectional Forwarding Detection (BFD) is a fault detection 19 protocol that can quickly determine a communication failure between 20 two forwarding engines. This document proposes a use of the BFD Echo 21

Re: Comments on draft-ietf-bfd-unaffiliated-echo-05

[resend with correct draft address] Authors, Some comments on version -05: 16 Abstract 18 Bidirectional Forwarding Detection (BFD) is a fault detection 19 protocol that can quickly determine a communication failure between 20 two forwarding engines. This document p

Comments on draft-ietf-bfd-secure-sequence-numbers-10

Authors, Thank you for the substantive update on this draft. I think we're most of the way there! Aside from my questions about the auth seq number space being shared between the different modes (ISAAC vs. strong), my comments are largely editorial. Comments below in the idnits numbered documen

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

Alan, > On Mar 9, 2023, at 3:02 PM, Alan DeKok wrote: > One question is whether the document should contain sample code. ISAAC > isn't trivial, and it's easy to get it wrong. The GitHub repo includes > source code, but is that enough? I would avoid re-stating or otherwise including this in

Re: Comments on draft-ietf-bfd-secure-sequence-numbers-10

Alan, > On Mar 21, 2023, at 3:41 PM, Alan DeKok wrote: >> If it is the case that the Sequence Number is intended to be a single >> continuous >> space used by both the Meticulous Keyed ISAAC and the stronger authentication >> while performing state changes, I think we know how this should work.

Re: Comments on draft-ietf-bfd-secure-sequence-numbers-10

> On Mar 21, 2023, at 5:26 PM, Alan DeKok wrote: > >>> What if there's no auth method, or auth-type==simple? >> >> Another argument for a separate numbering space. > > I think that's the best approach. > >>> It just keeps going. The sequence number isn't used to derive the 32-bit >>> Aut

Re: Can a BFD session change its source port to facilitate auto recovery

> On Mar 23, 2023, at 2:17 PM, Reshad Rahman > wrote: > > Hi all, > > +1 to Jeff's comment on not wanting to pretend that everything is fine. > > And if we're running BFD single-hop and BFDoLAG where needed, this is a > non-issue right? Not quite. In theory, if we had a full set of link t

Re: Can a BFD session change its source port to facilitate auto recovery

> On Mar 23, 2023, at 3:06 PM, Reshad Rahman wrote: > >> In practice, what's often seen is that even with full coverage of the paths >> that there are end-to-end forwarding faults for various reasons. In at >> least some of these cases it's because BFD is implemented in a layer that >> isn'

Re: Several questions about the draft-ietf-bfd-unaffiliated-echo

lt;mailto:<david.sinicr...@gmail.com>;> To: Jeffrey Haas ,Reshad <mailto:<jh...@pfrc.org>,Reshad> Rahman <mailto:<res...@yahoo.com>;> Cc: Alvaro Retana ,John <mailto:<aretana.i...@gmail.com>,John> Scudder ,Martin <mailto:<j...@juniper.net>,Mart

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

Aijun, > On Apr 4, 2023, at 5:28 AM, Aijun Wang wrote: > From the description of this document, the state machine of local device is > conformed that described in RFC5880, the main standard parts of this > document are the contents of related fields within the BFD ECHO Packet. If > so, I suggest

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

Xiao Min, Thanks for addressing Greg's comments. I some additional comment on Greg's points: > On Apr 6, 2023, at 3:35 AM, > wrote: > The draft describes how the destination IP address of the Echo packet is set. > Are there any special considerations for selecting IPv6 destination address?

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

Greg, > On Mar 27, 2023, at 1:40 AM, Greg Mirsky wrote: > > Dear Authors, > I read the latest version of the draft. I appreciate your work on improving > its readability. I have several concerns and appreciate your consideration: > It appears like the document defines the format of the Echo me

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

Aijun, > On Apr 6, 2023, at 8:53 PM, Aijun Wang wrote: >> Providing additional detail to help illustrate the mechanism would be >> in-scope and perhaps helpful. Did you have any explicit recommendations for >> the text? > [WAJ] How about to refer the style of > https://datatracker.ietf.org/doc/

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

Xiao Min, > On Apr 7, 2023, at 3:15 AM, xiao.m...@zte.com.cn wrote: >>> On Apr 6, 2023, at 3:35 AM, >> > >> > wrote: >> One of the considerations may be whether a IPv6 link local address is >> preferable to a global address. >> >> The

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

Greg, > On Apr 7, 2023, at 1:03 PM, Greg Mirsky wrote: > Since the feature is intended to be used for single-hop, the source address > SHOULD be an address on the shared subnet with the interface of the device > that is looping the packets back. Perhaps it might even be reasonable to > requi

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

Greg, > On Apr 7, 2023, at 1:10 PM, Greg Mirsky wrote: > On Thu, Apr 6, 2023 at 7:36 AM Jeffrey Haas <mailto:jh...@pfrc.org>> wrote: > Greg, > > >> On Mar 27, 2023, at 1:40 AM, Greg Mirsky > <mailto:gregimir...@gmail.com>> wrote: >> >> D

draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo Working Group, The Working Group Last Call for draft-ietf-bfd-unaffiliated-echo has completed. My judgment is that it has weak, but positive support to proceed to publication. This isn't atypical of BFD work at this point

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

Xiao Min, > On Apr 9, 2023, at 10:42 PM, > wrote: > From: JeffreyHaas > > "could" isn't one of our RFC 2119 normative terms. Do you believe "SHOULD" > is more appropriate? > [XM-2]>>> If we would like to use normative term for SA, then that can also > apply to DA, suggest s/would/MUST. As

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

aft-cw-bfd-unaffiliated-echo, nor for the draft-ietf-bfd-unaffiliated-echo. Have I missed something?Regards,GregOn Mon, Apr 10, 2023 at 8:27 AM Jeffrey Haas <jh...@pfrc.org> wrote:https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo Working Group, The Working Group Last Call fo

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

The "Required Min Echo RX Interval" defined in [RFC5880] MUST be set >to zero. > Perhaps stating that the "Required Min Echo RX Interval" value is ignored in > the Unaffiliated BFD Echo is sufficient. WDYT? > > Regards, > Greg > > On Mon, Apr 10, 202

Re: New Version Notification for draft-rvelucha-bfd-offload-yang-05.txt

Tom, > On Apr 13, 2023, at 7:05 AM, t petch wrote: > > Taking a step back > > On 05/04/2023 10:20, t petch wrote: >> On 04/04/2023 06:20, Rajaguru Veluchamy (rvelucha) wrote: >>> Thanks, Tom for review/comments. >>> >>> Version been updated for comments. Can u please check. > > How widely is

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

Greg, > On Apr 12, 2023, at 1:09 PM, Greg Mirsky wrote: > > Dear All, > after reading the document once more, I've realized that I need help with a > paragraph in Section 3. Please find my notes in-lined in the original text > below under the GIM>> tag: >Once a BFD Unaffiliated Echo sessi

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

>Detection Time. > > OLD TEXT: >The "Required Min Echo RX Interval" defined in [RFC5880] MUST be set >to zero. > NEW TEXT: >The "Required Min Echo RX Interval" defined in [RFC5880] SHOULD be set >before the transmission and MUST be i

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

Greg, > On Apr 14, 2023, at 6:23 PM, Greg Mirsky wrote: > > Hi Jeff, > thank you for your kind consideration of the proposal. Indeed, leaving a > chunk of memory unchanged is a privacy issue. As I understand the proposal, > none of the fields defined in RFC 5880 for the BFD Control message is

Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

y, December 15, 2022, 05:39:32 PM EST, Jeffrey Haas > wrote: >> >> It's also not uncommon for implementations to dyanmically adjust their >> timers based on load within some constraints. When that's not possible, >> BFD traffic that becomes unsustainable caus

Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

Zahed, Oddly enough, it appears that mail from ietf.org delivered one of the two copies of mail from you in a corrupted form. This message replies to the missing piece of your question: On Tue, Apr 18, 2023 at 12:44:13PM +, Zaheduzzaman Sarker wrote: > > The environment must be under reasona

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

se for IESG review. I'm happy to make note of that in the shepherd's writeup, if you like. > On Fri, Apr 14, 2023 at 3:31 PM Jeffrey Haas wrote: > > The Discriminator field is used for demux. Authentication is utilized, if > > present. > > > GIM>>

Fwd: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

For whatever reason, Raj's attestation didn't make it into the BFD archives. So, a resend. -- Jeff > Begin forwarded message: > > From: Raj Chetan Boddireddy > Subject: Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check > Date: April 11, 2023 at 9:18:59

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

Greg, > On Apr 22, 2023, at 11:57 AM, Jeffrey Haas wrote: >> Device A performs its initial demultiplexing of a BFD Unaffiliated >> Echo session using the source IP address or UDP source port. >> Am I missing something? > > You are likely not paying sufficien

Re: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt

Working Group, After reviewing draft-07, I believe all pending review comments to date have been addressed. We're waiting on final acknowledgement on one point from Greg and then otherwise might proceed with publication. The shepherd's report is located here for your review: https://datatracke

Re: New Version Notification for draft-rvelucha-bfd-offload-yang-05.txt

Reshad, > On Apr 25, 2023, at 1:53 PM, Reshad Rahman wrote: > Not just the name, but the description. In this case the description > says "running in hardware". Sometimes that line is blurry, e.g. is VPP > considered hardware? Should the description instead say something along the > times o

Re: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

Reshad, > > > Please see inline … > > > From: Reshad Rahman mailto:res...@yahoo.com>> > Sent: 19 April 2023 03:38 > To: The IESG mailto:i...@ietf.org>>; Rob Wilton (rwilton) > mailto:rwil...@cisco.com>> > Cc: draft-ietf-bfd-unsolici...@ietf.org

[nomcom-chair-2...@ietf.org: NomCom 2023 Needs Your Feedback]

The IETF nomcom needs your wisdom to help select members who will take on the unpaid "management" and leadership roles within the IETF. Please take a moment to give them feedback for individuals you may know. -- Jeff - Forwarded message from NomCom Chair 2023 - Date: Sun, 05 Nov 2023

Re: Publication has been requested for draft-ietf-bfd-unaffiliated-echo-10

reful review on the draft. The text benefited greatly from your attention. -- Jeff On Mon, Jan 15, 2024 at 12:54:45PM -0800, Jeffrey Haas via Datatracker wrote: > -UID: 254690 > > Jeffrey Haas has requested publication of draft-ietf-bf

Re: Publication has been requested for draft-ietf-bfd-unaffiliated-echo-10

Greg, > On Jan 15, 2024, at 5:15 PM, Greg Mirsky wrote: > For several years I've actively participated in the work at BBF, including > the Working Area that published TR-146. I cannot recall that any member > company reported TR-146 implementation. Were there any on the BFD mailing > list tha

Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt

Authors, Feedback on version -12: : Auth-Key : : This field carries the 32-bit (4 octet) ISAAC output which is associated : with the Sequence Number. The ISAAC PRNG MUST be configured and initialized : as given in section TBD, below. Fill in the TBD. : While the rest of the contents of the BFD

Re: Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt

Alan, > On Jan 15, 2024, at 7:25 PM, Alan DeKok wrote: > On Jan 15, 2024, at 6:22 PM, Jeffrey Haas wrote: >> 1. We learn the Seed for this session for the first time. This somewhat >> argues we need a bfd.MetKeyIsaacKnown variable. We require it to not >> change.

Re: Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt

Alan, > On Jan 16, 2024, at 11:47 AM, Alan DeKok wrote: > On Jan 16, 2024, at 11:28 AM, Jeffrey Haas wrote: >> Option 2: >> Each side changing to ISAAC authentication knows that lost packets could be >> a problem. The draft says the window we need to keep around is 3

Re: Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt

Alan, > On Jan 16, 2024, at 6:47 PM, Alan DeKok wrote: > > On Jan 16, 2024, at 12:00 PM, Jeffrey Haas wrote: >> This means the two scenarios we have during the first transition to ISAAC in >> the face of packet loss are: >> 1. It's on "this" pag

Re: Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt

Alan, > On Jan 17, 2024, at 10:18 AM, Alan DeKok wrote: > > OK, I've pushed my latest set of changes which address all open concerns. In that push: + It is RECOMMENDED that implementations periodically use a + strong Auth Type for packets which maintain the session in an Up + s

Re: Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt

Alan, On Jan 17, 2024, at 11:19 AM, Alan DeKok wrote: > Perhaps then this text. Which both refers to the other draft, and then also > says how such a switch impacts ISAAC. > > It is RECOMMENDED that implementations periodically use a > strong Auth Type for packets which maintain the

Re: Publication has been requested for draft-ietf-bfd-unaffiliated-echo-10

Greg, > On Jan 17, 2024, at 4:43 PM, Greg Mirsky wrote: > > Hi, Jeff et al., > upon more consideration of this draft, the write-up, and the related to the > draft BBF liaison > , > I would propose to include the refe

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

Authors, Since secure sequence numbers is heading toward WGLC, it's time to refresh this document and review it vs. secure sequence numbers, and bfd stability. - From Introduction and some confusion about configuration and operational state: "This document also proposes that all BFD contro

draft-ietf-bfd-stability-10 comments

Authors, As we finish up work on the authentication features now that secure sequence is heading toward completion, it's time to reconcile your draft vs. our current learnings in that other work. The main change that seems appropriate is noting that any meticulous keyed authentication mechanis

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

> On Jan 18, 2024, at 7:26 PM, Mahesh Jethanandani > wrote: >> On Jan 17, 2024, at 5:05 PM, Jeffrey Haas > <mailto:jh...@pfrc.org>> wrote: > That is a good point. However, and thinking of this from a management > perspective, the operator can signal a they w

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

Alan, To your final point, ISAAC is reasonably secure for the Up case. However it doesn’t authenticate the packet contents. Jeff > On Jan 20, 2024, at 19:45, 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

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

> On Jan 21, 2024, at 11:58 AM, Alan DeKok wrote: > > On Jan 21, 2024, at 10:43 AM, Jeffrey Haas wrote: >> To your final point, ISAAC is reasonably secure for the Up case. However it >> doesn’t authenticate the packet contents. > > What fields can be modified w

<    1   2   3   4   5   6   >