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

[Matt Hartley <[e-mail]>]

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 <[e-mail]>
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


>
>