Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dhruv Dhody <dhruv.ietf@gmail.com> Fri, 30 April 2021 06:13 UTC

Return-Path: <dhruv.ietf@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 AB42A3A15A6; Thu, 29 Apr 2021 23:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, URIBL_BLOCKED=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 ibhi3h5WhBPT; Thu, 29 Apr 2021 23:13:14 -0700 (PDT)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 4F18F3A15A0; Thu, 29 Apr 2021 23:13:14 -0700 (PDT)
Received: by mail-ej1-x62e.google.com with SMTP id a4so10157794ejk.1; Thu, 29 Apr 2021 23:13:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I33DL3j63xNoL+MO9MkWLNNY320mGasLNCu0Huz7DN8=; b=J4U6R0fI1gqTIY8P10J/wUrVlPVi8o+Ntir0dr/M4P9qPNC2oXBwy1a/THOUAbd2d+ 7WclU8AfoMI/c/yUauFNfFOKddfqNbYfQmV7aDCTniGnyiW9DmZd1s7mnci04aibEK+H h9ylz+oe3SobDeoxm4g1yFn263+7lHAyXSbUQqoCYklUwA7iiEfd2Iw9jfjeZUyGV9lG Ktn4foq36R3MYloBjkwGrshBMqgaYBUR66MFLS3sax9NKiPmdwc+A8Mrb64Lc+XYcX2m N871ssJHqswtT19snHiG15wwO0PsP0w9T7YlNO7WKEi+Ux4TFmdfHhHRv6lNxfgycrQs Pw7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I33DL3j63xNoL+MO9MkWLNNY320mGasLNCu0Huz7DN8=; b=C0FrRnKsdGK4vbWz/jSjFutJdKGK1hx5F9/db9JtSosuDeb6dVq/QV8gkc5dKefV+n FZ12Nf5L8vY4ubKTViUzJCooQpNBBcQH4CitiZfwz0RMIGfRsDon3HN816i+cSRzyhE1 TYfUGqeZBlF6DwlZwNg2h3cqIR6+V3NrQhhYafaJQQIkJWN+vNIjNCNVqLnuKZvbfG4u M3yXZYXiNiVVjgQDA8WvFUS8rSZImumUI69CtNKHy99ctqEjsSvh1dRIVjlOHMwC4mqd AGRp8ZFgALgduhvnvLcAPJdeMYPzrnbGJzsxc0Q4y2NjUTrGv9xULGs/RtUFczs47XHm BalA==
X-Gm-Message-State: AOAM532CiuxZGH2Bcuz3XfG0p6Ir1rXLsbHrBzwg0+uK+Nt7jAma68/V zmdu0qiS8yLupGQ7ecd9Z/+DjvRuTM1fqVGs7RM=
X-Google-Smtp-Source: ABdhPJzm56TVXzCNuHvW1FmYJFCs9ru/JdimK3djBzeZlsogzO6bznVjqjOk6vzoIHxDZIMLOxNGB/Mtff5d+lkGgI4=
X-Received: by 2002:a17:906:b5b:: with SMTP id v27mr2396687ejg.40.1619763188462; Thu, 29 Apr 2021 23:13:08 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR13MB4206EF1F6E9B1C01BDDCDD76D24D9@MN2PR13MB4206.namprd13.prod.outlook.com> <CAB75xn6mV0b6AT_6DQEGNBvhMw1bLm7Hr-X71+afe+zPMBxaPg@mail.gmail.com> <MW3PR11MB4570B64CAD44377A56D5C0EDC15F9@MW3PR11MB4570.namprd11.prod.outlook.com> <CAB75xn6rcP7QbCZEgANgT15956M5GW0RkGN7FcT+-DTQnAPs0w@mail.gmail.com> <MW3PR11MB457062613B7F61B6D977BB39C15F9@MW3PR11MB4570.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB457062613B7F61B6D977BB39C15F9@MW3PR11MB4570.namprd11.prod.outlook.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Fri, 30 Apr 2021 11:42:31 +0530
Message-ID: <CAB75xn5-4p5rbgSOEmNcu9=e3wAwb+7ENxxzAN=iBVik4GkORA@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: James Guichard <james.n.guichard@futurewei.com>, "spring@ietf.org" <spring@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000077f59305c12a8192"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Q29PTW9Opt6dUnQSZosyCAgKdxg>
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
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, 30 Apr 2021 06:13:20 -0000

