Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

Aijun Wang <wangaijun@tsinghua.org.cn> Mon, 09 November 2020 01:26 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678363A105C; Sun, 8 Nov 2020 17:26:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL9rCuIYru4e; Sun, 8 Nov 2020 17:25:59 -0800 (PST)
Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A483A1059; Sun, 8 Nov 2020 17:25:57 -0800 (PST)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 0358F46ECB; Mon, 9 Nov 2020 09:25:52 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: 'Linda Dunbar' <linda.dunbar@futurewei.com>, "'Acee Lindem (acee)'" <acee@cisco.com>, 'Yingzhen Qu' <yingzhen.ietf@gmail.com>, lsr@ietf.org, lsr-chairs@ietf.org
References: <SN6PR13MB2334FB60B2DEF450A621C01285EF0@SN6PR13MB2334.namprd13.prod.outlook.com> <016301d6b317$b7fd7870$27f86950$@tsinghua.org.cn> <SN6PR13MB2334971229F82505F2A31E0985EE0@SN6PR13MB2334.namprd13.prod.outlook.com> <008001d6b3db$085bc510$19134f30$@tsinghua.org.cn> <SN6PR13MB233429C95B76F9756DF4A10785ED0@SN6PR13MB2334.namprd13.prod.outlook.com>
In-Reply-To: <SN6PR13MB233429C95B76F9756DF4A10785ED0@SN6PR13MB2334.namprd13.prod.outlook.com>
Date: Mon, 09 Nov 2020 09:25:49 +0800
Message-ID: <021a01d6b637$426dffd0$c749ff70$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_021B_01D6B67A.5097CF80"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQD2J7U/Llv21jdkogB4O2EIjUtqHQHqhSVQAm1ltiIBgQu/TAJQ2yzeqz7PnjA=
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZS0lPGRgaHh1LSUtIVkpNS09DQ05KTkhPTUhVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0hPQ1VLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OBA6Ojo4Sj8eERM3CSkSQg0R LT8KFAxVSlVKTUtPQ0NOSk5PS0pJVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUxOS0JINwY+
X-HM-Tid: 0a75aa9c05c39865kuuu0358f46ecb
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/J9ICS4cO-6SCyG4jeHOW0sM7rvo>
Subject: Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2020 01:26:04 -0000

Hi, Linda:

 

If the Load Measurement interval is 3600 seconds, I think it is acceptable. But can such long interval meet the requirement of the edge computing? And if the user specified one very short period, will it influence the performance of SPF calculation on each router?

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: Linda Dunbar [mailto:linda.dunbar@futurewei.com] 
Sent: Friday, November 6, 2020 10:45 PM
To: Aijun Wang <wangaijun@tsinghua.org.cn>; 'Acee Lindem (acee)' <acee@cisco.com>; 'Yingzhen Qu' <yingzhen.ietf@gmail.com>; lsr@ietf.org; lsr-chairs@ietf.org
Subject: RE: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

 

Aijun, 

 

There are three Metrics to be collected for 5G Edge Computing servers, to be carried by the three corresponding  Sub-TLVs proposed by the https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ 

 

-   IP-Layer Metric for App Server Load Measurement:

Two types of Load Measurement Sub-TLVs are specified. One is to carry the aggregated cost Index based on weighted combination of the collected measurements; another one is to carry the raw measurements of packets/bytes to/from the App Server address. The raw measurement is useful when the egress routers cannot be configured with a consistent algorithm to compute the aggregated load index and the raw measurements are needed by a central analytic system.

 

-   Capacity Index

Capacity Index is used to differentiate the running environment of the application server. Some data centers can have hundreds, or thousands, of servers behind an Application Server’s App Layer Load Balancer that is reachable from external world. Other data centers can have very small number of servers for the application server. “Capacity Index”, which is a numeric number, is used to represent the capacity of the application server in a specific location.

 

-   Site preference index: 

[IPv6-StickyService] describes a scenario that some sites are more preferred for handling an application than others for flows from a specific UE. 

 

The Update frequency for the 3 sub-TLVs can be different. The Site Preference Index and the Capacity Index should be in the same frequency as the Extended Prefix TLV because as the Application Server Prefix changes, their corresponding Site Preference and the Capacity Index would change as well.  

The Update frequency for the Load Measurement should be high to reflect the running load of the App servers. Currently, default is 3600 seconds, but can also be a user specified period in seconds. 

 

 

