Re: Re: bfd application with BGP and static routes draft submission

Suping Zhai <> Tue, 05 July 2005 13:26 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1DpnR3-00024b-8s; Tue, 05 Jul 2005 09:26:01 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1DpnO7-0000HO-Mz for; Tue, 05 Jul 2005 09:23:00 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id JAA16675 for <>; Tue, 5 Jul 2005 09:22:54 -0400 (EDT)
Received: from ([] by with esmtp (Exim 4.33) id 1Dpj7H-0007eY-6G for; Tue, 05 Jul 2005 04:49:24 -0400
Received: from (szxga03-in []) by (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <> for; Tue, 05 Jul 2005 16:15:58 +0800 (CST)
Received: from szxml02-in ([]) by (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <> for; Tue, 05 Jul 2005 16:15:57 +0800 (CST)
Received: from z11024 ([]) by (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <>; Tue, 05 Jul 2005 16:18:54 +0800 (CST)
Date: Tue, 05 Jul 2005 16:13:36 +0800
From: Suping Zhai <>
To: Carlos Garcia Braschi <>, "" <>
Message-id: <>
Organization: huawei
MIME-version: 1.0
X-Mailer: Foxmail 4.2 [cn]
Content-type: text/plain; charset="GB2312"
Content-transfer-encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: Re: bfd application with BGP and static routes draft submission
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Carlos, Richard,
At first very thank you both for your comments. See some response below.
>I agree with most of what you say, see some comments below.
>2005/7/4, <>:
>> Suping, Carlos,
>> The single-hop draft describes how BFD is used with graceful restart for OSPF/IS-IS and also mentions that BFD may be bootstrapped using OSPF/IS-IS hellos. Therefore if there is a requirement to use BFD with BGP, then I think a description of how BFD works with BGP graceful restart, and how BFD may be bootstrapped using BGP Open messages is important in order to achieve interoperability.
>> On the other hand, I am less convinced by the need for sections to cover BFD for static routes or RIP. In both cases, the BFD sessions will be established independently and therefore in my opinion the mapping of a BFD session to a static route or RIP neighbour is an implementation issue. What information do you believe is missing from the current drafts that prevents the implementation of interoperable static route and RIP BFD implementations (other than saying that BFD is optional)?
>[Carlos] Well, for RIP, I was advocating that the receiver of a RIP
>announcement take the Active role (and the sender a Passive role,
>unless it receives another announcement and is therefore a receiver),
>and that differs from the 1hop draft point 3. Although it's probably
[suping] Now I think that it's more appropriate to add some texts in 1hop draft about using BFD
with RIP, make some clarification about the application of BFD with RIP. 

>[Carlos] For both protocols, IF we discard LSP ping and ICMP methods
>for demultiplexing, a mention could be made that there is no need for
>other methods for initial session demultiplexing outside from what is
>written in the 1hop draft (so that we do not have an implementation
>that expects ICMP and the other that does not). Probably is so simple
>that could be included in the 1-hop draft.
[suping] I agree to remove LSP ping as a method to bootstrap the BFD session in 
BGP and static route case.

>> Additionally, what is the reason behind the suggestion to use ICMP to bootstrap BFD in the static route case? 

>***In the single-hop case, static route BFD sessions should be
>demultiplexed based on the interface and in the multi-hop case BFD
>sessions can be demultiplexed based on source/destination address
>pairs. The point being that the your discriminator fields do not need
>to be exchanged via another mechanism.
>An ideal solution would be for a BFD system (in an active role) to
>begin sending BFD control packets as soon as BFD is configured on the
>system using manual/OSS provisioning (with the your discriminator
>field set to zero and my discriminator set to a number automatically
>generated by the BFD system or via OSS). ***
>If ICMP was used here then OSS/manual provisioning would need to be
>used to configure the BFD sessions, and then to initiate the ICMP
>messages. Even if ICMP messages were sent automatically following BFD
>session configuration, why are they needed and what value do they add?
>[Carlos] I agree on the my discriminator being set to a number
>automatically generated or via OSS (although I prefer implementations
>with the former), but that's something that should not be on an RFC,
>should it?
>[Carlos] Although the paragraph between *** seems to follow from the
>1hop RFC and multi-hop RFC (although I have doubts on the
>applicability of static and RIP to multi-hop), what I am advocating is
>that a paragraph clarifying this could be added either to this draft
>or to the original 1hop draft. Probably that's all that is needed for
>static routes, and half of what is needed for RIP.
>[Carlos] About the value of ICMP in bootstrapping, that is a good
>question for Suping. I don't see it either.

[suping] As to ICMP, my initiate purpose is to provide a out-of-band
signalling method to bootstrap BFD session in the above two cases. And the advange is that
there is no need to send BFD control packet with the Your Discriminator is zero. So do you
think that this is applicable?

>> Please see below for some specific comments based on your discussion.
>> > > Should this draft be extended to the use of BFD for BGP in a
>> > > multi-hop environment? It seems that the changes needed for
>> > > BGP in a multi-hop environment would be that demultiplexing
>> > > should be based either on BGP signalling or on the
>> > > source/destination address pairs and that Authentication
>> > > SHOULD be used  (as specified in the multi-hop draft).
>> > [suping] For BGP I think the usually application is one-hop,
>> > so do we nessesarily need the multi-hop BGP?
>> [RS] What about IBGP and EBGP multihop?
>[Carlos] I agree, that's the application...

[suping] Yes, Perhaps that's the application. I think that according to the discussion we had, the demultiplexing of IBGP and EBGP is per the single-hop(interface and protocol) and multi-hop(source/destination pairs). And I think that the bootstrap issue of multihop IBGP and EBGP can be the same with the single-hop BGP(use the BGP OPEN message at least). And I want to know your opions?
>> > >Could this draft be extended to the use of BFD for RIP? This would
>> > >complete the application of BFD to the most common routing protocols
>> > >in use today, as OSPF and IS-IS are covered in the 1Hop draft.
>> >
>> > [suping] I am very happy to do that.
>> > >
>> > >As RIPv2 is mostly a protocol frozen in time, demultiplexing methods
>> > >would only be manual configuration and demultiplexing based on
>> > >source/destination address pairs.
>> > >ICMP and LSP-ping would not apply,
>> > >as reasoned below for static routes.
>> > >Also, because of this "frozennes", no possibility exists to negotiate
>> > >the discriminator value inside the protocol.
>> > >So, for this protocol, as in BGP, it should be OPTIONAL not
>> > to put the routes from RIP into the routing table until the BFD session is
>> > >established. In this case the behaviour could also be not to require
>> > >any peer to behave differently from standard RIP until the first
>> > >session is established.
>> >
>> > [suping]I agree with you.
>> [RS] If the BFD session cannot be established dynamically using RIP (i.e. it is established independently and then mapped to a RIP neighbour), then what information needs to go in the draft?
>[Carlos] I think there should be a way to establish the BFD sessions
>dinamically based on the RIP announcements. Manual configuration via
>OSS can be very cumbersome (and that's why we use RIP for routing
>anyway, so that we don't have to manually configure all the network).
>That's why I propose that RIP receivers start BFD sessions when
>receiving RIP announces (when they do not have already a BFD session),
>and give up after a numer of trials.
>> > >Although I'm not sure it is a good idea to use ICMP to achieve
>> > >demultiplexing, I think the section 3.1.1 is somewhat incomplete, as
>> > >it should define the ICMP type and code values (as TBD, perhaps), and
>> > >be extended to ICMPv6. I wouldn't do it, anyway.
>> >
>> > [suping]I think ICMP is a optional ways to demultiplexing
>> > BFD session. In fact in ICMP(V4), there are message types of 15
>> > (Information Request) and 16 (Information Reply), my intent is to
>> > extend the existing message by adding BFD discrimator in it.
>> > As for ICMPv6, I think there should be some new message
>> > type(TBD) for this purpose.
>> [RS] In the single-hop static route case (i.e. the next hop is directly connected) then the your discriminator field should be set to zero and the packet demultiplexed based on the interface. In the multi-hop static route case (i.e. the next hop is more than one hop away) then the your discriminator field should be set to zero and the packet demultiplexed based on the source/destination address pair. ICMP could be used to exchange your discriminator fields, but what would the advantage of this be over just sending a your discriminator field of zero, and demultiplexing based on the interface or source/destination address?
>[Carlos] I agree there is no advantage.
>> > >I'm also unsure what scenario could have a static route needing BFD
>> > >and have MPLS so that it has the LSP-ping mechanism to bootstrap the
>> > >session (3.1.2). If you have MPLS, you certainly could apply BFD for
>> > >MPLS and then you don't need BFD for this static route.
>> [RS] The requirement to use BFD for LSPs as well as static routes is perfectly viable. An operator may want to use BFD to detect failures between system A and system B where forwarding is based on static routes (e.g. for control traffic), whilst at the same time detect failures where forwarding is based on MPLS (e.g. customer traffic using a TE tunnel LSP). What is not viable is the use of LSP ping for bootstrapping the static BFD session.
>[Carlos] I see, that's right. In any case, LSP ping should not be used
>to bootstrap the static route.
>> > [suping]Yes, I think you are right. If MPLS is supported we
>> > could use BFD for MPLS and don't need BFD for the static route. In
>> > anoter word, when static route we think that no MPLS is supported. So
>> > I will make such clarification in the draft.
>> [RS] Forwarding of traffic between two systems based MPLS and static routes is valid, using BFD to bootstrap the static route session is not. If the static route belongs to a FEC for which forwarding is based on MPLS, then BFD should be used on the LSP (i.e. static route BFD is not needed because the packets are forwarded using MPLS not IP). If traffic for the static route is forwarded using IP, then the FEC for the LSP will be different and therefore LSP ping cannot be used to bootstrap the static route session, as per the MPLS BFD draft "BFD control packets sent by the ingress LSR are encapsulated in the MPLS label stack that corresponds to the FEC for which fault detection is being performed." The use of LSP ping to bootstrap any protocol other than MPLS is not viable and therefore this option should be removed from both the static and BGP cases in the draft.
>> > >I'm certainly overlooking something on 2.2 and 3.2, why
>> > >would one want to put a random address from 127/8 in the
>> > >destination address instead of the IP address of the peer
>> > >or the static route points to? In BGP, we already know the
>> > >destination address, why shouldn't it be used?
>> > >For static routes on a LAN environment, where that address must be
>> > >known in order to get its MAC address, the same reasoning applies. I
>> > >see the applicability to point-to-point environments, but there
>> > >Inverse ARP could be used to get the other side's IP address.
>> > >But in any case, probably a rationale for the decision wouldn't harm.
>> >
>> > [suping]Yes, I think you are right again:) We can use explicity destination
>> > IP address in BGP and static route applications because the DIP has been known.
>> [RS] The text from the encapsulation section being discussed here was obviously a 'cut & paste' from the BFD MPLS draft! There is no need for an encapsulation section anyway as encapsulation is covered in the single-hop draft.

[suping] My initial purpose is to get a integral draft, So copy some texts from BFD MPLS draft. I can remove this section if not needed iterate it. 
>> > >It would be a good thing if there were some mechanism so that manual
>> > >configuration does not need to configure a specific value for the My
>> > >discriminator... ¦ÜPerhaps restricting demultiplexing in the presence
>> > >of a zero value for the My discriminator to one session per
>> > >source/destination address pair?
>> [RS] The my discriminator field must be configured using a non-zero value, as per the base BFD draft "If the My Discriminator field is zero, the packet MUST be discarded." However, this doesn't mean that it needs to be manually configured, it could be dynamically generated by the system when the BFD session is enabled, or it could be dynamically generated/provisioned using OSS.
>[Carlos] You're right again.
>> > [suping]So in implementation a more situation must be considered if this is
>> > the criteria, and even more if more BFD sessions are needed, demultiplexing also
>> > needed not according to source/destination address pair.¦Ü
>> [RS] Demultiplexing issues/methods are already covered in the single-hop and multi-hop drafts. In the single-hop case, there should only be one BFD session per interface, per protocol. Therefore, if a system receives a BFD packet with a your discriminator of zero, then it is mapped to the corresponding session for that interface and protocol. In the multi-hop case,  if a system receives a BFD packet with a your discriminator of zero, then the session can be demultiplexed based on the source/destination address pair. Alternatively, out-of-band signalling may be used to exchange your discriminator fields prior to BFD session establishment, in which case packets are never received with a your discriminator field of zero.
>> > >Perhaps using the source port address for demuliplexing?
>> >
>> > [suping] There should be scenarios that more BFD sessions in one source port, so I don't
>> > think this will apply.
>> [RS] In the BGP and static route case, what possible scenarios are there where more than one BFD session will be required between two systems?

[suping] As to the demultiplexing issues, I think we can refer to the 1hop and multi-hop draft, so need not iterate in my draft again.

Best Regard,
>> Regards,
>> Richard