Re: [Lsr] Gunter Van de Velde's No Objection on draft-ietf-lsr-dynamic-flooding-17: (with COMMENT)
Tony Li <tony.li@tony.li> Fri, 05 April 2024 21:47 UTC
Return-Path: <tony1athome@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9F0C1519A6; Fri, 5 Apr 2024 14:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.745
X-Spam-Level:
X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HiaxkbKuSGft; Fri, 5 Apr 2024 14:47:08 -0700 (PDT)
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA317C15199C; Fri, 5 Apr 2024 14:47:08 -0700 (PDT)
Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-6eced6fd98aso2150833b3a.0; Fri, 05 Apr 2024 14:47:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712353628; x=1712958428; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=1VYElhWI9Uu+cTInOWgfAD/MXH74yJwZWpURnmNQs+8=; b=hiyTMtJngpSulC/cSqAPYIBV7Rypap1CuZGHTGTlq+LQsdwN0WL+qycZ0z0XFxaIjp KxLmjbqZjK9PJiT+wTkZBNN959UH1dR5g0nsQD4PSUkw3K4YAQC7tiX0Q0Hl8Yn2bXaV JFtUi+NH2NldoFhsTxwF11+hFLnAPRYY0GOZ3Q4ks8WoCfRZiE4K3SbP02NXAANpzGng C4QsCXNdHdvyzT77Hbuwa/1L+MmIG9b7ZL8e8RmZ3lt6TwHjSf0DhBbpb8FUeDyd+f7Q WUzvirrfLWId69X47zSoKMv5akqtjO5l4efAmBa3Dx7De1pI1UD13ekTCA1RNHHQHm14 ub9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712353628; x=1712958428; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=1VYElhWI9Uu+cTInOWgfAD/MXH74yJwZWpURnmNQs+8=; b=cdfLme255/LGizbiyaotM0kxshMAhp1yoFt6DNqbLBdNTEMs3fjSwynGUijvkHqZEG hsfQquaJxrrJnNgnkqjWnphcYI/FeV8H66mnida/fVYvWBzdhcvZPKK10jlCXjdP88Tk nU+FLzh+NUnoqhrZfgafgaWwxkxRL/w18nTKC5Ag0jl4i6V1w43FJ1IKijQmC+Q9tsL3 i/QmaukRUcpn+Hp9ZoZh+FQBNuiNECEyKk76gObjt9+qlkEuc8t+Hikfmo/TXzPgtBnP uickcum64o7/ttGiMLiseXeQUq7X8pIHReCyCp4FF8u6YUVAWVpxpKRDJ9tFfqx8NKqM Ju7g==
X-Forwarded-Encrypted: i=1; AJvYcCV7vooO5g4dcfv++LZfeu0vPjdlyDCZoy+QeHvNr7cRl+vGeamuBRaLwGGQxVoiDPa4+GlcdWJZNNsrKx0Y+gbfwqvFZZHYxS/Sg43ky892q/kzt2jT57F/ZzP/LAxyPtU0JdaQV7wjH6ZXJSdqxNTajcPOedZsmiSQzgA=
X-Gm-Message-State: AOJu0YzrTsOBBJQeW5M6c+TLZCUCZ24HUhTl6GT1zAg2SaWoAz0O5rww LTZbbYbXDZHL7Jv3980nUhCteSGszGX6LVTEVKFAUNS/QnfOCxnqw3z22CuS
X-Google-Smtp-Source: AGHT+IG6Ruu/MAi2K4Bixl+M2CmKP6XZNwRXwQ2TezytN6wHammWrK1ddnMxYtvMUVSnbGEzWCF2lg==
X-Received: by 2002:a05:6a21:9989:b0:1a7:2463:ae3b with SMTP id ve9-20020a056a21998900b001a72463ae3bmr3595401pzb.7.1712353174207; Fri, 05 Apr 2024 14:39:34 -0700 (PDT)
Received: from smtpclient.apple (c-73-93-167-4.hsd1.ca.comcast.net. [73.93.167.4]) by smtp.gmail.com with ESMTPSA id w3-20020aa78583000000b006ecdb55db60sm1975686pfn.195.2024.04.05.14.39.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Apr 2024 14:39:33 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
From: Tony Li <tony.li@tony.li>
In-Reply-To: <171223716890.1198.5664231188141334309@ietfa.amsl.com>
Date: Fri, 05 Apr 2024 14:39:22 -0700
Cc: The IESG <iesg@ietf.org>, draft-ietf-lsr-dynamic-flooding@ietf.org, lsr-chairs <lsr-chairs@ietf.org>, lsr <lsr@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, Acee Lindem <acee.ietf@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <01C2C81F-9A59-4BCB-BB36-6B2D1A2EA5E0@tony.li>
References: <171223716890.1198.5664231188141334309@ietfa.amsl.com>
To: "Gunter Van De Velde (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/PQWD_44xQNiKSFfjR4MGPm_5kkc>
Subject: Re: [Lsr] Gunter Van de Velde's No Objection on draft-ietf-lsr-dynamic-flooding-17: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Apr 2024 21:47:10 -0000
Gunter, Thank you for your comments. Please see inline. > Thank you for the work put into this document. This document is a joy to read > and documents an elegant solution to a well known IGP problem problem space. Thank you. > 409 Similarly, if additional redundancy is added to the flooding > 410 topology, specific nodes in that topology may end up with a very high > 411 degree. This could result in overloading the control plane of those > > The text reads smooth, until the term 'degree' pops up without explanation what > it entails. I (non-native English speaker) suspect it is terminology from graph > theory. I do recall it being mentioned within the presentations about this > draft in LSR WG. Maybe a short line explaining what degree in graph theory is > may help with the document for non-native English speakers. > > In my search for some level of understanding on what to understand of degree: > > "In graph theory, the degree of a vertex refers to the number of edges > connected to that vertex. For undirected graphs, this simply means the count of > edges touching the vertex. For directed graphs, you can distinguish between the > "in-degree" and the "out-degree" of a vertex: the in-degree is the number of > edges coming into the vertex, and the out-degree is the number of edges going > out from the vertex. > > For example, in an undirected graph, if a vertex has three edges connected to > it, its degree is 3. In a directed graph, if a vertex has two arrows pointing > to it and one arrow pointing away, its in-degree is 2 and its out-degree is 1." This is exactly correct. I will add a definition. > 417 If the leader chooses to include a multi-access broadcast LAN segment > 418 as part of the flooding topology, all of the links in that LAN > 419 segment should be included as well. Once updates are flooded on the > 420 LAN, they will be received by every attached node. > > The links mentioned here seem to not correspond to the physical links but > instead to the graph links. I assume a link here is from each unique router on > the LAN segment to the DR/DIS and from the DR/DIS to each unique router > connected on the LAN segment? Or is the term link referencing to something else? As you may recall, IS-IS handles LANs by modeling them as adjacencies from each node to the DIS. It would be more correct here to talk about adjacencies than links. Amended. > 422 4.4. Topologies on Complete Bipartite Graphs > > I agree with the comments from others that a short drawing would make the > topology descriptions easier to comprehend A better representation mechanism than ASCII art would make this much easier. > 493 If two nodes are adjacent on the flooding topology and there are a > 494 set of parallel links between them, then any given update MUST be > 495 flooded over a single one of those links. The selection of the > > small proposed re-edit for reading clarity: > > "If two nodes are adjacent in the flooding topology and there is a set of > parallel links between them, then any given update MUST be flooded over only > one of those links" Sure. > 513 these edges is optional. Note that this may result in the > 514 possibility of "hidden nodes" which are part of the flooding topology > > I have sometimes seen the term "stealth" used for hidden nodes or devices Added. > 525 Other encodings are certainly possible. We have attempted to make a > 526 useful trade-off between simplicity, generality, and space. > > Not sure who is 'we'? i have seen mostly in IETF style suggestions avoiding it > in favor of more direct or passive constructions to maintain formal tone and > objectivity. Ok. > 662 5.1.3. IS-IS Area Node IDs TLV > > Not sure it is clear from the text paragraph where this TLV is inserted in the > hierarchy of TLVs. For example, for the "IS-IS Dynamic Flooding Sub-TLV" it is > explicitly mentioned. (TLVs in section 5.1.4/5.1.5/5.1.6 do not have a explicit > indication of place in the TLV hierarchy either) This is a top level TLV. This falls out from the code point allocation. > 693 Length: 3 + ((System ID Length + 1) * (number of node IDs)) > > Should it be mentioned that the unit is octets? Octets is IS-IS standard, so that’s not really necessary. > if ever a yang is created it > will be in there documented anyway why does length start with '3'? I am missing > a calculation logic Starting index (2) + L/Reserved bits (1) + Number of node IDs * (length of a node ID == system ID + pseudonode index) > 826 In support of advertising which edges are currently enabled in the > 827 flooding topology, an implementation MAY indicate that a link is part > 828 of the flooding topology by advertising a bit-value in the Link > 829 Attributes sub-TLV defined by [RFC5029]. > > The register is standards action. and that seems according RFC8126 section 4 > (https://www.rfc-editor.org/rfc/rfc8126.html#section-4) to require a standards > track document or a BCP. This document is target to be experimental. > > 4.9. Standards Action > > For the Standards Action policy, values are assigned only through > Standards Track or Best Current Practice RFCs in the IETF Stream. Ok, I don’t know how to resolve this. Ideas? > 1978 IANA is requested to set up a registry called "IGP Algorithm Type For > 1979 Computing Flooding Topology" under the existing "Interior Gateway > 1980 Protocol (IGP) Parameters" IANA registry. > > Not explicit mentioned here, but which IANA a Registration Policy is implied? > https://www.rfc-editor.org/rfc/rfc8126.html#section-4 Added expert review. T
- [Lsr] Gunter Van de Velde's No Objection on draft… Gunter Van de Velde via Datatracker
- Re: [Lsr] Gunter Van de Velde's No Objection on d… Tony Li