Any other suggestions or comments? 

 

Linda Dunbar

 

From: Aijun Wang <wangaijun@tsinghua.org.cn <mailto:wangaijun@tsinghua.org.cn> > 
Sent: Thursday, November 5, 2020 7:21 PM
To: Linda Dunbar <linda.dunbar@futurewei.com <mailto:linda.dunbar@futurewei.com> >; 'Acee Lindem (acee)' <acee@cisco.com <mailto:acee@cisco.com> >; 'Yingzhen Qu' <yingzhen.ietf@gmail.com <mailto:yingzhen.ietf@gmail.com> >; lsr@ietf.org <mailto:lsr@ietf.org> ; lsr-chairs@ietf.org <mailto:lsr-chairs@ietf.org> 
Subject: RE: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

 

 

Hi, Linda:

 

For example, 

What’s the update frequency of the App server status data?  Will it influence the SPF efficiency on each flooding router etc.?

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: Linda Dunbar [mailto:linda.dunbar@futurewei.com] 
Sent: Friday, November 6, 2020 12:57 AM
To: Aijun Wang <wangaijun@tsinghua.org.cn <mailto:wangaijun@tsinghua.org.cn> >; 'Acee Lindem (acee)' <acee@cisco.com <mailto:acee@cisco.com> >; 'Yingzhen Qu' <yingzhen.ietf@gmail.com <mailto:yingzhen.ietf@gmail.com> >; lsr@ietf.org <mailto:lsr@ietf.org> ; lsr-chairs@ietf.org <mailto:lsr-chairs@ietf.org> 
Subject: RE: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

 

Ai Jun, 

 

Can you elaborate more on your proposed “analysis for the flooding influences”? 

 

Thank you very much. 

 

Linda

 

From: Aijun Wang <wangaijun@tsinghua.org.cn <mailto:wangaijun@tsinghua.org.cn> > 
Sent: Wednesday, November 4, 2020 8:03 PM
To: Linda Dunbar <linda.dunbar@futurewei.com <mailto:linda.dunbar@futurewei.com> >; 'Acee Lindem (acee)' <acee@cisco.com <mailto:acee@cisco.com> >; 'Yingzhen Qu' <yingzhen.ietf@gmail.com <mailto:yingzhen.ietf@gmail.com> >; lsr@ietf.org <mailto:lsr@ietf.org> ; lsr-chairs@ietf.org <mailto:lsr-chairs@ietf.org> 
Subject: RE: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

 

Hi, Linda:

 

