Subject: Working Group adoption for Seamless BFD (requires re-charter)

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Apr 2014 16:33:14 -0400

Working Group,

>From our last in-person IETF meeting in Vancouver, the S-BFD authors were
going to put additional work into their use cases and base protocol document
prior to requesting Working Group adoption.  That work has since been done
and, IMO, the quality of the documents has nicely improved.

But, being IETF work, we'd like to carry out further work on the proposal in
the openness of the WG.  Thus, I'd like to request the Working Group to
consider whether we'll want to adopt the Seamless BFD (S-BFD) documents.
Note that this work is currently outside the scope of our charter and would
require a re-charter.  Once we have a sense of the group for the interest in
this task we'll propose the charter update in support of the drafts.

The following two documents are current and describe the work:

http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/
http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/

Given the scope of this feature, I would like to particularly remind the
Working Group to focus on its security aspects.

The following three documents are slightly stale as a result of the
revisions in the base and use cases draft and will require an update.
However, they provide a sense of how the S-BFD mechanisms might be used.

Note in particular that the SR work will require coordination with the
SPRING Working Group.

http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/
http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ 
http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/

Finally, there is known future work targeting the distribution of the
necessary S-BFD bootstrapping information in OSPF and ISIS.  No drafts have
been authored on the topic at this time, but work on them is expected.

This begins a two week poll on whether the WG would like to adopt S-BFD as a
chartered task.  This poll ends on May 6.

As part of your response, please indicate if you have specific concerns
about individual drafts being part of this work.

Since Nobo is a contributor to this work, I will be taking the part of the
shepherding chair.

-- Jeff

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 21 Apr 2014 23:28:21 +0000

Hi Jeff,

Yes/support.

Being able to verify BFD up state "when needed" addresses the demand of upcoming applications, and flexibilities given to ingress truly harnesses the power of BFD.

> As part of your response, please indicate if you have specific concerns about
> individual drafts being part of this work.

