Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

ruoxin huang <huoruoxin@outlook.com> Wed, 08 May 2019 15:26 UTC

Return-Path: <huoruoxin@outlook.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 1AC86120089 for <idr@ietfa.amsl.com>; Wed, 8 May 2019 08:26:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=outlook.com
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 pwG_KTZypadv for <idr@ietfa.amsl.com>; Wed, 8 May 2019 08:26:15 -0700 (PDT)
Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255105.outbound.protection.outlook.com [40.92.255.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825A6120043 for <idr@ietf.org>; Wed, 8 May 2019 08:26:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sDHf4ABvn9rshsGYKV8ktlN5dchzL8vwZIBQRcASmek=; b=lGcnd3LCfbDWhE5VkwJQXXpq20LmXn6orgEkjJETDyF5yZk2ZcSB2uoHk3D6n7U6EPkDrUuHiV6MuETIx4vn87Me00hhZM8J+ugadbORi1CKs749rc8uobC8kLZsayfOuJRqzb+OckDmBEFCMPOHJfY1U6D7YN6RpnMVRQ0xem3oeHK4OuEnQzsHePxgmJie5f7YB0rbHJasea53ws7KTCCBWuzrJ65MStusBVMbaWf0UPAalDAyKPX23xUUl+9KHwQ+O77gUkA6vTfiYX+RbSFQ8zsggM4Df0K2QU3irdnBc16wtRRYN9k9KMX1T1LfwaK7l0FDWOnlBuHiNXHwtw==
Received: from HK2APC01FT014.eop-APC01.prod.protection.outlook.com (10.152.248.54) by HK2APC01HT088.eop-APC01.prod.protection.outlook.com (10.152.249.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1856.11; Wed, 8 May 2019 15:26:10 +0000
Received: from SG2PR01MB2760.apcprd01.prod.exchangelabs.com (10.152.248.51) by HK2APC01FT014.mail.protection.outlook.com (10.152.248.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1856.11 via Frontend Transport; Wed, 8 May 2019 15:26:10 +0000
Received: from SG2PR01MB2760.apcprd01.prod.exchangelabs.com ([fe80::1973:3cc9:1e44:efec]) by SG2PR01MB2760.apcprd01.prod.exchangelabs.com ([fe80::1973:3cc9:1e44:efec%6]) with mapi id 15.20.1856.012; Wed, 8 May 2019 15:26:10 +0000
From: ruoxin huang <huoruoxin@outlook.com>
To: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call
Thread-Index: AQHVBaPKDtyNGt2AkE6VwSaX8NC7dKZhV/To
Date: Wed, 08 May 2019 15:26:10 +0000
Message-ID: <SG2PR01MB27605AC342ECE38D0158D72EB9320@SG2PR01MB2760.apcprd01.prod.exchangelabs.com>
References: <013301d4f5ef$b1b51310$151f3930$@ndzh.com> <HK0PR06MB2564F6AA8D6EAC625A9B4698FC3C0@HK0PR06MB2564.apcprd06.prod.outlook.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D8F59D91A@DGGEMM532-MBX.china.huawei.com> <005801d50473$bef7d200$3ce77600$@org.cn>, <5A5B4DE12C0DAC44AF501CD9A2B01A8D8F59FA73@DGGEMM532-MBX.china.huawei.com>
In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8F59FA73@DGGEMM532-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:1B9CD229322624D1A2CC657FB81EC38EED3948D17A6431E7CF3FAF63C660B80A; UpperCasedChecksum:BF537E56CBF96DB671B27F4DFE15EA82E9DFF03C95CEA650B933624351861754; SizeAsReceived:7075; Count:42
x-tmn: [tuoV7qqLe+MUEZDWjKpV0Sc/2bh1j8Jg]
x-ms-publictraffictype: Email
x-incomingheadercount: 42
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(9118020)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:HK2APC01HT088;
x-ms-traffictypediagnostic: HK2APC01HT088:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-message-info: K4bgEIVDP4u2A1wx+VEWcbvT2QA2YLOg1HYVzaH/cebIe3EWKbB6/TOGCC5CCKIUkP/6iQXniOedtu5O8zfZzA30lKBKuEHUSBFg5BsT1QLhchJYDLxVWDV9slhqGclcKJrAS5/J9H6w8IszS8XQ9h8OLgwRJNYmVZulyiv04YJJCxG7XPnChwpn0k0TKcZa
Content-Type: multipart/alternative; boundary="_000_SG2PR01MB27605AC342ECE38D0158D72EB9320SG2PR01MB2760apcp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 803e2170-b613-4c40-872e-08d6d3c97fca
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2019 15:26:10.4890 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT088
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-_wV-0D0OvkS_5KecreCJbktoVU>
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 08 May 2019 15:26:18 -0000

support.

Best Regards,
Huoruoxin

Sent from Outlook<http://aka.ms/weboutlook>

________________________________
From: Idr <idr-bounces@ietf.org> on behalf of Lizhenbin <lizhenbin@huawei.com>
Sent: Wednesday, May 8, 2019 9:41 PM
To: Aijun Wang; 'li zhenqiang'; 'Susan Hares'; idr@ietf.org
Cc: 'draft-ietf-teas-enhanced-vpn'; 'draft-dong-lsr-sr-enhanced-vpn'
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call


Hi Aijun,

BGP-LS EPE is to distribute the BGP Peer SIDs from ASBRs to the controller. The requirement of the BGP extensions described in the draft is to allocate SID from the controller to the network devices (including ASBRs).

The SID encoding in draft-ietf-idr-bgpls-segment-routing-epe can be reused. But an extra TLV has to be introduced to indicate allocating SIDs instead of reporting SID info if BGP-LS is used for the purpose.



Best Regards,

Robin







From: Aijun Wang [mailto:wangaijun@tsinghua.org.cn]
Sent: Tuesday, May 07, 2019 9:25 AM
To: Lizhenbin <lizhenbin@huawei.com>; 'li zhenqiang' <li_zhenqiang@hotmail.com>; 'Susan Hares' <shares@ndzh.com>; idr@ietf.org
Cc: 'draft-ietf-teas-enhanced-vpn' <draft-ietf-teas-enhanced-vpn@ietf.org>; 'draft-dong-lsr-sr-enhanced-vpn' <draft-dong-lsr-sr-enhanced-vpn@ietf.org>
Subject: ´ð¸´: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call



Hi, Robin:



Can the mechanism described in draft-ietf-idr-bgpls-segment-routing-epe solve the scenarios that you mentioned for BGP-only environment?

Under the BGP-only environment, the controller/router may know only the PeerNode, PeerAdj and PeerSet information, then it is possible to reuse these SIDs for the allocation.





Best Regards.



Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.



·¢¼þÈË: Lizhenbin [mailto:lizhenbin@huawei.com]
·¢ËÍʱ¼ä: 2019Äê5ÔÂ6ÈÕ 9:35
ÊÕ¼þÈË: li zhenqiang; Susan Hares; idr@ietf.org<mailto:idr@ietf.org>
³­ËÍ: draft-ietf-teas-enhanced-vpn; draft-dong-lsr-sr-enhanced-vpn
Ö÷Ìâ: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call



Hi Zhenqiang,

Please refer to my reply inline.



Best Regards,

Zhenbin (Robin)



From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of li zhenqiang
Sent: Wednesday, April 24, 2019 3:51 PM
To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>
Cc: draft-ietf-teas-enhanced-vpn <draft-ietf-teas-enhanced-vpn@ietf.org<mailto:draft-ietf-teas-enhanced-vpn@ietf.org>>; draft-dong-lsr-sr-enhanced-vpn <draft-dong-lsr-sr-enhanced-vpn@ietf.org<mailto:draft-dong-lsr-sr-enhanced-vpn@ietf.org>>
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call



Hi Sue and All,



Zhenqiang Li from China Mobile.



I see the value to allocate SIDs in a centralized way, especially for the SIDs representing network resources as proposed in https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/ and https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/.



However, I want to know why BGP-LS is chosen to to complete this work, not PCEP or netconf? BGP-LS is mainly used to collect information from network, other than configure network from a controller.

[Robin]

1. To be honest, there is much concern about the standardization process, inter-operability, performance on Netconf/YANG. It is necessary to think about the other option. Just like topology collection, there existed the way to use SNMP/MIB or Netconf/YANG to collect topology info from the network, later BGP-LS was proposed.

2. There is already PCE work to allocate SID in the centralized way (Refer to PCECC work proposed by https://tools.ietf.org/html/draft-ietf-teas-pcecc-use-cases-02). But there truly exists the BGP-only scenarios. It is difficult to introduce one more control protocol which may increase the complexity of network operation and maintenance. That is the reason why we introduced the BGP extension to allocate SID which also can reduce the possible complexity.

3. For the possible methods of BGP extensions for the purpose, there can be other way such as introducing a new AFI/SAFI, etc. But we think the BGP-LS extension may be the easiest way. Since BGP-LS can collect info of all kinds of SIDs from the network devices to the controller, it is only to define a TLV/Sub-TLV to indicate the SID allocation from the controller to the network devices. All the existing TLV/Sub-TLV using by BGP-LS will be reused without any change. If use other ways, there has to define some new TLVs/Sub-TLVs or the transition from the corresponding BGP-LS TLV/Sub-TLVs to the new TLVs/Sub-TLVs. But the option is open. We would like to solicit comments from BGPers.









Best Regards,

Zhenqiang Li

________________________________

li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>



From: Susan Hares<mailto:shares@ndzh.com>

Date: 2019-04-18 22:04

To: idr@ietf.org<mailto:idr@ietf.org>

Subject: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

This begins a 2 week WG Adoption call for draft-wu-idr-bgp-segment-allocation-ext-02.txt.  You can access the draft at:



https://datatracker.ietf.org/doc/draft-wu-idr-bgp-segment-allocation-ext/



In your comments, consider:



1)      Does this draft mechanisms for  extending BGP-LS to provide IDs for allocation provide a beneficial addition to BGP mechanisms for segment routing?

2)      Is the mechanism well-formed enough to adopted as a WG draft?

3)      Do you see any problems with using these IDs for flow redirection?

4)      Do you support extending BGP-LS?

5)      Should we provide an early allocation for this technology?

6)      Do you know of any early implementations?



By answering these questions during WG Adoption call, you will help John and I determine what issues need to be considered prior to finalizing this WG draft.    Your answer will help us increase the speed of processing BGP-LS drafts.



If enough people indicate that they wish an early allocation upon adoption, I will then send this early allocation to Alvaro.



Sue Hares



PS ¨C I¡¯m trying new methods of WG adoption calls to help speed up the process in IDR WG.   Please send any thoughts on these new methods to me or John.