Re: [Idr] 答复: WG adoption call for draft-xu-idr-neighbor-autodiscovery

[Robert Raszuk <[e-mail]>]

Quote:

"peer no longer wishes to keep *BGP session*"


On Tue, Jul 17, 2018 at 5:45 PM, 徐小虎(义先) <[e-mail]> wrote:

> Where did you find that the quoted text talks about BGP sessions?
>
> Xiaohu
>
>
>
>
>
> 来自钉钉专属商务邮箱 <http://(null)>
>
> ------------------------------------------------------------------
> 发件人：Robert Raszuk<[e-mail]>
> 日 期：2018年07月17日 21:09:46
> 收件人：徐小虎(义先)<[e-mail]>
> 抄 送：Idr<[e-mail]>; Lizhenbin<[e-mail]>; Susan
> Hares<[e-mail]>; [e-mail]<[e-mail]>
> 主 题：Re: [Idr] 答复: WG adoption call for draft-xu-idr-neighbor-autodiscovery
>
>
> Xiaohu,
>
>
> A) Permanently installing routes in RIB & FIB carried in BGP Hellos TLVs
>> which are UDP based is something never heard of. Clearly you are up to
>> great precedence here. There is no mention in the current draft when such
>> routes are removed.
>>
>> [Xiaohu] It said in the draft that "
>>
>>    If the timer
>>    expires without receipt of a matching Hello from the peer, BGP
>>    concludes that the peer no longer wishes to keep BGP session for that
>>    link or that the peer has failed.  The BGP peer then deletes the
>>    Hello adjacency.  The route towards the BGP neighbor's loopback
>>    address that had been dynamically created due to that BGP Hello
>>    adjacency SHOULD be deleted accordingly. "
>>
>>
>
>
> ​You did not responded to the question at all as I never asked about BGP
> session above. There is no BGP session between loopbacks till you put
> routes in RIB and FIB as loopback is still unreachable. ​In your draft you
> are putting the routes from TLVs carried in UDP and not only how to reach
> loopback but also all the atomic connected addresses on how to ECMP towards
> loopback. Observe that in my proposal I am not doing it.
>
> IMO that is not acceptable.
>
> Now since you quoted the above note that even some of your own co-authors
> declared this is going away and session will not be brought down upon
> missing hellos. It is sufficient to keep any BGP session up based on the
> keepalives, bfd or manual shut.
>
> In fact just few lines below you agree that periodic hellos may not be
> necessary when the session is up.
>
> Very confusing picture ...
>
> [Xiaohu] Could you please explicitly point out which TLVs are not needed?
>>
>>
>
> ​All of them. ​
>
> C) Creation of new message instead of using existing BGP message requires
>> more changes then necessary. It also allows for extensible framework which
>> while normally is a feature here has a clear potential to be rather a bad
>> thing.
>>
>> [Xiaohu] Which existing BGP message could be used for this BGP peer
>> auto-discovery purpose from your POV?
>>
>>
>
> ​BGP Open Message. ​
>
>
>
>
>
>> D) Sending BGP Hellos periodically - after session is up does not seems
>> to bring any value especially for p2p links. For LANs on the other hand (if
>> such requirement is in place) there are much better solutions other then
>> periodic BGP Hellos.
>>
>> [Xiaohu] Good point. We could consider how to optimize it in the future.
>> Do you have any concrete suggestions for such optimization?
>>
>>
>
> ​as above ... ​
>
> ​Thx,
> R.​
>
>
>