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

From: Zhuangshunwan <[email-masked]>
Date: Wed, 11 Jul 2018 06:26:11 +0000

Hi Sue,

I support the adoption as a contributor, and I’m not aware of any IPR.

1)            Yes, it can be used to simplified the complicated configuration of BGP.
2)            Yes, it works for other deployments such as metro area networks.
3)            BGP Hello message is like an LDP Hello message, which has been proven to work very well.
4)            Yes, it can be used by LSVR WG.

Best Regards,
Shunwan

发件人: Idr [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2018年7月3日 1:09
收件人: [email-masked]
抄送: [email-masked]
主题: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Greetings:

This begins a 2 week WG adoption call for draft-xu-idr-neighbor-autodiscovery (July 2 – July 16).

https://datatracker.ietf.org/doc/draft-xu-idr-neighbor-autodiscovery/

The authors of this draft should send their IPR statements in response to this email.  I hope the authors will ihelp their vacationing co-authors to respond by July 7th.

The WG should consider the following:

1)      Does BGP need to have an autodiscovery mechanism for peers within Data Centers?

2)      Does this mechanism work for other deployments?

3)      If so, should be passed in BGP Hello message?

Or should it be a part of another protocol (e.g. LLDP, BFD, etc).

4)      Does this interact with any of the LSVR work?

I want to thank the authors for their patience while we sorted through some of the WG LC for other drafts.  We decided to wait until some of those discussion were cleared up prior to starting a new WG Adoption call.

Susan Hares

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 11 Jul 2018 20:26:48 +0000

Support,

Linda