Hi Ketan

Thanks for handling the comments. Just a final comment on the
security/manageability considerations that explains my reasoning. I would
let you/shepherd take a call!

This draft describes the SR Policy with a common informational model which
has proven to be quite useful. I would like to see this approach extended
to also capture the security and manageability aspects in a
protocol-agnostic way. The configuration of SR policy, the verification
rules, SR-DB handling, various policies that control active path selection,
are all common and should be listed in this I-D. You could also give clear
requirements for the protocols to build on. There have been cases where the
protocols have differed leading to issues. Having a section in this I-D
that lays out clearly for protocols would be useful. As the work is
distributed across WG, IMHO having a SPRING WG consensus on such a text
would be nice.

Just my 2 paisa :)
Stay Safe!

Thanks!
Dhruv


On Thu, Apr 29, 2021 at 7:40 PM Ketan Talaulikar (ketant) <ketant@cisco.com>
wrote:

> Hi Dhruv,
>
>
>
> Please check inline below.
>
>
>
> *From:* Dhruv Dhody <dhruv.ietf@gmail.com>
> *Sent:* 29 April 2021 15:46
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Cc:* James Guichard <james.n.guichard@futurewei.com>om>; spring@ietf.org;
> spring-chairs@ietf.org
> *Subject:* Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy
>
>
>
> Hi Ketan,
>
>
>
> Thanks for the discussion. Sniping to -
>
>
>
>
>
> If a node is identified by multiple addresses, from the point of view of
> the SR policy they would be considered as different nodes, correct?
>
> *[KT] This relates to the computation of SR Policy which is outside the
> scope of this document. There was some text around computation aspects in
> an earlier version of the draft that has been moved into
> draft-filsfils-spring-sr-policy-considerations around the WG adoption time.
> To answer your question, the endpoint address can be mapped to a node which
> becomes the tail-end and then path is computed to that node. In that case,
> multiple addresses may all map to a single node. This would be an
> implementation aspect.*
>
>
>
> [Dhruv]: I was thinking from the SR policy identification point of view,
> i.e. <H1-IP1, color, endpoint> and <H1-IP2, color, endpoint> will be
> considered as different SR policies even though H1-IP1 and H1-IP2 belong to
> the same headend H1.
>
> *[KT] Yes, they would be different SR Policies.*
>
>
>
>
> - Section 2.3, What are the 8-bit values for the Protocol-Origin, is there
> an existing registry that is used here? Is it -
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-14#section-9.4
> , should it be listed in this document perhaps?
>
> *[KT] These are not code points but suggested default values for the
> Priority assigned to each protocol. An implementation may use a completely
> different scheme and/or make theme configurable. I see that
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2
> <https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2>
> does not clearly indicate this and perhaps the authors should clarify that
> the Protocol Origin in that PCEP TLV is used to tweak/signal the Priority
> value to be used for that particular CP in the tiebreaker.*
>
>
>
>
> [Dhruv]: I am referring to this text -
>
>    Protocol-Origin of a candidate path is an 8-bit value which
>    identifies the component or protocol that originates or signals the
>    candidate path.
>
> Which says that an "8-bit value" identifies the protocol as PCEP, BGP,
> etc. What you are describing is the priority associated with the protocol.
> I feel the term "Protocol-Origin" and "Protocol-Origin Priority" is used
> interchangeably, leading to this misunderstanding.
>
> To confirm, in the example - Candidate-path CP1 <protocol-origin = 20,
> originator = 100:1.1.1.1, discriminator = 1>. The value 20 identify BGP or
> the Priority value associated with BGP? I am assuming it is the priority!
>
> In which case some cleanup of text is needed to make things clear.
>
> *[KT] I see your point. The use of “priority” and that too inconsistently
> might be the cause for the confusion. Will clean-up the text around this.*
>
>
>
>
> - Section 10, It might be a good idea to acknowledge security
> considerations from the SR policy architecture point of view: how various
> SR policy parameters and attributes could be exploited to make a headend to
> forward the traffic incorrectly. It is better to add details that clearly
> show that the authors/WG have given it a thought and analyzed the
> implications.
>
> *[KT] As a reminder the SR Policy has been introduced in RFC8402 which
> covers these aspects of incorrect routing and other challenges associated
> with source routing. This document is only providing the details of the
> implementation construct/framework for the SR Policy.*
>
>
>
>
>
> [Dhruv]: In my reading, RFC 8402 security considerations are focused on
> the data plane and not much on the interaction between the controller and
> SR nodes where the SR policy architecture comes in.
>
> *[KT] This document does not cover the actual protocols used for
> interactions between controller and routers – that is covered via PCEP and
> BGP documents.*
>
>
>
>
>
> - Section 11, What is the range of the value for Segment Types? A-Z only?
> It would be good to be clear about this. With A-K already allocated, worth
> thinking if this is too restrictive and not future-proof. Perhaps we could
> think of the value as a string that is currently populated with a single
> alphabetic character.
>
> *[KT] String can become freeform. How about A-Z, then AA-AZ … ZA-ZZ – that
> should be a large enough space?*
>
>
>
> [Dhruv]: That works. Maybe you could add this to the table to clearly
> indicate the range:
> L-Z: Unassigned
> AA-ZZ: Unassigned
>
> *[KT] I’ll try to describe this in the text since the AA-ZZ might not be
> very clear.*
>
>
>
> Related question: is there a value in putting aside a few of these for
> Experimental Use?
>
> *[KT] I don’t think so because these are not signaled in any protocol.*
>
>
>
>
> - Since the I-D talks about policy configuration, explicit candidate
> paths, verification, SR-DB, etc. I don't want to add work for the authors
> but I do feel in this case a dedicated manageability consideration section
> would be useful :)
>
> *[KT] Good catch. I will add it. It is not much work really since we need
> to point to RFC8402 which introduced the SR Policy and an informative
> reference to draft-ietf-spring-sr-policy-yang that the WG is already
> working on.*
>
>
>
>
>
> [Dhruv]: That helps, but also think in lines of documenting some key
> considerations as per
> https://datatracker.ietf.org/doc/html/rfc5706#section-2
>
> *[KT] This is not really a new protocol per-se and I am not sure if this
> is necessary. However, if there are any text proposals, we can discuss
> within the WG.*
>
>
>
> *Thanks,*
>
> *Ketan*
>
>
>
> Hope the authors and WG find these suggestions useful.
>
> *[KT] Yes, definitely.*
>
>
>
> Thanks!
>
> Dhruv
>
>
>
>
>
>
>
> *Thanks,*
>
> *Ketan*
>
> Thanks!
> Dhruv
>
> On Fri, Apr 16, 2021 at 12:27 AM James Guichard <
> james.n.guichard@futurewei.com> wrote:
>
> Dear WG:
>
>
>
> This email starts a 2 week Working Group Last Call for
> draft-ietf-spring-segment-routing-policy [1].
>
>
>
> Please read this document if you haven’t read the most recent version and
> send your comments to the SPRING WG list no later than April 29th 2021.
>
>
>
> If you are raising a point which you expect will be specifically debated
> on the mailing list, consider using a specific email/thread for this point.
>
>
>
> Lastly, if you are an author or contributors for this document please
> response to the IPR call in the previous email thread.
>
>
>
> Thanks!
>
>
>
> Jim, Joel & Bruno
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
>
>
>
>
>
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
>