Re: [Idr] comments to draft-ietf-idr-5g-edge-service-metadata-16

[Linda Dunbar <[e-mail]>]

Cheng,

With regard to your suggested Utilization, how about adding a subsection below:

4.7.  Service-Oriented Utilization Sub-TLV

  The "Service-Oriented Utilization Sub-TLV" is for distributing a
   metric that measures the real-time utilization of resources allocated
   for processing specific services or applications at an edge site.
   This Sub-TLV complements the "Service-Oriented Capability Sub-TLV"
   described in Section 4.6, which addresses the static resource
   capability of a site for a service.  While the Capability Abstract
   Value provides a baseline understanding of a site's potential to
   handle a service, the Utilization metric offers a dynamic perspective
   by quantifying how much of this capacity is currently being consumed.
   This distinction is crucial for managing resource efficiency and
   responsiveness in network operations, ensuring that capabilities are
   not only available but also optimally used to meet the actual service demands.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ServiceOriented Util Sub-Type |   Length      |P| Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  SO-UtilValue |            Reserved                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 7: Service-Oriented Utilization Sub-TLV

   - ServiceOriented Util Sub-Type:  (Service-Oriented Utilization Sub-
      Type) Sub-type=6 (specified in this document).

   - Flag (P):  A single bit flag =1 to indicate the value is a
      percentage for the Service-Oriented Utilization.

   - SO-UtilValue (when the Flag bit is set to 1):  Service-Oriented
      Utilization Value is a percentage (0-100), with 0 indicating that
      0% of the capability has been consumed and 100 indicating that
      100% has been consumed.  When the value is outside the 0-100
      range, the value carried in this Sub-TLV is ignored.

Linda
From: Linda Dunbar
Sent: Wednesday, April 17, 2024 11:25 AM
To: 'Cheng Li' <[e-mail]>; Dongjie (Jimmy) <[e-mail]>; IDR List <[e-mail]>
Cc: [e-mail]
Subject: RE: comments to draft-ietf-idr-5g-edge-service-metadata-16

Cheng,

Thanks for the feedback. Please see if the resolutions below are acceptable.
p.s. I change the subject line to reflect the discussion content.

Linda

From: Cheng Li <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, April 16, 2024 8:22 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; IDR List <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Reminder: Slides are needed \\RE<file://RE>: IETF 119 final IDR agenda posted

Hi Linda,

Thank you for your work, please see my reply inline.

Thanks,
Cheng


From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, April 16, 2024 1:08 AM
To: Cheng Li <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; IDR List <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: Reminder: Slides are needed \\RE<file://RE>: IETF 119 final IDR agenda posted

Cheng,

Thank you for the comments.

Below are the resolutions to your comments. Please let us know if they are acceptable.

Linda

From: Cheng Li <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, March 20, 2024 2:55 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; IDR List <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: Reminder: Slides are needed \\RE<file://RE>: IETF 119 final IDR agenda posted

<snipped>

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.

[Linda] Good suggestion. How about adding a following sub-section?

4.6.  Service-Oriented Capability Sub-TLV

   The service-oriented capability Sub-TLV is for distributing

   information regarding the capabilities of a DC for a specific

   service(S/ DC for a specific service/ service inside a site).  This information provides ingress routers or controllers

   with knowledge of available resources at each site, enabling them to

   make well-informed decisions for optimal path and site selection.

   Currently, the Sub-TLV only has an abstract value derived from

   various metrics, although the specifics of this derivation are beyond

   the scope of this document.  Importantly, this value is significant

   only when comparing multiple data center sites for the same service;

   it is not interchangeable between different services, meaning the

   capability value relevant to Service A cannot be directly compared

   with that for Service B.  Future enhancements may expand this sub-TLV

   to include raw data that represents direct metrics.  This information

   is important in 5G network environments where efficient resource

   utilization is crucial for enhancing performance and service quality.





    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

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

   | ServiceOriented Cap Sub-Type  |   Length      |A| Reserved    |

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

   |         Service-Oriented Capability Abstract Value            |

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



               Figure 6: Service-Oriented Capability Sub-TLV



   - ServiceOriented Cap:  (Service-Oriented Capability) Sub-type=5

      (specified in this document).



   - Flag (A):  A single bit flag =1 to indicate the value is an

      abstract value for the Service-Oriented Capability.



   - Service-Oriented Capability Abstract Value (when the Flag bit is

   set to 1):  an integer in the range of 0-100, with 0 indicating that

      the site has the relatively lowest capability for the service and

      100 indicating that the site has the highest capability for the

      service compared with all other sites that host the service.  When

      the value is outside the 0-100 range, the value carried in this

      Sub-TLV is ignored.


Thanks.

[Cheng]Please see my suggestion above. Regarding the value, if we plan to use 0-100, why do we need 4 bytes? Is it possible to use only 1 bytes? And reserve 3 bytes for alignment or future usage.

[Linda] How about the following:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ServiceOriented Cap Sub-Type  |   Length      |A| Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SO-CapValue   |            Reserved                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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.

[Linda]  Is the Utilization Sub-TLV per service? Is it one form of value for the Service Oriented Capability?
[Cheng]yes, utilization sub-TLV per service. Might be percentage? 0-100? Or the real-time available value of the capability? The receiver need to calculate the available resource if we use percentage, if we use absolute value, that can avoid the calculation. Both are good to me, a little bit prefer to use the absolute value instead of percentage.

[Linda] both   "Utilization" and  "Capability Abstract Value" are per service. Can we make "Capability Abstract Value" as the site's capability to process the specific service, and the utilization is what has been consumed? In another word, Capability Abstract Value is a static value depending on the resources at the site. The "Utilization" is a run time metric showing what has been consumed?


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?

[Linda] Version -16 has the raw delay value defined as:

  - Service Delay Predication Value (when the Flag bit is set to 0):

      the estimated delay time as defined in RFC5905.

Is it good enough?



[Cheng]Thanks, it looks good to me!


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

Thanks,
Cheng




From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Linda Dunbar
Sent: Wednesday, March 20, 2024 2:40 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; IDR List <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] Reminder: Slides are needed \\RE<file://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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Dongjie (Jimmy)
Sent: Wednesday, March 20, 2024 9:43 AM
To: IDR List <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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=[e-mail]<mailto:jie.dong=[e-mail]>>
Sent: Sunday, March 17, 2024 9:17 AM
To: IDR List <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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=[e-mail]<mailto:jie.dong=[e-mail]>>
Sent: Saturday, March 9, 2024 5:48 PM
To: IDR List <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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