Work in progress..


Main points:

  1. VLs can be divided into logically separated sub-VLs (VLANs)
  2. The "trunk" VL and a "sub" VL would be represented with two nodes:
    1. Both of the onap.nodes.VL type
    2. The relationship between the two nodes is specified using the "division" capability/requirement pair, capability type onap.capabilities.VL.Division
  3. No need to introduce to the model the concept of a sub-CP. Linking a CP to a "sub" VL node is what makes the CP a "sub" CP


node_templates:
  vl_1:
    type: VL
    capabilities: # chesla added
      - divideable:
          capability: division
    
  sub_vl_1:
    type: VL
    requirements:
      - division:
          node: vl_1
          capability: division
          relationship: divides
          
  sub_vl_2:
    type: VL
    requirements:
      - division:
          node: vl_1
          capability: division
          relationship: divides 
  cp_1:
    type: CP
    requirements:
      - link:
          node: sub_vl_1
          capability: link
      - bind: 
        # bound to some node
          
  cp_2:
    type: CP
    requirements:
      - link:
          node: sub_vl_2 # Chesla changed this from sub_vl_1 to sub_vl_2
          capability: link
      - bind: 
        # bound to some node

  cp_P:  # Chesla = represents parent port?
    type: CP
    requirements:
      - link:
          node: vl_1
      - bind:
        # bound to some node and representing the physical port or vnic?
  • No labels

5 Comments

  1. Chesla Wechsler

    If a VNFC has a connection point, and that connection point references a port (e.g., vnic), and that port is subinterfaced, how is that represented, i.e., what object would that be and what would its relationship to the "parent" connection point be?

    So I get what you are suggesting, and if I'm following a service path through the resulting topology I can track from connection point to connection point via the virtual links.  What I'm not sure how to answer yet are questions such as the following: 

    • If cp_P (physical port) is messed up, what is affected?  Would I have to take find my linked VL, then figure out which sub VLs divided me? 

    1. Anatoly Katzman

      Thinking mechanically, if a VL connects CPs, then a sub-VL connects two "sub-CPs". Going on with this approach, we might want to model the parent CP and the sub-CP as two nodes, both of type CP, related through a specially introduced for these purposes "division" requirement/capability pair, add a special capability type onap.capabilities.CP.Division (similar to the one for VLs), etc., etc.

      And we still can do that. Maybe we even should. But the question is what's the extra value that we gain with this extra-detailed approach? The cost is obvious - more types to comprehend, more complicated model which invites more troubles (what if a parent CP gets linked to a sub-VL? what if sub-CPs are interconnected through a sub-VL while and their parent CPs  accidentally get interconnected through a VL which is not the parent of the sub-VL? Do we craft our types so that they prevent such integrity violations? Do we develop extra validation logic? Do we just trust the designer senses?)

      My assumption was that dividing VLs would be enough. If I am wrong, then yes, we may extend division to CPs too.

  2. Chris Lauwers

    The ONF Core Information Model handles this in a very elegant way. It models CPs (or "interfaces") as LogicalTerminationPoints. LogicalTerminationPoints can in turn be encapsulated in other LogicalTerminationPoints to model exactly the type of "sub-interfacing" that Chesla Wechsler is asking about. You can decide to model whatever level of detail is appropriate based on your orchestration needs.

    I've been meaning to work with Nigel Davis to create tooling to translate the ONF CIM into TOSCA node types (similar to how Project Eagle translated into YANG). Our plan is to start with a translation of the Component Pattern first (which maps extremely nicely onto TOSCA's substitution mapping paradigm) and then create CIM-based types as "specifications" of the types that are based on the Component Pattern. 

    1. Anatoly Katzman

      Very interesting idea. Do you have a link to a more detailed description of this solution?

      1. Chris Lauwers

        Which part of the solution are you interested in? The core information model is captured in:

        https://www.opennetworking.org/software-defined-standards/models-apis/

        That page also has information about the translation to YANG.

        I'm not sure if the Component/System work has been fully published yet, and the translation to TOSCA is still in early discussions.