Subject: I-D Action: draft-ietf-bfd-seamless-base-01.txt

From: [email-masked]
Date: Thu, 26 Jun 2014 11:25:33 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.

        Title           : Seamless Bidirectional Forwarding Detection (S-BFD)
        Authors         : Nobo Akiya
                          Carlos Pignataro
                          Dave Ward
                          Manav Bhatia
                          Juniper Networks
	Filename        : draft-ietf-bfd-seamless-base-01.txt
	Pages           : 17
	Date            : 2014-06-26

Abstract:
   This document defines a simplified mechanism to use Bidirectional
   Forwarding Detection (BFD) with large portions of negotiation aspects
   eliminated, thus providing benefits such as quick provisioning as
   well as improved control and flexibility to network nodes initiating
   the path monitoring.

   This document updates RFC5880.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-base-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Santosh P K <[email-masked]>
Date: Thu, 26 Jun 2014 19:02:34 +0000

Hello All,

    S-BFD version 1 is published. Thanks to all who had provided comments.  Diff between version 0 and 1 is significant but there are no technical changes. Below are the changes.

1.       Taken care of all review comments.

2.       “Full/partial reachability” is removed and focus is on the reachability.

3.       SPRING dependency is removed.

4.       IP specific details has been moved to "draft-akiya-bfd-seamless- ip".

5.       Consistent terminology.

6.       Lots of rephrasing for better readability.

Thanks

Santosh P K

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 26, 2014 11:56 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-bfd-seamless-base-01.txt

        Authors         : Nobo Akiya

                          Carlos Pignataro

                          Dave Ward

                          Manav Bhatia

                          Juniper Networks

                Pages           : 17

                Date            : 2014-06-26

Abstract:

   the path monitoring.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 26 Jun 2014 23:32:03 +0000

Hello BFDers,

Yes, many thanks to those provided comments on S-BFD.

Couple of additional things:

draft-ietf-bfd-seamless-base-01

-        Contains significant changes from the previous version.

-        There should not be any technical changes.

-        Greatly seeking comments on how we move forward with S-BFD discriminator uniqueness requirements.

draft-akiya-bfd-seamless-ip-03

-        Just published, links below.

-        Seeking comments on whether we want to define a new associated channel type for S-BFD.

URL:            http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamless-ip-03.txt

Status:         https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/

Htmlized:       http://tools.ietf.org/html/draft-akiya-bfd-seamless-ip-03

Diff:           http://www.ietf.org/rfcdiff?url2=draft-akiya-bfd-seamless-ip-03

Thanks!

-Nobo

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P K
Sent: Thursday, June 26, 2014 3:03 PM
To: [email-masked]
Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt

Hello All,

Thanks

Santosh P K

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, June 26, 2014 11:56 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-ietf-bfd-seamless-base-01.txt

        Authors         : Nobo Akiya

                          Carlos Pignataro

                          Dave Ward

                          Manav Bhatia

                          Juniper Networks

                Pages           : 17

                Date            : 2014-06-26

Abstract:

   the path monitoring.

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 29 Jun 2014 15:24:50 -0700

Hello Santosh and Nobo,

good stuff. Every time I read it I find something new to learn :-)

Re-reading the draft I had a few thoughts:

1) the draft is a "base" but it actually defines some details I would have 
expected in other drafts. One example is the IP/UDP header. Yes, IP is 
everywhere but what about applications where you don't require IP ?  Or the 
other way around: why having an extra "bfd-seamless-ip" draft when IP/UDP is 
an essential part of the base draft? 

2) similar the details of the state machine is something I think you do not 
really need in the base draft (!). Just define the reflector as truly 
reflecting the state from the incoming packet (plus overwrite with AdminDown) 
and you then leave it to the initiator if it uses a new state machine or the 
5880 Down-Init-Up sequence or something completely different.

S-BFD is largely about the reflector, I would say. Your draft brings up a 
good point: the state machine details are not relevant for interop as long as 
it stays within the definition of the reflector.

3) Actually I do not agree with statements in the draft about the 5880 state 
machine "may not be applicable" or that your proposal is better suited for 
the initial delay to bring BFD sessions up. Your state machine requires 

   RTT + Tr 

the original 5880 takes

   2 * (RTT + Tr).

   (RTT: Round Trip Time, Tr: the processing time of the reflector)

True, that is faster ;-) but I'm not sure you had this in mind. And if 
O(RTT+Tr) is relevant then you _do_ have a "considerable" delay too and are 
not "seamless" anymore :-)

4) The D-Flag ... forgot what I wanted to say :-)  Mainly, if you define the 
behaviour you expect on the reflector then you don't need to make any 
statements or attempts to be "5880 compliant".

> discriminator uniqueness requirements.

You mean how to be unique?  Or if uniqueness is necessary?
For the "how", I propose that a manual option to set a "unique discriminator" 
is a requirement. Does not exclude smarter, automatic methods but it gets you 
started.

