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

Suresh Krishnan <suresh.krishnan@gmail.com> Mon, 26 September 2022 03:16 UTC

Return-Path: <suresh.krishnan@gmail.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 8BCF2C14F692; Sun, 25 Sep 2022 20:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5dYm9-Imo0Ou; Sun, 25 Sep 2022 20:16:33 -0700 (PDT)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 AFF13C14CE30; Sun, 25 Sep 2022 20:16:32 -0700 (PDT)
Received: by mail-qk1-x72e.google.com with SMTP id i3so3417490qkl.3; Sun, 25 Sep 2022 20:16:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date; bh=g7M9gutD9HwJfNHxJ0ZgBvgyTOb3ZPWB97MQ2NXfU4o=; b=VSPY6UshclGk5lnSP2GZ+93OuBNsfWHRDAQn5XqC7HGmh6Y9oytoAk8pY4jUDOwxWj 82litS1315bdsDc/86xUnHmC6FBvBwdhbl/YQ6D9F0bnu0y+X+zM5TCZZSEOImeiQ91k YRz3aHDiAw/51rssUajhsdnI6TT+fQCh6b6063rmodcrNfEbVZgTX1eHyvCZt/2PI8EV vlXTiXcpBcirvSli4wU95wsCKKkTxj0zdQRESiHH6PgoOTNTimReAGI4PT146rRODv1P voQHCmzBzhuVefPTSFjvWRQsOlZGFZC6D1/MFFZZBGUNzrqNOr+k/AGlfF2qy5nkwdIA r3WQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=g7M9gutD9HwJfNHxJ0ZgBvgyTOb3ZPWB97MQ2NXfU4o=; b=MJVt47Kaxvri1J8H/rLjqpFS/sN1OfLr6asQniaWQQTxOWjkKC3xwbIwwKPRNsrVX5 IT2k0zAIpvXbZoVVijcXbfS+uPvxd138tbu2VRZyRabWOazA6W9sg5qLo8CSEQiUsb6f 3WXdgU7SdmE6SiqsdWaY4xrZ6hBfbEYCz8i5jRNR9CO+N2IjDEuwkgCp0RC6w2YY5ie9 fsA09D/8GIbrtMlg3V7jBFPNdusp6OV4EJvFU6nzYTbP9MHCm+luNLrG4nN/tXo/0Vuf E4DZP0IXoUocLy66W74/eUvnVfNsCGC2dU/bXZTlBkIa2Lv6s7Qh25KYhuy46JEzRLDO C6QA==
X-Gm-Message-State: ACrzQf0Xl12HVV55u0nrGuLCRTEIoGnwED9EuauWL0Q/QK+wV0Fo2XH0 EE9IBLRm403puo+0ej8KEMA=
X-Google-Smtp-Source: AMsMyM6r8sQPOQlkwCqLRyiwr0M2PLEOpKx/wrY2b/GbT1aVFk4y5ThpOkDdF+hVq94tbUIJQX5q+A==
X-Received: by 2002:a05:620a:2785:b0:6ce:7dc2:2b2 with SMTP id g5-20020a05620a278500b006ce7dc202b2mr12896749qkp.395.1664162191562; Sun, 25 Sep 2022 20:16:31 -0700 (PDT)
Received: from smtpclient.apple (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id x17-20020a05620a449100b006b9264191b5sm10964092qkp.32.2022.09.25.20.16.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Sep 2022 20:16:29 -0700 (PDT)
From: Suresh Krishnan <suresh.krishnan@gmail.com>
Message-Id: <0CF331CA-B40D-49D5-BD01-5CE7C0D42040@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3C12FF22-1D56-44EA-99BF-FD2682212B95"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Date: Sun, 25 Sep 2022 23:16:28 -0400
In-Reply-To: <06eb01d8d038$f0ee3a80$d2caaf80$@olddog.co.uk>
Cc: Jen Linkova <furry13@gmail.com>, 6man <ipv6@ietf.org>, spring@ietf.org, 6man Chairs <6man-chairs@ietf.org>, draft-ietf-6man-sids.authors@ietf.org, spring-chairs@ietf.org
To: Adrian Farrel <adrian@olddog.co.uk>
References: <CAFU7BARixwPZTrNQOuEw3WP-FqUsVwTj7btMTahcMbXm_NqWGw@mail.gmail.com> <129a313a-d625-dae7-36f6-8541a8aea862@gmail.com> <06eb01d8d038$f0ee3a80$d2caaf80$@olddog.co.uk>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/11xuy8pFxkgCklOw07_WMiKF-WY>
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: Mon, 26 Sep 2022 03:16:38 -0000

Hi Adrian,
  Thanks for your comments. Greatly appreciate your detailed review. Please find responses inline.

> On Sep 24, 2022, at 1:13 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> 
> Hi Jen, all,
> 
> I've done a review of this document as part of working group last call.
> I found quite a few nits and so on, so I think the document needs some
> more work before escaping from the working group and being present for
> publication.
> 
> Cheers,
> Adrian
> 
> ======
> 
> I find it odd that this is an Informational document but its use of
> BCP14 language appears to constrain and direct implementations. So
> either you need to drop down to normal lowercase usage, or change the
> document to Standards Track.
> 
> There is only one use (a MUST in Section 3) that could easily be
> resolved.

I have a text resolution that removes this as a response to one of your other points below.

> 
> ---
> 
> Section headers need to be in header case

OK.

> 
> ---
> 
> You seem to freely interchange "Segment List" and "SID list". It would
> help to pick a term and stick with it since the change suggests there
> is a difference in meaning. If you are happy that they are the same, you
> could:
> - fix the text to use one term consistently
> - mention that the terms are equivalent in Section 2

The SID list terminology is something that is used in the spring compression design team document (draft-ietf-spring-compression-analysis) and I had to use it to refer to the document. I think we should stick with Segment list.

> 
> ---
> 
> Please select "Destination Address" or "destination address field" or
> "Destination address field" or "Destination address" and use it 
> consistently.

OK.

> 
> ---
> 
> Abstract
> 
> No citations in the Abstract
> 
> This document "intends"? Probably just state that it does.

OK.

> 
> ---
> 
> Section 3
> 
>   From this it
>   follows that all the SIDs that appear in the SRH are not SRv6 SIDs as
>   defined by [RFC8402].
> 
> I'm hoping you didn't intend what is written (because that would pretty
> much mean that SRv6 is dead!). Perhaps...
> 
>   From this it
>   follows that not all the SIDs that appear in the SRH are SRv6 SIDs as
>   defined by [RFC8402].
> 
> Maybe, it is also better to keep the context of the Segment List which 
> is how you introduced these SIDs. Something like...
> 
>   From this it
>   follows that not all the SIDs that appear in the SRH Segment List are
>   SRv6 SIDs as defined by [RFC8402].

The previous sentence 

<Some of these elements may represent a local interface as described
in Section 4.3 of [RFC8754] as "A FIB entry that represents a local
interface, not locally instantiated as an SRv6 SID”>

sets the context for the sentence you quoted. I think your second suggestion sounds great and will remove any possibility that this sentence could be misread.


> 
> ---
> 
> 3.
> 
> "It is also fairly clear"
> Well, that is illuminating :-)
> Perhaps you want to make statements about the SID elements and not about
> the clarity of the referenced documents?

