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

[Linda Dunbar <[e-mail]>]

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]>
Sent: Wednesday, March 20, 2024 2:55 AM
To: Linda Dunbar <[e-mail]>; Dongjie (Jimmy) <[e-mail]>; IDR List <[e-mail]>
Cc: [e-mail]
Subject: RE: Reminder: Slides are needed \\RE: IETF 119 final IDR agenda posted

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.

[Linda]  The version -16 (uploaded during IETF119)  has reserved field for all the sub-TLVs. We can make the Path Attribute Length to be 1 octet and have a reserved field, as below:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |AttFlag|Reserve|MetaDataPathAtt|Length(1 Octet)| Reserved      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |         Value (multiple Metadata Sub-TLVs)                    |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.  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.

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?

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?
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