I believe both use-case and base drafts are in good shape for WG adoption. If we re-charter, then I vote we focus on the use-case and base documents first. Afterwards, if/when required, then *-ip/*-sr/*-alert-discrim drafts can be revisited to describe technology specific procedures or extensions.

> been authored on the topic at this time, but work on them is expected.

Agree. Several folks have already expressed interest to take these up. If S-BFD gets included in the BFD WG charter, I think that'll be a good timing to kick off these tasks.

-Nobo, as individual contributor

> -----Original Message-----
> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Jeffrey Haas
> Sent: Monday, April 21, 2014 4:33 PM
> To: [email-masked]
> Subject: Working Group adoption for Seamless BFD (requires re-charter)
> 
> Working Group,
> 
> going to put additional work into their use cases and base protocol
> document prior to requesting Working Group adoption.  That work has since
> been done and, IMO, the quality of the documents has nicely improved.
> 
> The following three documents are slightly stale as a result of the revisions
> in the base and use cases draft and will require an update.
> This begins a two week poll on whether the WG would like to adopt S-BFD
> as a chartered task.  This poll ends on May 6.
> 
> As part of your response, please indicate if you have specific concerns about
> individual drafts being part of this work.
>

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 21 Apr 2014 16:41:40 -0700

WG chairs,

I support re-chartering the BFD WG to take up S-BFD work as it is important piece of OAM work useful in many areas like SPRING, SFC etc.

Would also like to support the adoption of the use-case and base documents for S-BFD.

cheers
-sam

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 21 Apr 2014 23:53:29 +0000

Dear WG chairs, et. al,
I support re-chartering of the BFD WG to include work on Seamless BFD to be in WG charter  scope.
Also, I support adoption of the listed drafts by the WG (co-author on use-case).

	Regards,
		Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Monday, April 21, 2014 1:33 PM
To: [email-masked]
Subject: Working Group adoption for Seamless BFD (requires re-charter)

Working Group,

>From our last in-person IETF meeting in Vancouver, the S-BFD authors 
going to put additional work into their use cases and base protocol document prior to requesting Working Group adoption.  That work has since been done and, IMO, the quality of the documents has nicely improved.

But, being IETF work, we'd like to carry out further work on the proposal in the openness of the WG.  Thus, I'd like to request the Working Group to consider whether we'll want to adopt the Seamless BFD (S-BFD) documents.
Note that this work is currently outside the scope of our charter and would require a re-charter.  Once we have a sense of the group for the interest in this task we'll propose the charter update in support of the drafts.

Given the scope of this feature, I would like to particularly remind the Working Group to focus on its security aspects.

The following three documents are slightly stale as a result of the revisions in the base and use cases draft and will require an update.
However, they provide a sense of how the S-BFD mechanisms might be used.

Note in particular that the SR work will require coordination with the SPRING Working Group.

Finally, there is known future work targeting the distribution of the necessary S-BFD bootstrapping information in OSPF and ISIS.  No drafts have been authored on the topic at this time, but work on them is expected.

This begins a two week poll on whether the WG would like to adopt S-BFD as a chartered task.  This poll ends on May 6.

As part of your response, please indicate if you have specific concerns about individual drafts being part of this work.

Since Nobo is a contributor to this work, I will be taking the part of the shepherding chair.

-- Jeff

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Tue, 22 Apr 2014 01:55:23 +0000

Support the WG re-chartering and the WG adoption of the S-BFD use-case and base drafts.
Thanks
Prasad

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Tuesday, April 22, 2014 2:03 AM
To: [email-masked]
Subject: Working Group adoption for Seamless BFD (requires re-charter)

Working Group,

-- Jeff

---

From: Mach Chen <[email-masked]>
Date: Tue, 22 Apr 2014 02:07:25 +0000

Hi,

I support the WG re-chartering to include S-BFD related works. And I also support to adopt the base and use case documents as WG documents.

Best regards,
Mach

> Sent: Tuesday, April 22, 2014 4:33 AM
> To: [email-masked]
> But, being IETF work, we'd like to carry out further work on the proposal in the
> openness of the WG.  Thus, I'd like to request the Working Group to consider
> whether we'll want to adopt the Seamless BFD (S-BFD) documents.
> require a re-charter.  Once we have a sense of the group for the interest in this
> task we'll propose the charter update in support of the drafts.
> 
> The following three documents are slightly stale as a result of the revisions in the
> base and use cases draft and will require an update.
> Finally, there is known future work targeting the distribution of the necessary
> S-BFD bootstrapping information in OSPF and ISIS.  No drafts have been
> authored on the topic at this time, but work on them is expected.
>

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 22 Apr 2014 04:20:57 +0000

Yes/support

Regards,
Jeff

> On Apr 21, 2014, at 1:33 PM, "Jeffrey Haas" <[email-masked]> wrote:
> 
> Working Group,
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 22 Apr 2014 06:31:37 +0000

Hi,

I support rechartering BFD WG to include S-BFD.

Work on IS-IS and OSPF extensions has already started as we speak.

Thanks, Manav

> document

---

From: "Srihari Raghavan (srihari)" <[email-masked]>
Date: Tue, 22 Apr 2014 06:35:28 +0000

As a member of a team implementing BFD and personally involved in the
S-BFD discussions, I support the WG re-chartering and adoption of S-BFD
use-case and base drafts.

Thanks
Srihari

---

From: "Girija Raghavendra Rao (giraghav)" <[email-masked]>
Date: Tue, 22 Apr 2014 07:19:46 +0000

Hi,

Support the WG re-chartering and the WG adoption of the S-BFD use-case and
base drafts.

Thanks & Regards
R.Girija

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Tue, 22 Apr 2014 07:22:27 +0000

Hi,

I support the rechartering and adoption of the SBFD use-case and base drafts

Regards
Mallik

From: "Girija Raghavendra Rao (giraghav)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 22 April 2014 12:49 PM
To: "Srihari Raghavan (srihari)" <[email-masked]<mailto:[email-masked]>>, Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Working Group adoption for Seamless BFD (requires re-charter)

Hi,

Thanks & Regards
R.Girija

On 22/04/14 12:05 PM, "Srihari Raghavan (srihari)" <[email-masked]<mailto:[email-masked]>>
wrote:

Thanks
Srihari

On 22/04/14 2:03 am, "Jeffrey Haas" <[email-masked]<mailto:[email-masked]>> wrote:

Working Group,

going to put additional work into their use cases and base protocol
document
prior to requesting Working Group adoption.  That work has since been
done
and, IMO, the quality of the documents has nicely improved.

But, being IETF work, we'd like to carry out further work on the proposal
in
the openness of the WG.  Thus, I'd like to request the Working Group to
consider whether we'll want to adopt the Seamless BFD (S-BFD) documents.
Note that this work is currently outside the scope of our charter and
would
require a re-charter.  Once we have a sense of the group for the interest
in
this task we'll propose the charter update in support of the drafts.

Finally, there is known future work targeting the distribution of the
necessary S-BFD bootstrapping information in OSPF and ISIS.  No drafts
have
been authored on the topic at this time, but work on them is expected.

as a

Since Nobo is a contributor to this work, I will be taking the part of
the
shepherding chair.

-- Jeff

---

From: Ignas Bagdonas <[email-masked]>
Date: Tue, 22 Apr 2014 09:15:19 +0100

Hi,

I have read the documents and believe that they address a needed and
valuable functionality, and I do support adopting the base and use cases
documents as WG items. A couple of areas that seem concerning to me - the
congestion aspects will need to be discussed, and likely more broadly than
in RFC5880, especially given the lack of state on the responder node, and
ability to allocate discriminators for nodes that do not necessary have a
control plane. Those concerns are not blocking and definitely could be
addressed later.

Ignas

---

From: Loa Andersson <[email-masked]>
Date: Tue, 22 Apr 2014 10:17:06 +0200

Folks,

I support adopting S-BFD as a chartered work item for the working group.

I do not have any particular concerns about the document listed below,
and think they should be adapted as working group document.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 22 Apr 2014 09:59:47 -0700

Hello Jeff,

I support to add S-BFD to the BFD charter and to adopt the "base" and "use 
case" document as workgroup documents.

I assume this won't stop us still having lots of discussions about various 
details ;-)

Regards, Marc

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Apr 2014 13:01:31 -0400

> I assume this won't stop us still having lots of discussions about various 

Hopefully more of them.

-- Jeff

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 23 Apr 2014 19:04:03 +0000

Thanks Ignas.

> control plane. Those concerns are not blocking and definitely could be

I agree with both. Below are my thoughts on the two areas.

Congestion:

Agree, S-BFD will require an additional hook. First bullet of section 9.8 of the base document describes a way for a reflector to tell those speaking to it to slow down, via changing the value of "Required Min RX Interval" in packets reflected. To handle the congestion from "trusted speakers", this may be sufficient. Some have expressed a concern of "this will change the failure detection time at initiators.", and that's certainly a valid concern. However, at some level, we have to rely on the users (operators or apps) to control how many S-BFD sessions are provisioned in the network (and how fast). The other aspect is congestion control to "non-trusted speakers". There's no guarantee that above technique will be honored by initiators. This one probably should be tackled with security aspect.

With that said, I think both congestion and security aspects can benefit from more people placing focus on them, whether what we have in base-03 is sufficient or we need more (if so what).

Lack of control plane:

Current direction appears to be "let's get S-BFD working with IGPs, and then expand the use", so looking at control-plane-less scenario at a later time make sense at this point.

-Nobo

> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Ignas
> Bagdonas
> Sent: Tuesday, April 22, 2014 4:15 AM
> To: [email-masked]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 25 Apr 2014 20:04:37 +0000

I support the WG re-chartering to include all mentioned aspects of S-BFD work.

   Les

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Apr 2014 22:11:46 +0100

Replying to Les, but only because it is the top email in the pile.

Tome for someone to start proposing some (minor) charter text?

Adrian

> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Les Ginsberg
> (ginsberg)
> Sent: 25 April 2014 21:05
> To: Jeffrey Haas; [email-masked]
> Subject: RE: Working Group adoption for Seamless BFD (requires re-charter)
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 25 Apr 2014 23:04:49 +0000

Hi Adrian, all,

Attempt #1

Define a mechanism to run the BFD protocol to seamlessly verify a path functionality when needed, to provide flexibilities to the initiator to quickly alter the BFD session operational state and parameters, and to allow the initiator to run multiple BFD sessions per verified path.

Tried to capture these characteristics:
- Quick session up.
- Flexibility to start, stop, resume, speed up/down the session [quickly] as needed.
- Not restricting to one session per interface, LSP, etc.

Open to tweaks, modifications and/or complete rewrites to what's proposed.

-Nobo

> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Friday, April 25, 2014 5:12 PM
> To: [email-masked]
> >  I support the WG re-chartering to include all mentioned aspects of
> > S-BFD
> work.
> >
> >    Les
> >
> > > document prior to requesting Working Group adoption.  That work has
> > > since been done and, IMO, the quality of the documents has nicely
> > > improved.
> > >
> > > But, being IETF work, we'd like to carry out further work on the
> > > proposal in the openness of the WG.  Thus, I'd like to request the
> > > Working Group to consider whether we'll want to adopt the Seamless
> BFD (S-BFD) documents.
> > > Note that this work is currently outside the scope of our charter
> > > and would require a re-charter.  Once we have a sense of the group
> > > for the interest in this task we'll propose the charter update in support of
> the drafts.
> > >
> > > Given the scope of this feature, I would like to particularly remind
> > > the Working Group to focus on its security aspects.
> > >
> > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discr
> > > im/ http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/
> > > Finally, there is known future work targeting the distribution of
> > > the necessary S-BFD bootstrapping information in OSPF and ISIS.  No
> > > drafts have been authored on the topic at this time, but work on them is
> expected.
> > >
> > > This begins a two week poll on whether the WG would like to adopt
> > > S-BFD as a chartered task.  This poll ends on May 6.
> > >
> > > As part of your response, please indicate if you have specific
> > > concerns about individual drafts being part of this work.
> > >

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 26 Apr 2014 15:55:51 +0000

Hi, Jeff,

I support the BFD WG taking on the work on S-BFD, as it solves a clear problem and strengthens the uses of BFD. I also support your proposed approach of i. rechartering (I believe this can be done as a surgical addition and not a major re-write), ii. adopting the -base and -usecase documents, and iii. continue to work and subsequently (later, not on this call) adopt the other adjunct docs.

Thanks,

Carlos.

---

From: Santosh P K <[email-masked]>
Date: Sun, 27 Apr 2014 06:43:10 +0000

Hi, Jeff,

Thanks
Santosh P K 

> > since been done and, IMO, the quality of the documents has nicely improved.
> >
> > Working Group to consider whether we'll want to adopt the Seamless BFD (S-
> BFD) documents.
> > would require a re-charter.  Once we have a sense of the group for the
> > interest in this task we'll propose the charter update in support of the drafts.
> >
> > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim
> > / http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/
> > have been authored on the topic at this time, but work on them is expected.
> >
> > the shepherding chair.