Re: [Idr] draft-chen-idr-ctr-availability-00.txt

Hey Huaimo,

How you are all fine.

Thank you for response.

Ad 1. To clarify - my point about NEs was that _today_ BGP messages
received over IBGP are not sent to other IBGP peers unless you are RR. I am
not sure if it is safe to cut exceptions for this application in BGP like
you described.

Ad 2 I am glad you will consider it :)

Ad 3 Ok that sounds much better - but current draft does not present it
such way.

In general what you are trying to propose is a flavor of ZooKeeper over BGP
:) Innovative ? - Yes by all means . Good idea ? - I am not sure.

Best,
R.

On Thu, Mar 19, 2020 at 4:59 PM Huaimo Chen <huaimo.chen@futurewei.com>
wrote:

> Hi Robert,
>
>     Thank you very much for your comments and suggestions.
>     My answers/explanations are inline below with prefix [HC].
>
> Best Regards,
> Huaimo
> ------------------------------
> *From:* Idr <idr-bounces@ietf.org> on behalf of Robert Raszuk <
> robert@raszuk.net>
> *Sent:* Monday, March 9, 2020 5:42 AM
> *To:* idr@ietf. org <idr@ietf.org>
> *Subject:* [Idr] draft-chen-idr-ctr-availability-00.txt
>
> Dear Authors,
>
> I read your draft and sorry to say do not have good news.
>
> 1)
>
> First you break IBGP rule from base BGP spec. It is pretty standard that
> controllers distribute information via IBGP and with the help of RRs. Only
> RRs can send information received over IBGP to other IBGP peers.
>
> In your case it is hard to assume that all NEs are RRs. It is also hard to
> assume that always multiple controllers from the same controller cluster
> will be connecting to the same RRs.
>
> [HC]: It is not necessary to assume that all NEs are RRs. In general, it
> seems enough to assume that every edge NE is connected to the controller
> cluster, and one or two edges of the network are connected to multiple controllers
> in the cluster.
>
> 2)
>
> The best solution to your problem is to have two independent controller
> clusters. When fatal intra-cluster failures occur all cluster members
> should drop BGP sessions to the network.
>
> [HC]: Using two or more independent controller clusters for network or
> controller reliability/availability is another solution, which we will
> consider.
>
> 3)
>
> Asking all network elements to participate in exchanging information
> between controllers is really not a good idea. Not to mention that your
> current encoding does not even have a notion of cluster id.
>
> [HC]: In general, only one or two edges of the network will participate
> in exchanging information about controllers between controllers. We will
> consider cluster ID notion and encoding.
>
> Many thx,
> R.
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Mon, Mar 9, 2020 at 2:08 AM
> Subject: I-D Action: draft-chen-idr-ctr-availability-00.txt
> To: <i-d-announce@ietf.org>
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : BGP for Network High Availability
>         Authors         : Huaimo Chen
>                           Yanhe Fan
>                           Aijun Wang
>                           Lei Liu
>                           Xufeng Liu
>         Filename        : draft-chen-idr-ctr-availability-00.txt
>         Pages           : 12
>         Date            : 2020-03-08
>
> Abstract:
>    This document describes protocol extensions to BGP for improving the
>    reliability or availability of a network controlled by a controller
>    cluster.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-chen-idr-ctr-availability/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-idr-ctr-availability%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C4afaa98d844947f1b03608d7c40e4481%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637193437868987310&sdata=lOGxdK%2BGukAtjt3W3AoBq3hxmt8vNBC1fAvpMv5ROyI%3D&reserved=0>
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-chen-idr-ctr-availability-00
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-chen-idr-ctr-availability-00&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C4afaa98d844947f1b03608d7c40e4481%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637193437868987310&sdata=uJMQBTm5YVYgAL8JDmFJI2Z%2B2KFUst5SJdhPJPuamv8%3D&reserved=0>
> https://datatracker.ietf.org/doc/html/draft-chen-idr-ctr-availability-00
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-chen-idr-ctr-availability-00&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C4afaa98d844947f1b03608d7c40e4481%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637193437868997301&sdata=g4S6FkscMfxOvKu0ar0N%2F5h6YKjBQ%2F3OQAlmIdo%2FGL4%3D&reserved=0>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C4afaa98d844947f1b03608d7c40e4481%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637193437868997301&sdata=iB23OQijsbiuH6eVMu782lSxe9VJsCH7s3Yc4c3DAJw%3D&reserved=0>
> .
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fi-d-announce&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C4afaa98d844947f1b03608d7c40e4481%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637193437868997301&sdata=q%2F66OyDbdk9E9z0HnmUIxtadQVdWfw6KWqYa%2BF6jvLM%3D&reserved=0>
> Internet-Draft directories: http://www.ietf.org/shadow.html
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ietf.org%2Fshadow.html&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C4afaa98d844947f1b03608d7c40e4481%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637193437869007292&sdata=rtB%2BW0A3z%2F5ob%2BSZi4Ghz8UBWhtORfCQsgUOl%2B9I6Zo%3D&reserved=0>
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>