Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

Robert Raszuk <robert@raszuk.net> Sat, 08 October 2022 18:51 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 8F423C14CF05 for <spring@ietfa.amsl.com>; Sat, 8 Oct 2022 11:51:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xvnf02RE-VeF for <spring@ietfa.amsl.com>; Sat, 8 Oct 2022 11:51:53 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597BCC14CE25 for <spring@ietf.org>; Sat, 8 Oct 2022 11:51:47 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id n12so11561922wrp.10 for <spring@ietf.org>; Sat, 08 Oct 2022 11:51:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GoVEo/oFIrFIHAfX5ALCqzwcUArmKJhlMUOWfaWHJQE=; b=Q29W6EO4taiU4B4iqzRxSYee9ZnAPNrWleLFq64JsYjLLdxziqeSgQaZK10E7jhR/V viQtLHLjkua5hvFsaeUUd0NQNJafcVAYrUGk00/Wjd0JrcIDxGEgPHYhwCQNOWG4noyv umZ/JdIgDZw1qAO+oL5JnfLJZMI7QcuL7QmX3bBtOIwI+fonYkzIo74kJZa7rAhJqGMn IH56Y392cxPe+6AVlN2y2CisvXblLIe+XjOHFccKQHQQYMdlMgZpkJSYEybYWe62Gz0y Zig6z0j/NWjxCdbqw14YJp1Spi/lqPPLeGH7CPXiz7h5CQStKWfo70+zeb47qMsQVm3l O08Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GoVEo/oFIrFIHAfX5ALCqzwcUArmKJhlMUOWfaWHJQE=; b=m/uuFBSr15WEWpPvPFmjkBBQNNIBu6ivREfft0U7EcLSLdmztonQ+Jr2HxeBJoX8FZ Zg7cwy/fVgvIAs3yWY+7J5ZNrLodz++YvGS5Mv7gd12/h5nHaVpR0AbhqNXmollG0vFF sGqq6+LE7lr0Q2iizsOY6h3Q7lZavEKM6tVJFn6/q1WItyRDXoX+pTrUjkYPYuEmSMg8 UMnVavcZSNsCzKoEdATnWS97yCj4uUF19pXqxwSa3JFIBbjvPLD5GeFpodQfZvm8e6mp S9qJUS6L9dyOg5b8Ynsk4wkhN5rqq6NWCZxlFjrN/b7jFklUTN+g3gTKaQuQnNU2Pu/G at9Q==
X-Gm-Message-State: ACrzQf1rChAW+SNh1i5873pTNdd7BcdU92QXxLXIDCdbN4kXBhbzIWLe sC0QH3Mo5oIBen8vkCtv7gu7T2qQyZxS6pt7CreH5Q==
X-Google-Smtp-Source: AMsMyM5iJXDjXGhgaNqOF4Eyn0O4ppa5oO06zXw4HRSGC6ciZf01pnekObllxaxZKuFZCqIrsIMe3oO48+By0nZWB9w=
X-Received: by 2002:a5d:4c8c:0:b0:22e:d81b:67cf with SMTP id z12-20020a5d4c8c000000b0022ed81b67cfmr5017284wrs.69.1665255105636; Sat, 08 Oct 2022 11:51:45 -0700 (PDT)
MIME-Version: 1.0
References: <CAFU7BARixwPZTrNQOuEw3WP-FqUsVwTj7btMTahcMbXm_NqWGw@mail.gmail.com> <CAB75xn4+N31=ggO03AAQJANv7RgHaC1eNGXRUQ9B20rLK+nJyg@mail.gmail.com> <E77D8982-11E9-45F9-81BF-3CA1E1F6B745@gmail.com> <CAB75xn4Zme4KOjPuY1_-4jCKTk1jshbq8X645zXhYQLiKB+N9g@mail.gmail.com> <54A38015-95AD-41F0-8E9D-76B3E62AA55B@gmail.com> <bdd7bf12-f712-3fe5-2698-9272c16ddded@joelhalpern.com> <58E77509-A1A1-4CE8-9EE4-22BEEEA8B62E@gmail.com> <98a941e4-0fff-ced1-d4ca-4406368eac31@joelhalpern.com> <4DC495DF-AD6B-4D60-80C4-B836DD365A0C@gmail.com> <CAOj+MMEx7+jWN1yC=81dMwo5GmqbhyHqOZr9W2_qzN9BNjs+Zw@mail.gmail.com> <ab55e9c0-60b9-2986-07f1-38c28852009e@joelhalpern.com>
In-Reply-To: <ab55e9c0-60b9-2986-07f1-38c28852009e@joelhalpern.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 08 Oct 2022 20:52:24 +0200
Message-ID: <CAOj+MMEn6Dz-Rz0PRRvR8VXT8idAQm+rLuouWJoNz-dA+kRkJQ@mail.gmail.com>
To: Joel Halpern <jmh@joelhalpern.com>
Cc: Suresh Krishnan <suresh.krishnan@gmail.com>, 6man <ipv6@ietf.org>, SPRING WG List <spring@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000008438205ea8a6be4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/oXld5-Aq81H8R-mDgJKIckJ6AlE>
Subject: Re: [spring] 6MAN WGLC: draft-ietf-6man-sids
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 08 Oct 2022 18:51:57 -0000

Hi Joel,

I was hoping this is apparent so let me restate that I do not buy into
"limited domain" business for SRv6.

I have N sites connected over v6 Internet. I want to send IPv6 packets
between my "distributed globally limited domain" without yet one more
encap.

If there is any spec which mandates that someone will drop my IPv6 packets
only because they contain SRH in the IPv6 header I consider this an evil
and unjustified action.

Kind regards,
Robert

On Sat, Oct 8, 2022 at 7:40 PM Joel Halpern <jmh@joelhalpern.com> wrote:

> Robert, I am having trouble understanding your email.
>
> 1) A Domain would only filter the allocated SIDs plus what it chooses to
> use for SRv6.
>
> 2) Whatever it a domain filters should be irrelevant to any other domain,
> since by definition SRv6 is for use only within a limited domain.  So as
> far as I can see there is no way a domain can apply incorrect filtering.
>
> Yours,
>
> Joel
> On 10/8/2022 3:16 AM, Robert Raszuk wrote:
>
> Hi Suresh,
>
> NEW:
>> In case the deployments do not use this allocated prefix additional care
>> needs to be exercised at network ingress and egress points so that SRv6
>> packets do not leak out of SR domains and they do not accidentally enter SR
>> unaware domains.
>>
>
> IMO this is too broad. I would say that such ingress filtering
> could/should happen only if dst or locator is within locally
> configured/allocated prefixes. Otherwise it is pure IPv6 transit and I see
> no harm not to allow it.
>
>
>> Similarly as stated in Section 5.1 of RFC8754 packets entering an SR
>> domain from the outside need to be configured to filter out the selected
>> prefix if it is different from the prefix allocated here.
>>
>
> Again the way I read it this kills pure IPv6 transit for SRv6 packets. Why
> ?
>
> (Well I know the answer to "why" from our endless discussions about SRv6
> itself and network programming however I still see no need to mandate in
> any spec to treat SRv6 packets as unwanted/forbidden for pure IPv6 transit.)
>
> Thx,
> R.
>
>