Re: [Idr] Fw: WG adoption call for draft-xu-idr-neighbor-autodiscovery(Internet mail)

"UTTARO, JAMES" <ju1738@att.com> Tue, 31 July 2018 22:09 UTC

Return-Path: <ju1738@att.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29282130E89 for <idr@ietfa.amsl.com>; Tue, 31 Jul 2018 15:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYcd0xTZ3ayg for <idr@ietfa.amsl.com>; Tue, 31 Jul 2018 15:09:30 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8243130DC3 for <idr@ietf.org>; Tue, 31 Jul 2018 15:09:29 -0700 (PDT)
Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w6VM5UkC028559; Tue, 31 Jul 2018 18:09:28 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 2kjywg0f5b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Jul 2018 18:09:27 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w6VM9RZl026188; Tue, 31 Jul 2018 18:09:27 -0400
Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w6VM9J1q026104; Tue, 31 Jul 2018 18:09:21 -0400
Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id D5B0816A3EE; Tue, 31 Jul 2018 22:09:19 +0000 (GMT)
Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (unknown [130.9.129.152]) by zlp27125.vci.att.com (Service) with ESMTPS id B397716A3EB; Tue, 31 Jul 2018 22:09:19 +0000 (GMT)
Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.64]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0408.000; Tue, 31 Jul 2018 18:09:19 -0400
From: "UTTARO, JAMES" <ju1738@att.com>
To: "zcjiang(蒋治春)" <zcjiang@tencent.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] Fw: WG adoption call for draft-xu-idr-neighbor-autodiscovery(Internet mail)
Thread-Index: AQHUIooGv4eGR4+up0aXdjX/QRJ7raSp8DKg
Date: Tue, 31 Jul 2018 22:09:18 +0000
Message-ID: <B17A6910EEDD1F45980687268941550F3678AC31@MISOUT7MSGUSRCD.ITServices.sbc.com>
References: <013701d41227$579d2d10$06d78730$@ndzh.com> <001201d41f44$b65ef2a0$231cd7e0$@ndzh.com> <af70397b-e69d-4054-a09f-64028078f9a1.xiaohu.xxh@alibaba-inc.com> <001801d4201b$50989610$f1c9c230$@ndzh.com> <61c2eb0c-e9dd-4dc5-9ae4-8a98acaae0be.xiaohu.xxh@alibaba-inc.com> <DA0A405C-96EF-4340-A582-BC4EFF442116@tencent.com>
In-Reply-To: <DA0A405C-96EF-4340-A582-BC4EFF442116@tencent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.144.121]
Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F3678AC31MISOUT7MSGUSRCD_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-31_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807310203
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/JCmG4y6k2EUhXIlCvn6bAyxUAAc>
Subject: Re: [Idr] Fw: WG adoption call for draft-xu-idr-neighbor-autodiscovery(Internet mail)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Jul 2018 22:09:34 -0000

Zhichun,

                We also are heavily invested in BGP at AT&T Domestic and MOW networks.. help me understand the ask here. Are you saying that you want discovery everywhere in your network? Or is this ask specific to the DC and you will continue  with provisioning in the MAN/WAN space..


Thanks,
                Jim Uttaro

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of zcjiang(???)
Sent: Monday, July 23, 2018 9:35 AM
To: idr@ietf.org
Subject: Re: [Idr] Fw: WG adoption call for draft-xu-idr-neighbor-autodiscovery(Internet mail)

Hi , folks

I am a network architect from Tencent, one of the top 3 China's Internet giants and the largest Chinese social-network service operator, running multiple MSDCs across the world.

In our deployment of DC network, BGP is used as IGP to build the underlay of the DC fabric. Since we think BGP is better from perspective of scale and simplicity(think about the flooding of IGP in a DC fabric.....). We are also looking at the BGP based SR in DC yo achieve better traffic engineering and unified MPLS fabric across the DC/MAN and backbone.

The missing piece of BGP comparing to IGP is the neighbor auto-discovery, you still need to configure the peer address , local- remote AS etc, so the effort to add the auto neighbor discovering mechanism to BGP is highly desired.

We as an web operator and I personally as one of the contributor of the draft would like to advocate the mechanism described on this draft for sure.

Thanks

Zhichun Jiang.

------------------------------------------------------------------
From:Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>
Send Time:2018年7月20日(星期五) 19:18
To:徐小虎(义先) <xiaohu.xxh@alibaba-inc.com<mailto:xiaohu.xxh@alibaba-inc.com>>; Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>>; idr <idr@ietf.org<mailto:idr@ietf.org>>
Cc:draft-xu-idr-neighbor-autodiscovery <draft-xu-idr-neighbor-autodiscovery@ietf.org<mailto:draft-xu-idr-neighbor-autodiscovery@ietf.org>>
Subject:RE: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Xiaohu:

Our next step is to gather requirements for the IDR neighbor discovery from the WG.  We would especially be interested in feedback on requirements from operators of data centers.  If you know of an operators of medium data centers who could send requirements to the IDR chairs or the IDR list, it would be helpful.

Cheerily, Susan Hares

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of ???(??)
Sent: Friday, July 20, 2018 7:12 AM
To: Idr; idr
Cc: draft-xu-idr-neighbor-autodiscovery
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery


Hi Sue,

Thanks for launching the WG adoption call for draft-xu-idr-neighbor-autodiscovery.

Hi all,

There has been one implementation developed by a switch vendor. Furthermore at least two additional implementations from other vendors are under construction. If any of you have any concrete and technical concerns on this mechanism, please feel free to tell us and we would like to verify your concerns on the implementation and then give you feedbacks.

Best regards,
Xiaohu
------------------------------------------------------------------
From:Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>
Send Time:2018年7月19日(星期四) 17:59
To:idr <idr@ietf.org<mailto:idr@ietf.org>>
Cc:draft-xu-idr-neighbor-autodiscovery <draft-xu-idr-neighbor-autodiscovery@ietf.org<mailto:draft-xu-idr-neighbor-autodiscovery@ietf.org>>
Subject:Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

This closes the 2 week adoption for draft-xu-idr-neighbor-autodiscovery
(July 2 – July 16).

The WG chairs conclude on my original questions that:

1)  There is WG interest to have an auto-discovery mechanism

that will work for BGP peers in Data Centers


2)  There is some WG  interest having this work

in other deployments.


3)  There is no consensus on the mechanisms

(BGP hellos or other mechanisms)

Or requirements for the mechanisms.


4)  There is WG consensus and AD Consensus that we should

collaborate with LSVR. One mechanism for both would

be good, but it needs to fit the requirements set

by the WG.

There is no consensus on adoption this draft.

During today’s IDR session (18:10-19:10), we will have a
discussion on the requirements for the auto-discovery mechanisms.
We will start by reviewing the LSVR requirement set.

If our discussions today do not come to a clear conclusion,
the chairs are willing to sponsor an interim on the topic.

Susan Hares and John Scudder.

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, July 2, 2018 1:09 PM
To: idr@ietf.org<mailto:idr@ietf.org>
Cc: draft-xu-idr-neighbor-autodiscovery@ietf.org<mailto:draft-xu-idr-neighbor-autodiscovery@ietf.org>
Subject: [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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dxu-2Didr-2Dneighbor-2Dautodiscovery_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=MU6Gnn4Pl1H3kbngfFfnwWWrIF4eDWqmnSrxG03TYQ8&s=JWVZk-QAfbuLnv3IJNkfcyJDYO-4MUCpjoEGA_s7plY&e=>

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