BFD Yang editors,
Please note that this model references BFD, but doesn't implement the
cfg-params. Please consider engaging the last call comments immediately.
-- Jeff
- Forwarded message from The IESG -
Date: Tue, 28 Nov 2017 08:29:53 -0800
From: The IESG
To: IETF-Announce
Cc: dra
Working Group,
In an attempt to give our AD a holiday gift, we're at the point where we may
now work to conclude WGLC on the BFD multipoint documents. We did one pass
of last call June-July of this year, and held off approval pending review
from ALU who has an implementation of the base spec. AL
On Wed, Dec 13, 2017 at 12:24:43PM -0500, Jeffrey Haas wrote:
> Working Group,
>
> In an attempt to give our AD a holiday gift, we're at the point where we may
> now work to conclude WGLC on the BFD multipoint documents.
It is also worth noting that Greg Mirsky will be taking o
Working Group,
This likely could use BFD eyes upon it, especially given our current WGLC on
the multipoint documents.
-- Jeff
- Forwarded message from The IESG -
Date: Mon, 18 Dec 2017 13:56:36 -0800
From: The IESG
To: IETF-Announce
Cc: trill-cha...@ietf.org, draft-ietf-trill-p2mp-..
[Speaking as an individual contributor.]
On Tue, Dec 19, 2017 at 02:20:11AM +, Carlos Pignataro (cpignata) wrote:
> S-BFD currently specified for p2p but I don't see a reason why S-BFD cannot
> be applied to p2mp cases. So, for a BFD node that supports both RFC 7880 and
> draft-ietf-bfd-mult
[Speaking as an individual contributor.]
I'm going to pick this as my response point. I'm not picking on you,
Ashesh. :-)
I have several concerns about the proposal in this document:
1. It's not very clear how services get mapped to BFD sessions. As others
are indirectly noting, p2p BFD ses
-
> Balaji Rajagopalan
>
>
>
> From: Greg Mirsky
> Date: Saturday, 16 December 2017 at 3:33 AM
> To: "BRUNGARD, DEBORAH A"
> Cc: Kireeti Kompella , Balaji Rajagopalan
> , Jeffrey Haas , "Carlos Pignataro
> (cpignata)" , "ginsb...@c
Ashesh,
I'll take it as a given that there's an implied gripe about a lack of TLVs
for BFD and a push for BFDv2. :-)
The work in here seems reasonable, but does run up against the question I
always must ask: Is this actually useful/usable at high BFD rates?
I understand that a likely scenario (a
Ashesh,
On Tue, Dec 19, 2017 at 12:30:10PM -0500, Ashesh Mishra wrote:
> It really depends on the use-case and the implementation. This measurement
> may be excessive if running at a 3.3ms or 10ms interval, but you don’t run
> these intervals on anything but the best and most deterministic of li
This normally happens as part of IETF, but it got away from us.
The BFD wiki has been updated with current status of known documents and
documents utilizing BFD outside of the working group.
https://trac.ietf.org/trac/bfd/wiki
-- Jeff
n
with the Yang module implications discussion.
-- Jeff
> On Tue, Dec 19, 2017 at 8:05 AM, Jeffrey Haas wrote:
[...]
> > At this point it is also worth noting that the session type has no
> > centralized location covering their enumerations. This leads to two
> > interesting obs
for these documents.
-- Jeff
On Wed, Dec 13, 2017 at 12:24:43PM -0500, Jeffrey Haas wrote:
> Working Group,
>
> In an attempt to give our AD a holiday gift, we're at the point where we may
> now work to conclude WGLC on the BFD multipoint documents. We did one pass
> of la
0800, IETF Secretariat wrote:
> The BFD WG has placed draft-spallagatti-bfd-vxlan in state
> Call For Adoption By WG Issued (entered by Jeffrey Haas)
>
> The document is available at
> https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/
>
> Comment:
> The authors of draf
rable implementations of the draft, please consider pushing hard to
reach the point where we can publish this ASAP. :-)
If the implementations are already publicly done, please unicast me and I'll
add them to the BFD status page on the wiki.
-- Jeff
On Wed, Jan 03, 2018 at 10:49:25AM -0500, Jeffrey
Working Group,
The authors of the BFD Yang module have declared their work on that document
complete. Thus, working group last call is in progress for this document.
Please provide your hopefully final reviews on the text.
The last several revisions of the document have largely been done to reso
- Forwarded message from David Ward -
Date: Wed, 24 Jan 2018 10:23:18 -0800
From: David Ward
To: Jeffrey Haas
Cc: David Ward
Subject: Re: [rrah...@cisco.com: IPR poll for multipoint drafts]
I know of none
> On Jan 24, 2018, at 10:23 AM, Jeffrey Haas wrote:
>
> Hi Dave.
-tail/shepherdwriteup/
>
> Regards,
> Reshad.
>
> From: Greg Mirsky
> Date: Tuesday, January 16, 2018 at 11:01 PM
> To: "Reshad Rahman (rrahman)"
> Cc: "Carlos Pignataro (cpignata)" , Jeffrey Haas
> , "rtg-bfd@ietf.org"
> Subject:
Reminder, WGLC ends tomorrow.
On Wed, Jan 24, 2018 at 01:22:07PM -0500, Jeffrey Haas wrote:
> Working Group,
>
> The authors of the BFD Yang module have declared their work on that document
> complete. Thus, working group last call is in progress for this document.
> Plea
yang doctors have not yet responded.
Once we complete the directorate reviews and address any lingering comments,
we will forward the document to the IESG for publication.
-- Jeff
On Thu, Feb 08, 2018 at 03:02:52PM -0500, Jeffrey Haas wrote:
> Reminder, WGLC ends tomorrow.
>
> On Wed
Working Group,
BFD has requested a meeting slot for IETF 101 in London. IETF is little
over a month away.
This is a call for topics for our session. Even if you think you've
requested a slot, please respond in thread so all can see the request for
discussion on the topic.
As is our tradition,
On Sun, Feb 18, 2018 at 03:28:13AM +, Reshad Rahman (rrahman) wrote:
> Hi Acee,
>
> What I meant is that BFD always augments the control palne protocols in
> ietf-routing model. And the BFD augmentation can be used as-is or mounted in
> LNE or in NI.
Basically:
Whereever ietf-routing is, BF
Just a reminder, a call for topics is open for the upcoming session.
I've posted the agenda to date:
https://datatracker.ietf.org/doc/agenda-101-bfd/
-- Jeff
On Thu, Feb 15, 2018 at 04:22:31PM -0500, Jeffrey Haas wrote:
> Working Group,
>
> BFD has requested a meeting slot f
last but not least, clarification of BFD bootstrap by LSP ping
>over MPLS p2p LSP and interest in RFC5884bis (based on
>draft-mirsky-mpls-bfd-bootstrap-clarify)
>
> Regards,
> Greg
>
> On Thu, Feb 15, 2018 at 1:22 PM, Jeffrey Haas wrote:
>
> > Working Gro
As part of the shepherd writeup, we're required to confirm whether or not
there are any IPR disclosures on the BFD Yang module.
Authors, please respond to this thread, copying the mailing list.
-- Jeff
Jeffrey Haas has requested publication of draft-ietf-bfd-multipoint-14 as
Proposed Standard on behalf of the BFD working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
Jeffrey Haas has requested publication of
draft-ietf-bfd-multipoint-active-tail-07 as Proposed Standard on behalf of the
BFD working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/
018, at 9:47 AM, Jeffrey Haas wrote:
>
> As part of the shepherd writeup, we're required to confirm whether or not
> there are any IPR disclosures on the BFD Yang module.
>
> Authors, please respond to this thread, copying the mailing list.
>
> -- Jeff
d in Large Packets
Authors : Jeffrey Haas
Albert Fu
Filename: draft-haas-bfd-large-packets-00.txt
Pages : 5
Date: 2018-03-19
Abstract:
The Bidirectional Forwarding Detection (BFD) protocol is commonly
Presenters at the upcoming BFD meeting MUST unicast their slides to the
chairs before the meeting. Ideally 24 hours before. Don't make us scrape
through our email at the last second. :-)
-- Jeff & Reshad
Jeffrey Haas has requested publication of draft-ietf-bfd-yang-13 as Proposed
Standard on behalf of the BFD working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/
0:23 -0700
From: IETF Secretariat
Subject: Personal ID list of jh...@pfrc.org notification: Changes to
draft-ietf-bfd-yang
Hello,
This is a notification from the Personal ID list of jh...@pfrc.org.
Document: draft-ietf-bfd-yang,
https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/
Change
Working Group,
The draft minutes have been uploaded to the data tracker.
https://datatracker.ietf.org/doc/minutes-101-bfd/
Please review them. In particular, the minutes from the second half of the
meeting may be incomplete since we seem to have lost audio recording around
then.
(This chair re
Working Group,
The authors of the following Working Group drafts have requested
Working Group Last Call on the following documents:
https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-01
https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-04
https://tools.ietf.org
Authors,
Several comments on the draft in no particular order:
---
The document header says "BFD Authentication". You should include the word
"optimizing" somewhere in that. :-)
---
The NULL Auth TLV has a recommended Authentication Type of 0. While this
seems like a good idea, it's problema
Authors,
A few comments on your draft in no particular order:
Operational Considerations:
- How do you go about enabling this feature?
+ It's independent of, but recommended for, optimizing BFD authentication.
- What are the yang considerations?
+ Similar point - changes to the yang model f
ived bounces on Manav and Alan's addresses. Please update them
and also make sure they're following the WGLC.
>
> > On Mar 28, 2018, at 9:38 AM, Jeffrey Haas wrote:
> >
> > Working Group,
> >
> > The authors of the following Working Group drafts have r
Working Group,
https://tools.ietf.org/html/bcp79
A reminder that if you're aware of IPR against IETF work, disclose it.
Don't make us find this out at WGLC.
-- Jeff
Working Group,
We had very active discussion (yay!) at the microphone as part of Mahesh's
presentation on BFD Performance Measurement.
(draft-am-bfd-performance)
I wanted to start this thread to discuss the greater underlying issues this
discussion raised. In particular, active tuning of BFD ses
Bob,
Addressing these specific points. (Note that I'm not a multicast expert.)
On Mon, Jun 11, 2018 at 10:47:28PM +0100, Bob Briscoe wrote:
> If there is an SSM tree from host A to multicast address G, I am not
> familiar enough with SSM to know what happens when host B sends a
> packet to G wit
;>
> Date: Monday, June 25, 2018 at 9:34 AM
> To: "rtg-bfd@ietf.org <mailto:rtg-bfd@ietf.org>" <mailto:rtg-bfd@ietf.org>>
> Cc: "bfd-cha...@ietf.org <mailto:bfd-cha...@ietf.org>" <mailto:bfd-cha...@ietf.org>>
> Subject: IETF102 B
Carlos,
On Tue, Jun 26, 2018 at 05:17:20AM +, Carlos Pignataro (cpignata) wrote:
[...]
> I do not believe the question was whether S-BFD or any other protocol
> followed the behavior. It’s a question about this document.
>
> For correctness, S-BFD (RFC 7880) did not miss to define PointToPoi
[Note that I'm making this comment for posterity so that the IESG doesn't
ask the same thing of other draft authors.]
On Thu, Jul 05, 2018 at 06:18:42AM -0700, Eric Rescorla wrote:
> On Thu, Jul 5, 2018 at 6:10 AM, Reshad Rahman (rrahman)
> wrote:
> > The pyang tool does this for real references
On Wed, Jul 04, 2018 at 06:33:16PM +0200, Martin Vigoureux wrote:
> Hello Alissa,
>
> thanks for your review.
> I'm fine with discussing this but wonder if we should tie it to this draft.
> I would prefer that we collectively discuss that and once we reach a
> decision we start applying it.
It's
On Tue, Jul 03, 2018 at 10:56:49PM -0500, Benjamin Kaduk wrote:
> On Wed, Jul 04, 2018 at 03:20:42AM +, Reshad Rahman (rrahman) wrote:
> > I am not 100% sure I understand the point being made. Is it a question
> > of underlying the importance of having the IGPs authenticated since the
> > IG
Mirja,
On Mon, Jul 09, 2018 at 04:01:22PM +0200, Mirja Kuehlewind (IETF) wrote:
> > Am 05.07.2018 um 21:27 schrieb Greg Mirsky :
> > GIM>> I believe that such limit will negatively impact applicability of
> > this method to detect defects in networks. Analysis of BFD transmission
> > intervals p
On Wed, Mar 28, 2018 at 01:41:51PM -0400, Jeffrey Haas wrote:
> Mahesh,
>
> On Wed, Mar 28, 2018 at 10:33:23AM -0700, Mahesh Jethanandani wrote:
> > Chairs,
> >
> > We the authors acknowledge an IPRs related to these drafts. It is titled
> > “Integrity check op
Greg,
On Tue, Mar 20, 2018 at 10:40:00AM +, Greg Mirsky wrote:
> thank you for bringing up for discussion this interesting proposal. A
> question and a comment ahead of the meeting to save us time:
>
>- which applications will benefit from monitoring path MTU (PMTU) rather
>from using
t Benjamin's comments as requiring a security
> boundary between BFD clients (BGP, IPGPs) and BFD running on the same dveice,
> which I agree would be preposterous.
>
>Regards,
> Reshad.
>
>On 2018-07-10, 10:17 PM, "Acee Lindem (acee)&quo
Benjamin,
On Wed, Jul 11, 2018 at 10:02:41AM -0500, Benjamin Kaduk wrote:
> "may be overkill in some circumstances" sounds exactly like an RFC 2119
> SHOULD, does it not?
Putting it slightly a different way, I am always wary of trying to embed too
much operational and security wisdom in documents
Mirja,
You keep waving around RFC 8085 as a panacea. Consider:
: 4.1. Multicast Congestion Control Guidelines
:
:Applications using multicast SHOULD provide appropriate congestion
:control.
Firstly, it's a SHOULD, and not a MUST. Also, I believe we've made the
point more than once th
Working Group,
This starts the Working Group Last Call for BFD for VxLAN. This last call
ends the Friday after IETF, November 9.
https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
Please comment whether you believe this document is ready to advance or not.
There is currently one IPR statem
Working Group,
The BFD chairs have received an adoption request for
"BFD in Demand Mode over Point-to-Point MPLS LSP"
(draft-mirsky-bfd-mpls-demand).
https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/
The adoption call will end on the Friday after IETF 103, November 9.
Note that th
Naiming,
A specific comment on the crypto overhead:
On Mon, Oct 22, 2018 at 07:38:18PM +, Naiming Shen (naiming) wrote:
>
> Probably just bandwidth increase, and if you need encryption/decryption on
> the packets,
> then large packets will cost more in CPU.
The BFD protocol has you check t
Les,
A brief note, and one worn as a chair:
Despite having strong personal preferences about mail quoting, I realize
that not everyone gets a chance to choose a client of their own choice.
But that said, your responses in this thread have been impossible to parse
out from the surrounding reply in
Note that I'm choosing this message out of a mixed thread to give a reply.
So, not all of this is targeted as a response to you, Acee.
On Tue, Oct 23, 2018 at 04:30:52PM +, Acee Lindem (acee) wrote:
> Hi Albert, Les,
>
> I tend to agree with Les that BFD doesn’t seem like the right protocol f
Les,
I *think* the following text is yours.
On Mon, Oct 22, 2018 at 12:36:52AM +, Les Ginsberg (ginsberg) wrote:
> [Les:] So, this has some implications:
>
> We have both a transmit interval and a multiplier for a BFD session because
> we allow that some BFD packets may be dropped for reas
On Thu, Oct 25, 2018 at 10:28:52PM +, Les Ginsberg (ginsberg) wrote:
> > https://tools.ietf.org/html/draft-ietf-bfd-stability-02
>
> [Les:] I have read this draft - not sure how relevant it is.
Mostly, the idea being that it's possible to do probing in BFD without
necessarily having to commit
Reshad,
On Fri, Oct 26, 2018 at 06:32:26PM +, Reshad Rahman (rrahman) wrote:
>On 2018-10-25, 11:38 AM, "Jeffrey Haas" wrote:
> > The draft I had previously worked on with Xiao Min discussing probing
> > using
> > BFD Echo had the concept of probe
Working Group,
Reviewing my notes, I was remiss in sending out an adoption request for
draft-chen-bfd-unsolicted (Unsolicited BFD for Sessionless Applications).
https://datatracker.ietf.org/doc/draft-chen-bfd-unsolicited/
This relatively minor change from the RFC 5880 spec is implemented by at
l
Mahesh,
On Mon, Oct 15, 2018 at 09:24:59PM -0700, Greg Mirsky wrote:
> thank you for your quick response. The comment regarding the state change,
> as I understand from the minutes, came from Jeff.
> Yes, the question was about the periodic authentication in Up state. I
> believe that at the meeti
On Mon, Oct 29, 2018 at 04:39:04PM +, Les Ginsberg (ginsberg) wrote:
> Given the MTU issue is associated with a link coming up - and the use of Echo
> would allow the problem to be detected and prevent the BFD session from
> coming up -
> and you are acknowledging that the protocol allows pa
Les,
On Mon, Oct 29, 2018 at 04:55:05PM +, Les Ginsberg (ginsberg) wrote:
> I note that no one supports "large-packets" today.
A vapid phrase that I generally loathe hearing on IETF mailing lists. We
need our own version of [1]. When meant pleasantly, sometimes implies, "no,
I'm not aware o
Les,
On Mon, Oct 29, 2018 at 06:13:53PM +, Les Ginsberg (ginsberg) wrote:
> The fact that the problem is not detected on protocol adjacency formation
> does not mean the problem gets introduced afterwards. Unless you are
> saying that folks change the link MTU AFTER the link comes up and has b
Working Group,
As a reminder, calls are ongoing for the following ending on November 9:
Working Group Last Call:
draft-ietf-bfd-vxlan
Adoption:
draft-mirsky-bfd-mpls-demand
draft-haas-bfd-large-packets
draft-chen-bfd-unsolicted
In particular, please supply your feedback on the last call above.
Working Group,
As is our custom, the BFD wiki has been updated with current status of the
group and known documents. You are encouraged to review it.
https://trac.ietf.org/trac/bfd/wiki
-- Jeff & Reshad
ed these into the wiki.
-- Jeff
>
> Regards,
> Greg
>
> On Thu, Nov 8, 2018 at 3:52 PM Jeffrey Haas wrote:
>
> > Working Group,
> >
> > As is our custom, the BFD wiki has been updated with current status of the
> > group and known documents. Yo
Reshad,
On Sat, Nov 17, 2018 at 01:58:25PM +, Reshad Rahman (rrahman) wrote:
> Hi authors.,
>
> This document has passed adoption as a BFD WG document.
>
> Please resubmit the doc as draft-ietf-bfd-large-packets. Please also note
> that while there was strong support for adopting the docume
Working Group,
After discussing this with Reshad, the consensus is we have enough interest
to proceed in working group adoption.
Authors, please re-submit your draft as draft-ietf-bfd-unsolicited.
-- Jeff
On Mon, Oct 29, 2018 at 11:52:32AM -0400, Jeffrey Haas wrote:
> Working Gr
dures for BFD demand mode are not
necessarily in need of amending in this instance to warrant a new working
group task. Errata would be considered for minor issues, if necessary.
-- Jeff
On Wed, Oct 17, 2018 at 06:24:31PM -0400, Jeffrey Haas wrote:
> Working Group,
>
> The BFD chairs ha
Greg,
Apologies for the long delay in reply.
On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote:
> I respectfully ask to summarize the comments that were shared with you and
> to publish them to the WG without naming the authors.
Tersely:
- The document is not addressing fundamental i
BESS Working Group members,
https://tools.ietf.org/html/draft-ietf-bfd-vxlan-04
BFD has finished working group last call on BFD for Vxlan and is about ready
to request publication as an RFC. A last minute comment suggested that we
should consider inviting comment from your working group for expe
Greg,
Thanks for integrating what appears to be the final comments on the draft.
Our intent is to send this off to the IESG on Friday if there's no further
feedback.
-- Jeff
On Wed, Dec 19, 2018 at 10:29:54AM -0800, Greg Mirsky wrote:
> updates to address comments WGLC comments by Anoop Ghanwan
As part of doing my shepherd review for BFD for VXLAN, I noted three details
that should be attended to prior to the document being submitted to the IESG:
There is a missing IPR attestation from Sudarsan. I have unicasted him to
request this to be done.
In the document:
IANA has assigned TBA
Note that this was related to the last IPR attestation for draft-ietf-bfd-vxlan.
Thank you, Sudarsan.
-- Jeff
> On Jan 2, 2019, at 1:51 PM, Sudar wrote:
>
> Hi all,
>
> There is no more IPR to be disclosed from my side. Please send this off to
> IESG.
> https://mailarchive.ietf.org/arch/m
Jeffrey Haas has requested publication of draft-ietf-bfd-vxlan-06 as Proposed
Standard on behalf of the BFD working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
section 6.8.3 of RFC 5880. I don't believe I
agree with your procedure that a system in demand mode must initiate a poll
sequence to declare that it is down.
Am I missing something?
-- Jeff
>
> Regards,
> Greg
>
> On Mon, Dec 10, 2018 at 2:10 PM Jeffrey Haas wrote:
>
&g
Working Group,
On March 28, 2018, we started Working Group Last Call on the following document
bundle:
draft-ietf-bfd-secure-sequence-numbers
draft-ietf-bfd-optimizing-authentication
draft-ietf-bfd-stability
The same day, Mahesh Jethanandani acknowledged there was pending IPR
declarations
Working Group,
We will be meeting in Prague for IETF 104.
We're currently a little over a month out from the meeting. Please send a
request to the chairs for timeslots for our session.
-- Jeff
Greg,
On Sat, Feb 16, 2019 at 09:38:08AM -0800, Greg Mirsky wrote:
> On Sat, Feb 16, 2019 at 8:33 AM Jeffrey Haas wrote:
> > Thanks for the update on the IPR declaration. It's good to see that the
> > terms of the licensing have shifted such that open source implementations
Greg,
Answering this message with the reply partially reorganized.
On Sun, Feb 17, 2019 at 04:40:31PM -0800, Greg Mirsky wrote:
> On Sat, Feb 16, 2019 at 10:46 AM Jeffrey Haas wrote:
> > > GIM>> The behavior of the system in Demand mode is introduced as
> > opt
g similar questions to the above.
-- Jeff
>
> Regards,
> Greg
>
> On Mon, Feb 18, 2019 at 7:26 AM Jeffrey Haas wrote:
>
> > Greg,
> >
> > Answering this message with the reply partially reorganized.
> >
> >
> > On Sun, Feb 17, 2019 at 04
On Mon, Feb 18, 2019 at 08:48:08AM -0800, Greg Mirsky wrote:
> As for your question of what is the change proposed in the draft I'll point
> to section 6.6 RFC 5880 that describes the Demand mode. It states that the
> periodic transmission of control messages MUST be stopped.
Correct.
> The draft
A reminder from 5880's state machine (6.8.6)
: Else
[...]
: Else (bfd.SessionState is Up)
: If received State is Down
: Set bfd.LocalDiag to 3 (Neighbor signaled
: session down)
: Set bfd.SessionState to Down
:
Greg,
We seem now to be converging on the substance of your draft. Thanks for
sticking with this.
On Tue, Feb 19, 2019 at 03:59:36PM -0800, Greg Mirsky wrote:
> thank you for pointing to the sloppy terminology I've used referring to
> what is the proposed update to RFC 5880. In fact, the draft,
Greg,
On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote:
> Hi Jeff,
> I'm glad that you feel that our discussion is helpful. I want to point that
> the use of the Poll sequence to communicate to the remote BFD system in the
> Concatenated Paths section is to relay the failure detected in
On Mon, Feb 25, 2019 at 09:10:16AM -0800, Greg Mirsky wrote:
> Hi Jeff,
> please find my answers in-line tagged GIM4>>.
>
> Regards,
> Greg
>
> On Sun, Feb 24, 2019 at 7:24 PM Jeffrey Haas wrote:
>
> > Greg,
> >
> > On Sun, Feb 24, 2019 at 09
Working Group,
We have a two hour session scheduled the Wednesday of IETF week.
A tentative agenda has been posted based on existing requests.
We have room for more presentations or discussion topics.
https://datatracker.ietf.org/doc/agenda-104-bfd/
-- Jeff & Reshad
gt; On Mar 12, 2019, at 2:15 PM, Acee Lindem (acee) wrote:
>
> Hi Jeff,
> We'd also like 10-15 to present
> https://datatracker.ietf.org/doc/draft-merciaz-idr-bgp-bfd-strict-mode/
>
> The presenter is Mercia Zheng.
>
> Thanks,
> Acee
>
> On 3/12/19, 8:5
Xiao Min,
I've added you to the agenda.
A personal request: Have at least one slide explaining Geneve. There will be
working group members that don't follow that work.
-- Jeff
> On Mar 13, 2019, at 12:54 AM,
> wrote:
>
> Hi Jeff & Reshad,
>
>
>
> On Feb 18th I've already requested a sm
Greg,
This will be added to the agenda. Two brief notes:
- Presuming the agenda doesn't get too full, this will be intentionally made
the last agenda item. The intention is to permit maximum discussion time on
this.
- The chairs may precede the longer discussion with 1-2 slides of our own
tit
On Fri, Jun 07, 2019 at 12:20:30PM +0100, Stewart Bryant wrote:
>
> +1
>
> However if you really want BFD, you only need a lightweight IP
> implementation to carry it.
During the work for BFD for LAG, IETF already went a bit too close to
stepping into IEEE territory. Raw BFD over Ethernet would
On Sat, Jun 08, 2019 at 12:45:50PM +, Alexander Vainshtein wrote:
> To the best of my recollection the BFD WG hss tried to cooperate with IEEE
> 802.1, but these attempts have failed.
I think that's a mis-characterization.
Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (L
On Wed, Jun 12, 2019 at 02:45:54PM +, Alexander Vainshtein wrote:
> Albrecht, Reshad and all,
> I concur with Reshad - it will work (RFC 7130 never says anything about the
> number of links in the LAG).
A somewhat perverse use of the feature. Cute. :-)
> Such a session would still use encaps
Carlos,
> On Jun 19, 2019, at 10:09 PM, Carlos Pignataro (cpignata)
> wrote:
>
>>
>> This packet loop may not be practical for several encapsulations and thus is
>> out of scope for such encapsulations. Whether this is practical for vxlan
>> today, or in the presence of future extensions to
Greg,
> On Jun 20, 2019, at 12:50 AM, Greg Mirsky wrote:
>
> Hello Carlos,
> could you please refer me to the specification of BFD that defines the
> message format that is used in the Echo mode of BFD. Is it the BFD control
> packet? Something else?
It is implementation specific. Only the
ecide if we'll
proceed with the publication process. Let's use this time prior to IETF 105
to discuss any pending issues on these documents.
-- Jeff
On Sat, Feb 16, 2019 at 12:07:40PM -0500, Jeffrey Haas wrote:
> Working Group,
>
> On March 28, 2018, we started Working Group La
Working Group,
Reshad had put out a call for presentations for IETF 105 in mid-June. As of
this time, we don't currently have any agenda requests.
A quick status of current work:
- BFD for vxlan is undergoing post WGLC expert review at the request of our
Area Director.
- BFD Authentication dra
Working Group,
Here's the draft agenda for IETF 105.
https://datatracker.ietf.org/meeting/105/materials/agenda-105-bfd
Please note we are reserving the end of the session for discussion about BFD
v2. We are using Greg's presentation as a seed item for that discussion.
Our request is if you are
[largely speaking as an individual contributor]
Carlos,
On Mon, Jul 22, 2019 at 01:44:46PM +, Carlos Pignataro (cpignata) wrote:
> > On Jul 18, 2019, at 12:12 PM, Jeffrey Haas wrote:
> > Please note we are reserving the end of the session for discussion about BFD
> >
Les,
On Sun, Jul 28, 2019 at 12:23:05AM +, Les Ginsberg (ginsberg) wrote:
> I have a related question:
>
> In the case where the BGP neighbor is multiple hops away, what benefit does
> BFD dampening provide?
> (Note that I am assuming that there likely would be single hop BFD sessions
> use
1 - 100 of 536 matches
Mail list logo
