Re: [Idr] WG LC on draft-ietf-idr-sr-policy-safi-00 and draft-ietf-idr-bgp-sr-segtypes-ext-02 (2/15/2024 to 2/29/2024)

linchangwang <linchangwang.04414@h3c.com> Sat, 02 March 2024 02:37 UTC

Return-Path: <linchangwang.04414@h3c.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 6B6CCC14F693 for <idr@ietfa.amsl.com>; Fri, 1 Mar 2024 18:37:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 rj98gX_uOG21 for <idr@ietfa.amsl.com>; Fri, 1 Mar 2024 18:36:57 -0800 (PST)
Received: from h3cspam02-ex.h3c.com (smtp.h3c.com [60.191.123.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A045C14F69F for <idr@ietf.org>; Fri, 1 Mar 2024 18:36:54 -0800 (PST)
Received: from mail.maildlp.com ([172.25.15.154]) by h3cspam02-ex.h3c.com with ESMTP id 4222afGQ091610; Sat, 2 Mar 2024 10:36:42 +0800 (GMT-8) (envelope-from linchangwang.04414@h3c.com)
Received: from DAG6EX03-IMDC.srv.huawei-3com.com (unknown [10.62.14.12]) by mail.maildlp.com (Postfix) with ESMTP id E451F2004BA9; Sat, 2 Mar 2024 10:37:52 +0800 (CST)
Received: from DAG6EX01-IMDC.srv.huawei-3com.com (10.62.14.10) by DAG6EX03-IMDC.srv.huawei-3com.com (10.62.14.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.27; Sat, 2 Mar 2024 10:36:40 +0800
Received: from DAG6EX01-IMDC.srv.huawei-3com.com ([fe80::1d4d:847c:a7e3:1f10]) by DAG6EX01-IMDC.srv.huawei-3com.com ([fe80::1d4d:847c:a7e3:1f10%20]) with mapi id 15.02.1258.027; Sat, 2 Mar 2024 10:36:40 +0800
From: linchangwang <linchangwang.04414@h3c.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] WG LC on draft-ietf-idr-sr-policy-safi-00 and draft-ietf-idr-bgp-sr-segtypes-ext-02 (2/15/2024 to 2/29/2024)
Thread-Index: AdpsSmeKxBtKoDvsQv+dD+FYs0L9gw==
Date: Sat, 02 Mar 2024 02:36:40 +0000
Message-ID: <f03bd9e155c64ba6aef3b16f31528e79@h3c.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.76.156]
x-sender-location: DAG2
Content-Type: multipart/alternative; boundary="_000_f03bd9e155c64ba6aef3b16f31528e79h3ccom_"
MIME-Version: 1.0
X-DNSRBL:
X-SPAM-SOURCE-CHECK: pass
X-MAIL: h3cspam02-ex.h3c.com 4222afGQ091610
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/oQ9c6JgpXQg1NSGVC6ujwpCjG2A>
Subject: Re: [Idr] WG LC on draft-ietf-idr-sr-policy-safi-00 and draft-ietf-idr-bgp-sr-segtypes-ext-02 (2/15/2024 to 2/29/2024)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 02 Mar 2024 02:37:01 -0000

Hi Sue,

I fully support the publication of these two drafts.
As a provider of network devices, it is crucial to have the capability to distribute SR policies based on BGP when developing segment routing policy functionalities. As mentioned in Ketan's email, many extended features of SR policies currently depend on these two foundational documents.

Additionally, the Segment Routing Policy Architecture document [RFC9256] has already been published in 2022.
Hence, there is an urgent need for the prompt publication of these two foundational BGP SETE documents.

Thanks,
Changwang

·¢¼þÈË: Idr <idr-bounces@ietf.org> ´ú±í Susan Hares
·¢ËÍʱ¼ä: 2024Äê2ÔÂ16ÈÕ 6:13
ÊÕ¼þÈË: idr@ietf.org
Ö÷Ìâ: [Idr] WG LC on draft-ietf-idr-sr-policy-safi-00 and draft-ietf-idr-bgp-sr-segtypes-ext-02 (2/15/2024 to 2/29/2024)

Greetings IDR:

This begins a 2-week WG LC on the following two drafts created from the text in
draft-ietf-idr-segment-routing-te-policy-18 ¨C that the IDR WG approved for publication:


  *   draft-ietf-idr-sr-policy-safi-00  (proposed standard)

https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-safi/

  *   draft-ietf-idr-bgp-sr-segtypes-ext-02 (experimental)

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-sr-segtypes-ext/

The Authors (per IETF policy) are asked to respond to this message with a
message indicating whether they know of any undisclosed IPR as the documents stand now.
Please note there are 3 IPR declarations on these drafts.

History:
======
After reviewing draft-ietf-idr-segment-routing-te-policy-18, Andrew Alston (IDR RTG AD)
asked that draft-ietf-idr-segment-routing-te-policy be split into two parts because
some segment types (C-L) did not have two implementations.
Therefore, draft-ietf-idr-bgp-srsegtypes-ext-02 contains the text for
Segment types C-L.   This split has been discussed at IETF meetings.

Since Andrew Alston had personally implemented this draft,
he also asked for additional reviews on procedures.

During this review, the procedures regarding the link to RFC9012 were improved.

Issues in call:
============
During the WG should note that the procedures specified in
draft-ietf-idr-sr-policy-safi-00 do the following:


  1.  Only apply to the SR Policy Tunnel (15) + SR Policy SAFI
  2.  Do not require any of the TLVs defined in RFC9012 for other tunnel types
  3.  May ignore TLVs defined in RFC9012 for other tunnel types
  4.  Do not use the validation process in RFC9012, and depend on the SRPM to validate content.
  5.  Makes changes to Color Extended Community [RFC9012] to add to 2-bits [C, O]

To support ¡°color-only¡± (CO)  functions of section 8.8 of [RFC9256]


C0 ¨C type 0 (00) ¨C Specific end-point match (Match endpoint that is BGP NH)
         type 1 (01) - Specific or null end-point match (BGP NH or null (default gw))
         type 2 (10) ¨C Specific, null, or any end-point match (BGP NH, Null, or any endpoint)
         type 3 (11) ¨C Reserved

The SR Policy Tunnel functions in this draft use BGP as a transport mechanism for the
Information contained in the SR Policy.

Please note that these procedures split the context validation away from the
BGP module into the SRPM module.   This split is similar to the BGP-LS split
syntax validation from context validation.

There are multiple implementations of this technology as detailed at:
https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement

The WG members are asked to confirm their agreement to the changes made in this document.

If there are questions, please ask them on this mail thread.  Please note any errors in the call are mine (and not the authors).

Cheerily, Sue

-------------------------------------------------------------------------------------------------------------------------------------
±¾Óʼþ¼°Æ丽¼þº¬ÓÐлªÈý¼¯Íŵı£ÃÜÐÅÏ¢£¬½öÏÞÓÚ·¢Ë͸øÉÏÃæµØÖ·ÖÐÁгö
µÄ¸öÈË»òȺ×é¡£½ûÖ¹ÈκÎÆäËûÈËÒÔÈκÎÐÎʽʹÓ㨰üÀ¨µ«²»ÏÞÓÚÈ«²¿»ò²¿·ÖµØй¶¡¢¸´ÖÆ¡¢
»òÉ¢·¢£©±¾ÓʼþÖеÄÐÅÏ¢¡£Èç¹ûÄú´íÊÕÁ˱¾Óʼþ£¬ÇëÄúÁ¢¼´µç»°»òÓʼþ֪ͨ·¢¼þÈ˲¢É¾³ý±¾
Óʼþ£¡
This e-mail and its attachments contain confidential information from New H3C, which is
intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!