Every implementation must allow to configure a unique value within the least 
significant M bits of the discriminator. M is implementation specific, 
recommendation is M >= 16. So yes, this wouldn't be the router-id then but a 
bfd-id. Pardon, sbfd_id ;-)

Regards, Marc

On Thu, 26 Jun 2014 23:32:03 +0000, Nobo Akiya (nobo) wrote:
> URL:            
> http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamless-ip-03.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/
> Diff:           
> http://www.ietf.org/rfcdiff?url2=draft-akiya-bfd-seamless-ip-03
>  
> Thanks!
>  
> -Nobo
>  
>     S-BFD version 1 is published. Thanks to all who had provided comments.  
> Diff between version 0 and 1 is significant but there are no technical 
> changes. Below are the changes.
>  
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 30 Jun 2014 23:18:00 +0000

Hi Marc,

> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Sunday, June 29, 2014 6:25 PM
> To: Nobo Akiya (nobo); Santosh P K
> Cc: [email-masked]; Marc Binderberger (mbinderb)

As always, thanks for comments!

> everywhere but what about applications where you don't require IP ?  Or
> the other way around: why having an extra "bfd-seamless-ip" draft when
> IP/UDP is an essential part of the base draft?

One of the changes from draft-ietf-bfd-seamless-base-00 to draft-ietf-bfd-seamless-base-01 to take out all IP related procedures and move it over to draft-akiya-bfd-seamless-base-ip-03. Intent of the authors is to:

1) Focus s-bfd-base on the procedures for UDP header and BFD header.
2) Focus s-bfd-ip on the procedures for IP header and MPLS.
3) Add ip-less procedures (i.e. associated channel) in either s-bfd-ip or create a separate draft (i.e. s-bfd-ip-less).
4) s-bfd-sr to be worked on at a later time.

Since we are only defining one port for S-BFD, this made sense to those who worked on the recent changes to the S-BFD documents.

Yes there are alternative ways to structure the documents. That being said, it would be helpful to hear "yeah above is reasonable" or "let's structure it this way" from you and the WG.

> really need in the base draft (!). Just define the reflector as truly reflecting
> the state from the incoming packet (plus overwrite with AdminDown) and
> you then leave it to the initiator if it uses a new state machine or the

This comment looks familiar :)

Texts above the state machine now says:

   For
   persistent SBFDInitiators, the states and the state machine described
   in [RFC5880] will function but are more than necessary.  The
   following diagram provides an optimized state machine for persistent
   SBFDInitiators.

And after the diagram:

   Note that the above state machine is different from the base BFD
   specification[RFC5880].  This is because the Init state is no longer
   applicable for the SBFDInitiator.  Another important difference is
   the transition of the state machine from the Down state to the Up
   state when a packet with State Up is received by the initiator.  

I think the texts and the described state machine is helpful for reader to better understand how S-BFD operates. So I prefer that this section remains somewhere to give better ideas to readers on how SBFDInitiators can be implemented. So, I think we have few options.

- Texts in the s-bfd-base-01 is sufficiently reasonable.
- Further texts should be added to make it more obvious that describe state machine is not mandatory.
- Move the SBFDInitiator State Machine section to appendix.

Thoughts?

> 
> S-BFD is largely about the reflector, I would say. Your draft brings up a good
> point: the state machine details are not relevant for interop as long as it
> stays within the definition of the reflector.

Yes I agree.

> not "seamless" anymore :-)

True, but you forgot the aspect of:

BFD:
  - in case of MPLS, LSP ping bootstraps the session on egress
  - session is created
  - tx timer is started at no faster than 1 second

S-BFD:
  - no LSP ping bootstrapping
  - session is created
  - packet can get tx'ed right away

>From above aspect, "considerable" delay (i.e. couple of seconds) is shaved off :)

> 
> 
> 4) The D-Flag ... forgot what I wanted to say :-)

LOL, I do that often too.

> 4) The D-Flag ... forgot what I wanted to say :-)

LOL, I do that often too.

> 4) The D-Flag ... forgot what I wanted to say :-)

Wait, didn't I reply to this already? :)

>  Mainly, if you define the

Agree, I don't think S-BFD is trying to be compliant with RFC5880, but S-BFD is trying to keep as much the same semantics possible with BFD so that we are not re-inventing everything.

> is a requirement. Does not exclude smarter, automatic methods but it gets
> you started.

Agree, this seems to be the direction we are heading, and I think it is reasonable. However, I (we?) do see a need for auto-foo, where foo may be "S-BFD discriminator allocation", "collision detection", "collision correction" or combination of them.

> 
> Every implementation must allow to configure a unique value within the
> least significant M bits of the discriminator. M is implementation specific,
> recommendation is M >= 16. So yes, this wouldn't be the router-id then but
> a bfd-id. Pardon, sbfd_id ;-)

