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

Dhruv Dhody <> Thu, 29 April 2021 06:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 858A63A1A25; Wed, 28 Apr 2021 23:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uDL7vsnn0xQ2; Wed, 28 Apr 2021 23:21:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D6363A3208; Wed, 28 Apr 2021 23:21:24 -0700 (PDT)
Received: by with SMTP id mu3so7070332ejc.6; Wed, 28 Apr 2021 23:21:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5d3B+0/3JZ/YZx0wy09XjKN0acxAZajUKzIumGFkg0s=; b=l3JtUUd3i3y7zzn5waxyu0MwgANGAm+2YBRUAfFbXLH69halbNDf3kUr6xGF5w6tWo 5Go24FNip2fS2XA0Yz5sSZWByrDqr0b/WT0hF69lDsgXPUpO3D2npcG+M9GcEQoG43tY rLMKAFP4fjxirkVUHqGcX3WaTewfbCVOo7WX/ViS1IvMlM5Y1rMjqNmfLj8vjnkKnA1y 6rSnEtwAQxVvPk55n+xHh8I8JFbkWCI7wzX1oelNFOz5I10maEc4e5tViPAkRIGJ1MBi fKYiLKEBqySgaovy0DgFkMSskc1gvlKhcDOppvojovYu8YVGwXgFYC5xcWijfJVk3s86 tyyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5d3B+0/3JZ/YZx0wy09XjKN0acxAZajUKzIumGFkg0s=; b=tBoNYLTUMbaKp9aSuovnSwBrZg+eQsSfVlBDfttEPxn6Od4ZlH1qh8selQ7hYNYygi zwGiF5BN3Aae6sr12TJ5jtxJxHO2UPMXJTsGn8Nz3ipM4FCb86qLD3OD2sumTvBq+HsN iZXQ1nzfHZdIbOxyk1HwN+pmjaYJAzLb6YUsJkz6t2bGo6NTIB+jQd6AE1AMJegErkju 7nwyiRgm5g8GNoCGBOYYAzMBzzvA/09zZNTIg9cGU1eQfdO+2H9l4ukEAbZAVkmOCuVK fosBbayl2AjfqGGqz/Wv9CXBBEQq+S+9Z8IvL90y+WLFmrUkOFwNawBH/ZqutPtTk8a6 9kgQ==
X-Gm-Message-State: AOAM530U6sCcVb4U3mPS03Y55E4QhXSseDfiF0XI2KT1NkTXcgnTmgKd kBget4xvkAuhcmwgV3rW2+MqIyGHzlnZIvKpMMO3UVK4ziQ=
X-Google-Smtp-Source: ABdhPJymemcvNnhkaROut+cI5RVh99ZYEdEjoED3JhoYmnYulHjHHS/etiFGp6bi5+B2t+Cg5JORVxvlItBUCnlAz4A=
X-Received: by 2002:a17:906:d8d4:: with SMTP id re20mr13521487ejb.505.1619677281359; Wed, 28 Apr 2021 23:21:21 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dhruv Dhody <>
Date: Thu, 29 Apr 2021 11:50:44 +0530
Message-ID: <>
To: James Guichard <>
Cc: "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000019bbc05c11681f1"
Archived-At: <>
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy
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: Thu, 29 Apr 2021 06:21:30 -0000

Hi WG, Authors,

Support publication. The document reads well and describes key concepts
clearly. Just some friendly suggestions for the authors to consider -

- IMHO introduction section should be expanded as it can provide helpful
clues to new-bees, our published document is not just for the insiders.
- Section 2.1, is there any guidance for the IP address for the headend and
endpoint? 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?
- Section 2.1, I am worried that the use of the noun "intent" to describe
'color'. It does not align with the other use of the term in industry/NMRG.
I see 'SLA associated with color' in other places. There was a jabber
discussion in 110, maybe I am in rough here but wanted to reconfirm!
- Section 2.3, Reference to RFC 8664 for PCEP is wrong here, as <color,
endpoint> is signalled via draft-ietf-pce-segment-routing-policy-cp instead.
- Section 2.3, What are the 8-bit values for the Protocol-Origin, is there
an existing registry that is used here? Is it -
, should it be listed in this document perhaps?
- Section 2.4, For ASN, maybe add "If 2-byte ASNs are in use, the low-order
16 bits MUST be used, and the high-order bits MUST be set to zero.". For
IPv4 Node Address, I would suggest adding the high-order bits MUST be set
to zero!
- Section 2.5, in draft-ietf-pce-segment-routing-policy-cp, no further
clarification is given about the Discriminator and it simply points to this
I-D. This draft says it is left for the future for PCEP. Since the I-D says
tuple <Protocol-Origin, originator, discriminator> uniquely identifies a
candidate path; we need to specify clearly how to populate the
discriminator value in PCEP in this I-D or in PCE WG I-D (it cant be left
for the future IMHO)!
- Section 2.7, we need to say that preference is a 32-bit value (as done
for other fields).
- Section 2.11, why only a SHOULD and not MUST in "Only the active
candidate path SHOULD be used for forwarding traffic that is being steered
onto that policy."?
- Section 3, The focus is on SR headend, some text on SR-DB at the
controller would be nice. Further, in "A non-attached (remote) domain
topology MAY be learned via BGP-LS or NETCONF."; could we clarify that this
is at the controller? The PCEP references should be changed to
- Section 4, there should be rules regarding which combinations of segment
types are allowed to form a valid segment list. Cant mix SR-MPLS and SRv6
for example!
- 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
- 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.
- 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 :)

- Expand on first use: SRv6, SRGB, SRLB,SRLG, SRH, BSID, PW, BFD,
- s/SR DB/SR-DB/g
- Section 2.2, s/via protocols like/via protocol extensions like/

Hope the authors and WG find these suggestions useful.

On Fri, Apr 16, 2021 at 12:27 AM James Guichard <> 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]
> _______________________________________________
> spring mailing list