Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Andrew Alston <Andrew.Alston@liquidtelecom.com> Thu, 05 March 2020 01:51 UTC

Return-Path: <andrew.alston@liquidtelecom.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 428F53A083F for <spring@ietfa.amsl.com>; Wed, 4 Mar 2020 17:51:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 4BYECvTyebNb for <spring@ietfa.amsl.com>; Wed, 4 Mar 2020 17:51:47 -0800 (PST)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [207.82.80.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13C4F3A083E for <spring@ietf.org>; Wed, 4 Mar 2020 17:51:46 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp2057.outbound.protection.outlook.com [104.47.2.57]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-222-Jz_D5eAuM3Sml5d-_s4OXg-1; Thu, 05 Mar 2020 01:51:38 +0000
X-MC-Unique: Jz_D5eAuM3Sml5d-_s4OXg-1
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com (20.179.47.79) by DBBPR03MB5287.eurprd03.prod.outlook.com (10.255.78.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.16; Thu, 5 Mar 2020 01:51:37 +0000
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com ([fe80::31cd:8171:1d1f:2fa9]) by DBBPR03MB5415.eurprd03.prod.outlook.com ([fe80::31cd:8171:1d1f:2fa9%5]) with mapi id 15.20.2772.019; Thu, 5 Mar 2020 01:51:36 +0000
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: Robert Raszuk <robert@raszuk.net>
CC: "Joel M. Halpern" <jmh@joelhalpern.com>, "Darren Dukes (ddukes)" <ddukes@cisco.com>, "spring@ietf.org" <spring@ietf.org>, Martin Vigoureux <martin.vigoureux@nokia.com>
Thread-Topic: [spring] WGLC - draft-ietf-spring-srv6-network-programming
Thread-Index: =?utf-8?q?AdWrjZKMyJw/FcG0Qj29O28HuDn7+xFNkTUAAAMg8IAAKLwhgAAB?= =?utf-8?q?NaWAAAHeLgAAAGe2AAAD1sGQAAHPQgAABuLOAAAn360QAAYCKoAAACMrgAAHbDKA/?= =?utf-8?q?//Pc4CAAHHGAA=3D=3D?=
Date: Thu, 5 Mar 2020 01:51:36 +0000
Message-ID: <5A24EE4B-F18F-4186-90B0-1BB0EA30C7B7@liquidtelecom.com>
References: =?utf-8?q?=3C17421=5F1575566127=5F5DE93B2F=5F17421=5F93=5F1=5F53?= =?utf-8?q?C29892C857584299CBF5D05346208A48D1A3DA=40OPEXCAUBM43=2Ecorporate?= =?utf-8?q?=2Eadroot=2Einfra=2Eftgroup=3E?= <3e2da3a5-5d1b-10a0-aeb4-320c57584241@nokia.com> =?utf-8?q?=3C8259d37e-b460-5f76-1ce6-b0d026bccf6b=40gont=2Ecom=2Ear=3E_=3C2?= =?utf-8?q?0143=5F1583250558=5F5E5E7C7E=5F20143=5F390=5F3=5F53C29892C8575842?= =?utf-8?q?99CBF5D05346208A48DD80E6=40OPEXCAUBM43=2Ecorporate=2Eadroot=2Einf?= =?utf-8?q?ra=2Eftgroup=3E?= =?utf-8?q?=3C5d693a5e-baa0-6ffb-4e39-2695795b7413=40joelhalpern=2Ecom=3E_?= =?utf-8?q?=3C7501=5F1583255845=5F5E5E9125=5F7501=5F499=5F1=5F53C29892C85758?= =?utf-8?q?4299CBF5D05346208A48DD84FF=40OPEXCAUBM43=2Ecorporate=2Eadroot=2Ei?= =?utf-8?q?nfra=2Eftgroup=3E?= =?utf-8?q?=3Cfc5bf8d9-073f-2eff-6041-e1610bf6e116=40joelhalpern=2Ecom=3E_?= =?utf-8?q?=3CDM6PR05MB63484795948C4901C9B7A548AEE40=40DM6PR05MB6348=2Enampr?= =?utf-8?q?d05=2Eprod=2Eoutlook=2Ecom=3E?= <CAOj+MMGE+j7_QnFn-8ZQcU3BKLGEPaXj6hfppxG7-7iFkT3R1g@mail.gmail.com> =?utf-8?q?=3CCAA=3DduU3fXaQY--XufYo+CuCnJsTd+bXH2uBbjUUHVJg6tLpzng=40mail?= =?utf-8?q?=2Egmail=2Ecom=3E_=3CDM6PR05MB63489FBEF2D0FBAB1322E4B2AEE50=40DM6?= =?utf-8?q?PR05MB6348=2Enamprd05=2Eprod=2Eoutlook=2Ecom=3E?= <90D3C257-F254-4C04-9B62-039DC7A7300D@cisco.com> <5d066bc0-34a1-f06f-e714-548909edb92d@joelhalpern.com> <82CDEB1D-29D0-4353-AFF8-E46389F7080A@liquidtelecom.com> <CAOj+MMG6QiWtT8D4+iyfDs1zx5CkB6McQz-NHHz8uEKWpNy+RQ@mail.gmail.com>
In-Reply-To: <CAOj+MMG6QiWtT8D4+iyfDs1zx5CkB6McQz-NHHz8uEKWpNy+RQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.21.0.200113
x-originating-ip: [2c0f:fe40:3:3:9129:5211:eff3:eec2]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: a53f5942-f297-462f-b600-08d7c0a7bda1
x-ms-traffictypediagnostic: DBBPR03MB5287:
x-microsoft-antispam-prvs: =?utf-8?q?=3CDBBPR03MB528736FAF4D19793ADB279A7EEE?= =?utf-8?q?20=40DBBPR03MB5287=2Eeurprd03=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03333C607F
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810019020=29=284636?= =?utf-8?b?MDA5KSgxMzYwMDMpKDM2NjAwNCkoMzc2MDAyKSgzOTYwMDMpKDM0NjAwMikoMzk4?= =?utf-8?b?NjA0MDAwMDIpKDE4OTAwMykoMTk5MDA0KSg4Njc2MDAyKSg1MzU0NjAxMSko?= =?utf-8?q?86362001=29=282906002=29=28966005=29=286506007=29=2871200400001?= =?utf-8?b?KSgzMTYwMDIpKDU0OTA2MDAzKSg4MTE2NjAwNikoODExNTYwMTQpKDY5MTYwMDkp?= =?utf-8?q?=288936002=29=2864756008=29=28186003=29=2836756003=29=28566030000?= =?utf-8?b?MikoOTE5NTYwMTcpKDY2NDQ2MDA4KSg3NjExNjAwNikoMjYxNjAwNSkoNjY1?= =?utf-8?q?56008=29=2866476007=29=2866946007=29=286512007=29=28478600001=29?= =?utf-8?q?=286486002=29=284326008=29=2833656002=29=3B?= DIR:OUT; SFP:1102; SCL:1; SRVR:DBBPR03MB5287; H:DBBPR03MB5415.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?0TXJwqf3WZtmxDKqdPR8XnnnyPJu7xq?= =?utf-8?q?4uykA0F3wBj8PtNfIShvZjbp3DdTF9mtd+BFrD302jwiIb8quDg7nPrwXXcfIqn2T?= =?utf-8?q?8ZZp1SANZHcYCZKNqsYlqidEJpugeoxTqGTiIRO6o1+wgTAOLruyuAULjHK+LLMau?= =?utf-8?q?u58zkjvzOcdSOYXZ84suunAy6yey57ZPaGs+sxww+zByBIIsHf1gpTqSjZ6uRk9Jy?= =?utf-8?q?7+kwZlgpvB9q8vH2qWT98rrZLCYq1wjWr5btsohzrPAjLauO0uz6acfkNZKuAZojS?= =?utf-8?q?Aj7gKeAdGq1gaI/YHJFwWyTiDEE5V/IR868Zyvec6WC+x9xnuMwMDR9LuCeYSlaD1?= =?utf-8?q?QaQprdRlcl+ug4MxtPAYSQ6uDGsXp3I4S4okr6RPxlqGiEh1BfNV17UXpSLwqfn3d?= =?utf-8?q?qAg2l7MVLW5U4hRWg29fjbh6LQHCohqwJ6PKwvQHODtBoi74++iKHl8L0t3s9FLZu?= =?utf-8?q?LwHkp2kH8xtkq5OhKFUBcaLWxqHqNM/OsdFGU6mJPg3qhaEQ=3D=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?ipR3TLQNkSFxlNpzDUxb5viUa/AnaQ?= =?utf-8?q?4+qZUsGI+F0Wpj9ricFFJSJEsK3NyVwCtDydsiCZGbMlrTehkjXUJtFtbiWh+5wlS?= =?utf-8?q?5EwuqP/5AsOrm0fk9PazMhJR4FILocUOFgH8SUU+8IDW6i9iDbP8UkUqlOdvqU5xB?= =?utf-8?q?xzPcgYrML8ebBs09Swec6NZ09cr+92DsAaUhbblze/DpThVz7sSvuA=3D=3D?=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a53f5942-f297-462f-b600-08d7c0a7bda1
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2020 01:51:36.8278 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: =?utf-8?q?1vSAz8l1IjH18WM1HmxaB?= =?utf-8?q?qxFhV2WXbJ2Clx1m1y5awhq5tc/F3C4451bF3D9gCDUPzfCEzDqIafiqNHgm+Bypj?= =?utf-8?q?0oMqCJrvwpJYGLsrarugk=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB5287
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: liquidtelecom.com
Content-Type: multipart/alternative; boundary="_000_5A24EE4BF18F418690B01BB0EA30C7B7liquidtelecomcom_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/HjW7gz3v4tGwUQHQP2GYBxeqS7I>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
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: Thu, 05 Mar 2020 01:51:51 -0000

Robert –

When I am told by a vendor – explicitly – with no ambiguity – that on certain platforms – they will never support IPv6 in the context of SR-MPLS on certain platforms – and it was SRv6 or nothing if I wanted SR  – then – yes – I am being pushed in a particular direction – without question.  For now – I will refrain from naming said vendor – but they are free to raise their hands and own up to it if they choose to do so

Andrew


From: Robert Raszuk <robert@raszuk.net>
Date: Thursday, 5 March 2020 at 01:04
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>om>, "Darren Dukes (ddukes)" <ddukes@cisco.com>om>, "spring@ietf.org" <spring@ietf.org>rg>, Martin Vigoureux <martin.vigoureux@nokia.com>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming


> When a vendor is pushing me to implement a technology

Last time I checked SRv6 is not enabled by default by any code base. What type of "vendor push" are you referring to ? Maybe you can share which vendor is pushing you with such strong push that you can not resist ?

Thx,
R.


On Wed, Mar 4, 2020 at 10:58 PM Andrew Alston <Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com>> wrote:
I have to second the below from an operator perspective.

When a vendor is pushing me to implement a technology – yet not disclosing that implementing it could result in serious network degradation dependent on the boxes I have in the network and their positioning – that exposes me as an operator to a position of either roll back – or forced upgrades and potentially significant cost.


Thanks

Andrew


From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> on behalf of "Joel M. Halpern" <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>
Date: Thursday, 5 March 2020 at 00:25
To: "Darren Dukes (ddukes)" <ddukes@cisco.com<mailto:ddukes@cisco.com>>
Cc: "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>, Martin Vigoureux <martin.vigoureux@nokia.com<mailto:martin.vigoureux@nokia.com>>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Darren, could you please comment on the behavioral / deployment
implications I believe I identified in my recent email about the use
case? It does seem to me that something needs to be said about the
implications of the use case. Yes, we do sometimes make allowances in
protocol design for deficient but complaint implementations. But we do
not pretend that there are not issues when doing so. And we try to
identify the needs clearly.

Yours,
Joel

On 3/4/2020 4:21 PM, Darren Dukes (ddukes) wrote:
> Hi Ron
>
> I don’t think you are really asking equipment vendors to provide that
> information on this list.  That will not happen.
>
> I’ll simply repeat what has been stated by others on this list.
> Products with limited ability to receive and process a packet containing
> a RH when SL==0 exist.
> PSP provides a means of allowing those products to be used as a PE.
>
> Thanks
>   Darren
>
>> On Mar 4, 2020, at 3:01 PM, Ron Bonica
>> <rbonica=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>
>> <mailto:rbonica<mailto:rbonica>=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>>> wrote:
>>
>> Andy,
>> AFAIKS, the only use case PSP is to accommodate SRv6 egress nodes that:
>>
>> * Can process an SRv6  SID that appears in the IPv6 Destination Address
>> * Can process the SRH with Segments Left equal to 0
>> * But cannot process the SRH with Segments Left equal to 0 at high speed
>>
>> I am not aware that any such device exists. Does anybody know of one?
>>                                                    Ron
>> *From:*Andrew G. Malis <agmalis@gmail.com<mailto:agmalis@gmail.com> <mailto:agmalis@gmail.com<mailto:agmalis@gmail.com>>>
>> *Sent:*Tuesday, March 3, 2020 6:28 PM
>> *To:*Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net> <mailto:robert@raszuk.net<mailto:robert@raszuk.net>>>
>> *Cc:*Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>
>> <mailto:rbonica@juniper.net<mailto:rbonica@juniper.net>>>;bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>
>> <mailto:bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>;spring@ietf.org<mailto:spring@ietf.org>
>> <mailto:spring@ietf.org<mailto:spring@ietf.org>>; Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>
>> <mailto:jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>>; Martin Vigoureux
>> <martin.vigoureux@nokia.com<mailto:martin.vigoureux@nokia.com> <mailto:martin.vigoureux@nokia.com<mailto:martin.vigoureux@nokia.com>>>
>> *Subject:*Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
>> MPLS PHP was invented to solve a particular issue with some forwarding
>> engines at the time - they couldn't do a final pop followed by an IP
>> lookup and forward operation in a single forwarding cycle (it would
>> impact forwarding speed by 50% best case). 20 years later, is this
>> still an issue at the hardware/firmware level? If so, affected
>> implementers should speak up, otherwise there's really no need for PSP.
>> Cheers,
>> Andy (who was there at the time)
>> On Tue, Mar 3, 2020 at 3:11 PM Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>
>> <mailto:robert@raszuk.net<mailto:robert@raszuk.net>>> wrote:
>>
>> Hi Ron,
>> >   MPLS PHP is a clear case of de-encapsulation.
>> Purely looking at technical aspect that is not true at all.
>> MPLS PHP does not remove label stack. MPLS PHP is just used to pop
>> last label. After MPLS PHP packets continue with remaining label
>> stack to the egress LSR (example L3VPN PE).
>> >  I don't think that you can compare MPLS PHP with SRv6 PSP
>> But I agree with that. Both operations have very little in common
>> from packet's standpoint or forwarding apect. Well maybe except
>> "penultimate" word :)
>> Kind regards,
>> R.
>> On Tue, Mar 3, 2020 at 8:30 PM Ron Bonica
>> <rbonica=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>
>> <mailto:40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>>> wrote:
>>
>> Folks,
>>
>> I don't think that you can compare MPLS PHP with SRv6 PSP.
>> MPLS PHP is a clear case of de-encapsulation. We do that all
>> the time. In SRv6 PSP, we are removing something from the
>> middle of a packet. That is quite a different story.
>>
>>
>>
>>           Ron
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org<mailto:spring@ietf.org> <mailto:spring@ietf.org<mailto:spring@ietf.org>>
>> https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QEhtnK3a_SkTtK5jFwY7ANmF22RCkp657bAyNJfcGg1xaI_ewfHQHKp7NIgQ3SpI$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QEhtnK3a_SkTtK5jFwY7ANmF22RCkp657bAyNJfcGg1xaI_ewfHQHKp7NIgQ3SpI$>>
>> Juniper Business Use Only
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org<mailto:spring@ietf.org> <mailto:spring@ietf.org<mailto:spring@ietf.org>>
>> https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
>

_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>