Is it better to add some analysis for the flooding influences on the router performance when we add such dynamic information within the IGP protocol?

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>  [mailto:lsr-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, November 5, 2020 6:44 AM
To: Acee Lindem (acee) <acee@cisco.com <mailto:acee@cisco.com> >; Yingzhen Qu <yingzhen.ietf@gmail.com <mailto:yingzhen.ietf@gmail.com> >; lsr@ietf.org <mailto:lsr@ietf.org> ; lsr-chairs@ietf.org <mailto:lsr-chairs@ietf.org> 
Subject: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

 

Acee, 

 

Thank you very much for suggesting using the Prefix TLV for carry the Running Status and environment of 5G Edge Computing servers. 

 

In a nutshell, the https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2f1c51ec07de4cfced5908d881f22dc4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637402224453498580%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=d%2B5SQkJSd40ykZDuqxL0U1RNdKiFiXR%2FPljSgqrE0gw%3D&reserved=0>  proposes the extension to LSA that can carry the three SubTLVs that are used to represent the Running Status and Environment information of the 5G Edge Computing Servers attached to the router:

 

Ø  Load measurement sub-TLV  

Ø  Capacity Index  Sub-TLV                             

Ø  Preference Index  Sub-TLV                                                   

 

Several sections of the draft are devoted to describe what those measurement are and why need them for 5G Edge Computing, which may have made it not so straightforward when reading in a rush. 

 

The Goal of the OSPF extension is to carry those Sub-TLVs in the router’s LSA to be advertised to other routers in the 5G Local Data Network. 

 

If using your suggested RFC7684 OSPFv2 Extended Prefix TLV, the extension does seem easier and cleaner: 

 

We can have: 

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type                          | Length                        |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Route Type    | Prefix Length | AF            | Flags         |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Address Prefix (variable)                                     |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   

| Load Measurement Sub-TLV                                      | 

~                                                               ~ 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   

| capacity Index Sub-TLV                                        | 

~                                                               ~ 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   

| Site Preference Sub-TLV                                       | 

~                                                               ~  

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   

 

 

RFC7684 only has the Extended Prefix TLV for IPv4. If the App Server addresses are in IPv6, should we specify the extension to RFC8362 in the same draft? Or define a new AF type for the same extension to RFC7684? 

 

Your guidance is greatly appreciated. 

 

Thank you very much. 

 

Linda Dunbar

 

 

From: Acee Lindem (acee) <acee@cisco.com <mailto:acee@cisco.com> > 
Sent: Tuesday, November 3, 2020 1:38 PM
To: Linda Dunbar <linda.dunbar@futurewei.com <mailto:linda.dunbar@futurewei.com> >; Yingzhen Qu <yingzhen.ietf@gmail.com <mailto:yingzhen.ietf@gmail.com> >; lsr@ietf.org <mailto:lsr@ietf.org> ; lsr-chairs@ietf.org <mailto:lsr-chairs@ietf.org> 
Subject: Re: Need 10 minute slot to discuss OSPF extension for 5G Edge Computing (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests

 

We have a pretty full schedule and we add you as optional. I took a look at the draft and it is all over the place right now with standardization requested for one solution but 3 separate solutions partially specified. It could benefit from some WG mailing list discussion prior to a 10 minute presentation where we wouldn’t have time to discuss the many issues. 

 

One major issue is that you should be extending RFC 7684 rather than RFC 3630 and it seems you these app-server selection metrics should be associated with a prefix and NOT a stub link (i.e., the application server address).

 

I’ll try to read it in more depth before IETF 109. 

 

Thanks,
Acee

 

From: Linda Dunbar <linda.dunbar@futurewei.com <mailto:linda.dunbar@futurewei.com> >
Date: Monday, November 2, 2020 at 10:12 PM
To: Yingzhen Qu <yingzhen.ietf@gmail.com <mailto:yingzhen.ietf@gmail.com> >, "lsr@ietf.org <mailto:lsr@ietf.org> " <lsr@ietf.org <mailto:lsr@ietf.org> >, "lsr-chairs@ietf.org <mailto:lsr-chairs@ietf.org> " <lsr-chairs@ietf.org <mailto:lsr-chairs@ietf.org> >
Subject: Need 10 minute slot to discuss OSPF extension for 5G Edge Computing (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests
Resent-From: <alias-bounces@ietf.org <mailto:alias-bounces@ietf.org> >
Resent-To: Yingzhen Qu <yingzhen.ietf@gmail.com <mailto:yingzhen.ietf@gmail.com> >, Acee Lindem <acee@cisco.com <mailto:acee@cisco.com> >, Christian Hopps <chopps@chopps.org <mailto:chopps@chopps.org> >
Resent-Date: Monday, November 2, 2020 at 10:12 PM

 

LSR Chairs, YingZhen, 

 

Can you give us 10 minute slot to present this new draft:

https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2f1c51ec07de4cfced5908d881f22dc4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637402224453508393%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MSNE4hXo5LnoLkFH3Y7vTN9Ov5Wcq6LKlz0PrqkmQfA%3D&reserved=0> 

 

This draft describes an OSPF extension that can distribute the 5G Edge Computing App running status and environment, so that other routers in the 5G Local Data Network can make intelligent decision on optimizing forwarding of flows from UEs. The goal is to improve latency and performance for 5G Edge Computing services. 

 

Thank you very much, 

 

Linda Dunbar

 

From: Lsr <lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org> > On Behalf Of Yingzhen Qu
Sent: Monday, October 19, 2020 3:52 PM
To: lsr@ietf.org <mailto:lsr@ietf.org> ; lsr-chairs@ietf.org <mailto:lsr-chairs@ietf.org> 
Subject: [Lsr] IETF 109 LSR Presentation Slot Requests

 

Hi all, 

 

We're now accepting agenda requests for the LSR Working Grouping meeting IETF 109. Please send your requests to  <mailto:lsr-chairs@ietf.org> lsr-chairs@ietf.org indicating draft name, speaker, and desired duration (covering presentation and discussion). 

 

LSR session is scheduled on Monday, Nov 16, 12:00-14:00 ICT.

 

Thanks,

Yingzhen