From nobody Wed Feb 16 11:04:21 2022 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 19A2B3A1536; Wed, 16 Feb 2022 11:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shLEnZ_UOyoK; Wed, 16 Feb 2022 11:03:57 -0800 (PST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169623A1531; Wed, 16 Feb 2022 11:03:57 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id j20so3582615vsg.5; Wed, 16 Feb 2022 11:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0PxjaH4Y/5g2IYphsYmJYFHqOKsZn78PWKkazzzzrxY=; b=HovftpCQZLXcbhnqaC7H+3H2MQbBRqL74B/3FZiBLCMH9Pe9TnI7aubArF0HJobAMf P0hludP34ojrxqMH3Bpz+7p0kmdTPtItp33E1Yr7d5dpb+/jmnRC9n/Hb29nLi/7+kby DBUW9owTdK85NmgtYfiRY5Aglvs8RHm8OICx2G1MpSj4CjnfDsvyRTidztbOPRB6LUFy 39ohNLkv42/+/oOzxZRFmN2VuNmGkbiHsAJHHVuJu/GqDX8zCbazKCj+ts4MX5oxpHWn XsRNLT2BPMUjhvcDZb5kRsed7uSplRI+sbtJvq+XILBlb7eFichTIbGMFTVfnKnal3Kv 5GdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0PxjaH4Y/5g2IYphsYmJYFHqOKsZn78PWKkazzzzrxY=; b=hRXMzYg8ZRlQNY4zuyPKTDV/MpwL8UI/qB7m0IT1F7sVm05PVYAYKJGSRBuv8iUsbr qL/HAmeEjAjwadwPC1BTf5NYQ3payUquARUOIC8tQKLQa8E8uH1Mnttc3NO784tlSKUS nH2JLb8Omjgklf96dewDMZskrzDZm2RhVqF+Yrigyj3DE7ewJYSHF8DwifsSAp9UpuMp 4vuKgtAZTnSoZpZ2CtkBTufDVW/hG1TpcqWTsYbHkPz9MIs3xy9ZVACNOc/AV9w5ZVKD xMbMu3B64J1MXnGKxu6fkYFM3PRK6gHLg3AwrprhYb1aCiGM24y4q4l/obpV0Qd0WYsO E6Fg== X-Gm-Message-State: AOAM533AdWsEuilf4bx3mptd9+fMsq74jPffSwGitpj5NK4+EhmIf7CF Pil/PfyGscgdv2yF3AKQKDB/9fmvKfJftLI7OvYoDcnZBMI= X-Google-Smtp-Source: ABdhPJwRNriuJ9oiixa1IqMzeb7K1NISA72vuwxWnqC95UX2CD98EqjCa2ase8mD3usbgKuA79s+fnMECRGck6FKJHU= X-Received: by 2002:a05:6102:3591:b0:310:ef5d:d2be with SMTP id h17-20020a056102359100b00310ef5dd2bemr29034vsu.34.1645038234974; Wed, 16 Feb 2022 11:03:54 -0800 (PST) MIME-Version: 1.0 References: <164503079307.9996.17286143339105134181@ietfa.amsl.com> In-Reply-To: <164503079307.9996.17286143339105134181@ietfa.amsl.com> From: Ketan Talaulikar Date: Thu, 17 Feb 2022 00:33:43 +0530 Message-ID: To: John Scudder Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="000000000000a34b7605d8274ffb" Archived-At: Subject: Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 19:04:00 -0000 --000000000000a34b7605d8274ffb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, Thanks for your review and please check inline below for responses. On Wed, Feb 16, 2022 at 10:29 PM John Scudder via Datatracker < noreply@ietf.org> wrote: > John Scudder has entered the following ballot position for > draft-ietf-spring-segment-routing-policy-17: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy= / > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I=E2=80=99ve done an initial review of this document and have several con= cerns I=E2=80=99d > like > to discuss. I apologize for not also providing a full review as comments = in > this ballot, I judged it more important to begin the discussion about the= se > points timely, than to provide all comments in a single message. > > 1. The shepherd writeup indicates that =E2=80=9CStandard Track is request= ed and > indicated in the title page header. This is appropriate for a > specification of > packet steering into an SR policy needing interoperability between the > ingress/source of the policy instantiation and the egress/destination of > the > policy termination.=E2=80=9D > > I realize it=E2=80=99s unusual to ask to discuss a shepherd writeup rathe= r than the > spec itself, but I think this one rises to the level. My concern is that > this > description (needing interoperability between the ingress and the egress) > doesn=E2=80=99t comport with my understanding of the Segment Routing arch= itecture. > Surely, one of the key value propositions of SR is that it=E2=80=99s stat= eless > everywhere other than the headend? Indeed, that=E2=80=99s stated in the a= bstract. > SR > doesn=E2=80=99t require the egress to even understand that it IS an egres= s of a SR > Policy, it just does what the headers tell it to, right? > > If that's so, then the rationale given for the requested track must be > wrong. > :-( And that in turn leads me to ask, whether the track really is right. = It > seems to me that in most respects this is more an Informational document > than a > standards track one. That=E2=80=99s not a value judgement in any respect,= just a > statement of fact =E2=80=94 for the most part, it doesn=E2=80=99t seem as= though the > information found in this document is needed in order to interoperate wit= h > another system. (Section 8.8 is an exception, I discuss that separately.) > > Anyway, not to get too far ahead of myself, let=E2=80=99s start by workin= g on this > question: is the shepherd writeup correct in saying that interoperability > between headend and tailend is required? If so, can someone please > characterize > the nature of that interoperability, and put it in the context of SR=E2= =80=99s > stateless nature? > KT> I see that Jim (doc shepherd) has clarified. The document aims to standardize the SR Policy constructs and related behaviors. It provides the basis then for protocol extensions (e.g. PCEP and BGP) and the YANG model to follow by a normative reference to it. > > 2. It seems to me an unusual practice for this document to be defining > semantics and even reserving values in a field allocated by a different > document, by a different WG. I=E2=80=99m referring here to the so-called > =E2=80=9C=E2=80=98Color-Only=E2=80=99 > bits=E2=80=9D discussed in Section 8.8. > > - I would be more comfortable if the work were all done in one place, to > the > extent possible. > > - Given the fact this document is reaching in to a registry normally > managed by > IDR, was there any discussion with the IDR group? I don't see any evidenc= e > of a > courtesy notification of the last call when I look at the IDR mailing lis= t > archive. > > I=E2=80=99ve also emailed the IDR list about this in connection with > draft-ietf-idr-segment-routing-te-policy, see > https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/ KT> Thanks. I will work on addressing them as a co-author of that IDR document. > > > Relating this back to my previous question, it=E2=80=99s evident that if = this > document > is going to define semantics for the Color Extended Community Flags, then > that > makes it Standards Track because there is an interoperability factor to > take > into account (that's been imported from IDR). A more ideal solution would > be to > take care of that in the IDR document rather than putting it in this > =E2=80=9Carchitecture=E2=80=9D document, though. Surely, this kind of det= ail is > implementation, > not architecture? Indeed, Ketan said in his reply to Matthew Bocci's RTG > review, "Given that this is an architecture document, it describes the > architecture and not really the protocol mechanisms"... but this section > seems > to be an exception to that aspiration. > KT> The resolution of BGP service routes over the underlying forwarding constructs may be seen by some as more of a "system" or "forwarding" aspect than a BGP protocol aspect. This is in the architecture because operators who have deployed SR Policies expected the same consistent resolution behavior across headed routers from different vendors. > > 3. Related to the above, at least one of the references listed as > informational > clearly has to be normative with the document as it stands. > draft-ietf-idr-segment-routing-te-policy is the one I=E2=80=99m thinking = of, for > example its use in =C2=A72.4 seems like it may rise to the "normative" le= vel, > =C2=A72.5 > almost surely does, =C2=A74.1 surely does, and =C2=A78.8.1 is the icing o= n the cake > because this document defines semantics for a field that isn=E2=80=99t ev= en > allocated > until and unless draft-ietf-idr-segment-routing-te-policy is published. > KT> It is the other way round. The SPRING document specifies the information model and the constructs of the SR Policy. The IDR document is primarily about signaling of the SR Policy from a controller to the headend using the new SR Policy SAFI (73) - as such it does refer normatively to the SPRING SR Policy. > > 4. In =C2=A72.1 you talk about the signaling of symbolic names for candid= ate > paths. > Although you are careful to say that such symbolic names are only used fo= r > presentation purposes, it seems to me they still could be considered a ne= w > potential source of vulnerability, since a string that has no > sanity-checking > whatsoever applied by the protocol can display literally anything to an > operator viewing it. Shouldn=E2=80=99t this be addressed in your Security > Considerations? (For an example of a related Security Considerations, see > RFC > 9003. It=E2=80=99s probably not the best example, but it=E2=80=99s the on= e I had at my > fingertips=E2=80=A6) > KT> RFC9003 uses UTF-8 while this document uses printable ASCII. As such, I am not aware of security issues around printable ASCII - please do point me to any references. Also note that this document does not specify protocol encodings where some extra verbiage is normally required (e.g. that it is signaled without NULL, handling truncation/overruns, etc.). > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > As noted in my DISCUSS, these comments are unfinished but I thought I=E2= =80=99d > give > you what I have. > > 1. I see that Cullen Jennings referred to this in his ART review, but I= =E2=80=99d > like > to talk about it a little more: why have you chosen to restrict symbolic > names > to ASCII? UTF-8 is the more usual choice in this context; indeed > implementations may have to go to extra effort to scrub their input to > insure > that only ASCII is present. BCP 18 doesn=E2=80=99t require you to interna= tionalize > your > strings, of course, it gives you two options, of which you have (sort of, > you > don't have the "US-") followed the latter: > > This document does not mandate a policy on name internationalization, > but requires that all protocols describe whether names are > internationalized or US-ASCII. > > But in 2022 the choice to restrict symbolic names to ASCII seems unusual > enough > to invite the question. > > If you do stick with ASCII as currently written, might you add text > mandating > that implementations scrub their input to prevent non-ASCII characters fr= om > being accepted? > KT> As discussed in the WG, we are sticking to printable ASCII. When the encoding is specified to be printable ASCII, it is expected that implementations valid that. Thanks, Ketan --000000000000a34b7605d8274ffb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

Thanks for yo= ur review and please check inline below for responses.=C2=A0

=

On Wed, Feb 16, 2022 at 10:29 PM John Scudder via Datatracker <noreply@ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">John Scudder has entered t= he following ballot position for
draft-ietf-spring-segment-routing-policy-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.o= rg/doc/draft-ietf-spring-segment-routing-policy/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I=E2=80=99ve done an initial review of this document and have several conce= rns I=E2=80=99d like
to discuss. I apologize for not also providing a full review as comments in=
this ballot, I judged it more important to begin the discussion about these=
points timely, than to provide all comments in a single message.

1. The shepherd writeup indicates that =E2=80=9CStandard Track is requested= and
indicated in the title page header. This is appropriate for a specification= of
packet steering into an SR policy needing interoperability between the
ingress/source of the policy instantiation and the egress/destination of th= e
policy termination.=E2=80=9D

I realize it=E2=80=99s unusual to ask to discuss a shepherd writeup rather = than the
spec itself, but I think this one rises to the level. My concern is that th= is
description (needing interoperability between the ingress and the egress) doesn=E2=80=99t comport with my understanding of the Segment Routing archit= ecture.
Surely, one of the key value propositions of SR is that it=E2=80=99s statel= ess
everywhere other than the headend? Indeed, that=E2=80=99s stated in the abs= tract. SR
doesn=E2=80=99t require the egress to even understand that it IS an egress = of a SR
Policy, it just does what the headers tell it to, right?

If that's so, then the rationale given for the requested track must be = wrong.
:-( And that in turn leads me to ask, whether the track really is right. It=
seems to me that in most respects this is more an Informational document th= an a
standards track one. That=E2=80=99s not a value judgement in any respect, j= ust a
statement of fact =E2=80=94 for the most part, it doesn=E2=80=99t seem as t= hough the
information found in this document is needed in order to interoperate with<= br> another system. (Section 8.8 is an exception, I discuss that separately.)
Anyway, not to get too far ahead of myself, let=E2=80=99s start by working = on this
question: is the shepherd writeup correct in saying that interoperability between headend and tailend is required? If so, can someone please characte= rize
the nature of that interoperability, and put it in the context of SR=E2=80= =99s
stateless nature?

KT> I see that Jim= (doc shepherd) has clarified. The document aims to standardize the SR Poli= cy constructs and related behaviors. It provides the basis then for protoco= l extensions (e.g. PCEP and BGP) and the YANG model to follow by a normativ= e reference to it.
=C2=A0

2. It seems to me an unusual practice for this document to be defining
semantics and even reserving values in a field allocated by a different
document, by a different WG. I=E2=80=99m referring here to the so-called = =E2=80=9C=E2=80=98Color-Only=E2=80=99
bits=E2=80=9D discussed in Section 8.8.

- I would be more comfortable if the work were all done in one place, to th= e
extent possible.

- Given the fact this document is reaching in to a registry normally manage= d by
IDR, was there any discussion with the IDR group? I don't see any evide= nce of a
courtesy notification of the last call when I look at the IDR mailing list<= br> archive.

I=E2=80=99ve also emailed the IDR list about this in connection with
draft-ietf-idr-segment-routing-te-policy, see
https://mailarchive.ietf.org/a= rch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/

KT> Thanks. I will work on addressing them as a co-author=C2=A0of that= IDR document.=C2=A0
=C2=A0


Relating this back to my previous question, it=E2=80=99s evident that if th= is document
is going to define semantics for the Color Extended Community Flags, then t= hat
makes it Standards Track because there is an interoperability factor to tak= e
into account (that's been imported from IDR). A more ideal solution wou= ld be to
take care of that in the IDR document rather than putting it in this
=E2=80=9Carchitecture=E2=80=9D document, though. Surely, this kind of detai= l is implementation,
not architecture?=E2=80=A8 Indeed, Ketan said in his reply to Matthew Bocci= 's RTG
review, "Given that this is an architecture document, it describes the=
architecture and not really the protocol mechanisms"... but this secti= on seems
to be an exception to that aspiration.

= KT> The resolution of BGP service routes over the underlying forwarding = constructs may be seen by some as more of a "system" or "for= warding" aspect than a BGP protocol aspect. This is in the architectur= e because operators who have deployed SR Policies expected the same consist= ent resolution behavior across headed routers from different vendors.
=
=C2=A0

3. Related to the above, at least one of the references listed as informati= onal
clearly has to be normative with the document as it stands.
draft-ietf-idr-segment-routing-te-policy is the one I=E2=80=99m thinking of= , for
example its use in =C2=A72.4 seems like it may rise to the "normative&= quot; level, =C2=A72.5
almost surely does, =C2=A74.1 surely does, and =C2=A78.8.1 is the icing on = the cake
because this document defines semantics for a field that isn=E2=80=99t even= allocated
until and unless draft-ietf-idr-segment-routing-te-policy is published.
=

KT> It is the other way round. The SPRI= NG document specifies the=C2=A0information model and the constructs of the = SR Policy. The IDR document is primarily about signaling of the SR Policy f= rom a controller to the headend using the new SR Policy SAFI (73) - as such= it does refer normatively to the SPRING SR Policy.=C2=A0
=C2=A0<= /div>

4. In =C2=A72.1 you talk about the signaling of symbolic names for candidat= e paths.
Although you are careful to say that such symbolic names are only used for<= br> presentation purposes, it seems to me they still could be considered a new<= br> potential source of vulnerability, since a string that has no sanity-checki= ng
whatsoever applied by the protocol can display literally anything to an
operator viewing it. Shouldn=E2=80=99t this be addressed in your Security Considerations? (For an example of a related Security Considerations, see R= FC
9003. It=E2=80=99s probably not the best example, but it=E2=80=99s the one = I had at my
fingertips=E2=80=A6)

KT> RFC9003 use= s UTF-8 while this document uses printable ASCII. As such, I am not aware o= f security issues around printable ASCII - please do point me to any refere= nces. Also note that this document does not specify protocol encodings wher= e some extra verbiage is normally required (e.g. that it is signaled withou= t NULL, handling=C2=A0truncation/overruns, etc.).
=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

As noted in my DISCUSS, these comments are unfinished but I thought I=E2=80= =99d give
you what I have.

1. I see that Cullen Jennings referred to this in his ART review, but I=E2= =80=99d like
to talk about it a little more: why have you chosen to restrict symbolic na= mes
to ASCII? UTF-8 is the more usual choice in this context; indeed
implementations may have to go to extra effort to scrub their input to insu= re
that only ASCII is present. BCP 18 doesn=E2=80=99t require you to internati= onalize your
strings, of course, it gives you two options, of which you have (sort of, y= ou
don't have the "US-") followed the latter:

=C2=A0 =C2=A0This document does not mandate a policy on name internationali= zation,
=C2=A0 =C2=A0but requires that all protocols describe whether names are
=C2=A0 =C2=A0internationalized or US-ASCII.

But in 2022 the choice to restrict symbolic names to ASCII seems unusual en= ough
to invite the question.

If you do stick with ASCII as currently written, might you add text mandati= ng
that implementations scrub their input to prevent non-ASCII characters from=
being accepted?

KT> As discussed in = the WG, we are sticking to printable ASCII. When the encoding is specified = to be printable ASCII, it is expected that implementations valid that.

Thanks,
Ketan=C2=A0
=C2=A0=C2=A0
--000000000000a34b7605d8274ffb--