Subject: S-BFD open items, seeking comments

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 24 Jul 2014 13:30:56 +0000

Hi BFDers,

In order for us to progress S-BFD Base and IP documents, we need your input on following 2 points.

Details can be found in pages 3 and 5 of:
http://www.ietf.org/proceedings/90/slides/slides-90-bfd-2.pptx

== Document Structure:

1) S-BFD-Base document to describe UDP and BFD headers.
    a) S-BFD-IP document to describe IP and MPLS data plane headers.
    b) S-BFD-SR document to describe SPRING and data planes it uses.
    c) If S-BFD-IP-Less document is needed, it will describe ACh and clarify that UDP is not applicable.

2) S-BFD Base document to describe BFD header.
    a) S-BFD-IP document to describe UDP, IP and MPLS data plane headers.
    b) S-BFD-SR document to describe UDP, SPRING and data planes it uses.
    c) If S-BFD-IP-Less document is needed, it will describe ACh.

Frankly neither are perfectly clean. Approach (1) creates a special case (IP-less) whilst approach (2) requires UDP to be repeated in IP and SR documents. Authors are ok to go with either approach from above, given WG consensus.

== SBFDReflector state field setting in sending S-BFD packets.

1) SBFDReflector to set its local state [UP or ADMINDOWN].

2) SBFDReflector to set [ADMINDOWN or reflect received state].

For pros/cons, please view the slide. S-BFD-Base document is currently structured with (1). Speaking with couple of folks offline, it sounds like (1) is preferred which aligns with thoughts from most authors. We will plan to go with (1) unless there are strong objections.

== Additionally ...

Welcoming comments and discussions on pages 6 and 7. Note, these are not gating the progress of S-BFD-Base/IP drafts at the moment but good topics to discuss.

Thanks!

-Nobo

---

From: Pablo Frank <[email-masked]>
Date: Fri, 25 Jul 2014 10:05:13 -0400

Hi Nobo, et al,

Regarding the document structure:

I think I prefer the option where the base S-BFD draft does not specify UDP
headers.  UDP is not intrinsic to BFD although it is commonly used in
several encapsulations.  We already have examples where the UDP port usage
had to be modified anyway (e.g. BFD-LAG, and of course S-BFD).  Wrt/
concerns over having to repeatedly specify the UDP behaviour across
multiple documents, I think we can mostly avoid that by primarily
specifying the UDP header usage in the S-BFD-IP document.  S-BFD-SR (or any
other documents that need it) can simply reference the S-BFD-IP document
for UDP header usage, and the S-BFD-BASE for BFD header usage.

Regarding the state field in the S-BFD packets:

I think I strongly prefer option 1.  By giving the reflector an independent
state, it leaves open the possibility of extending the state machine in the
future (I do have an ulterior motive here that I'd like to discuss soon).
 Option 2 is very rigid and leaves little room for extension.  I also think
it's misleading to suggest that option 2 allows the initiator to re-use the
RFC 5880 state machine.  Because of the differences in procedure introduced
by S-BFD, the state-machine is only superficially similar.  It may have the
same set of states but the details of the transitions are quite different.
 Therefore, I see little value in option 2.

My 2 cents,

regards,
Pablo

On Thu, Jul 24, 2014 at 9:30 AM, Nobo Akiya (nobo) <[email-masked]> wrote:

> Frankly neither are perfectly clean. Approach (1) creates a special case
> (IP-less) whilst approach (2) requires UDP to be repeated in IP and SR
> documents. Authors are ok to go with either approach from above, given WG
> consensus.
>
>
> For pros/cons, please view the slide. S-BFD-Base document is currently
> structured with (1). Speaking with couple of folks offline, it sounds like
> (1) is preferred which aligns with thoughts from most authors. We will plan
> to go with (1) unless there are strong objections.
>
>
> == Additionally ...
>
> Welcoming comments and discussions on pages 6 and 7. Note, these are not
> gating the progress of S-BFD-Base/IP drafts at the moment but good topics
> to discuss.
>
>
> Thanks!
>
> -Nobo
>
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 27 Jul 2014 18:21:52 +0000

Hi Pablo,

Truly appreciate your comments.

Please see-inline.

> -----Original Message-----
> From: Pablo Frank [mailto:[email-masked]]
> Sent: Friday, July 25, 2014 10:05 AM
> To: Nobo Akiya (nobo)
> Cc: [email-masked]
> Subject: Re: S-BFD open items, seeking comments
> 
> Hi Nobo, et al,
> 
> headers.  UDP is not intrinsic to BFD although it is commonly used in several
> encapsulations.  We already have examples where the UDP port usage had
> to be modified anyway (e.g. BFD-LAG, and of course S-BFD).  Wrt/ concerns
> over having to repeatedly specify the UDP behaviour across multiple
> documents, I think we can mostly avoid that by primarily specifying the UDP
> header usage in the S-BFD-IP document.  S-BFD-SR (or any other documents
> that need it) can simply reference the S-BFD-IP document for UDP header
> usage, and the S-BFD-BASE for BFD header usage.

>     c) If S-BFD-IP-Less document is needed, it will describe ACh.

