Re: bfd application with BGP and static routes draft submission

[Carlos Garcia Braschi <[e-mail]>]

I agree with most of what you say, see some comments below.

2005/7/4, [e-mail] <[e-mail]>:
> 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
obvious...

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

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

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

> > >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.
> 
> > >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?
> 
> Regards,
> Richard
> 
>