RE: bfd application with BGP and static routes draft submission

richard.spencer@bt.com Mon, 04 July 2005 12:56 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpQVJ-0008OZ-Vl; Mon, 04 Jul 2005 08:56:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpQVB-0008Lm-RF for rtg-bfd@megatron.ietf.org; Mon, 04 Jul 2005 08:56:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08823 for <rtg-bfd@ietf.org>; Mon, 4 Jul 2005 08:56:43 -0400 (EDT)
From: richard.spencer@bt.com
Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpQvj-0008Gl-QD for rtg-bfd@ietf.org; Mon, 04 Jul 2005 09:24:12 -0400
Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Jul 2005 13:56:25 +0100
Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Jul 2005 13:56:25 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 04 Jul 2005 13:56:25 +0100
Message-ID: <B5E87B043D4C514389141E2661D255EC074C4F0C@i2km41-ukdy.domain1.systemhost.net>
Thread-Topic: Re: bfd application with BGP and static routes draft submission
Thread-Index: AcV8Yzh8sJ4iTTWkR9ujrlp7TGB58gADotfQ
To: zhaisuping@huawei.com, cgbraschi@gmail.com
X-OriginalArrivalTime: 04 Jul 2005 12:56:25.0676 (UTC) FILETIME=[C95E88C0:01C58097]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: f2984bf50fb52a9e56055f779793d783
Content-Transfer-Encoding: quoted-printable
Cc: rtg-bfd@ietf.org
Subject: RE: bfd application with BGP and static routes draft submission
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org

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

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?

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?

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

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

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

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

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

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

Regards,
Richard