Subject: [Srcomp] 2020-11-02 Meeting Minutes

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 2 Nov 2020 14:40:12 +0000

Attendees: Weiqiang, Wim, Chongfeng, Ron, Cheng, Darren, PSF

Agenda:

  1.  How do we use the next two weeks (4 meetings)
     *   4.1.1, 4.1.2, 4.1.5
     *   4.3 needs review
     *   Suggestions were provided via email on how to proceed
        *   Weiqiang proposes we close 4.1.x before bringing to the Working Group.
        *   8 members may be able to come to a solution easier than the full WG.
        *   Suggest more discussion to look for a compromise would be best for team, WG, industry.
     *   Team members suggestions
        *   Ron
           *   OK provided we are transparent with the working group
        *   Darren
           *   Close 4.3 sooner, and close 4.1.1, 4.1.2, 4.1.5 Wednesday.
        *   Cheng Li
           *   Close 4.3 first, get more complete where we can.
        *   Chongfeng
           *   Hope to accelerate requirement draft and get stable requirements
           *   Have deployed SRv6 and support 4.1.1, 4.1.2, 4.1.5 and wants to remain neutral to allow other solutions.
           *   Need to be transparent to the WG.
        *   Wim
           *   Complete other sections then come back to 4.1.1, 4.1.2, 4.1.5
           *   Could use WG meeting to present the different view points and try to get a sense on how WG sees it.
           *   This is still a draft, and no matter what is in it the WG will give input.
        *   PSF
           *   Agree with Wim
        *   Weiqiang
           *   Go to 4.3 first and then come back to other sections
           *   3 meetings to review the items
           *   1 meeting to talk about presentation and information to share
     *   DT agreed on Weiqiang’s summary
     *   Start review and closure of Scalability requirements.  Notes captured below and stored in github<https://github.com/IETF-srcomp/drafts/blob/main/req-backlog/draft-srcompdt-req-backlog-01.txt>.

Notes 2020-11-2:

  *   No overlap between LINK-SCALE and LINKNODE-SCALE
  *   Add definition of link.
  *   Do we mean adjacency or physical link?
     *   We mean adjacency
  *   LINK-SCALE appears to be the correct value 16bit (65k)
     *   Description: Change "must have the capability to support 65,536 (16bit) adjacency segments per node"
     *   Title: Adjacency Scale
     *   Rationale: Some network operators configure nodes to advertise up to 65000 adjacency segments.
     *   Metric: A proposal that allows 16 bits for adjacency segments satisfies this requirement.
  *   NODE-SCALE
     *   Team to consider below and provide text proposals.
     *   Proposal - clone text from 1.2.1 and change adjacency to node.
        *   in description…
        *   s/topology/IGP domain/
        *   s/topology/controller domain/
        *   TBD
     *   s/topology/domain/
     *   Weiqiang: Largest provinces have 150k nodes in 4G network. All nodes share the same network mgmt system.
        *   This is deployed with "static" routing via a centralized controller
        *   We should have a compression solution that supports such scale.
     *   Keep 65k in a single ISIS/hierarchy
        *   But to support Weiqiang's use maybe we can require greater
        *   Shall we call out the non-typical case of millions of nodes in a domain?
        *   Should we require 20 bits, or 1 million, nodes in a domain?
     *   Chongfeng
        *   It is possible that the whole national network is a domain, do we need to consider population or endpoints?
        *   Should the compression solution be able to identify such endpoints?
     *   Many cases to consider!
  *   LINKNODE-SCALE appears to be valid too
     *   Not discussed in detail