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

[" 徐小虎(义先) " <[e-mail]>]

Have you seen that the BGP session is teared down due to the loss of hello adjacency in this text?





来自钉钉专属商务邮箱------------------------------------------------------------------
发件人：Robert Raszuk<[e-mail]>
日　期：2018年07月18日 00:01:16
收件人：徐小虎(义先)<[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

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 





来自钉钉专属商务邮箱------------------------------------------------------------------
发件人：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.​