Re: [RTG-DIR] Rtgdir early review of draft-ietf-mpls-inband-pm-encapsulation-08

Darren Dukes <ddukesietf@gmail.com> Tue, 23 April 2024 21:02 UTC

Return-Path: <ddukesietf@gmail.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 2071AC14E513; Tue, 23 Apr 2024 14:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.085
X-Spam-Level:
X-Spam-Status: No, score=-7.085 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_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, T_KAM_HTML_FONT_INVALID=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 (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 GRWjdK7MUCXD; Tue, 23 Apr 2024 14:02:42 -0700 (PDT)
Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (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 3335EC151069; Tue, 23 Apr 2024 14:02:39 -0700 (PDT)
Received: by mail-lf1-x142.google.com with SMTP id 2adb3069b0e04-518a56cdbcfso9566720e87.2; Tue, 23 Apr 2024 14:02:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713906157; x=1714510957; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zGBTA99fqWsO5COWfX4CmC5IaFhvqZZvgGGyap4L3l8=; b=a3v9Rdc2cZpm7+A+lDIA5BAO2BgEJWD6Tlr1Lck/5dkicLaJqwNd3maxwzJHOqQMsg wk966gfUj8Ol4T49eLjTl9/xbuHCefi3oL6U98TD7b6Ouh8FyhmHZyF8a1QQV88NMZW4 2I9pAnCFLfrgUg3KsJMrtGBTFWmWCHUo74nMBUtSjQtVBgZgvHdu3RMJ4pImD5pTWJLj VibD6j0MYmA2IZc/v/y5/9i1YwECWM4uMe0h4SdCGg0jVuxTtNZMba1AVOUMg08OzMYr HnZYbKzvjj6UZtpLqt2+VgHX7K2sN5jewTogS2sF85dzGoCCJd7yUmikfN8h6XfyX5rZ B4pQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713906157; x=1714510957; 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=zGBTA99fqWsO5COWfX4CmC5IaFhvqZZvgGGyap4L3l8=; b=pz/T97D82bvf28TiVp8jU1Yi0qIlhFBRQzUZpvDpzwFDZXJxk62diAwKduaBETYcyS 8ETc9OT8JxT2bmFO1j3ZuqnxJJz6mufQblXrnyXrjIIG5nNyckCQtkpAks7BxHeIpiQN 8zNOmYZR4xH2a2YXlE4CoB0PwlIabhLkvnp317L8gMXec3P2Qot5Ru9cwTvH7S2qIvWZ 7LeaMwgA+XKRakll0iKWZYxKy7O4lZ14GA0jU9YvfIMNG7vx0iCmzw8rFVdpDXe4t+h3 rzKJOsFMq8NQ3qetGLUaZWgZO+2Cr9nhl/fFlT3r8Tg1JoqlH+SZ141ENn5a+vCTfXJ/ I87g==
X-Forwarded-Encrypted: i=1; AJvYcCVTxs1vEYTO/vCkBSc/DnIjWrpp+Ku+9Nj0O3g2nDPiGkUzRccU16huxnTxDvPejthGcN8liOWvSFZEF3aNWaqdaf/Jb09l9KIdN9ylTNI+pC+QiEP0nPDB49R0vdI4rhI4qA7GImJWWWvuXFPl7rtuC1Y7
X-Gm-Message-State: AOJu0YzUuqj7uFmrnI4QgB5ya0oyNScmgdZ4CekhdjZ6EEkg2BNtWfRT xB1VfauFgBn/K3+cx5nvFZyhaHmZ5qbHtZOtI0VoCQbq0Vr/lMeCMrRQtNaMCqjjiP7cNfwdSPV gDtQfGJ1afRyQiCauMEYpwbxRArk4UVHCKPs=
X-Google-Smtp-Source: AGHT+IHp3p2HzHI+hBipoWkrdR/0MP4E/toAwJ4rNDpR8b36YkDWE3/e6SJnSA86GlnMYsgTyT1D3Cq6YLVO6eSrYTA=
X-Received: by 2002:a05:6512:e9f:b0:512:fe25:550b with SMTP id bi31-20020a0565120e9f00b00512fe25550bmr653717lfb.47.1713906157054; Tue, 23 Apr 2024 14:02:37 -0700 (PDT)
MIME-Version: 1.0
References: <170873514415.40774.18151433069910014963@ietfa.amsl.com> <20240301090941644482158@chinamobile.com>
In-Reply-To: <20240301090941644482158@chinamobile.com>
From: Darren Dukes <ddukesietf@gmail.com>
Date: Tue, 23 Apr 2024 17:02:25 -0400
Message-ID: <CAFhLL-aOopTXUNgQKdYNJpkXq+Fev+ec+nZsEApRwxH86uJJvw@mail.gmail.com>
To: Weiqiang Cheng <chengweiqiang@chinamobile.com>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-mpls-inband-pm-encapsulation.all" <draft-ietf-mpls-inband-pm-encapsulation.all@ietf.org>, mpls <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ab739f0616c9df50"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/6IDlOxHCuGsYJbFPW2GLkYQrgWY>
Subject: Re: [RTG-DIR] 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: Tue, 23 Apr 2024 21:02:43 -0000

Weiqiang and authors, sorry for not hitting reply on this email weeks ago!

I've double checked revision 10 and it, along with your comments, resolve
my concerns.

Darren



On Thu, Feb 29, 2024 at 8:09 PM Weiqiang Cheng <
chengweiqiang@chinamobile.com> wrote:

> Hi Darren,
> Thank you very much for your detailed review and comments.
>
> We’ve addressed your feedback in the new Version -10, available at
>
>
> https://www.ietf.org/archive/id/draft-ietf-mpls-inband-pm-encapsulation-10.html
>
>
>
> For specific responses to your comments, please see my inline feedback
> marked as [Weiqiang].
>
> Any comments are welcome.
>
>
> Best Regards,
> Weiqiang
>
>
> Original
> *From: *DarrenDukesviaDatatracker <noreply@ietf.org>
> *To: *rtg-dir@ietf.org <rtg-dir@ietf.org>;
> *Cc: *draft-ietf-mpls-inband-pm-encapsulation.all@ietf.org <
> draft-ietf-mpls-inband-pm-encapsulation.all@ietf.org>;mpls@ietf.org <
> mpls@ietf.org>;
> *Date: *2024年02月24日 08:39
> *Subject: **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?
>
> [Weiqiang] The text was borrowed from section 4.2 of RFC6790 and there are
> no recommended values.
>
>
> [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.
>
> [Weiqiang] This is not an exhaustive list of possible types. The text was
> updated to reflect that.
>
>
> [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. "
>
> [Weiqiang] This sentence was removed.
>
>
> [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.
>
> [Weiqiang] There is definition of MPLS ingress/egress node in RFC3031, so
> the reference to that RFC was added.
>
>
> [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?
>
> [Weiqiang] There is description of the protocols to the external NMS in
> draft-ietf-ippm-alt-mark-deployment, so the reference to that draft was
> added.
>
>
>
> [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?
>
> [Weiqiang] You're absolutely correct the two ways are non-exhaustive. As
> long as the requirement in the last paragraph is met, the interoperability
> can be met and it would be compliant.
>
>
> [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?
>
> [Weiqiang] FRLD and FLC are needed along a path the performance
> measurement is applied to, if the network reconverges, then it's expected
> that the ingress node should stop adding FL until the ingress node confirms
> that FRLD and FLC are met along the new path.
>
>
>
> [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.
>
> [Weiqiang] Yes, section 6 has been expanded. Please check the text update.
>
>
>
> [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.
>
> [Weiqiang] In the real deployment only one domain is involved, so some
> text was added to make multi-measurement-domain scenario out of scope.
>
>
> [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?
>
> [Weiqiang] Some text was added to clarify the boundary of the measurement
> domain.
>
>
>
> [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./
> [Weiqiang] Thank you for the suggested text change, which was applied.
>
>
>