Re: [spring] Is srv6 PSP a good idea

"Pablo Camarillo (pcamaril)" <pcamaril@cisco.com> Sat, 14 December 2019 09:57 UTC

Return-Path: <pcamaril@cisco.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 6C0E212008C for <spring@ietfa.amsl.com>; Sat, 14 Dec 2019 01:57:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=QZO+f3aD; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mp3FPyhH
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 Uj8CwoxVoVe9 for <spring@ietfa.amsl.com>; Sat, 14 Dec 2019 01:57:12 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4717612006B for <spring@ietf.org>; Sat, 14 Dec 2019 01:57:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9574; q=dns/txt; s=iport; t=1576317432; x=1577527032; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=UjuOYTMsVbmI2PlyE5IeG2csecyWEt2CQGhgkj0HwHA=; b=QZO+f3aDb1ab8BJkVsnoLdNb1p0nWUfLLRhWauTjoAWU1bu11n1VRuhl HtBebxe5QF4sKqpIFPECGzf/wbXQrhbzS0MA3Z/UNdOwc90LapcAUgw+D qCC472PO6qDF8xhZj6LRwQEN41Ccla2IVeSC5ZquQ4jFs6eeftlZJ5OZ5 0=;
IronPort-PHdr: 9a23:400e9hxr0cxBS9fXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1kAgMQSkRYnBZudAkT+JeTrawQxHd9JUxlu+HToeUU=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DzCADbr/Rd/4YNJK1lHAEBAQEBBwEBEQEEBAEBgX6BS1AFbFggBAsqCoN5g0YDiw5OgWwlmAaBQoEQA1QJAQEBDAEBGAsKAgEBgUyCL0UCF4F4JDgTAgMNAQEEAQEBAgEFBG2FCwYmDIVeAQEBAQIBAQEQEQQNDAEBLAwLBAIBCBEDAQEBAwIjAwICAiULFAEICAIEARIigwABgkYDDiABAwuhNwKBOIhhdX8zgn4BAQWFExiCFwMGgQ4ojBgagUE/gREnDBSCHi4+gmQBAYFLGBeCeTKCLI0+gnSPDCKPHAqCNIxdiScUB5EkiSSLbYJfmkcCBAIEBQIOAQEFgWkigVhwFTsqAYJBUBEUixyBdgkDF4NQhRSFP3QBgSeMewGBDwEB
X-IronPort-AV: E=Sophos;i="5.69,313,1571702400"; d="scan'208";a="382875410"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Dec 2019 09:57:11 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id xBE9vBgv021797 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 14 Dec 2019 09:57:11 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 14 Dec 2019 03:57:10 -0600
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 14 Dec 2019 04:57:10 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 14 Dec 2019 03:57:09 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TybyB0I//T7mg8/K+3vA0W3qT+WYPq4n4r8qwTgl6WrmajZsht9Wj9mx+QYXc2J50U53+AGK+RZYVu0/IKXFLaMXmdIR77MYeZF/Kol834fr90utzRY5fOQvdCc3IeiS3joqvnjZGp5+FaBwbUul3TN7/PPHREuUHLocPLTtJFIIjw01V1xQ7jVtHhEzdIZXK35pqSYQnD6WJSnSmadQB8usRwMH3vGxeVfrLdiVRQP+eRnOQB66jHhNjs8RcJdycVU/1BGd2FszNNbQgcmevcCZdoVu56jYK2hb4PF/DnNEABUkzRF2kFmn35vYgeXRNAnSfaKCzNrnHz8yPQYe6w==
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=UjuOYTMsVbmI2PlyE5IeG2csecyWEt2CQGhgkj0HwHA=; b=jQtk1Ey+1dfNYDsmLWCWZCq2Am4T2aGFBj2ijClpaLDs6MjlYd6j4Eb/aeeOxin6/JqG77AbNTzOvhIaxYv/Hrp0MiXCZNM/apVkH/86PxhUhAnqa+iHcR9bn7e7buDFTttc4vpaIjvVCugK8ISNYAaMnuq9iMQCdJ2x0sW3/HG2b1PTNdYlNPlxEYYjdXWJUj2YXw0DIflsZMJ4vzuoI2xjICo9ho+utELKdQdok8XgjxW1PVNcPfm9MbN3szKGXj3XKXcZitrsY28Bztyqga3LWMkaTeTtJHCBVbGTt86DUNY3SbTbbA/moSEtKkO43JxtjM1MFU9xNiHo9lKUhA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UjuOYTMsVbmI2PlyE5IeG2csecyWEt2CQGhgkj0HwHA=; b=mp3FPyhHRoHFCdje35Bh3QyXLdFsFux8AcEEnus8fFCFI6pVq/+jdjQWt5s8yIVPk4ajSqGWXoVFOP2PqCLP76Dr1VY5BrpaH2AoY7awLDMWopJIOMISBqMeCmAGR1vH9mERsCJAnATREosI6/Qg6sug8ATq95CyNIa74MOn624=
Received: from MWHPR11MB1374.namprd11.prod.outlook.com (10.169.234.8) by MWHPR11MB1277.namprd11.prod.outlook.com (10.169.236.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.19; Sat, 14 Dec 2019 09:57:08 +0000
Received: from MWHPR11MB1374.namprd11.prod.outlook.com ([fe80::b04b:c9bb:2378:7a8d]) by MWHPR11MB1374.namprd11.prod.outlook.com ([fe80::b04b:c9bb:2378:7a8d%11]) with mapi id 15.20.2538.017; Sat, 14 Dec 2019 09:57:08 +0000
From: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
To: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] Is srv6 PSP a good idea
Thread-Index: AQHVr85jMV33kJTkH0WlnUgh9KVMGKe0UwiAgAGR8gCAASTbAIACcQKA
Date: Sat, 14 Dec 2019 09:57:08 +0000
Message-ID: <EF38045A-3B36-4897-A900-7DCF7CB54072@cisco.com>
References: <5c2a4b36-0c59-709e-23eb-00f4aa1ce52f@joelhalpern.com> <16253F7987E4F346823E305D08F9115AABAEB42B@nkgeml514-mbx.china.huawei.com> <21AFAEDA-F3B0-45AA-AE49-EB4E5FB73918@cisco.com> <BYAPR15MB3078DEDDBF672EEE0DF931D6D0550@BYAPR15MB3078.namprd15.prod.outlook.com>
In-Reply-To: <BYAPR15MB3078DEDDBF672EEE0DF931D6D0550@BYAPR15MB3078.namprd15.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.20.0.191208
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pcamaril@cisco.com;
x-originating-ip: [88.27.141.80]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6809ae14-c2ca-4996-b905-08d7807bfba5
x-ms-traffictypediagnostic: MWHPR11MB1277:
x-microsoft-antispam-prvs: <MWHPR11MB127787755AB939E2F290ACB9C9570@MWHPR11MB1277.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 025100C802
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(366004)(136003)(396003)(199004)(189003)(13464003)(129404003)(316002)(110136005)(33656002)(5660300002)(6512007)(6486002)(71200400001)(478600001)(966005)(66476007)(66574012)(66946007)(86362001)(76116006)(91956017)(36756003)(2906002)(53546011)(6506007)(8936002)(26005)(81166006)(81156014)(8676002)(2616005)(186003)(64756008)(66556008)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1277; H:MWHPR11MB1374.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Zbe/hmsyye4/tNAT8lXksDZ7DtXx5NEVM5vsM4hEHWoSuvpcHq17ZXYKi9xX80AicGPwAwrY2Suo4qp2S6N9iXhRa3LDgBx8JBTHMkbZE+zr5u0APZAExf4445W9VWjDYYF4j62Rz68c5sNrgSLI2KxRDFp5hO8OOykyLPJkSzhZA0jUt/a5P3GdlyCUr1Fu4KKWhbc3lS4uOojSFQ+dFfJDs8iqhJKq1lRhSTmRTj/rKQlwoMOxI6Qh/ZYcOU/1K7xx3nF/BbZQMidVwAsRLJx5ErZcW5BYaINCddfnTAe0H9Lt9vBVDkiea7tj53RhAYnCJMAn+YsGkwTK9FXtRLs4AqUnvhEKl3Ww21EYDK6ygAhUktvtGJEDj/yjAxnhiRXj5lIJesD9UauDy7XzZ+cvacYTccQR3gJro+VoS1amJ8WObzAkjPi+YAGp3dmKr/qqhkWY5vCXz+FqyR2QxGNI/rtprRD/w42tGnNvixxlWoHg+4p7geX2JRl+UCfIPhmViaFVS2lRkAOAw8hg/PPHmwQBx7gM0WfQfILBAPWu5cXz+ZqxnvsprybzymlR
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <E8DAEC887694FC4085924CEB38BAE41E@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6809ae14-c2ca-4996-b905-08d7807bfba5
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2019 09:57:08.5880 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: xTjUJDF9VvYX2btbCQ2/PsLt9/GLlT4DDtbCawQSLG4TIYoJmWZcl4m4cxHiKJoDS0Gl7UlromX/h4t/N99r1A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1277
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com
X-Outbound-Node: alln-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/CH_l9iLk64-Pjyst-OHUxgxVGJI>
Subject: Re: [spring] Is srv6 PSP a good idea
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, 14 Dec 2019 09:57:15 -0000

