[Pce] Re: I-D Action: draft-ietf-pce-pcep-extension-native-ip-35.txt

Dhruv Dhody <dd@dhruvdhody.com> Thu, 22 August 2024 17:20 UTC

Return-Path: <dd@dhruvdhody.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D78C14F6BF for <pce@ietfa.amsl.com>; Thu, 22 Aug 2024 10:20:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=dhruvdhody-com.20230601.gappssmtp.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 f3QNLpE4uWDy for <pce@ietfa.amsl.com>; Thu, 22 Aug 2024 10:20:48 -0700 (PDT)
Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com [IPv6:2001:4860:4864:20::36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D832C14F5E3 for <pce@ietf.org>; Thu, 22 Aug 2024 10:20:48 -0700 (PDT)
Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-268d0979e90so149754fac.3 for <pce@ietf.org>; Thu, 22 Aug 2024 10:20:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20230601.gappssmtp.com; s=20230601; t=1724347247; x=1724952047; 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=DiqPKu5I4HMxeHIXFsEBZ7s+esS0ZX5pzUCbrxkcGfU=; b=hxeIUaSoY56XCGSyT41l6yW93YNv3o+H9jUchs5Tm3wuepV9Z7HUd3soP3vI2f7C5i w+JGiLTzveu4jPOLHj9xKyUasRSG3qxS/tzhAyMkci9hZEaWiJ2T99+EjBVgG2xkGIt7 RdNc5plKo2NzJpB17VbH7LJsSnLpJRhTcLtC8hW976XvJCoa7ENjxWdtZW1OEQUjAo20 4YWMqJoc3MWJLly4Sb1xD7uAM+dPMldvNv7YTkBee8fVfbfVSh23eUyBr9aVVbhSrgFb L5183jujo0ppWelXjEV6Dl/o6OIREJ3B3Ai9aHp7W347Ye0kIXGW01N1We12xUaiHzLE v6zQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724347247; x=1724952047; 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=DiqPKu5I4HMxeHIXFsEBZ7s+esS0ZX5pzUCbrxkcGfU=; b=Yv4y6saS7JoEIW5GvSELo8/Ggtu6l2ozGORNpTEt7En7vrHFUHdPMsMhhjwK3UghM8 sHvw8O2ihfZaa/w07R1o/sZJ0vJfIhxo/2GHsD7PkDPSX9iJINHSSC5p1+x/NPC0DeP/ icKXNyygVF/3fFcj7f1McXra0Mpl7FOnSIcvcuhzLi9KdTPgz/UDdKgpF01M4mut9g8m AyzYDCVHBnJc8prVheSjo4Ot0fB9xWS4BOaMvvKZ+ZWEg00fJsHZCzQprCRAAnK9gCuh xq5yMr924G4ACu+NOyQ0kpY0ZcT8frQM4+e2zo8TJO3ouvfR5/jgsPdpsCncGRa/ykpn JLGw==
X-Forwarded-Encrypted: i=1; AJvYcCVUyckMU6fghpWMD2/O0lUIMIGpjho5uPU0keHiQSxlGeIGx8xGAhN6kEGUaM/aB8sQTgM=@ietf.org
X-Gm-Message-State: AOJu0Yx8AZcyoXgc3skJpbVhbDBru1CvWgI6O7hR6P6chW7KK46IAlsz OX8UTfrpCA4/SQkEXkcmCBAuT89vicpbqof5pTpeHIKUj9Icr4APNwYFIYQ+x5/bsFcBKgwEAdR QhUz5p3O9KaHKOFLomLwMrRa5+rKhyAAXQIC3t4qUBU4lAqMN3Zg=
X-Google-Smtp-Source: AGHT+IH0y+tkecckqnrKfiwcP0Gr72mVL7ZOQcVcnvhf0xEtiIBLE2UhW1Y4B912beWxRl3SGcU9lXervU7uUsXkmvI=
X-Received: by 2002:a05:6870:5491:b0:260:e907:4646 with SMTP id 586e51a60fabf-2737ef08cfamr4253822fac.4.1724347247466; Thu, 22 Aug 2024 10:20:47 -0700 (PDT)
MIME-Version: 1.0
References: <172432075598.2526122.11479092311358998224@dt-datatracker-6df4c9dcf5-t2x2k> <007f01daf47a$df507370$9df15a50$@tsinghua.org.cn>
In-Reply-To: <007f01daf47a$df507370$9df15a50$@tsinghua.org.cn>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Thu, 22 Aug 2024 22:50:10 +0530
Message-ID: <CAP7zK5ZBBVm3YSGk4Szmko-jsm1DbLdZP2b5yu1nkQsi6Ehekw@mail.gmail.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Content-Type: multipart/alternative; boundary="00000000000027b6da062048e115"
Message-ID-Hash: VRANVV2ZQCGLLXIXAV6MZJZBGMY6TKRH
X-Message-ID-Hash: VRANVV2ZQCGLLXIXAV6MZJZBGMY6TKRH
X-MailFrom: dd@dhruvdhody.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pce.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: The IESG <iesg@ietf.org>, pce@ietf.org, draft-ietf-pce-pcep-extension-native-ip@ietf.org, pce-chairs@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Pce] Re: I-D Action: draft-ietf-pce-pcep-extension-native-ip-35.txt
List-Id: Path Computation Element <pce.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/MJoOa0e0rc2cScPcWjZU6jIS-vg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Owner: <mailto:pce-owner@ietf.org>
List-Post: <mailto:pce@ietf.org>
List-Subscribe: <mailto:pce-join@ietf.org>
List-Unsubscribe: <mailto:pce-leave@ietf.org>

