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

[Igor Bryskin <[e-mail]>]

Hi Matt,

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

Igor

From: Matt Hartley [mailto:[e-mail]]
Sent: Monday, October 15, 2018 3:29 PM
To: [e-mail]
Cc: [e-mail]
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

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