[Teas] Minutes of 3272bis Design Team Meeting 2019-02-12

["Adrian Farrel" <[e-mail]>]

3272bis Design Team Meeting 2019-02-12

Webex meeting 9pm GMT

Attendees
    Acee Lindem
    Adrian Farrel
    Aijun Wang
    Dieter Beller
    Jeff Tantsura 
    Liu Hua (Autumn)
    Luis Miguel Contreras
    Martin Horneffer
    Tarek Saad
    Xufeng Liu
    Pavan Beeram (WG chair)
Apologies
    Daniele Ceccarelli
    Julien Meuric 
    Lou Berger (WG chair)

Purpose of meeting
    Level-set and work out what we're doing

Charter and Expectations
    The meeting reviewed how the plan to revise 3272 came about and
    looked at the DT charter. There were no issues.

    The question was raised about what should be done if problems 
    with other related documents were found. 
    It was agreed that *this* team is focused on revising 3272. If
    issues with other documents are found they should be raised to
    the TEAS WG. Anyone (including members of this DT) is free to
    work on revisions of other document. It seems likely that such
    revisions will be dependent on the changes made to 3272.

Background Reading
    Adrian highlighted several sources that may be useful to the DT:
    - https://datatracker.ietf.org/doc/rfc3272/  (obviously)
    - https://datatracker.ietf.org/doc/rfc2702/
      "Requirements for Traffic Engineering Over MPLS"
       - It is specific to MPLS, but pre-dates RFC 3272 by 2.5 years
    - https://datatracker.ietf.org/meeting/103/materials/slides-
                103-edu-sessk-an-ietf-traffic-engineering-overview
      "An IETF Traffic Engineering Overview"
      - A tutorial at IETF-103
      - It is quite high-level, but may trigger some thoughts
    - http://iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf
      "Modern Router Architecture (for protocol designers)" 
      - A bit old (2015) but important background for thinking about 
        how TE works
      - Will be updated as a tutorial at IETF-104

Agenda
    - What do you think of 3272?
    - At a high level, what should we do with 3272?
    - What technologies should we add to the draft?
    - How shall we go about the work?
    - When shall we meet next?    

What do we think of 3272?
    - All agreed that there had been a long gap since their previous
      reading and review for this work. It was felt that the basic
      principles had stood the test of time well, but that the 
      technical material was dated.
    Adrian: Too many words
    Adrian: Not concrete enough
    Adrian: Too much history
    Aijun: Section 4 is legacy (Tarek agrees)
    Tarek: It's comprehensive. Can we abbreviate and focus?
    Aijun: Terms and taxonomy don't need to be redefined
    Pavan: May need new terms
    Acee: Can it stand w/o section 4?
    Xufeng: history is useful but might make document too long
    Xufeng: document is missing design-time architecture
    Autumn: lacks focus; what is it trying to address? Avoid addressing
problems we already have solved.
    Dieter: Have the basic principles of TE changed? "no"
    Luis: More recent networks move to needing more dynamic TE
    Luis: Granularity has become much finer over the years

What should we do with 3272?
    Adrian floated four high-level options:
    1. Minor edits/sections to add new technologies
    2. All of 1. and fix text for modern thinking and practices
    3. All of 2. and major rework of all text
    4. Complete re-write from scratch

    Some time was spent understanding the difference between 3 and 4.
    The difference is that 4 starts with a blank sheet of paper and
    may borrow text from 3272, while 3 starts with 3272 and edits as
    needed.

    All agreed to attempt to do 3.

    Aijun raised some additional points about how we might approach
    the existing text:
    - May be able to re-use definition and scope
    - TE methodology and taxonomy could be simplified
    - Need to add scenarios for the application of TE
    - Set the purpose of the document that the user can find the right
      TE solution for their requirements
    - Include inter-domain

    Document structure:
    Tarek: Do we retain the structure or make a new ToC?
    Adrian: Start with current ToC
    Pavan/Acee: For each section work out what stays and what goes
    Acee: Current structure stays until we change it

What is the target length of the document?
    The meeting discussed readability and how long documents don't
    get read. We agreed that long documents are hard, but also that
    there is a lot of material to be covered.
    - RFC 3272 is already >70 pages
    - We agreed to try to target 50 pages, but understood that that 
      could be impossible
    Aijun: Just give the aims of each technology and point to other
           documents
    Pavan: Talk about paradigms and tools according to applications,
           but point out to other docs
    Adrian: If we identify a missing applicability statement, someone 
            else can write that in another doc, we don't have to 
            include it here
    Pavan: Aim for a shelf-life of 10 years

List some missing technologies
    We started a scratch list of technologies that need to be
    mentioned, but agreed to not attempt to make a complete list at
    this time:
      ECN
      AQM
      Multi-path TCP and QUIC
      PCE
      BGP-LS
      SR-TE
      SDN
      Virtual networks
      Telemetry
      DetNet
      Sub-IP
      performance measurement
      e2e path manipulation
      queue technology at the nodal level
      distributed protocols vs. north-south between device & controller

How shall we work?
    Agreed that phone meetings may not work well
    - Time zones a real challenge
    - Not a good use of time for a large meeting
    Should try to meet up in Prague
    Leaves email as the default

    Agreed to try to use github for our work
    - We will work on branches and get agreement / do merges before
      pushing to the main copy
    - Acee will set up the repository
    - Adrian will act as the editor/authoriser
    - We will try to work on small sections so as to not overlap
    - We will try to tell everyone which sections we plan to work on

Risks and Actions
    Risk: No one does anything: large team syndrome
          Addressed by "just getting on with it"
    Risk: We all over-write each other
          Addressed by github and communication
    Risk: Final document is too long.
          Addressed by concise writing and deleting unnecessary text
    Risk: Can we meet our dates? Target is adoptable draft at IETF-105
          Addressed by having *a* draft very soon even if lots of work 
          is still needed

    Action: Decide on markdown or XML
            Tarek likes markdown and has a sample he will share
    Action: Need a base document.
            Adrian to convert RFC to markdown or XML
    Action: Need github repository
            Acee will set up
    Action: Need minutes of our meeting.
            Adrian to send to DT and TEAS
    Action: Need to report in Prague.
            Adrian to prepare slides and send to DT nearer the time