I will take a crack at restructuring the S-BFD documents soon.

> future (I do have an ulterior motive here that I'd like to discuss
> soon).  Option 2 is very rigid and leaves little room for extension.  I also
> think it's misleading to suggest that option 2 allows the initiator to re-use
> the RFC 5880 state machine.  Because of the differences in procedure
> introduced by S-BFD, the state-machine is only superficially similar.  It may
> have the same set of states but the details of the transitions are quite
> different.  Therefore, I see little value in option 2.

Good points. Looks like consensus is pointing to option 1, the way it is currently described in the S-BFD-Base document. I will plan to proceed as is.

And looking forward to hearing your ulterior motive soon :)

> My 2 cents,

Your comments were/are worth way more than 2 cents, thanks!

-Nobo

> Frankly neither are perfectly clean. Approach (1) creates a special case (IP-
> less) whilst approach (2) requires UDP to be repeated in IP and SR
> documents. Authors are ok to go with either approach from above, given
> WG consensus.
> 
> 
> structured with (1). Speaking with couple of folks offline, it sounds like (1) is
> preferred which aligns with thoughts from most authors. We will plan to go
> with (1) unless there are strong objections.
> 
> 
> == Additionally ...
>

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 28 Jul 2014 23:03:49 -0700

Hello Nobo and Pablo,

>> several
>> 	[...]
> You are the third person who voiced the preference for this document 
> structure on the list, as opposed to zero(0) preferring the current 
> document structure. Number of votes are small, but it's probably reasonable 
> to conclude that we should go with:
> 

You won't be surprised I prefer (2) as well if I have the choice ;-)

