Re: [spring] WG Adoption Call for draft-raza-spring-sr-policy-yang

Dhruv Dhody <> Sat, 25 July 2020 17:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02E543A0A51; Sat, 25 Jul 2020 10:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, 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 fMdvwtxlUsXg; Sat, 25 Jul 2020 10:19:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8640C3A0D1B; Sat, 25 Jul 2020 10:19:13 -0700 (PDT)
Received: by with SMTP id y18so1342777ilp.10; Sat, 25 Jul 2020 10:19:13 -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=C/ll8b1gkzwdeIPQpRmFRDuPSBFmgnLAhOkThNeNVJ8=; b=r6rs4HluoAGpP1bNny+PzuYclc1K5QXcQJkqSDu+NwbPLhzb+6d9RQ2o3D3lYQF2S3 TqmHg752jdUd0uT2H9YA18MvFjOffxS5qDw693qnlOyPTWhmoJk3wAK0CwYTJiIXbJri XXoW7fH4dLKrqpAMtc/PhPOX2suESbf6SzmGgM4l5WCDldsfVVwJ87rXpP2KzYZ8cIdU xE2n7EjiE2G7Q/p2c/Ocqz0hj0Kp+I0Cu/CMkjweSmbG5/xO9M3O1NKCpxYu2vkzKLFt QQETK6GiZSYkauy9L54a1q50MFxPejiafkQuHg5jNOyPGDjh4ceKKsAzz85iRVj7sXUN Sr0Q==
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=C/ll8b1gkzwdeIPQpRmFRDuPSBFmgnLAhOkThNeNVJ8=; b=eVthHWi8W317D67t4cOqafP+7Ffz9V3yj4QVVcACoyymB+2ZgvI4q73Y3BzqhSSSxF qQlOw5Fhbf5vogBYVjep1PCgouSILw3CI5m72UJoRDDQLx3fmbKxKaoGEv0+k1KIHwU+ 6TvFEXpLatPKdskmouodE1JHRhi8HiOXrAbaUL5UfhGtUtESD/kgDU3Jg52Svb+FYCs/ ycYMx2sC7n3tH0HKSqqK5sBeVnpJaVSKqJ0ng0qJ8J6h+cnS452qw3aZujw8X4T/Orw6 2DGw6oZVyCJyc/FigY/s9FMg8NoLxYdpldZ+5Rqh6AHxK2iEaUgM0TNk2WfJ8lj59o1E Mn+w==
X-Gm-Message-State: AOAM531KEkk+XEWFKFYEmSsMoWxfXcpDLwOOaD+T/h7EnI4B02i9XUsX UW0LSs9AAdr3GQN0uhk99AMDMWBsXJhUGfXHR48g5lUr8dk=
X-Google-Smtp-Source: ABdhPJzFer12ZwxsRtrXyyciT0UlxmYaL5bT5BWUCmNfZrVFspih2bykhC2k4ewLTsu8mFD772sBlU4sheDXbCN91RA=
X-Received: by 2002:a92:d450:: with SMTP id r16mr14908475ilm.124.1595697552327; Sat, 25 Jul 2020 10:19:12 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dhruv Dhody <>
Date: Sat, 25 Jul 2020 22:48:35 +0530
Message-ID: <>
To: James Guichard <>
Cc: "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [spring] WG Adoption Call for draft-raza-spring-sr-policy-yang
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: Sat, 25 Jul 2020 17:19:15 -0000

Hi WG,

I support the adoption of this work and I have thoughts on how to
improve the document -

Some questions/comments -

- Why do you have the config and the state trees separately in Figures
2 and 3? That's out of fashion with NMDA!
- I hope this model is applicable for both the headend router as well
as for the controller. If yes, we should highlight that as well as
make sure the YANG model takes care of this. For example, counters,
path-forwarding_state, etc
- I found the top-level container "traffic-engineering" on top as out
of place when the rest of the SR-Policy work does not use it.
- Regarding segment types, I have a few thoughts -
  * I-D.ietf-spring-segment-routing-policy uses Type A,B,C,...,
whereas you use Type 1,2,3..
  * Should we use identity here instead of enum, to allow for future
segment types to be defined?
 - Please describe the use of group-id and subgroup-id for
disjointness, this was not clear from yang or the text
 - The constraints currently defined are quite minimal, is there any
reason for that? I feel more constraint and optimization criteria
should be supported.
 - How do we relate the information in forwarding-paths to the
candidate path? Also, where would the inactive candidate paths
received from BGP/PCEP stored in this model (assumption that
forwarding-paths are active only)? Maybe segment-lists for dynamic
paths should be added as well?

Suggestions for improving YANG -
- Add references such as during import and important leaves.
- Use generic-path-disjointness in ietf-te-types instead of defining a
new identity for path-disjointness
- Use of identity for protocol-origin-type (instead of enum) to allow
other protocols to be added easily
- Use of labels as a key in a label stack is incorrect (see grouping
mpls-label-stack), as you could have the same label repeated in the
- sid-algorithm, color, and name should have its own typedef
- Run "pyang -f yang --keep-comments --yang-line-length 69 <FILE>" to
help with formatting.


On Mon, Jul 13, 2020 at 9:08 PM James Guichard
<> wrote:
> Dear WG:
> This email begins a 2 week WG adoption call for ending Monday 27th July 2020.
> Please speak up if you support or oppose adopting this document into the WG. Please also provide comments/reasons for that support (or lack thereof). Silence will not be considered consent.
> Thanks!
> Jim, Joel & Bruno
> _______________________________________________
> spring mailing list