Subject: How to enforce BFD to be sent over different paths between two systems?

From: Linda Dunbar <[email-masked]>
Date: Wed, 23 Sep 2009 11:34:58 -0500

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? 

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

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? 

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)? 

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? 

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? 

7.	Editorial: Section 2 Design: 6th line of the first paragraph:
"making it useful in concert with"? Is it a typo? 

Thank you very much for helping me. 

Best Regards, Linda Dunbar

Advanced Technology Dept, Wireline Networks,

Huawei Technologies, Inc.

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 23 Sep 2009 09:52:37 -0700

Hi Linda,

I am sure Dave will answer these questions better that I do, but let me give you my 2c inline.

Regards,
Shahram

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, September 23, 2009 9:35 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: How to enforce BFD to be sent over different paths between two systems?

Dave,

 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?

SD> For example there can be multiple LSPs between two systems and you need to run BFD separately on each LSP.

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

 SD> Your understanding is correct. But note that Echo packets are not BFD packets. BFD just negotiates the Echo interval.

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

SD> Every LSP or PW or tunnel that runs BFD could be setup using an instance of control plane.  We don't care about the control plane of the client or server layers. What this bit indicates is the control-plane for the layer you are running the BFD on.

 1.  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)?

    SD> If D=0 it means Async mode. For Echo, if a system does not want to receive Echo it can set  "Required Min Echo RX Interval " = 0 . And there is not need to signal that you want to Tx Echo.

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

   SD> the Discr is a locally unique number (not globally) very similar to an LSP MPLS label that is distributed from a downstream node. It it not negotiated.

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

SD> As far as I know concatenated paths in transport networks mean stitching two connections such as two LSPs.

 1.  Editorial: Section 2 Design: 6th line of the first paragraph: "making it useful in concert with"? Is it a typo?

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 23 Sep 2009 12:09:38 -0500

Hi Shahram, 

Thank you very much for the answers. 

Maybe some wording can be improved. For example, if the text says
"transmitting BFD" over multiple paths, it is better to define what "path"
means. To many people, especially people with transport network background,
paths mean physical paths. Different LDP or LSP paths between two systems
may not traverse all the paths between two systems. 

I understand that the intent of BFD is to let BFD run over various media.
But the description of the protocol is under the assumption that BFD is
running over a path which source can control, like LSP or LDP. For IP
forwarding, the source can't control which path to traverse from A to B. It
is up to intermediate nodes to choose a path.  

 Linda Dunbar

  _____  

From: Shahram Davari [mailto:[email-masked]] 
Sent: Wednesday, September 23, 2009 11:53 AM
To: Linda Dunbar; [email-masked]; [email-masked]; [email-masked]
Subject: RE: How to enforce BFD to be sent over different paths between two
systems?

Hi Linda,

I am sure Dave will answer these questions better that I do, but let me give
you my 2c inline.

Regards,

Shahram

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Linda Dunbar
Sent: Wednesday, September 23, 2009 9:35 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: How to enforce BFD to be sent over different paths between two
systems?

Dave, 

 

SD> For example there can be multiple LSPs between two systems and you need
to run BFD separately on each LSP.  

 SD> Your understanding is correct. But note that Echo packets are not BFD
packets. BFD just negotiates the Echo interval.

SD> Every LSP or PW or tunnel that runs BFD could be setup using an instance
of control plane.  We don't care about the control plane of the client or
server layers. What this bit indicates is the control-plane for the layer
you are running the BFD on.

    SD> If D=0 it means Async mode. For Echo, if a system does not want to
receive Echo it can set  "Required Min Echo RX Interval " = 0 . And there is
not need to signal that you want to Tx Echo.

   SD> the Discr is a locally unique number (not globally) very similar to
an LSP MPLS label that is distributed from a downstream node. It it not
negotiated. 

SD> As far as I know concatenated paths in transport networks mean stitching
two connections such as two LSPs.

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 23 Sep 2009 10:31:28 -0700

Hi Linda,

That is correct. For IP there is only one path (shortest path)  between two systems.

Regards,
Shahram

________________________________
From: Linda Dunbar [mailto:[email-masked]]
Sent: Wednesday, September 23, 2009 10:10 AM
To: Shahram Davari; [email-masked]; [email-masked]; [email-masked]
Subject: RE: How to enforce BFD to be sent over different paths between two systems?

