Subject: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)]

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sat, 26 Apr 2014 03:59:36 +0000

[renaming the subject to separate the thread from the poll]

> -----Original Message-----
> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya
> (nobo)
> Sent: Friday, April 25, 2014 7:05 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Working Group adoption for Seamless BFD (requires re-charter)
> 
> 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
> 
> > -----Original Message-----
> > From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Adrian
> > Farrel
> > Sent: Friday, April 25, 2014 5:12 PM
> > To: [email-masked]
> > Subject: RE: Working Group adoption for Seamless BFD (requires
> > re-charter)
> >
> > 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: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 26 Apr 2014 15:57:01 +0000

This looks really good -- I would add that BFD is expected to liaise and interface with other WGs in progressing the set of S-BFD work docs (e.g., SPRING, OSPF, ISIS)

Thanks,

Carlos.

---

From: Gregory Mirsky <[email-masked]>
Date: Sun, 27 Apr 2014 04:08:26 +0000

Hi Nobo,
I've tried some rewording following characteristics you've set forth. Here's what came out:
- define mechanism to perform single-ended continuity verification based on BFD specification;
- allow such mechanism to seamlessly work both proactively and on-demand;
- allow the mechanism maintain multiple sessions between two given network entities.

	Regards,
		Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Friday, April 25, 2014 9:00 PM
To: [email-masked]; [email-masked]
Subject: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)]

> 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.
> 
> - Flexibility to start, stop, resume, speed up/down the session 
> [quickly] as needed.

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 27 Apr 2014 14:47:37 +0000

Hi All,

Thanks for the suggestion Carlos. I absolutely agree that a text regarding liaison should be included.

Thanks for thoughtful texts Greg. I agree with almost all, but tweaked some texts (in first and third sentences). Reasons below.

Here's consolidated charter text proposal.

Attempt #2

Define a mechanism to perform single-ended path (ex: continuity) verification based on the BFD specification; allow such mechanism to seamlessly work both proactively and on-demand; allow the mechanism to maintain multiple sessions to a target entity. In doing this work, the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING.

> - define mechanism to perform single-ended continuity verification based

s/continuity verification based on BFD specification/path (ex: continuity) verification on the BFD specification/

I agree that the continuity check is the primary goal of this new mechanism. Although S-BFD alert discriminator requires further considerations and work, I prefer texts which implicitly excludes this mechanism.

> - allow the mechanism maintain multiple sessions between two given

s/ maintain multiple sessions between two given network entities/to maintain multiple sessions to a target entity/

I think it'll be a good idea for the word "maintain" to not imply anything on the target side (i.e. reflector session).

-Nobo

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Sunday, April 27, 2014 12:08 AM
> To: Nobo Akiya (nobo); [email-masked]; [email-masked]
> Subject: RE: BFD charter update proposal [was: RE: Working Group adoption
> for Seamless BFD (requires re-charter)]
> 
> Hi Nobo,

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 27 Apr 2014 14:57:21 +0000

Hi,

Correcting one typo below.

> Sent: Sunday, April 27, 2014 10:48 AM
> To: Gregory Mirsky; [email-masked]; [email-masked]; Carlos Pignataro
> (cpignata)
> Thanks for thoughtful texts Greg. I agree with almost all, but tweaked some
> texts (in first and third sentences). Reasons below.
> 
> Define a mechanism to perform single-ended path (ex: continuity)
> verification based on the BFD specification; allow such mechanism to
> seamlessly work both proactively and on-demand; allow the mechanism to
> maintain multiple sessions to a target entity. In doing this work, the WG will
> work closely with at least the following other WGs: ISIS, OSPF, SPRING.
> 
> 
> I agree that the continuity check is the primary goal of this new mechanism.
> Although S-BFD alert discriminator requires further considerations and work,
> I prefer texts which implicitly excludes this mechanism.

s/implicitly excludes/implicitly does not exclude/

Text should have been:

I agree that the continuity check is the primary goal of this new mechanism. Although S-BFD alert discriminator requires further considerations and work, I prefer texts which implicitly does not excludes this mechanism.

Sorry about that, should've had more coffee before writing this email :)

-Nobo

