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

Matt Hartley <mhartley.ietf@gmail.com> Thu, 18 October 2018 16:51 UTC

Return-Path: <mhartley.ietf@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62167130DED; Thu, 18 Oct 2018 09:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: 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 apJTlqD8wQln; Thu, 18 Oct 2018 09:50:59 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 971A2130DEE; Thu, 18 Oct 2018 09:50:59 -0700 (PDT)
Received: by mail-pg1-x52a.google.com 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; d=gmail.com; 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; d=1e100.net; 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: <CAKfnWBhTrSZyfhpUZdBbyZWei_+grj7iGs3MP10mvryGCZ2XfQ@mail.gmail.com> <0C72C38E7EBC34499E8A9E7DD00786391C524514@sjceml521-mbx.china.huawei.com>
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD00786391C524514@sjceml521-mbx.china.huawei.com>
From: Matt Hartley <mhartley.ietf@gmail.com>
Date: Thu, 18 Oct 2018 12:50:47 -0400
Message-ID: <CAKfnWBi_dJXrO=SKC2RPGs-ZgbyG_Ev8gPYCSZmN8BGdXT_+sA@mail.gmail.com>
To: Igor.Bryskin@huawei.com
Cc: draft-ietf-teas-yang-te-types@ietf.org, teas@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005eb44c0578839750"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/5X8AdKcaQKFhx496EPWxShNYsR4>
Subject: Re: [Teas] Comments on draft-ietf-teas-yang-te-types
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Oct 2018 16:51:09 -0000

Igor,

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 <Igor.Bryskin@huawei.com>;
wrote:

> 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.

Cheers

Matt


>
>