Sure :-). Suggest 

OLD:
   It is also fairly clear that the non-SRv6-SID elements that appear in
   the SRH SID list are simply IPv6 addresses assigned to local
   interfaces annd MUST conform to [RFC4291].

NEW:
   As stated above, the non-SRv6-SID elements that appear in
   the SRH SID list are simply IPv6 addresses assigned to local
   interfaces and they need to conform to [RFC4291].

> 
> ---
> 
> 3.
> 
> s/annd/and/

Ack.

> 
> ---
> 
> 3.
> 
>   the following
>   discussions are intended to be applicable
> 
> Maybe s/are intended to be/are/

OK.

> 
> ---
> 
> 3.
> 
>   Section 3.1. of [RFC8986] describes the format of an SRv6 SID as
>   composed of three parts LOC:FUNCT:ARG, where a locator (LOC) is
>   encoded in the L most significant bits of the SID, followed by F bits
>   of function (FUNCT) and A bits of arguments (ARG). 
> 
> Would it be helpful to qualify L+F+A = 128 in all cases?

Actually not. RFC8986 defines L+F+A <=128 instead and this would be inconsistent with that. 

> 
> ---
> 
> 3.
> 
>   When an SRv6 SID occurs in the IPv6 destination address field of an
>   IPv6 header, only the longest match prefix corresponding to the
>   locator is used to forward the packet to the node identified by the
>   Locator.
> 
> Possibly you mean s/is used/should be used/
> Or maybe s/used/used by an SRv6-capable node/

