[Pce] Re: Path segment supporting multiple segment lists in a candidate path

Dhruv Dhody <dhruv.ietf@gmail.com> Wed, 25 September 2024 12:40 UTC

Return-Path: <dhruv.ietf@gmail.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 A70EDC1CAF2A; Wed, 25 Sep 2024 05:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, 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
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 GxvJjR_XFnLB; Wed, 25 Sep 2024 05:40:03 -0700 (PDT)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 A8B12C169404; Wed, 25 Sep 2024 05:40:03 -0700 (PDT)
Received: by mail-vs1-xe2d.google.com with SMTP id ada2fe7eead31-49bd76fa981so2617021137.3; Wed, 25 Sep 2024 05:40:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727268002; x=1727872802; 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=MAKZRY8rPKb5wz3G2uytWKLS4XkSUVEZ89lGRVBZoMk=; b=Q2pkVulHjegbMLmvkevGDmSzHcOClWNkYBwIDuQ0GK+5KowfKl5UbOSqU3Cs08ZQ7q PHYIYyxMf7GE3oJdCiisuvHlR1C1R1PdYZm9Isu9XavcNg2Xh4OYL+Nksh9drhmOAdkA kjl5Ot8nonlbS3CpIoeuC7rY7d9YMZ1lCbgOuR4t9WyGmSJKA0TUWuT/t2mPwdRlF3xJ nZHcHRm7nB2drvsh2yxfdlUw9KD6rhlDArwcCRAob7E+FCWxe1CRcHXPViqzcWXSA1t8 IGWxfx3y6wZOu0+7Tc+gviFAmcwG0XiQrZqZf1MKGiKptzK/dxaPCTUieWpvC8C/Sy6a /cPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727268002; x=1727872802; 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=MAKZRY8rPKb5wz3G2uytWKLS4XkSUVEZ89lGRVBZoMk=; b=eUE+Ggw9AM9/GlLKN1QV/wgptKsuAk/Qq1oCSS7yCjgv3URZuXx5xT/jJ1yplFoPh4 Zcvjlo/1mlAdwM0UOqx8vpZ9A0JlkwzhS/huXlZxoil4YkFl+uIYlt00aaX1f/6sIian qMMINANhTizDnhs2a5GzQbfgGgsBsXYkfpTjKwi5IGHv+8KB5uTSM3ETdORlVzoZN+MZ OMn2in0T3pIHArH92ZYQdtDX4IpJ3eGsibVDCM7SoTBxhMc7C13hseWTowuf9MGmNNsn 709oh97zjF3LcY9zoDKouFmCamuSWZxYcgbDWxWpywLPjzP8Kz6xO0XoYiqAJs+N3NDN /aQw==
X-Forwarded-Encrypted: i=1; AJvYcCVT1Dg7Oh8FXUejkl0miBij2H5e6xG9a7Wg7PtJFj64tPnnKC3RsGPUGQT137n2DG1g8yjh@ietf.org, AJvYcCWJN/ZXlf1vdjo2P+DOBbtya3ee4yQpkDubuy7+nvNWri9DhWC4PYg/30RybjskvPUhxx3cvgEyuF3DEAGZ++KSIA7C0yzNMt8Y1iaqKLU=@ietf.org
X-Gm-Message-State: AOJu0YyuW01fHdef13TKSNAO2vF2hZXSThLbgYkZuUiCMm3A0cC7gnRn MA2/h5NFPmEBSp8fjwTnVmGmlpQ1SqOFtv+jcz6evIXf+/av/KX4EHqqfeCyfsjvc6mpjRsDH3F Sg85FGzok3vSeQ32aaobfpiD+MTYfHTP7
X-Google-Smtp-Source: AGHT+IHNtAGQjm2+4qRdSoslFHFAy5VbCCCkCImV/nUE5ME87eQ3lKE9TENmnB/rfDlGQALhNMo1qGhzxU9vS79spSg=
X-Received: by 2002:a05:6102:549f:b0:497:6d56:3073 with SMTP id ada2fe7eead31-4a15dc643cdmr2437576137.7.1727268002173; Wed, 25 Sep 2024 05:40:02 -0700 (PDT)
MIME-Version: 1.0
References: <09d7e4afdb9a4291b781b7cca39a8ef4@huawei.com> <20240924154117702ex4ibZSddhvUhQ3RztZOD@zte.com.cn>
In-Reply-To: <20240924154117702ex4ibZSddhvUhQ3RztZOD@zte.com.cn>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Wed, 25 Sep 2024 18:09:24 +0530
Message-ID: <CAB75xn5=zp00Kkb4Lx7r9ddReNQVGFV00G8sbbvfw71OmOVBwA@mail.gmail.com>
To: xiong.quan@zte.com.cn
Content-Type: multipart/alternative; boundary="000000000000b39a6f0622f0eb16"
Message-ID-Hash: 3EMIIQQMY2JOX7UYHHGNZUAHTZOCHKC2
X-Message-ID-Hash: 3EMIIQQMY2JOX7UYHHGNZUAHTZOCHKC2
X-MailFrom: dhruv.ietf@gmail.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, draft-ietf-pce-sr-path-segment@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Pce] Re: Path segment supporting multiple segment lists in a candidate path
List-Id: Path Computation Element <pce.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/Tvl1w5Fz9ZIB4Y_7Q0W6b9JPDg8>
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 Quan,

On Tue, Sep 24, 2024 at 1:11 PM <xiong.quan@zte.com.cn> wrote:

>
> Hi Cheng,
>
>
> Thanks for your suggestion!
>
>
> Got it about the PSID.
>
> And I also agree with the P flag in LSP. So I suggest to clarify it and
> the adding text may be as following shown.
>
>
> 4.5. Path Attributes Object
>
>
>        The [I-D.ietf-pce-multipath] defines the PATH-ATTRIB object, which
> carries
>
>         per-path information and serves as a separator between multiple
> ERO/RRO
>
>         objects, enabling the encoding of multiple segment lists in a
> Candidate
>
>         Path, as described in [I-D.ietf-pce-segment-routing-policy-cp].
> The Path
>
>         Segment TLV can be optionally included in the PATH-ATTRIB object to
>
>         associate a segment list with the Path Segment Identifier(PSID).
> It’s
>
> important to note that the Path Segment TLV in the PATH-ATTRIB object
>
>        applies to the path (the immediately following ERO/RRO), whereas
> the Path
>
> Segment TLV in the LSP object applies to all paths in the PCEP message.
>
> If the PSID is encoded in the PATH-ATTRIB object, it MUST be used to
>
> identify the SR path. The P flag in LSP Object is also used to indicate
>
>         that the allocations of all PSIDs need to be done by the PCE.
>
>
>
Dhruv: Can I suggest changing the last sentence to make it generic -

The usage of P flag in the LSP object for Path Segment as
specified in Section 4.2 also applies to all PSIDs encoded
in the PATH-ATTRIB object.

And in section 4.2, you can remove " in the LSP object", to keep the text
generic and thus apply to TLV in both LSP object and PATH-ATTRIB object.

Thanks!
Dhruv


> Thanks,
>
> Quan
>
>
> Original
> *From: *ChengLi <c.l@huawei.com>
> *To: *熊泉00091065;dhruv.ietf@gmail.com <dhruv.ietf@gmail.com>;
> *Cc: *pce@ietf.org <pce@ietf.org>;draft-ietf-pce-sr-path-segment@ietf.org
> <draft-ietf-pce-sr-path-segment@ietf.org>;
> *Date: *2024年09月23日 16:20
> *Subject: **RE: [Pce] Re: Path segment supporting multiple segment lists
> in a candidate path*
>
> Hi Quan,
>
>
>
> PSID(Path Segment ID) was defined in RFC9545 originally, and introduced in
> SRv6 draft, so it can apply to SR-MPLS and SRv6.
>
>
>
> Reusing P flag in LSP is better to me, make it as general, indicating PSID
> allocation request, no matter where the Path Segment TLV will be encoded.
>
>
>
> My 2cents,
>
> Cheng
>
>
>
>
>
> *From:* xiong.quan@zte.com.cn <xiong.quan@zte.com.cn>
> *Sent:* Monday, September 23, 2024 4:59 AM
> *To:* dhruv.ietf@gmail.com
> *Cc:* Cheng Li <c.l@huawei.com>; pce@ietf.org;
> draft-ietf-pce-sr-path-segment@ietf.org
> *Subject:* Re: [Pce] Re: Path segment supporting multiple segment lists
> in a candidate path
>
>
>
> Hi Dhruv,
>
>
>
> Thanks for your reply!
>
>
>
> I will take your suggestion for the new version. But I have two concerns.
>
> The PSID is defined as "SRv6 Path Segment Identifier" in
> draft-ietf-spring-srv6-path-segment and it is not mentioned in this
> documents , cause path segment should cover both SR-MPLS and SRv6. So I
> suggest we still use the path segment instead of PSID.
>
> Another concern is that,  for example, when we put multiple path segment
> TLVs in multiple PATH-ATTRIB objects but none in LSP object in PCInitiate
> message,  we also need to indicate PCE or egress PCC to allocate the path
> segment. There may be two options, reusing P flag in LSP object to indicate
> all path segment TLVs or creating a new P flag in PATH-ATTRIB object
> to indicate each path segment TLV. So I think we need to clarify it.
>
>
>
> What is your thoughts? Thanks!
>
>
>
> Best Regards,
>
> Quan
>
>
>
>
>
> Original
>
> *From: *DhruvDhody <dhruv.ietf@gmail.com>
>
> *To: *Cheng Li <c.l=40huawei.com@dmarc.ietf.org>;
>
> *Cc: *熊泉00091065;pce@ietf.org <pce@ietf.org>;
> draft-ietf-pce-sr-path-segment@ietf.org <
> draft-ietf-pce-sr-path-segment@ietf.org>;
>
> *Date: *2024年09月20日 20:15
>
> *Subject: Re: [Pce] Re: Path segment supporting multiple segment lists in
> a candidate path*
>
> Hi Cheng,  Quan,
>
>
>
> On Fri, Sep 20, 2024 at 2:52 PM Cheng Li <c.l=40huawei.com@dmarc.ietf.org>
> wrote:
>
> Hi Quan,
>
> Thank you for proposing the text. Please see my comment below.
>
> Thanks,
>
> Cheng
>
>
>
> 4.5.  Path Attributes Object
>
>
>
>    The Path Attributes (PATH-ATTRIB) Object is used to carry per-path
>
>    information and to act as a separator between several ERO/RRO objects
>
>    as per [I-D.ietf-pce-multipath].
>
> As per [RFC9545], a Path Segment can be used to uniquely identify a
>
>    segment list or multiple segment lists in a candidate path or an SR
>
>    policy.
>
> __OLD__
>
> When a set of path segments are used to identify multiple
>
>    segment lists, the Path Segment TLV as described in the
>
>    Section 4.2.1, MUST be carried in the PATH-ATTRIB Object to indicate
>
>    the per-SR-path information regarding the Path Segment identifier.
>
> __OLD__
>
> [Cheng]This might be rephrased. My suggestion.
>
> When multiple ERO/RRO objects are included as per
> [I-D.ietf-pce-multipath], to support multiple segment lists in an Candidate
> Path [ref to SR policy draft], the Path Segment TLV as described in the
> Section 4.2.1, MUST be carried in the PATH-ATTRIB Object to identify each
> SR path associated with a segment list.
>
>
>
> Dhruv: This use of MUST here means that if a PATH-ATTRIB Object exists,
> the Path Segment TLV MUST be encoded in it. But we want to do that only in
> case when a different PSID is used by each segment list.
>
>
>
>
>
> The P flag in LSP Object is used to indicate that the allocation of all
> path segments need to be done by the PCE. A Path Segment TLV encoded in
> the LSP Object apply to all the ERO/RRO, while a Path Segment TLV encoded
> in a PATH-ATTRIB Object only apply to its ERO. In the cases that all the
> segment lists are sharing a same PSID, the Path Segment TLV can be carried
> in the LSP Object or each PATH-ATTRIB Object, respectively.
>
>
>
>
>
> Dhruv: I am unsure why we need to highlight the P flag here. The rest of
> the text makes sense if we set or unset the P flag.
>
>
>
> Here is my suggestion -
>
>
>
> The [I-D.ietf-pce-multipath] defines the PATH-ATTRIB object, which carries
> per-path information and serves as a separator between multiple ERO/RRO
> objects, enabling the encoding of multiple segment lists in a Candidate
> Path, as described in [I-D.ietf-pce-segment-routing-policy-cp]. The Path
> Segment TLV can be optionally included in the PATH-ATTRIB object to
> associate a segment list with the PSID. It’s important to note that the
> Path Segment TLV in the PATH-ATTRIB object applies to the path (the
> immediately following ERO/RRO), whereas the Path Segment TLV in the LSP
> object applies to all paths in the PCEP message. If the PSID is encoded in
> the PATH-ATTRIB object, it MUST be used to identify the SR path.
>
>
>
> Thanks!
>
> Dhruv
>
>
>
>
>
> *From:* xiong.quan@zte.com.cn <xiong.quan@zte.com.cn>
> *Sent:* Friday, September 20, 2024 10:59 AM
> *To:* pce@ietf.org
> *Cc:* draft-ietf-pce-sr-path-segment@ietf.org
> *Subject:* Path segment supporting multiple segment lists in a candidate
> path
>
>
>
>
>
> Hi PCE WG,
>
>
>
> A new version has been submitted as per
> https://www.ietf.org/archive/id/draft-ietf-pce-sr-path-segment-11.txt.
>
>
>
> But in case of supporting multiple segment lists in a candidate path, it
> is required to add Path Segment TLV into Path Attributes Object as
> different path segment may identify different segment list . And in order
> to make it backward compatible to current implementation, it needs to allow
> carrying the TLV in both LSP and PATH-ATTRIB object. So I suggest to add a
> new section to describe this part of extension as following shown.
>
>
>
>
>
> 4.5.  Path Attributes Object
>
>
>
>    The Path Attributes (PATH-ATTRIB) Object is used to carry per-path
>
>    information and to act as a separator between several ERO/RRO objects
>
>    as per [I-D.ietf-pce-multipath].
>
>
>
>    As per [RFC9545], a Path Segment can be used to uniquely identify a
>
>    segment list or multiple segment lists in a candidate path or an SR
>
>    policy.  When a set of path segments are used to identify multiple
>
>    segment lists, the Path Segment TLV as described in the
>
>    Section 4.2.1, MUST be carried in the PATH-ATTRIB Object to indicate
>
>    the per-SR-path information regarding the Path Segment identifier.
>
>    The P flag in LSP Object is used to indicate that the allocation of
>
>    all path segments need to be done by the PCE.  When one single path
>
>    segment is used to identify all segment lists, the Path Segment TLV
>
>    MAY be carried in the LSP Object or PATH-ATTRIB Object.  But the Path
>
>    Segment TLV MUST be ignored in the LSP Object when it is also
>
>    included in the PATH-ATTRIB Object.
>
>
>
> What is your thoughts? Any comments and suggestions are welcome. Thanks!
>
>
>
> Best Regards,
>
> Quan
>
>
>
>
>
> _______________________________________________
> Pce mailing list -- pce@ietf.org
> To unsubscribe send an email to pce-leave@ietf.org
>
>
>
>
>