[spring] Re: [Idr] Solicit feedbacks on introducing template to SR Policy architecture

Nat Kao <pyxislx@gmail.com> Thu, 05 September 2024 11:05 UTC

Return-Path: <pyxislx@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9470AC1519AC; Thu, 5 Sep 2024 04:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW_pUMrtUUXx; Thu, 5 Sep 2024 04:05:29 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17908C15199B; Thu, 5 Sep 2024 04:05:29 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-5356bb5522bso785873e87.1; Thu, 05 Sep 2024 04:05:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725534327; x=1726139127; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NiBEhRf2n0fZ4IpJoJi+VzWI4DhK51nDwDTq5pL+/Ww=; b=ciyCeS3dQv+yStR4CIHnkZn0hbhPJtWjvMATN0jlPO+KAAq/m6fYtfRcmZw/yJtvr3 KxfT/Jmyn0+c752plzdvnqvdbw+jig7lY9GC5BYieP1jNQYcp3GkkyIx2+dc/tIpGZmX PdtES5BUAfB56PTyr5Mfixe2yIFl69cItO5fwK1jFziq5qq+AVzJ2yQi7vHq+obdDBDd 9zDWyekff907J5sNfgvJf+x6wVRAwu37UfOeRwKO9dBxlFoRxVE8cNdRMQbxj88SPW10 6VJjHFzAoaG5+cC7REuNlw9PmcilmOWDQI9VnkWiaq6GDveRmuG4hJ7zLQtg3hDk5LTO A+dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725534327; x=1726139127; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NiBEhRf2n0fZ4IpJoJi+VzWI4DhK51nDwDTq5pL+/Ww=; b=hceeqsGeyhk25PyKQjcJu4ZQRRlRXu7l2ABTxHWrVZ3ch20R1m+/8wJ5efOLBA9FL9 AQ061UPNGtfcNmhGZt8G3a0z3nVDgeNytdpV9kj5GXrO0l3qPJxEy82d9i3ljnz5Sd9w ylMVE5MwfBrK4YHRWR+HoMeOQXSswE0U+q3ecK+A9hevwONU0QNq3Sa2y4Ijkdt/fjE+ d2jDcOsiwGEr33Y6liY14PmFcpKqMo6XOh3TzXio/Dvr/PagAx8y8B5eUICZa5I2m1Qp n3Mrjch5mcuAsYQVW33J31WUm1sRkZf44UUg2cH62JMWxpNEVZDFX4WbMMqMZEucwaS+ Sm1A==
X-Forwarded-Encrypted: i=1; AJvYcCUrtr7edoLz3CuAqUGvC+HRkfWNQ7E4OJiFgOEs5CFRqSRjd3Vfb7OI5PRkRoBOl00SoEE=@ietf.org
X-Gm-Message-State: AOJu0YxqlJPhvcUhwjmfno+mZoNFQa48oy3E7r2+5stSZ14rVnjlQt4u IdrRizHQMrSuhckS8UXFsdbTamdfgbn+rbPsKm0Eb71/HjZ9FiyTnS1Zp2QCYzTLAgt68IWs+sq c8CR1pyrmpUHzb5/oL5YNXXq2YVY=
X-Google-Smtp-Source: AGHT+IEMgyv7y4DIihW0B+2+oqNVXU67mPfFzFfuXCn30qGAclXOdKMZ4oW51uSE1eIm0NIwlF6FDEkXPBE0zbQ/AmE=
X-Received: by 2002:ac2:4e06:0:b0:534:3cdc:dbfe with SMTP id 2adb3069b0e04-53546b2b9f3mr12414909e87.28.1725534326881; Thu, 05 Sep 2024 04:05:26 -0700 (PDT)
MIME-Version: 1.0
References: <ab74ea398fdb4196b92ed97c8e2c912b@huawei.com>
In-Reply-To: <ab74ea398fdb4196b92ed97c8e2c912b@huawei.com>
From: Nat Kao <pyxislx@gmail.com>
Date: Thu, 05 Sep 2024 19:04:50 +0800
Message-ID: <CAKEJeo4dFdnEdoQHHgrPVcw7-69z2V4F3Ap36s6FjiXPowmmWQ@mail.gmail.com>
To: "Dongjie (Jimmy)" <jie.dong=40huawei.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009a0a1f06215d44e8"
Message-ID-Hash: JUFDC34QW5MWLXKALFM4TPSG7JYUUMR5
X-Message-ID-Hash: JUFDC34QW5MWLXKALFM4TPSG7JYUUMR5
X-MailFrom: pyxislx@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spring.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "spring@ietf.org" <spring@ietf.org>, "idr@ietf.org" <idr@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [spring] Re: [Idr] Solicit feedbacks on introducing template to SR Policy architecture
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/V8sGx_ocl15Np-7XFsJugCEMdCU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Owner: <mailto:spring-owner@ietf.org>
List-Post: <mailto:spring@ietf.org>
List-Subscribe: <mailto:spring-join@ietf.org>
List-Unsubscribe: <mailto:spring-leave@ietf.org>

Hi, Jie.

I've read -04 of this draft.
We can further augment it by introducing attributes in the current
candidate paths(CPs). (ex: SID lists, ENLP, ...etc.)
The template acts as a collection of default values of SR policy CPs on the
headend.
If we do so, we can define procedures for the following:
    1. How are the values for the same attribute selected from the received
CP or the referring template?
       -We can inherit the values from the referring template for the
attributes if there's no definition in the CP.
       -For some attributes, a merge might also be an option.
    2. How to deal with CPs when we add/modify/remove the referring
template.

Thanks
Nat

On Tue, Sep 3, 2024 at 2:59 PM Dongjie (Jimmy) <jie.dong=
40huawei.com@dmarc.ietf.org> wrote:

> Dear all,
>
>
> A few month ago, draft-zhang-idr-sr-policy-template was presented at an
> interim meeting of IDR WG, and on the meeting there was suggestion that the
> architecture part of introducing template to SR Policy needs to be
> discussed in SPRING. Hence we would like to solicit attention and opinions
> from SPRING WG on this topic.
>
> As described in the IDR draft, a template consists of a set of attributes
> and functions which can be associated with an SR Policy and its candidate
> paths. Some examples of the attributes and functions are:
>
> - BFD and its parameters
> - protection
> - in-situ performance measurement
> - traffic statistics
> - etc.
>
> The content of a template can be defined by an operator and then provided
> to both the controller and the network devices via management interfaces. A
> template may be used only on a specific headend node, or it may be used on
> multiple headend nodes in the network.
>
> For the instantiation of an SR Policy, only the template ID needs to be
> carried as one of the attributes of the SR Policy in the control protocols,
> such as BGP and PCEP. Thus the extensions to the control protocols are
> straightforward. Please note for PCEP there is a draft proposing similar
> concept and extensions: draft-alvarez-pce-path-profiles.
>
>
> Any comments and considerations on introducing template to the SR Policy
> architecture would be appreciated.
>
> Best regards,
>
> Jie (on behalf of the coauthors)
> _______________________________________________
> Idr mailing list -- idr@ietf.org
> To unsubscribe send an email to idr-leave@ietf.org
>