|Day||Period||Topic (Lead & Work Item)||Comment|
- Diagram should highlight multiplicities (fan-down/in and fan-up/out)
- TR-512.3 lifecycles states should be examined as these relate to arbitration of virtual network provision
- Should consider how this applies to the Core Controller model
- In the standard work we should use the term controller for all layers (orchestrator etc. are marketing terms - see TMF IG1118 (previously sent via liaison)). Likewise the labeling on the interfaces should be generalised from an architectural perspective.
- The distinct labelling for the interface at each level, when describing a use case or application, may be useful to distinguish between the profiles of TAPI used so long as each profile/label is clearly defined. Likewise the labels used on the the controller should be fully defined.
- In the generalized pattern, the controller that owns the fan-up/out must perform the arbitration (VN administration). Clearly some mechanism for allocation must be present. This may be some local administration at the controller that owns the fan-up/out (where that administrator has a work order etc.) or there is some negotiation between the client and the orchestrator.
- It is possible that this is simply contained on one controller layer, but it is more likely that the allocation/division of the network is spread across several layers of controller (due to abstraction/complexity)
- This may (or may not) be via different TAPI contexts depending upon the administration strategy at and between each level of control
- Hing-Kam Lam Clarification with respect to multiplicities (fan-down/in and fan-up/out), meaning of labelled interfaces and controllers, administration strategy where fan-up/out is present (VN administration) and whether the more than one layer of controller is VN aware.
- otcc2019.SSL.001.TAPI and RFC8345 Network Topologies.pptx
- Possible distinction between meaning of "layering" in IETF and ONF/ITU-T etc.
- Links are unidirectional point to point in IETF.
- The model does not prevent multiple links between the same two TPs and a link from a TP to itself
- A TP can be unidirectional or bidirectional as dictated by the Link conbination that relate to it
- For a node to be supported by a node the corresponding networks must be in the same supporting relationship
- The layering of nodes is actually viewing rather than partition
- The IETF model uses the same relationships to represent layering and views (Link has supporting links and TP has supporting TPs)
- It is not possible to explicitly represent a bidirectional link (a pair of links in reverse direction between the same two TPs)
- Off-network TPs, where the higher level view has an explicit link but there is no link at the lower level, have to be explicitly configured (TE topology etc. can be used for off-network link using the access link capability)
- TE topology has network specific details... (please refine this comment)
- Augmenting grouping → container similar to TAPI
- TE topology has connection capability for the node using the connectivity matrix which is equivalent node/link capability
- TE topology is mainly augmenting properties on Topology entities
- MDA RFC8... (need number)
- "Everything" is writeable in the model
- Nodes and Links should be created via intent in terms of constraints
- It would appear that the projected view of the network can be changed in violation of the actual network capability. There are two behaviours to deal with this:
- The provide rejects the change (violating the writeable statement)
- The provider allows the delete and then immediately reproduces the deleted thing
- By default, almost all writeable things are actually read only by security
- It would seem that the correct approach to operation would be for the client to request via "intent" and the provider to state what has been achieved
- It was agreed that we would proceed with the work to convert TAPI to a model that augments IETF RFC8345 as as shown in the slide 24 with some enhancements.
- It was agreed that TAPI would be broken down into smaller (meaningful) modules
- There was some concern over lack of backward compatibility due to name changes etc. as TAPI would move to RFC8345 entity names.
We use this session to go over the RFC8345 presentation from the previous session (otcc2019.ssl.001.TAPI and RFC8345 Network Topologies.pptx)
- Probably not covering ring protection due to complexity
- Forwarding route definition caused some concern but these concerns were parked to allow the presentation to continue
- Considering options for specifying routes, it was recognised that protection may be added to an existing connection where the protection was added in fragments.
- Discussed the challenge of lifecycle where the whole connection is built unprotected and then protection is added over some "arbitrary span". The aim would be not to have to restate how the route is represented
- It was emphasized that it is the switch ports that carry the priority (this is actually mapped to the FcPort with the assumption that even when there are several switches, it is the priority for the ports of the connection that are relevant).
- It was suggested that the XC assembly alone can be used to fully define the installed structure in a protection case. The routes are emergent from this.
- Discussed maintenance as a reason to select a route and concluded that it is a reason to exclude a resources (by shutting down or costing out) which will consequently
- cause switches to change the route for a protection solution (where the shutting down causes priorities of switch ports to change)
- cause routers to find alternatives in packet systems
- Where traffic is still on a resource that is costed out or shutting down after some period of time then there is an issue that may need to be dealt with
- It was also noted that in some cases further capacity may be put in place to allow moved "services" to be necessarily resilient
- oimt2019.WC.001.00_SD-WAN Requirements and Architecture -V1.pptx
- Converge solutions across various access capabilities and across different regional operations
- Enterprise customers are constructing their own SD-WAN solutions
- CPE vendor variety degrades the opportunity to provide uniform and consistent services across the entire network
- There needs to be a strong interface between the controller and the box so as to allow multiple vendors in a consistent way
- Need to examine each of the listed technologies to determine what we can do which could be:
- Extract from existing model (e.g., OpenConfig)
- Collaborate with another body
- Do ourselves
- A challenge is integration with existing systems where the approach may be
- Need to balance Core and TAPI work where TAPI should focus on the urgency and core should focus on the strategy
- Some core work may move to TAPI
- Key is to provide a framework structure (based upon the core model) that can be augmented to combine all the different technologies into one system
- China Mobile see the CIM as a good basis for this
- We need a guideline for how others should use the model
- The model modularization is also key here
- Nigel Davis Hing-Kam Lam Develop plan for developing guideline for framework to enable others to augment and develop the model
- oimt2019.AM.001_TAPI PhotonicConnectivityModel.pptx
- There is distinction between MC and OTSiMC; MC has a filter, OTSiMC is the intent of the spectrum used by an OTSi.
- MCA is a group of MCs + OAM
- OTSMCA is a group of MCs supporting an OTS
- OMSMCA is a group of MCs supporting an OMS
- OTSiAMCA is a group of MCs supporting an OTSiA
- In ITU-T, there is no more the terms OMS link and OTS link. There are two MCAs, one for C-band, one for L-band.
- OMS Link is 1-1 to the strand
- PHY NEP
- Stephane's photonic service slide deck
- referenced slide are from V15, Photonic Model V15.pptx
- p-nep: Parent NEP
- c-nep: Child NEP
- a-nep: Assembly NEP
- Current TAPI doesn't allow 2 c-CEPs associate with 1 p-NEP (as shown in the left figure). Should be as the right figure.
- There are slides in the Photonic Model V15 that show those relation. see page 25, 28
- Service request/creation
- Nigel Davis Write the rules for service dependency (e.g., VC12 auto create VC4 v VC4 precreated, equipment inserted in slot autoconfigures slot the does not deconfigure when removed). Show dependency graph of constraints.
We use this session to continue the Photonic discussion.
To follow up on the Aug. 8 OIMT call action items for relevant material to liaise to MEF.
- Chris Hartley Provide initial draft of a spontaneous liaison to MEF, taking input from the material forwarded from Malcolm.
- Hing-Kam Lam Formulate the final liaison statement for review and transmital.
It is likely that we will focus more on TAPI than the Core.
There are two documents for the meeting:
- Core: oimt.2019.ND.016.00-StreamingDiscussion.pptx
- Nigel Davis Change the class name "StreamSource" to "StreamHandler".
- Nigel Davis Find a better name for the association "GetNext"
- Nigel Davis The multiplicity of the blue associations should be * on both ends of the association. Correction should be made for the blue assocations of Filter, Log, and LogStreamControl.
- Nigel Davis The multiplicity of the association between Log and StreamSource need to be corrected.
- Nigel Davis Administration of creating Filter, Operation of subscribing to Filter
- StreamHandler pulls content from the Log and push the content to the client.
- In slide #3 of the summary slide deck, improve the word "Connection", which means streaming connection
- Should allow (be able) to create/define a context for things that do not exist yet, e.g., planning
- Order preservation should be entity-wise.
- Nigel Davis Put the rules down for the order of events of an entity (single entity)
- Alarm correlation system should be able to deal with out-of-order events
- Nigel Davis Explore tombstone of delta (e.g., attribute) change of entity
- Tombstone only has the entity id and no other information. The Kafka community recognized that this needs to be corrected.
- Nigel Davis Swarp the words "left" and "right" in the three bullets below the figure in Appendix I
- Nigel Davis Should ask Stephane for the gRPC filter configuration reference
- Nigel Davis Improvement the alignment of the names between the TAPI Streaming document diagrams and the Core Streaming model diagram.
- Nigel Davis Provide a simplifierd version of Message Sequence diagram showing just the essential flows.
- Nigel Davis Create separate diagrams to shown the essential flows for each of the use cases
I am intending to do a demo of compaction during the meeting.
Demo deferred to later.
- Will do the demo on Thursday Lunch session
Chris walked throug the initial drafts of TR-512.15, TR-512.A.14, and TR-512.16.
The version being shown are in GenDoc form. MS Word form will be generated for review.
- Nigel Davis Take the GenDoc of TR-512.15 and TR-512.A.14 from Chris and geneate the MS Word documents
- TR-512.15 Storage
- LUN definition
- Storage option
- Why no File System for the SAN option, is the shim in the Block Storage or Network
- Decoupling of physical from logical, contigueous means logical contigueous.
- Partitioning & Aggregation: block not shown
- TR-512.A.14 Storage Examples
- T.39 Event driven architecture
Also slides 2-4 in oimt.2019.ND.011.00_ProfilesAndTemplates.pptx
And slide 5 (and slides 2-4) in oimt.2019.ND.013.00_ProfilesAndTemplates.pptx
I have also made some comments on the Party model at Comments on Party and Location model at Comments on Location
|ONF Connect ODTN & TAPI session|
|4.4||https://wiki.opennetworking.org/download/attachments/266141701/ONF_Txx_ConnectorPinStrand.pptx?api=v2||ONF Connect ODTN & TAPI session |
Brainstorm on forward looking topics
Review work item