[spring] Re: WG Adoption Call for draft-ali-spring-srv6-policy-sid-list-optimization-01

Gyan Mishra <hayabusagsm@gmail.com> Mon, 03 November 2025 09:49 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: spring@mail2.ietf.org
Delivered-To: spring@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 90F4F81452AD for <spring@mail2.ietf.org>; Mon, 3 Nov 2025 01:49:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buCrKQBAciXk for <spring@mail2.ietf.org>; Mon, 3 Nov 2025 01:49:39 -0800 (PST)
Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 mail2.ietf.org (Postfix) with ESMTPS id CD367814529E for <spring@ietf.org>; Mon, 3 Nov 2025 01:49:39 -0800 (PST)
Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-340299fe579so4352960a91.2 for <spring@ietf.org>; Mon, 03 Nov 2025 01:49:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762163379; x=1762768179; 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=AIpWuxGIBBBRc3RHBW6Y7jHyh41bQq2BX+3xwtbclTk=; b=kp2bARsI0WwsdZx3qg9s3PoohKVR7ngZAqi/1nrwgPqmmGGYxY06RyGOy2adJ7ZpuA H1qGxd8RPJYwwMTLOeWcs4oubt/LUhXB4JgXC42iWy3U9K1H5CpGF7ZhuIXv9HB8DmwD D4zSPxAPH4/x4wHvpB+qzyuRrtBuyfspR88ZUQAJa2MAyFilw6FISogUSQ4GDe7bq7eL GceT2SY3Chkvi1k44uD7pa/ETi8jMnwLsv++HoI/VwUhwGshoFAgPTUa2bm1KfGnV+tQ W5yayMvbFi/9cbzODAZh5aioJBfP2gt2Za0YvX/zQQRmAn9mEjdoKchW9IFWKCbyLofB MfZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762163379; x=1762768179; 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=AIpWuxGIBBBRc3RHBW6Y7jHyh41bQq2BX+3xwtbclTk=; b=G6eZLIMLvKv8cbfYXhG4yVSJfDyLcwDd5DbhVunnP1mnIh3D3yD3vQ5VRw67ule2MU dDYM97Sb2M7EegA9PYGDpc/n8kNsIyaW0cbKHWg6vEtOvx3TWWRChBTIlhVhsiv9qgX+ H0vFpsZpB0fD6ba5WbBdTaMafKZxSyNEFLGs4Phzt89EywxeoGGgBwfA88COfySusEw9 szx8OFr2rT1ckvQK7nXgcDXIq1PyumIkhTKfE3c7tNCjnGZim6nAn7LZop+wSDRJv6yi biGwpYjesmza0LI3d+b2EZaed1lSPERzmLmOo/IO6Uvvy0m1ApP9iPj6bfMhl2rz/R6Z eehg==
X-Forwarded-Encrypted: i=1; AJvYcCWcWO3wiGYwczN4RJoZu9NUwwFNtP6L951I2X2avYU67zdY1IkOeG/oh/BLmyDx81QhHNcMVHU=@ietf.org
X-Gm-Message-State: AOJu0YwY3suRDYqreoy8Fwi0TqN/rnrIyUOGTa89933g8y8R7W02E34M TViNRq0zXkia6IKAMdfqgvmMqDH9PbMlDQMY51FSsb5qmMrD5TB+KIEWhDzrXkXNcv5AU3tMs7q Mip8pxQjtfNYio3cVxfwoLeibQvcq5CU=
X-Gm-Gg: ASbGncsDN4/lWRVj+Qio9ctV8k7rry9AczLIwkMDpyolMBIi8GcumFtSo304KmvG7cF VrQTqLH8Ul4pkEM/Pk+6qyZYBZkCr+g2PPE7VKMVN0wNmJyCuWi+6VVkDmBezDtM6ul4i7DyVd8 asJNQVYIg1holMkD+5d/lzFPwp7Hd/2Wb6a0DCv0AAXhAzGiRzHeSt02AmzVSelzomb3k015PfA EyjTd6cdd17A6nwF3imAGvSgoeG+tGFDNzR9p02h6BeyGExui4gqWsr+mlaA2Z93nCx+WyfbT7H zL4s91Jc9cepaUUaTA==
X-Google-Smtp-Source: AGHT+IEFM0o5E10bRKpdtbk8yk+7PWdcOq+peuYh2/6/Pb5BoP8nbUgHvj2KXHOyR0rmh+nbGtuW8C8o2M3VoHz5hkc=
X-Received: by 2002:a17:90b:2d8e:b0:340:be44:dd11 with SMTP id 98e67ed59e1d1-340be44de44mr8740780a91.27.1762163378633; Mon, 03 Nov 2025 01:49:38 -0800 (PST)
MIME-Version: 1.0
References: <MR1P264MB4354AB9A1BB5AA5549B03D95F0FAA@MR1P264MB4354.FRAP264.PROD.OUTLOOK.COM> <DM6PR11MB4692959C48CFBE4925638036DEFAA@DM6PR11MB4692.namprd11.prod.outlook.com> <CABNhwV089V_Mq9pUv-YA0PrnQD51XzXAkmDgR9LYJiB27bf9wg@mail.gmail.com>
In-Reply-To: <CABNhwV089V_Mq9pUv-YA0PrnQD51XzXAkmDgR9LYJiB27bf9wg@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 03 Nov 2025 04:49:27 -0500
X-Gm-Features: AWmQ_bnRY4K2kP4-oSmWVpCqmC6zc-Xpar7J_Av3smxUffdZShmyZsPo4TM3EN8
Message-ID: <CABNhwV0YB_sXbYjZe_4SQCtpWqtYkX7aNam8F+_-MhrYzPjX+Q@mail.gmail.com>
To: "Zafar Ali (zali)" <zali=40cisco.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003842910642ada22e"
Message-ID-Hash: 2ZOYKWQVRJEX5CKUPVPJYEVFJ46QYQZ3
X-Message-ID-Hash: 2ZOYKWQVRJEX5CKUPVPJYEVFJ46QYQZ3
X-MailFrom: hayabusagsm@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: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, SPRING WG List <spring@ietf.org>, "draft-ali-spring-srv6-policy-sid-list-optimization@ietf.org" <draft-ali-spring-srv6-policy-sid-list-optimization@ietf.org>, "Zafar Ali (zali)" <zali@cisco.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [spring] Re: WG Adoption Call for draft-ali-spring-srv6-policy-sid-list-optimization-01
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/nboRxBgK875RhrOXRq7v88E2TLw>
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>

