Re: [RTG-DIR] [mpls] Rtgdir early review of draft-ietf-mpls-inband-pm-encapsulation-08
Weiqiang Cheng <chengweiqiang@chinamobile.com> Sat, 24 February 2024 07:48 UTC
Return-Path: <chengweiqiang@chinamobile.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BE8C14F5FE; Fri, 23 Feb 2024 23:48:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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
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 E4Tcjs4F6UAg; Fri, 23 Feb 2024 23:48:55 -0800 (PST)
Received: from cmccmta1.chinamobile.com (cmccmta2.chinamobile.com [111.22.67.135]) by ietfa.amsl.com (Postfix) with ESMTP id 686CCC14F5FD; Fri, 23 Feb 2024 23:48:48 -0800 (PST)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[10.188.0.87]) by rmmx-syy-dmz-app03-12003 (RichMail) with SMTP id 2ee365d99f53146-9a938; Sat, 24 Feb 2024 15:48:45 +0800 (CST)
X-RM-TRANSID: 2ee365d99f53146-9a938
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from chengweiqiang (unknown[223.72.89.102]) by rmsmtp-syy-appsvr01-12001 (RichMail) with SMTP id 2ee165d99f5bd8e-37138; Sat, 24 Feb 2024 15:48:44 +0800 (CST)
X-RM-TRANSID: 2ee165d99f5bd8e-37138
Date: Sat, 24 Feb 2024 15:48:45 +0800
From: Weiqiang Cheng <chengweiqiang@chinamobile.com>
To: Darren Dukes <ddukesietf@gmail.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Cc: "draft-ietf-mpls-inband-pm-encapsulation.all" <draft-ietf-mpls-inband-pm-encapsulation.all@ietf.org>, mpls <mpls@ietf.org>
References: <170873514415.40774.18151433069910014963@ietfa.amsl.com>
X-Priority: 3
X-GUID: CCD4AE8A-589E-4F81-A486-1EEC7E1D2BC3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.25.213[cn]
Mime-Version: 1.0
Message-ID: <2024022415484493865861@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart768688033604_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/PmTUrtXDllXfWflpPbKmdHNQ4oI>
Subject: Re: [RTG-DIR] [mpls] Rtgdir early review of draft-ietf-mpls-inband-pm-encapsulation-08
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Feb 2024 07:48:57 -0000
Dear Darren, Thank you for your detailed review and comments. Co-authors will respond and address these comments promptly. Best, Weiqiang From: Darren Dukes via Datatracker Date: 2024-02-24 08:39 To: rtg-dir@ietf.org CC: draft-ietf-mpls-inband-pm-encapsulation.all; mpls Subject: [mpls] Rtgdir early review of draft-ietf-mpls-inband-pm-encapsulation-08 Reviewer: Darren Dukes Review result: Has Issues I've been assigned as part of the Routing Directorate to review draft-ietf-mpls-inband-pm-encapsulation-08.txt. In reviewing the draft I note it has issues that should be addressed. Review ========================= Section 2: [minor] - line 234-239 says the TTL and TC SHOULD be that of the previous label for the XL and FLI, but MAY be set to other values if they will not be exposed as top of stack. Is there any recommended value for XL and FLI if not that of the preceding label, eg when they cannot appear at top of stack? [minor] - Section 2.1 lines 364-365 Is this an exhaustive list of possible "application label" types? If not it's better to state that these are non-exhaustive examples. [minor] - Section 3 This sentence does not make sense " If the hop-by-hop measurement is applied, i.e., the T bit is set to 0, then whether the transit node or the egress node is the processing node. " [minor] - Section 3 "egress node" is not defined so I cannot tell how an "egress node" knows it's an "egress node" and takes the correction action in bullet 2 of this section. A similar definition for "ingress node" is needed. [major] - Section 3 I do not see any description of the protocol to the external NMS. Is that described in another draft and does it need to be updated for the content in this section? [major] - Section 4 states "There are two ways of allocating Flow-ID" I find this section a bit confusing. The two ways appear to be two examples of how flow-id may be assigned. The only normative text in this section is the last paragraph. What happens if an implementation chooses another means of flow-ID allocation that meets the requirement in the last paragraph? Would it affect interoperability? Would it be non-compliant? Are there more than two ways? [major] - Section 5 FRLD and FLC are needed along a path, but are they not needed in the entire measurement domain along any possible path? If the network reconverges and the PHP is no longer FLC I expect some strange behaviors are possible. Can you clarify this? [major] - Section 6 Can you expand on the ECMP problem with FLI specifically? This section leaves me guessing if it's intended that some packets of a flow contain an FLI and other do not, therefore forcing some packets of a flow on a different path... but I've not understood that up until this section. With these assumptions I don't see how the workarounds in the referenced specification are applicable and it appears specific operation needs to be specified for FLI. [major] - Section 7 I see no text indicating how the multi-measurement-domain FLI value can be solved at ingress, or transit. Is it solvable? Can a packet traverse multiple measurement domains as its SR SID list may cross multiple domains. [minor] - Section 7 What is the boundary of the measurement domain? Is the measurement domain not the entire MPLS domain of an operator? Are there recommendations for operators? [nit] - Section 7 This sentence is ambiguous, can it be simplified like follows ( up to you) ... s/Improper configuration so that the Flow-ID label being passed from one domain to another would likely result in potential Flow-ID conflicts./Improper configuration so the Flow-ID label is passed from one measurement domain to another would result in Flow-ID conflicts./ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls
- [RTG-DIR] Rtgdir early review of draft-ietf-mpls-… Darren Dukes via Datatracker
- Re: [RTG-DIR] [mpls] Rtgdir early review of draft… Weiqiang Cheng
- Re: [RTG-DIR] Rtgdir early review of draft-ietf-m… Weiqiang Cheng
- Re: [RTG-DIR] Rtgdir early review of draft-ietf-m… Darren Dukes
- Re: [RTG-DIR] Rtgdir early review of draft-ietf-m… Weiqiang Cheng