Re: [Idr] Reminder: Slides are needed \\RE: IETF 119 final IDR agenda posted

Cheng Li <c.l@huawei.com> Wed, 20 March 2024 07:55 UTC

Return-Path: <c.l@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18C4C15107C; Wed, 20 Mar 2024 00:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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, URIBL_BLOCKED=0.001, 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 6YF9rhtgYCL2; Wed, 20 Mar 2024 00:55:41 -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 1EAC3C151093; Wed, 20 Mar 2024 00:55:30 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4V018b0NYyz6K5w8; Wed, 20 Mar 2024 15:54:55 +0800 (CST)
Received: from lhrpeml100004.china.huawei.com (unknown [7.191.162.219]) by mail.maildlp.com (Postfix) with ESMTPS id 53860140B63; Wed, 20 Mar 2024 15:55:26 +0800 (CST)
Received: from dggpemm100005.china.huawei.com (7.185.36.231) by lhrpeml100004.china.huawei.com (7.191.162.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Wed, 20 Mar 2024 07:55:25 +0000
Received: from dggpemm500003.china.huawei.com (7.185.36.56) by dggpemm100005.china.huawei.com (7.185.36.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Wed, 20 Mar 2024 15:55:22 +0800
Received: from dggpemm500003.china.huawei.com ([7.185.36.56]) by dggpemm500003.china.huawei.com ([7.185.36.56]) with mapi id 15.01.2507.035; Wed, 20 Mar 2024 15:55:22 +0800
From: Cheng Li <c.l@huawei.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, IDR List <idr@ietf.org>
CC: "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Thread-Topic: Reminder: Slides are needed \\RE: IETF 119 final IDR agenda posted
Thread-Index: Adp3+AGT573RcboVQw2j1Jn4LrBMHgCXv1hAAApFwyAABeU44A==
Date: Wed, 20 Mar 2024 07:55:22 +0000
Message-ID: <fb40d097a14141a38f8c1c8a107a5019@huawei.com>
References: <dc48cf5acc8b46a5b90c6b8a152bf467@huawei.com> <75dc67e024d34d25bf9bb9350bc5da17@huawei.com> <CO1PR13MB49202BB44BAE90A7A1B7719685332@CO1PR13MB4920.namprd13.prod.outlook.com>
In-Reply-To: <CO1PR13MB49202BB44BAE90A7A1B7719685332@CO1PR13MB4920.namprd13.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.126.201.53]
Content-Type: multipart/alternative; boundary="_000_fb40d097a14141a38f8c1c8a107a5019huaweicom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/MXmA_APTd_44SpXxU8qGVmYdfS0>
Subject: Re: [Idr] Reminder: Slides are needed \\RE: IETF 119 final IDR agenda posted
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2024 07:55:46 -0000

Hi Linda,

Thank you for sharing the slide before the meeting.
Well, I do see my comments (raised before) may not be addressed fully, so I like to share here once again in case that we do not have enough time to discuss it in IDR meeting. In order to not miss the email in IDR email sea again, I also added my comments as issues in the Github repo.


1.     Regarding page 2, I think it is great that we have such a path attribute. Thanks for your work.



2.     make the TLVs more flexible

I see we defined several TLVs in the attribute. However, most of them do not have reserved bits. We may need to avoid this, because we cannot expect that we won't have any extension forever. Therefore, I highly suggest to reserve some bits in TLVs for future extension, like, making the length filed shorter? or make it as a reserved filed if the length is a fixed value. Thanks.

3. adding a Capability sub-TLV for a service

Currently in the draft, a site capability sub-TLV is defined. I think it is good.

However, I will suggest to add a service-oriented or per-service capability sub-TLV to distribute the capability that a service can use in a site. This is vital for an ingress router/controller to know how much resource can be accessed in a site for a service. I highly suggest to added one of it. For the details, we can discuss.

Till now, I will recommend to introduce two ways of carrying capability data of a service in the sub-TLV. Firstly, we should allow the service to announce the raw data, however, I do not suggest to do so, but let's allow this in this draft, and leave the details for future or other drafts. Secondly, we should support to distribute the unified format of the capability. It means in BGP, we only care about the value of the capability, we do not care what's the true meaning of the value means, it is defined by the service itself.
Thanks.

4. add a utilization TLV for the per-service/service-oriented Capability TLV
Only with the service-oriented capability TLV, a service still cannot know how much resource is used, and how much is available now.
So please consider to add a utilization TLV to indicate the percentage of the used resource or remaining resources.
In this way, for a ingress router or a controller, it can know how much resource a site can provide for the service, and it can make the decision based on this info.
Thanks.

5. Allowing to distribute raw delay info?
I see we have defined a TLV to describe the delay prediction. How about let's allow the TLV or add a new TLV to carry the raw delay. Because it many cases, the ingress router/controller need the raw delay data to compute the E2E delay, so that they can choose the service instance/site with lowest delay. I see the F flag is added, is it for this purpose?


Sorry for jumping in since I found my comments may be missed . Hope the comments help.

Thanks,
Cheng




From: Idr <idr-bounces@ietf.org> On Behalf Of Linda Dunbar
Sent: Wednesday, March 20, 2024 2:40 PM
To: Dongjie (Jimmy) <jie.dong@huawei.com>; IDR List <idr@ietf.org>
Cc: idr-chairs@ietf.org
Subject: Re: [Idr] Reminder: Slides are needed \\RE: IETF 119 final IDR agenda posted

Jimmy,

Attached are the slides for draft-ietf-idr-5g-edge-service-metadata-15.
After discussing with Sue and Keyur yesterday, we think we don’t need to present draft-ietf-idr-sdwan-edge-discovery-13.

Linda

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Dongjie (Jimmy)
Sent: Wednesday, March 20, 2024 9:43 AM
To: IDR List <idr@ietf.org<mailto:idr@ietf.org>>
Cc: idr-chairs@ietf.org<mailto:idr-chairs@ietf.org>
Subject: Re: [Idr] Reminder: Slides are needed \\RE<file://RE>: IETF 119 final IDR agenda posted

This is a kind reminder for presenters on our Friday session to send/upload their slides, thanks.

Best regards,
Jie

From: Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org<mailto:jie.dong=40huawei.com@dmarc.ietf.org>>
Sent: Sunday, March 17, 2024 9:17 AM
To: IDR List <idr@ietf.org<mailto:idr@ietf.org>>
Cc: idr-chairs@ietf.org<mailto:idr-chairs@ietf.org>
Subject: Reminder: Slides are needed \\RE<file://RE>: IETF 119 final IDR agenda posted

For presenters on Monday session who have not sent their slide yet, this is a kind reminder.

Best regards,
Jie

From: Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org<mailto:jie.dong=40huawei.com@dmarc.ietf.org>>
Sent: Saturday, March 9, 2024 5:48 PM
To: IDR List <idr@ietf.org<mailto:idr@ietf.org>>
Cc: idr-chairs@ietf.org<mailto:idr-chairs@ietf.org>
Subject: IETF 119 final IDR agenda posted

Hi all,

The updated IDR agenda for IETF 119 can be found at: https://datatracker.ietf.org/doc/agenda-119-idr/01/

Best regards,
Jie

From: Dongjie (Jimmy)
Sent: Wednesday, March 6, 2024 11:15 AM
To: IDR List <idr@ietf.org<mailto:idr@ietf.org>>
Cc: idr-chairs@ietf.org<mailto:idr-chairs@ietf.org>
Subject: IETF 119 draft IDR agenda posted

Dear all,

The draft idr agenda for IETF 119 has been posted at: https://datatracker.ietf.org/doc/agenda-119-idr/

Please let us know if any change is needed.

Currently all presentations are in the Monday session, and the Friday session will be used as overflow session in case some topics require more on-site discussion.

Presenters, please remember to either send me (and CC the chairs) the slides (in PDF format) or upload them by yourself 24 hours before the session you present. Our first session is on Monday afternoon, which means we need the slides for the first session ready by Sunday afternoon (local time), thanks.

Best regards,
Jie