[Idr] Re: I-D Action: draft-ietf-idr-5g-edge-service-metadata-19.txt

[Linda Dunbar <[e-mail]>]

Chang Wang,

Thank you for the comments. Please see the detailed response below.

Linda

-----Original Message-----
From: linchangwang <[e-mail]>
Sent: Wednesday, July 3, 2024 6:44 AM
To: [e-mail]; [e-mail]
Subject: [Idr] Re: I-D Action: draft-ietf-idr-5g-edge-service-metadata-19.txt

Hi, Linda

Here are the comments :

1. For Section 4.4, "Site Physical Availability Index Metadata," the metadata is viewed as a routing attribute.
 In the Site Physical Availability Index, a site index is defined, and routes are associated with this site index, with the 'I' flag indicating whether it is an association or a notification of changes in site availability.
 In practice, routes associated with the same site need to be linked, and one route must be selected to carry the site's availability status.
 This implicitly advertises the availability changes of site routes within the attribute.
 This implementation necessitates significant modifications to how current BGP attributes are handled.

  It is recommended that site availability be advertised as a regular TLV, similar to other metrics, without associating routes.

[Linda] The Site Physical Availability Index Metadata is associated with the Edge router’s Loopback address; therefore, it has the associating route.  When the Site Physical Availability Index Metadata is propagated by routes attached to the Edge Router (i.e., The Route-Flag I =1), the Site Availability Index is for BGP speakers (receivers) to associate the routes with the Site-ID. It has the associating routes as well.

 2. For the Service Delay Prediction Index Sub-TLV, should the definitions of delay align with IGP, including values such as minimum delay and jitter?

[Linda] What does it mean by “Jitter” for a service hosted in an Edge DC? “Jitter” usually refers to the variation in the time between packets arriving, caused by network congestion, timing drift, or route changes.  IGP has Jitter to reflect the network path jitter. How would you define the “jitter” within a DC?


 3. The current metric definitions are numerous and complex.
  Can we introduce a generalized metric, similar to the definitions from draft-ssangli-idr-bgp-generic-metric-aigp-08 and draft-ietf-lsr-flex-algo-bw-con-12?
  This could be done using a unified abstract form like the following to standardize service metrics:

0                 1                   2                   3
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type     |       Length   |  metric-type  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric-flags| metric-value                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
​
[Linda] do you mean have a new Type? Or replace all the metrics proposed in the document?


 4. Since the metadata is defined as non-transitive, it is incompatible with current deployments, and Route Reflectors (RR) will require upgrades.
[Linda] Indeed, that is the main purpose of setting it as “Non transitive”, to prevent accidental leaking the meta data out of domain. It is requested by IDR chairs, an important security measure.

 5. As the NLRI advertises anycast addresses, when there is an RR deployment, BGP must use the multi-path functionality as specified in RFC 7911. It is recommended to address this in the document.
[Linda] not necessary. The existing BGP can allow ingress node to choose one optimal edge (NextHop) based on the metrics received.

Linda

Thanks,
Changwang

-----邮件原件-----
发件人: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
发送时间: 2024年6月25日 4:19
收件人: [e-mail]<mailto:[e-mail]>
抄送: [e-mail]<mailto:[e-mail]>
主题: [Idr] I-D Action: draft-ietf-idr-5g-edge-service-metadata-19.txt

Internet-Draft draft-ietf-idr-5g-edge-service-metadata-19.txt is now available. It is a work item of the Inter-Domain Routing (IDR) WG of the IETF.

   Title:   BGP Extension for 5G Edge Service Metadata
   Authors: Linda Dunbar
            Kausik Majumdar
            Cheng Li
            Gyan Mishra
            Zongpeng Du
   Name:    draft-ietf-idr-5g-edge-service-metadata-19.txt
   Pages:   28
   Dates:   2024-06-24

Abstract:

   This draft describes a new Metadata Path Attribute and some Sub-TLVs
   for egress routers to advertise the Metadata about the attached edge
   services (ES).  The edge service Metadata can be used by the ingress
   routers in the 5G Local Data Network to make path selections not only
   based on the routing cost but also the running environment of the
   edge services.  The goal is to improve latency and performance for 5G
   edge services.

   The extension enables an edge service at one specific location to be
   more preferred than the others with the same IP address (ANYCAST) to
   receive data flow from a specific source, like a specific User
   Equipment (UE).

The IETF datatracker status page for this Internet-Draft is:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-5g-edge-service-metadata%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C32b99ba531cd485e276008dc9b663ebb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638556110655370598%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=igvqxF%2FwP3r1a6VhERt8BwIFYU%2B5PEifEsmDG5il%2FnQ%3D&reserved=0

There is also an HTMLized version available at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-5g-edge-service-metadata-19&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C32b99ba531cd485e276008dc9b663ebb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638556110655382934%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=LwUaODyMtJVx%2B071gQje5L8NStHAxDZXveAj3pdwApw%3D&reserved=0

A diff from the previous version is available at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-idr-5g-edge-service-metadata-19&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C32b99ba531cd485e276008dc9b663ebb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638556110655390736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jvPuED7WvocXaz5KVDBiRFu%2F87c5%2FY3rwidx5l7YBWU%3D&reserved=0

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


_______________________________________________
Idr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
_______________________________________________
Idr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>