发件人: Idr [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2018年7月3日 1:09
收件人: [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Greetings:

Or should it be a part of another protocol (e..g. LLDP, BFD, etc).

Susan Hares

---

From: Lizhenbin <[email-masked]>
Date: Sun, 15 Jul 2018 14:41:44 +0000

Support for the WG adoption. BGP is widely used and simplifying the provisioning is important and useful. The solution proposed in the draft can solve the issue better. Moreover the solution should be better to be provided by BGP's self. Dependency on other protocols may add unnecessary limitation.

Best Regards,

Zhenbin(Robin)

Greetings:

Susan Hares

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 16 Jul 2018 17:32:31 +0200

*Hello Zhenbin,*

BGP is widely used and simplifying the provisioning is important and
> useful.
​+

> Moreover the solution should be better to be provided by BGP's self.
>
​+​

> Dependency on other protocols may add unnecessary limitation.
>

​Well I do agree with your above three comments above. But since
IMO draft-xu-idr-neighbor-autodiscovery goes way over the above points
opening pandora box with various TLVs, instead of keep arguing on the list
I wrote a small 3 page draft which does address the core issue of BGP build
in session auto setup in a fully automated way for both DCs or campus
deployments - yet without any risk of taking BGP on one more wild tracks
again.

*Hello Sue,*

Please kindly consider the below proposal as simple candidate solution for
the discussed problem at hand.

​ A new version of I-D, draft-raszuk-idr-bgp-auto-session-setup-00.txt
has been successfully submitted by Robert Raszuk and posted to the
IETF repository.

Name:           draft-raszuk-idr-bgp-auto-session-setup
Revision:       00
Title:          BGP Automated Session Setup (BGP-ASS)
Document date:  2018-07-16
Group:          Individual Submission
Pages:          6
URL:            https://www.ietf.org/internet-drafts/draft-raszuk-idr-bgp-
auto-session-setup-00.txt
Status:         https://datatracker.ietf.org/doc/draft-raszuk-idr-bgp-auto-
session-setup/
Htmlized:       https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-
session-setup-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-raszuk-idr-bgp-
auto-session-setup

Abstract:
   This document proposes a solution for BGP deployments in some
   specific environments to automatically establish BGP sessions without
   need for manual peer configuration.

Kind regards,
Robert.

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 17 Jul 2018 09:07:25 +0800

Robert,

If you believe that some TLVs proposed in draft-xu-idr-neighbor-autodiscovery are unnecessary, please list them explicitly and then we can consider how to address your concerns.

It seems that you have denied your previous argument as below. It seems like a good start:)

"...Sure you can do that. But perhaps someone could just explain (s/explain/complain?) what is so difficult in configuring your TORs and SPINEs with provisioning tool ? Why in DC there is need for this automation in BGP ? "

Best regards
Xiaohu
------------------------------------------------------------------
From:Robert Raszuk <[email-masked]>
Send Time:2018年7月16日(星期一) 23:33
To:Lizhenbin <[email-masked]>; Susan Hares <[email-masked]>
Cc:[email-masked] <[email-masked]>
Subject:Re: [Idr] 答复: WG adoption call for draft-xu-idr-neighbor-autodiscovery

Hello Zhenbin,

BGP is widely used and simplifying the provisioning is important and useful. 
+
 Moreover the solution should be better to be provided by BGP's self. 
+ 
Dependency on other protocols may add unnecessary limitation.

Well I do agree with your above three comments above. But since IMO draft-xu-idr-neighbor-autodiscovery goes way over the above points opening pandora box with various TLVs, instead of keep arguing on the list I wrote a small 3 page draft which does address the core issue of BGP build in session auto setup in a fully automated way for both DCs or campus deployments - yet without any risk of taking BGP on one more wild tracks again. 

Hello Sue,

Please kindly consider the below proposal as simple candidate solution for the discussed problem at hand. 

A new version of I-D, draft-raszuk-idr-bgp-auto-session-setup-00.txt
has been successfully submitted by Robert Raszuk and posted to the
IETF repository.

Name:           draft-raszuk-idr-bgp-auto-session-setup
Revision:       00
Title:          BGP Automated Session Setup (BGP-ASS)
Document date:  2018-07-16
Group:          Individual Submission
Pages:          6
URL:            https://www.ietf.org/internet-drafts/draft-raszuk-idr-bgp-auto-session-setup-00.txt
Status:         https://datatracker.ietf.org/doc/draft-raszuk-idr-bgp-auto-session-setup/
Htmlized:       https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-session-setup-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-raszuk-idr-bgp-auto-session-setup

Abstract:

Kind regards,
Robert.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 17 Jul 2018 09:10:53 +0200

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.

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.

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.

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.

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

Thx,
R.

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 17 Jul 2018 17:21:43 +0800

Robert,

Please see my response inline with [Xiaohu]

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

Xiaohu,

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

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. 

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

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

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 17 Jul 2018 15:09:46 +0200

Xiaohu,

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

​All of them. ​

> auto-discovery purpose from your POV?

​BGP Open Message. ​

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

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 17 Jul 2018 23:45:57 +0800

Where did you find that the quoted text talks about BGP sessions?

Xiaohu 

来自钉钉专属商务邮箱------------------------------------------------------------------
发件人：Robert Raszuk<[email-masked]>
日　期：2018年07月17日 21:09:46
收件人：徐小虎(义先)<[email-masked]>
抄　送：Idr<[email-masked]>; Lizhenbin<[email-masked]>; Susan Hares<[email-masked]>; [email-masked]<[email-masked]>
主　题：Re: [Idr] 答复: WG adoption call for draft-xu-idr-neighbor-autodiscovery

Xiaohu,

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

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. 

​All of them. ​

​BGP Open Message. ​

​as above ... ​
​Thx,
R.​

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 17 Jul 2018 18:01:16 +0200

Quote:

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

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

> 来自钉钉专属商务邮箱 <http://(null)>
>
> 抄 送：Idr<[email-masked]>; Lizhenbin<[email-masked]>; Susan
> Hares<[email-masked]>; [email-masked]<[email-masked]>
>> 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

---

From: "徐小虎(义先)" <[email-masked]>
Date: Wed, 18 Jul 2018 00:06:16 +0800

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

日　期：2018年07月18日 00:01:16

Quote:

"peer no longer wishes to keep BGP session" 

Xiaohu 

Xiaohu,

​All of them. ​

​BGP Open Message. ​

​as above ... ​
​Thx,
R.​