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