Hi Aijun,

Apart from the global replacement of should/SHOULD, I also noticed the
following issues in -35.

(1) Abstract

To handle Gunter's comment, you made the following change.

17      Abstract
> 18
> 19         This document defines the Path Computation Element Communication
> 20         Protocol (PCEP) extension for Central Control Dynamic Routing
> (CCDR)
> 21         based applications in Native IP networks.  It describes the key
> 22         information that is transferred between the Path Computation
> Element
> 23         (PCE) and the Path Computation Clients (PCC) to accomplish the
> End-
> 24         to-End (E2E) traffic assurance in the Native IP network under
> PCE as
> 25         a central controller (PCECC).
>
> [minor]
> an alternate proposal for abstract easier to digest and read for people
> with less PCEP awareness. Please use or ignore as you find useful
>
> "
> This document defines extensions to the Path Computation Element
> Communication Protocol (PCEP) to support the computation of paths for
> native IP traffic. The proposed extensions enable a Path Computation
> Element (PCE) to calculate and manage paths for native IP networks,
> enhancing the capabilities of PCEP beyond traditional MPLS and GMPLS
> networks. By introducing new PCEP objects and procedures, this document
> allows for the efficient use of IP network resources and supports the
> deployment of traffic engineering in native IP environments. "
>
> 【WAJ】Have updated the document accordingly.
>

I suggest the following rewording, hope this works for you and Gunter.

This document introduces extensions to the PCE Communication Protocol
(PCEP) to support path computation in native IP networks through a
PCE-based central control mechanism known as Centralized Control Dynamic
Routing (CCDR). These extensions empower a PCE to calculate and manage
paths specifically for native IP networks, expanding PCEP’s capabilities
beyond its traditional use in MPLS and GMPLS networks. By implementing
these extensions, IP network resources can be utilized more efficiently,
facilitating the deployment of traffic engineering in native IP
environments.

(2) Thanks for adding normative reference to [I-D.ietf-pce-iana-update],
but you should also refer to it in Section 13.2. I suggest adding the
following note -

Editorial Note (To be removed by RFC Editor): This experimental track
document is allocating a code point in the registry under the
standards action registry which is not allowed.
[I-D.ietf-pce-iana-update] updates the registration policy to IETF
review allowing for this allocation. Note that an early allocation was
made when the document was being progressed in the standards track. At
the time of publication, please remove this note and the reference to
[I-D.ietf-pce-iana-update].


(3) Please move RFC 3209 and RFC 5036 to Informative references.

(4) There is an inconsistent use of lowercase "bytes" and "Byte".

(5) Section 7.2, s/IP address MUST be one unicast address and/IP address
MUST be a unicast address and/

(6) Section 5, you removed the mention of SRP and LSP in error handling.
Note that section 6.1. of RFC 9050 does mention error handling for missing
SRP, LSP objects alongside CCI objects. I saw Gunter's comment but I dont
think the suggestion was that the other objects should be removed.

Thanks!
Dhruv (Doc Shepherd)




On Thu, Aug 22, 2024 at 3:36 PM Aijun Wang <wangaijun@tsinghua.org.cn>
wrote:

> Hi, All experts:
>
> I have uploaded the updated version of the IESG WGLC document, and wish it
> address all the comments received until now.
> If there is still any existing comments not solved, or new comments,
> please let me know.
>
> I also removed the original section for the implementation considerations.
>
> Thanks all you for your careful reviews and suggestions!
>
>
> Best Regards
>
> Aijun Wang(on behalf of all authors of this document)
>
>
>
>
> -----邮件原件-----
> 发件人: forwardingalgorithm@ietf.org [mailto:forwardingalgorithm@ietf.org]
> 代表 internet-drafts@ietf.org
> 发送时间: 2024年8月22日 17:59
> 收件人: i-d-announce@ietf.org
> 抄送: pce@ietf.org
> 主题: [Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-35.txt
>
> Internet-Draft draft-ietf-pce-pcep-extension-native-ip-35.txt is now
> available. It is a work item of the Path Computation Element (PCE) WG of
> the IETF.
>
>    Title:   Path Computation Element Communication Protocol (PCEP)
> Extensions for Native IP Networks
>    Authors: Aijun Wang
>             Boris Khasanov
>             Sheng Fang
>             Ren Tan
>             Chun Zhu
>    Name:    draft-ietf-pce-pcep-extension-native-ip-35.txt
>    Pages:   37
>    Dates:   2024-08-22
>
> Abstract:
>
>    This document defines extensions to the Path Computation Element
>    Communication Protocol (PCEP) to support the computation of paths for
>    native IP traffic.  The proposed extensions enable a Path Computation
>    Element (PCE) to calculate and manage paths via Path Computation
>    Client (PCC)for native IP networks, enhancing the capabilities of
>    PCEP beyond traditional MPLS and GMPLS networks.  By introducing new
>    PCEP objects and procedures, this document allows for the efficient
>    use of IP network resources and supports the deployment of traffic
>    engineering in native IP environments.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
>
> There is also an HTMLized version available at:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-35
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-pcep-extension-native-ip-35
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> Pce mailing list -- pce@ietf.org
> To unsubscribe send an email to pce-leave@ietf.org
>
>