Subject: Re: New version notification for draft-akiya-bfd-seamless-base-03.txt

From: Marc Binderberger <[email-masked]>
Date: Mon, 5 May 2014 19:24:04 -0700

Hello Mallik and authors,

reading the new draft version, here some first feedback:

(1) You are fairly detailed in sections 9.2.2 and 9.3 what to copy over from 
the received into the responder packet but it does not mention what the 
reflector is doing with the P/F flags. I assume it needs to copy them into 
the reflected packet?

Sure, you say in 9.5 "The Poll sequence MUST operate in accordance with 
[RFC5880]." but details are missing.

(2) What I'm still wondering: why do you want to change the RFC5880 state 
machine?  I would assume that if you want to re-use code/hw on the Initiator 
side then that's the last thing to change. And you don't need to:

 * Initiator sends out the usual Down/Init/Up as per RFC5880
 * Reflector simply copies the state into the reply packet
   (or overwrites the state field with AdminDown)

Play it through - it works ;-)  More important there is a subtle difference 
of simply going to "Up" state when receiving "Up" packets and filling the 
packet path with Down, then Init, then Up.

(3) Nitpick: section 9.1.1 says "The notation on each arc represents the 
state of the remote system" - there is no state of the remote system, the 
reflector is stateless ;-)

(4) Section 11 "Scaling Aspects". The "total number of BFD sessions in a 
network" - why would this be a relevant number? This is not RSVP-based TE 
tunnels where some core nodes may indeed come close to the N * (N - 1) number 
of RSVP tunnel state for an any-any mesh. But a BFD session is just a bit of 
traffic in the forwarding plane for most routers, only sender/receiver take a 
hit.
True, there is still the factor of about "2" per single router. I would 
propose keeping the first paragraph of 11 but remove the rest.

Have to re-read your draft for the other parts, especially the D-bit ;-)

Regards, Marc

On Thu, 17 Apr 2014 12:50:12 +0000, MALLIK MUDIGONDA (mmudigon) wrote:
> Hello BFD WG Members,
> 
> We have published a new version of Seamless BFD draft, 
> draft-akiya-bfd-seamless-base-03. Several sections have been updated for 
> improving readability. It also has a few technical changes as well. Please 
> review the draft and get back to us with your comments.
> 
> Thanks
> 
> Regards
> Mallik

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 7 May 2014 16:59:35 +0000

Hi Marc,

Please see inline.

> -----Original Message-----
> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Marc
> Binderberger
> Sent: Monday, May 05, 2014 10:24 PM
> To: MALLIK MUDIGONDA (mmudigon)
> Cc: [email-masked]
> Subject: Re: New version notification for draft-akiya-bfd-seamless-base-
> 03.txt
> 

Thanks for the first feedback!
Look forward to seeing more :)

> reflector is doing with the P/F flags. I assume it needs to copy them into the
> reflected packet?

P bit should be followed with F bit from the other side, in both directions. So P/F bits aren't copied from received packet to transmitted packet at the reflector session.

> [RFC5880]." but details are missing.

Agree, entire section 9 can benefit from a bit of restructuring.

> packet path with Down, then Init, then Up.

If we strictly look at this from the protocol perspective, there is no need for the initiator to have INIT state (it doesn't even make sense to have one). ADMINDOWN might still be useful to have, to allow the initiator session to be enabled/disabled. Thu I think it's correct for the new FSM to be available for this. We may need to add ADMINDOWN back in though ... thoughts?

Now, if we apply the new FSM to existing implementation, I suppose RFC5880 FSM can be re-used, as long as the implementation properly transitions *through* INIT state. But I see this as an implementation detail, and should be left out from the document.

> reflector is stateless ;-)

Good catch. Agree that sentence should be rewritten to remove "state of the remote system" out.

> propose keeping the first paragraph of 11 but remove the rest.

You are right, everything below the first paragraph is just a bit noisy. Yes I agree that we should only keep the first paragraph of section 11 (i.e. remove the rest).

-Nobo

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 7 May 2014 18:26:23 -0700

Hello Nobo,

thanks for the reply!

> P bit should be followed with F bit from the other side, in both 
> directions. So P/F bits aren't copied from received packet to transmitted 
> packet at the reflector session.

ah okay, the reflector sees "P" and sets "F" when sending the reflected 
packet? Good idea.

> If we strictly look at this from the protocol perspective, there is no need 
> for the initiator to have INIT state

agree, a minimal FSM can do without.