>> future (I do have an ulterior motive here that I'd like to discuss

?!? ... how can option 1 be extended? Well, of course you can always modify a 
definition but S-BFD base defines the state of the reflector as Up unless 
it's AdminDown for administrative reasons. How is this an independent state?

Not to mention: an independent state on the reflector - wasn't the reflector 
supposed to be "stateless" ? (i.e. not having many state variables to 
remember)

>> Option 2 is very rigid and leaves little room for extension.

I'm almost wondering if we talk about different things? Option 2 means the 
reflector just reflects the incoming state field. Unless it's set to 
AdminDown for administrative reasons. In which sense is this rigid?

From what you write I would guess you want to have a state on the reflector 
per session or group of sessions, in any case a larger number of states?

>> different.

Can you elaborate on this? Not that I promote the re-use of RFC5880 state 
machine but you can actually run it against a state reflector and it works 
(talking about todays RFC5880 BFD, of course). In which sense are the details 
of the transition quite different for S-BFD?

Nobo, there was the other discussion about the discriminator pool. What is 
the status?  Do we introduce a new UDP port for reflector->Initiator 
sessions?  Or do you propose setting the source port to the S-BFD port?  Or 
something else?

Thanks & Regards,
Marc

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 29 Jul 2014 12:39:19 +0000

Hi Marc,

> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Tuesday, July 29, 2014 2:04 AM
> To: Nobo Akiya (nobo); Pablo Frank
> Cc: [email-masked]
> Subject: RE: S-BFD open items, seeking comments
> 
> Hello Nobo and Pablo,
> 
> >> I think I prefer the option where the base S-BFD draft does not
> >> specify UDP headers.  UDP is not intrinsic to BFD although it is
> >> commonly used in several
> >> 	[...]
> >
> > document structure. Number of votes are small, but it's probably
> > reasonable to conclude that we should go with:
> >

Yup, this is indeed the consensus.
I have spent some time last night re-structuring the documents, as well as incorporating comments from you and Greg.
We should be able to roll out new revisions of -base and -ip documents soon.

> >> I think I strongly prefer option 1.  By giving the reflector an
> >> independent state, it leaves open the possibility of extending the
> >> state machine in the future (I do have an ulterior motive here that
> >> I'd like to discuss
> 
> ?!? ... how can option 1 be extended? Well, of course you can always modify
> a definition but S-BFD base defines the state of the reflector as Up unless
> reflector just reflects the incoming state field. Unless it's set to AdminDown
> for administrative reasons. In which sense is this rigid?
> 
> 

I'll leave above between you and Pablo, but the rough consensus (at least in my eyes as an individual contributor) is pointing to option 1. This is based on few folks chimed in on the list in last few weeks as well as speaking to few folks in Toronto last week. At the end, things will work either way but we need to choose one to allow implementations to move forward (I know of one implementation that is being worked on). As the lead contributor of this document, I'm making the call to proceed with option 1. Sorry Marc, but I appreciate that you have raised this point and made it aware by everyone!

> sessions?  Or do you propose setting the source port to the S-BFD port?  Or

We've closed on this one already, and some clarification texts will be added in the -base as result. Hopefully we can roll out the revision this weekend. Once it's out, can you take a look and see if you have any further concerns?

Thanks!

-Nobo

---

From: Pablo Frank <[email-masked]>
Date: Thu, 31 Jul 2014 12:12:19 -0400

Hi Marc,

See PF>> below...

On Tue, Jul 29, 2014 at 2:03 AM, Marc Binderberger <[email-masked]> wrote:

> independent

Well, it's not completely stateless.  It's either "up" or "admin-down" in
option 1.  I suppose you could argue that it's either "admin-down" or
"reflecting" in option 2.  I guess what I don't like about option 2 is that
if the device is in "reflecting" state, then the state that it emits is not
its own state.  That's what I meant with the word "independent".  Consider
the case where the initiator is running the 5880 state machine and enters
admin-down.  Per the spec, it will send some number of admin-down packets
that will get happily reflected by the option 2 reflector.  The state from
the reflector is now ambiguous.  Is it admin-down because the reflector is
admin-down or is it admin-down because the initiator is admin-down?  That
seems a bit fishy.

By the way, my reading of the current (option 1) draft is that the
reflector would respond to an admin-down packet with an UP state.  I'm not
sure if that was authors' intent...?  Could use some clarifying text.

> per session or group of sessions, in any case a larger number of states?

PF>>  I've got a half-baked idea about reflector sessions that are
associated with point-to-point links (e.g. a bi-directional LSP) could
transition into an initiator themselves.  The idea is that an S-BFD session
(under specific circumstances) could basically morph into a regular BFD
session (the main use-case is fast bring-up of protected LSPs).  I'm still
sketching the idea out on paper though.  I haven't convinced myself it
works yet... :-)

> >> introduced by S-BFD, the state-machine is only superficially similar.
>  It
> >> may

PF>> Mostly the timer usage I think.  An RFC 5880 BFD session would start
with a slow exchange of packets running at 1 packet per second.  S-BFD is
explicitly trying to eliminate this slow / sedate bring-up of the session.

regards,
Pablo