Hi Shahram,

Thank you very much for the answers.
Maybe some wording can be improved. For example, if the text says "transmitting BFD" over multiple paths, it is better to define what "path" means. To many people, especially people with transport network background, paths mean physical paths. Different LDP or LSP paths between two systems may not traverse all the paths between two systems.

I understand that the intent of BFD is to let BFD run over various media. But the description of the protocol is under the assumption that BFD is running over a path which source can control, like LSP or LDP. For IP forwarding, the source can't control which path to traverse from A to B. It is up to intermediate nodes to choose a path.

 Linda Dunbar

Subject: RE: How to enforce BFD to be sent over different paths between two systems?

Hi Linda,

Regards,
Shahram

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

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)?
    SD> If D=0 it means Async mode. For Echo, if a system does not want to receive Echo it can set  "Required Min Echo RX Interval " = 0 . And there is not need to signal that you want to Tx Echo.

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?
   SD> the Discr is a locally unique number (not globally) very similar to an LSP MPLS label that is distributed from a downstream node. It it not negotiated.

7.      Editorial: Section 2 Design: 6th line of the first paragraph: "making it useful in concert with"? Is it a typo?

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 23 Sep 2009 10:35:24 -0700

Hi Shahram,

> That is correct. For IP there is only one path (shortest path)  between two
Except ofcourse for the ECMP case.

Thanks,
Vishwas

> “transmitting BFD” over multiple paths, it is better to define what “path”
> forwarding, the source can’t control which path to traverse from A to B. It
> 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”.
>
>
>
>
>
> 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”?
>
>
>
> 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”.
>
>    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?
>
>
>
> 4.      The BFD’s Control Packet Format described in Section 4.1 has a bit
> 5.      Is the Discriminator field of the BFD’ Control Packet Format same as
> “making it useful in concert with”? Is it a typo?
>
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 23 Sep 2009 14:11:36 -0500

There is also ECMP for IP forwarding. 

Linda

  _____  

From: Shahram Davari [mailto:[email-masked]] 
Sent: Wednesday, September 23, 2009 12:31 PM
To: Linda Dunbar; [email-masked]; [email-masked]; [email-masked]
Subject: RE: How to enforce BFD to be sent over different paths between two
systems?

Hi Linda,

That is correct. For IP there is only one path (shortest path)  between two
systems.

Regards,

Shahram

  _____  

Hi Shahram, 

 Linda Dunbar

  _____  

Hi Linda,

Regards,

Shahram

  _____  

Dave,

---

From: Mach Chen <[email-masked]>
Date: Thu, 24 Sep 2009 10:54:37 +0800

Hi,

For LDP LSP, it also has the same ECMP issue.

Could I say that BFD is suitable for any ECMP scenario?

Best regards,
Mach

--------------------------------------------------
From: "Vishwas Manral" <[email-masked]>
Sent: Thursday, September 24, 2009 1:35 AM
To: "Shahram Davari" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Subject: Re: How to enforce BFD to be sent over different paths between 
twosystems?

---

From: Mach Chen <[email-masked]>
Date: Thu, 24 Sep 2009 11:00:42 +0800

Correct:-)

"Suitable" should be "not suilable"

--------------------------------------------------
From: "Mach Chen" <[email-masked]>
Sent: Thursday, September 24, 2009 10:54 AM
To: "Vishwas Manral" <[email-masked]>; "Shahram Davari" 
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Subject: Re: How to enforce BFD to be sent over different paths 
betweentwosystems?

---

From: Dave Katz <[email-masked]>
Date: Mon, 28 Sep 2009 13:26:27 -0600

On Sep 23, 2009, at 10:34 AM, Linda Dunbar wrote:

> Section 3: 3rd line of the first paragraph states “A pair of 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  

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

No, just my somewhat arcane choice of wording.  "In concert with"  
means "along with" or "in combination with".

---

From: Dave Katz <[email-masked]>
Date: Mon, 28 Sep 2009 13:34:59 -0600

"Path" is a very generic term;  it is unfortunate that there is some  
conflict in terminology, but those of us steeped in network layer  
technology don't view paths as being physical.

For what it's worth, there is this bit in the spec:

  BFD can provide failure detection on any kind of path between
  systems, including direct physical links, virtual circuits, tunnels,
  MPLS LSPs, multihop routed paths, and unidirectional links (so long
  as there is some return path, of course.)

 From the standpoint of BFD running at the network layer, you are  
