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

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 1 Jul 2014 14:32:36 +0000

Hi Marc,

> -----Original Message-----
> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Tuesday, July 01, 2014 2:06 AM
> To: Nobo Akiya (nobo)
> Cc: Santosh P K; [email-masked]; Marc Binderberger (mbinderb)
> Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt
> 
> 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 :-)

Thanks! To answer your questions above ...

I believe RFC5880 focuses on the BFD header alone since ports are different for various use of the BFD (i.e. SH, MH, MPLS).
S-BFD on the other hand will have one port for all use of S-BFD, except for IP-less case.
So, except for the exception case (i.e. IP-less), current S-BFD document structure is a reasonable (or not a bad) fit.

Thinking more on the exception ... S-BFD-IP document has:

   Ed-Note: Discuss whether we want a new associated channel type for
   S-BFD.

But perhaps we should create a separate document for IP-less.

> 
> 
> 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!

ACK on moving the example state machine to appendix (some texts will still be kept around in the current section).

Regarding SBFDReflector reflecting the state, I do see your point. If the state of received S-BFD packet is reflected by the SBFDReflector, then the SBFDInitiator requires no FSM changes (i.e. able to re-use FSM from RFC5880). Although that will result in time(2 * (RTT + Tr)) for the SBFDInitiator to reach UP state. In reality, it actually would be time((2 * (RTT _ Tr)) + tx_gap) where "tx_gap" is the interval between the 2 packets transmitted. I do think one of the strength of S-BFD is the fact it only takes one packet to complete the connectivity test. Thus I'm leaning towards standing the ground of SBFDReflector only being able to send [UP, ADMINDOWN] states, and not reflecting received state.

> 
> From your reply
> 
> > 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 :)
> 
> 
> 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.

Make sense, let us expand a bit more on why S-BFD will result in faster setup than BFD, in the next revision.

> 
> 
> > 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 :-)

This is a valuable comment, and I do like your suggestion of auto-foo being in a separate document (than base). 

Do you think current texts in "5.  S-BFD Discriminators" section is sufficient to imply this?

Thanks!

-Nobo

> 
> 
> Regards, Marc
> 
> 
> 
> 
> 
> On Mon, 30 Jun 2014 23:18:00 +0000, Nobo Akiya (nobo) wrote:
> > Hi Marc,
> >
> >> -----Original Message-----
> >> 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)
> >> Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt
> >>
> >> Hello Santosh and Nobo,
> >>
> >> good stuff. Every time I read it I find something new to learn :-)
> >
> > As always, thanks for comments!
> >
> >>
> >> 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?
> >
> > 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.
> >
> >>
> >>
> >> 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.
> >
> > 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.
> >
> >>
> >>
> >> 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 :-)
> >
> > 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
> >> behaviour you expect on the reflector then you don't need to make any
> >> statements or attempts to be "5880 compliant".
> >
> > 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.
> >
> >>
> >>
> >>> -        Greatly seeking comments on how we move forward with S-BFD
> >>> 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.
> >
> > 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
> >
> >>
> >>
> >> Regards, Marc
> >>
> >>
> >>
> >> On Thu, 26 Jun 2014 23:32:03 +0000, Nobo Akiya (nobo) wrote:
> >>> 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.t
> >>> xt
> >>> 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,
> >>>     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
> >>>
> >>>
> >>> 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: Marc Binderberger <[email-masked]>
Date: Tue, 1 Jul 2014 09:19:59 -0700

Hello Nobo,

> But perhaps we should create a separate document for IP-less.

hmm, that is a bit a circle. If you have already IP-less on the todo list 
then why not structure the documents accordingly?

If I understand right what you require from the outer frame mechanism is 
this: your outer frame must be able to distinguish S-BFD from other (BFD) 
traffic (ex: UDP port assigned for S-BFD).

Then define the UDP port, the IP address copying/selection in seamless IP.
I mention this as I think the structure of 5880 + 5881/5883/5884/[...] was 
quite useful.

Anyway, "yeah I think it's reasonable" still holds.  :-)

> Regarding SBFDReflector reflecting the state, I do see your point. If the 
> state of received S-BFD packet is reflected by the SBFDReflector, then the 
> SBFDInitiator requires no FSM changes (i.e. able to re-use FSM from 
> RFC5880). Although that will result in time(2 * (RTT + Tr)) for the 
> SBFDInitiator to reach UP state. In reality, it actually would be time((2 * 
> (RTT _ Tr)) + tx_gap) where "tx_gap" is the interval between the 2 packets 
> transmitted. I do think one of the strength of S-BFD is the fact it only 
> takes one packet to complete the connectivity test. Thus I'm leaning 
> towards standing the ground of SBFDReflector only being able to send [UP, 
> ADMINDOWN] states, and not reflecting received state.

No, you may not see my new point yet :-)
While discussing with you I realized the Reflector should not impose any 
state machine model. Dumb reflection of the state provides full control to 
the Initiator side which can implement any state machine it likes.
For your Down<->Up machine, it's possible too with the state reflection. You 
need one additional rule

    if (bfd.SessionType == SBFDInitiator):
        set state in outgoing BFD packet to "Up".

