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: 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 6E4901200C4 for <spring@ietfa.amsl.com>; Thu, 19 Sep 2019 02:34:23 -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=unavailable 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 3HVEK8Gl6HMk for <spring@ietfa.amsl.com>; Thu, 19 Sep 2019 02:34:21 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 C04ED1208FE for <spring@ietf.org>; Thu, 19 Sep 2019 02:34:20 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id f16so2626830qkl.9 for <spring@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=I+Fq3ZzZtn18oa6bsiL48ppRP3uwLbmt0WKmfpts85wLcCNKAYILsen1qQWN7Fg/RY kLw9LwcRUAr2ATRT4oWF7YARGFRnKk/ILPEEceCCb+cEvg5/OmwQA3YOSI5oGlU5KWgU 2DuJS6TUjYlnV6VrpOZPk7yeZS249KYOF89ItvqqVhDb8DCz2J9bfF9lvjP2SSpd0MJh J8/y8Q07+mQzERIxnn+9A88mrHoyfewc4OX034yzE2KnxEwxntIbmfwRpcjp878/3FMC h7fG4o26qSQ93lzF+/9EC0INPCRDH41G0KqkK/pHCPaVoas9Q2vfbhRjUCymAhtnJfDa f66Q==
X-Gm-Message-State: APjAAAW6NyBrR33s9aJH/dZ8z+ao3xgOzPppkfh+jnZ+VWikw8Ih/rh9 Wzi83Oco5uF6GANeVISZbckEbieXNOIXKQuvR14ugg==
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>
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/spring/GQZLWMwZIYyZ5g0mZKTqGnJ3QAg>
Subject: Re: [spring] “SRV6+” complexity in forwarding
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, 19 Sep 2019 09:34:24 -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