Subject: bfd application with BGP and static routes draft submission

From: zhaisuping <[email-masked]>
Date: Thu, 23 Jun 2005 19:18:33 +0800

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,
[email-masked]
Huawei Technologies Co., Ltd.
Tel: +86-10-82882867
Fax: +86-10-82882537
2005-06-23

---

From: Carlos Garcia Braschi <[email-masked]>
Date: Tue, 28 Jun 2005 18:40:31 +0200

2005/6/23, [email-masked] <[email-masked]>:
> 
> Message: 2
> Date: Thu, 23 Jun 2005 19:18:33 +0800
> From: zhaisuping <[email-masked]>
> Subject: bfd application with BGP and static routes draft submission
> To: "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>,      "[email-masked]"
>         <[email-masked]>,    "[email-masked]" <[email-masked]>,
>         "[email-masked]" <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="gb2312"
> 

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

---

From: zhaisuping <[email-masked]>
Date: Wed, 29 Jun 2005 12:23:48 +0800

At first thank you very much for your carefully reading the draft.
See my response inline please,marked with[suping].

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

>in use today, as OSPF and IS-IS are covered in the 1Hop draft.

[suping] I am very happy to do that.
>any peer to behave differently from standard RIP until the first

[suping]I agree with you.
>be extended to ICMPv6. I wouldn't do it, anyway.

[suping]I think ICMP is a optional ways to demultipelexing 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.
>MPLS and then you don't need BFD for this 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.
>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.
>discriminator... Perhaps restricting demultiplexing in the presence
>source/destination address pair? 

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

>Perhaps using the source port

[suping] There should be scenarios that more BFD sessions in one source port, so I don't 
think this will apply.