Re: [Teas] [Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-isis-rfc5316bis-04: (with COMMENT)
t petch <ietfa@btconnect.com> Thu, 22 September 2022 08:39 UTC
Return-Path: <ietfa@btconnect.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB4FC15258C; Thu, 22 Sep 2022 01:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 jYNivDwoKCac; Thu, 22 Sep 2022 01:39:03 -0700 (PDT)
Received: from EUR03-DBA-obe.outbound.protection.outlook.com (mail-dbaeur03on2090.outbound.protection.outlook.com [40.107.104.90]) (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 DA6B7C15257F; Thu, 22 Sep 2022 01:39:02 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H5mxM8TEP2FdJisNAoMPdS4qeXQuW8B6htSUFqxW0kNHGslwlfV4DNOO/d8G8NPyPQe2ObXJWEv/AtexcO592oTRfV8p4IaqJsjfhVT8kXWMWCykLDtEr01aRG7WqVSkP0iyvzXQORvwoUtWSL/er3AaTy9UK3ETwSyoLfgHMzOX3ctPiIdnMLSa2jXkiuwlEPkDgI5AFSmWAbAAhZguvKx6jJQM6wAA4WKBBs6RHzCfGJ8keT353sSjV4t1MJc3Fjx7rCImHaqu5ATWehm2c5sgy1h0kr+hCXY36IWFK9Qdjj0iX9KSEZkSwF0BQolwPZXdGBw/Ykz+1jNBiICq7Q==
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=YRmi4Ab4TaUG3TokADL3BswXGNHMPAbjN0PVmKX8ZHQ=; b=RNWFG0nr2TOBES1gq2VckQasY7b2407F6XY9W9V6ZK1LPiki98T3h53oeNcmCUv3LHNagEZG9aBYJvEJbwRuEx1TMJN8a3RrZU4+7KLPGuYHvQAZ4ZGQeKGCQkDuJ2BBVSVVuzKIHUvHzl7zr7xe0hxYfwCM7/8GoL86w10qK0NSYb9FzZyWgwhjNH0JIKZ9D5efQULwqWTp0EtEA3yBkcqPklJU5rvt7m6O5ldL7NUIBbco5wzsDIEQHdzV62YTauiEcuroi2c4D8CpJzIbKi/yFtBLZAgprbByWfctPpC36yOBGV8Njc/NmZpk0b4fDhcZUsZEmtd4VVWwhje8wg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YRmi4Ab4TaUG3TokADL3BswXGNHMPAbjN0PVmKX8ZHQ=; b=RIwFV5yjRZofPZg8yKcOswDT+3v+Yig/EJb0g9uSu+q2p8JCV8ACIjCoN2CvJERKvR/5ixeFkEapJ0odyJxfSpMtJGn/VhC/fFlIYq2yfJdyj6KdOK6thMgS+i3mISV1nfjeH/q0BhP4jJZ/aYSDU7B37cAx0qYbNbbrYVeKxN0=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=btconnect.com;
Received: from DB7PR07MB5546.eurprd07.prod.outlook.com (2603:10a6:10:73::23) by PAXPR07MB8844.eurprd07.prod.outlook.com (2603:10a6:102:24a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.14; Thu, 22 Sep 2022 08:38:59 +0000
Received: from DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::30b8:4c51:9347:149c]) by DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::30b8:4c51:9347:149c%6]) with mapi id 15.20.5654.014; Thu, 22 Sep 2022 08:38:59 +0000
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, John Scudder <jgs@juniper.net>
References: <166331686368.59474.12583201274811500459@ietfa.amsl.com> <C817A43A-B2DE-4E5A-91DC-AB77B8CC15AC@juniper.net> <63249C90.30208@btconnect.com> <BDA872CB-3921-4542-AE94-52BA866755C6@juniper.net> <6324A630.8040401@btconnect.com> <BY5PR11MB4337BEE7704893FDAF4649C4C14F9@BY5PR11MB4337.namprd11.prod.outlook.com> <632AEB28.3040202@btconnect.com> <BY5PR11MB43375F9638F63D90F3244D10C14F9@BY5PR11MB4337.namprd11.prod.outlook.com> <EE745271-4AEE-4406-9DB9-4036A871A2B8@juniper.net> <BY5PR11MB433785D5706954B630449AE0C14F9@BY5PR11MB4337.namprd11.prod.outlook.com>
Cc: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, The IESG <iesg@ietf.org>, "draft-ietf-lsr-isis-rfc5316bis@ietf.org" <draft-ietf-lsr-isis-rfc5316bis@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, lsr <lsr@ietf.org>, "chopps@chopps.org" <chopps@chopps.org>, "teas@ietf.org" <teas@ietf.org>
From: t petch <ietfa@btconnect.com>
Message-ID: <632C1F2B.3040405@btconnect.com>
Date: Thu, 22 Sep 2022 09:39:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: <BY5PR11MB433785D5706954B630449AE0C14F9@BY5PR11MB4337.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO2P123CA0090.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:138::23) To DB7PR07MB5546.eurprd07.prod.outlook.com (2603:10a6:10:73::23)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DB7PR07MB5546:EE_|PAXPR07MB8844:EE_
X-MS-Office365-Filtering-Correlation-Id: 1cc1ff82-dc25-4c76-891a-08da9c75e4ad
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: u2tBFJ6cVzHNy6tC1bk0RP21YmHko+c+4DeqlEs9a7qcUKd5J8rRoRDFjNABpd33K5f1f5XJyrIOj8yjA3PswdwcDVlVppopdiI/v69voUuj9vyhxU1ctkLxVdYB4NpYO/hTyT9ak7yhkxA/7XDi5qrGjHxZ2HnY7KEBkVhm1zMU0mrVMCBEmUYDFZhOU0qVRauLaHlkiE+hPEZCEBNdVRolKcdl3aZLsIspf5e9Y1H/bOmCOAPO1qksj6c8IQ1uymun9s5HrH7I6UqlTJSfBwsx2lyzC3IOuDEfGGSVlFD00rNMkZNh2z70a5KVhxT74Zp2Z+8lkaRli2kqVA2ysK5AdHXdGxN30lEnC+c7LU7cdgC+wHcfTvc6K9zNycyj3On5QzSIlhs/0kgg8OeCBuwJAWG7MRnWT7U0kdgh/IUjr6hM69qdAH8A8RssEEyIlLVNWMWG5wKnAz8IGFRpBFYfBFgs3WI6OVdrH+Pger7k+bAaHP5ZHzQl1m3G3c0rqrWEY7HMtj0ve3l73GMSIP6FWOe/sq9TTtKqVHwy39bjn66VyO/5Q66T6oWCCn+576R6Nw0prfXU1xMP4pNHCwdYdIR1btot73DEDYMdOUZVuh+IBMf/O8TXgY4hI4AXJUUMH1SNBPHzvzAd9wFFshGyK5f/ozlQ7E193lDIVT+zjOETTtW5PdtnO0BMYd5yUrdbQKEx13ztWgM8t6YOhqpeT2m10XMKz8Ldly3RKk74RBSLYVIH4B4CtO7Z6/jQ81ty3MOYBD8mjnGI5VDdTQ==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB5546.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(39860400002)(366004)(376002)(346002)(396003)(136003)(451199015)(966005)(478600001)(6486002)(53546011)(87266011)(2616005)(6506007)(26005)(6512007)(41300700001)(6666004)(52116002)(186003)(2906002)(66574015)(110136005)(66476007)(316002)(54906003)(30864003)(4326008)(66556008)(8936002)(66946007)(5660300002)(38350700002)(38100700002)(33656002)(83380400001)(82960400001)(86362001)(36756003)(224303003); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: eFKlMsZKKH9l/rznn9MZobd7xo5Rr14hW/j9DvnAWlTAk2aGKOtPHYf0CmWWOb3tZWBTX2L8pgs58On03bPViD3kJOcTXdC7edZkuROphecFPRRDjT8SQ0AZq6o2O6uNcoClK4VvjXu01F6L3Un/uLWrrezPkhXmq4trhq2YJJY/ICHTa0b0I79yKIEwzUt7PA0Bm7gINMi0cdUppjyKU9c9Lp1NicUZexGjPSFFpwgaiUtAOlNdvWulRQY4mI7pp1sF10A/fmRqsH+G2yfkulqfMXdf2sqku5Hj8wEJLrGj7Q4Phdf4Jv1mkm3bGHY964ZCLY9dYu9m/oiZHDEOmG2LkOqFl2Ymh5ZXYuIMdfcBtNgIHIpvnQhcSl23d+1msaCpgnIZGWq8i3FiBrDTJ1swBPC4+s/LLWtMw5KSiFL79+p/EyWYNA2z+adHwsZ/Uks/H0mS2OW1vM8evaGPqg5cA8XnRsLE9KUr7jryz9dH+dc6EiNbplAIDzEEUBm/4OFlm3EqeAF6CbLVh8XN3F0qn2D9UwmItTbbYQAF1jIhsAVDQPrLrARJ6wnhC9Ueyw+EsL02xz9vBZtenkVzUuGVJS4hKAZa3Iec0lMYzRSjoyktkuBBkFQJQM5a7yxHuKyTPCOImXAaGs0CbwgJhs7zNo5Bd+JRmCyLM469oSBlEfgIVdfFz+ZR1XZwNLMWOJq7Oosv8Cc6GMj/ntlv/PWl0XOKeffD4LH0kI6CtZCuSOtg4Nmz7/M0pmhEu8v8+A931+j5VisH0tHtVKY2ShDhtwEdQ0AOJ4gh9VZI/ptKWLZwRUimTxUrf0FDmmAKKfy+IZW4JQi/N7stjqcRfv65ufbDeA8ctTSb2VjiOB9IvRCF86julNKsTWUdfHy+NisZuDQRRezNQTB5hJ0evrLt18zNo0j5cJKRgcxNX16hzvQhqDJ7TNDFC7pITE+Yyv38KMR6LYbjhSmlfcjfvYEx7Srr2ps7HQTeNHFtCBN/lgm3s5j5XPACMK1kaxVo5ZTEoCDXupuwfGM7/OcjOYrZVlLgdIG1UsnizBn19N8fWR9XqFWSdpjo2O17D2FYOAaaCRMbu4fDIAy634nmB7LSrTFXGv5z1Px4ZwQn7d4hoGc6tzotEU7+Bny74T2cswIFDwz8HyIDIqcA2nxOSD9oEzLQzUO9ds9PeNPOPx/EYI3N1ShAFU4HUJlXiTP+ZixSZepi6h9+WQeoOI72yRHJI1swbY03ch8WNkIAOtV3PPiS0P9SOvfMM73b9lKoSASdTZZZ+qUN1RN5x8XZS/tyG2dTpRc8F4EMcOAMXfltKzjq/xiLUoWADk1/knXEiHvsOT23Vyvg2GNAg4e/CbqpPL9bPOmOddemHr4GFDx6Uf23++XEuCQNkoG5h4kZc+d5Mil7JsSnIKAmuFPfz3zilI3WGi1W3wDoHge9X2Wp7yMbZoZL1KpRbrHoChgMxZmGRW4fGflWN3HBVP7Noz439wxomVHuxoGcRyK4ircMQLY2oqYq8V/7DjzFMM3j4utXEYivZlTU/1suxwlwquHsNrtqAxrPvYcSY5T9T/KbnIiL7SpgeqTMV0/I2Lq2
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1cc1ff82-dc25-4c76-891a-08da9c75e4ad
X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB5546.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2022 08:38:59.0687 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 3gzTq6GfVPj/wKtyrNXbkqhljBz/zWiXgCc1nVYSsIeZUXUBowZ8drVMu3rFHSTTbznY4Ozq+GZ45rPlktnB3Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR07MB8844
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/CGPOyYJwyBHXrBo31lW_FzGr-iY>
Subject: Re: [Teas] [Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-isis-rfc5316bis-04: (with COMMENT)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Sep 2022 08:39:08 -0000
On 21/09/2022 19:15, Les Ginsberg (ginsberg) wrote: > John - > > Thanx for the thoughtful suggestions. > I like your last suggestion i.e., simply removing the phrase > > "which contains the IPv4 Router ID of the router who generates the inter-AS reachability TLV" > > Hope that works for everyone. Les, Yes, looks good to me, Tom Petch > > Les > > >> -----Original Message----- >> From: John Scudder <jgs@juniper.net> >> Sent: Wednesday, September 21, 2022 7:44 AM >> Les, >> >> If I read Tom’s last comment correctly, the entire substance of the change >> he’s suggesting is: >> >> OLD >> which contains the IPv4 Router ID of the router which >> NEW >> which identifies the router which >> >> That seems reasonable to me considering that as Tom explains, the “IPv4 >> Router ID” is *not a thing that exists*. The “TE Router ID” exists, and you >> make the case that it should probably have been named the “IPv4 TE Router >> ID", but that isn’t what the text in question is referring to. Why would you >> *not* want to make this change, which seems to be both accurate and >> harmless? >> >> Based only on the text shown in the OLD/NEW one might also suppose you >> could correct it to “NEW: which contains the Traffic Engineering Router ID of >> the router which”. But taken in context of the overall paragraph, that doesn’t >> work: >> >> The Router ID field of the inter-AS reachability TLV is 4 octets in >> length, which contains the IPv4 Router ID of the router who generates >> the inter-AS reachability TLV. The Router ID SHOULD be identical to >> the value advertised in the Traffic Engineering Router ID TLV >> [RFC5305]. If no Traffic Engineering Router ID is assigned, the >> >> The sentence after the one in question says it SHOULD be identical to the… >> TE Router ID. Which is the exception that proves the rule (that your text >> “IPv4 Router ID” must not be referring directly to the TE Router ID). >> >> Another fix could be to simply remove the clause in question, as in >> >> The Router ID field of the inter-AS reachability TLV is 4 octets in >> length. The Router ID SHOULD be identical to >> the value advertised in the Traffic Engineering Router ID TLV >> [RFC5305]. If no Traffic Engineering Router ID is assigned, the >> >> Thanks, >> >> —John >> >>> On Sep 21, 2022, at 9:49 AM, Les Ginsberg (ginsberg) >> <ginsberg@cisco.com> wrote: >>> >>> >>> Tom - >>> >>>> -----Original Message----- >>>> From: t petch <ietfa@btconnect.com> >>>> Sent: Wednesday, September 21, 2022 3:45 AM >>>> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; John Scudder >>>> >>>> On 21/09/2022 05:16, Les Ginsberg (ginsberg) wrote: >>>>> Top posting here - and my response applies to the discussion between >> Eric, >>>> John, and Tom regarding Section 3.1 (and also to Alvaro - though I will >> reply >>>> directly to Alvaro's email as he has some specific questions not covered in >> the >>>> discussion below...) >>>>> >>>>> The text in Section 3.1 is currently: >>>>> >>>>> " The Router ID field of the inter-AS reachability TLV is 4 octets in length, >>>> which contains the IPv4 Router ID of the router who generates the inter- >> AS >>>> reachability TLV. The Router ID SHOULD be identical to the value >> advertised >>>> in the Traffic Engineering Router ID TLV [RFC5305]. If no Traffic >> Engineering >>>> Router ID is assigned, the Router ID SHOULD be identical to an IP >> Interface >>>> Address [RFC1195] advertised by the originating IS. If the originating node >>>> does not support IPv4, then the reserved value 0.0.0.0 MUST be used in >> the >>>> Router ID field and the IPv6 Router ID sub-TLV MUST be present in the >> inter- >>>> AS reachability TLV. The Router ID could be used to indicate the source of >> the >>>> inter-AS reachability TLV." >>>>> >>>>> >>>>> Tom suggests this should be modified to state: >>>>> >>>>> "> If a Traffic Engineering Router ID TLV >>>>>> [RFC5305] is available for the router which generates >>>>>> the inter-AS reachability TLV, then that value MUST be used. >>>>> >>>>> I am reluctant to do this. The use of MUST suggests that receivers >> should >>>> do a check to see if the router referred to in the Router ID field actually >>>> advertised a TE Router ID (TLV 134) and if it did and the value in the inter- >> AS >>>> reachability TLV is non-zero and does not match the value advertised in >> TLV >>>> 134 then the receiver is obligated to reject the inter-AS Reachability TLV >> as >>>> "invalid". This is unnecessarily strict and onerous. >>>>> >>>>> If a node advertises TLV 134 then that value SHOULD be used in the >> inter- >>>> AS reachability TLV. But if an implementation were to choose to use a >> value >>>> advertised in an IPv4 Address TLV by the same node no harm would be >> done. >>>> So I believe the existing text is more appropriate. >>>>> Note that I am not suggesting that the router ID be ignored (the use of >>>> SHOULD is a strong statement against doing that) but forbidding the use >> of >>>> an IPv4 address advertisement goes beyond what is needed here IMO. >>>>> >>>>> Therefore, I prefer to leave this text unchanged. >>>>> Is this acceptable? >>>> >>>> Les >>>> >>>> I think not. You focus on 'MUST' v 'SHOULD' (with hindsight that change >>>> was a mistake) and prefer the latter and I am ok with that. >>>> >>>> The original IESG comments were about 'IPv4 Router ID' and I think that >>>> that still needs addressing, which my formulation did. I see no such >>>> concept as 'IPv4 Router ID' anywhere in the IETF AFACT and think that >>>> the use of the term in an LSR document will reinforce a common >>>> misconception, that the 32 bit router ID, as used e.g. in OSPFv3, is >>>> something to do with IPv4, which it is not. It is 32 bits, that is all. >>>> >>>> Another way of putting it is >>>> OLD >>>> which contains the IPv4 Router ID of the router which >>>> NEW >>>> which identifies the router which >>>> >>> [LES:] I did not comment on the different meaning of Router ID in OSPF vs >> IS-IS because I thought that had been sorted out in the email thread already. >>> This is an IS-IS document. We need not be concerned with what router id >> means in OSPF. >>> >>> If you look at https://www.iana.org/assignments/isis-tlv-codepoints/isis- >> tlv-codepoints.xhtml#tlv-codepoints you will see: >>> >>> 134 Traffic Engineering router ID >>> ... >>> 140 IPv6 TE Router ID >>> >>> It could be argued that a better name for TLV 134 would have been "IPv4 >> Traffic Engineering Router ID" - but that isn’t within the purview of RFC 5316. >>> >>> The current text says (emphasis added): >>> >>> “The Router ID field of the inter-AS reachability TLV is 4 octets in length, >> which contains the IPv4 Router ID of the router who generates the inter-AS >> reachability TLV. The Router ID SHOULD be identical to the value advertised >> in the Traffic Engineering Router ID TLV [RFC5305].” >>> >>> I really do not see what is unclear about this. >>> You seem to be objecting to the use of the term “IPv4 Router ID” – but >> given that RFC 5316bis necessarily has to talk about both an IPv4 Router ID >> and an IPv6 Router ID I think this usage is necessary to avoid ambiguity. >>> ?? >>> >>> Les >>> >>>> I think that the following three sentences about where the value comes >>>> from - TLV, IPv4 address or 0.0.0.0 - still make perfect sense with that >>>> change. >>>> >>>> Tom Petch >>>> >>>> >>>> >>>>> >>>>> Les >>>>> >>>>>> -----Original Message----- >>>>>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of t petch >>>>>> Sent: Friday, September 16, 2022 9:37 AM >>>>>> >>>>>> On 16/09/2022 17:24, John Scudder wrote: >>>>>>> Hi Tom, >>>>>>> >>>>>>> Thanks for your comments! >>>>>>> >>>>>>>> On Sep 16, 2022, at 11:56 AM, t petch <ietfa@btconnect.com> >> wrote: >>>>>>>> >>>>>>>> On 16/09/2022 14:13, John Scudder wrote: >>>>>>>>> Hi Éric, >>>>>>>>> >>>>>>>>> A few comments below. >>>>>>>>> >>>>>>>>>> On Sep 16, 2022, at 4:27 AM, Éric Vyncke via Datatracker >>>>>> <noreply@ietf.org> wrote: >>>>>>>>>> >>>>>>>>>> ## COMMENTS >>>>>>>>>> >>>>>>>>>> ### Section 3.1 >>>>>>>>>> >>>>>>>>>> ``` >>>>>>>>>> The Router ID field of the inter-AS reachability TLV is 4 octets in >>>>>>>>>> length, which contains the IPv4 Router ID of the router who >>>>>> generates >>>>>>>>>> the inter-AS reachability TLV. The Router ID SHOULD be >> identical >>>> to >>>>>>>>>> the value advertised in the Traffic Engineering Router ID TLV >>>>>>>>>> [RFC5305]. If no Traffic Engineering Router ID is assigned, the >>>>>>>>>> Router ID SHOULD be identical to an IP Interface Address >>>> [RFC1195] >>>>>>>>>> advertised by the originating IS. >>>>>>>>>> ``` >>>>>>>>>> >>>>>>>>>> AFAIK, the router ID is 'just' a 32-bit value that it is protocol >> version >>>>>>>>>> agnostic. So, s/IPv4 Router ID/Router ID/ ? >>>>>>>>>> >>>>>>>>>> Suggest: s/IP Interface Address [RFC1195]/IPv4 Interface >> Address >>>>>> [RFC1195]/ ? >>>>>>>>> >>>>>>>>> I wondered about this too when I was reviewing the document, >> and >>>>>> indeed RFC 5305 just calls the TE Router ID a 4-octet value. But then >> RFC >>>> 6119 >>>>>> says, >>>>>>>>> >>>>>>>>> The TE Router ID TLV contains a stable IPv4 address that is >> routable, >>>>>>>>> regardless of the state of each interface. >>>>>>>>> >>>>>>>>> Similarly, for IPv6, it is useful to have a stable IPv6 address >>>>>>>>> identifying a TE node. The IPv6 TE Router ID TLV is defined in >>>>>>>>> Section 4.1. >>>>>>>>> >>>>>>>>> So even though it was after the fact, I suppose calling the former >> the >>>>>> “IPv4 Router ID” makes sense and just codifies what is apparently >> already >>>> the >>>>>> practice. The existence of the IPv6 TE Router ID, so named, is “the >>>> exception >>>>>> that proves the rule”. >>>>>>>> >>>>>>>> Well, not really. >>>>>>>> >>>>>>>> The router id is 32 bits with no semantics, often displayed as dotted >>>>>>>> quad. It is used in a number of protocols, in both IPv4 and IPv6, as >> in >>>>>>>> OSPFv3. A YANG type for it is defined in routing-types (RFC8294) >> and >>>>>>>> you will find it in such as draft-ietf-opsawg-l2nm. It has nothing to >>>>>>>> do with IP of any version and so cannot be relied on for the transfer >> of >>>>>>>> packets. (I see it used to add semantics about a router, such as >> OSPF >>>>>>>> Area, although others conflate it with an IPv4 loopback address). >>>>>>>> >>>>>>>> TE needed a routable address and so created Traffic Engineering >>>>>>>> Router-ID, one for IPv4 and a different one for IPv6. Try >>>>>>>> draft-ietf-ospf-yang s.2.4 for usage and references. The >> terminology is >>>>>>>> not that of the original TE RFC (RFC3630) but I find the ospf-yang >>>>>>>> terminology clear and used elsewhere. This I-D under review is a >>>>>>>> product of the LSR WG and I would have hoped that a draft-ietf-lsr >>>> would >>>>>>>> get this distinction between the router-id, with no semantics, and >> the >>>>>>>> TE router ID, IPv4 or IPv6, right:-( >>>>>>>> >>>>>>>> Tom Petch >>>>>>> >>>>>>> Actually now that you have sent me back to look again, I’m second- >>>>>> guessing myself. The text in question is from Section 3.1, which is >> about >>>> the >>>>>> Inter-AS Reachability TLV, and NOT the TE Router ID. So, the analysis I >>>>>> provided above doesn’t seem to be applicable. Looking at what RFC >> 5316 >>>>>> said, it’s >>>>>>> >>>>>>> The Router ID field of the inter-AS reachability TLV is 4 octets in >>>>>>> length, which contains the Router ID of the router who generates >> the >>>>>>> inter-AS reachability TLV. >>>>>>> >>>>>>> The term “Router ID” is used as though it were an agreed term of art >> in >>>> IS- >>>>>> IS, but it’s not, to my knowledge. This is probably the root of the >> problem: >>>> IS- >>>>>> IS has a System Identifier or System-ID, which is notionally 1-8 bytes >>>> variable >>>>>> but AFAIK is generally (always?) 6 bytes. So it seems as though RFC >> 5316 >>>>>> could have been clearer in that regard, but quite probably did mean >> what >>>>>> you say above. >>>>>>> >>>>>>> So, I take it back, I think you and Éric are right, strictly speaking. >>>>>> Unfortunately it doesn’t look like simply removing the adjective “IPv4” >> will >>>> be >>>>>> sufficient, though. Let’s look at the whole paragraph in RFC 5316: >>>>>>> >>>>>>> The Router ID field of the inter-AS reachability TLV is 4 octets in >>>>>>> length, which contains the Router ID of the router who generates >> the >>>>>>> inter-AS reachability TLV. The Router ID MUST be unique within >> the >>>>>>> ISIS area. If the router generates inter-AS reachability TLV with >>>>>>> entire ISIS routing domain flooding scope, then the Router ID >> MUST >>>>>>> also be unique within the entire ISIS routing domain. The Router >> ID >>>>>>> could be used to indicate the source of the inter-AS reachability >>>>>>> TLV. >>>>>>> >>>>>>> Now let’s look at the replacement paragraph: >>>>>>> >>>>>>> The Router ID field of the inter-AS reachability TLV is 4 octets in >>>>>>> length, which contains the IPv4 Router ID of the router who >> generates >>>>>>> the inter-AS reachability TLV. The Router ID SHOULD be identical >> to >>>>>>> the value advertised in the Traffic Engineering Router ID TLV >>>>>>> [RFC5305]. If no Traffic Engineering Router ID is assigned, the >>>>>>> Router ID SHOULD be identical to an IP Interface Address >> [RFC1195] >>>>>>> advertised by the originating IS. If the originating node does not >>>>>>> support IPv4, then the reserved value 0.0.0.0 MUST be used in the >>>>>>> Router ID field and the IPv6 Router ID sub-TLV MUST be present in >> the >>>>>>> inter-AS reachability TLV. The Router ID could be used to indicate >>>>>>> the source of the inter-AS reachability TLV. >>>>>>> >>>>>>> Even if you took “IPv4” out as a qualifier of "Router ID”, the >> remainder of >>>>>> the paragraph goes into some detail about harvesting bits to put in >> that >>>> field >>>>>> from an IPv4 interface. It generally seems like sensible advice, but it’s >>>>>> blatantly IPv4-specific. If we don’t like “IPv4” qualifying “Router ID”, is >>>> there >>>>>> some further consideration needed for the rest of the paragraph? By >> the >>>>>> way, the global uniqueness requirement is still satisfied in the “but >> what if >>>>>> there are no IPv4 interfaces” case by requiring that the IPv6 Router ID >>>> sub- >>>>>> TLV be present in that case, or so I read it. >>>>>>> >>>>>>> Anyway, I think this puts the ball back in the authors’ (and WG’s) >> court to >>>>>> decide what to do with the technically-inaccurate term “IPv4 Router >> ID”. >>>>>> (And in any case I do agree with Éric’s s/Interface Address/IPv4 >> Interface >>>>>> Address/.) >>>>>> >>>>>> Indeed. Perhaps something like >>>>>> >>>>>> The Router ID field of the inter-AS reachability TLV is 4 octets in >>>>>> length. >>>>>> >>>>>> If a Traffic Engineering Router ID TLV >>>>>> [RFC5305] is available for the router which generates >>>>>> the inter-AS reachability TLV, then that value MUST be used. >>>>>> If no Traffic Engineering Router ID is assigned, the >>>>>> Router ID SHOULD be identical to an IP Interface Address [RFC1195] >>>>>> advertised by the originating IS. >>>>>> If the originating node does not >>>>>> support IPv4, then the reserved value 0.0.0.0 MUST be used in the >>>>>> Router ID field and the IPv6 Router ID sub-TLV MUST be present in the >>>>>> inter-AS reachability TLV. The Router ID could be used to indicate >>>>>> the source of the inter-AS reachability TLV. >>>>>> >>>>>> It is now later Friday and next Monday and Tuesday are spoken for so I >>>>>> may not see any response until Wednesday. >>>>>> >>>>>> Tom Petch >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> —John >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Lsr mailing list >>>>>> Lsr@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lsr >
- [Teas] Éric Vyncke's No Objection on draft-ietf-l… Éric Vyncke via Datatracker
- Re: [Teas] Éric Vyncke's No Objection on draft-ie… John Scudder
- Re: [Teas] Éric Vyncke's No Objection on draft-ie… Eric Vyncke (evyncke)
- Re: [Teas] Éric Vyncke's No Objection on draft-ie… Acee Lindem (acee)
- Re: [Teas] Éric Vyncke's No Objection on draft-ie… t petch
- Re: [Teas] Éric Vyncke's No Objection on draft-ie… John Scudder
- Re: [Teas] Éric Vyncke's No Objection on draft-ie… t petch
- Re: [Teas] [Lsr] Éric Vyncke's No Objection on dr… Les Ginsberg (ginsberg)
- Re: [Teas] [Lsr] Éric Vyncke's No Objection on dr… t petch
- Re: [Teas] [Lsr] Éric Vyncke's No Objection on dr… Les Ginsberg (ginsberg)
- Re: [Teas] [Lsr] Éric Vyncke's No Objection on dr… John Scudder
- Re: [Teas] [Lsr] Éric Vyncke's No Objection on dr… Les Ginsberg (ginsberg)
- Re: [Teas] [Lsr] Éric Vyncke's No Objection on dr… t petch