> s/ maintain multiple sessions between two given network entities/to
> maintain multiple sessions to a target entity/
> 
> I think it'll be a good idea for the word "maintain" to not imply anything on
> the target side (i.e. reflector session).
> 
> -Nobo
> 
> > Subject: RE: BFD charter update proposal [was: RE: Working Group
> > adoption for Seamless BFD (requires re-charter)]
> >
> > Hi Nobo,
> > > 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.
> > >
> > > > From: Rtg-bfd [mailto:[email-masked]] On Behalf Of
> > > > Adrian Farrel

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 28 Apr 2014 09:48:30 -0400

[Not specifically speaking as a chair here...]

> Define a mechanism to perform single-ended path (ex: continuity) verification based on the BFD specification; allow such mechanism to seamlessly work both proactively and on-demand; allow the mecha…

So... what exactly does seamless mean here?  What seams were you seeing that
you were trying to remove?

FWIW, I think the charter discussion is moving along well, but I've never
quite groked the context for "seamless" for the proposal.  "Stateless" BFD,
I can see quite well.

-- Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 28 Apr 2014 10:46:54 -0700

Hello,

> you were trying to remove?

:-)

I took the "seamless" always as a nice label. Bit marketing, no harm.

If someone would ask me to describe it: it's a single-sided BFD, driven by 
the active side, supported by a (passive, stateless) reflector.

Somehow I also stumble over "single-ended" but I assume it means start and 
end point are the same. Technically maybe not 100% accurate as the reflector 
processes the packet, i.e. it's not the pure forwarding U-turn we have with 
echo. But when turns being exact into being non-helpful? ;-)

Nevertheless, I like the direction the combined Nobo+Greg+Carlos text takes.

Regards, Marc

On Mon, 28 Apr 2014 09:48:30 -0400, Jeffrey Haas wrote:
>> maintain multiple sessions to a target entity. In doing this work, the WG 
>> will work closely with at least the following other WGs: ISIS, OSPF, 
>> SPRING.
>

---

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

Hi Jeff, Marc, all,

> > So... what exactly does seamless mean here?  What seams were you
> > seeing that you were trying to remove?
> 
> :-)
> 

Indeed lol. There has been several occasion of "name discussion", but we couldn't converge on something better than "seamless".

In any case, "seamless" is primary intended to describe:
- No bootstrapping
- No session up negotiation

Meaning "seam" is the time when a node wants to verify a path to the time when a node has verified the path.

"stateless" does also capture large part of this (i.e. reflector side). If we focus on the naming based on the reflector side, then "stateless" is probably a better choice. If we focus the naming based on the initiator side, then "seamless" does the job better.

As far as the charter text is concerned, I have no objection to replacing the word "seamless" with something else, if anyone wants to propose a text.

> Somehow I also stumble over "single-ended" but I assume it means start
> and end point are the same. Technically maybe not 100% accurate as the
> reflector processes the packet, i.e. it's not the pure forwarding U-turn we
> have with echo. But when turns being exact into being non-helpful? ;-)

That's what I assumed as well.

> Nevertheless, I like the direction the combined Nobo+Greg+Carlos text

:)

-Nobo

> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Monday, April 28, 2014 1:47 PM
> To: Jeffrey Haas
> Cc: Nobo Akiya (nobo); [email-masked]; Carlos Pignataro (cpignata)
> Subject: Re: BFD charter update proposal [was: RE: Working Group adoption
> > So... what exactly does seamless mean here?  What seams were you
> > seeing that you were trying to remove?
> 
> :-)
> 
> Somehow I also stumble over "single-ended" but I assume it means start
> and end point are the same. Technically maybe not 100% accurate as the
> reflector processes the packet, i.e. it's not the pure forwarding U-turn we
> have with echo. But when turns being exact into being non-helpful? ;-)
> 
> >> seamlessly work both proactively and on-demand; allow the mechanism
> >> to maintain multiple sessions to a target entity. In doing this work,
> >> the WG will work closely with at least the following other WGs: ISIS,
> >> OSPF, SPRING.
> >
> > So... what exactly does seamless mean here?  What seams were you
> > seeing that you were trying to remove?
> >
> > FWIW, I think the charter discussion is moving along well, but I've
> > never quite groked the context for "seamless" for the proposal.
> > "Stateless" BFD, I can see quite well.
> >
> > -- Jeff
> >

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 28 Apr 2014 18:17:55 +0000

