Hi, Jie.
I've read -04 of this draft.
We can further augment it by introducing attributes in the current
candidate paths(CPs). (ex: SID lists, ENLP, ...etc.)
The template acts as a collection of default values of SR policy CPs on the
headend.
If we do so, we can define procedures for the following:
1. How are the values for the same attribute selected from the received
CP or the referring template?
-We can inherit the values from the referring template for the
attributes if there's no definition in the CP.
-For some attributes, a merge might also be an option.
2. How to deal with CPs when we add/modify/remove the referring
template.
Thanks
Nat
On Tue, Sep 3, 2024 at 2:59 PM Dongjie (Jimmy) <jie.dong=
40huawei....@dmarc.ietf.org> wrote:
> Dear all,
>
>
> A few month ago, draft-zhang-idr-sr-policy-template was presented at an
> interim meeting of IDR WG, and on the meeting there was suggestion that the
> architecture part of introducing template to SR Policy needs to be
> discussed in SPRING. Hence we would like to solicit attention and opinions
> from SPRING WG on this topic.
>
> As described in the IDR draft, a template consists of a set of attributes
> and functions which can be associated with an SR Policy and its candidate
> paths. Some examples of the attributes and functions are:
>
> - BFD and its parameters
> - protection
> - in-situ performance measurement
> - traffic statistics
> - etc.
>
> The content of a template can be defined by an operator and then provided
> to both the controller and the network devices via management interfaces. A
> template may be used only on a specific headend node, or it may be used on
> multiple headend nodes in the network.
>
> For the instantiation of an SR Policy, only the template ID needs to be
> carried as one of the attributes of the SR Policy in the control protocols,
> such as BGP and PCEP. Thus the extensions to the control protocols are
> straightforward. Please note for PCEP there is a draft proposing similar
> concept and extensions: draft-alvarez-pce-path-profiles.
>
>
> Any comments and considerations on introducing template to the SR Policy
> architecture would be appreciated.
>
> Best regards,
>
> Jie (on behalf of the coauthors)
> _______________________________________________
> Idr mailing list -- i...@ietf.org
> To unsubscribe send an email to idr-le...@ietf.org
>
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
