Re: [mpls] Shepherd review of draft-ietf-mpls-spring-inter-domain-oam-10
Adrian Farrel <adrian@olddog.co.uk> Wed, 07 February 2024 16:53 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7645C14F5F3; Wed, 7 Feb 2024 08:53:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_DNSWL_BLOCKED=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_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=olddog.co.uk
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 RcJnzUm6J2Fx; Wed, 7 Feb 2024 08:53:23 -0800 (PST)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 5BC7AC14F5E9; Wed, 7 Feb 2024 08:53:21 -0800 (PST)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.7/8.14.7) with ESMTP id 417GrJ5g029665; Wed, 7 Feb 2024 16:53:19 GMT
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DA31B4604B; Wed, 7 Feb 2024 16:53:18 +0000 (GMT)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CD94B4604A; Wed, 7 Feb 2024 16:53:18 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS; Wed, 7 Feb 2024 16:53:18 +0000 (GMT)
Received: from LAPTOPK7AS653V ([148.252.129.168]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 417GrHJB003353 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Feb 2024 16:53:18 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: adrian@olddog.co.uk, draft-ietf-mpls-spring-inter-domain-oam@ietf.org
Cc: mpls@ietf.org
References: <03d501da5941$e6a74880$b3f5d980$@olddog.co.uk>
In-Reply-To: <03d501da5941$e6a74880$b3f5d980$@olddog.co.uk>
Date: Wed, 07 Feb 2024 16:53:17 -0000
Organization: Old Dog Consulting
Message-ID: <04ba01da59e6$26f288b0$74d79a10$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEAhxO7SoweSX83YOY3KSNKBE3xCrKyvJvw
Content-Language: en-gb
X-Originating-IP: 148.252.129.168
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding; s= 20221128; bh=aA7A2Yozx28hXi/FlxnCPs8DEcB9i6hsbawl4vtriKw=; b=thf 8cLkVIBGOVIUiKIO7Yc27oLCoW1JjQ9KFU4KYX5kQXUkGFZenrUkGRMaZZFVGTPN j+SuQQ9BMfjjLhpdPt+Y4hPuM5WSZ2rqpkfeA8QC/FSECYSqvrFg0Av85vflSdup He0NwCc7+dgVmvnRxjZQ7AszJpVb4sr2ci0fg/lBeYoFNWpXN/srr+z9Gr0VuE7X zLA/tbCJRQQWeU8DVe1gM/agOROKpcbF5GtTrTgk/2KArPQ8hVnu69GMkBCi85Mx 0szUwA7xCtAeL3ywbg8naFeKpRUDBw9NBKvxP3BAyprMWoRxon6NWFBecT13JswJ rkq/EJoGyHVzf2Wsk2A==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-28176.000
X-TM-AS-Result: No--27.799-10.0-31-10
X-imss-scan-details: No--27.799-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28176.000
X-TMASE-Result: 10--27.799300-10.000000
X-TMASE-MatchedRID: jFqw+1pFnMzxIbpQ8BhdbKoXHZz/dXlxVBDQSDMig9EM74Nf6tTB9m8w cjvVdNwcp635axwDi2eDs24hteATn+xl9HNVJWpcsZaZ5UBQsofF11Guem055247M5sxfdoIZng ixNorteBrVLn9+3EQ1SOxbMZGtzKy84uhfUdbYE4K3Ma88LL+bgv/9UzFeXITz5ZiODdbPIp1V0 N/6ncOcsgaqUgNYNLGRu+54+IMWaQrqSb6h39QPATtNEP9j0LPgf3FRZbpKzv49It3+aqOX57BE eKXZ2+C6oHv+vDBrw0swgmgBEKZes4Cn0fUiJuCh4Ce12gzEFo1gRGJ6Up9hSyteUB4iQcKa0IE kYOsokXpm17rTwNEVrKFQsyeQ723gpiEITtY9wtWdeCTfSse8h6OXxdRGLx8yBXJN3+n78iyuhp iqaRnallzahCClUPLx/l0Ky+1KBnnXTcEZvGUhlk1hIeTdmvRI3CelQUbNBwSgmfkOsgfKswil6 AxcZWLbfiTv4IF1xa9kfujYGhXhnXCw37BwNl9fUkgDiuGxn8csx3IH4sq3Mbl1d1BOPY4tvOwJ AUGquiIEpNtrQQjQRkP3mYLz4BQjxmC4zinH8p+PaHzn/5F3XFd5+Cf9M1D8vJ7Gotm2YAaZW50 SGemhE5EkrrL8tOX+4vaPDtAmOJ0IEJuFpC6iB+6KI45ee2VM9EkAUzyluGq+LxFU7C3tnioE/M crQgc88Nlh3h4mC+UI512D01p9EVY8oFPPrIpzYK5U+QI3O72/fdRbxY1gEJsNXD374+phjISH0 pZGro7sGNvmRDvlYLbOrl0mDmesXqem1oR8/9ANB89sV0bJ30tCKdnhB58vqq8s2MNhPAL4KbF8 qbADAzKt8/2P4LV33fj+sMArfMaMUyeC0staEkVAPr0TXS8
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/fPu5XCYFRFoTlVFMN3PsnrMceoM>
Subject: Re: [mpls] Shepherd review of draft-ietf-mpls-spring-inter-domain-oam-10
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Feb 2024 16:53:28 -0000
Oh, I should add... Please be sure to clean up all of the nits reported by idnits https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id /draft-ietf-mpls-spring-inter-domain-oam-10.txt The only things you can get away with are the things that look like references, but aren't. Cheers, Adrian -----Original Message----- From: mpls <mpls-bounces@ietf.org> On Behalf Of Adrian Farrel Sent: 06 February 2024 21:18 To: draft-ietf-mpls-spring-inter-domain-oam@ietf.org Cc: mpls@ietf.org Subject: [mpls] Shepherd review of draft-ietf-mpls-spring-inter-domain-oam-10 Hi, I have taken over as shepherd for your document. That necessitates me jumping in with a "slightly late" review. But I guess all reviews are helpful. If you can spin a new version, I can pass the document on to the AD. Thanks, Adrian === Throughout the document there are a number of cases of missing spaces before or after round brackets or commas. Please check and fix. --- Abstract s/Segment Routing (SR)/The Segment Routing (SR)/ s/Autonomous Systems(AS)/Autonomous Systems (ASes)/ s/with simple/with a simple/ --- Please move the section on Requirements Language down to become 1.2. --- 1. I think this section really should start with some text and not leap in with a figure. Figure 1 is not referenced until the 3rd paragraph, so this should be easy to do. The figure could use a key for: AS ASBR P PE PMS --- 1. para 1 s/Autonomous Systems either/Autonomous Systems (ASes) either/ s/Segment Routing/Segment Routing (SR)/ s/Autonomous systems(AS)./ASes./ s/Identifiers(SID)/Identifiers (SIDs)/ --- 1. para 2 s/with MPLS/with an MPLS/ s/Autonomous system/AS/ s/Autonomous Systems(AS)/ASes/ --- 1. para 3 s/(EPE-SID)/(EPE-SIDs)/ s/For example in Figure 1/For example, in Figure 1,/ --- 1. para 3 It is advantageous for operations to be able to perform LSP ping and traceroute procedures on these inter-AS SR-MPLS paths. - s/operations/operators/ ??? - "It is advantageous" feels a bit unsupported. What are the advantages? Perhaps "... in order to detect and diagnose failed deliveries and to determine the actual path that traffic takes through the network." --- 1. You have both 'traceroute' and 'Traceroute'. Please pick one and apply it to the whole document. --- 1. para 4 That is because there is no IP connectivity to the source address of the ping packet, which is in a different AS from the packet's destination. I know what you mean, but as stated this is not completely true (and not always true, in any case). Maybe... That is because there might not always be IP connectivity from a responding node back to the source address of the ping packet when the responding node is in a different AS from the source of the ping. --- 1. para 5 s/out the MPLS/out MPLS/ s/requires PMS/requires the PMS/ --- 1. para 5 This mechanism is operationally very heavy and requires PMS to be capable of building a huge number of GRE tunnels, which may not be feasible. Presumably... This mechanism is operationally very heavy and requires the PMS to be capable of building a huge number of GRE tunnels or installing the necessary static routes, which may not be feasible. --- 1. para 6 s/segment routing/SR/ --- 1. para 7 s/[RFC7743] mechanism/The [RFC7743] mechanism/ s/in slow path/on the slow path/ --- 1. para 8 This mechanism uses MPLS path and no changes are required in the forwarding path. I cannot parse this. Maybe s/MPLS path/MPLS LSPs/ ? --- 1. para 8 s/Reply path TLV/Reply Path TLV/ (twice) s/segment routing/SR/ (please check the rest of the doc!) --- 1.1 Nothing wrong with what you have written, but RFC 8402 defines the term "SR domain" and distinguishes it from an "IGP domain". Upon opening your document, I was confused by your use of "domain" until: - Tony Li put me straight - I read section 1.1 I wonder whether there are ways you can make the distinction clearer sooner in the document. --- 1.1 s/Autonomous System (AS)/AS/ --- 2. Please use Title Case for the section header. --- 2. Again, please don't begin the section with a figure. The text needs to make reference to the figure. --- 2. s/Reply path TLV/a Reply Path TLV/ s/in echo reply/in an echo reply --- 3. OLD and PMS/Head-end NEW and a PMS/Head-end END --- 3. s/Reply path TLV/Reply Path TLV/ (please check the rest of the doc) s/Implementations may/Implementations MAY/ (twice) s/Command Line Interface(CLI)/Command Line Interface (CLI)/ sIPV4/IPv4/ s/dual- stack/dual-stack/ --- 4. OLD The motivation has been to keep the definitions same as in [RFC9256] with minimal modifications if it is needed. NEW The intention was to keep the definitions as close to those in [RFC9256] as possible, with modifications only when needed. END --- 4. s/segment sub-TLV/Segment Sub-TLV/ (please check whole doc) --- 4.2 Not all confusing to have TBD1, TBD3, and TBD4 (but no TBD2) :-) Aha! This is because you have a "TBA2" instead. Maybe change TBA to TBD. Except, you also have a TBA1. --- 4.1 The following applies to the Type-1 Segment sub-TLV: I think s/Type-1/Type-A/ Similar issues in 4.2 and 4.3. Also, the section headings should (presumably) be s/Type A/Type-A/ etc. --- 4.1, 4.2, 4.3 Compare the requirements for the Reserved fields. Why are they different? --- 4.2 When the Algo is present it is used to derive the Label. Is that the SID label? How does that conflict with the SID field (if present)? Ditto 4.3 --- 4.4 and 10.2 It's not illegal, it's just a bit odd that you are requesting bit 1 to be assigned and not but 0. Any reason? --- 4.4 Unused bits in the Flag octet SHOULD be set to zero upon transmission and MUST be ignored upon receipt. I think you need this to be MUST be zero on transmission. Otherwise you break the definition of new bits in the future (new bit has meaning but legacy implementation sometimes sets the bit to 1). --- 4.4 A-Flag applies to Segment Types C, D. If A-Flag appears with any other Segment Type, it MUST be ignored. Is this too strong? It may confuse future extensions that want to define new Segment Types and use the A flag. Perhaps all you are concerned about is the use of the A flag with Type-A segments? --- 5. SRv6 dataplane is not in the scope of this document and will be addressed in a separate document. Will it, though? Either s/will/may/ or delete from "and" to the end. --- 6.1 In the inter-AS scenario,the procedures described in this document should be used to specify the return path. Is this "should" or "SHOULD"? You are allowing variation (by using should not must) so you need to say why an implementation/deployment would choose to do something different. --- 6.1 has several acceptable uses of "MUST". But I don't find what a receiver should do if one of these is violated. For example, LSP ping initiator MUST set the Reply Mode of the echo request to 5 So, it the receiver sets a Reply Mode set to another value, what happens? 6.2 might cover this, but doesn't quite. --- 6.3 The responder MAY check the reachability of the top label in its own Label Forwarding Information Base (LFIB) before sending the echo reply. A fine use of MAY, but you should indicate how/why an implementation would make this choice. --- 6.3 In certain scenarios,the head-end may choose to send Type C/Type D segments consisting of IPV4 address or IPv6 address. "may" or "MAY"? Which scenarios and why make that choice? --- 6.3 Optionally SID may also be associated with the Type C/Type D segment. "Optionally" or "It is OPTIONAL"? How is his choice determined? --- 6.3 The reply path return code must be set as described in section 7.4 of [RFC7110]. The Reply Path TLV must be included in an echo reply indicating the specified return path that the echo reply message is required to follow as described in section 5.3 of [RFC7110]. "must" or "MUST"? (twice) --- 6.4 Is it possible that the TTL pre-increment is 255? --- 7. Example topologies given in Figure 1 and Figure 2 will be used I think that your examples here all use ASBRs, so you are actually limiting yourself to Figure 1 except for the final paragraph of 7.2.2? --- 7. IGPs like OSPF/ISIS Are there many IGPs like OSPF and ISIS? -- 7.1 s/mpls/MPLS/ You have some non-ASCII characters --- 7.2.1 You have a couple of cases of "MUST" in this section. But this is an example, not normative text. So I think "will" is good enough. --- 8. and subsections Please use Title Case for the section headings --- 8.1 Is "to traceroute" really a verb leading to the participle "tracerouted"? --- 8.1 This seems very late to be introducing the expansion of ABR which you have used before. --- 8.1 In cases when SRGB is not uniform across the network, it is RECOMMENDED to add a Type C or a Type D segment. Fair enough, but why might an implementation choose to do otherwise and what are the benefits/implications? --- 10.1 You cite "[IANA]" but have no matching reference --- 10.2 I don't think that Figure 7 needs to be a figure. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls
- [mpls] Shepherd review of draft-ietf-mpls-spring-… Adrian Farrel
- Re: [mpls] Shepherd review of draft-ietf-mpls-spr… Adrian Farrel
- Re: [mpls] Shepherd review of draft-ietf-mpls-spr… Shraddha Hegde
- Re: [mpls] +AFs-mpls+AF0- Shepherd review of draf… Adrian Farrel
- Re: [mpls] +AFs-mpls+AF0- Shepherd review of draf… Shraddha Hegde
- Re: [mpls] +AFs-mpls+AF0- Shepherd review of draf… Adrian Farrel
- Re: [mpls] Shepherd review of draft-ietf-mpls-spr… loa