![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|
Dave, My email was bounced back by rtg-bfd alias
due to the size being too large. So I will send the PDF file marked with my
comments directly to you. Here are my questions and hope you can
help. Thanks, Linda From: Linda
Dunbar [mailto:ldunbar at huawei.com] Hi Dave, 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. -
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. 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. -
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? -
Section 6.8.5: Is the “Detecting Failures with
Echo Function” referring to the system who initiates “Echo”?
The system which loops back Echo
shouldn’t have any failure related to Echo, should it? -
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. -
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? o Why “Admin Down” is not
on the state machine? 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. -
Section 6.8.16: Why set SessionState to Down when
Enabling a session? Should it be “INIT”? -
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? -
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. In addition, all forwarding engines
are unidirectional. Who impose the bi-directional property on forwarding
engines? Do you mean BFD is to detect
failures between two forwarding engines which face (or peer with) each other
for some applications? -
Section 4.1, under “Diagnostic (Diag)”: 3
-- Neighbor Signaled Session Down Should “remote node (or
system)” be more accurate description than the “Neighbor”? -
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? -
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. I have some editorial comments
marked on the enclosed PDF file. Please have a look. Best Regards, Linda Dunbar Advanced
Technology Dept, Wireline Networks, Huawei Technologies, Inc. |