[Idr] Re: Metadata draft

[Linda Dunbar <[e-mail]>]

Gyan,

Thanks for the comments. See my reply inserted below:

Linda

From: Gyan Mishra <[e-mail]>
Sent: Saturday, July 6, 2024 9:45 AM
To: Linda Dunbar <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: Metadata draft

Hi Linda

Agreed there is a tradeoff between static and dynamic metrics and having a balance between optimizing app flow and stability which is important as we discussed and your update I believe resolves the issue.

I agree with the solution to have a minimal interval for metric changes is a good solution.

Some feedback on wording.

RSVP TE auto bandwidth is widely implemented by vendors and used by SPs worldwide and AFAIK since auto bandwidth feature is for PCALC path and reserve messages stateful control plane in bringing up the tunnel based on available bandwidth along a path it is not stable and not subject to instability. RSVP TE metric for ospf RFC 7471 and Isis RFC 8570 is the real time dynamic metric you are talking about which AFAIK the vendor implementation uses PCE to. distribute the metric for RSVP TE and with SR this is integrated into SR PM performance measurement for SR Policy latency metric and SR Algo using BGP-LS to collect the link data distributed by the PCE. The implementation is widely used in operator deployments and is stable as well.

I am trying to think of a good use case where you have dynamic real time metrics injected into the routing protocol and we have instabilities today.  Here are a few ideas that are similar to issue described in issue 15 and can be used as example in place of RSVP auto bandwidth and also be used as part of the solution to mitigate and circumvent the instability problem.

So you could use BFD as an example where BFD timers are tuned very low which could exacerbate link flapping and route instability which can be circumvented with BFD dampening or strict BFD. Also in cases where dirty fiber links continually flapping causing route churn and instability can be circumvented with BGP route dampening.  Some vendors have L3 event or route dampening, carrier delay, debounce timeout which is IGP related  interface dampening which helps IGP instability issues nor BGP so I would call it out as BGP route dampening.

I have a comment on this sentence below which seems confusing:

Particularly, in the context of routes used for BGP nexthop resolution (e.g., labeled unicast), frequent changes in these metrics can lead to significant churn not only for the prefixes carrying the data but also for dependent routes.

My thoughts are the prefixes carrying the new path attribute metric would be in the VPN RIB BGP overlay routes  and even for global table BGP customer routes scenarios are in BGP overlay which recurses to IGP BGP next hop which could be BGP LU or IGP LDP labeled prefixes next hops of egress PE.  So the new path attribute routes would never be underlay routes which it seems you are alluding to.

[Linda] Site Physical Availability Index Metadata can be sent out by egress router which can impact all the routes attached to the egress router.


Kind Regards




