IETF Logo Mail Archive

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

"Joel M. Halpern" <jmh@joelhalpern.com> Sat, 19 October 2019 15:06 UTC

Return-Path: <jmh@joelhalpern.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 47D45120018 for <spring@ietfa.amsl.com>; Sat, 19 Oct 2019 08:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 dm8OZOyQkpcG for <spring@ietfa.amsl.com>; Sat, 19 Oct 2019 08:06:50 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 7542612001A for <spring@ietf.org>; Sat, 19 Oct 2019 08:06:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 46wR7t2ZL8zbjWL; Sat, 19 Oct 2019 08:06:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1571497610; bh=F1j6lQoy1w/qRIQBMEyGxHoEmcjyhWrRTw/Jl5of+ho=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Z1PS+8ZVKK3EzVUxMu+X7eiHtFN+AdMwIem60ymsqpjZGR8KH0db8HLt1cSx8i1xk mOn0Uj+rAwn1h+9mugmubahZtKaKoHPEIh9IgCT0iZMtkSIvGO0o4GY19EhBxlWQ2d 7vVw22rZWi0Ajb9/hufgctdwHQvk+g2n9Np6zm1A=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [10.199.7.89] (65-118-77-72.dia.static.qwest.net [65.118.77.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 46wR7s5vH4zbjWJ; Sat, 19 Oct 2019 08:06:49 -0700 (PDT)
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>, SPRING WG List <spring@ietf.org>
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> <MN2PR05MB6080204CE8F16BE1FC68E713BE6F0@MN2PR05MB6080.namprd05.prod.outlook.com> <MN2PR05MB6080D4E770AB1ABDEF01D360BE6F0@MN2PR05MB6080.namprd05.prod.outlook.com> <CY4PR11MB1541B9E294AC6946BF749CE3C16F0@CY4PR11MB1541.namprd11.prod.outlook.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <5f9a845f-6c50-81a2-a97d-2a85b7a797c4@joelhalpern.com>
Date: Sat, 19 Oct 2019 11:06:47 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CY4PR11MB1541B9E294AC6946BF749CE3C16F0@CY4PR11MB1541.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/zP2ZnC9m9zCLGmdnmIIewS3rpcg>
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 15:06:54 -0000

The fact that T.insert is deployed does not seem particularly relevant  
to the quesiton of whether the working groups (6man and SPRING) will  
approve the draft asking for permission to violate RFC 8200.

I will grant that we have also not decided to deprecate that behavior.  
The groups are still debating.  The authors have appropriately removed  
all of the insert functionality from the base network programming draft.  
  If USP and PSP are coupled to that, then they belong in the draft on  
the insertion behaviors.

Pablo has argued that there is no dependence.  Technically, I have to  
grant it is true.  It still seems that the primary use cases are ones  
which are coupled to the insertion behaviors.

Yours,
Joel

On 10/19/2019 12:22 AM, Ketan Talaulikar (ketant) wrote:
> Hi Rajesh,
> 
> T.insert is definitely not deprecated. Please check 
> https://mailarchive.ietf.org/arch/msg/spring/zRwYRZrKEwzMor2cXpYiag--_y0 
> - I would suggest you go through the archives to get the history/context.
> 
> In fact, it is already deployed – check 
> https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-02
> 
> Thanks,
> 
> Ketan
> 
> *From:*Rajesh M <mrajesh@juniper.net>
> *Sent:* 19 October 2019 09:34
> *To:* Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org>; Wang, Weibin (NSB 
> - CN/Shanghai) <weibin.wang@nokia-sbell.com>; Pablo Camarillo (pcamaril) 
> <pcamaril@cisco.com>; SPRING WG List <spring@ietf.org>; Peter Psenak 
> (ppsenak) <ppsenak@cisco.com>; Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Cc:* Srihari Sangli <ssangli@juniper.net>; Shraddha Hegde 
> <shraddha@juniper.net>; Ron Bonica <rbonica@juniper.net>
> *Subject:* RE: [spring] 
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04#page-24
> 
> if we use T.Insert Mode for TI-LFA then PSP and USP Flavours are useful.
> 
> T.insert mode is  deprecated ? if Yes then PSP and USP Flavours also 
> must be deprecated as per me.
> 
> Thanks
> 
> Rajesh
> 
> Juniper Business Use Only
> 
> *From:*Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org 
> <mailto:mrajesh=40juniper.net@dmarc.ietf.org>>
> *Sent:* Saturday, October 19, 2019 7:59 AM
> *To:* Wang, Weibin (NSB - CN/Shanghai) <weibin.wang@nokia-sbell.com 
> <mailto:weibin.wang@nokia-sbell.com>>; Rajesh M <mrajesh@juniper.net 
> <mailto:mrajesh@juniper.net>>; 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>>; Ron 
> Bonica <rbonica@juniper.net <mailto:rbonica@juniper.net>>
> *Subject:* RE: [spring] 
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04#page-24
> 
> 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 
> <mailto:weibin.wang@nokia-sbell.com>>
> *Sent:* Saturday, October 19, 2019 6:26 AM
> *To:* Rajesh M <mrajesh@juniper.net <mailto:mrajesh@juniper.net>>; 
> 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
> 
> 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 
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-04*page-24__;Iw!8WoA6RjC81c!Tj1RzlZX05hQXJCRb6NfbDmr4p543xmCTIQUDjQsIjiWMC6mn7vFFP39Imon9Has$>
> 
> 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
> 
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>

v2.23.0 | Report a Bug | By Email