Re: bfd application with BGP and static routes draft submission

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

2005/6/23, [e-mail] <[e-mail]>:
> 
> Message: 2
> Date: Thu, 23 Jun 2005 19:18:33 +0800
> From: zhaisuping <[e-mail]>
> Subject: bfd application with BGP and static routes draft submission
> To: "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>,      "[e-mail]"
>         <[e-mail]>,    "[e-mail]" <[e-mail]>,
>         "[e-mail]" <[e-mail]>
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="gb2312"
> 
> I am sorry that I don't attatch the file in the last mail, so I send the mail again. Sorry for the mistake.
> 
> Dear all,
> I have written a draft about BFD application with BGP and static routes, the purpose is to resolve the BFD bootstrapping end encapsulation problem when in applications. It's 6 pages long, Comments are very welcome.
> 
> Please help to post to the IETF website this draft and thank you for that.
> 
> Thank you and Best regards.　　　　　　
> 
> Best Regards,
> [e-mail]
> Huawei Technologies Co., Ltd.
> Tel: [phone]
> Fax: [phone]
> 2005-06-23
> 

My comments:

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

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.

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.

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.

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.

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.

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? ¿Perhaps using the source port
address for demuliplexing?

Regards,
Carlos.
--
Telefonica Empresas