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

From: Matt Hartley <[email-masked]>
Date: Mon, 15 Oct 2018 15:28:45 -0400

Authors,

Some LC comments on this. Please note that I haven't really been all that
involved in the discussions and I'm coming to it fairly cold... which may
or may not be a good thing :)

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.

p32: identity lsp-encoding-optical-channel: this has the same description
as the next one. One of these needs fixing.

p33: identity route-usage-type has route-exclude-ero as an option. Is that
intended to cover XROs too? Or do we need another identity for XROs?

p34: identity te-optimization-criterion: Can't an optimization criterion be
anything that can be used as a metric? Do we actually need a separate type
here? If we do, what does 'cost' refer to? And is the delay the average or
minimum (as for the metrics)? the model seems inconsitent with itself here.

p37: identity oduc: description is "ODUCn bit rate." For all the other
elements here the ODU type is the same in the description as in the
identity name (barring capitalization) but here it's different. Is there a
reason for that or does something need to be fixed?

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?

p39: grouping te-topology-identifier: leaf topology-id: should we put some
RFC 2119 language in there, if things MUST be unique? And what's the scope
of that uniqueness? Within the provider/client pair? Globally? Something
else? It's unclear.

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?

Note: Everything after here is nits...

p5, admin-groups: "A union type for TE link's" -> "A union type for a TE
link's"

p5, srlg: "representing the Shared" -> "representing a Shared"

p6, protection-external-commands: "trouble shooting" -> "troubleshooting"

p7: te-class-type, bc-type, bc-model-type: "Diffserv-TE" -> "DS-TE" (since
you went to the trouble of defining this up front...)

p12: typedef te-link-access-type, enum multi-access: is NBMA something that
we can assume is generally understood, or does it need to be expanded?

p13: typedef te-oper-status, enum unknown: I think just "Status cannot be
determined" would do for the description. The rest is redundant.

p13: typedef te-oper-status, enum maintenance: the description here doesn't
reference the control plane (contrast preparing-maintenance above). Would
it be worth specifying that the resource is disabled in both planes?

p17: typedef srlg: I think having the description as "SRLG type" is
confusing (my initial reaction was 'hang on, SRLGs don't have types...').
Maybe just "SRLG"?

p19: identity of-minimize-cost-path: That's a really confusing name. I
thought it was a mangled version of minimize-cost-of-path until I figured
out that the 'of' is just a prefix for objective-function. Maybe
of-minimize-path-cost would be better? Similarly for the next one... maybe
of-minimize-path-load?

p20: identity path-externally-queried: The description is awkward. Maybe:
"Constrained-path LSP in which the path is obtained by querying an external
source, such as a PCE server. In the case that an LSP is defined to be
externally queried, it may also have associated explicit definitions
provided to the external source to aid computation. The path that is
returned by the external source need not be a wholly resolved path back to
the originating system; some additional local computation may also be
required."

p28: identity protection-external-commands: "trouble shooting" ->
"troubleshooting"

p32: identity path-signaling-type: please put a blank line before this so
it's more obvious it's a new base type when reading it.

p36: identity srlg-preferred: is this best-effort? If so, could we have
that in the description?

p37: identity otn-rate-type: description could just be "Base type to
identify OTN bit rates." The rest is redundant.

Cheers

Matt

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 17 Oct 2018 14:26:05 +0000

Hi Matt,

Thank you for your comments. Please, see in-line.

Igor

From: Matt Hartley [mailto:[email-masked]]
Sent: Monday, October 15, 2018 3:29 PM
To: [email-masked]
Cc: [email-masked]
Subject: Comments on draft-ietf-teas-yang-te-types

Authors,

Some LC comments on this. Please note that I haven't really been all that involved in the discussions and I'm coming to it fairly cold... which may or may not be a good thing :)

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.

p32: identity lsp-encoding-optical-channel: this has the same description as the next one. One of these needs fixing.
IB> Good catch

p33: identity route-usage-type has route-exclude-ero as an option. Is that intended to cover XROs too?
IB>> Yes
Or do we need another identity for XROs?
IB>> No

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

Do we actually need a separate type here? If we do, what does 'cost' refer to?

IB>> path summary TE cost.
And is the delay the average or minimum (as for the metrics)? the model seems inconsitent with itself here.
IB>> For the basic models this is minimal (propagation) delay. Packet specific models are expected to ptovide a richer set of delay metrics.

p37: identity oduc: description is "ODUCn bit rate." For all the other elements here the ODU type is the same in the description as in the identity name (barring capitalization) but here it's different. Is there a reason for that or does something need to be fixed?
IB>> Just a typo, thanks

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.

p39: grouping te-topology-identifier: leaf topology-id: should we put some RFC 2119 language in there, if things MUST be unique? And what's the scope of that uniqueness? Within the provider/client pair? Globally? Something else? It's unclear.

IB>> see above

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

I hope this helps,

Igor

p5, admin-groups: "A union type for TE link's" -> "A union type for a TE link's"

p7: te-class-type, bc-type, bc-model-type: "Diffserv-TE" -> "DS-TE" (since you went to the trouble of defining this up front...)

p12: typedef te-link-access-type, enum multi-access: is NBMA something that we can assume is generally understood, or does it need to be expanded?

p13: typedef te-oper-status, enum unknown: I think just "Status cannot be determined" would do for the description. The rest is redundant.

p13: typedef te-oper-status, enum maintenance: the description here doesn't reference the control plane (contrast preparing-maintenance above). Would it be worth specifying that the resource is disabled in both planes?

p17: typedef srlg: I think having the description as "SRLG type" is confusing (my initial reaction was 'hang on, SRLGs don't have types...'). Maybe just "SRLG"?

p19: identity of-minimize-cost-path: That's a really confusing name. I thought it was a mangled version of minimize-cost-of-path until I figured out that the 'of' is just a prefix for objective-function. Maybe of-minimize-path-cost would be better? Similarly for the next one... maybe of-minimize-path-load?

p20: identity path-externally-queried: The description is awkward. Maybe: "Constrained-path LSP in which the path is obtained by querying an external source, such as a PCE server. In the case that an LSP is defined to be externally queried, it may also have associated explicit definitions provided to the external source to aid computation. The path that is returned by the external source need not be a wholly resolved path back to the originating system; some additional local computation may also be required."

p28: identity protection-external-commands: "trouble shooting" -> "troubleshooting"

p32: identity path-signaling-type: please put a blank line before this so it's more obvious it's a new base type when reading it.

p36: identity srlg-preferred: is this best-effort? If so, could we have that in the description?

p37: identity otn-rate-type: description could just be "Base type to identify OTN bit rates." The rest is redundant.
Cheers

Matt

---

From: Matt Hartley <[email-masked]>
Date: Thu, 18 Oct 2018 12:50:47 -0400

Igor,

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

> name should be ...1-plus-1, shouldn't it? Same for the bidir one below.
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?

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

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

> IB>> agree, no need at all. Any TE re;ated UANG model can use the te-types
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

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 18 Oct 2018 17:49:32 +0000

Hi Matt,

Please, see my further responses in-line.

Igor

-----Original Message-----
From: Matt Hartley [mailto:[email-masked]] 
Sent: Thursday, October 18, 2018 12:51 PM
To: Igor Bryskin
Cc: [email-masked]; [email-masked]
Subject: Re: Comments on draft-ietf-teas-yang-te-types

Igor,

IB>> We will have separate identities for 1+1 and 1:N, with the latter covering 1:1 as a special case

IB>> We will

> the same, but we do not assume that these are necessarily the same things