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. > > 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. Thanks, Ketan > > Any comments and suggestions are welcome. > > Thanks, > Yao >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
