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

[Ketan Talaulikar <[e-mail]>]

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.


>
> 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
>