Re: [Teas] Comments on draft-ietf-teas-yang-te-types

Matt Hartley <> Thu, 18 October 2018 16:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62167130DED; Thu, 18 Oct 2018 09:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 apJTlqD8wQln; Thu, 18 Oct 2018 09:50:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 971A2130DEE; Thu, 18 Oct 2018 09:50:59 -0700 (PDT)
Received: by with SMTP id r190-v6so2831747pgr.13; Thu, 18 Oct 2018 09:50:59 -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=r7i9K036Izr4Q99JwcP1HJadORJzzrLLAMpxsZz+hWk=; b=nRzzrphg1RAvH0HrhQq7jTKTrvHFPpMAMyNv7OB5iyOnkJ6G59sNrwihM8taG9sMmB oBsLfli1vn75yRQMp+glZAT6VZoYIA1psMw4PhnENz4+rA5edPIMc0X5nCxCdMawFYIq 9nN8Jkn9DVzkYVqP5l3jlE2dK0eJP2iyFsWmU6Nr0vBYMu0VfWWo8iE4QNqSmjebs+ff B88R3pHUzo0b+G0cYVhzwkhvzn046kMQv0LZ8Prk7H8WN85qPyOsuSlmGP5SYngES9lY YImjoSqTL1lGA7laLXS9oREPFyvl3zWEWrhr4/5VYwniQo/PpQjo4q3PT6aBWA5g5eyh CnMw==
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=r7i9K036Izr4Q99JwcP1HJadORJzzrLLAMpxsZz+hWk=; b=M/Pt5Pniz1Izvi6vNbw83LTAdUVRvWbiYAqHSQGKoM4RtOqvtV1/3BtvmbKr9CqWz0 o7miqOw3GJICKJuf/LQRooNH4S2/uLCRBqTGlC/GqH/5lDDIXx3wKPY5a+rpX3bnM+yD hGWI5QypqHcgOmleQYJ5sIVrDH7254+oj2xHytBEKZIaAjS+phmUfbz9JjjfeMzlzjmR vQBCSmR0ad3OBXEqFgQIPDZXrsDVAnrHb38KqvdpBoPYRnGP91d6ZejYhtNGibb1Wv1X uUIsWvS0HY4YBQ0NxxqK/y+bfa2+PfVgX3deKkbnEFC44WSm/uiVe32j4BK93tDPwfFR PGbg==
X-Gm-Message-State: ABuFfojxmGsjyE9I9CMGsZi+oQOi/ZekEJ0vSoSv7u3wajVkhHH9PEcv 5BoGYhM7xGP8WV6tnIMtup3wXEYp+GzWMzzjdqswa10w
X-Google-Smtp-Source: ACcGV60v+ClibABiZAOfPbJjZI5nd9CtXJzwac8n10kRT7Yih3cYrfDIHofg1q81LEh1BFNMQ7JYiKP5hmThZFTZBD8=
X-Received: by 2002:a62:18d3:: with SMTP id 202-v6mr30757107pfy.143.1539881459167; Thu, 18 Oct 2018 09:50:59 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Matt Hartley <>
Date: Thu, 18 Oct 2018 12:50:47 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000005eb44c0578839750"
Archived-At: <>
Subject: Re: [Teas] Comments on draft-ietf-teas-yang-te-types
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Oct 2018 16:51:09 -0000


Thanks for the reply. Snipped most things (I assume you'll do mark-ups
where appropriate) but a couple of follow-ups:

On Wed, Oct 17, 2018 at 10:26 AM Igor Bryskin <>;

> p26: identity lsp-protection-unidir-1-to-1: description is "LSP protection
> '1+1 Unidirectional Protection'", but that's inconsisent with the name. I'd
> expect this to be for 1:1 protection, not 1+1. Or if it is for 1+1, the
> name should be ...1-plus-1, shouldn't it? Same for the bidir one below.
> IB>> Correct.
OK - so is that going to be changed? And if so, how? In particular, are you
going to have a separate identity for 1:1, or is that considered to be just
a special case of 1:N and covered by that one?

> p33: identity route-usage-type has route-exclude-ero as an option. Is that
> intended to cover XROs too?
> IB>> Yes
OK, but please make this clear in the description.

> p34: identity te-optimization-criterion: Can't an optimization criterion
> be anything that can be used as a metric?
> IB>> Yes, in many cases path metrics and path optimization criteria are
> the same, but we do not assume that these are necessarily the same things.
> For example, an ERO could an optimization criterion – optimize your path
> selection as much as possible to follow the specified ERO, but this is not
> a resulting path metric. In fact, many (but not all) path constraints could
> be also used as path optimization criteria
OK, so there isn't complete overlap, so you can't have common types. But I
think we should add types for optimization criteria for the stuff that's
missing, unless we consider it impossible to optimize for. Just by analogy
with the metrics, you need:
TE metric
IGP metric
Hop count
Average delay
Minimum delay
Residual bandwidth

Also: it sounds like path-metric-optimize-includes and
path-metric-optimize-excludes are intended to represent EROs and XROs. is
that correct? If so, it isn't at all clear from the text, so please could
you fix that?

> p39: grouping te-topology-identifier: leaf provider-id: how do we ensure
> uniqueness here? Is this something that will need to be managed in the same
> way as IP addresses and AS numbers? Or should we recommend that something
> like an AS number or IP address owned by the provider be used here?
> IB>> the only requirement is that clientid-providerid-topologyid triplet
> is unique within a client-server session. The global uniqueness of any of
> these attributes is not required.
OK, but please make sure the description is clear on this.

> 10.1: You've got the other yang models we're working on as normative
> references. Isn't the idea that this document stands alone, and those
> documents can reference it? Why do we need them as normative references
> here?
> IB>> agree, no need at all. Any TE re;ated UANG model can use the te-types
> definitions
OK. You'll need to take them out of section 1 too - I think it's sufficient
to just remove the example that they occur in.