[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347



On Fri, Jul 5, 2024 at 7:15 PM Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:
Do you think the following wording can close the Github Issue 15 (https://github.com/ietf-wg-idr/draft-ietf-idr-5g-edge-service-metadata-14/issues/15 )?

Route Churn Considerations
While the mechanism detailed in this document aims to provide dynamic metrics like Capacity Availability Index, Site Delay Prediction Index, Service Delay Prediction Index, and Raw Measurement to optimize path selection, it is essential to consider the broader implications of metric-induced churn. Particularly, in the context of routes used for BGP nexthop resolution (e.g., labeled unicast), frequent changes in these metrics can lead to significant churn not only for the prefixes carrying the data but also for dependent routes.
This behavior is analogous to the impacts observed with RSVP auto-bandwidth, which can introduce considerable instability within a network. Such route churn can propagate through the network, causing a cascade of updates and potential route flaps, thereby affecting overall network stability and performance.
To mitigate these effects, network operators should carefully manage the advertisement intervals of these dynamic metrics, ensuring they are set to avoid unnecessary churn. The default minimum interval for metrics change advertisement, set at 30 seconds, is designed to balance responsiveness with stability. However, in scenarios with higher sensitivity to route stability, operators may consider increasing this interval further to reduce the frequency of updates.
Furthermore, operators should implement robust route damping and filtering policies to control the propagation of changes and minimize the impact on dependent routes. By acknowledging and planning for these broader impacts, the mechanism can be deployed more effectively, ensuring optimal performance without compromising network stability.


Linda

From: Linda Dunbar
Sent: Friday, July 5, 2024 3:37 PM
To: Gyan Mishra <[e-mail]<mailto:[e-mail]>>
Subject: RE: Metadata draft

Gyan,

Do you think if it is a good idea to add the following extra statement to Section 7?

While the Minimum Interval for Metrics Change Advertisement is configurable, operators should be aware that frequent updates to the metrics carried in the Metadata Path Attribute can lead to route instability and churn. This is particularly important when the routes carrying this attribute are used for BGP next-hop resolution, as changes in the metrics could trigger updates in dependent routes. The potential for churn in these metrics is similar to the effects seen with features like RSVP auto-bandwidth, which are known to have negative impacts on network stability. Operators should carefully consider the trade-offs between the benefits of dynamic metric updates and the potential for increased churn when configuring the Minimum Interval for Metrics Change Advertisement.

I am trying to close all the open Issues in the Github.

Thanks, Linda

From: Linda Dunbar
Sent: Friday, July 5, 2024 3:07 PM
To: Gyan Mishra <[e-mail]<mailto:[e-mail]>>
Subject: RE: Metadata draft

Gyan,


  *   Do you think Section 7 (Minimum Interval for Metrics Change Advertisement) is good enough to address the “Sticky service” concept?
  *   In terms of relating to CATS, we purposely took any correlation with CATS out of the document because we really want to get the Metadata Path Attribute early assignment. When it was linked to CATS several revisions ago, there were comments that CATS is in early stage and haven’t decided to use BGP as its control protocol.
  *   Your suggested wording change makes sense. Can you send an email to IDR mailing list and add one issue in the Github (https://github.com/ietf-wg-idr/draft-ietf-idr-5g-edge-service-metadata-14/issues/15 ) as it is an IDR WG draft.

Thanks, Linda



From: Gyan Mishra <[e-mail]<mailto:[e-mail]>>
Sent: Friday, July 5, 2024 12:56 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Subject: Re: Metadata draft


The sticky concept is a load balancer concept for persistence to the same path is always uses such as a last known good path in case of a flapping  or instability situation.

Since the draft name has 5G  and talks in detail about 5G scenario which is the primary use case in the name it makes one think its only for 5G but its really useful for any server load balancing application.

This paragraph opens it up to any server use case

While the proposed Metadata Path Attribute is particularly beneficial for low latency services, the metadata path attributes can be expanded to propagate information about GPU availability, power, or other resources necessary for compute-intensive services such as AI and machine learning. This flexibility makes it a valuable tool for a wide range of applications beyond just low latency services.¶<https://datatracker.ietf.org/doc/html/draft-ietf-idr-5g-edge-service-metadata-20#section-1-4>
Since 5G is mentioned in the draft name what do you think of this updated verbiage for this paragraph to make it clear that its not just for 5G.  Also wherever mention GPU or CPU by itself  mention CPU/GPU so its encompasses both

While the proposed Metadata Path Attribute is particularly beneficial for 5G low latency services, the metadata path attributes can be expanded to propagate information about CPU/GPU availability, power, or other resources necessary for compute-intensive services such as AI and machine learning as well as any load balanced mission critical application. This flexibility makes it a valuable tool for a wide range of applications beyond just 5G low latency services.¶<https://datatracker.ietf.org/doc/html/draft-ietf-idr-5g-edge-service-metadata-20#section-1-4>

CATs new WG is mentioned in the draft but I wonder maybe a section to talk about the integration and interop with CATs now being developed and maybe even how they are parallel use cases with their similarities  but also different and reasons why this draft stands by itself from CATs.

Thanks

Gyan

On Fri, Jul 5, 2024 at 3:22 PM Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:
Gyan,

What is the “sticky bit service”?
You are absolutely correct that the metadata concept is not limited to 5G. It is applicable to any network that needs to consider both network delay and service delay for optimal path selection. Just in WAN, the network distance delay is much more significant.

Thanks, Linda



From: Gyan Mishra <[e-mail]<mailto:[e-mail]>>
Sent: Friday, July 5, 2024 11:43 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Subject: Metadata draft



Hi Linda

I will plan to do a thorough review of the meta data draft when I get a chance on my todo list.

The latest revision you posted looks good!

I know the metadata concept primarily was for 5G but I think it could apply to any service provider on Prem or off Prem multi cloud or hybrid cloud use case as well.  What do you think?

I wonder if a  sticky bit service would be valuable in case of false positive or negative that is being injected from a server would be a good idea.  Maybe somehow catch a flapping route from a metric change  based on frequency change and shutdown that path or make it sticky to a single known good path so it does not keep changing.

Kind Regards


[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347



--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347