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

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 13 February 2019 10:29 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E804312894E; Wed, 13 Feb 2019 02:29:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zykkjsxYicow; Wed, 13 Feb 2019 02:29:19 -0800 (PST)
Received: from mta5.iomartmail.com (mta5.iomartmail.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1A2124BAA; Wed, 13 Feb 2019 02:29:18 -0800 (PST)
Received: from vs3.iomartmail.com (vs3.iomartmail.com []) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1DATGPg026883; Wed, 13 Feb 2019 10:29:16 GMT
Received: from vs3.iomartmail.com (unknown []) by IMSVA (Postfix) with ESMTP id 7AC502203A; Wed, 13 Feb 2019 10:29:16 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown []) by vs3.iomartmail.com (Postfix) with ESMTPS id 65A8522032; Wed, 13 Feb 2019 10:29:16 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1DATF6B014979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 Feb 2019 10:29:15 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <teas-3272bis-design-team@ietf.org>
Cc: "'TEAS WG'" <teas@ietf.org>
Date: Wed, 13 Feb 2019 10:29:14 -0000
Organization: Old Dog Consulting
Message-ID: <00da01d4c386$f8316e10$e8944a30$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AdTDhvA5TqNuS0CeQNSrhZUKWUtAYQ==
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--17.076-10.0-31-10
X-imss-scan-details: No--17.076-10.0-31-10
X-TMASE-Result: 10--17.075700-10.000000
X-TMASE-MatchedRID: 1G/3DZEt2zETirVDGxl2AbsjNzpxvaQK4ceq9hWiO113ymYYvRV4qEMd kIpDjD61cX7Tn44mTpiK0wRUNixtE0a2DXGqwZmf4NAJeq9IDSze/DVpWKI5KzhgoAzehG32KDk R2MDyn9ysUL4SZCppCVnXvaC0RNMqJVWqk0NljVz9zT4slMys3bqGBW9J0Yqjut/GVGOoEneooS DAIqqmjq2+yqP54Zipc3cxZD41aLd4BX1/pVVpS/C1l8Gignpr3FYvKmZiVnOBLcV/MuE3xw1iN Q55bFRrm3pZQGWDxLLSSJDcAqmuMnMtRMwL8VEPXP5rFAucBUErHkgIan9a0ccUgRIkw68HyVBW 8fUk7pMLdyUejpd5yeiMueJjAsCV2feVev1q1MG8mw5HALM2ES3mEfGTTK17zOM3mJUmJl3jx8T o8gWyQH8DxHuaSOvpG5F59ZXzRJewGLdIYhMxRd35+5/2RxqmeJ1OirYwzANJJReS9JUB3G9Vua dbvLRcsMbP8kL7iRjxITo/xUIJE/EaWwu+jcuNwCZxkTHxccn8d3gJRYhL8bNTRH7kNsNsbwIuA yuB59zCJ49XrPlFan882byw79zmZLc0QItFlAlxgZi4qPpiYG73ma3jsPM2fmHrLgoJIlwyeD5b xJWRn7KvnIziwgE0s3r6Ur55N6cERznX5Usjmqb8GfRpncAzL34I8IpvQcILigFCwAAoVosONKr yt/2Bov9ufjtgWyWBG8dw1v3v6W+L3lQx0OQBu25wbZ2DWAOGLPZnwUyxvbWHBxDKp/ccnx4pQC K0LXfi8zVgXoAltlwtzewu2M633FYX00nSXLhIquHKOC7oobDszp3K5gqD9xS3mVzWUuAsVSKMb 3aZyQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/bBxGftGP9SJOaHChsEeDsHSvFnk>
Subject: [Teas] Minutes of 3272bis Design Team Meeting 2019-02-12
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Feb 2019 10:29:22 -0000

3272bis Design Team Meeting 2019-02-12

Webex meeting 9pm GMT

    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)
    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-
      "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

    - 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

    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
    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:
      Multi-path TCP and QUIC
      Virtual networks
      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