Re: [spring] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04#page-24

Rajesh M <mrajesh@juniper.net> Sat, 19 October 2019 02:28 UTC

Return-Path: <mrajesh@juniper.net>
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 6285512080C for <spring@ietfa.amsl.com>; Fri, 18 Oct 2019 19:28:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 gsr7ZdA6JnKR for <spring@ietfa.amsl.com>; Fri, 18 Oct 2019 19:28:52 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 49571120800 for <spring@ietf.org>; Fri, 18 Oct 2019 19:28:52 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9J2SmIK019805; Fri, 18 Oct 2019 19:28:48 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=YEeFTOsCezsxsAPzvPXyzHXg4mOPqeUzYIkeyaD0Sb4=; b=1FuFI3sSpM2IhMV10FqbjfjlZxe2SkUEUY48k2GmZRt+PKTwEPdeChz2u23S9UA4XJJk 3KnU7mmdM+pSyhpWwhRtSt0WorXNlK+8/Ob8yt/Yf0lvy+qcp0Wx3S2+N++q87qcj2/N om308incVRswivFCOIvHAGM8rXzByeUBB0Om+AqU/sRMOjToHgMZ2W2Mqo6Eq9wx7OpW VpjAAe/uSpwfVFLZ63q0Icbosh6zMTLxKcTiFaiPqtvcUWF4qohSD1lH8jk9fNgeDG6c Lx1IKWfrGntwKETHa9SHUaf87q4WqzKUNRSclX5G5Xy9RSHOnMT9QnWJYbJhxA6GrT7l 5Q==
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2051.outbound.protection.outlook.com [104.47.38.51]) by mx0b-00273201.pphosted.com with ESMTP id 2vqfv7rt97-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Oct 2019 19:28:47 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XXEuzaM9FhXW6jFFJDX6j3b+vM56/4gVi5vYyo/pB7VwVwSEbHYkBdZpbeykiTyh1pUG7ATvwQlmUZjWXTNwGFWvBfyImqnhwjCvCY02LYCeYzM0KzqKiPbpcQN65qxV9uVMYXkM7oEPAY6pE8REJYwcvp/7sBLJ4gSmV20TRrqQKD9sM6cGz/Dr15SKqjoJW2+NuLfE6C/DzG2u+9kiIcRNkYbDlFg2RpTnAob+GwabHKOe6fGsMXhpZn5xVPIvvu4cBsx53RjMLNVK/2neTd0QsC99Bdl4+GS8fzHxxL6+q6wPalBZKsdVDTdCcPfPicVwuEL9a9VuqlwEsbWpSA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YEeFTOsCezsxsAPzvPXyzHXg4mOPqeUzYIkeyaD0Sb4=; b=IO3Zu/ry/fIw5PsL9WtyjRnnMDSs9kQyG4dcWQVKjZF/l5f2YBWFGv96mMtaUx7dFqJpJPe6dq2gioQhzuTOWV0pQ96F0iuCtbQ30nldMkZFSSVfc5cnuXnsFtXn0uXRuTN5WnhOoFzRwH7bSEuBTzro9KYa0pz8pB/bLzPqgF1lqcv9Av//p7uvbeuppZkM4YHFECFST4itYgHGMay67narXrkzk88Xia66rrzXb+MFdL+4pWCH3PXl+smyPZVBTF4CBcbkEEVt4Ww0YKZbdK44Max3cZ0O6g9wX6wZpvKzQ02v+vaL11WTIUTQPPGsSbgGUaCQunnf0pp6KI6UMw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
Received: from MN2PR05MB6080.namprd05.prod.outlook.com (20.178.241.21) by MN2PR05MB7071.namprd05.prod.outlook.com (52.135.39.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.14; Sat, 19 Oct 2019 02:28:45 +0000
Received: from MN2PR05MB6080.namprd05.prod.outlook.com ([fe80::75f9:ea2d:bb47:8292]) by MN2PR05MB6080.namprd05.prod.outlook.com ([fe80::75f9:ea2d:bb47:8292%4]) with mapi id 15.20.2367.019; Sat, 19 Oct 2019 02:28:45 +0000
From: Rajesh M <mrajesh@juniper.net>
To: "Wang, Weibin (NSB - CN/Shanghai)" <weibin.wang@nokia-sbell.com>, Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org>, "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>, SPRING WG List <spring@ietf.org>
CC: Srihari Sangli <ssangli@juniper.net>, Shraddha Hegde <shraddha@juniper.net>, Ron Bonica <rbonica@juniper.net>
Thread-Topic: [spring] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04#page-24
Thread-Index: AQHVg3el/QTSxmKUH02g4wcuLniNTadfbEpggABcrACAAIiUIIAA11oAgAAZXRA=
Date: Sat, 19 Oct 2019 02:28:44 +0000
Message-ID: <MN2PR05MB6080204CE8F16BE1FC68E713BE6F0@MN2PR05MB6080.namprd05.prod.outlook.com>
References: <19C3F806-B455-4D0A-A56B-9BF5C6A36DE8@cisco.com> <MN2PR05MB6080AF7CB8230A9F403F7C89BE6D0@MN2PR05MB6080.namprd05.prod.outlook.com> <02b54f9299ce4820b83e9344e8a5f049@nokia-sbell.com> <MN2PR05MB60806B43DBD4D38910CBB1E3BE6C0@MN2PR05MB6080.namprd05.prod.outlook.com> <b78d1ef5e02d4c22b2b266fb1338e3f7@nokia-sbell.com>
In-Reply-To: <b78d1ef5e02d4c22b2b266fb1338e3f7@nokia-sbell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=mrajesh@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-10-11T01:46:23.5028871Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=da749b5a-3079-47d3-b15d-13c6e8f83efc; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic
dlp-product: dlpe-windows
dlp-version: 11.2.0.14
dlp-reaction: no-action
x-originating-ip: [116.197.184.16]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 155aeb7e-cec5-4f23-0dba-08d7543c10b0
x-ms-office365-filtering-ht: Tenant
x-ms-traffictypediagnostic: MN2PR05MB7071:
x-ms-exchange-purlcount: 7
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR05MB707145D238645313BF18CF63BE6F0@MN2PR05MB7071.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01952C6E96
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(136003)(366004)(396003)(376002)(189003)(199004)(4326008)(8936002)(99286004)(71190400001)(229853002)(71200400001)(606006)(55016002)(66066001)(7696005)(3846002)(6116002)(790700001)(66574012)(64756008)(66556008)(86362001)(6246003)(14454004)(76176011)(107886003)(2906002)(66446008)(446003)(33656002)(54906003)(110136005)(6436002)(316002)(5660300002)(966005)(186003)(486006)(102836004)(66476007)(478600001)(236005)(476003)(76116006)(9686003)(74316002)(81166006)(6506007)(53546011)(25786009)(81156014)(256004)(8676002)(14444005)(7736002)(54896002)(6306002)(11346002)(66946007)(52536014)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR05MB7071; H:MN2PR05MB6080.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: c04qXa5/R9GTpnXrsC6Rpz1mNyjVaqPqENv/bm1fy7bGOKieicI4IfW6k5zFVq3JlnWOoWsKyYA2bSKcp5pxS85M2+wM1GLR7IStOf74txHisT7DytOnl2c6xjHiXD6CJprXOxAt2PxWcmtGQtJm9HvSAFbaDADiMk4hOa7VJrNz/JkMm8CYN0tLG1NpGw7uHJ97MxmWzHGcgzJAnZ0RpCLkn9QcLxrQLbl4BYfv/Log4X/AEyhH0+E/n0YhRu7vuf/KWihSDJkk51lqwrzeKAOvhWClWREcuKPhyEaxXaR2PTsXsPwmEY8dUlpuoit9LKCsRkRHwpB6q9AYK28eihBAYpcScz7kPp0hcdxmcSybxcHpta4Dno3Y8k0ETzrxZL5CnUgyM7k3HMR2+7fo4Y1wXVAZOrzpQFoRiE7rM/ykoBzICxybFtKDn6gpv15onq0cmhcBL8q3hOqXpM3qQD4peIyn+pFm5Ih6dR2aeqc=
Content-Type: multipart/alternative; boundary="_000_MN2PR05MB6080204CE8F16BE1FC68E713BE6F0MN2PR05MB6080namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 155aeb7e-cec5-4f23-0dba-08d7543c10b0
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2019 02:28:44.9429 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0nwvzY4Hl7B+KPIYuaBwAPBptk9IliXYkdOHE72JEUnGYY2IsrmqKeVJ04LABkm4NfA6KBSwDc/HY8Yg8cAcyA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB7071
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-19_01:2019-10-18,2019-10-19 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxlogscore=999 malwarescore=0 spamscore=0 priorityscore=1501 impostorscore=0 phishscore=0 lowpriorityscore=0 clxscore=1015 bulkscore=0 suspectscore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910190021
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/jL8WcB6XaJUEetJXDfGqyFLg19Q>
Subject: Re: [spring] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04#page-24
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Oct 2019 02:28:56 -0000

MPLS world PSP will help in avoiding one more lookup at egress for VPN cases.

I feel both PSP and USP are not useful in case of SRV6.



Juniper Business Use Only
From: Wang, Weibin (NSB - CN/Shanghai) <weibin.wang@nokia-sbell.com>
Sent: Saturday, October 19, 2019 6:26 AM
To: Rajesh M <mrajesh@juniper.net>; Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org>; Pablo Camarillo (pcamaril) <pcamaril@cisco.com>; SPRING WG List <spring@ietf.org>
Cc: Srihari Sangli <ssangli@juniper.net>; Shraddha Hegde <shraddha@juniper.net>
Subject: RE: [spring] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04#page-24

Hi Rajesh:
The answer to your question, I think, had better be provided by Authors of NET-PGM, You can also refer to Ron’s email previously one or two days before who give some guess, I think it make sense, in addition , also including processing-load mitigation in Last hop (egress PE);
Could you Pls explain the benefit of similar behavior in PHP of MPLS world.  I think it may be same.

--------------------------------------
Cheers !


WANG Weibin

From: Rajesh M <mrajesh@juniper.net<mailto:mrajesh@juniper.net>>
Sent: 2019年10月18日 20:18
To: Wang, Weibin (NSB - CN/Shanghai) <weibin.wang@nokia-sbell.com<mailto:weibin.wang@nokia-sbell.com>>; Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org<mailto:mrajesh=40juniper.net@dmarc.ietf.org>>; Pablo Camarillo (pcamaril) <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>
Cc: Srihari Sangli <ssangli@juniper.net<mailto:ssangli@juniper.net>>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Subject: RE: [spring] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04#page-24

I was more focused towards END.DT4 SID where behavior you mentioned is possible only if we do below optimization in https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-dawra-bess-srv6-services-02__;!8WoA6RjC81c!VLXDHwQhv3Ai4Cky1wjCRKLg4MMbWlArh2rC0Srmtc6uKxdGYoSjuGxkKh-cx1pT$>  section 3.

when the received route is colored with an extended color community 'C' and Next-Hop 'N', and the ingress PE has a valid SRv6 Policy (C, N) associated with SID list <S1,S2, S3>, then the effective SR Policy is <S1, S2, SRv6-Service-SID>.Here if you see
S3 and SRv6-Service-SID both belong to Egress so s3 has been removed.


For you my query is removing only SRH header on PHP router will give what kind of advantage ?

Thanks
Rajesh





Juniper Business Use Only
From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of Wang, Weibin (NSB - CN/Shanghai)
Sent: Friday, October 18, 2019 9:26 AM
To: Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org<mailto:mrajesh=40juniper.net@dmarc.ietf.org>>; Pablo Camarillo (pcamaril) <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>
Cc: Srihari Sangli <ssangli@juniper.net<mailto:ssangli@juniper.net>>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Subject: Re: [spring] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04#page-24<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04*page-24__;Iw!8WoA6RjC81c!Xvm3hzUGljwi9nBE2mtVYPtMItbLLS1EMD8VDmp4d3K0OZliIbHVQDKF1Nw-lbbm$>

The value of Segment Left field in SRH begin with 0, so [SL]=0 represent the last SID. in this case, when [SL] decrease 1, and the penultimate SRv6 node copy IPv6 SID corresponding to [SL]=0 to DA field of IP packet, when enable PSP flavor at same time, the penultimate SRv6 node will check the [SL] value, if it is 0, then pop SRH, these extra action is pseudocode of PSP. This logic has no problem.


--------------------------------------
Cheers !


WANG Weibin

From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of Rajesh M
Sent: 2019年10月18日 6:38
To: Pablo Camarillo (pcamaril) <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>
Cc: Srihari Sangli <ssangli@juniper.net<mailto:ssangli@juniper.net>>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Subject: Re: [spring] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04#page-24<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04*page-24__;Iw!8WoA6RjC81c!Xvm3hzUGljwi9nBE2mtVYPtMItbLLS1EMD8VDmp4d3K0OZliIbHVQDKF1Nw-lbbm$>

WANG had given below use case : But using existing PSP logic this will not work.
In below at PSP router updated SL will be 1 (since END.DT4 is still there) ,so SRH pop won’t happen.



   S14.1.   If (updated SL == 0) {

   S14.2.      Pop the SRH

   S14.3.   }

WANG use case:
“For example in SRv6-based L3VPN service scenario, The ingress PE within SRv6-enabled domain can utilize SR-TE policy to enable TE-path function when encapsulating and transiting L3VPN traffic, The Ingress PE push on customer packets with SID list representing SR-TE policy plus END.DT4 as last SRv6 SID in SRH; So I think, each flavor of PSP/USP/USD can be designed to perform in related SRv6 endpoint. Imaging the PSP, the penultimate Endpoint can perform PSP, e.g. copy the last SID (END.DT4) of SRH to destination field of IPv6 header and POP the SRH, then forwarding it toward egress PE identified by DA”







Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <pcamaril@cisco.com<mailto:pcamaril@cisco..com>>
Sent: Tuesday, October 15, 2019 10:13 PM
To: Rajesh M <mrajesh@juniper.net<mailto:mrajesh@juniper.net>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>
Cc: Srihari Sangli <ssangli@juniper.net<mailto:ssangli@juniper.net>>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Subject: Re: [spring] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04#page-24<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04*page-24__;Iw!8WoA6RjC81c!Wogoc-HBxWprNFIMxDGoprcCPpEqeSUK6WmLst9CNbljhrh-Ur4yOghFj3kDJQnV$>

Rajesh,

This has already been replied less than one week ago.. Please see:
https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c__;!8WoA6RjC81c!W8zXtokq31cYlPoLJ6Ip-BlyXApb7JIhuJzRXW3khd_OAByxCvaxs9Jw7HGIr9o9$>
https://mailarchive.ietf.org/arch/msg/spring/WrYzRZC0HKVgBYaYMCQVcTWrfak<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/WrYzRZC0HKVgBYaYMCQVcTWrfak__;!8WoA6RjC81c!W8zXtokq31cYlPoLJ6Ip-BlyXApb7JIhuJzRXW3khd_OAByxCvaxs9Jw7P8QaU_7$>

Thanks,
Pablo.


From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> on behalf of Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org<mailto:mrajesh=40juniper.net@dmarc.ietf.org>>
Date: Friday, 11 October 2019 at 03:47
To: SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>
Cc: Srihari Sangli <ssangli@juniper.net<mailto:ssangli@juniper.net>>, Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Subject: [spring] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04#page-24<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04*page-24__;Iw!8WoA6RjC81c!Wogoc-HBxWprNFIMxDGoprcCPpEqeSUK6WmLst9CNbljhrh-Ur4yOghFj3kDJQnV$>


Wanted to know the use case where we only POP the SRH ?

4.16.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04*section-4.16.1__;Iw!8WoA6RjC81c!W8zXtokq31cYlPoLJ6Ip-BlyXApb7JIhuJzRXW3khd_OAByxCvaxs9Jw7DAv5v98$>..  PSP: Penultimate Segment Pop of the SRH

   The SRH processing of the End, End.X and End.T behaviors are

   modified: after the instruction "S14.  Update IPv6 DA with Segment

   List[Segments Left]" is executed, the following instructions must be

   executed as well:



   S14.1.   If (updated SL == 0) {

   S14.2.      Pop the SRH

   S14.3.   }



Juniper Business Use Only