Re: More questions on "draft-ietf-bfd-base-09.txt"

[Vishwas Manral <vishwas.ietf at gmail.com>]

Hi Linda,

Good to see you have spent quite an effort preparing and doing such an
indepth review.

> Thank you very much for answering my questions last week. Now I do see
> unique values of BFD, comparing to IEEE802.1ag. I was very actively involved
> in IEEE802.1ag’s development for a few years. BFD is simpler than
> IEEE802.1ag and has some useful features, such as its Demand mode, which
> IEEE802.1ag doesn’t have. I think Demand Mode is very useful in reducing the
> processing power imposed on systems. Here are some more questions. Hope you
> can help me again.

Great to know you were so instrumental in 802.1ag. Yes BFD is a good
CC protocol. The base protocol however does not provide all the other
functionality like Locking etc. There are additional drafts under
consideration for each of the other functionalities extending BFD.

> -          Section 3 Protocol Overview, 2nd paragraph: “A path is only
> declared to be operational when two way communication has been established
> …”
> My comment:  Under the context of MPLS, “a path”, i.e. LSP, is always
> uni-directional. So it is not correct to declare a path being operational
> when two way communication is established.
For the BFD case if we only have unidirectional LSP's there has to be
an off path mechanism to transfer packets in the other direction,
otherwise BFD will not be able to operate over such a scenario.

> My suggestion: Should have an entity which binds two uni-directional paths
> in the BFD context, or paired paths. Then you can easily say a path in the
> pair (or in the entity) is declared operational when two way communication
> is established. Even though the specification doesn’t have to specify how
> two paths are associated, it is worthwhile to have an entity to bind two
> uni-directional paths together in the BFD document. The “My (Your)
> Discriminator” in the BFD control packet should have “Entity identifier”
> embedded in.
To see how BFD works with MPLS LSP or over Pseudowire you can look at
http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-07
http://tools.ietf.org/html/draft-ietf-bfd-mpls-07

> -          I don’t see ECHO reply packet from remote system defined anywhere
> in the document. I would think that it is necessary to have an ECHO reply
> message which includes the original ECHO packet plus some information from
> the remote system. Why?
The format of the echo packet is outside the scope of the spec. This
is because the echo packet is only processed and received only by the
sender. It is forwarded from the peers forwarding plane.

> -          Section 6.8.5: Is the “Detecting Failures with Echo Function”
> referring to the system who initiates “Echo”?
That is correct.


> The system which loops back Echo shouldn’t have any failure related to Echo,
> should it?
It would not know.

> -          The BFD Control Packet has “Required Min RX Interval” and
> “Required Min Echo RX Interval”. When “Required Min RX Interval” is set to
> zero, can remote system still send Echo frame? If yes, then the description
> for Required Min RX Interval should be more accurate.
Yes. For echo's the "Required Min Echo RX Interval" is used instead.

> -          Questions on State Machine of BFD:
>
> o       The second last paragraph of Section 6.2 indicates “Once a session
> has been declared down, it cannot come back until remote end first signals
> that it is down”. What if the local system goes down by provisioning, and
> decides to turn up. Why have to wait for the remote end to go down first?
The question is not clear.

> o       Why “Admin Down” is not on the state machine?
It could have been added to the diagram. though there is only one
transition out of it is the ADMIN UP state and to the down state.

> o       When local system is Down state, why the BFD packet from remote
> system with DOWN status transition the state machine from “DOWN” to “INIT”
> state? I thought it should be INIT state from remote node to trigger the
> local node to go to INIT state.
INIT is there for the 3 way handshake. The idea of INIT is, I have
heard from you, but dont know if you have heard from me yet.

>
> -          Section 6.8.16: Why set SessionState to Down when Enabling a
> session? Should it be “INIT”?
Refer above.

> -          In the Introduction and overview sections, the word “adjacent
> systems/forwarding engines” is used frequently. For example, the first
> sentence of the Introduction stated: the rapid detection of communication
> failures between adjacent systems.
>
> However, the sections in the latter part of the specification use “two
> systems”, or “pair of systems”.
>
>
>
> My question: are they referring to the same thing? Does the “adjacent” in
> the overview sections mean neighboring node as in OSPF’s neighbors or two
> systems on two ends of the path for BFD session?

It could be made consistent.

> -          Section 2 Design, the first paragraph:
>
> What does it mean by saying "failure in communication with a forwarding
> plane next hop"? Why next hop? The rest of the specification uses “two
> systems”, “remote system”, etc, which I think is more accurate.
This could be clarified.

>
> In addition, all forwarding engines are unidirectional.  Who impose the
> bi-directional property on forwarding engines?
Can you clarify the question?

>
> Do you mean BFD is to detect failures between two forwarding engines which
> face (or peer with) each other for some applications?
Same as above?


>
> -          End of the first paragraph of Section 2, it stated that BFD
> implemented in Control Plane may preclude the detection of some kinds of
> failure. What kind of failures will be precluded?
This can be clarified for sure.

>
> -          Section 3.1, last sentence of the first paragraph: you stated
> that BFD can run between two OSPF neighbors. Why you need to run BFD between
> two OSPF neighbors? If the two immediate neighbors need to discover
> connectivity to each other faster, HELLO timer can be set shorter.
This is something that goes back to the introduction. The idea is:

1. Lesser load.
2. Single faster detection mechanism for multiple protocols.

> I have some editorial comments marked on the enclosed PDF file. Please have
> a look.
>
> Best Regards, Linda Dunbar
Thanks a lot for the really thorough review.
Vishwas