Questions for discussion: 

                          1. Domain name for statistics collecting server. 

                          2. Resources to deploy the server.

                       Source code:



  • Action items
    • Convert 5.1 blog announcement to release notes: Darien Hirotsuwill take this over from VM (Vicky) Brasseur (she/her)
    • Tabling the question of TPC IP address; will be handled otherwise
    • Deferring all Sukhdev items (he's traveling)
  • Frederick Kautz: Network Service Mesh + TF
    • Has been speaking with Will & Sukhdev (started in KubeCon EU 2019)
    • Presenting slides (will send to Casey to get attached to the minutes)
    • Problems solved by NSW
      • network service discovery & connection discovery
      • controller of controllers (even across organizations)
    • 3 primitives: client, network service, connection
    • Consumers: Want to request a service (for instance, a pod in k8s)
    • Operator gets to define what that service is
      • Basic service function chaining but enforced by policy & defined in a declarative way
    • CNF/VNF vendor gets to declare both the connection mechanism and payload; clear contract
    • Apply concepts from L4-L7 to L2 & L3
    • No need to define IPs, routes, subnets and the like since they're all negotiated as needed
    • Can swap out the data plane easily as long as there's something that knows how to do the conversion
    • Have a reference architecture based on VPP but looking to add different data planes
    • Instantiation of the interface is when the interface is requested
      • Could be during pod creation, or in middle of pod's lifecycle
      • Can create on the fly
    • Security?
      • NSM is looking into a security path now by way of Spiffe and Spire
        • Each connection has a cryptographically secured identity
      • RLB: Security policy…? TF has good and flexible security policy handling (matches well in k8s world). Can TF add value to NSM here?
        • Dynamically take an intent-based policy and apply to the dynamically-instantiated interface?
      • NSM current is focusing on identity
        • These policies don't live in the data plane 
        • NSM having no control over what goes over the wire
        • TF could be valuable for this
        • Would rely on TF (or whatever) to pull identity policies
    • Come see #nsm channel on
  • Deprecation policy review
  • CoC
  • Usage reporting client
    • Server that gets the stats from the container?
      • Opt-in, anonymous usage reporting
    • Can we get a server from LF?
  • TF CI design & improvements doc
    • All the things that were done and are planning to do for the CI migration
    • The alignment between Juniper and the TF community
    • Increase test coverage & speed of tests, plus integrating pieces into the CI that never have been (tf-devenv, for example)
    • We'll be moving this to the wiki (probably)
    • Folks, please review this. Will review in ~2 weeks
  • Who's running the TC calls?
    • VMB suggested Prabhjot Singh Sethi
    • No blueprints to review yet, but he'll take on running the meeting
  • Dockerhub access, who should have it?
    • Docker Hub Account Management
    • Idea: 2 types of access
      • Owners
      • Builders
    • Currently 5 people as Owners
    • No builders yet (will be for automation & release management)
      • Zuul, release manager
    • Owners can manage everything, builders will have limited access to pull/push to existing container repos
    • Is this OK so far?
    • RLB: Down side to having more owners?
      • None, as long as owners take responsibilities
      • RLB: Just map it to the TSC
  • ONS EU Demos
    • Proposals due by the end of the month
    • Get on this
  • ATT docs contributions
    • Abhijit isn't here, Rudra will pick this up

Action items