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

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

Robert,

Please see my response inline with [Xiaohu]


------------------------------------------------------------------
From:Robert Raszuk <[e-mail]>
Send Time:2018年7月17日(星期二) 15:10
To:徐小虎(义先) <[e-mail]>
Cc:Idr <[e-mail]>; Lizhenbin <[e-mail]>; Susan Hares <[e-mail]>; [e-mail] <[e-mail]>
Subject:Re: [Idr] 答复: WG adoption call for draft-xu-idr-neighbor-autodiscovery

Xiaohu,

First I did not deny anything. 

I still believe that DCs should use following reachability protocols in the order of preference: 

1. Link state IGP (vast majority of DCs can use it *as is*)
2. MSDCs link state with flooding reduction
3. EBGP with central configuration

I can see a value of automatic bring-up for SD-WAN CPE - you buy a box, place it anywhere in the world and it joins the local provider's underlay and then VPNs you are authorized to join all with just a login name. 

But in DC things do not work that way. In order to install a box you need to open a ticket with exact connectivity map as otherwise it will not get mounted. So you do know exactly where it is placed and who to peer with. Configuration will be necessary anyway. 

Note that validation if connectivity is done correctly according to your map is very important, but clearly does not belong to BGP. 

I wrote my proposal to a little bit enhance the #3 above mainly due to: 

a) points made by some folks that IETF should not mandate or limit operators on how to build his network

b) to limit damage which other similar proposals will result with. 


> please list them explicitly and then we can consider how to address your concerns.

Sure: 

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

B) All TLVs which are defined outside of need to bring up BGP session are dangerous as they glue current BGP with say new innovation (ex: LSVR) Once done here you can no longer separate the two. 

[Xiaohu] Could you please explicitly point out which TLVs are not needed?

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? 

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?

E) I see no reason to suggest in any form use of port 179 to such UDP multicast messages

[Xiaohu] If port 179 is reserved for other purpose, it looks fine for me to use another port number.

Best regards,
Xiaohu

Thx,
R.