Carrying this a step further: I do not see why vendor X could not use a 
different state machine than vendor Y. The interop is guaranteed by the same 
definition of what the reflector does.

And yes, I realized your state machine does it with a single packet and I'm 
not arguing against this improvement.

> sufficient to imply this?

I think section 5 is fine and we can leave certain aspects between the lines. 
Even my "complicated" comment with "M least significant bits" for a manual 
configuration is nothing we should write down. I only mentioned it here to 
see if it stirs up something, some concern. But otherwise common sense and 
silent agreements will probably get us towards some basic 32-bit 
manual-config implementations for day-1. Well, I hope so :-)

Regards, Marc

On Tue, 1 Jul 2014 07:32:36 -0700, Nobo Akiya (nobo) wrote:
> I believe RFC5880 focuses on the BFD header alone since ports are different 
> for various use of the BFD (i.e. SH, MH, MPLS).
> So, except for the exception case (i.e. IP-less), current S-BFD document 
> structure is a reasonable (or not a bad) fit.
> 
> Regarding SBFDReflector reflecting the state, I do see your point. If the 
> state of received S-BFD packet is reflected by the SBFDReflector, then the 
> SBFDInitiator requires no FSM changes (i.e. able to re-use FSM from 
> RFC5880). Although that will result in time(2 * (RTT + Tr)) for the 
> SBFDInitiator to reach UP state. In reality, it actually would be time((2 * 
> (RTT _ Tr)) + tx_gap) where "tx_gap" is the interval between the 2 packets 
> transmitted. I do think one of the strength of S-BFD is the fact it only 
> takes one packet to complete the connectivity test. Thus I'm leaning 
> towards standing the ground of SBFDReflector only being able to send [UP, 
> ADMINDOWN] states, and not reflecting received state.
> 
>> 
>> From your reply
>> 
>>>>> Htmlized:       
>>>>> http://tools.ietf.org/html/draft-akiya-bfd-seamless-ip-03
>>>>> Diff:

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 2 Jul 2014 22:52:10 +0000

Hello Marc,

> From: Marc Binderberger (mbinderb)
> Sent: Tuesday, July 01, 2014 12:20 PM
> To: Nobo Akiya (nobo)
> Cc: Marc Binderberger; Santosh P K; [email-masked]
> hmm, that is a bit a circle. If you have already IP-less on the todo list then
> why not structure the documents accordingly?
> 

Agree, it's not the prettiest either way. But we also may not want IP, SR, SFC, etc documents to repeat the UDP port and procedures either. So we figured we define the UDP port and procedures as a core portion in the base document, and treat IP-less as a special case.

> Anyway, "yeah I think it's reasonable" still holds.  :-)

Thanks :)

We'll proceed down the current path unless there are objections.

> 
> 
> > Regarding SBFDReflector reflecting the state, I do see your point. If
> > the state of received S-BFD packet is reflected by the SBFDReflector,
> > then the SBFDInitiator requires no FSM changes (i.e. able to re-use
> > FSM from RFC5880). Although that will result in time(2 * (RTT + Tr))
> > for the SBFDInitiator to reach UP state. In reality, it actually would
> > be time((2 * (RTT _ Tr)) + tx_gap) where "tx_gap" is the interval
> > between the 2 packets transmitted. I do think one of the strength of
> > S-BFD is the fact it only takes one packet to complete the
> > connectivity test. Thus I'm leaning towards standing the ground of
> > SBFDReflector only being able to send [UP, ADMINDOWN] states, and not
> reflecting received state.
> 
> No, you may not see my new point yet :-) While discussing with you I
> realized the Reflector should not impose any state machine model. Dumb
> reflection of the state provides full control to the Initiator side which can
> implement any state machine it likes.

I think it'll be more like:

If (bfd.SessionType == SBFDInitiator) {
    Set local state in outgoing BFD packet;
    /* where local state is either UP or ADMINDOWN */
}

Where what you are suggesting will likely require:

If (bfd.SessionType == SBFDInitiator) {
    If (local state == ADMINDOWN) {
        Set state in outgoing BFD packet to "ADMINDOWN";
    } else {
        Copy received state to the state in outgoing BFD packet;
    }
}

> different state machine than vendor Y. The interop is guaranteed by the
> same definition of what the reflector does.

Assuming you are talking about SBFDInitiator, then yes I agree: vendor can chose any state machine. And as you said, we just have to converge and standardize how SBFDReflector behaves.

> not arguing against this improvement.

Frankly, I see both ways (what's currently in the document as well as what you suggested) to work reasonable well. We may need others to chime to decide which way to move forward. Anyone??

> manual-config implementations for day-1. Well, I hope so :-)

Good stew requires good stirring :)

Thanks!

-Nobo

> > ACK on moving the example state machine to appendix (some texts will
> still
> > be kept around in the current section).
> >
> Santosh