...
See bottom of the page
Attendees
Agenda plan of April 12, 13 and 15 ONF OTCC TAPI Meeting
...
| Day | Period | Topic & Contributions | TAPI Version | Discussion - pls add link to contributions | Notes |
|---|
| Mon 12 | P1.1 | Intro, Agenda review |
| AllAgenda agreed. Ramon Casellas is reviewing the minutes of past TAPI calls: some of the new Use Cases of draft RIA 1.1 need further review, to be planned in the next TAPI calls. |
|
| P1.2 | Path Computation / Planning / Check Service Feasibility (providing an Explicit Route Object) Fully Explicit Route indication | 2.1.3 2.3 --> | Ramon Casellas presents otcc2021.RC.001_TAPI-PathComputation.pptx otcc2020.ND.010_TAPI-ConnectivityServiceComputationService.pptx Reference to RIA 1.1 UCs Ramon Casellas - Learning from IETF PCE
- Issue of UUIDs instead of object ref:
 Image Added
- Karthik Sethuraman this is likely only historical, we can amend with usual object references, e.g.
grouping path-ref {
leaf path-uuid {
type leafref {
path '/tapi-common:context/tapi-path-computation:path-computation-context/tapi-path-computation:path/tapi-path-computation:uuid';
}
description "none";
}
description "none";
} - Ramon Casellas proposes to specify in the RIA 1.1 two name-value pairs which allow to group PathComputationService concurrent provisioning:
 Image Added
- It is possible to define an agreement between client and server that the Path Computation task is composed by N distinct Paths, implemented through N PathComputationService requests with a common group id and the index.
- This solution does not conform to the protocol, but is doable in TAPI 2.1.3
- Nigel Davis will present the PathSet concept as more generic mechanism to group Paths, see next P2 slot.
- Karthik Sethuraman In MEF and TMF there is the concept of Order, which purpose is to track the provisioning activity.
- ERO Provisioning:
- Proposed the solution to specify the ConnectivityService / Path constraints as an
- ordered set of NEPs (referenced by name),
- per each NEP a new data structure (allocation) which includes technology specific constraints, e.g. wavelength, amplifier gain/tilt, etc:
 Image Added
- Andrea Mazzini we should try to avoid model duplications, because the detailed path/route constraints can be specified through a subset of current (technology specific) CEP attributes. Ideally we should split the CEP object between intent and state attributes. Nigel Davis we also need to consider intents expressed as ranges., e.g. route the connection using a choice between three time-slots. Ramon Casellas in GMPLS works we started some study considering ranges, but we concluded that it was too complex with respect to actual requirements, where ranges are not required but only exact single time-slot / wavelength. Karthik Sethuraman outlines a Use Case where Orchestrator provisions an end-to-end connectivity spanning three distinct managed domains:
- First domain, the Orchestrator requests all the available wavelengths between UNI1 and ENNI1.
- Second domain, the Orchestrator requests the subset of available wavelengths between ENNI1 and ENNI2 among the ones available in the first domain.
- Third domain, the Orchestrator requests the subset of available wavelengths between ENNI2 and UNI2 among the ones available in the second domain.
- Ramon Casellas suggests a simpler scenario, where Orchestrator asks to each domain all the available wavelengths and then enforces the one common to all three domains.
- Nigel Davis we also need to consider multi-layer constraints, where not-yet-exisiting-client NEPs could be part of the constraints.
- Ramon Casellas notes that PathComputationService already foresees 1-to-many Paths, hence using the diversityPolicy attribute of RoutingConstraint object it seems possible to implement some grouping provisioning.
Preliminary list of Path Computation Use Cases emerged during the discussion: - Client requests Server to calculate more Paths between same end points, each Path with different constraints (e.g. focus on delay or focus on cost, etc.). One of these Paths will be used as routing constraint for ConnectivityService provisioning. Note that a variable degree of routing diversity could be required between the group of Paths. To be considered also the multiplicity between PathComputationService and its Paths.
- ERO provisioning, Client requests more detailed constraints, e.g. the exact label / time-slot / wavelength of a Path. Single layer only.
- Stateless PCE, the calculated Path is not created at Server side, i.e. is seen at the management interface only in the reply of Path provisioning Post/RPC (Post could inherently not support a stateless provisioning).
- Provisioning of a group of ConnectivityServices, with specific rules for the group (e.g. degree of diversity).
|
|
| P2 | Path Computation / Planning / Check Service Feasibility (providing an Explicit Route Object) Fully Explicit Route indication | 2.1.3 2.3 | As above | Nigel Davis presents otcc2020.ND.010_TAPI-ConnectivityServiceComputationService.pptx - There is an error in the current UML definition, the correct association between Path and Link is [* → 1..*] (rather than 1→ 1..*) because more Paths can share same Link.
- Consider the static and dynamic cost of a Link, more in general it is required a dynamic planning (or on-line planning), where planned paths can change during their lifecycle to follow network changes (evolution, faults) while respecting the originally specified constraints (but there is only one RoutingConstraint instance per PathComputationService instance).
- Karthik Sethuraman recalls that Path Computation was introduced for architectural purposes, and stateful. Nigel Davis presents the PathSet concept:
 Image Added
- Predefined PathSets:
- Set provides alternative Link Chains
- Different PathSets may be used for different services
- PathSets may be constructed for future cases that require different routing to current
- PathSets are not provisioned
- Agreed that PathSet is a generalization of the grouping solution proposed by Ramon Casellas in previous slot P1.2
- Nigel Davis we should explore whether to collapse Path Computation into ConnectivityService provisioning, given that the Path is essentially a pre-computed intent for the Route.
- Also consider the provisioning of multiple ConnectivityServices with intra-constraints.
- Andrea Mazzini considers that the Path could also be infrastructure, i.e. a virtual network to be used for future end-to-end ConnectivityService provisioning.
- E.g. the ODUk Serial Compound Link Connection which interconnects the transponders.
|
|
| P3 | Consolidation of ODU OAM | 2.3 | Andrea Mazzini | Nigel Davis indicates that the CurrentData is not associated to the MEP/MIP/CEP instance providing the measurement. Minutes to be completed. |
|
| Tue 13 | P1 | Physical Route and Optical impairments GNPy | 2.4 | |
|
| P2 | Physical Route and Optical impairments GNPy | 2.4 | As above |
|
| P3 | European H2020 PASSION Project Politecnico di Milano and SM-Optics | 2.3 ? | |
|
| Thu 15 | P1 | Consolidation of Alarm/TCA | 2.3 | Andrea Mazzini- Discussion on "stateful" alarm/TCA |
|
| P2 | OTS and OMS model | 2.1.3 ? | |
|
| P3 | 3R or UNI Client interfaces modelling. DSR/ODU multiplexing over ODU | 2.3 ? | Ramon Casellas for UNI DSR over ODU mux |
|
...