Hi, Acee and Linda:
The mentioned information in this draft are more related to the links that connect the server to the edge router, than to the prefix of the app server. For example, the “Capacity Index”, “Preference Index” are all related to the site, not the prefix. And, for “Load Measurement”, it is not enough to detect only the load to the server, but omits the load status of the link that connected the servers. We should also considering the future possible extension, such as the bandwidth reservation on these links to the App server etc. In conclusion, associate these attributes to the link is more reasonable than to the prefix. Such links are another typical use case of passive/stub link within the network. Best Regards Aijun Wang China Telecom From: [email protected] <[email protected]> On Behalf Of Acee Lindem (acee) Sent: Thursday, November 5, 2020 8:42 AM To: Jeff Tantsura <[email protected]>; Yingzhen Qu <[email protected]>; [email protected]; [email protected]; Linda Dunbar <[email protected]> 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 Exactly. Thanks, Acee From: Jeff Tantsura <[email protected] <mailto:[email protected]> > Date: Wednesday, November 4, 2020 at 6:16 PM To: Acee Lindem <[email protected] <mailto:[email protected]> >, Yingzhen Qu <[email protected] <mailto:[email protected]> >, "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> >, "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> >, Linda Dunbar <[email protected] <mailto:[email protected]> > 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 For OSPFv3 use E-LSAs (RFC8362) Cheers, Jeff On Nov 4, 2020, 2:44 PM -0800, Linda Dunbar <[email protected] <mailto:[email protected]> >, wrote: 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://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ 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) <[email protected] <mailto:[email protected]> > Sent: Tuesday, November 3, 2020 1:38 PM To: Linda Dunbar <[email protected] <mailto:[email protected]> >; Yingzhen Qu <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> 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 < <mailto:[email protected]> [email protected]> Date: Monday, November 2, 2020 at 10:12 PM To: Yingzhen Qu < <mailto:[email protected]> [email protected]>, " <mailto:[email protected]> [email protected]" < <mailto:[email protected]> [email protected]>, " <mailto:[email protected]> [email protected]" < <mailto:[email protected]> [email protected]> Subject: Need 10 minute slot to discuss OSPF extension for 5G Edge Computing (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests Resent-From: < <mailto:[email protected]> [email protected]> Resent-To: Yingzhen Qu < <mailto:[email protected]> [email protected]>, Acee Lindem < <mailto:[email protected]> [email protected]>, Christian Hopps < <mailto:[email protected]> [email protected]> 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%7C83f990f38fe14407efe208d880300245%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637400290992237706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CooHUjUYe%2BePz9rwBZe0orzPqku%2BoSL%2FrMVVa%2Fl2uIc%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 <[email protected] <mailto:[email protected]> > On Behalf Of Yingzhen Qu Sent: Monday, October 19, 2020 3:52 PM To: [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> 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:[email protected]> [email protected] 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 _______________________________________________ Lsr mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
