Re: How to enforce BFD to be sent over different paths between two systems?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How to enforce BFD to be sent over different paths between two systems?
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.
>
>
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.