> (it doesn't even make sense to have one).

disagree, it can serve a purpose. Effectively the same it does for async BFD, 
that you are not jumping immediately into Up state again on receiving an "Up" 
packet. You first need to confirm the Down, which for S-BFD means you see 
your own Down first before. You are "flushing out" all Up packets in the path.

Otherwise you may see flaps, depending on the interruption. Which of course 
you can cure with holddown timers in your implementation - but why not using 
this nice (?) behaviour of the existing FSM?

> We may need to add ADMINDOWN back in though ... 
> thoughts?

maybe not necessary but useful, yes.

> Now, if we apply the new FSM to existing implementation, I suppose RFC5880 
> FSM can be re-used, as long as the implementation properly transitions 
> *through* INIT state. But I see this as an implementation detail, and 
> should be left out from the document.

my point is that a new FSM means "work" on the Initiator side. If this is 
complete new code or just a modification - speculation, it depends on the 
code/hw. Preferably (for me) there would be no change on the Initiator side 
and all changes on the Reflector side, which needs to be implemented "from 
scratch" anyway. Well, see below.

From a formal point of view ... I don't mind a new FSM but we should then 
stop referring to RFC5880. Actually the D-flag is the same story, the new 
state variable does not make it compatible to RFC5880 (*) IMHO.

Depends on what you want: you can write a "new" BFD for the Initiator with 
some references to or copies from RFC5880, e.g. C-Bit and Poll sequence I 
guess can be borrowed 1:1. There is nothing wrong with it, it may be actually 
more honest and avoids rules that only serve the compatibility, not the 
functionality. You can define a new FSM, you can use the place of the D-bit 
for your R-eflector bit etc..

The other extreme would be to re-use the existing packet engine (I/O, FSM, 
5880 rules). Running existing BFD 5880/5881 against a simple reflector does 
work (tested, yes :-) , so I guess this would work for your more elaborate 
reflector as well. And if it doesn't work, then see above, go with a clean 
new definition. 
I say "packet engine" because that part matters for IETF, for the interop. 
The code e.g. selecting a discriminator will likely change as you have new 
requirements for S-BFD. But that code is largely "implementation specific" 
and outside the scope of most documents.

Regards, Marc

(*): it is a nice structure for the implementor though. Wrap "if (!sbf) { ... 
}" around existing Demand code and add "if (sbfd) { ... }" for the S-BFD 
D-flag code. But that was not why several people including me had a bad 
feeling.

On Wed, 7 May 2014 16:59:35 +0000, Nobo Akiya (nobo) wrote:
>> the
> P bit should be followed with F bit from the other side, in both 
> directions. So P/F bits aren't copied from received packet to transmitted 
> packet at the reflector session.
> 
>> 
> If we strictly look at this from the protocol perspective, there is no need 
> for the initiator to have INIT state (it doesn't even make sense to have 
> one). ADMINDOWN might still be useful to have, to allow the initiator 
> session to be enabled/disabled. Thu I think it's correct for the new FSM to 
> be available for this. We may need to add ADMINDOWN back in though ... 
> thoughts?
> 
> Now, if we apply the new FSM to existing implementation, I suppose RFC5880 
> FSM can be re-used, as long as the implementation properly transitions 
> *through* INIT state. But I see this as an implementation detail, and 
> should be left out from the document.
> 
>> 
>> 
> You are right, everything below the first paragraph is just a bit noisy. 
> Yes I agree that we should only keep the first paragraph of section 11 
> (i.e. remove the rest).
> 
> -Nobo
> 
>> 
>>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 9 May 2014 23:59:03 +0000

Hi Marc,

Thanks for the reply as well!
Please see in-line.

> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Wednesday, May 07, 2014 9:26 PM
> To: Nobo Akiya (nobo)
> Cc: MALLIK MUDIGONDA (mmudigon); [email-masked]
> Subject: RE: New version notification for draft-akiya-bfd-seamless-base-
> 03.txt
> 
> Hello Nobo,
> 
> thanks for the reply!
> 
> 
> > directions. So P/F bits aren't copied from received packet to
> > transmitted packet at the reflector session.
> 

I can imagine a persistent initiator session, which initiator state will be useful (whether INIT is included or not).
I can also imagine a module that throws out an S-BFD packet once (when needed) and then goes on to do something else, which initiator state is really useless (getting a response back in timely manner is all it cares about).
I can also imagine variants on how I want the initiator to behave.

Perhaps the draft should focus less on the initiator side entirely and focus mostly on standardizing the reflector session behavior.

> state variable does not make it compatible to RFC5880 (*) IMHO.

Not necessary. bfd-multipoint extends RFC5880 by introducing new state variables and new procedures.

> and outside the scope of most documents.

As I read this email, I'm getting more convinced that S-BFD reflector is what needs to be standardized. How initiator behaves really doesn't matter, as long as it sends packets to reflectors according to what we define as the standard of reflector behavior.

> D-flag code. But that was not why several people including me had a bad

Perhaps a portion of existing BFD code can be reused when initiator is used as a persistent session, and I'm sure that will happen. But S-BFD also requires no bootstrapping, no need for sedated bring-up sequence, no need to "bring down the session gracefully/ungracefully" - just stop when you want to, etc. And obviously initiator doesn't necessary have to be a persistent session like today.

-Nobo

> > Good catch. Agree that sentence should be rewritten to remove "state of
> the
> > remote system" out.
> >
> >>
> >>