Proposed solution for path-id (open issue #52)

italobusi commented 5 years ago

Proposed changes to the YANG model to address open issue #52

Question for further discussion/review:

[x] How to force that the transaction-id is specified only if the timer is specified?
[x] How to create the delete RPC?
[x] Review with Xufeng changes in https://github.com/rvilalta/ietf-te-path-computation/pull/60/commits/99175b64668fb6510bf716d01aeb9fce360d934c
[x] Update as per comment https://github.com/rvilalta/ietf-te-path-computation/pull/60#issuecomment-460586989
[x] Compile

italobusi commented 5 years ago

@sergiobelotti : udated as discussed today (not yet compiled)

italobusi commented 5 years ago

@sergiobelotti : updated after discussion with Xufeng

@sergiobelotti , @efralaz , @carloperocchio : please review the updated YANG model

italobusi commented 5 years ago

Please consider that with the current YANG model, it is possible to send a single RPC request to compute multiple paths and at the same time (with the same RPC request) to remove paths associated with multiple transaction-id values

I do not see drawbacks with this solution but we should document it in the Internet-Draft

italobusi commented 5 years ago

The latest version of the YANG module (2019-01-29) has been compiled after having fixed the compilation errors

The YANG tree has also been uploaded

@sergiobelotti , @efralaz , @sergiobelotti : please review and send you feedbacks

Thanks @carloperocchio for having compiled and fixed the compilation errors

sergiobelotti commented 5 years ago

The latest version of the YANG module (2019-01-29) has been compiled after having fixed the compilation errors

The YANG tree has also been uploaded

@sergiobelotti , @efralaz , @sergiobelotti : please review and send you feedbacks

Thanks @carloperocchio for having compiled and fixed the compilation errors I'm going to review the new version

sergiobelotti commented 5 years ago

The latest version of the YANG module (2019-01-29) has been compiled after having fixed the compilation errors

The YANG tree has also been uploaded

@sergiobelotti , @efralaz , @sergiobelotti : please review and send you feedbacks

Thanks @carloperocchio for having compiled and fixed the compilation errors

I'm going to review the files. In the comment above " I think we need to add a "reference" (name) to the computed path that is returned by RPC in order to be able for tunnel model to setup exactly this path when it is needed to setup the tunnel . We could add the tunnel name in the request (in this case the name is suggested by client) or we can have a name just in the output of RPC (in this case it is the server that suggest a name after the path is computed and returned )" , it seems as though we can propose "reference name" in the input of RPC ,or as output of RPC proposed by server thta has computed the path. In the proposed encoding we have -tunnel-name in the requested-state grouping

tunnel-ref in the reported-state grouping that is used by data models that need to reference configured TE tunnel.

Two questions here : 1) is it needed to have also this tunnel-ref when we provide already tunnel-name in the request ? 2) Tunnel-ref, by definition is related to a configured tunnel , we are considering a reference to a computed path that is not yet instantiated. I'm not sure if that would be correct.

italobusi commented 5 years ago

@sergiobelotti

Regarding your question:

1) I think it makes sense to always return the tunnel-ref as a confirmation that the tunnel state has been created

A side question is whether the tunnel-name configured by the client is requested or suggested.

The current YANG description assumes it is requested: it is the "name to assign" and the "te-tunnel is not created if a te-tunnel with this tunnel name already exists.". Therefore the returned tunnel-ref either points to a tunnel with the requested name or is empty (indicating that no tunnel has been created)

Maybe it is better to update the description and make it suggested: in this case there is no guarantee that the tunnel will be created with the name suggested by the client. In this case, the tunnel-ref is necessary to indicate the actual name that has been assigned by the server (which may or may not be the same as the tunnel-name suggested by the client)

2) The tunnel-ref is pointing to a tunnel which is created (by the server) in the state DS only to report computed path even if no connection is setup but only used to report computed paths (compute-only mode)

italobusi commented 5 years ago

After a call with @sergiobelotti :

1) I will update the descriptions in the model to indicate that the tunnel-name, the primary-path-name and the secondary-path-name are suggested name

2) We will check with te-types authors whether definition of the tunnel-ref data type allows referencing a tunnel in the state DS or only in the config DS

Further updates to be done:

1) add use reported-stateto include the reported state in the response

2) check whether the right syntax to check that the timeris specified is mustor when

italobusi commented 5 years ago

Feedbacks from Xufeng:

replace must with when: no default value for the timer
otherwise use presence container and define a default value for the timer

italobusi commented 5 years ago

Italo/Sergio: agreed to define a default value of 10min for the timer in line with PCEP path key:

https://tools.ietf.org/html/rfc5520#section-2.1

italobusi commented 5 years ago

@carloperocchio : could you please re-compile the updated YANG module?

italobusi commented 5 years ago

@sergiobelotti : the compilation errors have been fixed and the YANG tree generated by @carloperocchio

I think the pull request is ready to be merged

IETF-TEAS-WG / ietf-teas-yang-path-computation

Proposed solution for path-id (open issue #52) #60