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
>