Re: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)
Linda Dunbar <linda.dunbar@futurewei.com> Wed, 14 September 2022 16:58 UTC
Return-Path: <linda.dunbar@futurewei.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 9E30FC14F732; Wed, 14 Sep 2022 09:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level:
X-Spam-Status: No, score=-7.011 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5SIztaOr_xd; Wed, 14 Sep 2022 09:58:46 -0700 (PDT)
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2137.outbound.protection.outlook.com [40.107.94.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACCBBC14F72A; Wed, 14 Sep 2022 09:58:46 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CWIssYrm0VUo7TMEr/kYCUzXvP35suQsfYdkHCnVsGPMqBQTzQoPjV0jIqgl4nY6DKihBmzsFScRtlZfxo6/3Rx0HW9EVpPSeRh0fCRPjZt9lLwSr94MZlmDBxuKly9djYAT7dU6ilgZdN12FFFZgvkDOnBAzm+TqPRA2+hMCADVyl4CjpI/q4N0L0JpzhgPybmgkejRqvwPSpU1+uR8EEiZnClOuE1Bdu57FzHh1EpSdeXVxSPlB4RV8Fr8dSn2sxN6e1dxtZNeZ3rWIVAWJtQysS6sfnUCIR7vS6WIgiV7i6SnUCA9zlj1SMTghLl4o0y3ctDsicHo5Ad7mozsGg==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=11ZgY04a58vTPMmxdtGxCUtJc9fQeDVx1ARaSQC0XQY=; b=RUMNuOYTvF1AcENC3xFSzbrIALeX/hl+zd/1ccTb7RaiXb2mVdXzTrsxT4G6ifqfMbeUzDLjQzVh+tEr3CtkAdbYLMw0HmEG/s8R0q8OAuULxQKbGK/if/uj8epP8BZaVCMb7w4WFLvdWLnoNHGb6okOJH++p+D3WSFxXtoDVXunX1EPvF+tCMEdhkJ+SwTFbtsIkf1gUUrbg3B6V1KwPZ8PTQvHEWkOvWlqHxeeLUf8CjxL1w87reDaXE0Dr2tDvHgZzJ9X39GhdrLgik2PUqFey6BS/IG7Eaz+7IzE3vgrv7+TpqC1apcmDvSiMmiT/gL/VnXTGbl/Xzk1y/OSbw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=11ZgY04a58vTPMmxdtGxCUtJc9fQeDVx1ARaSQC0XQY=; b=AQJ6ZvM21Fb73hRy3U4sn3scF5SBJP2Lo9cRDh4JP3eFvLUTnebVI4iBtyAQ75VKBdQiU1syaDzwi1RqjZv2+X0ZGZFVxGA6B7F1twm7WyZIKs7dcVzdF67X4AGKn3M7XeMDnhEAtLUC/25cCxT6qZf5OY0ObbhfbbzvrXlkpXs=
Received: from CO1PR13MB4920.namprd13.prod.outlook.com (2603:10b6:303:f7::17) by PH0PR13MB5268.namprd13.prod.outlook.com (2603:10b6:510:db::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5632.12; Wed, 14 Sep 2022 16:58:42 +0000
Received: from CO1PR13MB4920.namprd13.prod.outlook.com ([fe80::f7e8:d63b:681:a0d3]) by CO1PR13MB4920.namprd13.prod.outlook.com ([fe80::f7e8:d63b:681:a0d3%5]) with mapi id 15.20.5632.012; Wed, 14 Sep 2022 16:58:42 +0000
From: Linda Dunbar <linda.dunbar@futurewei.com>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, Susan Hares <shares@ndzh.com>
CC: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)
Thread-Index: AdjCLr/gdp6Uy8yETEiboMJ0QdDUtwBUajGQADhUFoAAjsuGUABvZ3Ww
Date: Wed, 14 Sep 2022 16:58:42 +0000
Message-ID: <CO1PR13MB4920302EC3CAFECFBE79CB1485469@CO1PR13MB4920.namprd13.prod.outlook.com>
References: <BN7PR08MB48688D62F43E023CEF6CA810B37E9@BN7PR08MB4868.namprd08.prod.outlook.com> <15676_1662646797_6319FA0D_15676_371_1_98d7b3e0495f4653bfcfc6be0b21b6a2@orange.com> <BYAPR08MB48725820873B5F22FEB478DFB3439@BYAPR08MB4872.namprd08.prod.outlook.com> <32417_1662984536_631F2158_32417_242_6_3dce5ac3c35549c4b635f4cc5a162f16@orange.com>
In-Reply-To: <32417_1662984536_631F2158_32417_242_6_3dce5ac3c35549c4b635f4cc5a162f16@orange.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-09-12T12:08:54Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ActionId=f9034a6a-275c-480b-9565-0def109c14e4; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CO1PR13MB4920:EE_|PH0PR13MB5268:EE_
x-ms-office365-filtering-correlation-id: d234ac0b-9eeb-4d66-8abd-08da96726120
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 8kev4eWG1VuKIHOwsDbDhWRV9QnRqab4N3ZzZEygj7tyxVJr0fK41DoSSsFN1bLgOWijI/KG0Xosvs5vMybH/myZ/GttIn6wLjMm/1LzZ4IXLCnOK79fwrwJWg8IFqxZBoptxHbJthcx2QoApn7M6i/uXUcPZT/RDqVSnKeeeCg+mrQ4T7QFAjQxRNzC3xRfjG/Yf8RZ6llL5vytYtZgr5ha6OtmiaLkjnPer925bAKunVJAzg5uBnDLf9fqjVlTsn3dotIQh3WPzMltOBWhVkwWVZQ9T9z6yKjS1+yS5/aYDa+2uzimIWFyudV5TNZ9tfjfXRJeCmqNF4Lx6pMVRcPTJnFMNj7HocKiez0p5bglli79BDIVLuBpepWqR/KMpGAb+EDHM7x9+y/8etKhxyTRPkJ9fL+YmTv2BgXRzqJOpqyyPwmsCMPsWRzg0h+I9mjZBWgqfIN1B4jeFWndGFr9u8B3m55+1tiZ5exXhuqOtulV1p9ieh3Hng4y4TxNhGzGSbSA6Ly+eaKZbwa/jRBDSXWMDBoHP45M1GDFtcBN9hHGunUTn96214JhxZaXwV4ONT69no+BEf13F3IVE1Ha9g47y3AvAgjQsvkvT41D/06DRqARPCazUymyeSiLwdc06MmBFiVeqBiKc4BwAotU82NdByGqmBNkZHF95h1c/7UkOYRCiQk7dJ/14NgrS7NOXJe5P4ztC+omylJt5ouNUyos3MFWVNMmth14R14y4473UE0Dz95L4cyC8IQJDjVt4+Qx/2IvXg4V8sQ+hW1VY+50Mw3aAvuDPBymNrsld/wWo73i6bkH4JtcMTY90oseJe7PXi6secgq2LZ7tw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR13MB4920.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(376002)(39840400004)(136003)(366004)(346002)(396003)(451199015)(9686003)(66574015)(38070700005)(38100700002)(110136005)(83380400001)(54906003)(6506007)(316002)(26005)(53546011)(966005)(478600001)(186003)(33656002)(66946007)(44832011)(2906002)(66476007)(86362001)(76116006)(66556008)(166002)(5660300002)(55016003)(66446008)(7696005)(30864003)(8936002)(122000001)(8676002)(4326008)(52536014)(71200400001)(41300700001)(64756008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: /nw2lhdB2kjCUdrzlIsiZ4z1dpHhtAQmFTZWoVMjeiLDqo1uVs+eBfzNNSfYRe9SK4w2mKCwjIw2BfdzQ1GY+1sZDXgb3HoAxIa8jYeYgxNe6Iu1FqBfjdNMugzE7VBcXZxVsS2CIqqE4nDbNsbF464OtEm7zeLBRW0Av+pPhWTRtM43/r0xFXeMFzKtbNs/lkV7dEJlYbDvz5c/klBhXdBVffld+DU/rYvZwekIcSBFJThOLktgUeK2nUnQyWVtiJpNMzghvYsANZng94HFH/TKqng3qyLnyYhVikB4mJj37vjRdxgruEBGYgGxhYWUWjvCc/Z8I95H0A7bX45t0JN2HAddqCUF29c4ZQ/6mYcsJfe1FoHfQ0qVjfZ3XZXh7thIOgLUkkO2IMHBgJUiHBfomgwGA1zIzCtuh+c0Agzq2AZMyrCm8sC4wxVO3reTZtVvMc/BK9cdv8Bm5BcMfq2BejGeMDCVlx8JYfXKlZMQIFtTTn30e0s2P35affCKmZ6UmLC1ur0irocTW/B0t6dfF+KekiqhanlixZTyzDCDLXg2tBiofisp0jeMQD6O60L+RnDDrOfIr2S/hVdLnJ91UUSHWswgmTEKnQX1tWGsuNuhaug5GROeThphJstngt1Nd163LHugCsBcBqtMppgyw3iijjpJJNx4XRw52QJKlNXejK+w82jmC/IA/dNjYlshFG/zbCcWWSfvBSAvjZsGAWFkdsNf0LS++3bl5wJssU/lZZcZPJBfkGuKG5smjQUujq0WnsUDEH5AHj51LPc5vamYHqzVcj4V9F8y/vPfIVn+1p367Jt+cIM1ManyD0wWTsJgltwPz+VoStSKVS44qvAU0wEVMUqthsrTlOVhHL30RkHHQ5Cs+RmVbRpSvBPttAV/Ma1JPLMuNDLF84FmyAr/43TtDuuAkf4Z6t2iTbC9ItsWNwsvoueVsPiv9+uYJ0NE0FEmqnVo7mx5TDMCsukE3L2SavoAA8XFMTfpByQROPMyWv/sUqHzDrdOiVdC/wa4+UxDDUegLPO5eK1OM6wpZ6bzKSij/bwILGUetPuW/mvl9CMAbkIY3/7Q0Q2sW1f63ug9K5zVcPvnby26RWCgD42Xfb6tR4MiV69wG1MI9TZvR8+DQ7iRDfcS7sPduRQqOSDe8pgSItx5kSjMelJqprjz+N5RPEU8dQxnmq2kqpRcqDzbhowhwc5zXpwqFYVi2eBLcfwg0KYjVLOGbN5Rwa7In9Q6WdiA61s1eyYTz2vR/lOpa/xnTevN6K8F4BGYG/78Be5oATPlXrmhs0tWIFdBEu1fD5ioflZuEsJXqyFOtIINLVgwppkBrcPDbYG9bh43LsBA3AMrdsqDZwASdBIzRUXHdpeuPH1q1Z+QIvQeR53C904D5OMjHdwCAvsfPMbnmi0d402DeCQ0TAmZ6kvRxr11oxYuPI3mmBTaK8P75GQKgDG+mP8VnQFQNkSawRBs1QQxu5id3Y03Y4wKR2uEDVvvZ3193GCFiw5mPN/q4WpddpRQxl80F9ohpQXV+/i/0lj6CNhr5q72XCaze7esk7wPGtr9mzxwAAQu57yyW6NuSw1cIjPR
Content-Type: multipart/alternative; boundary="_000_CO1PR13MB4920302EC3CAFECFBE79CB1485469CO1PR13MB4920namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR13MB5268
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/tBY-5QP8nvgZzHQo8Ag5_SUR8LY>
Subject: Re: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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, 14 Sep 2022 16:58:50 -0000
I support the WG adoption for draft-scudder-idr-entropy-label-01. After reading through both draft-ietf-idr-next-hop-capability-08 and draft-scudder-idr-entropy-label-01, I think they are different, and doesn't need to be merged. The draft-ietf-idr-next-hop-capability-08 is about non-transitive path attribute, while as draft-scudder-idr-entropy-label is about transitive path attribute Linda Dunbar From: Idr <idr-bounces@ietf.org> On Behalf Of bruno.decraene@orange.com Sent: Monday, September 12, 2022 7:09 AM To: Susan Hares <shares@ndzh.com> Cc: idr-chairs@ietf.org; idr@ietf.org Subject: Re: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022) Sue, Thank you for your clarification questions. Please see inline. Orange Restricted From: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>> Sent: Friday, September 9, 2022 8:09 PM To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>; idr@ietf.org<mailto:idr@ietf.org> Subject: RE: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022) Bruno and John: The target for the adoption for draft-scudder-idr-entropy-label-01 is a bis draft for [RFC6790] to fix a bad RFC. The IDR chairs did start this call for draft-scudder-idr-entropy-label-01 to compete with draft-ietf-idr-next-hop-capability-08.txt or other drafts regarding next hops or bgp attributes (e.g. draft-scudder-idr-entropy-label-01 as a "bis" document). Thanks for the info. Why is there a desire from IDR chairs to bring a second solution (draft-scudder-idr-entropy-label) to compete with the first (draft-ietf-idr-next-hop-capability)? - Is this that in general two solutions are better than one? - Is this that the WG expressed comments/limitations on draft-ietf-idr-next-hop-capability? Bruno argues that it would be better to include this in draft-ietf-next-hop-capability-08.txt as a fix. For this shepherd to monitor this portion of the adoption call, I need John and Bruno to provide additional input: John: you need to address Bruno's comments on "So ELCv2 is not to be used. But this draft is more or less saying the opposite in Appendix A, therefore I object the content of Appendix A. ELCv2 is a proprietary solution. Migrating away of ELCv2 may be handled without the IETF." Bruno: if we are going to consider draft-ietf-next-hop-capability-08.txt as alternate short term fix to [RFC 6790] I need to know the following: Why do you say that draft-ietf-next-hop-capability is a short term fix, while it 1) fixes the problem and 2) it provides a generic tools to advertise BGP Next-Hop dependent capability which will be needed for current MPLS WG evolutions (In Stack Data, Post Stack Data)? Why are you considering draft-ietf-next-hop-capability as the possible alternate while it's the solution been adopted by the IDR WG. In my opinion those qualifiers "alternate" and "if we are going to consider" would better apply to the recent individual draft (draft-scudder-idr-entropy-label) 1) Do you have a specific proposal for adding this fix to draft-ietf-next-hop-capability? If the WG express the need for a non-transitive BGP attribute in order to avoid the software upgrade on the RR it seems straightforward for draft-ietf-next-hop-capability to replace the non-transitive attribute with a transitive attribute recording the latest BGP NH which has modified the attribute. I don't recall such request from the IDR WG. 2) what is the implementation status is for draft-ietf-next-hop-capability-08.txt. [how many implementations and how many features]? I'm not aware of any publically announced implementation. How MPLS transitioning away from "Entropy Label for the New Thing" does not really impact a "bis" draft. The focus here is publishing a fix to a broken draft. - If the focus is publishing a fix for a broken draft, we already have a WG document for this: draft-ietf-idr-next-hop-capability - IMO, as we know that we need the signal more than ELC, it looks more futureproof to work on a generic solution. draft-ietf-idr-next-hop-capability provides this generic solution, draft-scudder-idr-entropy-label does not Thank you, Regards, --Bruno As shepherd, I expect that John Scudder and Bruno will answer these questions as part of their upcoming posts. Cheerily, Sue From: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> Sent: Thursday, September 8, 2022 10:20 AM To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org> Subject: RE: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022) Sue, Orange Restricted From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Susan Hares Sent: Tuesday, September 6, 2022 10:32 PM To: idr@ietf.org<mailto:idr@ietf.org> Subject: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022) This begins a 2 week WG Adoption and IPR call for: https://datatracker.ietf.org/doc/draft-scudder-idr-entropy-label/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-scudder-idr-entropy-label%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C046598604686445ef38508da94b79da3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637985813628492667%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kYzIuZlTA6P3Zuana%2FBuNlz%2BJ%2FjKYEQ4zDIANKpQaJs%3D&reserved=0> The co-authors should respond to this message with an IPR statement. The specification revised the BGP attribute for Entropy Label Capability. The abstract of the document states: "This specification defines the Entropy Label Capability Attribute version 3 (ELCv3), a BGP attribute that can be used to inform an LSP ingress router about an LSP egress router's ability to process entropy labels. This version of the attribute corrects a specification error in the first version, and an improper code point reuse in the second. 1) We already have a solution for this; an IDR WG document. https://datatracker.ietf.org/doc/html/draft-ietf-idr-next-hop-capability-08<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-next-hop-capability-08&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C046598604686445ef38508da94b79da3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637985813631148353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=238a24ykF8LTxeGGepufCs44uLZBP1Mu%2Fsr92uiqLhU%3D&reserved=0> "This document also defines a Next-Hop capability to advertise the ability to process the MPLS Entropy Label as an egress LSR for all NLRI advertised in the BGP UPDATE. It updates RFC 6790<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc6790&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C046598604686445ef38508da94b79da3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637985813631148353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cW57FHhk83QWPXMfluiNxzAwuTjb3Jj4MqVW8hEcjLw%3D&reserved=0> with regard to this BGP signaling." I don't recall that the WG expressed an issue on this solution. Nor asked for the use of a non-transitive attribute. Now if there is a compelling reason to use a transitive attribute, this can be discussed by the WG as part of regular WG work on draft-ietf-idr-next-hop-capability. If needed, both drafts may also be merged. 2) Initiating a technical comparison of transitive vs non-transitive attribute: Non-transitive: - require the software upgrade of PE, ASBR, RR Transitive: - require the software upgrade of PE, ASBR. - require the re-implementation, test and debugging of the non-transitive-like filtering. All in all, small gain in term of deployability at a small cost in term of implementation. Obviously, "small" is in the eye of the beholder. Regarding software upgrade, the only difference is the BGP Route Reflector which: is a small number of nodes (typically at least two order of magnitude smaller), control plane only / no impact on customers, typically centralized in a very small number of locations, control plane only so very possibly we are talking about a VM or container. I would not call this a 'forklift upgrade'. Again, this is a discussion that we can have on the WG document that we have (draft-ietf-idr-next-hop-capability) 3) lack of feature coverage draft-ietf-idr-next-hop-capability is a generic tool allowing the advertisement of different kind of BGP Next-hop dependent capabilities. Entropy label is one, but the MPLS WG is currently defining new data plane features (In Stack Data, Post Stack Data) which will require to advertise different type de capabilities, possibly with related parameters. Therefore the general tool is needed. (and some people in the MPLS WG have even proposed to deprecate the Entropy Label for the New Thing, so defining a new BGP Capability just for Entropy Label may seem a bit late). There are other usages for other dataplane such as IOAM (another IDR WG using draft-ietf-idr-next-hop-capability) 4) In all cases, I don't think we need two solutions for this simple problem. (the operational differences are small, a few %) In your comments consider: 1) Does this specification fixes errors in versions 1 and 2? 2) Are there any additional errors or weakness in this specification of version 3? For example, has this specification clearly described what happens if version 1, 2 and 3 exist in a network? Not really. As already expressed on the list, what happens if ELCv2 and ELCv1 exist in the network is BGP sessions reset with a major impact on the network. So ELCv2 is not to be used. But this draft is more or less saying the opposite in Appendix A, therefore I object the content of Appendix A. ELCv2 is a proprietary solution. Migrating away of ELCv2 may be handled without the IETF. 3) Will deployment of version 3 of Entropy Label Capability BGP attribute aid in fixing problems in current networks? 4) Are there enough implementations that this draft should Be moved quickly to WG LC? There are no implementations of ELCv3. Regards, --Bruno Cheerily, Sue _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
- [Idr] WG adoption call for draft-scudder-idr-entr… Susan Hares
- Re: [Idr] WG adoption call for draft-scudder-idr-… John Scudder
- Re: [Idr] WG adoption call for draft-scudder-idr-… Serge Krier (sekrier)
- Re: [Idr] WG adoption call for draft-scudder-idr-… UTTARO, JAMES
- Re: [Idr] WG adoption call for draft-scudder-idr-… Bertrand Duvivier (bduvivie)
- Re: [Idr] WG adoption call for draft-scudder-idr-… LINGALA, AVINASH
- Re: [Idr] WG adoption call for draft-scudder-idr-… Donald Eastlake
- Re: [Idr] WG adoption call for draft-scudder-idr-… Satya Mohanty (satyamoh)
- Re: [Idr] WG adoption call for draft-scudder-idr-… Gyan Mishra
- Re: [Idr] WG adoption call for draft-scudder-idr-… Aijun Wang
- Re: [Idr] WG adoption call for draft-scudder-idr-… bruno.decraene
- Re: [Idr] WG adoption call for draft-scudder-idr-… Susan Hares
- Re: [Idr] WG adoption call for draft-scudder-idr-… bruno.decraene
- Re: [Idr] WG adoption call for draft-scudder-idr-… Linda Dunbar
- Re: [Idr] WG adoption call for draft-scudder-idr-… Gyan Mishra
- Re: [Idr] WG adoption call for draft-scudder-idr-… John Scudder
- Re: [Idr] WG adoption call for draft-scudder-idr-… Gyan Mishra
- Re: [Idr] WG adoption call for draft-scudder-idr-… Susan Hares
- Re: [Idr] WG adoption call for draft-scudder-idr-… Susan Hares
- Re: [Idr] WG adoption call for draft-scudder-idr-… bruno.decraene
- Re: [Idr] WG adoption call for draft-scudder-idr-… Susan Hares
- Re: [Idr] WG adoption call for draft-scudder-idr-… bruno.decraene
- Re: [Idr] WG adoption call for draft-scudder-idr-… John Scudder
- Re: [Idr] WG adoption call for draft-scudder-idr-… Shawn Zhang
- Re: [Idr] WG adoption call for draft-scudder-idr-… Susan Hares
- Re: [Idr] WG adoption call for draft-scudder-idr-… Aijun Wang
- Re: [Idr] WG adoption call for draft-scudder-idr-… Robert Raszuk
- Re: [Idr] WG adoption call for draft-scudder-idr-… Aijun Wang
- Re: [Idr] WG adoption call for draft-scudder-idr-… Robert Raszuk
- Re: [Idr] WG adoption call for draft-scudder-idr-… Aijun Wang
- Re: [Idr] WG adoption call for draft-scudder-idr-… Acee Lindem (acee)
- Re: [Idr] WG adoption call for draft-scudder-idr-… UTTARO, JAMES
- Re: [Idr] WG adoption call for draft-scudder-idr-… Aijun Wang
- Re: [Idr] WG adoption call for draft-scudder-idr-… Gyan Mishra
- Re: [Idr] WG adoption call for draft-scudder-idr-… Robert Raszuk
- Re: [Idr] WG adoption call for draft-scudder-idr-… Robert Raszuk
- [Idr] 答复: WG adoption call for draft-scudder-idr-… Aijun Wang
- Re: [Idr] WG adoption call for draft-scudder-idr-… Susan Hares
- Re: [Idr] WG adoption call for draft-scudder-idr-… Acee Lindem (acee)
- Re: [Idr] WG adoption call for draft-scudder-idr-… Susan Hares
- Re: [Idr] WG adoption call for draft-scudder-idr-… Aijun Wang
- Re: [Idr] WG adoption call for draft-scudder-idr-… Robert Raszuk
- Re: [Idr] WG adoption call for draft-scudder-idr-… bruno.decraene
- Re: [Idr] WG adoption call for draft-scudder-idr-… Robert Raszuk
- Re: [Idr] WG adoption call for draft-scudder-idr-… bruno.decraene