[Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt
Cheng Li <c.l@huawei.com> Wed, 11 September 2024 09:38 UTC
Return-Path: <c.l@huawei.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 5C025C14F71B; Wed, 11 Sep 2024 02:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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_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 L9VOTbi1MEpG; Wed, 11 Sep 2024 02:38:20 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6486AC14F6A2; Wed, 11 Sep 2024 02:38:17 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4X3b3W4pjWz6K6js; Wed, 11 Sep 2024 17:33:27 +0800 (CST)
Received: from lhrpeml100006.china.huawei.com (unknown [7.191.160.224]) by mail.maildlp.com (Postfix) with ESMTPS id 990DD140B38; Wed, 11 Sep 2024 17:38:14 +0800 (CST)
Received: from sinpeml500004.china.huawei.com (7.188.194.107) by lhrpeml100006.china.huawei.com (7.191.160.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 11 Sep 2024 10:38:13 +0100
Received: from frapeml500003.china.huawei.com (7.182.85.28) by sinpeml500004.china.huawei.com (7.188.194.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 11 Sep 2024 17:38:06 +0800
Received: from frapeml500003.china.huawei.com ([7.182.85.28]) by frapeml500003.china.huawei.com ([7.182.85.28]) with mapi id 15.01.2507.039; Wed, 11 Sep 2024 11:38:04 +0200
From: Cheng Li <c.l@huawei.com>
To: "xiong.quan@zte.com.cn" <xiong.quan@zte.com.cn>, "draft-ietf-pce-sr-path-segment@ietf.org" <draft-ietf-pce-sr-path-segment@ietf.org>
Thread-Topic: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt
Thread-Index: AQHbAnLdnkDXF+pE8EKAXxeA9kIw47JPDUWAgAAmVYCAAtK9AIAAUQYA
Date: Wed, 11 Sep 2024 09:38:04 +0000
Message-ID: <ce565cf3d87542d4808f38c9ef49fb81@huawei.com>
References: 20240906172005470rVkrD2uj3_bzEZJX66mUG@zte.com.cn,202409091722532955kF66y1BqnkjWurMD0Hzj@zte.com.cn,633e09a0f80546deba21a1afd91bf0d7@huawei.com <20240911144652862CYyh71ya73mRlw9qXoiOR@zte.com.cn>
In-Reply-To: <20240911144652862CYyh71ya73mRlw9qXoiOR@zte.com.cn>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.70.229]
Content-Type: multipart/alternative; boundary="_000_ce565cf3d87542d4808f38c9ef49fb81huaweicom_"
MIME-Version: 1.0
Message-ID-Hash: T4IYRLOW6XGRZ6ASX4HK4SFOCK7XWWX5
X-Message-ID-Hash: T4IYRLOW6XGRZ6ASX4HK4SFOCK7XWWX5
X-MailFrom: c.l@huawei.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: "pce@ietf.org" <pce@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt
List-Id: Path Computation Element <pce.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/VVBueLNkDqAyprNQ9ioyiGWFdA8>
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>
The update looks good to me. Thank you for your work! Respect, Cheng From: xiong.quan@zte.com.cn <xiong.quan@zte.com.cn> Sent: Wednesday, September 11, 2024 8:47 AM To: Cheng Li <c.l@huawei.com>; draft-ietf-pce-sr-path-segment@ietf.org Cc: dd@dhruvdhody.com; pce@ietf.org Subject: Re: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt Hi Cheng and Co-authors, I have updated the draft as discussed and the diff file is attached. Please review and comment and I will submit it before this weekend! Thanks! Best Regards, Quan Original From: ChengLi <c.l@huawei.com<mailto:c.l@huawei.com>> To: 熊泉00091065;dd@dhruvdhody.com <dd@dhruvdhody.com<mailto:dd@dhruvdhody.com>>; Cc: pce@ietf.org<mailto:pce@ietf.org> <pce@ietf.org<mailto:pce@ietf.org>>;draft-ietf-pce-sr-path-segment@ietf.org <draft-ietf-pce-sr-path-segment@ietf.org<mailto:draft-ietf-pce-sr-path-segment@ietf.org>>; Date: 2024年09月09日 17:42 Subject: RE: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt Hi Quan, Do you mind to lead this update? If yes, please update the xml(You can download it from the datatracker) and share the diff file for authors to review. I am crazy busy on updating 10+ drafts recently. If you can help on this, I will be very appreciated! Thanks, Cheng From: xiong.quan@zte.com.cn<mailto:xiong.quan@zte.com.cn> <xiong.quan@zte.com.cn<mailto:xiong.quan@zte.com.cn>> Sent: Monday, September 9, 2024 11:23 AM To: dd@dhruvdhody.com<mailto:dd@dhruvdhody.com> Cc: jmh.direct@joelhalpern.com<mailto:jmh.direct@joelhalpern.com>; gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>; pce@ietf.org<mailto:pce@ietf.org>; draft-ietf-pce-sr-path-segment@ietf.org<mailto:draft-ietf-pce-sr-path-segment@ietf.org> Subject: Re: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt Hi Dhruv and Joel, Thanks for your suggestion! The adding texts in my last email mainly clarify the path segment related parameters (e.g association) within an SR policy. I think the PCE communicates with the tail instead of a notification, for example, as figure 3 shown, it send PCInitiate message to the egress PCC for PCE tail notification, for example, as figure 3 shown. I agree that the path segment is the first function that requires communication with both tail and head end cause the the path segment should be inserted at the ingress PCC and should be recognized at the egress PCC. From my understanding, the section 3 has described the operations, as per https://www.ietf.org/archive/id/draft-ietf-pce-sr-path-segment-10.html#name-overview-of-path-segment-ex, the path segment can be allocated by egress PCC or PCE. A, If it is allocated by the egress PCC as per section 5.1, the PCE (or ingress PCC first sends requests to the PCE) should request a path segment from egress PCC and notify the ingress PCC. B, If it is allocated by the PCE as per section 5.2, the PCE should allocate a path segment and notify both ingress and egress PCC. Would it be better to clarify it clearly in section 3 like following shown? "There are various modes of operations, such as • The Path Segment can be allocated by Egress PCC. The PCE should request the Path Segment from egress PCC by PCInitiate messge and notify the ingress PCC bu PCUpd messge as per section 5.1.2. • The PCE (or the ingress PCC requests the path segment to PCE) can allocate a Path Segment on its own accord and inform the ingress/egress PCC by PCInitiate or PCUpd messge as per section 5.2.2. • Ingress PCC can also request PCE to allocate the Path Segment, in this case, the PCE would either allocate and inform the assigned Path Segment to the ingress/egress PCC using PCInitiate or PCUpd message, or first request egress PCC for Path Segment and then inform it to the ingress PCC as per 5.1.1. " What is your thoughts? Best, Quan Original From: DhruvDhody <dd@dhruvdhody.com<mailto:dd@dhruvdhody.com>> To: Joel Halpern <jmh.direct@joelhalpern.com<mailto:jmh.direct@joelhalpern.com>>; Cc: 熊泉00091065;gregimirsky@gmail.com <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>;pce@ietf.org <pce@ietf.org<mailto:pce@ietf.org>>;draft-ietf-pce-sr-path-segment@ietf.org <draft-ietf-pce-sr-path-segment@ietf.org<mailto:draft-ietf-pce-sr-path-segment@ietf.org>>; Date: 2024年09月09日 12:43 Subject: Re: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt Hi Joel, On Fri, Sep 6, 2024 at 7:22 PM Joel Halpern <jmh.direct@joelhalpern..com<mailto:jmh.direct@joelhalpern..com>> wrote: > These references appear useful. There is however one aspect that I am > missing. It may well be my own mistake, rather than a problem in the > draft. The usage of the sr path segment relies on the tail of the path > being able to recognize the path segment label. I am not familiar with any > usage of PCE that communicates path information to the LSP tail end, rather > than the head end. Looking at the drat you point to in these changes, I do > not see any addition of tail notification. Is there already a PCE tail > notification that I have forgotten about? > There is a PCECC model RFC 9050 that communicates with all nodes (including the tail) along the path, so there is some precedence. But the path segment draft is the first one that requires communication with the tail end ( https://www.ietf.org/archive/id/draft-ietf-pce-sr-path-segment-10.html#figure-3) outside of the PCECC model. Authors, I suggest that your draft should highlight this explicitly rather than it being buried in a subsection. Thanks! Dhruv > Thank you, > > Joel > On 9/6/2024 5:20 AM, xiong.quan@zte.com.cn<mailto:xiong.quan@zte.com.cn> wrote: > > > Hi Greg, Joel and all, > > > Thanks for your discussion on the MPLS mailing list as following link > shown~ > > https://mailarchive.ietf.org/arch/msg/mpls/e3CI8xeDN1OTu5FgAIB6tI_yRaY/ > > > Allow me to take the discussion to PCE. As per RFC9545 and > draft-ietf-spring-srv6-path-segment, a path segment can identify a SR path, > a SR policy, a candidate-path or a SID-List in a SR policy. But this > document did not mention the path segment processing within SR policy PCEP > instantiation. It may cause some misunderstandings about PCEP processes and > parameters for path segment within a SR policy. So I suggest to add > some texts for next version of this draft. Please see inline with > <suggested text>. > > > 1 Introduction > > [RFC8664] specifies extensions to the Path Computation Element > Protocol (PCEP) [RFC5440] for SR networks, that allow a stateful PCE to > compute and initiate SR-TE paths, as well as a PCC to request, report or > delegate SR paths. *<suggested text>* *"[ietf-pce-segment-routing-policy-cp] > specifies the PCEP extension to signal candidate paths of the SR Policy
- [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segm… xiong.quan
- [Pce] I-D Action: draft-ietf-pce-sr-path-segment-… internet-drafts
- [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segm… Joel Halpern
- [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segm… Dhruv Dhody
- [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segm… xiong.quan
- [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segm… Cheng Li
- [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segm… Joel Halpern
- [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segm… xiong.quan
- [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segm… Cheng Li
- [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segm… Dhruv Dhody
- [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segm… Cheng Li
- [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segm… xiong.quan
- [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segm… Dhruv Dhody