IETF Logo Mail Archive

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

Nick Buraglio <buraglio@es.net> Fri, 07 October 2022 11:20 UTC

Return-Path: <buraglio@es.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 B83C9C14CF09 for <spring@ietfa.amsl.com>; Fri, 7 Oct 2022 04:20:29 -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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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 (2048-bit key) header.d=es.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 mtgwIUH3SUdB for <spring@ietfa.amsl.com>; Fri, 7 Oct 2022 04:20:26 -0700 (PDT)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 19C79C14F733 for <spring@ietf.org>; Fri, 7 Oct 2022 04:20:26 -0700 (PDT)
Received: by mail-ej1-x62a.google.com with SMTP id bj12so10520875ejb.13 for <spring@ietf.org>; Fri, 07 Oct 2022 04:20:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=es.net; s=esnet-google; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=x9LboWO32ubdsfdf4QcF4uNG995eSVUrXOlaQ5dDJTg=; b=KXWTAHWlOHIzytUpfCP3R0qAE7jsJxNeasuQ1m6cmyRDqYr2oceiiv3ttgyfdo4fLF dJDqN9Mux7yeMceeOpz9F7H6Q3RLaCiVps+0qq3HQ38wIvY+wWRj4yP5R+nCN28CCSt9 UObrS/sS/oi9QZ1kgckASP39qVGySnJXl4VdhrpqOF+eaBZQwWCa2IsAmG4yFN+17HLd fanXAA/c21ReXmaoSsbWDGhdAxU7rdMEZOa1zZqR8IDlX0UEPZHfBTvMr0teEvvJALST OKFHIMONvmt/QW7hko8GhhrjtmJ1H4riytFkMIKDt7rJqo5kAISAYOzF7wQc5tsyXklj d7ZQ==
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:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=x9LboWO32ubdsfdf4QcF4uNG995eSVUrXOlaQ5dDJTg=; b=EcAmNrJXXuZo3S9Zd2fopi/SK9DOG8g2S9bMdPa2WJujM6eGW06ZOaL5+0S5wkcAit 7Ju6t4JIpjPytQ2E15aVLbSYbFND4PZP9/omVKvXiX4yybnIy97MfltgZHRRLmkIk97z r96ivY9Yxx4VjkIPjAoUvGGi+jOtk6bIwwZvTeYM+vJZe9NPg54ZG8ZCfxcckjZRNOPO wvNWzDwZoW39JUrOI6rt6lTCGDi6lJxtrz1aKba099oIsQ/+DhYIEtDLiMvvbreOsvDa LMHf7aBif5LCU4BUTdls0aol1bU3hyRzoCNNQ2sndg0GmN5vShXsG8BP/ZOjF8hovrJz tNxQ==
X-Gm-Message-State: ACrzQf2v+tkMkh25NXCLf/L+XaS0bT8gtEaKufTsuKglW72QxG6SmPOV nMXFe7OF4refVD7LoSTIjFNn2EPOA7tn+TtEmQcc3mZVsjxgoIi24TRP+imDp9ZE7GT4/XszqjH PlhpXtmvXZ8w6Zdgx14gVXokrGKtExsvWFcDLflnNVTvYxvgfrEiY2K6iG6P3iliXZHGEvOslny ZI8A==
X-Google-Smtp-Source: AMsMyM62TddzFYTQvPm+g1XdsfsnqAWzvsFke+oWNEQ70hetdVtPZoey2cBCqL1LV4gquwEBQycSQ5POmyCBM7T4SrA=
X-Received: by 2002:a17:907:5c2:b0:77e:def7:65d8 with SMTP id wg2-20020a17090705c200b0077edef765d8mr3660591ejb.487.1665141623785; Fri, 07 Oct 2022 04:20:23 -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>
In-Reply-To: <bdd7bf12-f712-3fe5-2698-9272c16ddded@joelhalpern.com>
Reply-To: buraglio@es.net
From: Nick Buraglio <buraglio@es.net>
Date: Fri, 07 Oct 2022 06:20:12 -0500
Message-ID: <CAM5+tA9cAybjVHFTDEAWLLq7FcKhTGzTuBDbFyfv19ARVyXEoA@mail.gmail.com>
To: Joel Halpern <jmh@joelhalpern.com>
Cc: 6man <ipv6@ietf.org>, SPRING WG List <spring@ietf.org>, Suresh Krishnan <suresh.krishnan@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000fcb82605ea6ffe55"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/cdB8XJYGn3OTBfTamN7ymhV653k>
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: Fri, 07 Oct 2022 11:20:29 -0000

On Thu, Oct 6, 2022 at 10:15 PM Joel Halpern <jmh@joelhalpern.com> wrote:

> I wonder if we could / should add a sentence or two related to the address
> block noting that if an operator chooses to use other address blocks for
> the SRv6 SIDs then they need to be extra careful about configuring their
> edge filters to prevent leaks inwards or outwards?
>

This is a large concern I have heard within the operational community and I
believe it should be noted as a best operational practice.

> Yours,
>
> Joel
> On 10/6/2022 10:34 PM, Suresh Krishnan wrote:
>
> Hi Dhruv,
>
> On Oct 5, 2022, at 12:27 AM, Dhruv Dhody <dhruv.ietf@gmail.com> wrote:
>
> Hi Suresh,
>
> Thanks for taking the comments into consideration. Snip to just two
> points...
>
>
>
>> - Do we need to add some text on what happens if the address block
>> assigned by IANA is not used in the received IPv6 packet?
>>
>> Dhruv: Any thoughts on this?
>
>
> This block is not mandatory to use. The packet will be processed as any
> other IPv6 packet would. Is there something specific you are worried about?
>
>
>
>> - This text "This would be useful in identifying and potentially
>> filtering packets at the edges of the SR Domains as described in Section
>> 4.1.". But section 4.1 of this I-D does not have any text for this! Do
>> you mean some other document?
>>
>>
>> This is in reference to the following text in 4.1
>> " In this case, to allow the SR domain to fail closed, some form of
>> filtering based on the LOC part of the SRv6 SID is required as relying
>> purely on the presence of an SRH will not be sufficient.”
>>
>> Please let me know if I can clarify this further.
>>
>>
> Dhruv: I got confused because section 4.1 is meant to be only about C-SID.
> My suggestion would be to avoid the reference and just put the relevant
> sentence there for emphasis and clarity.
>
>
> Sounds good. Will do.
>
> Thanks
> Suresh
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 
----
nb

v2.23.0 | Report a Bug | By Email