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> Wed, 11 November 2020 03:14 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 8E3D73A083B for <idr@ietfa.amsl.com>; Tue, 10 Nov 2020 19:14:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=B2SaeVCl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PaKUbT9F
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 fZcP2Rkwknpp for <idr@ietfa.amsl.com>; Tue, 10 Nov 2020 19:14:53 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1493A0808 for <idr@ietf.org>; Tue, 10 Nov 2020 19:14:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10568; q=dns/txt; s=iport; t=1605064493; x=1606274093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IRZdN93ARJ4BHukUktDt2vC0YlV9COWugGp8NzsxSnw=; b=B2SaeVClyj3Z13GB1JfE2+s0SL8KFr25fsRXqI+NdBDucZue6brXZy2z rAIhobpkzlHH4X/7rsAWIT+BDtR7ErLp29H7D6sWoAFyhxPGf/eYt4uuA EPWfXk+UlqxSDNcU0C9JjmYiPSCLb0wLrJ4X4PDHuL8gfqkFuq9p11ZQy k=;
X-IPAS-Result: =?us-ascii?q?A0AeEACgVqtffZxdJa1iHQI9BQUECRaBUYFQKSh7WS8uC?= =?us-ascii?q?oQzg0kDjVeBBYkQjm2BQoERA1QLAQEBDQEBGAsKAgQBAYNLfwIXgX0CJTgTA?= =?us-ascii?q?gMBAQEDAgMBAQEBBQEBAQIBBgQUAQGGPAyFcgEBAQECAQEBEBEEDQwBASwLA?= =?us-ascii?q?QQHBAIBBgIRBAEBAQICJgICAh8GCxUICAEBBA4FCBqDBYJVAw4gAQ6TK5BqA?= =?us-ascii?q?oE7iGh2fzODBAEBBYFHQYMODQuCEAMGgQ4qAYJyg3WGVxuBQT+BEUOCGgcuP?= =?us-ascii?q?oEEgRdCAQECAQGBJgESASODFTOCLJAaIIMsokuBKFQKgm2JDYxxhTWDGIoVk?= =?us-ascii?q?hSCM4dbjXaIfYJuj3mCaAIEAgQFAg4BAQWBayFpcHAVO4JpUBcCDY5WbgEIg?= =?us-ascii?q?kOFFIVEdDgCBgEJAQEDCXyLCC2BBgGBEAEB?=
IronPort-PHdr: =?us-ascii?q?9a23=3A5Pvy0xNticavflVN7TAl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKwx3lDMVITfrflDjrmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtaHc//YxvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,468,1596499200"; d="scan'208";a="607561754"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2020 03:14:52 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AB3EqUB029768 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2020 03:14:52 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 21:14:51 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 21:14:51 -0600
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 10 Nov 2020 22:14:50 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b8f7G4WqTfBe/WtbIDs/PJTz7yZ53y/n34QhauZ75SZkufBK17eKAqjGa8LRQ62B5l24QNLs6mJeFZRoyhbJgVsnGtXQE0ocOIpWlz9JO5BVnLkkyNP5UCvGP4Vf6PqPNyaCslnw3xv8FgwxqZT5eLM9rQDKE6KVVopP//HFBL2W9iSAxC9+H8FPebwiOI63EyznRW/bPwcWGPT4WytbV/uokxVHSafLBa/fOkJiN86LDU5coaVyh9FB0pNER7HCq4/lAkz50fwNbYf8+kfwGQ6aDpMDlC5D8I61ke893ruhkQT9oMALAsICrww9bGML+XwG1gmKCQV/1rfhqkeXSQ==
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=IRZdN93ARJ4BHukUktDt2vC0YlV9COWugGp8NzsxSnw=; b=aK04s9eKUiy0aJJw0pc57bCKgj/MV3T9c0m4nACq2u7vqO1KMtgKnAmStiVkDyhH+6iFt1S84N7sNgr3XJASidlIulWLofcYtdM0GsmWFOp9Jl4XmDBj2VQWYs0/VIY+k3YKUPvzDi2xJA9sbA/kLO71HuCFF4JPUhnXCiYshd06MbBSTpqxi1U7ezHp2M98h8LudDfwtLRICpVkKpM7ScN6VXiskbn/ovhCME3rYbx24Sfbx4e3qgX8BMVLYy8XaSHVO4NcOMPcQJi5ejTsqriyyTZPul19E4h72DYE6yvXOGIS4FqPC+5rp+DAdGimJpqWXpNkdlo79/aXjFl0BA==
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=IRZdN93ARJ4BHukUktDt2vC0YlV9COWugGp8NzsxSnw=; b=PaKUbT9FGgy1SrrQDxGeW1tFWDp2rsOiB2f2ibYchMtqKCmai1kt/qs6Ag+2NLg1vHm3vzM2XoWuvfe0A64nWyNzmzizGYZrVoXzUJ0YGEBD5H6VunmmU29sfXGefNH6Ip0WGfPD4GxXxYsll/QGpH7npRg5dMRfbiC75grwgqA=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB1775.namprd11.prod.outlook.com (2603:10b6:300:10e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.25; Wed, 11 Nov 2020 03:14:49 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3541.025; Wed, 11 Nov 2020 03:14:49 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>
CC: Susan Hares <shares@ndzh.com>, idr wg <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/0gpQGgsPiAAABLfLAAB73FgAAbPDew
Date: Wed, 11 Nov 2020 03:14:49 +0000
Message-ID: <MW3PR11MB4570248EE04C9CD3D959B5C1C1E80@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <045d01d6b0c7$c5eb4900$51c1db00$@ndzh.com> <CAB75xn64J_Fb+8ePQiCTYvD0hrHDd+6mA0-Ta-Wjnd7sq4MHjw@mail.gmail.com> <MW3PR11MB4570A7A8DBF7AB23857F9A04C1E90@MW3PR11MB4570.namprd11.prod.outlook.com> <CAB75xn6hdRxeGBf9RGkXA6GVT6dQw1OnjGhq+ah1T6Px6Q85Ww@mail.gmail.com>
In-Reply-To: <CAB75xn6hdRxeGBf9RGkXA6GVT6dQw1OnjGhq+ah1T6Px6Q85Ww@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [72.163.220.5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e6ead328-6a0e-4dda-5778-08d885eff33c
x-ms-traffictypediagnostic: MWHPR11MB1775:
x-microsoft-antispam-prvs: <MWHPR11MB17751FB1D509DB951B8FF27EC1E80@MWHPR11MB1775.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: a7FC2LuYwnx5aV9TDSzuR5P2kcraI/SaZzNazTK9AMA2uAzwptRvSFe9Hu9RBqDywUPcRVYG3V9ubqROnF0NaSTs6fZYUwZNYhrmExZD9HfLarKzaP9+vumO78zNBVKUf+6pwlR821zyRxRq+Bd9fYIjrEy3ptSUHmMdiMt/aMyVHzh/A1ttHApQFru7ndyWY4U0xumYjB+P74u9YZYeuizMiKnn8/uWj9cPuUSLBsgJ+6Hld0Q++JP6uUF3AsZPtq0/OjMDqpiC/cXWXrZ3/0ClCOTgOMGory2TDfKvdik4nThgKOQ2O51UyuvGPtAOkl2SMcG/KsiSn/MHZyXJ7iChp6atRnyzvgCRWSCIFGehPzQhItplQgdf4atUPwqm/Cxe67TG0IEP2s74qPkv1g==
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:(396003)(366004)(346002)(376002)(136003)(39860400002)(71200400001)(64756008)(66946007)(66476007)(66556008)(76116006)(8936002)(83380400001)(66446008)(52536014)(9686003)(53546011)(6506007)(4326008)(55016002)(5660300002)(8676002)(7696005)(2906002)(54906003)(186003)(316002)(478600001)(6916009)(966005)(86362001)(26005)(33656002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Cph+LvdruJMuWzkYTqLQKwmFNLiT4Go2Kse3f9HCgF6ZR6tHrTYk8VjOyxpa6p4Lg6A84EtPg1RaL14RQQDTP3oAbNhCilD4rLrTMxEw5pNAHrVd6sI3XAnuuhtzRC5lJNbT2/6OOSLTbHcHLOfZ5BKnXZycumzWioO/+9L0AnSU8uMplEyr4vY8SWgCoOEFGgvRBeVQY9vFPM3FZ+zzJD6WMv0/lTJ5YIIMRNptONGCeZaKtDnz8nkcDoyMTV2+jLIe5ji5QWVh0F9kc0x5OfZfcaCFw31uqY4f/5hv5YbfjBmbfp9DhHqvqELpluxVjGKRWIhTYZW6Rb3li9Y1C8qGc0BC+S9+zzpnvjFIVtK93Dg2+o2sn4vlhK8dXXFnxoE9u/yZH/sDDTFgrWiTS/jql22ozeos4btK6J3SPAGrcpwmN6Pfm4n+iG9DFCmfALhiCWMyrt6HZWqLodnG1V1UsRVlLWO5Ay8/7cQWQSLyJ2E9eP7d8SgjoqfW46N5ZN+qbXcvfiM1bwqQAzRsHHrfSxCktZhB7HsU1FtUnocb390SyjYxxBZtj205QpZQKa8+gR+WRPLPBrbYs4oY6McwIUDRcprmhLT3mK28DwtZ7Ay0kmTEyoMvYtguaXA7ROdrSy2xhba0xb3p/39yZcauBhaIGnjaq8/yNrBD+ogWY2pUaH5vMOY2Ezy0/chVZo2k39T1QJJfIhH/CaIc1x8WTFrh6ro00TFjsSGr63nhJEbUsE8WL5Da9bND/RWtp2MsLGdBuS9S+fUOeFPyEh4/0YS6wyjykNdpMC4RGX1giiIp0+X4pji9ehdqIhWFeIk2Vs1Lq47bjwG9UL0iKXVWAtVo8vDY6iHg2NAnyU+A76wn3v2krp5ZLS5rMUWQyQj+Z8gbXe//Y1AtZJ+inw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: e6ead328-6a0e-4dda-5778-08d885eff33c
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2020 03:14:49.7032 (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: h1FUTpD+1rW7tFgZH0wE/JM5UWSztLdi4omwx6np003Ck9dCTncbA0EBkkKgF9j03YSfdl8fYlqVRgc4XCpsxQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1775
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LJLqir45Uz79sIldjXvR88LWNm4>
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: Wed, 11 Nov 2020 03:14:56 -0000

Hi Dhruv,

Please check inline below [KT2].

-----Original Message-----
From: Dhruv Dhody <dhruv.ietf@gmail.com> 
Sent: 10 November 2020 19:21
To: Ketan Talaulikar (ketant) <ketant@cisco.com>
Cc: Susan Hares <shares@ndzh.com>om>; idr wg <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 a quick reply and taking my comments into consideration.

On Tue, Nov 10, 2020 at 4:55 PM Ketan Talaulikar (ketant) <ketant@cisco.com> wrote:
>
> Hi Dhruv,
>
> Thanks for your thorough review and feedback/comments. Please check inline below.
>
> -----Original Message-----
> From: Idr <idr-bounces@ietf.org> On Behalf Of Dhruv Dhody
> Sent: 10 November 2020 15:31
> To: Susan Hares <shares@ndzh.com>
> Cc: idr wg <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 Sue, WG,
>
> The SRv6 work for BGP-LS is important and I support its publication. I do have some comments which I hope will improve the I-D:
>
> Major
> - Regarding the various flag fields in the I-D. Should we redefine 
> them here or refer to the IGP documents? I see they match with 
> draft-ietf-lsr-isis-srv6-extensions. For the SR-MPLS draft (in
> draft-ietf-idr-bgp-ls-segment-routing-ext) the approach was to use a reference to the ISIS draft.
> [KT] The base RFC7752 has had the odd convention of providing reference to ISIS specifications for TLVs even though the information was applicable to both IGPs. The draft-ietf-idr-bgp-ls-segment-routing-ext points to the respective ISIS, OSPFv2 and OSPFv3 specs for the flags field - it does not point alone to ISIS drafts. Traditionally, there have been minor variations between the IGPs causing the flags to be different for each IGPs in BGP-LS. We've received feedback from the consumer applications of BGP-LS information to abstract and provide a consistent data across IGPs (where possible). That is the reason why the flags are being defined in the BGP-LS specifications here. If we look at RFC7752, we've had a union of flags for TLVs like Node Flags Bits TLV and IGP Flags TLV.
>

Few Observations -
- My main concern is to avoid re-definition and duplication; if you don't want to point to the flag fields as done in draft-ietf-idr-bgp-ls-segment-routing-ext, you can still point to the meaning of each of the flags where they were originally defined (unless there is any change in the context of BGP).
[KT2] The flags for SR-MPLS and SRv6 are different and likely evolve differently. We do not wish to link them up together in the encoding.

- BTW are you making a change in RFC7752bis to handle this concern? Is it right to do this only for SRv6?
[KT2] This is not about base BGP-LS spec and hence not a topic for the RFC7752bis.

<snip>

> - Section 2 provides a good summary; for ease of reader, can you add a forward reference to sections where each of the TLV is defined in this I-D?
> [KT] This will result in each line of this summary pointing to at least one or two (if not more) forward references and IMHO will affect readability. The section headings themselves are organized based on the summary and so are forward references really necessary?
>

The new RFC v3 format makes a pretty HTML rendering. Having a forwarding reference allows a reader to use the reference links to jump directly without looking at the ToC. IMHO it is useful, the readability is a concern perhaps in plain text, but even there section numbers help rather than looking for section headings.
[KT2] Sure. I will add those forward references 😊

> - Section 2, 2nd last paragraph, should this be normative regarding the different behaviour for underlying IGP and BGP-EPE?
> [KT] I am not sure that I understand. Could you please clarify exactly what normative text is required here?
>

I meant, think of using RFC2119 keywords - MUST/SHOULD etc.
[KT2] This document is just adding new information - the procedures for advertising info from IGP and BGP-EPE have been normatively defined in the base RFC7752 and BGP-EPE drafts.

> - Section 4.1, need reference for IGP Algorithm Type registry [KT] The 
> text already points to the IANA IGP Algorithm Type registry where there are references for the spec that is introducing the new algorithm types.
>

A reference to RFC8665 is useful, as that is the place where this registry is created.
[KT2] The algorithm was defined in RFC8402. RFC8665 only defined the registry for it. Now with Flexible Algorithms and potentially others getting added down the line, the pointer to the registry seems to make more sense to me.

> - Section 4.2, add the tag Neighbor ID in the figure as well to match 
> the text [KT] Ack
>
> - Section 6, we should say Protocol-ID is from RFC 7752, of which the following are applicable for SRV6.
> [KT] RFC7752 does not introduce BGP - it was introduced by the BGP EPE draft. So perhaps we can just refer to the IANA registry for Protocol IDs instead and remove the list from this section in the draft?
>

You can say something like -> the Protocol-ID registry was created by [RFC7752] and then extended by other BGP-LS extensions. The following values are valid in SRv6 -
[KT2] Ack - will update that and remove the references to the list.

<snip>

> - Various MUST conditions in the draft, but no idea what happens when they are not met. Is this the legacy issue with RFC7752 and we need to wait for the RFC7752bis?
> [KT] Ack - the fault management clarifications are being introduced in RFC7752bis. In brief, BGP-LS does not perform semantic validation of the TLVs' contents.
>

Worth adding some text, I am sure directorate/AD reviews might have the same concern.
[KT2] Agree. Will add that text.

Thanks,
Ketan

Thanks!
Dhruv

> Nits
> - s/Segment Routing IPv6 (SRv6)/Segment Routing over IPv6 (SRv6)/
> - Expand SR, NLRI, MSD, DR, DIS, on first use.
> [KT] Ack - will fix this.
>
> Thanks,
> Ketan
>
> Thanks!
> Dhruv
>
> On Mon, Nov 2, 2020 at 8:55 AM Susan Hares <shares@ndzh.com> wrote:
> >
> > 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%20
> > im
> > plementations
> >
> >
> >
> > 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
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr