[Pce] Re: Where the Controlled ID info shuold be carried/encoded?

Cheng Li <c.l@huawei.com> Tue, 02 July 2024 09:20 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 286C5C1516F3 for <pce@ietfa.amsl.com>; Tue, 2 Jul 2024 02:20:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level:
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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] autolearn=unavailable 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 XR5wE7fPbLV7 for <pce@ietfa.amsl.com>; Tue, 2 Jul 2024 02:20:07 -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 0C991C14F69D for <pce@ietf.org>; Tue, 2 Jul 2024 02:20:07 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4WCy5f6DFYz6K6Gv for <pce@ietf.org>; Tue, 2 Jul 2024 17:19:02 +0800 (CST)
Received: from lhrpeml500006.china.huawei.com (unknown [7.191.161.198]) by mail.maildlp.com (Postfix) with ESMTPS id CF3EB140B55 for <pce@ietf.org>; Tue, 2 Jul 2024 17:20:02 +0800 (CST)
Received: from kwepemf200010.china.huawei.com (7.202.181.236) by lhrpeml500006.china.huawei.com (7.191.161.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Tue, 2 Jul 2024 10:20:01 +0100
Received: from dggpemf500009.china.huawei.com (7.185.36.50) by kwepemf200010.china.huawei.com (7.202.181.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 2 Jul 2024 17:19:59 +0800
Received: from dggpemf500009.china.huawei.com ([7.185.36.50]) by dggpemf500009.china.huawei.com ([7.185.36.50]) with mapi id 15.02.1544.011; Tue, 2 Jul 2024 17:19:59 +0800
From: Cheng Li <c.l@huawei.com>
To: "Samuel Sidor (ssidor)" <ssidor=40cisco.com@dmarc.ietf.org>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: Where the Controlled ID info shuold be carried/encoded?
Thread-Index: AdrC9mo3AtPUfqOjT9WSdNJIu0kPGQFrV5KAACW3u+AAEla4IA==
Date: Tue, 02 Jul 2024 09:19:59 +0000
Message-ID: <255d8fc7aeae478fb706bd5513b3e281@huawei.com>
References: <c7083e8f89e74d4fa9985842b4c0e8b5@huawei.com> <fb95526175714f17a93586a57b45438b@huawei.com> <IA0PR11MB7792C4DA179086C313551703D0D02@IA0PR11MB7792.namprd11.prod.outlook.com>
In-Reply-To: <IA0PR11MB7792C4DA179086C313551703D0D02@IA0PR11MB7792.namprd11.prod.outlook.com>
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_255d8fc7aeae478fb706bd5513b3e281huaweicom_"
MIME-Version: 1.0
Message-ID-Hash: ZZAUJDLTDBEUWJZ3H6B63ZHP2J3GUDQ2
X-Message-ID-Hash: ZZAUJDLTDBEUWJZ3H6B63ZHP2J3GUDQ2
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
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Pce] Re: Where the Controlled ID info shuold be carried/encoded?
List-Id: Path Computation Element <pce.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/fVeVrdquVuC659ghUhGBzO0ZUq4>
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 Samuel,

Thank you so much for your suggestions. Good input.
Let’s wait for others’ POV.

I also requested for a slot to discuss this, if people do not have the time to write some emails.

Thanks,
Cheng


From: Samuel Sidor (ssidor) <ssidor=40cisco.com@dmarc.ietf.org>
Sent: Friday, June 28, 2024 11:19 AM
To: Cheng Li <c.l@huawei.com>; pce@ietf.org
Subject: RE: Where the Controlled ID info shuold be carried/encoded?

Hi Cheng,

Sorry for delayed response.


  1.  PCOpen
I would personally prefer to decouple PCEP session from ID space advertisement as there is no logical connection between them, so to me this option seems to be least preferred one.

  1.  Use PCEP-LS encoding and make this a node attribute
I’m fine with using PCEP-LS encoding, but ideally without requiring full support of PCEP-LS draft as that dependency may be too big for vendors, which does not need to support it, but still want to exchange some specific ID space

  1.  New type of notification
  2.  New message/object
I’m fine with both options above, but completely new message type may be cleaner approach, ideally with some message type, which can be re-used in the future (not too specific for this usecase).

Thanks a lot,
Samuel

From: Cheng Li <c.l=40huawei.com@dmarc.ietf.org<mailto:c.l=40huawei.com@dmarc.ietf.org>>
Sent: Thursday, June 27, 2024 5:09 PM
To: Cheng Li <c.l=40huawei.com@dmarc.ietf.org<mailto:c.l=40huawei.com@dmarc.ietf.org>>; pce@ietf.org<mailto:pce@ietf.org>
Subject: [Pce] Re: Where the Controlled ID info shuold be carried/encoded?

Echo request 😊

Hope to have your valuable suggestions!

Thanks,
Cheng


From: Cheng Li <c.l=40huawei.com@dmarc.ietf.org<mailto:c.l=40huawei.com@dmarc.ietf.org>>
Sent: Thursday, June 20, 2024 11:46 AM
To: pce@ietf.org<mailto:pce@ietf.org>
Subject: [Pce] Where the Controlled ID info shuold be carried/encoded?

Hi Guys,

Thank you so much for your helpful review and comments of our draft draft-ietf-pce-controlled-id-space.
In the WG adoption, I can summarize our discussion into the below bullets, hope they are correct,

  1.  The draft is useful, and the mechanism defined in the draft is needed, we should work on it. (Thanks!)
  2.  We need to discuss the where the info should be carried in the PCEP. Open Object seems not so good ☹
  3.  TLV encoding should be updated to be more generic or let's avoid the generic description and define specific sub-TLVs as needed.

I see the reasons why we decided to carry the info in PCEP Open Object, because it is a device-wide configuration info, which should not be modified in the running state. We may face a lot of trouble of removing some IDs and then modify the range in a running network. However, we may also need to handle the negotiation between PCC and PCE?  Therefore, I am also concerning about this.

I like to hear your voice on this, which object/msg is appropriate to carry the info? I am open with other options.

Possible options could be

l  Open message

l  Use PCEP-LS encoding and make this a node attribute

l  New type of notification

l  New message/object

Once we get the conclusion of this, we can go to the bullet 3, which is much easier that bullet 2. IMHO, I will prefer to define sub-TLVs one by one, this can decouple the relations between IDs, though we may need to delete the 'generic' words.

Thoughts?
Cheng