Dear authors

I read through the draft again and I believe there should be alignment
across all vendors on compression as it pertains to overlay and underlay
merge of SIDs.

Below is an example on cisco platform where overlay and underlay merge is
disabled and the command has been deprecated so that overlay and underlay
is not merged for compression which can lead to other issues.

This is on Cisco XR platform and by default the overlay and underlay are
not merged.

As you can see the service endpoint part of the 2 tuple on SR policy
headend {color,endpoint} in this fast the endpoint uN next Sid CSID is 4
with service Sid for uDT4 or e035.

So now if you merged overly and underlay you would burn to node Sid entries
in the carrier for endpoint node Sid and service Sid.

So in this case the underlay only contains Sid up to the USP node or prior
as last hop and then LPM routes to egress PE endpoint of the Sid list.

There is absolutely no reason to merge overlay and underlay Sids as it
burns up valuable space in the carrier when using CSID compression and this
applies to next Sid without SRH can steer up to a full 6 node Sid hope and
replace Sid can also now steer more hops as well within a single carrier so
both endpoint behaviors can benefit from this draft.

This is a very valuable draft and concept optimization and should be
standardized and I think some of the input I have given here should be
reflected in the draft.

Not standardizing on this concept makes it very painful for operators if
the vendors implement this differently.

next hop fc00:0:1:e010:: via fc00:0:1:e010::/64
SRv6 H.Encaps.Red SID-list {fc00:0:4:e035::}-------------------> overlay
SRv6 H.Insert.Red SID-list {fc00:0:2:e026:6:e020:5:e010}---> underlay