Hi Dave,

Thank you for participating in the discussion.

I fail to see how it "fragmentation becomes particularly ugly". What is the negative impact to the final destination? I believe there is none.
Intuitively I tend to agree with Jingrong that PSP is beneficial since the egress PE will have easier access to the fragmentation header.

Regardless of whether it has any benefit: note that the source is the one choosing which segments that go into the SRH. As such, it can encode into the packet a penultimate segment with no PSP support. PSP is optional and it is advertised in the control plane so that the source can decide whether to use it.

Thank you,
Pablo.

-----Original Message-----
From: David Allan I <david.i.allan@ericsson.com>
Date: Thursday, 12 December 2019 at 22:40
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>, "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "spring@ietf.org" <spring@ietf.org>
Subject: RE: [spring] Is srv6 PSP a good idea

    Hi Pablo
    
    Looking over the benefits list, Irrespective of any other merits, I'd actually suspect that 1.3/example 2 is kind of a specious benefit. 
    
    My reasoning is if fragmentation has occurred, and the NSH has been replicated in all fragments and needs to be removed from each fragment by the penultimate SR. This offers minimal benefit to the reassembly function at the ultimate Segment Router.
    
    IMO SRH removal at an intermediate device is a more complex operation.  In a simplistic description of operation it adds at a minimum, parsing and a memcpy of the payload. In effect it replaces Start_of_payload_ptr += length (SRH) at the ultimate SR with memcpy (start_of_SRH_ptr, start_of_SRH_ptr+length(SRH), length(SRH)) at the penultimate SR.
    
    So skipping over the exhausted SRH would appear to be trivial compared to the work at the penultimate segment router to remove it entirely. IMO it does not offer benefits equivalent to PHP in MPLS
    
    The same argument could be considered without fragmentation, but fragmentation becomes a particularly ugly example.
    
    Hope this helps
    Dave
    
    
    
    -----Original Message-----
    From: spring <spring-bounces@ietf.org> On Behalf Of Pablo Camarillo (pcamaril)
    Sent: Wednesday, December 11, 2019 12:12 PM
    To: Xiejingrong (Jingrong) <xiejingrong@huawei.com>; Joel M. Halpern <jmh@joelhalpern.com>; spring@ietf.org
    Subject: Re: [spring] Is srv6 PSP a good idea
    
    Jingrong,
     
    > Nothing new, but benefits that people have already said seems notable to me.
    
    Agreed.
    
    Cheers,
    Pablo.
    
    -----Original Message-----
    From: spring <spring-bounces@ietf.org> on behalf of "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
    Date: Wednesday, 11 December 2019 at 05:15
    To: "Joel M. Halpern" <jmh@joelhalpern.com>, "spring@ietf.org" <spring@ietf.org>
    Subject: Re: [spring] Is srv6 PSP a good idea
    
        I think it's a good idea.
        Nothing new, but benefits that people have already said seems notable to me.
        
        (1) reduce the load of final destination. This benefit can be notable for the following sub reasons.
        (1.1) final destination tends to have heavy load. It need to handle all the EHs and do the delivery/demultiplex the packet to the right overlay service.
        (1.2) example 1, the final destination may need to handle the DOH after the RH.
        (1.3) example 2, the final destination may need to do the assembly of fragmented packets.
        (1.4) example 3, the final destination may need to do AH/ESP after the Fragmentation Header.
        (1.5) example 4, the final destination may need to deliver the packet to the right overlay service.
        
        (2) support the incremental deployment when final destination(s) do not process/recognize SRH. This benefit can be notable for the following sub reasons.
        (2.1) A core router may (fan-out) connected with a big number of low-end routers that do not support SRH but support tunnel-end/service-demultiplex function of SRv6.
        
        Thanks
        Jingrong
        
        -----Original Message-----
        From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Joel M. Halpern
        Sent: Wednesday, December 11, 2019 10:55 AM
        To: spring@ietf.org
        Subject: [spring] Is srv6 PSP a good idea
        
        For purposes of this thread, even if you think PSP violates RFC 8200, let us assume that it is legal.
        
        As I understand it, the PSP situation is:
        o the packet arrives at the place (let's not argue about whether SIDs are locators) identified by the SID in the destination address field o that SID is the next to last SID in the SID list o that sid is marked as / known to be PSP o at the intended place in the processing pseudocode, the last (first) entry in the SRH is copied into the destination IPv6 address field of the packet
        -> The SRH being used is then removed from the packet.
        
        In order to evaluate whether this is a good idea, we have to have some idea of the benefit.  It may be that I am missing some of the benefit, and I would appreciate clarification.
        As far as I can tell, the benefit of this removal is that in exchange for this node doing the work of removing the SRH, the final node in the SRH does not have to process the SRH at all, as it has been removed.
        
        I have trouble seeing how that work tradeoff can be beneficial. 
        Removing bytes from the middle of a packet is a complex operation. 
        Doing so in Silicon (we expect this to be done in the fast path of significant forwarders as I understand it) requires very special provision.  Even in software, removing bytes from the middle of a packet requires somewhere between some and a lot of extra work.  It is distinctly NOT free.
        
        In contrast, we have assumed that the work of processing SRH itself is tractable, since otherwise all of SRv6 would be problematic.  So why is this necessary.
        
        Yours,
        Joel
        
        PS: Note that both the MPLS case and the encapsulation case are very different in that the material being removed is at the front of the IP packet.  Pop or prepend are MUCH easier than middle-removal (or middle-insertion).
        
        _______________________________________________
        spring mailing list
        spring@ietf.org
        https://www.ietf.org/mailman/listinfo/spring
        
        _______________________________________________
        spring mailing list
        spring@ietf.org
        https://www.ietf.org/mailman/listinfo/spring
        
    
    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring