IETF Logo Mail Archive

Re: [spring] “SRV6+” complexity in forwarding

Robert Raszuk <robert@raszuk.net> Thu, 19 September 2019 09:34 UTC

Return-Path: <robert@raszuk.net>
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 B6789120900 for <ipv6@ietfa.amsl.com>; Thu, 19 Sep 2019 02:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 4tGPVqYLqKGX for <ipv6@ietfa.amsl.com>; Thu, 19 Sep 2019 02:34:20 -0700 (PDT)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 A5F531200C4 for <6man@ietf.org>; Thu, 19 Sep 2019 02:34:20 -0700 (PDT)
Received: by mail-qk1-x733.google.com with SMTP id y144so2638869qkb.7 for <6man@ietf.org>; Thu, 19 Sep 2019 02:34:20 -0700 (PDT)
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=+EIisj2R7xEb9oXLEaXaGNah9+zBclCnq4zavlyQ7Gs=; b=bduTcedwbamHPEoQlJQYyrTOjaNCCrnToKG5Z2sVPtRhbZfJyIIuBv3YFBuMX33RtF TaL14OvgQreCzIz8HhRefDEWDejTPstAVMB7qADr9ilbFptTKfG8t0gFXL0STqfR3iIv RXJGfU0q6uKbZJ1fGftqJ80B0Zmxz7YUuVa8l5KO/QPeaI5n5UvShIKa0xt8//5b1/aJ q51IF8gShLQofwAk6excGKvW81UVHabtTXDRbJAgZ5GFOrDqSaU9L5TvResAZAvhbZEj 2Md178io8vmTWjBq/MYCu3dDma+ohpXF3DokZ11zO5kMsmywRa9CvV3XRARDihDWfDRp eK0g==
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=+EIisj2R7xEb9oXLEaXaGNah9+zBclCnq4zavlyQ7Gs=; b=ThlCSpSre+DEfghf0MiV89o+rzjaz9THCh8EfYbd4uhhcgZjbXoQI/lHVnjiE9a8AI u4e7lHdXCIDopyoBIP8JnZbr3SyCywltP9yu2DNGmhjQRIctF3KSr1OcxQ5FxfwaGdYV 1K91GQP5osCmS+ybFn3hS6R38VjDnMEXpJBnUcTGwMvGUvPlkEWClS5+kPsEKYsK1gIH T8bYJCDqv/qwvZokJ9dqgoaqXx+d4z6sTff6a2Rz947mwLwUUssHCMTDUtVIUb+cZaTC Tpjyn5S8ukWIfzsxUW6lCAyP+jjQt1Yqa/MbIPkXW5R1aSiXf2EYOhmyhXKJvvxaIowJ TDPQ==
X-Gm-Message-State: APjAAAXvDT21dgWP9jSXfu/E3dDp8qEQCF1Hj5pvX9w2Df2BoiEXNll5 J5M3i4jRx+PuMmse5Yokv2bOsNP6EesvJ+YnTR+41A==
X-Google-Smtp-Source: APXvYqwu7Mj5sW7pKykzp8CDu2IFD9OukyWmC5oIqX2Z0YuHvplseZJnfzs0kpfytp/SJbKRkoQpgCyY0wU38qv7W/8=
X-Received: by 2002:a37:6144:: with SMTP id v65mr1806975qkb.465.1568885659606; Thu, 19 Sep 2019 02:34:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAHd-QWtA21+2Sm616Fnw0D-eB7SNb_BeG8-A-MCLLFgTwSpOsg@mail.gmail.com> <BYAPR05MB54632F09C712ADB30138CFA9AEBE0@BYAPR05MB5463.namprd05.prod.outlook.com> <BYAPR19MB3415D21403394F8129A4BAD8FCB90@BYAPR19MB3415.namprd19.prod.outlook.com> <30491F13-C652-45C3-AB2B-95F765FBB4EA@juniper.net> <65C5CB04-3A2F-4F83-A7C8-2045154F93AE@cisco.com> <BYAPR05MB5463EC3250F2A303A3641839AEBA0@BYAPR05MB5463.namprd05.prod.outlook.com> <91CBADAD-EFE6-46E1-A9D3-DAA111357179@juniper.net> <CAOj+MMGyUFRPDqCBo5SbLX486o_9GLpM6Zxf8KSt1voWiqhkGQ@mail.gmail.com> <E8D473B5-3E8D-4339-9A79-0CAE30750A55@juniper.net> <CAOj+MMFOy5PyTo=jPJkVrQOctdWjsTbD=7ix-2n89vodKzT3gQ@mail.gmail.com> <2F604D74-51CF-4F2F-AEA9-1CBDEEA9B9F7@gmail.com> <F09C2D09-D769-4817-AF73-97D6ED1BC4BF@lapishills.com> <201909120857387140042@chinatelecom.cn> <1568259664564.62561@bell.ca> <CAO42Z2wQ_8GEE+=nAMFBj+ape9Vf7fARVoOwGdCiUxdffkyXgw@mail.gmail.com> <BYAPR05MB5463A04B05B4BD6AA294F7F0AEB00@BYAPR05MB5463.namprd05.prod.outlook.com> <6EA6F7C0-BEB2-4749-A6AB-62B1337213B2@cisco.com> <BYAPR05MB5463426F1668202EE5F183EFAE8F0@BYAPR05MB5463.namprd05.prod.outlook.com> <634900D2-FBCE-47CF-8907-C8B9CB3A4102@cisco.com> <CALx6S34=Tw-u4Hz-07-Rs-GjsungkqnD_fMoQnGc17u3VJhY1g@mail.gmail.com> <CAFqxzqYr7g2jzwJrhvjL_DXYZsDzbzqx01cy0zB1aBweDde1XQ@mail.gmail.com> <CAO42Z2yrjwRMykWxmEo5=18fMvuZdMtuyz5g1p=8oSzp_ro9Vw@mail.gmail.com> <52FDA21F-E860-45E2-846A-43B969DEDC87@juniper.net>
In-Reply-To: <52FDA21F-E860-45E2-846A-43B969DEDC87@juniper.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 19 Sep 2019 11:34:10 +0200
Message-ID: <CAOj+MMFjCcQt7FLf9NjfEKruEYktU0iJEs8Q+qFG8Pjkt7jDaA@mail.gmail.com>
Subject: Re: [spring] “SRV6+” complexity in forwarding
To: Ron Bonica <rbonica@juniper.net>
Cc: Mark Smith <markzzzsmith@gmail.com>, Dirk Steinberg <dirk@lapishills.com>, Tom Herbert <tom@herbertland.com>, Rob Shakir <robjs@google.com>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>, "Darren Dukes (ddukes)" <ddukes@cisco.com>, "xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn>, Tarek Saad <tsaad.net@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000006f38f60592e4a83d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jTuDRotIHK4JIJINIAsPmFti0FY>
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: Thu, 19 Sep 2019 09:34:23 -0000

Hi Ron,

If you want to push complexity to the edge, put it in a destination option
> that is processed at the edge.
>
> Ron
>

Just curious what is your definition of the "edge" ? If destination address
matches local address that is the "edge" for the packet. So each TE
midpoint is the "edge".

The only difference I observed is if you put something before or after RH
is how to handle it when that something is unknown to the node. Here as
each router can be an edge this unknown is not likely to occur.

There is no difference in how IPv6 processing of those DOH will attempt to
take place.

That is also why IMHO split of PSSI from PPSI is a bit wired as the only
reason for it seems to be to avoid dropping packets at mid points if PPSI
is unknown to it.

Thx,
R.

v2.23.0 | Report a Bug | By Email