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

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

Hi Linda,

>
> 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.
>
> [Linda] Do you mean the format of the ECHO reply message is out of the
> scope? But you have to specify how remote system sends the received Echo
> back to the sender, right? Otherwise how does the sender know a received
> packet is really a reply message of an Echo message earlier?

The packet format for the echo packet is itself not specified. The
idea is that the echo packet itself is looped back by the forwarder
(there is only forwarding processing the receiver will not know it
received a BFD echo packet).

Thanks,
Vishwas



> Linda
>
> -----Original Message-----
> From: Vishwas Manral [mailto:vishwas.ietf at gmail.com]
> Sent: Wednesday, October 07, 2009 12:23 PM
> To: Linda Dunbar
> Cc: Dave Katz; rtg-bfd at ietf.org
> Subject: Re: More questions on "draft-ietf-bfd-base-09.txt"
>
> 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