Re: [Idr] SID Related Algorithm in draft-peng-idr-segment-routing-te-policy-attr
Ketan Talaulikar <ketant.ietf@gmail.com> Thu, 07 April 2022 16:30 UTC
Return-Path: <ketant.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D693A1750; Thu, 7 Apr 2022 09:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA4qoLq3iyTd; Thu, 7 Apr 2022 09:30:24 -0700 (PDT)
Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7D73A1732; Thu, 7 Apr 2022 09:30:03 -0700 (PDT)
Received: by mail-vk1-xa32.google.com with SMTP id w67so914301vkw.6; Thu, 07 Apr 2022 09:30:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pIDWgrzzpM9nB/ATsvw2Rf9PrGjFgf02iMiZ3hjfA10=; b=pnRlOeEwj/O9Z9OKAaEK0AXvU7RPOeQkSiUZ99KMvTnpDitHUVIh5neTiYn7m/aX6P dKQufHPB2fshS60rBlR8ZiTkBV8TYI8tpRErwsbubYFKOmT6I3wzMKuzOrQJizTOZ4wr vQHoNSoz38O7x81j2RHBUmPEXLKTYvQD6VZk9t1prsjmDNsk8Xt7//zveEz7D65BjkNM /eMScKSO8Y/JWRL14w+1JeyDlh1ktKW2QEAYUORDFZmM8tOrrxUh5ZzfxWY7o5o5OeN5 0CwXHTVsxZVfET7DzYrhEfbiDr9VjuQrJwuknrIfVpbLhjUgGH/NmQEyheHXQqPlx4AV nfVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pIDWgrzzpM9nB/ATsvw2Rf9PrGjFgf02iMiZ3hjfA10=; b=UVDrSbf5RMdLtClfcw8rwpDZNn1Y4iXtE27KczfZfgKbwwg/iwPMaqlZDYBEuT9qf7 ujyWq6L+h02WTJTyPMO6Peki6ro6EuXNBgf4vrCFP0+0PSPg1u7Dq8kvGCJ8FAJuu6BU xueUSEScoEt7Upc8nCG5YLFL/WdK/u4yf0MbgIkaO2dDuJSzzaaeIxjaePTy71Zk5syQ wMw0kC5qC5A/IveOcSEYdNPKmluwRRJOwcP6kx2RXdl8lwx78WrPqfCCb8NSr0+DuZHC ci0zB+v1vUbW/bytzdio0ozUZiOwxzjpigTvU869HIb2JOmWkU0PQ8cfWve1zbEAKlyk KLRA==
X-Gm-Message-State: AOAM530YBqw26RBdfsU3Osgz+nxaXMEHo9ACC3ZIPOrC5CjCwYFZEXwh IK2lX1T1pCctxqFVC2w3d/f7D238Mt9KDWZri9aHj4FP
X-Google-Smtp-Source: ABdhPJzzWZaNS15vC3kfW0zkSgNxFY+y3CL0Y02Sg5DwAzQJUc6w8dvIYnF2bTv6qH9pnOQbqYSxL/nNfZI8QvFO9XA=
X-Received: by 2002:ac5:cfe7:0:b0:344:a419:c76a with SMTP id m39-20020ac5cfe7000000b00344a419c76amr5208630vkf.33.1649349001401; Thu, 07 Apr 2022 09:30:01 -0700 (PDT)
MIME-Version: 1.0
References: <CAH6gdPyxDxq9soDCTvo84kVYwbOmA5w7D57ihuoOL5fmng-bMg@mail.gmail.com> <202204070927047797007@zte.com.cn>
In-Reply-To: <202204070927047797007@zte.com.cn>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Thu, 07 Apr 2022 21:59:50 +0530
Message-ID: <CAH6gdPzzAQY64PXHrrwyfxDg4vCffbydK5a5Oc+8gHPOkp25=g@mail.gmail.com>
To: liu.yao71@zte.com.cn
Cc: SPRING WG <spring@ietf.org>, idr@ietf.org
Content-Type: multipart/alternative; boundary="00000000000056da4e05dc12fda2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/s0UtIvvreuNW1Swi0p_SD94f3Pk>
Subject: Re: [Idr] SID Related Algorithm in draft-peng-idr-segment-routing-te-policy-attr
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2022 16:30:39 -0000
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.yao71@zte.com.cn> wrote: > Hi Ketan, > Thanks for your further comments and explanation. Please see inline YAO>. > > Regards, > Yao > > ------------------原始邮件------------------ > 发件人:KetanTalaulikar > 抄送人:SPRING WG;idr@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.yao71@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 >
- [Idr] SID Related Algorithm in draft-peng-idr-seg… liu.yao71
- Re: [Idr] SID Related Algorithm in draft-peng-idr… Ketan Talaulikar
- Re: [Idr] SID Related Algorithm in draft-peng-idr… liu.yao71
- Re: [Idr] SID Related Algorithm in draft-peng-idr… Ketan Talaulikar