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

[zhaisuping <[e-mail]>]

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

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

[suping] For BGP I think the usually application is one-hop, so do we nessesarily
need the multi-hop BGP?  

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

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

[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
>address for demuliplexing?

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