For connectivity (i.e. reachability) test purpose, a system will need one sbfd-id [or more]. For other applications of S-BFD, there may be a need for a system to allocate few tens of S-BFD discriminators. So, this really places more weight on the "uniqueness" requirement and the need for auto-foo.

Thanks!

-Nobo

> > 2.       "Full/partial reachability" is removed and focus is on the
> > reachability.

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 30 Jun 2014 23:05:55 -0700

Hello Nobo,

> One of the changes from draft-ietf-bfd-seamless-base-00 to 
> draft-ietf-bfd-seamless-base-01 to take out all IP related procedures and 
> move it over to draft-akiya-bfd-seamless-base-ip-03. Intent of the authors 
> is to:

okay, so having an IP/UDP header is a fixed part of S-BFD then?  It's not as 
agnostic as RFC5880 is regarding the frame around the BFD packets?

I wasn't sure about this, thus my comment. If IP/UDP is an inherent part of 
S-BFD then ...

> it would be helpful to hear "yeah above is reasonable" or "let's structure 
> it this way" from you and the WG.

yeah I think it's reasonable :-)

About the state machine 

> This comment looks familiar :)

I think I repeat myself ;-) but there is a reason. Nothing wrong with the 
state machine you propose but I do not see this must be part of the 
definition. As an appendix, to show S-BFD allows for other state machines 
than 5880, that would be educational.

As explained I prefer a more open approach, the reflector truly reflecting 
the state as well. Your state engine is then solely driven by the initiator. 
Just setting the state to Up on the reflector is removing this degree of 
freedom, unnecessary IMHO and reducing the ability to "play" with the S-BFD 
definition.

> - Move the SBFDInitiator State Machine section to appendix.

I would like that!

From your reply

>> From above aspect, "considerable" delay (i.e. couple of seconds) is shaved 

What I like from your reply and what maybe should be more pointed in the 
draft are exactly the aspects that make S-BFD fast. Yes, you do say it 
somehow in section 3 and section 1, 2nd paragraph.  Maybe a nitpick but you 
could talk about your design principles more explicitly. Example from section 
3:

                                   Required result is that applications,
   on other network nodes, possess the knowledge of the mapping from
   remote entities to S-BFD discriminators.

What you probably want to say is that S-BFD is requiring the distribution of 
the mapping before a session is even requested (principle: fast setup). Then 
logically discriminators are allocated per (system, entity) and not per 
session. Again, you say it somehow in the text but you actually do not demand 
this principle.

> Agree, this seems to be the direction we are heading, and I think it is 
> reasonable. However, I (we?) do see a need for auto-foo, where foo may be 
> "S-BFD discriminator allocation", "collision detection", "collision 
> correction" or combination of them.

no doubt about the auto-foo but I assume this is topic for another draft?  If 
so, then how can you make your S-BFD base draft working interoperable? Thus 
my comment to define something very basic (manual) to have a starting point. 
Not because manual configs are so great.
(although: in these days of central controllers and software-defined networks 
maybe "manual" or it's API equivalent is all that is needed :-)

Regards, Marc

On Mon, 30 Jun 2014 23:18:00 +0000, Nobo Akiya (nobo) wrote:
> One of the changes from draft-ietf-bfd-seamless-base-00 to 
> draft-ietf-bfd-seamless-base-01 to take out all IP related procedures and 
> move it over to draft-akiya-bfd-seamless-base-ip-03. Intent of the authors 
> is to:
> 
> 3) Add ip-less procedures (i.e. associated channel) in either s-bfd-ip or 
> create a separate draft (i.e. s-bfd-ip-less).
> Since we are only defining one port for S-BFD, this made sense to those who 
> worked on the recent changes to the S-BFD documents.
> 
> Yes there are alternative ways to structure the documents. That being said, 
> it would be helpful to hear "yeah above is reasonable" or "let's structure 
> it this way" from you and the WG.
> 
>> 
>> 
>> reflecting
> I think the texts and the described state machine is helpful for reader to 
> better understand how S-BFD operates. So I prefer that this section remains 
> somewhere to give better ideas to readers on how SBFDInitiators can be 
> implemented. So, I think we have few options.
> 
>> good
> Agree, I don't think S-BFD is trying to be compliant with RFC5880, but 
> S-BFD is trying to keep as much the same semantics possible with BFD so 
> that we are not re-inventing everything.
> 
>> 
>> 
> Agree, this seems to be the direction we are heading, and I think it is 
> reasonable. However, I (we?) do see a need for auto-foo, where foo may be 
> "S-BFD discriminator allocation", "collision detection", "collision 
> correction" or combination of them.
> 
>> 
> For connectivity (i.e. reachability) test purpose, a system will need one 
> sbfd-id [or more]. For other applications of S-BFD, there may be a need for 
> a system to allocate few tens of S-BFD discriminators. So, this really 
> places more weight on the "uniqueness" requirement and the need for 
> auto-foo.
> 
> Thanks!
> 
> -Nobo
> 
>> 
>> 
>> Regards, Marc
>> 
>> 
>>