Re: [ippm] RtgDir Last Call review: draft-ietf-ippm-ioam-conf-state-10 (really, this time)
Donald Eastlake <d3e3e3@gmail.com> Wed, 14 December 2022 21:00 UTC
Return-Path: <d3e3e3@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2632C14F738; Wed, 14 Dec 2022 13:00:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.844
X-Spam-Level:
X-Spam-Status: No, score=-6.844 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=ham 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 8QOlIT7rbtI0; Wed, 14 Dec 2022 13:00:10 -0800 (PST)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 E7DB4C14F720; Wed, 14 Dec 2022 13:00:09 -0800 (PST)
Received: by mail-ed1-x52f.google.com with SMTP id f7so24378550edc.6; Wed, 14 Dec 2022 13:00:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7LDENSi0cXWk4GG2NLaeIdRMTujoKI9QgiaMp2yEejw=; b=fCcmv6mNOTzSxtDnx5oJamdqM+sghpux66UlOarLv5LQ8+rW0Fiq2Hx0/p/6ar6vUE MNI6mMdDwjeMmo+rJFfWZHVnXp6Jq0LF4m8oE7aC1R23WuDTcBu39FjdK8a5ZnT1NH63 luExPP7Z75ubXafIjhPn8xiQDfq2ZLoSzhbXakQEXEhNk2cIQ+hSrPxiPo1Z6D2GdY6o rCWBGkQqnah6rQAIlzL2LNkhYf/H/50IoqbyitT2Sh2GYSCcvnmoTnEyVYGQWvU1DTIz N419EdUL0zkTvdPi0mdTkp/af0qF4vm/YkXYPGVkHHzvRsv/1CQ0ZM1SREsybh92nTpG 8dIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7LDENSi0cXWk4GG2NLaeIdRMTujoKI9QgiaMp2yEejw=; b=oYK7sVUTgRZrN7RIBpi4spOItXSWIMypFiRLaivsE5bKj52AVqg+8Dv/p4GzgdVGoa YNimkqp4Z57IvLNGKRNq/cAXM/sx1Jg4/74A+vjt2o9WiZEUmKZCb6KcEb+DrjP/frNo 8lvowGBS05/b32hHeo1KVsVO0jezSh7PY+KA4PJ86N4NczYRk4EkHwQuajMdCD52vlhZ Fc7wMWaQchWwHUgAQImpiHtZbZd3S596VsGc76KpopjGKNv4r0RSHNeyj0F3qt3dncGk j7+6IM3W5RL1qFO3UEPSrPEM3RkZrTn6vjtS4i9nuVKCNGGrGpT1i/wZeZF/MSvm5w+3 9w8w==
X-Gm-Message-State: ANoB5pnvNe+Y2+aZh+h3s5tIx12ohHj5ZiOHY4LfY5gqp1VYEM2EO1G9 46FpxwvnnCG6utNh3rO0UL00eJznK9e/HpCz/Nw=
X-Google-Smtp-Source: AA0mqf5odqSgd9PmVLn14nR7m66uVjhQaz2qGEecGXOHNkB0oAwxzUEwV0O/EC8c301JcPLGHD2RJVuBaVgJv0FZ2AY=
X-Received: by 2002:a05:6402:78e:b0:46c:6f53:bf19 with SMTP id d14-20020a056402078e00b0046c6f53bf19mr21400487edy.299.1671051608245; Wed, 14 Dec 2022 13:00:08 -0800 (PST)
MIME-Version: 1.0
References: <CAF4+nEFEKxs0_0THCH-2u4HGT5Kd_xpJuDrkOeMbb7b53ToSYA@mail.gmail.com> <202212141748530573668@zte.com.cn>
In-Reply-To: <202212141748530573668@zte.com.cn>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 14 Dec 2022 15:59:55 -0500
Message-ID: <CAF4+nEFjMia10MdvHoH1HnNt9uQmePtrK7sw0mEYZTN+OrQf1A@mail.gmail.com>
To: xiao.min2@zte.com.cn
Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-ippm-ioam-conf-state.all@ietf.org, ippm@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="00000000000082c7ed05efd005ad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/xEJThZxxK8wT2x09IveIGDxjM38>
Subject: Re: [ippm] RtgDir Last Call review: draft-ietf-ippm-ioam-conf-state-10 (really, this time)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Dec 2022 21:00:15 -0000
Thanks for your quick response. See below at <de>. On Wed, Dec 14, 2022 at 4:49 AM <xiao.min2@zte.com.cn> wrote: > Hi Donald, > > Thank you for the review and thoughtful comments. > > I'll attempt to address your comments, although the relevant document is > already in RFC Editor's Queue. > <de> You're welcome. For some reason I was asked to review your draft after it was in the RFC Editor's Queue so I'm not sure what will happen to comment resolutions. Please see inline my responses... > > > Best Regards, > > Xiao Min > Original > *From: *DonaldEastlake <d3e3e3@gmail.com> > *To: *<rtg-ads@ietf.org> <rtg-ads@ietf.org>; > *Cc: *rtg-dir@ietf.org <rtg-dir@ietf.org>; > draft-ietf-ippm-ioam-conf-state.all@ietf.org < > draft-ietf-ippm-ioam-conf-state.all@ietf.org>;ippm@ietf.org <ippm@ietf.org > >;Last Call <last-call@ietf.org>; > *Date: *2022年12月14日 02:50 > *Subject: **[ippm] RtgDir Last Call review: > draft-ietf-ippm-ioam-conf-state-10 (really, this time)* > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review is > to provide assistance to the Routing ADs. For more information about > the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. > > Document: draft-ietf-ippm-ioam-conf-state-10 > Reviewer: Donald Eastlake 3rd > Review Date: 13 December 2022 > IETF LC End Date: > Intended Status: Standards Track > > > Summary: > > I have some minor concerns about this document that I think should be > resolved before publication. > > > Comments: > > This document is reasonably well written but has some minor issues and > occasionally scattered grammatical slips. > > > Major Issues: > > No major issues found. > > > Minor Issues: > > Section 3.1: Concerning the list of IOAM Namespace-IDs, it states that > Namespace-ID 0x000 MUST be first, any other occurrences of 0x000 MUST > be disregarded. This naturally leads me to the following: > If there are multiple occurrences of other Namespace-IDs, are all but > > the first ignored? > > [XM]>>> As stated in section 6, duplicate IOAM Namespace-IDs is an error. > Is there any ordering requirement on any Namespace-IDs after the > > 0x0000 and, if so, how are out-of-order Namespace IDs handled? > > [XM]>>> No. > <de> OK. If it is convenient to modify the document, I think it would be good to mention earlier in the document, where Namespace-IDs are first mentioned, that duplicates are an error and that, except for the requirement that 0x0000 be first, the Namespace-IDs can be in any order. > Section 4: There is some unstated assumption here that IOAM capability > information is wanted for a specific known unicast path. I think this > > assumption should be made explicit. > > [XM]>>> For IPv6, IOAM Capabilities Query would be sent to the known IOAM > transit/decap nodes. For MPLS, IOAM Capabilities Query would be sent to the > egress node and intercepted by the transit node through TTL expiration. > <de> I was primarily wondering about multicast. > SoP / TSF: > - Either these need to be spelled out in the registry names for the > registries being created in Section 5 or each registry with such an > abbreviation in its registry name needs a note that includes the > > abbreviation expansion. > > [XM]>>> In section 5.1, it says "SoP: size of POT"; In section 5.2, it > says "TSF: timestamp format". Do you see a need for some new text? > <de> I think that text just in this draft is not sufficient. Someone looking at the Registries on the IANA web pages needs a bit more explanation. Of course, I suppose the RFC this draft is published as will be listed as a Reference from the IANA Registries which helps a lot. And maybe IANA will spontaneously put a little of this text into a Note at the beginning of each registry... > - Suggest adding these to Section 2.2 Abbreviations. > > [XM]>>> OK. > > Section 6, Page 16: > - There are two paragraphs in Section 6 where the first talks about > IOAM Capability information being carried across the network and the > second talks about collected IOAM Capability information. The first > paragraph reasonably gives example security methods for data in > transit. The second paragraph, however, does not mention or give an > example of how to protect collected information, which is presumably > data at rest. As it is, the paragraphs are mostly redundant except for > the first sentence of the 2nd paragraph. Suggest changing the 2nd > paragraph by replacing the existing material after the first sentence > with something like "Care should therefore be taken to limit access to > such collected IOAM Capabilities information." > - In the next to the last paragraph of Section 6, we first learn that > duplicate IAOM Namespace-IDs is an error. This should be mentioned > earlier where Namespace-IDs in messages is first discussed. This > paragraph also lists "whether the received Namespace-ID is an > operator-assigned or IANA-assigned one" as if that was an error > condition, which I don't understand. > [XM]>>> At this point, I prefer not to change section 6 in any way. As to > the text "whether the received Namespace-ID is an operator-assigned or > IANA-assigned one", it's from RFC 9197 which says " > > The Namespace-ID value is divided into two subranges: > <https://www.rfc-editor.org/rfc/rfc9197#section-4.3-2> > > - > > an operator-assigned range from 0x0001 to 0x7FFF and > <https://www.rfc-editor.org/rfc/rfc9197#section-4.3-3.1> > - > > an IANA-assigned range from 0x8000 to 0xFFFF. > > <de> Yes, I understand there are two ranges of IDs but they are mentioned here in the Security Considerations section in a paragraph about checking that "the fields in received echo requests and replies strictly conform to the specifications". I wasn't sure what being operator-assigned or IANA-assigned had to do with strictly conforming to the specifications. <de> Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com > Nits: > > Section 1, page 3: > OLD > Furthermore, each IOAM encapsulating node needs to establish > NETCONF Connection with each IOAM transit and IOAM decapsulating > node, the scalability can be an issue. > NEW > Furthermore, each IOAM encapsulating node needs to establish a > NETCONF Connection with each IOAM transit and IOAM decapsulating > node, so scalability can be an issue. > > Section 1, Page 4/5: > OLD > Fate sharing is a common requirement for all kinds of active OAM > packets, echo request is among them, in this document that means echo > request is required to traverse a path of IOAM data packet. This > requirement can be achieved by, e.g., applying same explicit path or > ECMP processing to both echo request and IOAM data packet. Specific > to apply same ECMP processing to both echo request and IOAM data > packet, one possible way is to populate the same value(s) of ECMP > affecting field(s) in the echo request. > NEW > Fate sharing is a common requirement for all kinds of active OAM > packets including echo request. In this document that means echo > request is required to traverse the path of an IOAM data packet. > This requirement can be achieved by, e.g., applying the same > explicit path or ECMP processing to both echo request and IOAM data > packets. Specifically, the same ECMP processing can be applied to > both echo request and IOAM data packets, by populating the same > value(s) in ECMP affecting field(s) of the packets. > > Section 3.2, Page 7: > "reply except the" -> "reply unless the" > > Section 3.2.6, Page 13: > OLD > it's > RECOMMENDED to include only the IOAM Edge-to-Edge Capabilities Object > but not the IOAM End-of-Domain Object. > NEW > including only the IOAM Edge-to-Edge Capabilities Object > but not the IOAM End-of-Domain Object is RECOMMENDED. > > Multiple sections: It is just a tiny bit confusing that many fields > that are to be sent as zero and ignored on receipt are labeled with > the ordinary capitalized word "Reserved". Suggest that you consider > using "MBZ" or "RES" or even "RESERVED" so you don't end up > duplicating the word when you say "Reserved field is reserved ..." > In Section 3.2.6, however, there is a "Must Be Zero" field and, > although all the fields are explained in other cases, there is no > explanation below for that field. > > > [XM]>>> Thank you for catching the Nits. Will work with RFC Editor to > address them. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > > >
- [ippm] RtgDir Last Call review: draft-ietf-ippm-i… Donald Eastlake
- Re: [ippm] RtgDir Last Call review: draft-ietf-ip… xiao.min2
- Re: [ippm] RtgDir Last Call review: draft-ietf-ip… Donald Eastlake
- Re: [ippm] RtgDir Last Call review: draft-ietf-ip… xiao.min2