Hi Jeff,

> quite groked the context for "seamless" for the proposal.  "Stateless" BFD,

Like others have said, we had some renaming discussions. Now it would be a good time to converge. Some of the (not perfect, but perfect is the enemy of good and progress here) more technical qualifiers are "Stateless", "Reflector", "Responder", "Mesh Group", "Asymmetric". These focus on the behavior of the responder mostly. Descriptive ones are also possible like "Easy", "Simple", "Seamless", etc.

Frankly I am not concerned about which name -- other than we should be consistent.

Net-net: I support your proposal of "Stateless" and a %s/Seamless/Stateless/g. It also keeps the same abbrev of S-BFD. What do others think?

Thanks,

Carlos.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 28 Apr 2014 14:48:42 -0400

Nobo,

> As far as the charter text is concerned, I have no objection to replacing the word "seamless" with something else, if anyone wants to propose a text.

And this is most of my point for charter discussion purposes.  If the word
is intended to mostly be an empty marketing word, let's not do that.  It
only confuses technical specifications. :-)

To my mind, the "fast" property you're looking for isn't a seam since it's
part of how the protocol works today.  Seams are where you have several
things butting together that require interfacing.  In this case, it's all of
the same components, just optimizing some of the cases.

-- Jeff

---

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

Hi Jeff,

Ok :)

Here's Attempt #3:

Define a mechanism to perform single-ended path (ex: continuity) verification based on the BFD specification; allow such mechanism to work both proactively and on-demand, without prominent initial delay; allow the mechanism to maintain multiple sessions to a target entity. In doing this work, the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING.

-Nobo

> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Monday, April 28, 2014 2:49 PM
> To: Nobo Akiya (nobo)
> Cc: Marc Binderberger; Jeffrey Haas; [email-masked]; Carlos Pignataro
> (cpignata)
> > "stateless" does also capture large part of this (i.e. reflector side). If we
> focus on the naming based on the reflector side, then "stateless" is
> probably a better choice. If we focus the naming based on the initiator side,
> then "seamless" does the job better.
> >
> > As far as the charter text is concerned, I have no objection to replacing the
> word "seamless" with something else, if anyone wants to propose a text.
> 
> And this is most of my point for charter discussion purposes.  If the word is
> intended to mostly be an empty marketing word, let's not do that.  It only
> confuses technical specifications. :-)
> 
> To my mind, the "fast" property you're looking for isn't a seam since it's part
> of how the protocol works today.  Seams are where you have several things
> butting together that require interfacing.  In this case, it's all of the same
> components, just optimizing some of the cases.
> 
> -- Jeff

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 28 Apr 2014 20:17:59 +0000

Hi Nobo, Jeff, et. al,
I agree that Reflector in S-BFD is stateless but I'm not sure if "stateless" can be equally applied to characterization of an S-BFD Sender. Perhaps "S" in S-BFD can stand for "single-ended"?
I think that it is important to stress in the charter update that:
*       S-BFD enables continuity check/verification/monitoring, i.e. availability of the path, and is not intended to support connectivity verification;
*       multiple session can be maintained not only to the same target entity, i.e. Your Discriminator, but between the same pair of network entities, i.e. IP addresses.

        Regards,
                Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Monday, April 28, 2014 12:05 PM
To: Jeffrey Haas
Cc: Carlos Pignataro (cpignata); [email-masked]
Subject: RE: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)]

Hi Jeff,

Ok :)

Here's Attempt #3:

-Nobo

> Cc: Marc Binderberger; Jeffrey Haas; [email-masked]<mailto:[email-masked]>; Carlos
> Pignataro
> (cpignata)
> Subject: Re: BFD charter update proposal [was: RE: Working Group
> probably a better choice. If we focus the naming based on the
> initiator side, then "seamless" does the job better.
> >
> And this is most of my point for charter discussion purposes.  If the
> word is intended to mostly be an empty marketing word, let's not do
> that.  It only confuses technical specifications. :-)
>
> To my mind, the "fast" property you're looking for isn't a seam since
> it's part of how the protocol works today.  Seams are where you have
> several things butting together that require interfacing.  In this
> case, it's all of the same components, just optimizing some of the cases.
>
> -- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 28 Apr 2014 16:22:20 -0400

