Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Greg Mirsky <gregimirsky@gmail.com> Fri, 28 February 2020 16:47 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF423A1B43; Fri, 28 Feb 2020 08:47:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0RtYx0fxnq-w; Fri, 28 Feb 2020 08:47:36 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 5400D3A1B48; Fri, 28 Feb 2020 08:47:32 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id u26so3884889ljd.8; Fri, 28 Feb 2020 08:47:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UgT8Tlu1u1BPo8hKp1yzXWUKXXY8CrHlLRqqrq0hFgw=; b=AApbHteQvYIS+bv1QXmYyE+JxE6My/ITIkd2CGoI38w6fa/NZpT0r/n1OsT3CVy+O+ UZ5kNCRtn1mKpmLhSMvSSBuI0R4Kvg8KppjcWZ0AeY4N2IaLL/ao+CufjHzWxgDZvnix ZfQRdKerxu/JG97JIXz/DrG81tcBv2i6uFErx43JtbCGvN6AVkYKo5JBE4jJJ0d1KeJQ NQofpuDT/S2Aq3HONxCCj0kwblUCIKgE2GhiilAEYgR9AEP3I7/KBfB49mHWEWbuX5Fr jsg2X8xe1ZaP/lEe+N84nQZBuO+5XZTCtsVtLcrM9IoSZPhRU/5ZDQq+Xwh0EituhUfN YbQw==
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=UgT8Tlu1u1BPo8hKp1yzXWUKXXY8CrHlLRqqrq0hFgw=; b=uQukIDx5OPdhzhgh/MOiY55OFvWAiZB/TL2VpxSkyxKxY4tbky/0oUbnZ42CIaZPK1 TuhUgnC263NXZX1Wjx/eoo6HqjeislEM8r5vnGikXbyu1/8FW3Voc+TONRUDqF5fOYE6 stka0PjlD50lMpFAWP5N9CYAumA8zpaaT2Zn/wU3uJu2hBp6kVeDj4UTjaVx0fr6wOiu NqXt5cog36Xdys6kXVDa2+G/vPP7pj2GRsONENSu/xbQYtRm9C94zN/XRwGoNC6Y1hlv i6NFyuq5edyP3mo3TWIMHSmZuYQDuaU4LQocffnA+d0gCvsbsElyya9GcgjyzYNf/ydW LgwA==
X-Gm-Message-State: ANhLgQ18GzwgATdYhUgKPzs4KYl3ofNQfts39R5hPeI0OfO3PHvY8U1j BwbWBha0xJsBUB5TRXbfH60LcdDJwIK6oxImWCHC/ONX
X-Google-Smtp-Source: ADFU+vuhTLM4cUEcb4YrivAkm+XdDLEN7t5bMfDiHRBchJbeOSl463UtkIrbNhusWbDsEx/MmCSxYyT4RDGsKITmasY=
X-Received: by 2002:a2e:7c08:: with SMTP id x8mr3372260ljc.185.1582908449974; Fri, 28 Feb 2020 08:47:29 -0800 (PST)
MIME-Version: 1.0
References: <158248836511.1031.1350509839394231473@ietfa.amsl.com> <7481061F-75A5-4E4D-80AE-40E1F933E94A@cisco.com> <1BB7ED35-98EC-4A73-92A3-AD043D462CF7@steffann.nl> <CAO42Z2zOr_8Ptukf_WE8hWOUUH1vXFig-=fNWhNeweruibQDhw@mail.gmail.com> <DBBPR03MB541525FF72B82416A020B632EEEC0@DBBPR03MB5415.eurprd03.prod.outlook.com> <DM6PR05MB63489BE3D1C669C277D64906AEEC0@DM6PR05MB6348.namprd05.prod.outlook.com> <BEE51E09-0929-4F48-B5B3-6BAB23E07DAB@cisco.com> <CABNhwV3q4MAopb0oXSw4uHezfVLjMnvf8h4BzFY_q8LS7dCXVw@mail.gmail.com> <97141983-EDF7-4C1E-A8F1-4ADCD345BC5A@cisco.com> <DM6PR05MB634859429BEBC90FFA687936AEEB0@DM6PR05MB6348.namprd05.prod.outlook.com> <470E6DF4-0EF8-4EC8-8F84-1D5C84CEC5B9@juniper.net> <CAOj+MMEY+gEPZ3RVp7tcL5q-D-N-hwjmXYY_cFi_OuNQ7+SrbA@mail.gmail.com> <CA+RyBmVH3D1Xpa=PArVipmcSYL60Q9bFuKS409JF2JwZf7a6fQ@mail.gmail.com> <DM6PR05MB6348DCB4349F74E12FA31275AEE80@DM6PR05MB6348.namprd05.prod.outlook.com>
In-Reply-To: <DM6PR05MB6348DCB4349F74E12FA31275AEE80@DM6PR05MB6348.namprd05.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 28 Feb 2020 08:47:17 -0800
Message-ID: <CA+RyBmVcxS-SZ=22u1kDx-fXj9dRqT9PzOR+o-Z62kijcZ-kGQ@mail.gmail.com>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt
To: Ron Bonica <rbonica@juniper.net>
Cc: Robert Raszuk <robert@raszuk.net>, John Scudder <jgs=40juniper.net@dmarc.ietf.org>, SPRING WG <spring@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000df6d6e059fa59720"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/xTLF9kgIq_alRRqzmHTOdOCHGHs>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2020 16:47:43 -0000

