Re: [spring] SID Related Algorithm in draft-peng-idr-segment-routing-te-policy-attr

[Ketan Talaulikar <[e-mail]>]

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 <[e-mail]> wrote:

> Hi Ketan,
> Thanks for your further comments and explanation. Please see inline YAO>.
>
> Regards,
> Yao
>
> ------------------原始邮件------------------
> 发件人：KetanTalaulikar
> 抄送人：SPRING WG;[e-mail];
> 日 期 ：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 <[e-mail]> 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
>