[I'm not helping. :-)]

> I agree that Reflector in S-BFD is stateless but I'm not sure if "stateless" can be equally applied to characterization of an S-BFD Sender. Perhaps "S" in S-BFD can stand for "single-ended"?

For any of the proposals that intend to use "single" to describe this,
please think through trying to explain "single... bi-directional forwarding
detection" to our English as a (possibly distant) second language
participants.

-- Jeff (I already have the fun of explaining that the Daves had a sense of
humor with regard to the "B.F.D." acronym in the first place...)

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 28 Apr 2014 20:30:49 +0000

Hi Jeff, et. al,
frankly I was trying to save us from the nightmarish discussion of "single-ended two-way" vs. "dual-ended one-way" OAM.

	Regards,
		Greg

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Monday, April 28, 2014 1:22 PM
To: Gregory Mirsky
Cc: Nobo Akiya (nobo); Jeffrey Haas; Carlos Pignataro (cpignata); [email-masked]
Subject: Re: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)]

[I'm not helping. :-)]

> I agree that Reflector in S-BFD is stateless but I'm not sure if "stateless" can be equally applied to characterization of an S-BFD Sender. Perhaps "S" in S-BFD can stand for "single-ended"?

For any of the proposals that intend to use "single" to describe this, please think through trying to explain "single... bi-directional forwarding detection" to our English as a (possibly distant) second language participants.

-- Jeff (I already have the fun of explaining that the Daves had a sense of humor with regard to the "B.F.D." acronym in the first place...)

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 28 Apr 2014 21:58:00 +0000

> detection" to our English as a (possibly distant) second language

For oxymorons, we already have Bidirectional FD for Unidirectional links [RFC5883] and (unidirectional) LSPs [RFC5884] :-) That said, I agree that 'single' or 'one-side' do not maximize clarity. 

"Stateless BFD Reflection"? Simply "S-BFD" with expansion of the acronym left as an exercise for the brave reader?

Carlos, English as a 3rd language participant.

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 28 Apr 2014 19:22:32 -0700

the "Asymmetric" BFD is actually not bad. Or shall I say "aSymmetric". 
Anyway, Nobo's last proposal was:

Define a mechanism to perform single-ended path (ex: continuity) verification 
based on the BFD specification; allow such mechanism to work both proactively 
and on-demand, without prominent initial delay; allow the mechanism to 
maintain multiple sessions to a target entity. In doing this work, the WG 
will work closely with at least the following other WGs: ISIS, OSPF, SPRING.

Would it be a problem to be more specific? E.g.:

Define a mechanism to perform path (ex: continuity) verification based on the 
BFD specification, with only one side holding all state and a stateless 
reflector as the peer. Allow such mechanism ...

Regards, Marc

On Mon, 28 Apr 2014 21:58:00 +0000, Carlos Pignataro (cpignata) wrote:
>>> I agree that Reflector in S-BFD is stateless but I'm not sure if 
>>> "stateless" can be equally applied to characterization of an S-BFD 
>>> Sender. Perhaps "S" in S-BFD can stand for "single-ended"?
>> 
> For oxymorons, we already have Bidirectional FD for Unidirectional links 
> [RFC5883] and (unidirectional) LSPs [RFC5884] :-) That said, I agree that 
> 'single' or 'one-side' do not maximize clarity. 
> 
> "Stateless BFD Reflection"? Simply "S-BFD" with expansion of the acronym 
> left as an exercise for the brave reader?
>

---

From: Tina TSOU <[email-masked]>
Date: Tue, 29 Apr 2014 04:38:48 +0000

Dear all,

Softwire WG may be among the list of other WGs we should work with.

See Nobo's discussion on draft-tsou-softwire-bfd-ds-lite in Softwire mailing list.

Thank you,
Tina

> On Apr 29, 2014, at 10:22 AM, "Marc Binderberger" <[email-masked]> wrote:
> 
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 29 Apr 2014 04:48:17 +0000

"Connectionless" (CL-BFD) works for me.

(Now ducking my head...)

   Les

> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Carlos
> Pignataro (cpignata)
> Sent: Monday, April 28, 2014 11:18 AM
> To: Jeff Haas
> Cc: [email-masked]
> Like others have said, we had some renaming discussions. Now it would be
> a good time to converge. Some of the (not perfect, but perfect is the enemy
> of good and progress here) more technical qualifiers are "Stateless",
> "Reflector", "Responder", "Mesh Group", "Asymmetric". These focus on the
> behavior of the responder mostly. Descriptive ones are also possible like
> "Easy", "Simple", "Seamless", etc.
> 
> Net-net: I support your proposal of "Stateless" and a
> %s/Seamless/Stateless/g. It also keeps the same abbrev of S-BFD. What do
> others think?
> 
> Thanks,
> 
> Carlos.
> 
> > -- Jeff

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 28 Apr 2014 23:16:31 -0700

connections less BFD checking connection failures :D
Sorry couldn’t resist. :D

-sam

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 29 Apr 2014 07:05:12 +0000

Verification/monitoring (on-demand/proactive) of path continuity in packet switched connectionless network domain.

	Cheers,
		Greg

PS. Resisted but not for too long :)

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Sam Aldrin
Sent: Monday, April 28, 2014 11:17 PM
To: Les Ginsberg (ginsberg)
Cc: Carlos Pignataro; [email-masked]
Subject: Re: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)]

connections less BFD checking connection failures :D Sorry couldn't resist. :D

-sam

On Apr 28, 2014, at 9:48 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:

>> the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING.
>>> 
>> Like others have said, we had some renaming discussions. Now it would 
>> be a good time to converge. Some of the (not perfect, but perfect is 
>> the enemy of good and progress here) more technical qualifiers are 
>> "Stateless", "Reflector", "Responder", "Mesh Group", "Asymmetric". 
>> These focus on the behavior of the responder mostly. Descriptive ones 
>> are also possible like "Easy", "Simple", "Seamless", etc.
>> 
>> %s/Seamless/Stateless/g. It also keeps the same abbrev of S-BFD. What 
>> do others think?
>> 
>> Thanks,
>> 
>> Carlos.
>> 
>>> -- Jeff
>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 29 Apr 2014 09:10:44 +0200

hmmm - "seamless" might not describe what we want or
define very accurately, but at least it is short and
catchy (the just add a few paragraphs to explain what
we'll do).

/Loa

-- 

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

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 29 Apr 2014 16:04:38 +0530

Jeff,

>From a different vantage point having to wait for the BFD protocol to
finish its handshaking before it can do something thats useful
(ensure/verify data plane connectivity) is a seam. You cant send
traffic bursting down the tubes till BFD comes up and tells you that
everything is ok. Now, when you eliminate this waiting period -- or
drastically reduce it to the point where it becomes negligible you
have removed that "seam" and thereby made it "Seamless".

So my vote is for S-BFD where S could be Seamless, Super, Slick,
Smart, or ... ! :-)

I am not a big fan of Stateless since the clients (the nodes
initiating the session) may not necessarily be stateless. However, i
will not be lying down the train tracks in protest if this is what the
WG tends towards.

Cheers, Manav

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Tue, 29 Apr 2014 17:04:27 +0000

Hi,

Stateless or Soft BFD?.

-Nagendra

On 4/29/14 12:48 AM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

>>never

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 29 Apr 2014 19:46:33 +0000

I get the sense that some of you guys are having a lot of fun with the naming :)

Continuing to consolidate comments for the charter text proposal (attempt 4 below).

[Greg wrote]
> * S-BFD enables continuity check/verification/monitoring, i.e. availability of
> the path, and is not intended to support connectivity verification;
> * multiple session can be maintained not only to the same target entity, i.e.
> Your Discriminator, but between the same pair of network entities, i.e. IP
> addresses.

Agree with second bullet. As for first bullet, we can tighten the text to restrict to CC. Although result does leave out alert discriminator which is aimed to provide operators with more clues on why multihop BFD had failed, doing CV attempt with S-BFD is still a topic that requires further investigations/discussions. Let us revisit this at a later time then. 

[Marc wrote]
> Define a mechanism to perform path (ex: continuity) verification based on
> the BFD specification, with only one side holding all state and a stateless