This is written as a statement about what happens today rather than specifying behavior for the node to follow.

> 
> ---
> 
> 3.
> 
>   While looking at the transit nodes it becomes apparent that these
>   addresses are used purely for routing and not for packet delivery to
>   end hosts.
> 
> The distinction between "end host" and "destination" is a fine one. When
> you are a transit node, you can't tell the difference. When the DA
> identifies the end of a segment, it is (from a network point of view)
> exactly like identifying an end host.
> 
> Maybe, in fact, you mean "packet delivery at end hosts" (at not to). 
> 
> I think you should also be careful with the term "routing" as well. 4129
> is pretty careful about not using it (except in the Anycast section), 
> but says "forwarding" instead. 7608 also prefers the term "forwarding".

Good point. I think sticking with the use of the term “forwarding” as in RFC7608 makes sense.

> 
> ---
> 
> 3.
> 
>   Hence the relevant standard to apply here is [RFC7608]
>   that allows the use of variable length prefixes in forwarding
> 
> I think 7608 is not a standard. Maybe say specification?
> But also, I don't think that 7608, as a BCP, "allows" anything.

Suggest changing this to

Hence the relevant specification to apply here is [RFC7608]
that requires implementations to support the use of variable 
length prefixes in forwarding.

Does that work?

> 
> ---
> 
> 4.
> 
>   The C-SID document [I-D.filsfilscheng-spring-srv6-srh-compression]
> 
> I don't think you can say "The C-SID document" because, well, definite
> articles are a bit limiting. Anyway, that draft was replaced by
> draft-ietf-spring-srv6-srh-compression a while ago.
> 
> Why don't you turn this around as...
> 
>   [I-D.ietf-spring-srv6-srh-compression] introduces an SRH encoding for
>   compressed segment lists (C-SIDs), describes how to use a single
>   entry in the SRH list as a container for multiple SIDs, and defines a
>   ways to do so.

OK.

> 
> ---
> 
> 4.
> 
>   A node
>   taking part in this mechanism accomplishes this by using the ARG part
>   [RFC8986] of the Destination address field of the IPv6 header to come
>   up with a new Destination address in some of these flavors.
> 
> "to come up with" and "flavors" are a bit colloquial. Maybe say 
> "derive" and "mechanisms".

Ack on the “derive” part, but “flavor” is a specific term used in [I-D.ietf-spring-srv6-srh-compression]

> 
> ---
> 
> 4.
> 
> s/i.e. The/I.e., the/
> s/note in here/note here/
> 
> ---
> 
> 4.
> 
>   One key thing to note in here is that the Locator Block at the
> 
> This is the first time you have used "Locator Block". Is this "LOC" as
> previously described?
> 
> ---
> 
> 4.1.
> 
>   There are a few issues that need to be addressed in the C-SID draft
>   prior to its publication as RFC:
> 
> Erm, no! You can't have an RFC that chats about the current state of
> another draft, or that claims it is going to be published as an RFC.
> 
> Perhaps the best solution is to compress sections 4, 4.1, and 4.2 into
> a very short note that "Many approaches to SID list compression have
> been proposed. It is important that any solution preserves the
> properties of the LOC as described in Section 3."

This text was added as requested by one of the spring chairs to specify that the spring document needs to address these issues. It would be great if the 6man/spring chairs and ADs can chime in on this topic.

> 
> ---
> 
> 5.
> 
>   All of the SRv6 related specifications discussed above are intended
>   to be applicable to a contained SR Domain or between collaborating SR
>   Domains.  Hence the behavior of SRv6 SIDs is visible purely within
>   the SR domain and they would be treated solely as IPv6 routing
>   prefixes by nodes that are not SR aware.
> 
> What is meant by a behavior being visible?

Any special behavior associated with SRv6 SIDs are not known or acted upon by non-SR-aware nodes and these nodes use them for forwarding based on the prefix as described in RFC7608.

> 
> I know that the permeability of SR domain boundaries is something that
> really worries at least one of the current ADs, and it might be good to
> spend some time discussing what happens when things go wrong and a 
> packet with a SID in the DA field escapes from the domain (this is
> distinct from the behavior of a non-SR node within the domain).

Yes. I certainly do understand that concern and one of the tools in reducing the permeability is moving this traffic to a well known filterable prefix at the borders of the domains depending on the stance of the domain. 

> 
> ---
> 
> 5.
> 
>   As an added factor of safety, it might be prudent to allocate some
> 
> "It might be prudent"? Are you asking to allocate this address space or
> not?

Yes. Certainly asking to allocate a prefix as per Section 6. Suggest 

s/might be/is/

> 
>   address space that explicitly signals that the addresses within that
>   space are not intended to comply with [RFC4291].  As described in
> 
> "are not intended to comply" means "do not comply"?

No. It simply means that compliance to RFC4291 cannot be expected. Are you looking for stronger text for requiring non-compliance?

> 
>   Section 3 above, there is precedent for mechanisms that use IPv6
>   addresses in a manner different from that specified in [RFC4291].
>   This would be useful in identifying and potentially filtering packets
>   at the edges of the SR Domains as described in Section 4.1.
> 
>   The SRv6 operational community, which is the first intended user of
>   this block, is requested to come up with conventions and guidelines
>   for the use of this newly allocated address block in line with their
>   requirements.
> 
> This sounds like you are:
> - not proposing any specific use
> - allocating the address space on the off-chance that someone might 
>  find a use for it
> - not suggesting that deployments (or implementations) actually change
>  their current behavior

How are you arriving at this conclusion. Spring is working on draft-ietf-spring-srv6-srh-compression-02. What address space do you think it can be deployed in? Here are some of the potential options

a) RIR allocations
b) ULA space
c) Something else* (this allocation)

I think all of these options have pros and cons and what you think of this prefix allocation might depend on what properties you desire. 

> 
> ---
> 
> 6. 
> 
> Obviously, there are many ranges in the registry marked as "Reserved
> by IETF" and IANA will need help selecting one. 
> 
> Also, since this registry is "IESG Approval" it would be timely to
> approach the IESG and determine whether they are likely to say "yes" or
> will need further changes to the document. Those changes should happen
> while the document is still in the working group.

Hmm. Isn’t that what the IESG review process is for? Or are you suggesting an early allocation request prior to advancing the draft so that the IESG can decide if a temporary allocation is worthwhile? If it is neither, can you elaborate on your proposed procedure.

> 
> ---
> 
> I'm surprised that section 7 doesn't point back to the "additional 
> safety" described in section 5. In particular, not using that safety
> would appear to be a risk.

I can certainly duplicate some of the text from section 5 if the WG would find it useful.

Thanks
Suresh