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

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Thu, 09 May 2019 09:58 UTC

Return-Path: <ketant@cisco.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 9A4B7120092; Thu, 9 May 2019 02:58:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=BUVdub7h; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Z+bXRN35
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 wVaryDABtlTc; Thu, 9 May 2019 02:58:03 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854A7120041; Thu, 9 May 2019 02:58:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55398; q=dns/txt; s=iport; t=1557395882; x=1558605482; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MsxTCQI0hm97Gf345TrAcDQzK2FtR6iHkCHBc2Kzmmo=; b=BUVdub7h2yfzYl1kGJZuBkH9uehgprH2dzn+DCCUWsqCSTe2LwSyI5RI vDLgYVbYcNoB6bHeY9zVSwVXOyobJGJYv5b8Vlf9P70VPulKPAy+eAX+Y 4X+fX7LVjEowVrKXwmdueAYy+HVUake1VUj/U0xm+w/0H+XSsdfYkbCkO E=;
IronPort-PHdr: 9a23:Smo6cRx8UiEmKLLXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5YR2N/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1kAgMQSkRYnBZuGBFHyKuLCZC0hF8MEX1hgrDm2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AGAABd+NNc/5hdJa1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ4vJCwDaVUgBAsohBGDRwOEUoorgld+gWWGXI1mgS6BJANUCQEBAQwBASUIAgEBhEACF4FxIzQJDgEDAQEEAQECAQRtHAyFSgEBAQQSCwYKEwEBNwEPAgEIEQMBAQEhAQIEAwICAjAUCQgBAQQBDQUIGoMBgR1NAx0BAgyiEQKBNYhfcYEvgnkBAQWBBgEvAg5BgnwYgg8DBoEyAYtNF4FAP4ERRoIXNT6BBIEWRwEBAwGBXxUJBwYJglQygiaKf4JahE2ICoxdOQkCggmGHYhigSaCSIIQhkSNA4Nwhx6BF4ZNgU6MWwIEAgQFAg4BAQWBTziBVnAVgyeCDwwFEhSDOIUUhQgBNnKBKY5hAQE
X-IronPort-AV: E=Sophos;i="5.60,449,1549929600"; d="scan'208,217";a="545436631"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 May 2019 09:58:00 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x499w0Z4023054 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 May 2019 09:58:00 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 May 2019 04:57:59 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 May 2019 04:57:59 -0500
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 9 May 2019 04:57:59 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MsxTCQI0hm97Gf345TrAcDQzK2FtR6iHkCHBc2Kzmmo=; b=Z+bXRN35BGOuoYOdVP/VOJ0Wu+dW4NYBA3CW3dsOxPreSbI5Owt232cQuFm/RIijayZIPcTjIub/e8FhS7rWoZDmk9YktNGL+gPQR6s5GVaYoQpXA+0FYlO0UTPRPXONtg0mDXwwGAN8p0KVE4h1q77uR+HxT26oPjqGWajz+xA=
Received: from SN6PR11MB2845.namprd11.prod.outlook.com (52.135.93.24) by SN6PR11MB3517.namprd11.prod.outlook.com (52.135.125.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.12; Thu, 9 May 2019 09:57:57 +0000
Received: from SN6PR11MB2845.namprd11.prod.outlook.com ([fe80::5c42:5f15:d194:98f]) by SN6PR11MB2845.namprd11.prod.outlook.com ([fe80::5c42:5f15:d194:98f%5]) with mapi id 15.20.1878.019; Thu, 9 May 2019 09:57:57 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Lizhenbin <lizhenbin@huawei.com>, li zhenqiang <li_zhenqiang@hotmail.com>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <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>
Thread-Topic: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call
Thread-Index: AdT17jAMyz+sjMM6SRqyoxzf6xKAMQNusd3AAECOSzAAYvZqUAAFcw4A
Date: Thu, 09 May 2019 09:57:57 +0000
Message-ID: <SN6PR11MB2845B438EDD216F4E28EA989C1330@SN6PR11MB2845.namprd11.prod.outlook.com>
References: <013301d4f5ef$b1b51310$151f3930$@ndzh.com> <HK0PR06MB2564F6AA8D6EAC625A9B4698FC3C0@HK0PR06MB2564.apcprd06.prod.outlook.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D8F59D91A@DGGEMM532-MBX.china.huawei.com> <SN6PR11MB284525EF7924E957EB851410C1310@SN6PR11MB2845.namprd11.prod.outlook.com> <76CD132C3ADEF848BD84D028D243C927CCD3A904@NKGEML515-MBX.china.huawei.com>
In-Reply-To: <76CD132C3ADEF848BD84D028D243C927CCD3A904@NKGEML515-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ketant@cisco.com;
x-originating-ip: [2001:420:5447:1264:4432:ee07:bba4:3000]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1be96dd3-c143-48c4-080a-08d6d464d033
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:SN6PR11MB3517;
x-ms-traffictypediagnostic: SN6PR11MB3517:
x-ms-exchange-purlcount: 6
x-microsoft-antispam-prvs: <SN6PR11MB3517D891C0CB08CAA72A7717C1330@SN6PR11MB3517.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 003245E729
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(376002)(39860400002)(366004)(396003)(189003)(199004)(102836004)(68736007)(46003)(54906003)(606006)(186003)(53546011)(6506007)(446003)(256004)(52536014)(14444005)(790700001)(478600001)(76116006)(45080400002)(966005)(486006)(476003)(14454004)(6116002)(76176011)(99286004)(86362001)(64756008)(66476007)(73956011)(66556008)(66446008)(66946007)(316002)(11346002)(4326008)(8936002)(81166006)(8676002)(53946003)(7736002)(6246003)(81156014)(71200400001)(25786009)(7696005)(110136005)(2906002)(229853002)(53936002)(9326002)(74316002)(55016002)(33656002)(6436002)(6306002)(54896002)(236005)(9686003)(2501003)(5660300002)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB3517; H:SN6PR11MB2845.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: ToG5ugllwb79qaalShzRzPEw2riDuQQgBPT9OvCcXqIEEF6Vjwq4CcyiflrtFe2pY67g/b1d6opOD06fB11C8zR3S5o5bzG6FAriSxHPw0rwEaZM/cW5W39m3k2ANQgp+JFdsZ7/2j9u+EKIsvSoGtDIdBeNXrBANgiBBwKLMQaUEUqjoynMqZor1MZWA7FDkifRi5YHj9Hkf+WHazVk8K55VDJ9TAG6t7CDu1N7kHdUXHqF1ybyNXXc5H+6w0P9dRgCA0iyotRTBQwjKghKHj0SZtn9kf2kWPUjQFHa/JzzYOOgv91scMhf4i/Wt6IBAI6qiAwSwwacHtfeCrpwJBwQFYCeSwlztiNl7DDO0qOtIXCi3VTFFpxeHjQ50oJtapTMqfkvvJgbwEbtYJz5v9+soTcps7jyal8UGxJ8I+E=
Content-Type: multipart/alternative; boundary="_000_SN6PR11MB2845B438EDD216F4E28EA989C1330SN6PR11MB2845namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1be96dd3-c143-48c4-080a-08d6d464d033
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2019 09:57:57.3416 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3517
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1q7DCC-6IlbdVHcRV0ypJ_emRQ8>
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: Thu, 09 May 2019 09:58:07 -0000

Hi Jie,

Sure, we would have SIDs which would need to be dynamically instantiated. Their allocation may even be done automatically by the node – it does not necessary imply the need/requirement always for a controller. But I think this argument is secondary.

Based on the discussions so far, my sense was that we need the authors to come up with an updated draft that covers the various aspects of provisioning via BGP and covers/clarifies on the points raised as part of this adoption call. I also believe that this is outside the scope of BGP-LS and we can discuss on doing this as a different AFI in BGP based on an updated draft.

Thanks,
Ketan

From: Dongjie (Jimmy) <jie.dong@huawei.com>
Sent: 09 May 2019 12:52
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; 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: RE: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Ketan,

One point raised during the discussion is that provisioning is relatively static, and signaling is usually dynamic. As the SIDs will be extended to represent various functions and resources, it is likely that some types of the SIDs will to be dynamically instantiated. In that case, it seems BGP could be an option for the SID allocation.

As for whether BGP-LS is the right option, or some other BGP mechanism should be defined, we can have further discussion on this.

Best regards,
Jie

From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
Sent: Tuesday, May 07, 2019 12:08 PM
To: Lizhenbin <lizhenbin@huawei.com<mailto:lizhenbin@huawei.com>>; li zhenqiang <li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>>; 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 Robin,

Please see inline for some comments.

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Lizhenbin
Sent: 06 May 2019 07:05
To: li zhenqiang <li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>>; 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 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.
[KT] Topology by it’s very nature is dynamic and changes due to planned and unplanned network events. That presents the case to advertise it via BGP-LS. The provisioning use-case is not quite on the same lines.

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.
[KT] PCEP is a p2p connection oriented protocol with a very transactional aspects to it’s protocol interactions – BGP is not.

3. For the possible methods of BGP extensions for the purpose, there can be other way such as introducing a new AFI/SAFI, etc.
[KT] If at all BGP, then that would perhaps be the way to approach this use-case/functionality.

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.
[KT] I think this is not just about re-use of BGP-LS TLVs anymore. It is a more fundamental shift in the BGP-LS use-case. The authors of the draft need to cover all possible aspects of this interactions, failures and other scenarios to explain how BGP is going to be used for doing day 0 and day X SR provisioning.

Thanks,
Ketan

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