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

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 04 March 2020 21:25 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 653113A094A for <spring@ietfa.amsl.com>; Wed, 4 Mar 2020 13:25:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 myo_pUHpfbwB for <spring@ietfa.amsl.com>; Wed, 4 Mar 2020 13:25:38 -0800 (PST)
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 5BD313A0948 for <spring@ietf.org>; Wed, 4 Mar 2020 13:25:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 48Xn3k1lj8z6GGDD; Wed, 4 Mar 2020 13:25:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1583357138; bh=IB/qYy0p4It08/E2F1X+jeXT7ckID4aT4icWp1qLxPg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=lXIEgpnTYDzPZ+w4E9dQ0ur4wM4fBKOoce9PNpSnYZA4UmLIK0X3XMZyooT3qVpf/ YsS4N+Q82QteGHYN42nNU7vt302qZh1tB+Xoybu3arbi5xNu1cpQuRmX/D8VrGKK1A +FtQuWNs/E7xxOSyoH+I7tzqWzBSYVa92EzZY1+Y=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (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 48Xn3j3SP0z6G8Dw; Wed, 4 Mar 2020 13:25:36 -0800 (PST)
To: "Darren Dukes (ddukes)" <ddukes@cisco.com>
Cc: "spring@ietf.org" <spring@ietf.org>, Martin Vigoureux <martin.vigoureux@nokia.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>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <5d066bc0-34a1-f06f-e714-548909edb92d@joelhalpern.com>
Date: Wed, 4 Mar 2020 16:25:35 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <90D3C257-F254-4C04-9B62-039DC7A7300D@cisco.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/S35bRfHqQjBLIvI0tTz9XK5Z_hs>
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: Wed, 04 Mar 2020 21:25:40 -0000

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:rbonica=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>>
>> *Sent:*Tuesday, March 3, 2020 6:28 PM
>> *To:*Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
>> *Cc:*Ron Bonica <rbonica@juniper.net 
>> <mailto:rbonica@juniper.net>>;bruno.decraene@orange.com 
>> <mailto:bruno.decraene@orange.com>;spring@ietf.org 
>> <mailto:spring@ietf.org>; Joel M. Halpern <jmh@joelhalpern.com 
>> <mailto:jmh@joelhalpern.com>>; Martin Vigoureux 
>> <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>> 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>> 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>
>>     https://www.ietf.org/mailman/listinfo/spring
>>     <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>
>> https://www.ietf.org/mailman/listinfo/spring
>