Hi Ron,
absolutely agree. And that is, in my opinion, question the authors of
draft-ietf-6man-spring-srv6-oam must clarify in the document. AFAIK, Zafar
and authors are working on the update to address WGLC comments. I'm looking
forward to discuss the changes.

Regards,
Greg

On Fri, Feb 28, 2020 at 8:37 AM Ron Bonica <rbonica@juniper.net> wrote:

>
>
> Beyond that, SRv6 nodes examine the O-flag, even when Segments Left is
> equal to 0. So, when the SRH is removed, O-flag functionality isn’t
> available at the ultimate segment endpoint.
>
>
>
>                                                           Ron
>
>
>
>
>
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Greg Mirsky
> *Sent:* Friday, February 28, 2020 11:22 AM
> *To:* Robert Raszuk <robert@raszuk.net>
> *Cc:* John Scudder <jgs=40juniper.net@dmarc.ietf.org>; SPRING WG <
> spring@ietf.org>; 6man WG <ipv6@ietf.org>
> *Subject:* Re: [spring] I-D Action:
> draft-ietf-spring-srv6-network-programming-10.txt
>
>
>
> Hi Robert,
>
> you've asked about a possible operational drawback of PSP. I think that
> for OAM PSP has decremental effect on the usefulness of performance
> measurements as there's no obvious information to identify the path a
> packet traversed.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Feb 28, 2020 at 2:55 AM Robert Raszuk <robert@raszuk.net> wrote:
>
> Hi John,
>
>
>
> > I have an additional observation, or question, about Dan’s scenario.
> Almost all communication is bidirectional.
>
> > Presumably this means a router that’s the tail end of an SRv6 path in
> one direction is the head end in the other.
>
>
>
> While your observation is correct that most TCP connections are bidir SR
> in a lot of cases can operate only in one direction. Needless to say it can
> also be used with UDP streaming.
>
>
>
> To extend Ketan's OTT video example let me observe that in a lot of
> transactions queries from clients are tiny and do not TE capabilities while
> responses are huge and bursty and may indeed benefit from special handling.
>
>
>
> Sure if you think of applications like VPNs than you are right ...
> regardless of the size of the packets proper tagging must occur in either
> direction - but this is just one use of SRv6 perhaps not even the major
> one.
>
>
>
> - - -
>
>
>
> Now as one friend just asked me offline - putting all IPv6 dogmas aside -
> what is the technical issue with removing previously applied extension
> header from the packet within a given operator's network ? What breaks when
> you do that ?
>
>
>
> Thx,
>
> R.
>
>
>
>
>
> On Thu, Feb 27, 2020 at 10:11 PM John Scudder <jgs=
> 40juniper.net@dmarc.ietf.org> wrote:
>
> I have an additional observation, or question, about Dan’s scenario...
> Almost all communication is bidirectional. Presumably this means a router
> that’s the tail end of an SRv6 path in one direction is the head end in the
> other. Doesn’t a head end need to add an SRH? If I’ve gotten that right,
> then we can extend Ron’s list with one more item. That is, apparently the
> ultimate segment endpoint:
>
>
> • Can process a SID, received as an IPv6 DA, on the fast path
>
> • Cannot process an SRH on receipt, even if Segments Left equal 0, on the
> fast path.
>
> • Can add an SRH on transmission, on the fast path
>
>
>
> Even though strictly speaking the second and third bullet points aren’t
> mutually exclusive, it’s a little difficult to imagine a real router that
> would have both these properties simultaneously. Perhaps I’m not being
> creative enough in imagining deployment scenarios? Since this scenario is
> claimed as an important reason this problematic feature is needed, it would
> be great if someone who understands it would elucidate, thanks.
>
>
>
> One further point, Ron says “I wonder whether it is a good idea to stretch
> the IPv6 standard to accommodate IPv6-challenged devices.” I also wonder
> this, especially because these devices will have a relatively limited
> lifetime in the network.[*] I don’t find the cost/benefit attractive of
> making a permanent detrimental change to the IPv6 architecture to
> accommodate a temporary deployment issue.
>
>
>
> Regards,
>
>
>
> —John
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WHQ0NUhAjwHVsM4IaKk9Y18cX6e8a4CIRz74xNQrYqdWDNahVJLVKyhuirvllWKo$>
> --------------------------------------------------------------------
>
>
>
> Juniper Business Use Only
>
>