I have tested this disable or overlay and underlay merge on both Nokia and
Juniper in interop between the three vendors and for intra domain and multi
domain with algo 0 and flex algo and the behavior is identical and as I
would like to see it and behaves per this drafts optimization strategy.


Thanks

Gyan

On Wed, Oct 29, 2025 at 10:45 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> I support WG adoption.
>
> I think it’s a valuable optimization for compression efficiency.
>
> Thanks
>
> Gyan
>
> On Wed, Oct 29, 2025 at 10:24 AM Zafar Ali (zali) <zali=
> 40cisco.com@dmarc.ietf.org> wrote:
>
>> Dear chairs and the WG,
>>
>>
>>
>> As an author, I support WG Adoption of this draft. It improves
>> compression efficiency and makes packet processing more efficient for the
>> SR policy endpoint node.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Regards … Zafar
>>
>>
>>
>> *From: *bruno.decraene@orange.com <bruno.decraene@orange.com>
>> *Date: *Wednesday, October 29, 2025 at 9:32 AM
>> *To: *SPRING WG List <spring@ietf.org>
>> *Cc: *draft-ali-spring-srv6-policy-sid-list-optimization@ietf.org <
>> draft-ali-spring-srv6-policy-sid-list-optimization@ietf.org>
>> *Subject: *[spring] WG Adoption Call for
>> draft-ali-spring-srv6-policy-sid-list-optimization-01
>>
>> Dear WG:
>>
>>
>>
>> This message starts a three-week adoption call for
>> draft-ali-spring-srv6-policy-sid-list-optimization, ending on November/19.
>>
>>
>>
>> From the Abstract:
>>
>>
>>
>>    Segment Routing (SR) allows a node to steer a packet flow along any
>>
>>    path.  SR Policy is an ordered list of segments (i.e., instructions)
>>
>>    that represent a source-routed policy.  The packets steered into an
>>
>>    SR Policy carry an ordered list of segments associated with that SR
>>
>>    Policy.  An SR Policy can be instantiated SR-MPLS and SRv6 data
>>
>>    planes.
>>
>>
>>
>>    In some use cases, an SRv6 Policy's SID list ends with the policy
>>
>>    endpoint's node SID, and the traffic steered (over policy) already
>>
>>    ensures that it is taken to the policy endpoint.  In such cases, the
>>
>>    SID list can be optimized by excluding the endpoint Node SID when
>>
>>    installing the policy.  This draft specifies procedures to indicate
>>
>>    whether the endpoint's node SID needs to be included or excluded when
>>
>>    installing the SRv6 Policy.
>>
>>
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-ali-spring-srv6-policy-sid-list-optimization
>>
>>
>>
>>
>>
>>
>>
>> Please review the draft and consider whether you support its adoption by
>>
>> the WG. Please share any thoughts with the list to indicate support or
>>
>> opposition -- this is not a vote.
>>
>>
>>
>> If you are willing to provide a more in-depth review, please state it
>>
>> explicitly to give the chairs an indication of the energy level in the
>>
>> working group willing to work on the document.
>>
>>
>>
>> WG adoption is the start of the process. The fundamental question is
>>
>> whether you agree the proposal is worth the WG's time to work on and
>>
>> whether this draft represents a good starting point. The chairs are
>>
>> particularly interested in hearing the opinions of people who are not
>>
>> authors of the document.
>>
>>
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Bruno (for the Chairs)
>>
>> ____________________________________________________________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>>
>>
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>>
>> they should not be distributed, used or copied without authorisation.
>>
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>>
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>
>> Thank you.
>>
>> _______________________________________________
>> spring mailing list -- spring@ietf.org
>> To unsubscribe send an email to spring-leave@ietf.org
>>
>