[Idr] Re: Request for comments on draft-li-idr-sr-policy-metric

["[e-mail]" <[e-mail]>]

Hello Yao,

Thank you for your question and comment. Please see my reply inline beginning with ZQL.

Regards,
Zhenqiang Li
China Mobile


[e-mail]
 
From: [e-mail]
Date: 2025-06-06 15:34
To: [e-mail]; [e-mail]
CC: idr; draft-li-idr-sr-policy-metric
Subject: [Idr] Re: Request for comments on draft-li-idr-sr-policy-metric
Hi Authors,

Thanks for the reply.
About comment a), considering that the metrics are used to select an SR policy of the best quality  among multiple SR Policies but the metric sub-TLV are delivered at the SR policy candidate path level, if the BGP update messages for CP1 and CP2 of the same SR Policy both carry the metric sub-TLV, my understanding is that the metric of the CP with the highest preference would be seen as the metric of this SR policy, is it right ?
ZQL:No. The rules for best CP selection are not chanaged. So the CP with higher preference will be the active CP and its metric carried in metric sub TLV will be the the metric of this SRv6 Policy. Please note preference is one attibute of CP.

As for comment c), my point is that, would other granularities for reliability be considered, or only use failures per month to represent the reliability metric.
ZQL: Any specific suggestion? I think it is ok for the possible application in the field network. We can refine it if needed.

Yao



Original
From: 宋力焱 <[e-mail]>
To: 刘尧00165286;lizhenqiang <[e-mail]>;
Cc: idr <[e-mail]>;draft-li-idr-sr-policy-metric <[e-mail]>;
Date: 2025年06月06日 10:57
Subject: Re: Re: Re: [Idr] Request for comments on draft-li-idr-sr-policy-metric
Hi Yao，
    Thank you for your good catch.
    d)Currently, BGP SR Policy does not support an acknowledgment mechanism to confirm successful receipt and processing at the headend. However, SR Policy state can be obtained via BGP-LS.We believe it would be more efficient to support direct state reporting within the BGP SR Policy framework. We will describe this mechanism in a separate document and also include a note in next version of this draft.
Sincerely, 
Liyan Song
China Mobile
[e-mail]   
 
发件人: lizhenqiang
时间: 2025/06/05(星期四)16:30
收件人: liu.yao71;
抄送人: idr;draft-li-idr-sr-policy-metric;
主题: Re: Re: [Idr] Request for comments on draft-li-idr-sr-policy-metric
Hello Yao,

Thank you very much for your review and comments.

a)draft-liu-spring-sr-policy-flexible-path-selection is mainly about candidate path selection and switch within one SR Policy. My doc, draft-li-idr-sr-policy-metric, is about the selection among multiple SR Policies that can be used to steer the same traffic and satisfy the SLA requirements. After SR policy selection using the method introduced in draft-li-idr-sr-policy-metric, candidate path selection and switch within the selected SR policy can use the method proposed in draft-liu-spring-sr-policy-flexible-path-selection.


b)draft-li-idr-sr-policy-metric is mainly about SR Policy selection at the headend when it has multiple SR Policies that can be used to steer the same traffic and satisfy the SLA requirements. The controller can reoptimize the paths of the SR Policies based on the performance metrics it collects. After SR Policy reoptimization, the controller updates the path performance to the headend, which may trigger the SR Policy selection logic at the hendend.

For your question in b.2), as I stated in a), the method introduced in draft-liu-spring-sr-policy-flexible-path-selection can still be used to select and switch CPs in a SR Policy. 


c)In practice, the number of path failure in one day is usually zero. So we suggest to use the number in a month in current version.



[e-mail]
 
From: [e-mail]
Date: 2025-06-05 10:47
To: [e-mail]
CC: [e-mail]; [e-mail]
Subject: Re: [Idr] Request for comments on draft-li-idr-sr-policy-metric
Hi Zhenqiang,

A few comments/questions after reading the draft.
a) From my reading, this draft is about the flexible SR path(candidate path) selection, is it related with  draft-liu-spring-sr-policy-flexible-path-selection ?
b) In this draft, the metric is collected/computed by the controller and sent to the headend, and then the headend makes candidate path selection based on its local policy. Other methods about SR path selection based on certain criterias I've seen include: 
1)  The controller keeps monitoring the metric of the SR path, once the metric no longer satisfies the original requirements, the controller can tear down the active candidate path and make the headend to switch to another CP.
2)  The headend monitors the metric itself, and the headend made candidate path selection based on its local policy or based on the policy set by the controller.
What are the differences and advantages between your draft and other methods?
c) About the reliability metric, what if one wants to carry the number of failures per day instead of per month?
d) In section 4, "Process BGP Acknowledgments: Await acknowledgments from headend nodes to ensure successful reception and processing of the SR policies". What type of BGP Acknowledgment message can indicate that the headend has processed the SR policy successfully? 

Regards,
Yao



From: [e-mail] <[e-mail]>
To: [e-mail] <[e-mail]>;
Cc: draft-li-idr-sr-policy-metric <[e-mail]>;
Date: 2025年06月03日 12:17
Subject: [Idr] Request for comments on draft-li-idr-sr-policy-metric
_______________________________________________
Idr mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
Hello all,

A new draft, https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-metric/, was submitted in March, which proposes an extension to the BGP SR Policy protocol by defining a new optional Metric Sub-TLV within the BGP Tunnel Encapsulation Attribute to enable the headend node to do performance-aware path selection. This draft also updates the BGP route selection procedures in RFC4271, modifying the Breaking Ties (Phase 2) logic to prioritize the metrics for SR Policy paths.

Comments are appreciated!

Thanks and Regards,
Zhenqiang Li
China Mobile


[e-mail]