Perhaps too specific, i.e. implies too much of requirements, IMHO. I figured it's beneficial for one person to consolidate comments into this charter text, which provides me with the privilege to apply my own filter first. But it doesn't mean that's the end, and feel free to discuss/argue :)

[Tina wrote]
> Softwire WG may be among the list of other WGs we should work with.

Yes I do I see S-BFD to fit nicely with DS-lite tunnel check from B4 to AFTR, and it does require DHCPv6 extension or something else to advertise BFD discriminators. I haven't seen anyone starting this activity yet, so I don't think we should explicitly include Softwire WG at this point. However, current proposal text says "... at least following other WGs: ISIS, OSPF, SPRING.". Thus I think we are ok. On the other hand, if you can rally sufficient interest before BFD WG charter update is done (May 8th), then I think it'll be good to explicitly include Softwire into the "at least" list.

Attempt #4

Define a mechanism to perform single-ended path (i.e. continuity) verification based on the BFD specification; allow such mechanism to work both proactively and on-demand, without prominent initial delay; allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING.

-Nobo

> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Loa
> Andersson
> Sent: Tuesday, April 29, 2014 3:11 AM
> To: [email-masked]
> hmmm - "seamless" might not describe what we want or define very
> accurately, but at least it is short and catchy (the just add a few paragraphs
> to explain what we'll do).
> 
> /Loa
> 
> > Verification/monitoring (on-demand/proactive) of path continuity in
> packet switched connectionless network domain.
> >
> > 	Cheers,
> > 		Greg
> >
> >>> to maintain multiple sessions to a target entity. In doing this
> >>> work, the WG will work closely with at least the following other WGs:
> ISIS, OSPF, SPRING.
> >>>>
> >>> Like others have said, we had some renaming discussions. Now it
> >>> would be a good time to converge. Some of the (not perfect, but
> >>> perfect is the enemy of good and progress here) more technical
> >>> qualifiers are "Stateless", "Reflector", "Responder", "Mesh Group",
> "Asymmetric".
> >>> These focus on the behavior of the responder mostly. Descriptive
> >>> ones are also possible like "Easy", "Simple", "Seamless", etc.
> >>>
> >>> %s/Seamless/Stateless/g. It also keeps the same abbrev of S-BFD.
> >>> What do others think?
> >>>
> >>> Thanks,
> >>>
> >>> Carlos.
> >>>
> >>>> -- Jeff
> >>
> >
> 
> --
> 
>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 30 Apr 2014 05:14:31 +0000

Hi Nobo,
I think you've nailed it. I'm happy with the Take #4.

	Regards,
		Greg

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]] 
Sent: Tuesday, April 29, 2014 12:47 PM
To: Loa Andersson; [email-masked]; Les Ginsberg (ginsberg); Carlos Pignataro (cpignata); Jeffrey Haas ([email-masked])
Cc: Marc Binderberger ([email-masked]); Gregory Mirsky; [email-masked]
Subject: RE: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)]

[Greg wrote]
> * S-BFD enables continuity check/verification/monitoring, i.e. 
> availability of the path, and is not intended to support connectivity 
> verification;
> Your Discriminator, but between the same pair of network entities, 
> i.e. IP addresses.

[Marc wrote]
> Define a mechanism to perform path (ex: continuity) verification based 
> on the BFD specification, with only one side holding all state and a 
> stateless reflector as the peer. Allow such mechanism ...

[Tina wrote]

Attempt #4

-Nobo

> accurately, but at least it is short and catchy (the just add a few 
> paragraphs to explain what we'll do).
> 
> /Loa
> 
> > On Apr 28, 2014, at 9:48 PM, Les Ginsberg (ginsberg) 
> > <[email-masked]>
> wrote:
> >
> >>> Carlos Pignataro (cpignata)
> >>> verification based on the BFD specification; allow such mechanism 
> >>> to seamlessly work both proactively and on-demand; allow the 
> >>> mechanism to maintain multiple sessions to a target entity. In 
> >>> doing this work, the WG will work closely with at least the following other WGs:
> ISIS, OSPF, SPRING.
> >>>>
> >>>> FWIW, I think the charter discussion is moving along well, but 
> >>>> I've never quite groked the context for "seamless" for the proposal.