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

Joel Halpern <jmh@joelhalpern.com> Sat, 08 October 2022 19:11 UTC

Return-Path: <jmh@joelhalpern.com>
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 133D5C14F728; Sat, 8 Oct 2022 12:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 wp5xEGjOOSQz; Sat, 8 Oct 2022 12:11:14 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 2F957C14F724; Sat, 8 Oct 2022 12:11:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4MlFC55xZbz1pNGk; Sat, 8 Oct 2022 12:11:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1665256273; bh=TndpbgMsWSweYs0aPGl72S2ZUxkYSeC9IFoC8SFKwIc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=cOuNRtwEHrB7SYJGVuehMD0ZUtXD/W9Hm1lN6yGpeHn1oZ/VVx64OKt2I5VXRv8ja FgGBRmS84NebsvoZqTYHK5H3r4Au2o3wHiNe7LA3UHzy7n5QRbNtUA0vimztq2koIY 8c9FyKzC1gJAIDFFzI/Ukee5nCi8SeKX6YDU7ecw=
X-Quarantine-ID: <SHNbFw5bExrx>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.23.73] (unknown [50.233.136.230]) (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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4MlFC51ZPfz1pHXG; Sat, 8 Oct 2022 12:11:13 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------hjs00bolAF0gE0N8WDvBR6bD"
Message-ID: <03a6afb0-33bf-2280-99c7-7f8f28878f57@joelhalpern.com>
Date: Sat, 08 Oct 2022 15:11:12 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1
Content-Language: en-US
To: Robert Raszuk <robert@raszuk.net>
Cc: 6man <ipv6@ietf.org>, SPRING WG List <spring@ietf.org>
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> <CAOj+MMEn6Dz-Rz0PRRvR8VXT8idAQm+rLuouWJoNz-dA+kRkJQ@mail.gmail.com>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <CAOj+MMEn6Dz-Rz0PRRvR8VXT8idAQm+rLuouWJoNz-dA+kRkJQ@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/2evI-xmLK9tiK_nmJXvy0dEFl4A>
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 19:11:18 -0000

Robert, whether you "buy into limited domain" or not, it is in the RFC 
and was part of what the IESG considered when they approved it.  As 
such, unless you believe you can change the community consensus our 
specifications need to conform to that.

Yours,

Joel

On 10/8/2022 2:52 PM, Robert Raszuk wrote:
> 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.
>