You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Attendees:

Please add your name in here:

  1. Mark Shostak (AT&T)
  2. Pankaj Goyal (AT&T)
  3. Kelvin Edmison (Nokia)
  4. Al Morton  (AT&T)
  5. Karine Sevilla (Orange)
  6. Ulrich Kleber (Huawei)
  7. Petar Torre (Intel)

Special Notes:

  • Each of the three RM sections will get 20 minutes
  • Given the limited time available, we will focus on identifying issues/actions/next steps, but not solving them right now
  • Weekly RM meetings are intended to
    • Identify owners for new Issues
    • Track open Issues
    • Address technical issues that cannot be resolved online (i.e. resolve stalls)

Agenda:


  • RM Core (status) (Mark S.)
    • Introducing CNTT networking initiative
      • For overview, read and comment at: \[RM] Networking Strategy #960 https://github.com/cntt-n/CNTT/issues/960 ]
      • Schedule meeting time for topic // action to publish announcement to mailing list
      • Start w/ Objectives, Strategy and Requirements
      • Programmable Fabric and Open APIs at all levels
    • VNF Evolution & VNF Profiles - the next chapter
      • Major progress: Have decomposed the "problem" into the questions list below
      • Summary: VNF Evolution will be based on the CNTT rls # and driven through VNF Profiles
      • To-do: Close the following questions, including technical and policy related (language for each bullet needs to be refined and fleshed out)

        1. In an OpenStack environment, what is the best way to schedule workloads against the correct variant (i.e. revision) of a flavor when using the Compute API? In other words, if there are multiple variants for a given flavor, such as version 1, ver 2, ver 3, etc., what is the best way to utilize the Compute API to instantiate the correct variant for a workload. Two examples are provided, but we are open to other options:

          a. Create a new flavor every time a new version of a profile is needed, then overload the flavor’s name w/ the variant. For example, Basic_v1, Basic_v2, etc. API calls would populate flavorRef = Basic_v2, etc.

          b. Have a single, static, base flavor name (e.g., Basic), and use a scheduler_hint parameter to identify the variant. In this scenario, API calls would populate flavorRef = Basic, and populate os:scheduler_hints = v2

          c. Other ideas?


        2. \[CLOSED] Should profile variant identifiers, which are simply integers, potentially w/ a “v” prefix (e.g., v1, v2, v3, etc.), be kept in lock step w/ CNTT release numbers? For example, profile variants in CNTT Rls n, would all be variant n. When a new CNTT release is produced, all profile variants will increment to stay aligned w/ the overall rls number. This includes releases where there are no changes to the variants – when the CNTT rls number changes, so does the profile variant identifier associated with that release.
          1. What are the drawbacks to this methodology?
          2. What happens if a new CNTT rls comes out and there are no changes to the profile? Do we increment the variant anyway, just to keep it in sync w/ the CNTT rls?

          3. CONCLUSION: We will synchronize the variant numbers w/ the CNTT release number for the time being. We can revisit this policy n the future, if needed.  

        3. How are Infra upgrades to be implemented and supported? We propose a make-before-break approach, where upgraded nodes are added to the Infra when convenient, and workloads are cutover to the new Infra once they’re certified or replaced with VNFs that are certified for the new profile variant
        4. What is forward compatibility directive (policy/strategy) for CNTT? // refer RM team's proposal to TSC/Gov for ratification
        5. What is backwards compatibility directive (policy/strategy) for CNTT? // refer RM team's proposal to TSC/Gov for ratification



  • Open questions
    • TBD


  • New Business

Actions:

  • General
    • None at this time
  •  Core
    • None at this time
  • Ops
    • None at this time
  • Comp
    • None at this time

Minutes:

  • General
    • Reviewed LNF/GSMA anti-trust policy
  •  Core
    1. TBD
  • Ops
    • TBD
  • Comp
    • TBD


  • No labels