[mpls] MPLS/PCE/TEAS YANG meeting minutes available

Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com> Tue, 26 July 2016 13:31 UTC

Return-Path: <Jonathan.Hardwick@metaswitch.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4F312DAB4; Tue, 26 Jul 2016 06:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMGPcKJEkHCS; Tue, 26 Jul 2016 06:31:05 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0124.outbound.protection.outlook.com [104.47.34.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4600412DC7D; Tue, 26 Jul 2016 06:14:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jFYyhf3oaw65U0f8YqTNmnj2ABeQpoU5/dMoKy5flPg=; b=rDBGVxw4KmDlRpZvtJ1D1hoJLL0jsj/wIs2MiH6YmhqsM05s1ytJJzui6umvZJE1CJvOXikfxTBFvgKiM36Nw19CfMWns4zTC/JVKmCTE6Ilb552IydlSvX7ChNCOxk38RNr3rwuLsH9TqqNryye1grJDkipQ1WI/Z0NDnrEiDA=
Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1909.namprd02.prod.outlook.com (10.163.75.151) with Microsoft SMTP Server (TLS) id 15.1.528.16; Tue, 26 Jul 2016 13:14:47 +0000
Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0528.017; Tue, 26 Jul 2016 13:14:47 +0000
From: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
To: "mpls@ietf.org" <mpls@ietf.org>, "pce@ietf.org" <pce@ietf.org>, "TEAS WG (teas@ietf.org)" <teas@ietf.org>
Thread-Topic: MPLS/PCE/TEAS YANG meeting minutes available
Thread-Index: AdHnP0O3t+zic4iEQxet5W8fSbNGgg==
Date: Tue, 26 Jul 2016 13:14:47 +0000
Message-ID: <BY2PR0201MB1910DD268B9AFE84EDDC2A38840E0@BY2PR0201MB1910.namprd02.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com;
x-originating-ip: [81.132.85.254]
x-ms-office365-filtering-correlation-id: d9cca83d-dbfa-48f7-ee10-08d3b556d170
x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1909; 6:i9tNxUn+DGw8Lsj+y5rXGt2aqMr/FJ17Sm3TmIUoI+CbsnmSmim3JdE0b5i+aV6OGYvEyfZL4og7j+Xmpm6cy7DzU8vm+sbogiK6DUiQBJs3uq+fUiHMD1ycTpnWCwwgbRvufrmFl22CJu2RZ25SylZfIsSxLwaD8l9ZoKewTjAgHitzrsLP5hAyoG1R5/FEF8Dl6y+CPhhioxBkRtgsn6eDDVYLQ7dsYn6I+DPm7D7RWxZjHyj+lMagx+6NA/AGW5vULtd95kxhS7mOXAcHaDle2Ce2Y91b1fBhO2T/BsE=; 5:y3oxnP09KkMyx++9rdS/N/XIORo5k3k4qWftN1LpQh88blnhLzQdOdTwJy8+g/vmMRF8uwJEgAMWCnWx2RedFdnx7KHZRs4+B3aYhjkBqDsu9sxaVrSA/Kzg+0EHKXD6Q+26LCfKT9NFExiNFZUXDA==; 24:52EnjYhBmL/PeYSFMrdha4w3Ubsn8LHElGcFedT0/AM6NK3L3+UDtThzDWlm/jps/24hyozvKwtMpHL6aiKxdzBElIPgxKzzlFO0bJHj6j0=; 7:7EGh14/XHRKS61/hLeCWd7jl0BHQmTEUaS3PIzFkeH6kvqbPtid7130Eus0ZTBLeTRK+Sbv/CqNxQ1lrblAasJ7ponT81j6IMbdk7Rw+P+mNKB/pWSUZl3I/z+LrKLaawaflI4sQ1AzajetWSe51FoHW+e/xyANkajmD7wg2UJJetwIWgqzzJUUNQH3OyJKdT7GDixlKBJSyJpUdffSScCw0UxN6wzL/ZABKzZZ9OWZkb9PWzuGo7fEZBk36QE1/
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB1909;
x-microsoft-antispam-prvs: <BY2PR0201MB190909C12257AC1407C4A409840E0@BY2PR0201MB1909.namprd02.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(120809045254105)(100405760836317)(21748063052155)(21532816269658);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BY2PR0201MB1909; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1909;
x-forefront-prvs: 00159D1518
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(54164003)(189002)(57704003)(199003)(77096005)(5003600100003)(7906003)(74316002)(2900100001)(16236675004)(19617315012)(105586002)(15975445007)(86362001)(5002640100001)(3846002)(97736004)(66066001)(106356001)(122556002)(101416001)(99286002)(76576001)(4326007)(7696003)(5001770100001)(92566002)(7736002)(87936001)(81166006)(790700001)(7846002)(2501003)(81156014)(102836003)(6116002)(19300405004)(10400500002)(3280700002)(8676002)(586003)(9686002)(19580395003)(68736007)(19625215002)(2906002)(54356999)(3660700001)(11100500001)(229853001)(8936002)(450100001)(33656002)(189998001)(50986999)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1909; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB1910DD268B9AFE84EDDC2A38840E0BY2PR0201MB1910_"
MIME-Version: 1.0
X-OriginatorOrg: metaswitch.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 13:14:47.2623 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1909
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/oU8tiep04YvPr8NpVILwI2cDcbY>
Cc: "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>
Subject: [mpls] MPLS/PCE/TEAS YANG meeting minutes available
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2016 13:31:10 -0000

The draft minutes for the joint MPLS/PCE/TEAS YANG meeting at IETF 96 are now available.  Please see "session II" at the link below.  Thanks to all our minute takers!  Please let me know if you have any comments or corrections.
https://www.ietf.org/proceedings/96/minutes/minutes-96-pce

Best regards
Jon

-------------------------------------------------------------------------------
Session II
Joint YANG session with MPLS & TEAS & PCE

Time:
     July 21, 2016, 16:20-18:20 (4:20pm-6:20pm)

Location:
     Charlottenburg II/III, Intercontinental Berlin, Germany

-------------------------------------------------------------------------------

Last meeting co-chaired by Ross. Set of pictures of Ross sitting between Pavan
and Jon taken by Lou and George.

1. Introduction
---------------

1.1. Welcome, Administrivia, Agenda Bashing (chairs, 10 min) (16:20-16:30)


2. YANG models discussion
-------------------------

2.1 YANG Data Model for TE Topologies
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/
Xufeng Liu, 20 min (16:30-16:50)

Dhruv Dhody: Relationship with SR model?
XL: Types to be shared.
DD: Do we need RW on per-node attributes?
Tarek: There are cases where information is learned via IGP, but other cases
       where static may be supported, thus the need for RW
DD: What do we do on conflicts? TBD
Igor Bryskin: one of the clients (users?) wanted to do path computation based
              on TE information as well
Pavan: How many have read? Not so many. Please read and send comments to the
       list.


2.2 A YANG Data Model for Traffic Engineering Tunnels and Interfaces
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/
Tarek Saad, 20 min (16:50-17:10)

Lou Berger: Send that [option request] to Netmod.
Xian Zhang: No strong preference among options, but, do these options on tunnel
            model also apply to TE topology?
TS: I think you are actually asking about somthing that is derrived from
    routing config, which is also using  option #2 (schema mount).
LB: Routing config is using it, although the another wildcard form. logical
    element and network instance in the RTGWG are also using this form. This
    would be the 1st use of mounting a specific schema.
Loa Anderson: Issues to be fixed on valid ranges of label values.
TS: Ack
LA: Ambiguous names to be fixed on H-LSP part.
LB: What about Extension Labels (RFC7274)
TA: will need to consider.
DD: Be careful on artifical segmentation around PCC/PCE...
DD: The lsp-key is 5 tuple and it should support extensions towards other
    technologies, e.g., SR.
TA: Will have split P2P and P2MP LSPs so will have index within each (sub)
    trees
LA: ietf-te-yang inherits from 2 models; do we need to ensure special review
    for these cases?


2.3 A YANG Data Model for MPLS Static LSPs
https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/
Tarek Saad, 20 min (17:10-17:30)

Iftekar (Infinera): Who's taking care of switch over?
TS: Static configuration. Pre-programmed backups are possible. Behaviors widely
    depend on DP capabilities.
LB: What about OpenConfig's "applied state" discussion?
TS: No IETF consensus about its usage so far.
LB: Indeed, reco is not to jump to fast, too much error-prone.
TS: General consistency matters.
LB: From routing area discussion: use to be limited. View as author?
Pavan: Agreed on consistency, but eithier way is fine.
LB: Simplifying our models might be nice. Maybe we should ask the room.
Kamran Raza (Cisco): Should be consistent with MPLS document, some fallback
                     already happened.
XL: Not so much work. Structure to be simplified.
LA: Would it work if both simplified and more complicated module were pushed?
LB: Would work, but more implementation load.  2 different ways for every
    information element; Having just one way to access the information implies
    less code.
LB (chair hat on):
    How many care? <A decent number, but "not as many as expected">
    How many for simplified? <Almost the same>
    How many for OpenConfig approach with augmentation? <A small number>
    How many for OpenConfig as is? <One>


2.4 TEAS Transport Service Model
https://datatracker.ietf.org/doc/draft-zhang-teas-transport-service-model/
Xian Zhang, 15 min (17:30-17:45)

Tarek S: I don't understand what's missing from other modules for "step 1".
XZ: SB relies on PCEP, this is a service model.
Daniele Ceccareli: Is technology-specific only on tunnels or also at service
                   level?
XZ: A couple of attributes are relevant for services.
DC: OK, so both tunnels and service include technology-specific.
Anurag Sharma (Infinera): Commonalty with tunnel: required work?
XZ: Many things from tunnels turn optional/unnecessary.
Himanshu Shah: Would end up creating something covered by other service models.
George Swallow: There seem to be confusion. Service layer may be different from
                transport layer (e.g., Ethernet and OTN).
Jon: This document is about transport as a service, not end user service
HS: Need another document to connect all the dots
DC: We can have higher layer services on top of pipe as well as service filling
    in pipes. We don't have a common service model, like an umbrella.
XZ: We are looking at it differently, where we can have the ethernet or OTN
    service
DC: Any plans in mind to solve non-te services?
XZ: Plans only for transport/TE.
Igor Bryskin: There is no difference between transport or service so lets just
              use (existing) tunnel model
XZ: Indeed, difference is not clear.


2.5 PCEP YANG
https://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/
Dhruv Dhody, 15 min (17:45-18:00)

Jeff Tantsura: Key-chain is close to LC.

Julien: Who has read document? <Some>

    Who thinks it should be a WG document? <more!>

    Who thinks it shouldn't be a WG document? <none>

    Clear consensus in the room. Decision will be confirmed by a poll on the
    PCE list.


2.6 YANG Data Model for MPLS LDP and mLDP
https://datatracker.ietf.org/doc/draft-raza-mpls-ldp-mldp-yang/
Kamran Raza, 15 min (18:00-18:15)

No question


2.7 LSP-PING-YANG
https://tools.ietf.org/html/draft-zheng-mpls-lsp-ping-yang-cfg-03
Greg Mirsky (remaining time; started at 6:07)

Italo Busi: Are you including MEG, MEP, MIP, etc?
GM: LSP ping doesn't need those. No intention to introduce them there.
Zheng? (Huawei, co-author): Confirmed

<6:12 - Meeting adjourned>