 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Dave, Thank you very much for the detailed
description. It really helped me to understand the specification much better. As for “Concatenated Path”,
you are right that the Oxford Dictionary defines “concatenation” as
“series of linked things or events”. The only problem is that huge
deployed bases of Optical interfaces (OC192, OC48, etc) conform to GR253’s
definition of concatenation which is to form a fatter pipe (like STS-3c,
STS-48c, STS192c). Those optical interfaces (OC192, OC48, OC12) are present on
all deployed routers/switches and transport equipment. PW uses “stitch” to refer
combining multiple segments. Can BFD use “stitch” too? If you
still think that “Concatenated Path” is a better way, then you
should add a “Definition Section” in the document to explain it
clearly. I am sure that I am not the only one being confused by this. Linda From: Dave Katz
[mailto:dkatz at juniper.net] 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. 1. 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.)
2. The Echo
function is pretty much like “ 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.
3. 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.
4. 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.
4. 5. 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.
5. 6. 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.
7. 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".
7. Thank
you very much for helping me. Best
Regards, Linda Dunbar Advanced
Technology Dept, Wireline Networks, Huawei
Technologies, Inc. |