correct in pointing out that the endpoint may not be able to choose  
the physical path over which the packets will fly (particularly with  
MPLS).  However, from BFD's standpoint in this case, the MPLS LSP *is*  
the path.  If the LSP gets moved around to a different physical path  
beneath it, BFD at this layer will not know nor care;  its sole  
purpose is to let the end system know whether or not the LSP is viable.

Note that one could run BFD at multiple layers;  a BFD session could  
run over each individual physical link if that was interesting,  
independent of BFD being run over the LSP. This is in fact likely to  
be the case if the LSPs are being built with the assistance of routing  
protocols being run directly over the physical links, for example.

--Dave

On Sep 23, 2009, at 11:09 AM, Linda Dunbar wrote:

> “transmitting BFD” over multiple paths, it is better to define what  
> “path” means. To many people, especially people with transport  
> network background, paths mean physical paths. Different LDP or LSP  
> paths between two systems may not traverse all the paths between two  
> systems.
>
> I understand that the intent of BFD is to let BFD run over various  
> media. But the description of the protocol is under the assumption  
> that BFD is running over a path which source can control, like LSP  
> or LDP. For IP forwarding, the source can’t control which path to  
> traverse from A to B. It is up to intermediate nodes to choose a path.
>
>  Linda Dunbar
>
> 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”.
>
>
> SD> For example there can be multiple LSPs between two systems and  
> you need to run BFD separately on each LSP.
>
> 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”?
>
>  SD> Your understanding is correct. But note that Echo packets are  
> not BFD packets. BFD just negotiates the Echo interval.
>
>
> SD> Every LSP or PW or tunnel that runs BFD could be setup using an  
> instance of control plane.  We don't care about the control plane of  
> the client or server layers. What this bit indicates is the control- 
> plane for the layer you are running the BFD on.
>
> 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)?
>     SD> If D=0 it means Async mode. For Echo, if a system does not  
> want to receive Echo it can set  "Required Min Echo RX Interval " =  
> 0 . And there is not need to signal that you want to Tx Echo.
>
> 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?
>    SD> the Discr is a locally unique number (not globally) very  
> similar to an LSP MPLS label that is distributed from a downstream  
> node. It it not negotiated.
>
> SD> As far as I know concatenated paths in transport networks mean  
> stitching two connections such as two LSPs.
>
> 7.      Editorial: Section 2 Design: 6th line of the first  
> paragraph: “making it useful in concert with”? Is it a typo?
>

---

From: Dave Katz <[email-masked]>
Date: Mon, 28 Sep 2009 13:40:51 -0600

BFD is suitable for any multipath scenario in which the sessions can  
be bound to those individual paths by one means or another.  This is a  
somewhat reflexive statement, but it gets at the heart of the  
problem:  if you can't distinguish multiple paths from the vantage  
point of where BFD is running, you can't have multiple sessions.

This tension is most obvious in the L1/L2 bundling case;  if BFD sees  
only the aggregate interface, there's no use in having multiple  
sessions (and you can't demultiplex the sessions without some other  
help, such as out-of-band discriminator exchange.)

One could imagine running BFD on each individual link of a bundle and  
then having a separate session that runs over the bundle (or not) but  
it looks like BFD won't get much traction at L2 so this is moot.

In the usual IP ECMP case, BFD is suitable because sessions can be  
bound to each of the individual L2 paths (by physical or logical  
interface, for example.)

--Dave

On Sep 23, 2009, at 9:00 PM, Mach Chen wrote:

> To: "Vishwas Manral" <[email-masked]>; "Shahram Davari" <[email-masked] 
> >
>> between twosystems?
>>>> can
>>>> not BFD
>>>> want to
>>>> not call
>>>> similar to
>>>> Therefore,
>>>> paragraph:

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 28 Sep 2009 16:34:36 -0700

Hi Mach,

> Could I say that BFD is suitable for any ECMP scenario?

If the two paths are at the head end we could force the packets out of
the different interfaces otherwise based on the FEC the packets could
be forced on particular path, but we may not be able to exercise every
ECMP path (if the routing convergence time is more than the BFD
detection time).

Thanks,
Vishwas

>>>  “path”
>>> systems
>>> instance