Subject: The usage of "Concatenation" in BFD spec.

From: Linda Dunbar <[email-masked]>
Date: Fri, 02 Oct 2009 14:35:09 -0500

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:[email-masked]] 
Sent: Monday, September 28, 2009 2:26 PM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: How to enforce BFD to be sent over different paths between two
systems?

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 "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.

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.

---

From: Dave Katz <[email-masked]>
Date: Fri, 2 Oct 2009 14:07:42 -0600

Our good friends at Bellcore used an unfortunate choice of  
terminology, alas.  It is technically true, if you squint, in that the  
frames that would have been interleaved in a channelized pipe are  
serialized (one after the other) in the OCxC pipe, and so are  
concatenated in that sense, but this creates an obviously misleading  
impression.

I can add a parenthetical insertion that disambiguates it, but given  
that the spec is in the final throes of last call, ready for RFC and  
the standards track, I'm loathe to start changing terminology at this  
late date.

--Dave

On Oct 2, 2009, at 1:35 PM, Linda Dunbar wrote:

> 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.
>

---

From: Dave Katz <[email-masked]>
Date: Fri, 2 Oct 2009 14:08:17 -0600

As has been pointed out to me privately, the terminology has been  
completely messed up by the definition of "virtual concatenation",  
which is a parallel bundle of pipes over which a "concatenated" pipe  
is reverse-muxed.  This effectively destroys the usefulness of the  
term.  Perhaps we can get the folks at Lake Superior State to add it  
to this year's list of banned words.  ;-)

--Dave

On Oct 2, 2009, at 1:43 PM, David Ward wrote:

> Linda -
>
> So far, you are the first to ask :-)
>
> Nonetheless, the functionality is about to be deprecated for PWE as  
> that WG is going to use status signaling and not BFD. The PWE WG was  
> the origination of "concatenated path" (where the request for the  
> diag came from) so, unfort we couldn't change without a lengthy  
> interaction/exchange with that WG.

---

From: Dave Katz <[email-masked]>
Date: Fri, 2 Oct 2009 15:16:19 -0600

I've already done so...

--Dave

On Oct 2, 2009, at 2:57 PM, Linda Dunbar wrote:

> It would be very helpful to add a parenthetical insertion that  
> disambiguates it
>
> Linda