ond by September 5th.
>
> Regards,
> Reshad (co-chair hat).
>
> From: Greg Mirsky
> Date: Thursday, August 8, 2019 at 8:04 PM
> To: "Carlos Pignataro (cpignata)"
> Cc: "rtg-bfd@ietf.org" , "bfd-cha...@ietf.org"
> , Martin Vigoureux
>
Reshad,
If procedures permit it (I'm unclear on the detail), does it make sense to
pull the BFD yang module for a fix from the editor queue?
-- Jeff
On Mon, Aug 19, 2019 at 07:31:27PM +, Reshad Rahman (rrahman) wrote:
> I was looking at an old copy of the doc which didn't have default. So ye
Hi Jeff,
>
> Yes, to me it makes sense to do the change suggested by Martin (add
> "default tx-rx-intervals;" to the choice statement). BFD YANG co-authors,
> please respond asap if you disagree.
>
> Regards,
> Reshad.
>
> On
s the only current hold-up on issuing WGLC on the
BFD Unsolicted draft.
-- Jeff
On Fri, Aug 23, 2019 at 10:35:39AM -0400, Jeffrey Haas wrote:
> On Wed, Aug 21, 2019 at 10:33:01PM +, Reshad Rahman (rrahman) wrote:
> > And this is what the changes would look like.
>
> That looks
should be advanced to
the IESG for publication as RFCs.
-- Jeff and Reshad
On Tue, Jul 02, 2019 at 02:37:15PM -0400, Jeffrey Haas wrote:
> Working Group,
>
> A followup on this item.
>
> Currently, the status is identical to that which was last posted. Mahesh
> did make cont
I am unaware of any applicable IPR.
Jeff
> On Aug 27, 2019, at 17:25, Reshad Rahman (rrahman) wrote:
>
> BFD WG, authors, contributors,
>
> We have started WGLC for draft-ietf-bfd-large-packets and need to do an IPR
> poll. This mail starts the IPR poll.
>
> Are you aware of any IPR that
Working Group,
This last call period is set to expire at the end of the week.
Please respond whether you believe these documents SHOULD or SHOULD NOT be
advanced for publication.
-- Jeff
On Tue, Aug 27, 2019 at 11:17:18AM -0400, Jeffrey Haas wrote:
> Working Group,
>
> As we dis
at 8:04 PM
> To: "Carlos Pignataro (cpignata)"
> Cc: "rtg-bfd@ietf.org" , "bfd-cha...@ietf.org"
> , Martin Vigoureux
> Subject: Re: BFD Echo mode coverage in BFD for VXLAN
> Resent-From:
> Resent-To: Jeffrey Haas ,
> Resent-Date: Thursday, Aug
Xiam Min,
On Wed, Sep 11, 2019 at 12:01:11PM +0800, xiao.m...@zte.com.cn wrote:
> From my personal perspective, I don't think we should require BFD for
> VxLAN to support Echo mode, because as I know, although the final standard
> is still on the way, many vendors including my company have already
Carlos,
> On Sep 12, 2019, at 10:56 PM, Carlos Pignataro (cpignata)
> wrote:
>
> Thanks for the reminder, Reshad. I support publication of this document,
> short and useful.
>
> I only have one comment in regards to:
>
>It is also worthy of note that even if an implementation can functi
Ketan,
Thanks for your comments.
> On Sep 12, 2019, at 11:55 PM, Ketan Talaulikar (ketant)
> wrote:
>
> Hi All,
>
> I would like to ask some questions and seek clarifications on this draft.
>
> • I am aware that this draft originates from practical pain points at a
> specific opera
Carlo,s
> On Sep 13, 2019, at 11:48 AM, Carlos Pignataro (cpignata)
> wrote:
> Right. Or a burst of large packets and a set of bursts of “regular sized”
> ones. My main point is that I’d like the spec to allow for flexibility in
> usage if you think it makes sense, and not be all-or-nothing.
Les,
On Wed, Sep 18, 2019 at 05:24:17AM +, Les Ginsberg (ginsberg) wrote:
> 1)Sorry to be late in responding - but just back from vacation.
I wouldn't know anything about that sort of problem. :-)
> There are very legitimate concerns about the impact supporting padded BFD
> PDUs may have on
Les,
On Thu, Sep 19, 2019 at 12:06:13AM +, Les Ginsberg (ginsberg) wrote:
> > > If these protocol changes are to be made, shouldn't they be specified in
> > this document?? Otherwise the document would seem just informational.
> >
> > No. There's not really any room in BFD v1 for negotiation
Les,
> On Sep 18, 2019, at 10:37 PM, Les Ginsberg (ginsberg)
> wrote:
>
> First I would like to reemphasize that I support the draft - so we aren't on
> opposite sides here. It is just that Last Call seems premature.
The purpose of WGLC is to shake out final comments when things have otherwi
Les,
On Tue, Sep 24, 2019 at 10:48:51PM +, Les Ginsberg (ginsberg) wrote:
> A few more thoughts - maybe these are more helpful than my previous comments
> - maybe not. I am sure you will let me know.
>
> Protocol extensions allowing negotiation and/or advertisement of support for
> larger P
On Tue, Oct 01, 2019 at 11:11:13PM -, Albert Fu (BLOOMBERG/ 120 PARK) wrote:
> There are well known cases, including those you mentioned, where BFD has
> limitations in deterministically detecting data plane issue, and not
> specific with the BFD Large Packet Draft. I am a novice to the IETF
>
Les,
On Fri, Sep 27, 2019 at 09:14:08PM +, Les Ginsberg (ginsberg) wrote:
> > The primary reason this is a "may" in the non-RFC 2119 sense is that our
> > experience also suggests that when the scaling impacts are primarily pps
> > rather than bps that this feature will likely have no major im
Gyan,
On Wed, Oct 16, 2019 at 12:10:25AM -0400, Gyan Mishra wrote:
> https://tools.ietf.org/html/draft-ietf-pim-drlb-11
>
>
> So the BFD PIM Draft would register the PIM protocol and in asynchronous mode
> with echo disabled we can achieve sub millisecond detection time and
> convergence durin
Santosh and others,
On Thu, Oct 03, 2019 at 07:50:20PM +0530, Santosh P K wrote:
>Thanks for your explanation. This helps a lot. I would wait for more
> comments from others to see if this what we need in this draft to be
> supported based on that we can provide appropriate sections in the dra
Santosh,
On Mon, Oct 28, 2019 at 10:24:06PM +0530, Santosh P K wrote:
> "As per section 4 inner destination IP address MAY be set to 127/8 address.
> There could be firewall configured on VTEP to block 127/8 address range if
> set as destination IP in inner IP header. It is recommended to allow 12
Joel,
> On Oct 29, 2019, at 10:08 PM, Joel M. Halpern wrote:
>
> I presume that most silicon implementations of VxLAN VTEPs do not have any
> logic for trapping out BFD packets under any circumstances. While some may
> have been built anticipating this draft, we have to assume that many will
Greg,
On Wed, Oct 30, 2019 at 01:58:30PM -0700, Greg Mirsky wrote:
> On Wed, Oct 30, 2019 at 1:27 PM Jeffrey Haas wrote:
>
> > Greg,
> >
> > From the updated text:
> >
> > "At the same time, a service layer BFD session may be used between the
> >
gt; Hi Jeff,
>> thank you for the detailed clarification of your questions. Please find my
>> follow-up notes in-lined tagged GIM2>>.
>> Regards,
>> Greg
>> On Wed, Oct 30, 2019 at 2:14 PM Jeffrey Haas > <mailto:jh...@pfrc.org>> wrote:
>>Greg,
Packets
Authors : Jeffrey Haas
Albert Fu
Filename: draft-ietf-bfd-large-packets-02.txt
Pages : 7
Date: 2019-11-01
Abstract:
The Bidirectional Forwarding Detection (BFD) protocol is commonly
used to
Working Group,
A session request had gone in for IETF 106 to accommodate the need for a
possible session. The agenda, to this point, had been left as an open
question primarily to accommodate need to close on lingering questions in
active work. In particular, this was for two items:
- BFD for v
Les,
> On Nov 5, 2019, at 12:55 AM, Les Ginsberg (ginsberg)
> wrote:
>
> Jeff/Albert -
>
> Thanx for the updated version. This addresses my concerns.
>
> A couple of modest comments.
>
> 1)Section 3.4
>
> s/that balacing/that balancing
Queued for next rev.
> 2)Regarding S-BFD (Section 3.
Weiqiang Cheng,
BFD appears to be likely to have a small amount of business at the upcoming
IETF-106. The working grooup needs to find a secretary to commit to minutes
for us to meet.
If we do meet, you may have 10 minutes to discuss this.
I will ask you to include the following information in y
Greg.
> On Nov 1, 2019, at 4:27 PM, Greg Mirsky wrote:
>
> I think that it will be of interest to the group to get an update on the
> draft-mirmin-bfd-extended. We've added details on the use of the Padding TLV.
As noted previously, we will be deferring this work for next IETF.
> Also, would
ud Network:
10 minutes
-- Jeff
On Fri, Nov 01, 2019 at 02:15:35PM -0400, Jeffrey Haas wrote:
> Working Group,
>
> A session request had gone in for IETF 106 to accommodate the need for a
> possible session. The agenda, to this point, had been left as an open
> question primari
Xiao Min,
On Mon, Nov 11, 2019 at 02:48:47PM +0800, xiao.m...@zte.com.cn wrote:
> Hi Jeff,
>
> I could be one minutes taker if no others experienced volunteered.
Thank you. That's all we need. And with etherpad others may help too.
-- Jeff
Weiqiang Cheng,
On Tue, Nov 12, 2019 at 03:56:23PM +0800, Weiqiang Cheng wrote:
> We will cover those points in the presentation.
Thank you.
> We just have a quick review on TR-146, where it says that Echo function is
> used and the destination IP is set to an IP address of the sender (the
>
In the interest of permitting the presentations to move smoothly at this
Friday's rtgwg session, I withheld my comments from microphone. However,
please consider these comments for the record for IETF-106.
Firstly, I'm surprised the chairs had a BFD presentation at rtgwg. rtgwg is
indeed intende
Thank you to Xiao Min who produced the following transcript of the session from IETF 106.Here is a pointer to the meetecho recording:https://play.conf.meetecho.com/Playout/?session=IETF106-BFD-20191119-1710-- JeffChairs update:
5 mins - Jeff Haas
Welcome to BFD. I'm Jeff Haas, Reshad is unable to
The following are the minutes from IETF-106 for BFD. Thanks to Xiao Min for
providing transcripts to help produce them.
Please send comments on the minutes ASAP.
-- Jeff
Bidirectional Forwarding Detection (bfd)
IETF-106, Singapore
Tuesday 17:10
Minutes taker, Xiao Min.
Chairs update - see sl
Dave,
On Fri, Nov 22, 2019 at 09:35:12PM +, Dave Katz wrote:
> If BFD’s transport semantics are that interesting, someone could take a
> week and whip up a transport that looks rather like BFD but is properly
> suited for the purpose. That would make all of these issues go away, and
> would p
Greg,
On Wed, Nov 20, 2019 at 10:41:46AM +0800, Greg Mirsky wrote:
> Dear All,
> as was decided at the meeting, an explanation of using an address from the
> Internal host loopback interface address range has been added into the
> Security Consideration section:
> NEW TEXT:
>This document rec
Greg,
On Fri, Nov 29, 2019 at 01:27:58PM -0800, Greg Mirsky wrote:
> Dear All,
> this version includes the update to the Security Considerations section
> regarding the use of an internal host loopback address as the destination
> IP address of the inner IP header, as discussed at the meeting in S
Mirja,
On Tue, Dec 10, 2019 at 04:38:30AM -0800, Mirja Kühlewind via Datatracker wrote:
> This document describes the use of BFD in VXLAN, however, it does not specify
> any new protocol elements or extension. Therefore I would expect such a
> document to be informational. The shepherd write-up do
Benjamin,
On Mon, Dec 16, 2019 at 03:43:13PM -0800, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> --
> DISCUSS:
> ---
Carlos, Éric,
Note that I'm not an expert in the underlying MPLS technologies. I'll make
two notes:
BFD for vxlan is in a similar feature-space as RFC 5884, BFD for MPLS.
RFC 5884, section 7, paragraph 3, suggests a TTL of 1 and provides a
reference to RFC 4379.
RFC 4379, section 4.3, provides
Carlos,
On Wed, Dec 18, 2019 at 09:28:30PM +, Carlos Pignataro (cpignata) wrote:
> The TTL of 1 recommended for RFC 4379 / RFC 8029 S4.3 is because if the MPLS
> packet is mis-routed, or there's a forwarding mis-programming, then an MPLS
> LSE pop would expose the BFD packet and so that the
Ben,
On Wed, Dec 18, 2019 at 02:02:46PM -0800, Benjamin Kaduk wrote:
> On Wed, Dec 18, 2019 at 03:24:48PM -0500, Jeffrey Haas wrote:
> > This is a clean summary of the considerations. At least a portion of the WG
> > seems to be comfortable with "test to the management VNI
Carlos,
On Thu, Dec 19, 2019 at 03:22:28AM +, Carlos Pignataro (cpignata) wrote:
> > 2019/12/18 午後4:41、Jeffrey Haas のメール:
> > But given that point, what precisely is the objection to the inner IP header
> > of the BFD for vxlan having a TTL of 1?
>
> The inten
Adam,
[re: directing packets to the loopback network]
On Wed, Dec 18, 2019 at 08:37:03PM -0600, Adam Roach wrote:
> I'm a little unclear about the scope of leakage that is causing
> concern here. If you simply want to prevent the packets from making
> it to an end host, there are a lot of choices
Carlos,
On Thu, Dec 19, 2019 at 08:12:56PM +, Carlos Pignataro (cpignata) wrote:
> > 2019/12/19 午後1:06、Jeffrey Haas のメール:
Interesting. You're a bit more multi-lingual that I knew. :-)
> > The encapsulated packet's outer IP header, if single hop, could certainly
Much like the BFD Working Group discussion on the BFD for vxlan feature, the
IESG review for the draft has reached a stage where it is difficult to
determine what the related actions are. (IESG take note for tools
discussion!)
This email is an attempt to kick the conversation back into gear.
My
Greg,
Thank you for your work on updating the draft.
I will review the current draft (-12) vs. the open issues writeup I did a
while back and will endeavor to have this completed by end of this week.
-- Jeff
On Mon, May 25, 2020 at 03:11:24PM -0700, Greg Mirsky wrote:
> Dear Carlos,
> thank y
addressed. Once addressed, we'll ask the IESG
to take this up again.
On Mon, Jan 27, 2020 at 05:17:05PM -0500, Jeffrey Haas wrote:
> Much like the BFD Working Group discussion on the BFD for vxlan feature, the
> IESG review for the draft has reached a stage where it is difficult to
Greg,
> On Jun 16, 2020, at 9:05 PM, Greg Mirsky wrote:
> thank you for providing continued support and guidance. Please find my
> notes in-lined under tag GIM>>. Attached are the new working version and
> its diff to -12. There are two remaining Open Issues - 7 and 9. I much
> appreciate your c
On Wed, Jun 17, 2020 at 03:52:14PM -0400, Jeffrey Haas wrote:
> >> Proposed solution: A MAC value should be chosen that is well known and the
> >> text would become:
> >>
> >> "Destination MAC: A Management VNI, which does not have any tenants, wi
addressed in a reply to Benjamin.
-- Jeff
On Tue, Jun 16, 2020 at 05:10:57PM -0400, Jeffrey Haas wrote:
> > Open Issue 2: Document Status should be Informational rather than Proposed
> > Standard.
> >
> > Proposed Action: Greg should make the document Informational.
Mahesh,
While reviewing version -10, I had the following questions:
For the state machine changes, in the Init->Init state, we have NULL auth.
While this is a "boring" transition, it's also happening at a very slow part
of the state machine; timers should be once a second. Is there a strong
argu
Éric,
On Wed, Jul 22, 2020 at 05:28:14AM -0700, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-bfd-vxlan-13: Abstain
>
[...]
> --
> COMMENT:
>
Manav,
On Thu, Jul 23, 2020 at 08:01:01AM +0530, Manav Bhatia wrote:
> GIven that there isnt a huge advantage in using Auth during INIT -> INIT
> and Down -> Down we should probably stick to NULL for the sake of
> simplicity. Unless, somebody finds a problem with using NULL.
Part of the reason I
Manav,
On Thu, Jul 23, 2020 at 08:19:26PM +0530, Manav Bhatia wrote:
> I am sorry I dont understand this point.
>
> I would like to stick to NULL because it's less prone to
> implementation/inter-op bugs where you dont need to keep changing the kind
> of auth you use depending upon where you are
Chairs: Jeffrey Haas, Reshad Rahman
# Agenda:
## Chairs update:
10 mins - Jeff Haas & Reshad Rahman
**Greg Mirsky** asks about bfd 2.0.
**Jeff Haas** answers we're likely rechartering to tighten our charter to the
core continuity check (CC) case. We're likely to try to spin
list of jh...@pfrc.org.
Document: draft-ietf-bfd-vxlan,
https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
Change by Jeffrey Haas on 2020-08-03 12:03 PDT:
: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
: Standard, Informational, Experimental, or Historic)? Why is this
Working Group,
https://datatracker.ietf.org/doc/draft-cw-bfd-unaffiliated-echo/
At the virtual IETF 108, Unaffiliated BFD Echo Function was presented. This
is a followup of a presentation given at IETF 106.
The authors have indicated they would like to have this work adopted by the
BFD WG. Thi
Working Group,
https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/
With apologies to the authors of BFD unsolicited, this document is past due
for Working Group Last Call. The primary holdup on the document had been
last minute interaction with the RFC Editor with regard to its impact o
wrote:
>>
>> Hi Jeff,
>> do you think that the record in the Usage filed for the requested MAC
>> address instead of "BFD over VXLAN" be more generic, e.g., "Active OAM over
>> NVO3"?
>> What do you think?
>>
>> Regards,
&
"Control channel in NVO3"? That would be helpful to the work on OAM in
> Geneve.
>
> Regards,
> Greg
>
> On Mon, Aug 10, 2020 at 12:14 PM Jeffrey Haas <mailto:jh...@pfrc.org>> wrote:
> Thank you, Donald.
>
> Greg, would you bump the draft with this a
I requested additional internal review from my colleagues who work on
Juniper's BFD implementation. Please find his comments attached.
-- Jeff
---8<--- cut here --->8--
Date: Mon, 17 Aug 2020 16:11:05 -0400
From: Raj Chetan Boddireddy
Subject
On Tue, Aug 04, 2020 at 09:21:22AM -0400, Jeffrey Haas wrote:
> Working Group,
>
> https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/
>
> With apologies to the authors of BFD unsolicited, this document is past due
> for Working Group Last Call. The primary holdup o
those.
-- Jeff
On Tue, Aug 04, 2020 at 09:15:49AM -0400, Jeffrey Haas wrote:
> Working Group,
>
> https://datatracker.ietf.org/doc/draft-cw-bfd-unaffiliated-echo/
>
> At the virtual IETF 108, Unaffiliated BFD Echo Function was presented. This
> is a followup of a presentation give
Greg,
Thank you for your patience.
On Thu, Jul 30, 2020 at 09:00:38AM -0700, Greg Mirsky wrote:
> Dear All,
> I much appreciate it if you can share the conclusion of the discussion of
> the draft-mirsky-bfd-mpls-demand.
>
> Regards,
> Greg
The BFD Working Group chairs and Area Director have rev
It's been some time since I've reviewed the entire document, so this is
almost fresh for me as well. :-)
My comments largely follow Reshad's:
- I don't know what [S] is intended to be.
- The chains in the diagrams aren't necessarily clear. I think they're
intended to represent that you can wo
Congratulations and thank you for all of your hard work Authors and Working
Group on another RFC.
-- Jeff and Reshad
- Forwarded message from rfc-edi...@rfc-editor.org -
Date: Mon, 14 Dec 2020 07:52:36 -0800 (PST)
From: rfc-edi...@rfc-editor.org
To: ietf-annou...@ietf.org, rfc-d...@rfc-
[Speaking as an individual contributor]
Authors,
Attached, please find an rfcdiff containing some suggested edits to your
draft. The intent is to try to add clarity to the document. If you would
find it helpful, I can also forward a patch vs. the published -01 xml.
---
Additionally, there are
Alan, Mahesh,
Let's go back to base expectations.
Right now, the base BFD specification leverages HMAC MD5 or SHA-1 for its
security. The security mechanism is on every packet. Prior measurements
have shown that for the desired protocol rates for failure detection that
even those older mechanis
Alan,
On Mon, Jul 26, 2021 at 10:35:01AM -0400, Alan DeKok wrote:
>
> That should be possible.
[...]
> Yes.
[...]
> Yes.
>
> > This means that the benefit for the feature would require a function that
> > can be run on a window of packets for predicted inputs and generate the pool
> > of n
Mahesh,
Sorry for long delay.
On Mon, Jul 26, 2021 at 04:25:25PM -0700, Mahesh Jethanandani wrote:
> > On Jul 26, 2021, at 7:48 AM, Jeffrey Haas wrote:
> > What's being requested is that our specifications have some specificity and
> > a proposal be made for a suitab
Mike,
Thanks for bringing this to the BFD Working Group. I've had a chance to
read through the draft. In spite of it being several years since I've
worked on/with PIM, I think I've understood it. :-)
If I were to re-state the longer version of the draft's name, this is
effectively "using BFD-MP
Med,
On Mon, Aug 30, 2021 at 12:19:23PM +, mohamed.boucad...@orange.com wrote:
> Hi Greg,
>
> Thank you for checking the OAM part and for sharing this comment.
>
> As you can read in both sections 4 and 5, this model is ** not a device
> configuration model **. The focus is on aspects that
Med,
On Wed, Sep 01, 2021 at 06:48:43AM +, mohamed.boucad...@orange.com wrote:
> Hi Jeff,
>
> Actually, except local-multiplier that we call detection-multiplier, the
> same names are used in both drafts. We can fix that one.
Certainly a start.
> Please note that we are not using the inter
Alvaro,
On Wed, Sep 01, 2021 at 03:41:12PM +0200, Alvaro Retana wrote:
> On August 31, 2021 at 4:51:17 PM, Jeffrey Haas wrote:
> > My second concern is shorter. Section 2.3 recommends that the p2mp BFD
> > sessions use a TTL of 255 and reference the GTSM procedures in RFC 5881.
>
Med,
On Wed, Sep 01, 2021 at 01:21:03PM +, mohamed.boucad...@orange.com wrote:
> The IETF LC was actually closed since 2021-08-06.
>
> Even if the IETF LC is closed, the current BFD comments will be part of the
> comments we will be addressing in the next iteration. For your record, we
> h
Working Group,
Now that the BFD YANG work is getting ready to pop out of the RFC Editor's
queue, it's an appropriate time to finish the last minor details for the
BFD Unsolicited draft.
Previously, the draft had exited Working Group Last Call with minor things
to be resolved, and a process quest
I have one minor additional tweak suggested to Greg's change. I think once we
converge on this point, I'll do the document shepherd report and submit to the
IESG.
> On Oct 18, 2021, at 8:47 PM, Greg Mirsky wrote:
>
> Hi Robert and the Authors,
> thank you for your kind consideration of my co
en on the passive side Unsolicited BFD sessions goes down an
> implementation MAY keep such session state for a configurable amount
> of time. Temporarily keeping such local state may permit retrieving
> additional operational information of such session which went d
BFD Unsolicited Authors,
As part of doing the document shepherd writeup for BFD Unsolicited prior to
sending it to the IESG for publication, I reviewed the archives to find whether
you had done your IPR attestations.
You haven't, but were asked at the time. :-)
Please respond to this thread as
$ pyang --ietf --max-line-length 69 ietf-bfd-unsolicited\@2021-10-15.yang
ietf-bfd-unsolici...@2021-10-15.yang:17: warning: imported module "ietf-bfd"
not used
ietf-bfd-unsolici...@2021-10-15.yang:22: warning: imported module
"ietf-bfd-ip-sh" not used
ietf-bfd-unsolici...@2021-10-15.yang:128: wa
uot;;
> reference "RFC 9127: A YANG data model for BFD unsolicited";
>}
>
> On Wednesday, October 20, 2021, 10:47:05 AM EDT, Jeffrey Haas <mailto:jh...@pfrc.org>> wrote:
>
>
> $ pyang --ietf --max-line-length 69 ietf-bfd-unsolicited\@2021-10-15.yang
&
> On Oct 20, 2021, at 4:58 PM, Mahesh Jethanandani
> wrote:
>
>
>
>> On Oct 20, 2021, at 1:53 PM, Jeffrey Haas > <mailto:jh...@pfrc.org>> wrote:
>>
>> There's also a note in the nits that the security considerations netconf
>> b
Tom,
I've not hit "publish" yet...
> On Oct 21, 2021, at 7:39 AM, t petch wrote:
>
> On 20/10/2021 22:00, Jeffrey Haas wrote:
>>
>>> On Oct 20, 2021, at 4:58 PM, Mahesh Jethanandani
>>> wrote:
>>>> On Oct 20, 2021,
Tom,
Minimally it updates one of the revision clauses, which I had missed. It's
likely the one you're noting was an issue.
If you could respond to the other mail we can try to close off on the issues
you're raising.
-- Jeff
> On Oct 21, 2021, at 6:21 PM, internet-dra...@ietf.org wrote:
>
>
Congratulations, Working Group, on finally getting the BFD Yang module
published!
This incidentally unclogs some MISREF at the RFC Editor that will permit some
other protocol YANG modules progress.
-- Jeff
> Begin forwarded message:
>
> From: rfc-edi...@rfc-editor.org
> Subject: RFC 9127 on
2, 2021, at 11:40 AM, t petch wrote:
>
> On 22/10/2021 12:59, Jeffrey Haas wrote:
>> Tom,
>>
>> Minimally it updates one of the revision clauses, which I had missed. It's
>> likely the one you're noting was an issue.
>>
>> If you cou
Working Group,
We won't be meeting at IETF-112. Here's the current status of our work:
We've re-organized the BFD wiki where we track our state.
https://trac.ietf.org/trac/bfd/wiki
Active status has been filtered here:
https://trac.ietf.org/trac/bfd/wiki/BFD%20Working%20Group%20Current%20Act
I owe the commenters in this thread a detailed response in the near future.
However, I did want to highlight the underlying motivation the Working Group
had to pick up this work.
On Wed, Nov 17, 2021 at 05:00:09PM +0800, xiao.m...@zte.com.cn wrote:
> As you may have known or not, before this draf
ntioned in TR-146? If not, how the
> BFD WG has concluded that BBF has any interest in that work?
>
> Regards,
> Greg
>
> On Thu, Nov 18, 2021 at 6:29 AM Jeffrey Haas <mailto:jh...@pfrc.org>> wrote:
> I owe the commenters in this thread a detailed response in the
David,
On Thu, Nov 18, 2021 at 05:18:38PM +, David Sinicrope wrote:
> Sorry, I don't recall our discussion, but then it would have been as long ago
> as Singapore in Nov 2019 or before.
> (Is it possible you spoke with Dave Allan?)
That's possible! As I noted in the thread, my notes from th
On Thu, Nov 18, 2021 at 12:38:02PM -0500, Jeffrey Haas wrote:
> David,
>
> On Thu, Nov 18, 2021 at 05:18:38PM +, David Sinicrope wrote:
> > Sorry, I don't recall our discussion, but then it would have been as long
> > ago as Singapore in Nov 2019 or before.
>
Xiao Min,
On Fri, Nov 19, 2021 at 10:15:08AM +0800, xiao.m...@zte.com.cn wrote:
> Thank you Jeff! A very clear description on the core motivation and current
> situation.
> From the author's perspective, I'd like to remove the reference to BBF TR-146
> if it's becoming a blocking issue instead o
Greg, Xiao Min,
Picking one small section of the replies as the basis of my own reply:
On Wed, Nov 17, 2021 at 07:48:34AM -0800, Greg Mirsky wrote:
> > The last sentence in the next proposed update to the RFC 5880 concerns me:
> > The Echo function may also be used independently, with neither
> >
Greg,
On Tue, Nov 23, 2021 at 09:21:42AM -0800, Greg Mirsky wrote:
> On Mon, Nov 22, 2021 at 2:10 PM Jeffrey Haas wrote:
> > The desired behavior is "obvious". If you support BFD Echo, you'd like to
> > turn on that code to the remote system and do so without letti
of Demand mode)."
>
> Best Regards,
> Xiao Min
> --原始邮件--
> 发件人：GregMirsky
> 收件人：Jeffrey Haas;
> 抄送人：肖敏10093570;rtg-bfd WG;draft-ietf-bfd-unaffiliated-e...@ietf.org;
> 日 期 ：2021年11月24日 05:17
> 主 题 ：Re: Several questions about the draft-ietf-b
Working Group,
The chairs are considering the following text for a liaison statement to the
Broadband Forum with regard to draft-ietf-bfd-unaffiliated-echo.
We'd like your feedback before we send it out.
-- Jeff
-
From group: bfd
From Contact: Jeffrey Haas
To Group: Broa
e
> draft are encouraged to participate in the development of the draft in the
> IETF via the IETF process."
>
> I hope this helps. Please let me know if you have any questions.
>
> Dave
>
>
>
> On 11/24/21 11:46, Jeffrey Haas wrote:
>> Working Group,
>
On Thu, Nov 25, 2021 at 11:03:16AM +0800, xiao.m...@zte.com.cn wrote:
> I have no objection to the comparison, please go on.
> One thing I want to emphasize is that, whether DC use case (brought up by
> draft-wang-bfd-one-arm-use-case) or broadband access use case (brought up by
> BBF TR-146), th
101 - 200 of 551 matches
Mail list logo
