Hi Nat,
Thanks for the review and comments.
In my understanding there are two types of attributes for a candidate path.
The first type is the attributes which are necessary for creating a candidate
path, this includes binding SID, SID list, priority, etc. In BGP, these
attributes are defined as TLVs/sub-TLVs associated with the SR Policy SAFI.
The second type is the attributes which are ancillary and could be associated
with a candidate path, this includes BFD, protection, traffic monitoring, etc.
In BGP, these attributes will not be defined as individual TLVs/sub-TLVs of the
SR Policy SAFI.
The template concept we are introducing here is about the second type of
attributes, as it is possible that these attributes could be the same for
multiple candidate paths, which means the template can be reused. And using one
template ID can refer to a series of attributes. Thus I would say “a template
acts as a collection of customized attributes associated with an SR Policy
candidate path”.
For your first comment about the procedure, since the attributes defined in a
template are not covered in the existing SR Policy attributes, there will be no
overlap or conflict.
As for your second comment, if the template for an SR Policy CP needs to be
updated or removed, the control plane mechanism (e.g. BGP) would be used to
send an update of the CP.
Best regards,
Jie
From: Nat Kao <pyxi...@gmail.com>
Sent: Thursday, September 5, 2024 7:05 PM
To: Dongjie (Jimmy) <jie.d...@huawei.com>
Cc: spring@ietf.org; i...@ietf.org
Subject: Re: [Idr] Solicit feedbacks on introducing template to SR Policy
architecture
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<mailto: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<mailto:i...@ietf.org>
To unsubscribe send an email to idr-le...@ietf.org<mailto:idr-le...@ietf.org>
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
