Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Sat, 07 November 2020 15:20 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 6379A3A0769 for <idr@ietfa.amsl.com>; Sat, 7 Nov 2020 07:20:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.697
X-Spam-Level:
X-Spam-Status: No, score=-7.697 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=EiKeKA2B; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vnnrUBF7
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 ypHDi703-sh5 for <idr@ietfa.amsl.com>; Sat, 7 Nov 2020 07:20:00 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46CCC3A0656 for <idr@ietf.org>; Sat, 7 Nov 2020 07:20:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38232; q=dns/txt; s=iport; t=1604762400; x=1605972000; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=lISftjwCOo+MLWiXadF4D7e9JJHK95Eox4Apvb4luAQ=; b=EiKeKA2BeoqunSXsSmUygNbxvPViQsGgBl0wJk8y2aPSq4Q3qrgD+qKH YC/2j2oJbXbzewMlC62A7ZrACcfY9amf+WoUhwykkgGmFOOcDz7+JaAJ7 GCZbexw0NMp3m4TiqYf0mcRtvnAWPuEulB6Of97vT/8hoGBR6ZgHjLZeS g=;
X-IPAS-Result: =?us-ascii?q?A0BlBwC3uqZffYUNJK1iHQEBAQEJARIBBQUBQIFPgSMvU?= =?us-ascii?q?XtZLy4Kh3wDjVWBBZd8gUKBEQNUCwEBAQ0BASUIAgQBAYNLfwKCDwIlOBMCA?= =?us-ascii?q?wEBAQMCAwEBAQEFAQEBAgEGBBQBAYY8DIVyAQEBAQMSGxMBATgPAgEIEQQBA?= =?us-ascii?q?SEBBgcyFAkIAQEEARIIGoMFgX5XAy0BAQ6jNAKBO4hodIE0gwQBAQWBR0GDC?= =?us-ascii?q?RiCEAMGgTiCc4Y5hBMbgUE/gREBQoIaBy4+gQSBWQEBAgEBgSYBEgEjKwmDF?= =?us-ascii?q?IIsmwGMDZEcCoJtiQ2SIoMYihKSE4Izh1qLdIp5kmWCaAIEAgQFAg4BAQWBa?= =?us-ascii?q?yEsPXBwFYMkUBcCDY4fDBcUgzqFFIVDAXQCNgIGCgEBAwl8jDsBgRABAQ?=
IronPort-PHdr: =?us-ascii?q?9a23=3AVSpK9RbrgIS7ICCqjQV6ZuT/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaXD4XG4u1JiqzdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZ0DbvXCzqzUVH0?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,459,1596499200"; d="scan'208,217";a="583582629"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Nov 2020 15:19:58 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A7FJw6p007846 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 7 Nov 2020 15:19:58 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 7 Nov 2020 09:19:58 -0600
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 7 Nov 2020 10:19:57 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sat, 7 Nov 2020 10:19:57 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=INvBgc7Lhl5MqdvHFZwU+FHSUfaR1YqJb05aZuMbGO4acvUwhLxy3tSqFgTcKYZvaqDoSYRllPkYhi2+YYTEwUvtfQ6mh9y/hMJrhNJUJLj900b9FmXUEqqTyLfweOy0LITKSR0ihRV1QQMdQA/qlBw9jAkorsKMNdUURGUeQGborDnIYw9qyMds5PyJGxFeUDgxohdHCInFBNfjQNs0vBVQFhJlT739J2CKOWONbYVZwcf/M4QK9gGNdagIb+J6ny7ppTji1AqkTF+Ggo5cC+D3ZyyKgiMvnYGqmefUvFbw97DqMzbCFKJm2dlaWaOJm+LQUb4dgphELA5OZQeXjg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LXK+CI9NCiHq2evamfvf1VIrlaC3P8KSOWt+C5dcmsU=; b=Knk2gAimRB9ePOvgXNqe5OD9jKG0biS8w6rMoRGp02e79c4UCev0FXIbpnsFSNuWUgk46pAQh+nN/uLTmP+7cVT3WeLKBTpPOBHSAYsRpcXAdHJbuMr2uKDgyF8SWRhD4Psa6zII0NZJ68ZwUMtjOXmfFESXEoBRR+xY52KujD45WPKm+NcwbZfdlSeDh57XBE2abERQ/YpLYoFmfpKC5PgelslMwQtxH7+FxdlPRYeXMhRajNMlq+y20OxHrBqZglutdTpUjBoCbpigUsQQnedlkOtqSc0fd8yf+9CZr0PEXLxsfP+2XHaNmHN1MJUATrYzFA9wOuXlwtXPssq07Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LXK+CI9NCiHq2evamfvf1VIrlaC3P8KSOWt+C5dcmsU=; b=vnnrUBF7tH5jYs08N3YqB7O4FbrSpPu1rYQdwcDtIIhh1MXoFNAY62s9wAhuCH0sWIgQ9MX6Qhv8r11BXYtG12cGYCLlh3UIkpiiILkvf8mKMEh8TXQRmICBwVnVzFh23Vl5tk7CrQrSfGAzhMoIqkCkCQnKSrPbFfifZmA0LV4=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB1519.namprd11.prod.outlook.com (2603:10b6:301:d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Sat, 7 Nov 2020 15:19:53 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%6]) with mapi id 15.20.3499.032; Sat, 7 Nov 2020 15:19:53 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)
Thread-Index: AdawxZFiqE7+Vp6ETxeuJxQP7/0gpQDHG6AAAANP3ZAAAKAsYABJmgDw
Date: Sat, 7 Nov 2020 15:19:53 +0000
Message-ID: <MW3PR11MB4570B16693F5917177CC3AE2C1EC0@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <045d01d6b0c7$c5eb4900$51c1db00$@ndzh.com> <90afe1f6a6ae4a8dbe35ae03b6549f2f@huawei.com> <MW3PR11MB457004537F251A4E20B2FCBEC1ED0@MW3PR11MB4570.namprd11.prod.outlook.com> <952b8f7ccdfe4ae19a5a7a185776e602@huawei.com>
In-Reply-To: <952b8f7ccdfe4ae19a5a7a185776e602@huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [1.39.169.255]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 93f0cf51-79c5-406f-5124-08d88330940c
x-ms-traffictypediagnostic: MWHPR11MB1519:
x-microsoft-antispam-prvs: <MWHPR11MB1519D93808C4194B64CD665CC1EC0@MWHPR11MB1519.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: c3bNjdxBcMbU3658WxJOVJRAw4QoGd0XFyGx96ayBKL14TQPcUiN49+YqcCBtSfCiiy9O2r+kGCCAY68FBWLR5WPolkaAQ3XOdOeBsgri0v8qvUK9+zM+xv428fJtVwSd2GWYZdnm+hGkJL1tKQh4bLkSJSKoDbXPVyjiFxSzLfMJ2xXQHNHavTN9ZnQ2NuCtzRBa0wp+lIy2EqIqxmZQxOeJchz/NTAnkB0KjjiSj6t3ddVk+Cc7VXKImQU5HiZ4W34Ocl3/zJJGbfpOlzZv/glUzRpfy9bXK1rO9P5jhxvg2xoebSC6gu74f/AU9tMc/TYwyi9BS9LkSkS/owM7jAIwqLGPxYwm1Sn3+kPLJGrUsezPRPgvx3W/4WZXhP4DS55OCsxiMHXKFhphJBDlQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(39860400002)(376002)(346002)(136003)(110136005)(6506007)(316002)(66556008)(66946007)(76116006)(64756008)(66476007)(86362001)(55016002)(52536014)(71200400001)(9326002)(9686003)(33656002)(83380400001)(66574015)(2906002)(53546011)(26005)(186003)(5660300002)(7696005)(166002)(8676002)(66446008)(478600001)(966005)(8936002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: x61gFoBWTMb3v1INqxn9vk0d2x7T2Nhhj/sN0BVq2OvQSKyouFR2eSaAzXr7WaDO2xZWsGGx4JSXTh1ztcJeLLEWfA7ZTu2k+lpOpRPZsEfbOUFkrla1Jg52EqNdnUnvIcbaHD6YRbCUN6Gc/Rd7ao/2RM2aryvcvRNatlSrR37tJMv0zfvn5/EEkwjSpDfYRNw5PBokg+10t+SDDfcI8pUzaeq/m/iPRxQqQ/ypkeEMwVq0j1U2f/d0vfYLbiiT06u9TcabOiFWfYlKTfKB6UMTMR/lzNsPGxDLhBWEIUFTuGMZ/6BM3ljF5NXjZdRMDVAAKJaizIFtwYPRgROYj/9Rm6/ftm5Jn82ZSX2DhdAvSCMoNQRI2A31SwDtFgtiLyrjHCls/oeNt5b7KkWldKSDpZn/h4LHaGONeB9syNbGbysk6o2ywLJfRThakIYOcaIE+xMsQrD9dJlG3U327WeWHBKEIiVvdTa1XWx9L8p8BZK3F1LqsgC7sj1psU2vagjZHVgse8gagVKg8PoGGT0/JpUADDWrN02qOhUvrAABY9myEVZ6HujQDaW4Zh8TPGKLtwW6BVUp+OqJVdhr+mSVSHdkriH1qrghXwBVDgL2KN4VpD4P1FxJUTXzdhOOHp4Wv8BZ5B93QFiNCgy0xA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570B16693F5917177CC3AE2C1EC0MW3PR11MB4570namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 93f0cf51-79c5-406f-5124-08d88330940c
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2020 15:19:53.7742 (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-CrossTenant-userprincipalname: N6fNaZqICe/MSoTBNWR8OUd+NYjnEd6ZCKuxS0v49uy+q9l4mhVThqJsmLZkkyQyX0QK6Kg7Whe86UN/Uq733Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1519
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/3hw6ejdy-mbfq6HXTeqpQ6Z4GeM>
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)
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: Sat, 07 Nov 2020 15:20:05 -0000

Hi Jie,

Please check inline below.

From: Dongjie (Jimmy) <jie.dong@huawei.com>
Sent: 06 November 2020 15:33
To: Ketan Talaulikar (ketant) <ketant@cisco.com>om>; Susan Hares <shares@ndzh.com>om>; idr@ietf.org
Subject: RE: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi Ketan,

Thanks for your clarification. Please find some further replies inline:

From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
Sent: Friday, November 6, 2020 11:55 AM
To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi Jie,

Please check inline below.

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Dongjie (Jimmy)
Sent: 06 November 2020 08:20
To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi,

Yes, support with one question for clarification:

For SRv6 EPE, the Peer adjacency SID is advertised using SRv6 End.X SID TLV with BGP-LS Link NLRI, and this document says:

"The SRv6 End.X SID for the BGP Peer Adjacency indicates the cross-connect to a specific layer-3 link to the specific BGP session peer (neighbor)."

For the SRv6 EPE Peer Node SID, this document says:

"... the similar Peer Node and Peer Set functionality can be realized with SRv6 using the END.X behavior. The SRv6 BGP Peer Node SID TLV is an optional TLV for use in the BGP-LS Attribute for an SRv6 SID NLRI corresponding to BGP protocol."

My question is: for a BGP peer established using direct interface address, does this require both a peer adj-SID with BGP-LS Link NLRI and a peer node SID in SRv6 SID NLRI be advertised?
[KT] Yes.

 While with the mechanism of SR-MPLS EPE, my understanding is in this case advertising only the peer node SID would be enough, the peer adj-SID is optional and may be used for a multi-hop session with multiple underlying layer-3 links.
[KT] The SR-MPLS BGP EPE specification does not mandate the advertisement of any SID. It simply describes how to advertise them. In that sense, all of them are optional and the use-case/application determines which ones are required.

[Jie] Please find the below text quoted from draft-ietf-idr-bgpls-segment-routing-epe, in which the peer node SID MUST be instantiated, while the peer Adj SID and peer Set SID MAY be instantiated.

" The following BGP Peering SIDs need to be instantiated on a BGP
   router for each of its BGP peer sessions that are enabled for Egress
   Peer Engineering:

   o  One PeerNode SID MUST be instantiated to describe the BGP peer
      session.

   o  One or more PeerAdj SID MAY be instantiated corresponding to the
      underlying link(s) to the directly connected BGP peer session.

   o  A PeerSet SID MAY be instantiated and additionally associated and
      shared between one or more PeerNode SIDs or PeerAdj SIDs."
[KT2] I stand corrected.


It is the same in case of SRv6 BGP EPE. The differences between the two are the following:

  *   In case of SR-MPLS, both Adjacency and Node SIDs are advertised using their own separate/different BGP-LS Link NLRIs - this happens because their link descriptors are different. Please check sec 4.1 and 4.2.

[Jie] Based on the above text and the text in section 4.1, in case of SR-MPLS, the peer node SID and the associated link NLRI can provide the information about the BGP peer and the layer-3 link, thus still I'm not sure the peer adjacency SID with an additional link NLRI is needed. I agree their link descriptors are different, but in this case both link NLRIs are used to advertise the attributes of the same link.
[KT2] Yes, in that specific case, you are correct. However, that is not a generic statement. Please check https://tools.ietf.org/html/rfc8402#section-4.2 - the "interface/link" semantics are associated with the Peer Adjacency SID and not the Peer Node SID (very similar to IGP Node SID and IGP Adjacency SID).


  *   In case of SRv6, it is also advertised via different NLRIs - the Adjacency SID using the Link NLRI since it represents a topological link similar to IGPs. And the Node SID using the SRv6 SID NLRI since it does not represent a topological link but instead a peering session (that may go over one or more topological links or in some cases with multi-hop multiple nodes).

[Jie] In my view the difference in SR-MPLS and SRv6 is due to the different treatment of the peer node SID and the peer adjacency SID.
[KT2] Yes. This is more clearly aligned with RFC8402.
With SR-MPLS, the peer node SID and its link NLRI represents a topological inter-domain "link" or connectivity in BGP, and the peer adj-SID can be used to further describe the underlying layer-3 links when needed (e.g. multiple L3 links used for a BGP session on loopback addresses). While with SRv6, the peer adjacency SID is used to represent each inter-domain layer-3 link, and peer node SID is not used as topological information any more.
[KT2] Please see my previous comment with references from RFC8402 where the BGP peering segments are defined.

Both approaches could work in this case, while one concern is do we need to keep the capability of describing an inter-domain "link" at BGP level?
[KT2] I am not sure that I understand. Can you please clarify?

Thanks,
Ketan

Best regards,
Jie


Hope that clarifies.

Thanks,
Ketan

Best regards,
Jie

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, November 2, 2020 11:25 AM
To: idr@ietf.org<mailto:idr@ietf.org>
Subject: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

This begins an IPR call and a 2 week WG LC for
draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1 to 11/16/2020)

You can access the draft at:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-flex-algo/

This draft focus on the BGP-LS support for SRv6.
Spring has proposed the SRv6 support in RFC8402
(see section 3.1.3 for mechanisms and section 8.2 for
Security considerations).

There are two implementations: Cisco and GoBGP
You can see the implementation report at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

In your responses, please consider the following questions:
a) Is the SRv6 technology ready for deployment or
are there known issues?

b) Will SRv6 provide valuable support for
deployments of BGP-LS in support of source routing
(aka spring)?

c) Is this draft ready for publication?

If you know of additional implementations, please send
a note to the idr chairs with the information or
respond to this email.

Cheers, Susan Hares