IETF Logo Mail Archive

[Idr] capability discovery - draft-ietf-idr-segment-routing-te-policy

"Stone, Andrew (Nokia - CA/Ottawa)" <andrew.stone@nokia.com> Fri, 20 July 2018 19:52 UTC

Return-Path: <andrew.stone@nokia.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 8B2D5130F53 for <idr@ietfa.amsl.com>; Fri, 20 Jul 2018 12:52:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 u8rmcakusd3a for <idr@ietfa.amsl.com>; Fri, 20 Jul 2018 12:52:48 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80117.outbound.protection.outlook.com [40.107.8.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B00131227 for <idr@ietf.org>; Fri, 20 Jul 2018 12:52:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WoWCQiQGfoCCtsgKMHjdGzQIOZ8UFvJuOETF8CClRRE=; b=EgXRpeZC0gpjKZlh7qnst93By21motKQH+UXvTtyz5iAyvdNvo88Fj/JDrH6SsNUiRsfrxqUbmCwo402YRQlttW6WbeyJ4P5q4ED0J0Qs99MA7w59C6xrxqfhHqHF0mvrPdW4ToLxTFQi4nAqgwdaoTqX4Pa+y6j2vOyy5xN/AI=
Received: from AM0PR07MB4417.eurprd07.prod.outlook.com (52.133.52.158) by AM0PR07MB4001.eurprd07.prod.outlook.com (52.134.82.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.16; Fri, 20 Jul 2018 19:52:43 +0000
Received: from AM0PR07MB4417.eurprd07.prod.outlook.com ([fe80::6c9f:58ac:b588:3a3]) by AM0PR07MB4417.eurprd07.prod.outlook.com ([fe80::6c9f:58ac:b588:3a3%2]) with mapi id 15.20.0995.008; Fri, 20 Jul 2018 19:52:43 +0000
From: "Stone, Andrew (Nokia - CA/Ottawa)" <andrew.stone@nokia.com>
To: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: capability discovery - draft-ietf-idr-segment-routing-te-policy
Thread-Index: AQHUIGM5QrDD/itLsE+8CeXIfzXksQ==
Date: Fri, 20 Jul 2018 19:52:43 +0000
Message-ID: <C1B70CF3-FBCB-469C-B312-F6CB79D19591@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.26.0.170902
x-originating-ip: [135.245.48.77]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB4001; 6:v7yWWOQF6nL+nGC1Ipi5TLqI6l1bMZjpr5x8CfEWgoxap1xO+O4XyHhXr982corv6dMOqdpJgAjXw5i8aJgZcfbf0hTaDkUyRXfIIwkgs2z2MdiBDTbbvGs/zYZ1BgFNqzhTRHwzJdP92v6MUFNyyle70pw5RwkTgkeq8WCOLXHD5reX7W6ItLApo5E4K/H/N1JHwzS07HahbqbS16kIHkEOz25ijWAizY+1FV+G2qFaR6AasPTbaCoZpaEEQgaLL/qpbx7/QR5izqVPY9WQyO1veX8enORkRLwIXUfpVX3dIfk2YDO+ONVDWvkPACByV5hgUe2PQnHxl8CjM7AqIVvd614JWyvBlf1Bzhd82TnJinbeX2iFoztHR3jAFUlVoLIBhtQFLD7AE0132lNe8eXXvTAAIE0v9iGyjYjA4Z4yKOVuAA1+RSEVak0T6/oThGe1f1W8dRfhctOUi2rfHg==; 5:/SN3n3zDTuRgIJ7GyKfp9fP2iFygteMzjGQByRiDg71/fm+V+a5Hy+VkeqXSCrTvtiWCXPgydWWVlEwIw6GkSlhsYHJqLcAJsPPIZX77J8SGKngYXHlRhzkw+qWodQ/w8bNDoUxuCrkbJHT1ZJl4FAAVOOqVgaR0KSQsVJ3QUlM=; 7:o8dfqbRwu317lJXHipVhUYiG7/utXpAH9qwsYW5Pk1xMT9+i59+JTU2zzXMRN/dsXk9A2+r0LU6ycz8C3+Q64Gb82kIlxRAe4FLwL4fgsrw8aDsYtnMGsKpXQhAITufME0wjyoA/HlXH0DEr8fw6ep8EqwKU8/3iQUPSEvozbHc1im+8pATYsSZK/wi2+PMWQr37rDZ2qsKWWTtvttkVK4+Q7bW3aK7BldfjXknz/Co8OXq9H1KUOL6vZf76nXWw
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 6f20644b-a27e-4275-3ced-08d5ee7a5bae
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:AM0PR07MB4001;
x-ms-traffictypediagnostic: AM0PR07MB4001:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.stone@nokia.com;
x-microsoft-antispam-prvs: <AM0PR07MB400145942C080AD830A7B86A91510@AM0PR07MB4001.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155)(17755550239193);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231311)(11241501184)(806099)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:AM0PR07MB4001; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4001;
x-forefront-prvs: 073966E86B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(366004)(136003)(376002)(346002)(199004)(189003)(53754006)(7736002)(86362001)(476003)(6916009)(486006)(97736004)(68736007)(2616005)(106356001)(478600001)(5250100002)(105586002)(2906002)(82746002)(81156014)(1730700003)(5660300001)(66066001)(81166006)(8676002)(256004)(25786009)(316002)(54896002)(6512007)(6306002)(102836004)(6506007)(36756003)(8936002)(99286004)(5640700003)(14454004)(6486002)(58126008)(6436002)(53936002)(186003)(33656002)(2351001)(83716003)(2501003)(26005)(2900100001)(6116002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4001; H:AM0PR07MB4417.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: uGXSMLIWzqacY7uex/CzOZ+6ASOx6q1B/SI9M5MQ4pnh1vYGbdPVvtBaXsmMu7Phwim/lAlDMmtahAU0X86bXwkRNPrCA0njeWkoMqbT11nc/ZCMQHk5VXHSEbIvXQZHTfD1aCnc6am5k4DhVoZMILyjmHvRrVWulYxB2doHsJEsiK/+zGF1LssU+EQwfMebzmqVx9figNxVFvCn47SICVun4j2hY3RkxdYM0Fti3k5YZu5pcxAPpQCxOe7H+uvP7CPlm953Pg6282SgFTqrYuqIpHjBZ5Ejgfd0DtdZhHqhWFeXz7s9OZJKDhguOsZgHOnaF9CZcOm0iguNvN+9HRBULLWF6BRhg/uQMSiCU/J1Um5G+YnnuK8JQcgiLtnUVUY6RXkmrHw35gXveKRvEw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_C1B70CF3FBCB469CB312F6CB79D19591nokiacom_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f20644b-a27e-4275-3ced-08d5ee7a5bae
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2018 19:52:43.3421 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4001
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LDy811C9O6YkUlb_uw5U9-Isae8>
Subject: [Idr] capability discovery - draft-ietf-idr-segment-routing-te-policy
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: Fri, 20 Jul 2018 19:53:04 -0000

Hi all,

Comment raised in IDR meeting regarding draft-ietf-idr-segment-routing-te-policy:

Assuming an architecture deployment where a controller is peered to a RR supporting address families bgp-ls and sr-te-policies, how does the controller know which downstream routers in the network support BGP advertised SR-TE Policies? as this information (peer session address families) is being masked by the RR? For example, if the controller wanted to install a BSID on a transient node in the middle of the network, how will the controller know that:

1) node in network is currently talking BGP
2) node supports sr-te-policy address family

Comparatively to PCEP, the PCEP session and its capability TLVs informs the controller of this.

Advertising SR-TE policy via BGP needs a similar ability or a description on how best to address this.

Some suggestions could include:


  *   perhaps advertising capability inside of BGP-LS
     *   But this means router needs to talk BGP-LS or have to relay it through IGP to reach the BGP-LS speaker, similar to draft-ietf-idr-bgp-ls-segment-routing-msd and draft-ietf-isis-segment-routing-msd
  *   Transient downstream router advertises the capability into using same SAFI as sr-te-policy but a different NLRI with a target of one, many or all controllers
  *   external learning such as via BMP, netconf, statically defined on controller… etc?

Thoughts?

Thanks
Andrew

v2.23.0 | Report a Bug | By Email