Child pages
  • Agenda plan for 2019 September 9-13 OIMT & OTCC Silicon Valley Meeting

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Core model key topics
    • C1 Review TR-512 documents on Party model & Location model (Nigel)
    • C2 Review of Lifecycle state (Malcolm)
    • C3 Review draft TR-512 document on Storage + CPU / Memory model (Chris) and Ethernet examples slides for possible updates of TR-512.A.6 (Chris)
    • C4 Discuss application of occurrence pattern (Nigel)
    • C5 Discuss Connector/pin/strand proposal slides vs existing model (Chris/Nigel)
    • C6 Discuss Expected equipment proposal slides from Chris and compare with existing model (Chris/Nigel)
    • C7 Review Profiles and Templates in general and discuss with respect to Wireless Transport application (Chris/Nigel)
    • C8 Discuss model extension guidelines (Chris/Nigel)
    • C9 Propose Streaming - Events - Telemetry - Cloud Native - Micro-services (Nigel)
    • C10 Discuss representation of Config vs Operational State (Chris/Nigel)
    • C11 SD-WAN IM & Interface
  • TAPI key topics (see TAPI roadmap for the leads)
    • T1 Topology enhancement 
    • T2 Connectivity 
    • T3 Resilience 
    • T4 Notification/Streaming 
    • T5 Photonic Enhancement 
    • T6 Routing constraint 

Agenda plan

DayPeriodTopic (Lead & Work Item)

Document / Link / Notes

Comment

Monday

9th

1.1
  • otcc2019.XYB.001.TAPI_for_Transport_NBI.pptx
    • 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.
  • https://wiki.opennetworking.org/download/attachments/259719184/otcc2019.AM.004-Partitioning_Abstraction.pptx?api=v2
  • otcc2019.SSL.001.TAPI and RFC8345 Network Topologies.pptx
    • Noted
      • 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:
        1. The provide rejects the change (violating the writeable statement)
        2. 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
    • https://wiki.opennetworking.org/download/attachments/259719184/TAPI%20Topology%20at%20ONF%20Connect%202019.pptx?api=v2
      • 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.

1.2

Deferred.

We use this session to go over the RFC8345 presentation from the previous session (otcc2019.ssl.001.TAPI and RFC8345 Network Topologies.pptx)


1.L

1.3


  • otcc2019.AM.004-Resiliency.pptx
  • Notes
    • 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


1.4


1.5
  • 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
    • Build on
    • Work around
  • 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

Tuesday

10th

2.1
  • 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
    • Image ModifiedImage Modified
    • 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.

2.2

Deferred.

We use this session to continue the Photonic discussion.


2.L

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.

2.3

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.
  • TAPI:
    •  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

2.4

Wednesday

11th

3.1

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:
      • unit or number?
    • 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
  • TR-512.16 CPU & Memory

http://verraes.net/2019/05/ddd-msg-arch/

  • T.39 Event driven architecture

3.2

oimt.2019.ND.019.00-Occurrence.pptx

    • FC spec, LTP spec,
    •  Nigel DavisSpin through a few cycles of recusion of the LTP spec & FC spec to understand how close to convergence
    •  Nigel Davis Build out a library of the re-usable parts

3.3

https://wiki.opennetworking.org/download/attachments/266141701/ONF_Txx_ExpectedEquipment.pptx?api=v2

  • Can we preconfigure a slot before a card is inserted in the slot? Configure the image of the card.
  • UML diagram Image Added
    •  Nigel Davis Replace the Connector to be ExpectedConnector and ActualConnector
    •  Nigel Davis Correct multiplicity: ExpectedHolder * — HolderHasExpectationConstraint — 1 Holder
    •  Nigel Davis Expected Equipment is driven by functional intension. The functional intension could be hard.
    •  Nigel Davis Need a model to link the intented function to the expected equipment.
    •  Nigel Davis Need a rule that says you cannot have a equipment without an expected and without an actual equipment.

https://wiki.opennetworking.org/download/attachments/266141701/ONF_T63s_EthernetExamples.pptx?api=v2

  • Slide 6: LTP diagram okay
  • Slide 8: Mac address is not state
    • Image Added
  • Slide 42:
    • Image Added
  • Layering of Technology Extension from the Core model
    • Image Added
      •  Nigel DavisHing-Kam Lam Need to determine where the applications are. TAPI? O-RAN? else?; In each of which, which bit of the information is usaul? Are there any properties that are not usable? Profile driven.
      •  Nigel Davis Hing-Kam Lam N & K approach WT, O-RAN, and TAPI to determine whicb of Chris's approach is critical,

3.4

https://wiki.opennetworking.org/download/attachments/266141701/ONF_T57_Profile_Template.pptx?api=v2

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

  • Potential requirement: Provide constraint on a set of attributes
  • Image Added
  • Need to also consider the spec/definition for the type of the instance.
  • Need to look at precedence
  • Need to draw table of "presence" each aspect of the property (config, default etc.)
  • Should also reintroduce the idea of tool generate properties (base concept of counter causes generation of all possible threshold attributes etc.)
  • Need to consider Log for immutables and current state for mutablesz
  • Need to be able to trace to the profile instance that is used to instantiate the subject instance. May need an attribute in the object class definition to have an attribute to indicate the profile that is used.
  • Immutable/Versioned: Template, Profile, Class (?), Insance
  • Consider applying the concept of streaming to the implementation of template/profile
  • Instance v class needs to be accounted for in the table


Thursday

12th

4.1
https://wiki.opennetworking.org/download/attachments/266141701/ONF_T61_ModelExtensions.pptx?api=v2
4.2
https://wiki.opennetworking.org/download/attachments/266141701/oimt2019.MB.002.02-draft-TR-512.3_v1.5.d03.docx?api=v2
4.L


4.3

oimt.2019.ND.014.00_TR-512.13_OnfCoreIm-Party.docx

oimt.2019.ND.015.00_TR-512.14_OnfCoreIm-Location.docx

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=v2ONF Connect ODTN & TAPI session

Friday

13th

5.1

Brainstorm on forward looking topics



5.2

Review work item