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

Robert Raszuk <robert@raszuk.net> Wed, 04 March 2020 22:04 UTC

Return-Path: <robert@raszuk.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 671D93A0A3A for <spring@ietfa.amsl.com>; Wed, 4 Mar 2020 14:04:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 KmZHyRx1txcw for <spring@ietfa.amsl.com>; Wed, 4 Mar 2020 14:04:30 -0800 (PST)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E95D3A0A39 for <spring@ietf.org>; Wed, 4 Mar 2020 14:04:30 -0800 (PST)
Received: by mail-ot1-x336.google.com with SMTP id x19so3653101otp.7 for <spring@ietf.org>; Wed, 04 Mar 2020 14:04:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rbE3p54IIV/mxoAvW0Ik2sB2+wDMQGTkMI6p2nhMeJw=; b=GzHMxgsYgBguHe8fZ6fOp8+7WJvl43uIVLuzSVVlwwxLSaR7ua5PcxzaZOVYJGkc/H fT/5exnUKnrp6c1XQiekpkBlPW1phOBPAMVP4949A337WtoFNEqRmvKS//DDU86ay2ra fjr8jQVJosGig2LYwWx/ZM+T7ZpzB41cAirfJgh2lKSyJkBecvDpoxJ/BuiFYJ2uzjJr yV5/+9ylk7rQ4F81VZWEYoU/yxO8/qC3SndZbSEh4hBUJbamXsfwoEj1sGB2m8xv+miB EexZN32kQeKDDEoXC3YEiKgOhN2VDhPA92u4oZ2ilGCzX774m5ZChRmdLVM3Iooft8e9 V+Kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rbE3p54IIV/mxoAvW0Ik2sB2+wDMQGTkMI6p2nhMeJw=; b=QjHBXYGhwwNuo8KftlKLOWakQ46QwAqeMN1oxExLwM0xA5EQvWusxwoknNg+xi6IQA qB9rjYpKHZvROTpoJVOG3oMHMr4aV7iO8qU5DxPxHBqFRDuyl0nZMtXK36e1RwfN/8ll LXzAsjc9XSpcDs74cfY4bNqbHF1G7TWHrHL+HOgYf+PkiIKX14YijnTy5X/TIRpnO+0O zujR3+16W+4ikWc2SvlMXCojC4k67zBctAnl+487/QVRDc+qPFEz3UcqQtdsaFeQkuR7 5qin5SIuaqv4yHz3sUyaUkfebAYtE9vyT69JJTr1frj4Pyk6j3bAHCnzWGS+uMqycGUr rBWg==
X-Gm-Message-State: ANhLgQ12GP5O3/wGgWHhENBmqqrNTL6JElY2JT8f+OFz91AK33FW4CUk QWohltS/n16kpTlOtDJYg0de8V/MhAMQz55DWO/Ntw==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vvLtN2tZfFPO3bzsodRczwbkdghN8yXgH4/jUyr?= =?utf-8?q?OM6swT99DSp/nF6GHYF0qjp2DHYcl1CJrWRqZ/GSMmj7VaM=3D?=
X-Received: by 2002:a05:6830:4a6:: with SMTP id l6mr4245578otd.61.1583359469592; Wed, 04 Mar 2020 14:04:29 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <82CDEB1D-29D0-4353-AFF8-E46389F7080A@liquidtelecom.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 4 Mar 2020 23:04:21 +0100
Message-ID: <CAOj+MMG6QiWtT8D4+iyfDs1zx5CkB6McQz-NHHz8uEKWpNy+RQ@mail.gmail.com>
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
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>
Content-Type: multipart/alternative; boundary="000000000000bcb3b905a00e9af4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/RMaDTL29mVeIqBKCrCRToWP3y8k>
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 22:04:32 -0000

> 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> 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> on behalf of "Joel M. Halpern" <
> jmh@joelhalpern.com>
> *Date: *Thursday, 5 March 2020 at 00:25
> *To: *"Darren Dukes (ddukes)" <ddukes@cisco.com>
> *Cc: *"spring@ietf.org" <spring@ietf.org>rg>, Martin Vigoureux <
> 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: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
> >
>
> _______________________________________________
> 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
>