From aretana.ietf@gmail.com Mon Mar 25 15:22:57 2024 Return-Path: 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 BA8BAC18DB85 for ; Mon, 25 Mar 2024 15:22: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, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=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 ABMAfdC6zpoh for ; Mon, 25 Mar 2024 15:22:57 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 F396AC180B7E for ; Mon, 25 Mar 2024 15:22:48 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-5d8b70b39efso3276288a12.0 for ; Mon, 25 Mar 2024 15:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711405368; x=1712010168; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=SJElz8q4WRqEdXmdO9+RasjsRFAdSBNUbbr2dkV/kXI=; b=bB4H4kQ0/q1v1kAyTFsPf8eQCSh2IGzENVs+5XlOU6yLTElmUApGLQFvONxvyAOZP5 fHPaDGeMIvCClJ496toXATLWNz/WhlOmBAgqZ3AZpLKyRe+PH12C0O4zzhSyZdaMKRC5 HyvAiYXyMpXVQ6/rGl/zrfTHG0DW0t+XN8FN9IiTzUf2GOkPXZ/e0jzpxkpHGaELeyRQ Ec6W/6S6Fmxp/NopcMwFVeONOqxJQ9lHe5kE632fHnt35c9JnnWvhT/Dbn6E9OQym9Rb PDmHFgH/YAjxh3gUGukWtwqECVTAlcNoTz3CDJktJW+5+YAQluDqAIgxvrZ+vyEd0OCG MoBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711405368; x=1712010168; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=SJElz8q4WRqEdXmdO9+RasjsRFAdSBNUbbr2dkV/kXI=; b=Ri8nKTnVPLYwtga7kLmZrs/N/sO6NvCfxyzQPLr7v4Scr9iumU/z3FvTJ5sLwljKw3 GO37jlGpaclwXkMzWJDCSC/x4hfn3YLBODmMaoyxxvLDBYFnWa72EMeu4ZL837GIP+53 qrZNTMy1aZs/yXzXdHmbPcI7P6/MzK7C84MVty/muatS184kVm9wUJBx16MMMmFaZTcX JlLxh/DlDPfqR+hfkkjsVVjF6LuCyQNgzGebea8G/ksjMnMSPW1/1XsVR7pMl5k5M28e Ofqjy4Xy8aUPgxKnRlK37Y2FzGIMe7q/Yv4iqxDM0jzcUUBqtJbqsglYiKD3w1AOYc1Q v7WA== X-Gm-Message-State: AOJu0Yzzw8da7xHPfUToui2depvO8vHmZA7eXppIBIoFeqBRytSnEw05 UZwFDtexxuEuEapnHFDX9sXFanVfXmMmmRsqnJfKhJ0l+uSGivNP+Rk7wZxwvXaQ9D+RZG33kNb zp0J8Z3nJc5bjPpHmfIxen67qA+q/AQ58 X-Google-Smtp-Source: AGHT+IG7eAy5eUWaIsoaujDPx0gNUCC368DHQxiG182PYgKzpzBNN5cJPagxR/QiQRKRVQyvBV0ZjILLqM2m2iieDsE= X-Received: by 2002:a05:6a20:50d4:b0:1a3:69e9:2fc4 with SMTP id m20-20020a056a2050d400b001a369e92fc4mr5405889pza.22.1711405367667; Mon, 25 Mar 2024 15:22:47 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 25 Mar 2024 15:22:46 -0700 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Mon, 25 Mar 2024 15:22:46 -0700 Message-ID: To: Francois Clad Cc: SPRING WG List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2024 22:22:57 -0000 On March 18, 2024 at 10:49:39=E2=80=AFAM, Francois Clad wrote: Francois: Hi! =C2=A0Thanks for the update! > Detailed replies inline. These include your follow-up comments as well as= the > review items that we missed in the first pass. > > Please let us know if you have any further feedback. I have some suggestions below, please consider them for the next revision. Thanks! Alvaro. ... > > I know that this document is not a deployment guide and that it cannot > > cover all cases. But the current guidance is basically non-existent > > given the large amount of choice. > > There are likely to various other considerations besides the C-SID length= s. > They may be a mix of technical and/or non-technical. Perhaps the SRv6 Ops > forum will produce some deployment and operational guidelines for the > technical aspects. It is not in the scope of this document to serve as a > deployment or design guide. At lease please include that ("There are likely to various other considerations besides the C-SID lengths. They may be a mix of technical and/or non-technical.") somewhere. I seem to be the only person asking for additional information, so I may be in the rough. =C2=A0However, I don't consider waiting for a future document a good solution. Let's move on. ... > > > > 1094 The segment list that the SR source node pushes onto the packe= t MUST > > > > 1095 comply with the rules in Section 6.3 and Section 6.4 and resul= t in a > > > > 1096 path equivalent to the original segment list. > > > > > > > > [major] "MUST...result in a path equivalent to the original segment > > > > list" > > > > > > > > How is a "path equivalent to the original" defined? The next > > > > paragraph mentions "a compressed segment list of equal or shorter > > > > length than the uncompressed segment list". What does the length > > > > refer to -- the number of Segment Lists in the SRH, the size of the > > > > SRH, or something else? > > > > > > We clarified in revision -13 that this is "the same forwarding path". > > > > > > The length of a segment list is the number of elements that it contai= ns. > > > > > > > 1098 If an SR source node chooses to compress the segment list, one= method > > > > 1099 is described below for illustrative purposes. Any other method > > > > 1100 producing a compressed segment list of equal or shorter length= than > > > > 1101 the uncompressed segment list is compliant. > > > > The requirement is: "MUST...result in the same forwarding path as the > > original segment list." BUT a method that produces "a compressed > > segment list of equal or shorter length than the uncompressed segment > > list is compliant". > > > > I understand the intent, but given that it is a requirement, how can > > "the same forwarding path" be enforced? If the path is loose, how can > > "the same forwarding path" be guaranteed? > > > > Suggestion> > > > > The segment list that the SR source node pushes onto the packet MUST > > comply with the rules in Section 6.3 and Section 6.4 and should result > > in the same forwarding path as the original segment list. > > That's a good point. However, "should result in the same forwarding path"= may > be too loose. > > How about "MUST [...] result in the same *set of possible forwarding path= s* > as the original segment list"? I've been reading this sentence over and over...let's take a step back. =C2=A0This is how the text has evolved: "The segment list that the SR source node pushes onto the packet MUST...result in " -11: "a path equivalent to the original segment list." -13: "the same forwarding path as the original segment list." -14: "the same set of possible forwarding paths as the original segment lis= t." I was getting stuck on the question of "how can the MUST be enforced as the packets are forwarded through a *path*?" =C2=A0But that's the wrong question. The "original segment list" includes the SR Policy that represent the path (in the form of SIDs =3D segment endpoints) that must be followed. The compressed segment list must result in a path with the same segments/segment endpoints (as the "original segment list"). =C2=A0Is that the correct interpretation? The requirement (a path with the same segments/segment endpoints) can only be enforced at the SR Source Node -- it can't be enforced in transit (in the forwarding path) or at the last segment router. Suggestion> =C2=A0 =C2=A0The segment list that the SR source node pushes onto the packe= t =C2=A0 =C2=A0MUST...result in the same SR Policy as the original segment li= st. Thoughts? ... > > 1242 6.3. Rules for segment lists containing NEXT-C-SID flavor SIDs ... > > 1262 6.4. Rules for segment lists containing REPLACE-C-SID flavor SIDs ... > > [major] Are these requirements validated at any point? For example, > > if rule #3 is not implemented and the next Segment List is not "a > > REPLACE-C-SID container in packed format". Which node enforces the > > fact that the specification is not followed? It seems to me that the > > only node in that position would be the one represented by the that > > last SID. Can any action be taken? What is the impact? > > These requirements are a part of how the SR source node builds the compre= ssed > segment list and the SR source node is sole responsible for enforcing the= m. > > As goes with any SRv6 segment list, the other nodes along the path can on= ly > validate that the next SID matches a local FIB entry. > > The impact if these rules are not followed are the same as any other > incorrect value in an SRv6 segment list: the packet may get dropped or > misrouted. Right, that's what I wanted to get to. Please consider adding that conclusion to the text: =C2=A0 =C2=A0If these rules are not followed, the packets may get dropped o= r =C2=A0 =C2=A0misrouted. ... > > 1458 Signaling the SRv6 SID Structure is REQUIRED for all the SIDs > > 1459 introduced in this document. It is used by an SR source node to > > 1460 compress a segment list as described in Section 6. The node > > 1461 initiating the SID advertisement MUST set the length values in the > > 1462 SRv6 SID Structure to match the format of the SID on the SR segmen= t > > 1463 endpoint node. For example, for a SID of this document instantiate= d > > 1464 from a /48 SRv6 SID block and a /64 Locator, and having a 16-bit > > 1465 Function, the SRv6 SID Structure advertisement carries the followi= ng > > 1466 values. > > > > [major] "Signaling the SRv6 SID Structure is REQUIRED..." > > > > The SRv6 SID Structure TLVs are optional in rfc9352, rfc9513, rfc9514, > > I-D.ietf-pce-segment-routing-ipv6, and > > I-D.ietf-idr-segment-routing-te-policy. Even if this document > > requires the information to be advertised, the control protocols > > don't. What should the SR Source Node do if the SRv6 SID Structure is > > not present? > > > > Given that the SRv6 SID Structure TLVs are optional, a rogue node can > > decide to not advertise the information -- the result would probably > > be that SIDs would not be available to construct all the paths that > > may be required, which may result in suboptimal routing, or even the > > inability to construct paths to specific destinations. Please include > > something about this threat in the Security Considerations. > > This is covered in section 6.1. In particular: > > | When compressing a segment list, the SR source node MUST treat an > | invalid SID structure as unknown, and treats the SID as > | incompressible. An invalid SID structure is not the same as a missing one, even if the result is. =C2=A0Please indicate that the above also applies to the case where it is missing. BTW, the first sentence in =C2=A76.1 says this: =C2=A0 =C2=A0As part of the compression process or as a preliminary step, t= he SR =C2=A0 =C2=A0source node MUST validate the SID structure, if known, of each= SID of =C2=A0 =C2=A0this document in the segment list. The combination "MUST validate the SID structure, if known" seems to imply that the structure doesn't need to be validated if not known... s/, if known, / > Not sure how that can be a security threat, though. It's a falsification attack: a rogue router (either the originator or one in transit) can delete the SID Structure Sub-TLV, or change it so that it is not valid. =C2=A0But you're right, the only issue would be that the SID cannot be compressed. https://datatracker.ietf.org/doc/html/rfc4593#autoid-17 > > [major] "...the SRv6 SID Structure is REQUIRED for all the SIDs > > introduced in this document." > > > > This document defines, for example, the End.T behavior for both C-SID > > flavors. However, rfc9352, rfc9513, and rfc9514 don't define the > > advertisement of End.T. To illustrate, rfc9352 says this: > > > > 9. SRv6 SID Structure Sub-Sub-TLV > > > > The SRv6 SID Structure sub-sub-TLV is an optional sub-sub-TLV of: > > > > * SRv6 End SID sub-TLV (Section 7.2) > > > > * SRv6 End.X SID sub-TLV (Section 8.1) > > > > * SRv6 LAN End.X SID sub-TLV (Section 8.2) > > ... > > > > No mention of End.T, or other behaviors mentioned in this document. > > > > Also, from =C2=A77.2: > > > > Supported behavior values, together with parent TLVs in which they > > are advertised, are specified in Section 10 of this document. Please > > note that not all behaviors defined in [RFC8986] are defined in this > > document, e.g., End.T is not. > > > > > > The above means that the requirement to advertise the SRv6 SID > > Structure "for all the SIDs introduced in this document" can't be met > > because the control plane protocols don't currently have the ability > > to signal all the behaviors or because the SRv6 SID Structure is not a > > valid option for them. > > > > While I don't think this issue is a showstopper for this document, I'm > > curious about the plan to extend/update the existing specifications. > > Note that the implementations in =C2=A710 give the impression that no > > exceptions exist -- of course, it is possible that other mechanisms > > (manual configuration, for example) are used. I am also curious about > > any manageability-related plans to enhance YANG models. > > The SID structure requirement only applies when those SIDs are advertised= in a control plane protocol. > > While it is desirable to extend the existing control and management plane > mechanisms for those remaining SIDs, it really falls outside the scope of > this document. For completeness, can you please add that to the document? =C2=A0I see how it can't be required to *signal* the SID structure if the control plane doesn't support it. =C2=A0However, it is required if the SIDs are intended/expected to be compressed, so it would be nice to say something about it in the text. Suggestion> =C2=A0 =C2=A0The SRv6 SID Structure may also be learned through configurati= on or =C2=A0 =C2=A0other management protocols. =C2=A0The details of such mechanis= ms are =C2=A0 =C2=A0outside the scope of this document.