Re: How to enforce BFD to be sent over different paths between twosystems?

[Vishwas Manral <vishwas.ietf at gmail.com>]

Hi Mach,

On Wed, Sep 23, 2009 at 7:54 PM, Mach Chen <mach at huawei.com> wrote:
>
> 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

> Best regards,
> Mach
>
>
> --------------------------------------------------
> From: "Vishwas Manral" <vishwas.ietf at gmail.com>
> Sent: Thursday, September 24, 2009 1:35 AM
> To: "Shahram Davari" <davari at broadcom.com>
> Cc: <rtg-bfd at ietf.org>; <dkatz at juniper.net>; <dward at cisco.com>
> Subject: Re: How to enforce BFD to be sent over different paths between
> twosystems?
>
>> Hi Shahram,
>>
>>> That is correct. For IP there is only one path (shortest path)  between
>>> two
>>> systems.
>>
>> Except ofcourse for the ECMP case.
>>
>> Thanks,
>> Vishwas
>>
>>> ________________________________
>>> From: Linda Dunbar [mailto:ldunbar at huawei.com]
>>> Sent: Wednesday, September 23, 2009 10:10 AM
>>> To: Shahram Davari; rtg-bfd at ietf.org; dkatz at juniper.net; dward at cisco.com
>>> 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
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: Shahram Davari [mailto:davari at broadcom.com]
>>> Sent: Wednesday, September 23, 2009 11:53 AM
>>> To: Linda Dunbar; rtg-bfd at ietf.org; dkatz at juniper.com; dward at cisco.com
>>> 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: rtg-bfd-bounces at ietf.org [mailto:rtg-bfd-bounces at ietf.org] On
>>> Behalf
>>> Of Linda Dunbar
>>> Sent: Wednesday, September 23, 2009 9:35 AM
>>> To: rtg-bfd at ietf.org; dkatz at juniper.com; dward at cisco.com
>>> Subject: How to enforce BFD to be sent over different paths between two
>>> systems?
>>>
>>> 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?
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>> 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?
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> 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?
>>>
>>>
>>>
>>> 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?
>>>
>>>
>>>
>>> Thank you very much for helping me.
>>>
>>>
>>>
>>> Best Regards, Linda Dunbar
>>>
>>> Advanced Technology Dept, Wireline Networks,
>>>
>>> Huawei Technologies, Inc.
>>>
>>>
>>
>