On Sep 23, 2009, at 10:34 AM, Linda Dunbar wrote: Dave, I have some questions on “draft-ietf-bfd-base-09.txt”. Hope you can help. - Section 3: 3rd line of the first paragraph states “A pair of systems transmit BFD packets periodically over each path between the two systems”.
Question: when there are multiple paths between two systems, do you mean to have multiple BFD sessions between those two systems, with each session covering individual path? How to enforce each path being traversed?
The idea is that a BFD session protects a path, and if multiple paths are present, the operator/implementor can protect any or all of them. "Enforcement" is outside the scope, but is most often a matter of configuration (configuring BFD to run on an interface or an LSP or whatever it may be.)
- The Echo function is pretty much like “Ping”. Each system can initiate a “Ping” to another system. Is “periodic Ping” an accurate description of the “Echo function”?
More or less, with two additions. First, the echo protocol itself is unspecified, so implementors can put whatever they want in the packets, and this could presumably have some additional added value. Second, the failure of the echo protocol is reflected in the control protocol, so there is a standardized (more or less) mechanism to signal that failure to the far end and to react to the failure. - Section 4.1 under the “Control Plane Independent” sub-section:
The first paragraph states “if clear, the transmitting system’s BFD implementation share fate with its control plane”. Question: When the transmitting system is running multiple routing protocols, more than one signaling schemes for different services, is it necessary to indicate which routing protocol and which signaling protocol? Actually, BFD is to test connectivity which can be up when the corresponding control plane is done. What is the reason to have BFD share fate with its transmitting system’s control plane?
The most common reason to share fate with the control plane is to implement BFD in the control plane, which is where many implementations start. BFD doesn't know or care about whether zero or more routing protocols are running; the protocol is protecting the data path over which the routing protocol runs. How BFD interacts with some or all of those protocols is outside the spec (though strongly hinted at in the Generic spec.) We have taken pains to keep BFD very loosely coupled with the rest of the system; BFD tests the path, and if it detects a failure, other parts of the system (typically routing protocols) are advised of this.
If multiple routing protocols are running over IPv4, there will be a single BFD session running over the IPv4 path between systems, and a failure of that BFD session would typically be signaled to each protocol.
- The BFD’s Control Packet Format described in Section 4.1 has a bit field for Demand mode. Why not having a bit field for the other two modes (Async and Echo)?
Because it is not necessary to signal them in this way; the bits would be redundant and/or useless. -
- Is the Discriminator field of the BFD’ Control Packet Format same as unique identifier for particular BFD session from one system? Why not call it Identifier? Is it negotiated between the two systems?
That's what we called it. It discriminates between multiple sessions between the same pair of systems.
- Section 6.18.17 Concatenated Paths
In transport network, Concatenated paths mean to combine (or bundle) multiple paths to form a bigger path which has higher bandwidth. Therefore, failure on one of the paths concatenated together will not cause connectivity problem for the two systems exchanging BFD. This failure will only cause the bandwidth of the concatenated path to be smaller. Do you mean that when one of the paths within a concatenated path fail, the BFD should indicate this partial failure of the concatenated path?
In my dictionary, "concatenation" is the process of hooking things together "in a chain or series." Bundling is not concatenation, at least in the general definition of the word, since it is parallel.
The point of this section is to point out that an end-to-end path may be stitched together out of segments of various technologies, and BFD may run over only part of this end-to-end path. If a failure is detected by other means on an adjacent segment (say, OAM), this can be signaled through BFD to the system connecting to the next segment, with the idea that the failure can be signaled all the way to the end, even though the bit over which BFD is running may not have failed itself.
This is an interworking hack.
- Editorial: Section 2 Design: 6th line of the first paragraph: “making it useful in concert with”? Is it a typo?
No, just my somewhat arcane choice of wording. "In concert with" means "along with" or "in combination with".
Thank you very much for helping me. Best Regards, Linda Dunbar Advanced Technology Dept, Wireline Networks, Huawei Technologies, Inc.
|
