Hi Yao, Thanks for your response. I don't see the need for the types L and Q. The controller might as well use existing types if it is not sure of the resolution.
Thanks, Ketan On Thu, Apr 7, 2022 at 6:57 AM <liu.ya...@zte.com.cn> wrote: > Hi Ketan, > Thanks for your further comments and explanation. Please see inline YAO>. > > Regards, > Yao > > ------------------原始邮件------------------ > 发件人：KetanTalaulikar > 抄送人：SPRING WG;i...@ietf.org; > 日 期 ：2022年04月05日 00:47 > 主 题 ：Re: SID Related Algorithm in > draft-peng-idr-segment-routing-te-policy-attr > Hi Yao, > Please check inline below. > > On Wed, Mar 30, 2022 at 2:34 PM <liu.ya...@zte.com.cn> wrote: > Hi all, > We presented > https://datatracker.ietf.org/doc/draft-peng-idr-segment-routing-te-policy-attr > on IDR's session last week. > This document defines two kinds of new Segment Sub-TLVs to carry SID > related algorithm when delivering SR Policy via BGP. One is for SR-MPLS > adjacency with algorithm, another kind is defined for carrying the algo > along with the SR-MPLS or SRv6 SID value. > > KT> This work is introducing new Segment Types over what is being > specified in > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22#section-4 > and hence I believe at least a review in SPRING WG would be useful. > YAO> Yes, thanks for the suggestion. > > While we believe that the former kind is necessary, considering > draft-ietf-lsr-algorithm-related-adjacency-sid complements that in > scenarios where multiple algorithm share the same link resource, the > algorithm can be also included as part of an Adj-SID advertisement for > SR-MPLS. > > KT> I agree. That LSR draft is extending the algorithm which was > associated with Prefixes by RFC8402 to now also adjacency SID and would > also benefit from SPRING WG review. I do believe there is a use case for > algorithm-specific adjacency SID. Therefore, I see there is a case for the > introduction of the new Segment Types M, N, O, and P that is being proposed > by you in draft-peng-idr-segment-routing-te-policy-attr. > > > We'd like to request the WG's opinion especially about the delivering > SR-MPLS or SRv6 SID value with optional algorithm. (Thanks for Ketan's > suggestion about this.) > Segment Sub-TLVs carrying SID value with optional algorithm are defined in > this draft because we think it may benefit the scenarios below: > Scenario 1: For verification purposes. The headend can check if the SID > value and the related algorithm received can be found in its SR-DB if > requested to do so. > Scenario 2: The headend may not know about the SID-related algorithm > especially in the inter-domain scenario. Providing the algorithm info > benefits troubleshooting and network management. > > KT> I do not see the point of the Segment Types L and Q that are proposed > in your document. I fail to understand what is meant by validation or > troubleshooting here. I will point to Sec 4 and 5 of > draft-ietf-spring-segment-routing-policy for details on how the segment > types are validated/used. When the SID is specified as a label or SRv6 SID > directly, then the controller has already done its resolution and > identified the SID. I don't see the point in complicating these "simple" > types that are the most widely deployed and used ones. > > YAO> The validation for type L and type Q are mainly used for checking > whether the data/status between the controller and the headend is > consistent, e.g, at first, the controller learnt the information of SID1 > with algo 128 from the data plane, then SID1 is re-allocated for algo 129, > but this info has not been advertised to the control plane due to certain > malfunction. If validation is enabled, this error can be observed. > As for troubleshooting, one potential scenario is the MPLS lspping with > the algorithm as referred in draft-iqbal-spring-mpls-ping-algo. If the SID > related algorithm information along the LSP needs to be verified using the > lspping mechanism, the headend needs to know the algorithm info before > sending the request message. In inter-domain scenario where the headend > can't get the algo of SIDs in other domains through IGP advertisement, > telling the headend this information by the controller is an option. > Above is the consideration for introducing SID value with optional > algorithm, if this is considered not very necessary for now, we can move it > to a separate draft for discussion. > > > Thanks, > Ketan > > > Any comments and suggestions are welcome. > Thanks, > Yao >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
