RE: More questions on "draft-ietf-bfd-base-09.txt"
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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]
Sent: Tuesday, October 06, 2009 6:06 PM
To: 'Dave Katz'; 'rtg-bfd at ietf.org'
Subject: More questions on "draft-ietf-bfd-base-09.txt"

 

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.

 


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.