From nobody Wed Dec 3 13:09:40 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41BA1A1EF0 for ; Wed, 3 Dec 2014 13:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 6k8jjdUX7y_h for ; Wed, 3 Dec 2014 13:09:22 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 90DB81A8727 for ; Wed, 3 Dec 2014 13:09:16 -0800 (PST) Received: (qmail 8238 invoked by uid 0); 3 Dec 2014 21:09:02 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 3 Dec 2014 21:09:02 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id P98z1p00M2SSUrH01992Eq; Wed, 03 Dec 2014 14:09:02 -0700 X-Authority-Analysis: v=2.1 cv=dfgTgxne c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=dnVcXgwgJT006LKN9p8A:9 a=Ztx-izuSjQf6F9eZ:21 a=eO9iTE163LBcfmPy:21 a=QEXdDO2ut3YA:10 a=k0LuJNu7CxwA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=PhgjQ58GhojiS4Shcg6Q88HKWTaKRumtFHfsbZMAfG4=; b=zNVdVCDrEOLro46ogNDEnt4iwLuBAOrE7OhmnwieDwKIAhiWOvV+45/W+wnuhdDhJ6rrdhpInJVG7LlM+f2LaWDGtiF4615VmYLikjyLgbnDdY+nSLWpSwMO4xSQcK2J; Received: from box313.bluehost.com ([69.89.31.113]:34073 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XwHAR-0002sm-3Y; Wed, 03 Dec 2014 14:08:59 -0700 Message-ID: <547F7BFE.2040705@labn.net> Date: Wed, 03 Dec 2014 16:09:18 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "rtg-yang-coord@ietf.org" , teas@ietf.org References: <20141203202653.18771.95322.idtracker@ietfa.amsl.com> In-Reply-To: <20141203202653.18771.95322.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141203202653.18771.95322.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/eE5fMML4cz0sNkVFuI7LmUm-lPw Cc: "BRUNGARD, DEBORAH A \(ATTLABS\)" Subject: [Teas] Fwd: CCAMP WG Virtual Interim Meeting: December 18, starting at 20:00 UTC X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 21:09:25 -0000 FYI - agenda is being worked and will be posted to both the CCAMP and TEAS lists. Please feel free to send us (me and Deborah) if you have an agenda request. -------- Original Message -------- Subject: CCAMP WG Virtual Interim Meeting: December 18, starting at 20:00 UTC Date: Wed, 03 Dec 2014 12:26:53 -0800 From: IESG Secretary Reply-To: ietf@ietf.org To: IETF Announcement List CC: ccamp@ietf.org TE Topology Yang Model Virtual Interim (CCAMP) There is a cluster of work around YANG models for topology and the TED (TE Topology Database). The Routing ADs are planning to have the TEAS working group formalized soon and the group is expected to have an explicit deliverable of a YANG model for the TED. We, the current CCAMP chairs, have been asked to get this effort moving by arranging a virtual interim meeting on the topic. The primary objectives of the meeting are to (a) get some basic agreement on TE topology model 'use cases' (e.g., driven by I2RS, PCE, ALTO, TEAS), (b) establish the dependencies/relationships of a TE topology model to other models (e.g., router, topology, routing protocols, ...) and finally, (c) to provide the needed foundation for a TEAS design team to be formed and deliver a TE Topology Yang Model draft by Dallas. A related activity has also started in the MPLS WG on a TE LSP Yang Model. This topic will *not* be the focus of this interim and we expect that work to continue concurrently. The Virtual interim is scheduled for 2-3 hours on December 18, starting at 20:00 UTC. The agenda and other logistic information for the meeting will be posted & discussed on the CCAMP and new TEAS mailing list (ccamp@ietf.org and teas@ietf.org). The existing set of related drafts includes: draft-liu-yang-abstract-te-topo draft-clemm-i2rs-yang-l3-topo draft-clemm-i2rs-yang-network-topo draft-amante-i2rs-topology-use-cases draft-chen-mpls-te-yang-cfg (LSP focused) draft-gandhi-mpls-te-yang-model (LSP focused) draft-ietf-netmod-routing-cfg (Foundational work, not topology specific) Deborah and Lou From nobody Thu Dec 4 09:50:17 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B41F1A1BB3 for ; Thu, 4 Dec 2014 09:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 CMneVacki9pi for ; Thu, 4 Dec 2014 09:50:12 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F421A1BAC for ; Thu, 4 Dec 2014 09:50:11 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB4Ho9Ya007529 for ; Thu, 4 Dec 2014 17:50:09 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB4Ho9HK007511 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 4 Dec 2014 17:50:09 GMT From: "Adrian Farrel" To: Date: Thu, 4 Dec 2014 17:50:04 -0000 Message-ID: <0fac01d00fea$bc6369a0$352a3ce0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAP6p2QU537oa3mSh+BgChmo5qpJQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21150.001 X-TM-AS-Result: No--1.466-10.0-31-10 X-imss-scan-details: No--1.466-10.0-31-10 X-TMASE-MatchedRID: L2gihrP87/hE6YjoR5i4+3S5xmwU5i7OEtdrY/Wb3fP1bGUO+1Pc3COf 6VnpNekd9GslsTFiZWBvcmY92rn2+U1+zyfzlN7y/sToY2qzpx5q8/xv2Um1avoLR4+zsDTt1MY I0Gm2di4U8AMSViQVDfLosnX1/X5735mJbcacojW1QQdLUpghM03+9BzFCkVzNAW83zYDw/v1Ol CIPxKfizngMRAgrdeEyfkWaeG5p9A= Archived-At: http://mailarchive.ietf.org/arch/msg/teas/e1oo5a5NH2AtB3N4RvWSewBks4A Subject: [Teas] Chartering approved X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 17:50:14 -0000 Hi, The IESG just approved the chartering of TEAS. As previously announced, Deborah and Lou will serve as chairs. Thanks to them for being willing. The IESG has also approved the rechartering of CCAMP, MPLS, and PCE in step with the creation of TEAS. Formal announcements of these changes will come out soon and I will be working with all of the chairs to ensure that documents are assigned to the right WGs and that milestones are posted. Adrian From nobody Thu Dec 4 14:58:19 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CDB1A871D for ; Thu, 4 Dec 2014 14:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 XGNcRhp8Pk9X for ; Thu, 4 Dec 2014 14:58:11 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id D5D6E1A86E0 for ; Thu, 4 Dec 2014 14:58:11 -0800 (PST) Received: (qmail 32057 invoked by uid 0); 4 Dec 2014 22:58:11 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 4 Dec 2014 22:58:11 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id Pay81p00u2SSUrH01ayBlP; Thu, 04 Dec 2014 15:58:11 -0700 X-Authority-Analysis: v=2.1 cv=dfgTgxne c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=FgF3-7Epf8XMPwykxwYA:9 a=wPNLvfGTeEIA:10 a=ytpu2zfS6uYA:10 a=5SWQHJI68BQA:10 a=41hXtTQAOwYA:10 a=6LUHSdp91MgA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=SFhaDufsAdPV5GJiag8BQMAghQzRZbH/MTTfUMSkp8o=; b=nPX27+IIkUErBR9g5YdGUvPM3U8qA8p9xqsBq6r9cvJHUtLLUKPp57psWQxdDhZZrI67jvnK/yFLOrS/mQwese+6ctHfFpy94fzKlx+95LGV6yK2NGLicCur0faBsYZF; Received: from box313.bluehost.com ([69.89.31.113]:33523 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XwfLb-00010h-Fq; Thu, 04 Dec 2014 15:58:08 -0700 Message-ID: <5480E712.4060003@labn.net> Date: Thu, 04 Dec 2014 17:58:26 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: TEAS WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/WFN-LLSd_e5NRo168WzJ6xHgmv4 Cc: "BRUNGARD, DEBORAH A \(ATTLABS\)" Subject: [Teas] Welcome & Related drafts in CCAMP WG LC X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 22:58:14 -0000 Hi, Welcome to the now official TEAS WG mail list. It'll take a short time, say up to a couple of weeks, to transition existing work from CCAMP and, to a lessor degree, MPLS. In the interim, please be aware that there are 3 TEAS Charter related documents completing LC in CCAMP. For details see the threads started at: http://www.ietf.org/mail-archive/web/ccamp/current/msg16758.html http://www.ietf.org/mail-archive/web/ccamp/current/msg16780.html http://www.ietf.org/mail-archive/web/ccamp/current/msg16781.html There is also one related adoption poll: http://www.ietf.org/mail-archive/web/ccamp/current/msg16777.html Comments during the LC / poll period should be made on the ccamp list (cc'ing teas is fine too). Lou (and Deborah) From nobody Fri Dec 5 07:41:40 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB0F1A899D; Fri, 5 Dec 2014 07:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 p-LGBbqS2MPg; Fri, 5 Dec 2014 07:34:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDB41ACEBE; Fri, 5 Dec 2014 07:34:53 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141205153453.32650.46273.idtracker@ietfa.amsl.com> Date: Fri, 05 Dec 2014 07:34:53 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/un4ZFy2Z-hCIvCqLsZZt2OiNOeE X-Mailman-Approved-At: Fri, 05 Dec 2014 07:41:29 -0800 Cc: teas WG Subject: [Teas] WG Action: Formed Traffic Engineering Architecture and Signaling (teas) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 15:34:58 -0000 A new IETF working group has been formed in the Routing Area. For additional information please contact the Area Directors or the WG Chairs. Traffic Engineering Architecture and Signaling (teas) ------------------------------------------------ Current Status: Proposed WG Chairs: Deborah Brungard Lou Berger Assigned Area Director: Adrian Farrel Mailing list Address: teas@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/teas Archive: http://www.ietf.org/mail-archive/web/teas/ Charter: The Traffic Engineering Architecture and Signaling (TEAS) Working Group is responsible for defining MPLS and GMPLS traffic engineering architecture, standardizing the RSVP-TE signaling protocol, and identifying required related control-protocol functions, i.e., routing and path computation element functions. Traffic Engineering (TE) is the term used to refer to techniques that enable operators to control how specific traffic flows are treated within their networks. TE is applied to packet networks via MPLS TE tunnels and LSPs. The MPLS-TE control plane was generalized to additionally support non-packet technologies via GMPLS. RSVP-TE is the signaling protocol used for both MPLS-TE and GMPLS. The TEAS WG is responsible for: a) Traffic-engineering architectures for generic applicability across packet and non-packet networks. This includes both networks that include the use of PCE and those that do not. The PCE architecture itself is out of the WG scope. b) Definition of protocol-independent metrics and parameters (measurement and/or service attributes) for describing links and tunnels/paths required for traffic engineering (and related routing, signaling and path computation). These will be developed in conjunction with requests and requirements from other WGs to ensure overall usefulness. c) Functional specification of extensions for routing (OSPF, ISIS) and for path computation (PCE) to provide general enablers of traffic-engineering systems that also use RSVP-TE. Protocol formats and procedures that embody these extensions will be done in coordination with the WGs supervising those protocols. d) Functional specification of generic (i.e., not data plane technology-specific) extensions for RSVP-TE, and the associated protocol formats and procedures that embody these extensions. e) Definition of control plane mechanisms and extensions to allow the setup and maintenance of TE paths and TE tunnels that span multiple domains and/or switching technologies, where a domain may be an IGP area, an Autonomous System, or any other region of topological visibility. f) Definition and extension of management and security techniques for RSVP-TE signaling. This includes configuring and monitoring RSVP-TE as well as mechanisms used to configure, control, and report OAM within TE networks. YANG and MIB modules may be considered. The TEAS working group is chartered to deliver the following: 1. Definition of additional abstract service, link, and path properties such as jitter, delay, and diversity. Extensions to IGPs to advertise these properties, and extensions to RSVP-TE to request and to accumulate these properties. Work with PCE WG to include these properties in computation requests. 2. Specification of terminology, architecture, and protocol requirements for abstraction and distribution of TE information between interconnected TE domains/layers. 3. Specification and protocol extensions for a GMPLS External Network-to-Network Interface (E-NNI), i.e., multi-domain GMPLS support. 4. Protocol mechanisms to signal associated LSPs in particular with different source nodes. 5. Requirements and protocol extensions for additional protection mechanisms including end-point protection, protection of P2MP LSPs, and inter-domain protection. 6. YANG models for a Traffic Engineering Database in coordination with working groups working on YANG models for network topology and for technology-specific network attributes. Requirements may be documented in stand-alone RFCs, may be folded into architecture or solutions RFCs, may be recorded on a wiki, or may be documented in an Internet-Draft that is not progressed to RFC. The TEAS WG will coordinate with the following working groups: - With the MPLS WG to maintain and extend MPLS-TE protocol mechanisms and to determine whether they should be generalized. - With the CCAMP WG to maintain and extend non-packet, data plane technology-specific TE protocol mechanisms and to determine whether they should be generalized. - With the OSPF and ISIS WGs to maintain or extend TE routing mechanisms for MPLS-TE and GMPLS. - With the PCE WG on uses of a PCE in the traffic-engineering architecture, on PCE extensions per the above, and on RSVP-TE extensions to support PCE WG identified requirements. - With the IDR WG on the use of BGP-LS in TE environments. In doing this work, the WG will cooperate with external SDOs (such as the ITU-T and the IEEE 802.1) as necessary. Milestones: TBD From nobody Fri Dec 5 07:49:44 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36011ACEDC; Fri, 5 Dec 2014 07:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 eXPaeyArvVju; Fri, 5 Dec 2014 07:49:38 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3801A1A0F; Fri, 5 Dec 2014 07:49:32 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB5FnBqu014628; Fri, 5 Dec 2014 15:49:11 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB5Fn8ov014615 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 15:49:08 GMT From: "Adrian Farrel" To: References: <20140908192308.6BD2B180015@rfc-editor.org> In-Reply-To: <20140908192308.6BD2B180015@rfc-editor.org> Date: Fri, 5 Dec 2014 15:49:02 -0000 Message-ID: <11ca01d010a2$fff2c130$ffd84390$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_11CB_01D010A2.FFF5CE70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG4SRPFXWGhuDh/2iDRqFsJvZBrd5ywq2Zg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21152.000 X-TM-AS-Result: No--14.089-10.0-31-10 X-imss-scan-details: No--14.089-10.0-31-10 X-TMASE-MatchedRID: Rp71wniPtoMwJ6xbTjBa5j24QfyP59+REQhmLSwsumrWgeiceig+bYjs z3Ta+/YE8p796sClznJgkuCSmHpeTLfptZTbFVSKl1zsjZ1/6aygD0t7xcmluv002DXYmoa1QLr Z4mdNKtWtcw7GcMT4xOzMxVgUVmx/iq265D4ITu9UdfWpvPVkNQGZ/+APXW9ks1NEfuQ2w2wygv vk2n2Dkc9fXdWbM+5n/du/64FUJjqnykMun0J1wu9VsdrlGzy3Q6/DFZugyt0wODfUl7mJKf4ZA Usty2ENqv6+7o00zYeLFgnz+hpr+XW0oJLOugKBj1RGQOB2Vvn9GaYSzB/sh6Jd7mc2dRi3oEoz raubH2nx6gF+AN4QjuBe5QRmIfivPwbcb/CNUOlwvDydhBUuyCAXLFyLhL5W5GdZsk1yqBcqoeX FMnt4lSJunynLhcivKEdCtwyfJsLWV8MKb34RlRZU/yoIC8o9JVsoL7U3JcDimKcLRvsB1UauzW hZogiAzkH/0tV77RAZttB2H+RMvyWvhQBtQUwTb/5HBZ6dvRh3Bf9JIqsoeA8YwboCQc88n0/rR Q9krRF9xQFIjQfO0oYCheGFuxsgL3m5ejCdaFGdCtkMrsOtOpkShYcLpGH9H06W6rwtvNULlTHL QDwoLbuwuIYnhcFSgDLqnrRlXrbVE7HmVnVGHv7E6GNqs6cesjvNV98mpPMD8pATt91pfuFzZRw dMo0L5h/zU3hLHs6IBKymqZqNp8DyhYqKEQgIxWCH9IQozrMqyguCp7MkCzpjCNjHFvGDAqkQfV EP3kc= Archived-At: http://mailarchive.ietf.org/arch/msg/teas/51HKOOigMC59IPosd-s-DZB5YXE Cc: ccamp@ietf.org, attila.takacs@ericsson.com, teas@ietf.org, akatlas@gmail.com, hejia@huawei.com, lberger@labn.net, don.fedyk@hp.com, dbrungard@att.com Subject: Re: [Teas] [Technical Errata Reported] RFC7260 (4106) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 15:49:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_11CB_01D010A2.FFF5CE70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Greg, I'm returning to this after an indecent interval. I checked with IANA and they are OK that we can make this sort of change with an Errata Report and they are happy. So now we have to agree what it should say. There is an error in your suggested change, I think because in the first table you show 65533 as IETF review, and in the second as reserved for experimentation. I am keen to make only the minimal changes to fix the obvious bugs. Therefore I think there is no need to reserve 65535 and it can remain as an experimental value. That leaves us with... IANA has created the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM Configuration Registry" as follows: Range | Note | Registration Procedures ------------+------------------------------|------------------------ 0-31 | Generic Sub-TLVs | IETF Review 32-65533 | Technology-specific Sub-TLVs | IETF Review 65534-65535 | Experimental Sub-TLVs | Reserved for | Experimental Use IANA has populated the registry as follows: Sub-TLV Type | Description | Reference -------------+-------------------------------+---------- 0 | Reserved | [RFC7260] 1 | OAM Function Flags Sub-TLV | [RFC7260] 2-65533 | Unassigned | 65534-65535 | Reserved for Experimental Use | [RFC7260] Is everyone OK with that change? Thanks, Adrian ------=_NextPart_000_11CB_01D010A2.FFF5CE70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

I'm = returning to this after an indecent interval.

 

I = checked with IANA and they are OK that we can make this sort of change = with an Errata Report and they are happy.

 

So now = we have to agree what it should say.

 

There = is an error in your suggested change, I think because in the first table = you show 65533 as IETF review, and in the second as reserved for = experimentation.

 

I am = keen to make only the minimal changes to fix the obvious bugs. Therefore = I think there is no need to reserve 65535 and it can remain as an = experimental value.

 

That = leaves us with...

 

    IANA has created = the "OAM Sub-TLVs" sub-registry of the "RSVP-TE = OAM

    Configuration = Registry" as follows:

=

    Range       | = Note       &nbs= p;            = ;     | Registration = Procedures

    = ------------+------------------------------|----------------------= --

    0-31        = | Generic Sub-TLVs       &nbs= p;     | IETF Review

   32-65533    | = Technology-specific Sub-TLVs | IETF Review

    65534-65535 | = Experimental Sub-TLVs        = | Reserved for

       &nbs= p;            = ;            =          &nbs= p;     |   Experimental = Use

    IANA has = populated the registry as follows:

=

       Sub-TLV Type | Description       &nbs= p;           | = Reference

       = -------------+-------------------------------+----------

       &nbs= p;   0        = | Reserved       &nbs= p;            = ;  | [RFC7260]

       &nbs= p;   1        = | OAM Function Flags Sub-TLV    | = [RFC7260]

       &nbs= p;   2-65533  = | Unassigned       &nbs= p;            = |

       = 65534-65535  | = Reserved for Experimental Use | [RFC7260]

 

Is = everyone OK with that change?

 

Thanks,

Adrian

------=_NextPart_000_11CB_01D010A2.FFF5CE70-- From nobody Fri Dec 5 08:02:36 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A511ACECD; Fri, 5 Dec 2014 08:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 kaP_Bg7UA_xs; Fri, 5 Dec 2014 08:02:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C395A1ACEC0; Fri, 5 Dec 2014 08:02:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141205160224.15830.11974.idtracker@ietfa.amsl.com> Date: Fri, 05 Dec 2014 08:02:24 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/EeGoTirVNpW_PDRz5pkEh809cc4 Cc: ccamp@ietf.org, teas@ietf.org Subject: [Teas] TEAS WG Virtual Interim Meeting: December 18, starting at 20:00 UTC (formerly CCAMP WG Virtual Interim) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 16:02:27 -0000 The previously announced TE Topology Yang Model Virtual Interim will be held as announced, but will be hosted by the new TEAS WG rather than the CCAMP WG. The original announcement is below. On Dec 3, 2014, at 12:26 PM, IESG Secretary wrote: > TE Topology Yang Model Virtual Interim (CCAMP) > > There is a cluster of work around YANG models for topology and the TED > (TE Topology Database). The Routing ADs are planning to have the TEAS > working group formalized soon and the group is expected to have an > explicit deliverable of a YANG model for the TED. We, the current > CCAMP chairs, have been asked to get this effort moving by arranging a > virtual interim meeting on the topic. > > The primary objectives of the meeting are to (a) get some basic > agreement on TE topology model 'use cases' (e.g., driven by I2RS, PCE, > ALTO, TEAS), (b) establish the dependencies/relationships of a TE > topology model to other models (e.g., router, topology, routing > protocols, ...) and finally, (c) to provide the needed foundation for > a TEAS design team to be formed and deliver a TE Topology Yang Model > draft by Dallas. > > A related activity has also started in the MPLS WG on a TE LSP Yang > Model. This topic will *not* be the focus of this interim and we > expect that work to continue concurrently. > > The Virtual interim is scheduled for 2-3 hours on December 18, > starting at 20:00 UTC. > > The agenda and other logistic information for the meeting will be > posted & discussed on the CCAMP and new TEAS mailing list > (ccamp@ietf.org and teas@ietf.org). > > The existing set of related drafts includes: > draft-liu-yang-abstract-te-topo > draft-clemm-i2rs-yang-l3-topo > draft-clemm-i2rs-yang-network-topo > draft-amante-i2rs-topology-use-cases > draft-chen-mpls-te-yang-cfg (LSP focused) > draft-gandhi-mpls-te-yang-model (LSP focused) > draft-ietf-netmod-routing-cfg (Foundational work, not topology > specific) > > Deborah and Lou > From nobody Fri Dec 5 12:31:27 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5181AD6CE; Fri, 5 Dec 2014 11:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 TstCyH9Nu2mm; Fri, 5 Dec 2014 11:49:17 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11851A008C; Fri, 5 Dec 2014 11:49:15 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-e9-54820c3ae03e Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 45.8F.04076.A3C02845; Fri, 5 Dec 2014 20:49:14 +0100 (CET) Received: from ESESSMB201.ericsson.se ([169.254.1.250]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 20:49:13 +0100 From: Attila Takacs To: "adrian@olddog.co.uk" , Gregory Mirsky Thread-Topic: [Technical Errata Reported] RFC7260 (4106) Thread-Index: AQHQEMSLyItfOS0YvEKmJXhRgrcACw== Date: Fri, 5 Dec 2014 19:49:13 +0000 Message-ID: References: <20140908192308.6BD2B180015@rfc-editor.org> <11ca01d010a2$fff2c130$ffd84390$@olddog.co.uk> In-Reply-To: <11ca01d010a2$fff2c130$ffd84390$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_D0A74BB53A5DBattilatakacsericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUyM+Jvja4VT1OIQV+3sMWPnhvMFp8eXmK2 eDLnBovF9p1LWCxaprxjtuhofsti0fpjB4sDu8fL/jmMHjtn3WX3aDnyltVjyZKfTB4fNjWz eazYvJIxgC2KyyYlNSezLLVI3y6BK2PDrttMBR96mSoOvJzO3sC48RNjFyMnh4SAicTzp++Y IGwxiQv31rN1MXJxCAkcYZR4/KKFHcJZzCgx5ccldpAqNgEDiQvNk5lBbBGBeIm5X56wgNjM ApOZJE6dUgOxhQXMJT4v28AGUWMhsf3ZNBYIW0+iZ+VSoG0cHCwCKhJ9/yVAwrxA5esvXAcb KSSQIXFh9zyw4zgFrCXWvpgMtpYR6Ljvp9YwQawSl7j1ZD7U0QISS/acZ4awRSVePv7HCmKL Aq2a9/AVG0RcSaJxyRNWiN4Yia2t1xkh9gpKnJz5hGUCo9gsJGNnISmbhaQMIq4jsWD3JzYI W1ti2cLXzDD2mQOPoXqtJd7feMWIrGYBI8cqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMDo P7jlt9UOxoPPHQ8xCnAwKvHwbpBvDBFiTSwrrsw9xCjNwaIkzrvw3LxgIYH0xJLU7NTUgtSi +KLSnNTiQ4xMHJxSDYwp4Wp2uvbs4jcNbulNXnh8wrJ1l1QPVcrLzHgb4zV1xu4T/97/kjl/ reBX7aczAU0vXolslbnb4RtnvXIJ8/Sf1v/XKC6dsCn4Z9lpy9oItcaCs82W26TNMp6lBN3Z caK2N+tkrMUe08ecbP//9nA/rljexcdy5NuL6hOJCal69n9CpV48kS1UYinOSDTUYi4qTgQA 9XStwt8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/teas/_Bz4ILKhnCcynZt3Xtd7gTkQpko X-Mailman-Approved-At: Fri, 05 Dec 2014 12:31:25 -0800 Cc: "ccamp@ietf.org" , "teas@ietf.org" , "akatlas@gmail.com" , "hejia@huawei.com" , "lberger@labn.net" , "don.fedyk@hp.com" , "dbrungard@att.com" Subject: Re: [Teas] [Technical Errata Reported] RFC7260 (4106) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 19:49:19 -0000 --_000_D0A74BB53A5DBattilatakacsericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian, Yes, I think we should do the simple fix as you have suggested. Thanks, Attila From: Adrian Farrel > Reply-To: Adrian Farrel > Date: Friday, December 5, 2014 at 7:49 AM To: Gregory Mirsky > Cc: "ccamp@ietf.org" >, "teas@ietf.org" >, Ericsson >, Don Fedyk >, "hejia@hu= awei.com" >, "akatlas@gmail.com" >, Berger Lou >, Deborah Brungard > Subject: RE: [Technical Errata Reported] RFC7260 (4106) Hi Greg, I'm returning to this after an indecent interval. I checked with IANA and they are OK that we can make this sort of change wi= th an Errata Report and they are happy. So now we have to agree what it should say. There is an error in your suggested change, I think because in the first ta= ble you show 65533 as IETF review, and in the second as reserved for experi= mentation. I am keen to make only the minimal changes to fix the obvious bugs. Therefo= re I think there is no need to reserve 65535 and it can remain as an experi= mental value. That leaves us with... IANA has created the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM Configuration Registry" as follows: Range | Note | Registration Procedures ------------+------------------------------|------------------------ 0-31 | Generic Sub-TLVs | IETF Review 32-65533 | Technology-specific Sub-TLVs | IETF Review 65534-65535 | Experimental Sub-TLVs | Reserved for | Experimental Use IANA has populated the registry as follows: Sub-TLV Type | Description | Reference -------------+-------------------------------+---------- 0 | Reserved | [RFC7260] 1 | OAM Function Flags Sub-TLV | [RFC7260] 2-65533 | Unassigned | 65534-65535 | Reserved for Experimental Use | [RFC7260] Is everyone OK with that change? Thanks, Adrian --_000_D0A74BB53A5DBattilatakacsericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Adrian,
Yes, I think we should do the simple fix as you have suggested.
Thanks,
Attila
From: Adrian Farrel <adrian@olddog.co.uk>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
Date: Friday, December 5, 2014 at 7= :49 AM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Cc: "ccamp@ietf.org" <cca= mp@ietf.org>, "teas@ietf.org" <teas@ietf.org>, Ericss= on <attila.takacs@ericsson.c= om>, Don Fedyk <don.fedyk@hp.= com>, "hejia@huawei.com= " <hejia@huawei.com>, "akatlas@gmail.com" <= ;akatlas@gmail.com>, Berger Lou= <lberger@labn.net>, Deborah = Brungard <dbrungard@att.com>=
Subject: RE: [Technical Errata Repo= rted] RFC7260 (4106)

Hi Greg,

 

I'm returning to this after an indecent interval.=

 

I checked with IANA and they are OK that we can m= ake this sort of change with an Errata Report and they are happy.

 

So now we have to agree what it should say.<= /o:p>

 

There is an error in your suggested change, I thi= nk because in the first table you show 65533 as IETF review, and in the sec= ond as reserved for experimentation.

 

I am keen to make only the minimal changes to fix= the obvious bugs. Therefore I think there is no need to reserve 65535 and = it can remain as an experimental value.

 

That leaves us with...

 

    IANA has created the "OAM Sub-TLVs" sub-registry of the &q= uot;RSVP-TE OAM

    Configuration Registry" as follows:

=

    Range       | Note     = ;            &n= bsp;       | Registration Procedures

    ------------+------------------------------|--------------------= ----

    0-31     &= nbsp;  | Generic Sub-TLVs = ;            | IETF Review

 &= nbsp; 32-65533  &nbs= p; | Technology-specific Sub-TLVs | IETF Review

    65534-65535 | Experimental Sub-TLVs=         | Reserved for

        = ;            &n= bsp;            = ;       = ;       |   Experimental Use

=

    IANA has populat= ed the registry as follows:

=

       Sub-TLV Type | Description  &n= bsp;            = ;    | Reference

       -------------+-------------------------------+----------

        = ;   0     &nbs= p;  | Reserved  &nbs= p;            &= nbsp;      | [RFC7260]

        = ;   1     &nbs= p;  | OAM Function Flags Sub-TLV    | [RFC7260]

        = ;   2-65533  | Unassigned       &n= bsp;            |

       65534-65535  | Reserved= for Experimental Use | [RFC7260]

 

Is everyone OK with that change?

 

Thanks,

Adrian

 --_000_D0A74BB53A5DBattilatakacsericssoncom_-- From nobody Sat Dec 6 18:39:16 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D1D1A6F24; Sat, 6 Dec 2014 17:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 JaFpTVQ1VeQp; Sat, 6 Dec 2014 17:22:25 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7761A1BC9; Sat, 6 Dec 2014 17:22:25 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-41-54835b9a94a7 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 03.2E.03307.A9B53845; Sat, 6 Dec 2014 20:40:11 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0195.001; Sat, 6 Dec 2014 20:22:21 -0500 From: Gregory Mirsky To: "adrian@olddog.co.uk" Thread-Topic: [Technical Errata Reported] RFC7260 (4106) Thread-Index: AQHPy5pZch2KBOE5ZEKuHN4DSxvQ9ZyCApgAgAHdmnA= Date: Sun, 7 Dec 2014 01:22:21 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AE1B5@eusaamb103.ericsson.se> References: <20140908192308.6BD2B180015@rfc-editor.org> <11ca01d010a2$fff2c130$ffd84390$@olddog.co.uk> In-Reply-To: <11ca01d010a2$fff2c130$ffd84390$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B8AE1B5eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyuXSPt+7s6OYQg3dH+S1+9Nxgtvj08BKz xZM5N1gstu9cwmLRMuUds0VH81sWi9YfO1gc2D1e9s9h9Ng56y67R8uRt6weS5b8ZPL4sKmZ zWPF5pWMAWxRXDYpqTmZZalF+nYJXBknf3xkLPieUbH48HymBsYn0V2MnBwSAiYSF6+tYoWw xSQu3FvP1sXIxSEkcIRR4u++bVDOMkaJzQ83glWxCRhJvNjYww5iiwjoS3Sfm8YOUsQscJhJ ov1WB2MXIweHsIC5xKKJmRA1FhLbn01jgbCtJE6/ugM2h0VARWLu0udMIDavgK/Ei2vrwWYK CWRIXNg9jxHE5hSwllj7YjJYnBHouu+n1oDVMwuIS9x6Mp8J4moBiSV7zjND2KISLx//g/pG SWLO62vMEPX5Ej0XXrNB7BKUODnzCcsERtFZSEbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHs MwceMyGLL2BkX8XIUVqcWpabbmSwiREYscck2HR3MO55aXmIUYCDUYmH94NFU4gQa2JZcWXu IUZpDhYlcd5ZtfOChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBWrcueNM26ICqS+77Jky9N gcI3G5rnqTPEFbFJ9/6aJHRxI/PxywuycwvTJhYvrBSvKw5r+HY8S6D7228+XbmnZiKzD8hz sM7Wfzk7aX3p5JdTwxT8fUvO2Gekdf/2daj2PjWNbe6Bq1wHNJMvOb6VnhfyTWtKW5x20zbe d+d+3f2Ubp1k9EeJpTgj0VCLuag4EQD7eeyOuQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/teas/5oD_4mEznj7GncyOGPMK9Rf9bfU X-Mailman-Approved-At: Sat, 06 Dec 2014 18:39:13 -0800 Cc: "ccamp@ietf.org" , Attila Takacs , "teas@ietf.org" , "akatlas@gmail.com" , "hejia@huawei.com" , "lberger@labn.net" , "don.fedyk@hp.com" , "dbrungard@att.com" Subject: Re: [Teas] [Technical Errata Reported] RFC7260 (4106) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 01:22:28 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8AE1B5eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian, thank you for your suggestions. My motivation to make all-1s reserved was t= o have symmetry with already reserved all-0s value. If authors of the RFC b= elieve it is unnecessary then I'm more than happy with the proposed resolut= ion. Regards, Greg From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, December 05, 2014 11:49 PM To: Gregory Mirsky Cc: ccamp@ietf.org; teas@ietf.org; Attila Takacs; don.fedyk@hp.com; hejia@h= uawei.com; akatlas@gmail.com; lberger@labn.net; dbrungard@att.com Subject: RE: [Technical Errata Reported] RFC7260 (4106) Hi Greg, I'm returning to this after an indecent interval. I checked with IANA and they are OK that we can make this sort of change wi= th an Errata Report and they are happy. So now we have to agree what it should say. There is an error in your suggested change, I think because in the first ta= ble you show 65533 as IETF review, and in the second as reserved for experi= mentation. I am keen to make only the minimal changes to fix the obvious bugs. Therefo= re I think there is no need to reserve 65535 and it can remain as an experi= mental value. That leaves us with... IANA has created the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM Configuration Registry" as follows: Range | Note | Registration Procedures ------------+------------------------------|------------------------ 0-31 | Generic Sub-TLVs | IETF Review 32-65533 | Technology-specific Sub-TLVs | IETF Review 65534-65535 | Experimental Sub-TLVs | Reserved for | Experimental Use IANA has populated the registry as follows: Sub-TLV Type | Description | Reference -------------+-------------------------------+---------- 0 | Reserved | [RFC7260] 1 | OAM Function Flags Sub-TLV | [RFC7260] 2-65533 | Unassigned | 65534-65535 | Reserved for Experimental Use | [RFC7260] Is everyone OK with that change? Thanks, Adrian --_000_7347100B5761DC41A166AC17F22DF1121B8AE1B5eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Adrian,<= /span>

thank you for your sug= gestions. My motivation to make all-1s reserved was to have symmetry with a= lready reserved all-0s value. If authors of the RFC believe it is unnecessa= ry then I’m more than happy with the proposed resolution.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Adrian F= arrel [mailto:adrian@olddog.co.uk]
Sent: Friday, December 05, 2014 11:49 PM
To: Gregory Mirsky
Cc: ccamp@ietf.org; teas@ietf.org; Attila Takacs; don.fedyk@hp.com; = hejia@huawei.com; akatlas@gmail.com; lberger@labn.net; dbrungard@att.com Subject: RE: [Technical Errata Reported] RFC7260 (4106)

 

Hi Greg,

 

I'm returning to this after = an indecent interval.

 

I checked with IANA and they= are OK that we can make this sort of change with an Errata Report and they= are happy.

 

So now we have to agree what= it should say.

 

There is an error in your su= ggested change, I think because in the first table you show 65533 as IETF r= eview, and in the second as reserved for experimentation.=

 

I am keen to make only the m= inimal changes to fix the obvious bugs. Therefore I think there is no need = to reserve 65535 and it can remain as an experimental value.

 

That leaves us with...<= /o:p>

 

    IANA has created the= "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM<= /span>

    Configuration Regist= ry" as follows:

 

    Range  &nb= sp;    | Note        = ;            &n= bsp;    | Registration Procedures

    ------------+---= ---------------------------|------------------------

    0-31  &nbs= p;     | Generic Sub-TLVs     =         | IETF Review<= /p>

   32-65533   = | Technology-specific Sub-TLVs | IETF Review

    65534-65535 | Experi= mental Sub-TLVs        | Reserved for

      &nb= sp;             = ;            &n= bsp;            = ;  |   Experimental Use

 

    IANA has populated t= he registry as follows:

 

       Su= b-TLV Type | Description        &nb= sp;          | Reference<= /o:p>

       --= -----------+-------------------------------+----------

      &nb= sp;    0        | Reserve= d            &n= bsp;         | [RFC7260]=

      &nb= sp;    1        | OAM Fun= ction Flags Sub-TLV    | [RFC7260]

      &nb= sp;    2-65533  | Unassigned    &nb= sp;            =    |

       65= 534-65535  | Reserved for Experimental Use | [RFC7260]

 

Is everyone OK with that cha= nge?

 

Thanks,

Adrian

--_000_7347100B5761DC41A166AC17F22DF1121B8AE1B5eusaamb103erics_-- From nobody Sun Dec 7 05:20:39 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983D11A8758; Sun, 7 Dec 2014 05:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 iiscR6wSI7H0; Sun, 7 Dec 2014 05:20:35 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D421A8757; Sun, 7 Dec 2014 05:20:33 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB7DK9nZ006717; Sun, 7 Dec 2014 13:20:09 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB7DK8gS006704 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 7 Dec 2014 13:20:08 GMT From: "Adrian Farrel" To: "'Gregory Mirsky'" References: <20140908192308.6BD2B180015@rfc-editor.org> <11ca01d010a2$fff2c130$ffd84390$@olddog.co.uk> <7347100B5761DC41A166AC17F22DF1121B8AE1B5@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AE1B5@eusaamb103.ericsson.se> Date: Sun, 7 Dec 2014 13:20:03 -0000 Message-ID: <136501d01220$834958e0$89dc0aa0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1366_01D01220.834DECC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG4SRPFXWGhuDh/2iDRqFsJvZBrdwJVG1MLAq+ETkOci4RTAA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21156.007 X-TM-AS-Result: No--26.882-10.0-31-10 X-imss-scan-details: No--26.882-10.0-31-10 X-TMASE-MatchedRID: j4nUk6F+aLanykMun0J1wvX3U1DOEZGvkPqe52Sp8B0hvFjBsLEZNA2K u+gP3kxi3kiD4RHEUuuao1DDysAB4hAMYVTioAt+HmtCXih7f9NlrsuS5tC+P9qCxkzSpW/Xt9z UwxhckRF7agc6LUgrg7QrDT2bryjE8978TsS8mZHYwybFNa+tmyGi0ftsSkQyVv+3DNSQobOOJm pFkiF2w1tsBfbZxKQE2x4ocHMSNYQuHf42idpFxxcqpH7D1rtQ0HjeANoeuJ1cAx/d1AnyZhG59 Y7tVhgxTIxGxG8pNg/AcYNHI1jaMFEAXL0Ub1O9VU3yVpaj3QzfVqwz+Cynace0H7LMCFcVwRq4 tsfhpByVu5TRVGSDEdtaN8VSEQvzw1hXve9gEVCO0rt0LpQGeRSpYqhygmjp6ygMMToK892nhZy bKoFsXELduO9IO73n36y5gCD1lYkzG8Dg48sJ/vIVL3+KSNgwkTzAgHG5eNKgJH974mpbq6gTkL gTtTggXql2hIcwl2sTHy/6jlpjHT4gGkEowIKZNs3S39zaoXYU2wesiIXyuxW+93iqRvX7VD4IX 3GhzkucTZGiBUd8fawQUp5/xlTGp/nT+xnI1R24jAucHcCqnXcF/0kiqyh4DxjBugJBzzwITux6 kRboK9Ezt6XnoBbPnuOhtEsGi0ZP5mzaUz6wQBD3+0w1DhqK3kR1SkDo278ML9Wb3Qh/hZjzLxY juNCwjSJ3SkiGrFPXkuVVlJMsPZx6Ilif8OzGb/5HBZ6dvRgbTwzYj2zQusO/l0Ny5PZ5C5Uxy0 A8KC27sLiGJ4XBUoAy6p60ZV621ROx5lZ1Rh7+xOhjarOnHjsAVzN+Ov/sDBgpg9sCPTMNlBUeS tUiaE9GnLJxNWMItDME7BLSuuAB2a3fIvwCmg== Archived-At: http://mailarchive.ietf.org/arch/msg/teas/3N3wLm3F4H2No-7El7iE8tBhSwA Cc: ccamp@ietf.org, 'Attila Takacs' , teas@ietf.org, akatlas@gmail.com, hejia@huawei.com, lberger@labn.net, don.fedyk@hp.com, dbrungard@att.com Subject: Re: [Teas] [Technical Errata Reported] RFC7260 (4106) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 13:20:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1366_01D01220.834DECC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks Greg, I think we could reserve all-1s. But that would need an RFC not an Errata Report. The point of the report is to fix the text is accidentally different from what the authors intended. Cheers, Adrian From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: 07 December 2014 01:22 To: adrian@olddog.co.uk Cc: ccamp@ietf.org; teas@ietf.org; Attila Takacs; don.fedyk@hp.com; hejia@huawei.com; akatlas@gmail.com; lberger@labn.net; dbrungard@att.com Subject: RE: [Technical Errata Reported] RFC7260 (4106) Hi Adrian, thank you for your suggestions. My motivation to make all-1s reserved was to have symmetry with already reserved all-0s value. If authors of the RFC believe it is unnecessary then I'm more than happy with the proposed resolution. Regards, Greg From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, December 05, 2014 11:49 PM To: Gregory Mirsky Cc: ccamp@ietf.org; teas@ietf.org; Attila Takacs; don.fedyk@hp.com; hejia@huawei.com; akatlas@gmail.com; lberger@labn.net; dbrungard@att.com Subject: RE: [Technical Errata Reported] RFC7260 (4106) Hi Greg, I'm returning to this after an indecent interval. I checked with IANA and they are OK that we can make this sort of change with an Errata Report and they are happy. So now we have to agree what it should say. There is an error in your suggested change, I think because in the first table you show 65533 as IETF review, and in the second as reserved for experimentation. I am keen to make only the minimal changes to fix the obvious bugs. Therefore I think there is no need to reserve 65535 and it can remain as an experimental value. That leaves us with... IANA has created the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM Configuration Registry" as follows: Range | Note | Registration Procedures ------------+------------------------------|------------------------ 0-31 | Generic Sub-TLVs | IETF Review 32-65533 | Technology-specific Sub-TLVs | IETF Review 65534-65535 | Experimental Sub-TLVs | Reserved for | Experimental Use IANA has populated the registry as follows: Sub-TLV Type | Description | Reference -------------+-------------------------------+---------- 0 | Reserved | [RFC7260] 1 | OAM Function Flags Sub-TLV | [RFC7260] 2-65533 | Unassigned | 65534-65535 | Reserved for Experimental Use | [RFC7260] Is everyone OK with that change? Thanks, Adrian ------=_NextPart_000_1366_01D01220.834DECC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks = Greg,

 

I think we could = reserve all-1s. But that would need an RFC not an Errata = Report.

The point of the = report is to fix the text is accidentally different from what the = authors intended.

 

Cheers,

Adrian

 

From: Gregory Mirsky = [mailto:gregory.mirsky@ericsson.com]
Sent: 07 December 2014 = 01:22
To: adrian@olddog.co.uk
Cc: ccamp@ietf.org; = teas@ietf.org; Attila Takacs; don.fedyk@hp.com; hejia@huawei.com; = akatlas@gmail.com; lberger@labn.net; = dbrungard@att.com
Subject: RE: [Technical Errata Reported] = RFC7260 (4106)

 

Hi = Adrian,

thank you for your = suggestions. My motivation to make all-1s reserved was to have symmetry = with already reserved all-0s value. If authors of the RFC believe it is = unnecessary then I’m more than happy with the proposed = resolution.

 <= /p>

    &= nbsp;           = Regards,

    &= nbsp;           &n= bsp;           &nb= sp;   Greg

 <= /p>

From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: = Friday, December 05, 2014 11:49 PM
To: Gregory = Mirsky
Cc: ccamp@ietf.org; teas@ietf.org; Attila Takacs; = don.fedyk@hp.com; hejia@huawei.com; akatlas@gmail.com; lberger@labn.net; = dbrungard@att.com
Subject: RE: [Technical Errata Reported] = RFC7260 (4106)

 

Hi Greg,

 

I'm = returning to this after an indecent interval.

 

I = checked with IANA and they are OK that we can make this sort of change = with an Errata Report and they are happy.

 

So now = we have to agree what it should say.

 

There = is an error in your suggested change, I think because in the first table = you show 65533 as IETF review, and in the second as reserved for = experimentation.

 

I am = keen to make only the minimal changes to fix the obvious bugs. Therefore = I think there is no need to reserve 65535 and it can remain as an = experimental value.

 

That = leaves us with...

 

    IANA has created = the "OAM Sub-TLVs" sub-registry of the "RSVP-TE = OAM

    Configuration = Registry" as follows:

 

    = Range       | = Note           &nb= sp;           &nbs= p; | Registration Procedures

    = ------------+------------------------------|------------------------=

    = 0-31        | Generic = Sub-TLVs           = ;  | IETF Review

   = 32-65533    | Technology-specific Sub-TLVs | IETF = Review

    65534-65535 | = Experimental Sub-TLVs        | = Reserved for

        =             &= nbsp;           &n= bsp;           &nb= sp;  |   Experimental Use

 

    IANA has = populated the registry as follows:

 

       = Sub-TLV Type | = Description          &n= bsp;        | = Reference

       = -------------+-------------------------------+----------

           = 0        | = Reserved           = ;           | = [RFC7260]

           = 1        | OAM Function Flags = Sub-TLV    | [RFC7260]

           = 2-65533  | = Unassigned          &nb= sp;         = |

       = 65534-65535  | Reserved for Experimental Use | = [RFC7260]

 

Is = everyone OK with that change?

 

Thanks,

Adrian

------=_NextPart_000_1366_01D01220.834DECC0-- From nobody Sun Dec 7 05:49:27 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C131A8760; Sun, 7 Dec 2014 05:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 uxerzgXvxFEh; Sun, 7 Dec 2014 05:49:22 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CF821A875D; Sun, 7 Dec 2014 05:49:21 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-21-5483fe70ee64 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E3.13.25146.07EF3845; Sun, 7 Dec 2014 08:14:56 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0195.001; Sun, 7 Dec 2014 08:49:11 -0500 From: Gregory Mirsky To: "adrian@olddog.co.uk" Thread-Topic: [Technical Errata Reported] RFC7260 (4106) Thread-Index: AQHPy5pZch2KBOE5ZEKuHN4DSxvQ9ZyCApgAgAHdmnCAAR1vgP//s+BQ Date: Sun, 7 Dec 2014 13:49:10 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AE285@eusaamb103.ericsson.se> References: <20140908192308.6BD2B180015@rfc-editor.org> <11ca01d010a2$fff2c130$ffd84390$@olddog.co.uk> <7347100B5761DC41A166AC17F22DF1121B8AE1B5@eusaamb103.ericsson.se> <136501d01220$834958e0$89dc0aa0$@olddog.co.uk> In-Reply-To: <136501d01220$834958e0$89dc0aa0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B8AE285eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyuXRPgm7Bv+YQgw83DC1+9Nxgtvj08BKz xZM5N1gstu9cwmLRMuUds0VH81sWi9YfO1gc2D1e9s9h9Ng56y67R8uRt6weS5b8ZPL4sKmZ zWPF5pWMAWxRXDYpqTmZZalF+nYJXBmbZ21mLJg4m7Hi3fL3LA2MTzoYuxg5OSQETCRevbjL DGGLSVy4t56ti5GLQ0jgCKPEgk+nmSGcZYwSGw59ZAKpYhMwknixsYcdxBYR0JfoPjeNHaSI WeAwk0T7LZCxHBzCAuYSiyZmQtRYSGx/No0FwnaTuLJ5NRuIzSKgItF5Zw6YzSvgK/Fw+S6w GiGBu4wSr5fIgdicAtYSzyecA9vFCHTd91NrwG5gFhCXuPVkPhPE1QISS/ach/pAVOLl43+s ELaSxJzX15gh6vMlFre2sUPsEpQ4OfMJywRG0VlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+Z YewzBx4zIYsvYGRfxchRWpxalptuZLiJERi1xyTYHHcwLvhkeYhRgINRiYd3w6HmECHWxLLi ytxDjNIcLErivJrV84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MMoJV32T9s6o0so2tfHa 49LoojPN6xVfQt9E083z/Lq+TyheLOQ1fx234MyrgXM25PJ8tJCYnLEhwGSicL7tD/U56T5X 7prPM10ndcjHuVBPdA1TirCXak1myY3Qq09XNG6Ymys0L1rq/jN+u/9Ps50CuOaymIu9mPb5 56U/rVrGhTuP8fcdVmIpzkg01GIuKk4EAGICAMS7AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/teas/V6W4ZiAUah24KS7Hm1oxeRWusM8 Cc: "ccamp@ietf.org" , Attila Takacs , "teas@ietf.org" , "akatlas@gmail.com" , "hejia@huawei.com" , "lberger@labn.net" , "don.fedyk@hp.com" , "dbrungard@att.com" Subject: Re: [Teas] [Technical Errata Reported] RFC7260 (4106) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 13:49:26 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8AE285eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian, I agree with the resolution you've proposed. Please let me know if I need to make changes to the Errata or it can be res= olved based on your proposal. Regards, Greg From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Sunday, December 07, 2014 9:20 PM To: Gregory Mirsky Cc: ccamp@ietf.org; teas@ietf.org; Attila Takacs; don.fedyk@hp.com; hejia@h= uawei.com; akatlas@gmail.com; lberger@labn.net; dbrungard@att.com Subject: RE: [Technical Errata Reported] RFC7260 (4106) Thanks Greg, I think we could reserve all-1s. But that would need an RFC not an Errata R= eport. The point of the report is to fix the text is accidentally different from w= hat the authors intended. Cheers, Adrian From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: 07 December 2014 01:22 To: adrian@olddog.co.uk Cc: ccamp@ietf.org; teas@ietf.org; Attila Takacs; don.fedyk@hp.com; hejia@huawei= .com; akatlas@gmail.com;= lberger@labn.net; dbrungard@att.com Subject: RE: [Technical Errata Reported] RFC7260 (4106) Hi Adrian, thank you for your suggestions. My motivation to make all-1s reserved was t= o have symmetry with already reserved all-0s value. If authors of the RFC b= elieve it is unnecessary then I'm more than happy with the proposed resolut= ion. Regards, Greg From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, December 05, 2014 11:49 PM To: Gregory Mirsky Cc: ccamp@ietf.org; teas@ietf.org; Attila Takacs; don.fedyk@hp.com; hejia@huawei= .com; akatlas@gmail.com;= lberger@labn.net; dbrungard@att.com Subject: RE: [Technical Errata Reported] RFC7260 (4106) Hi Greg, I'm returning to this after an indecent interval. I checked with IANA and they are OK that we can make this sort of change wi= th an Errata Report and they are happy. So now we have to agree what it should say. There is an error in your suggested change, I think because in the first ta= ble you show 65533 as IETF review, and in the second as reserved for experi= mentation. I am keen to make only the minimal changes to fix the obvious bugs. Therefo= re I think there is no need to reserve 65535 and it can remain as an experi= mental value. That leaves us with... IANA has created the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM Configuration Registry" as follows: Range | Note | Registration Procedures ------------+------------------------------|------------------------ 0-31 | Generic Sub-TLVs | IETF Review 32-65533 | Technology-specific Sub-TLVs | IETF Review 65534-65535 | Experimental Sub-TLVs | Reserved for | Experimental Use IANA has populated the registry as follows: Sub-TLV Type | Description | Reference -------------+-------------------------------+---------- 0 | Reserved | [RFC7260] 1 | OAM Function Flags Sub-TLV | [RFC7260] 2-65533 | Unassigned | 65534-65535 | Reserved for Experimental Use | [RFC7260] Is everyone OK with that change? Thanks, Adrian --_000_7347100B5761DC41A166AC17F22DF1121B8AE285eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Adrian,<= /span>

I agree with the resol= ution you’ve proposed.

Please let me know if = I need to make changes to the Errata or it can be resolved based on your pr= oposal.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Adrian F= arrel [mailto:adrian@olddog.co.uk]
Sent: Sunday, December 07, 2014 9:20 PM
To: Gregory Mirsky
Cc: ccamp@ietf.org; teas@ietf.org; Attila Takacs; don.fedyk@hp.com; = hejia@huawei.com; akatlas@gmail.com; lberger@labn.net; dbrungard@att.com Subject: RE: [Technical Errata Reported] RFC7260 (4106)

 

Thanks = Greg,

&n= bsp;

I think= we could reserve all-1s. But that would need an RFC not an Errata Report.<= o:p>

The poi= nt of the report is to fix the text is accidentally different from what the= authors intended.

&n= bsp;

Cheers,=

Adrian<= o:p>

&n= bsp;

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: 07 December 2014 01:22
To: adrian@olddog.co.uk Cc: ccamp@ietf.org; teas@ietf.org; Attila Takacs; don.f= edyk@hp.com; hejia@huawei.com; akatlas@gmail.com; lberger@labn.net= ; dbrungard@att.com
Subject: RE: [Technical Errata Reported] RFC7260 (4106)

 

Hi Adrian,<= /span>

thank you for your sug= gestions. My motivation to make all-1s reserved was to have symmetry with a= lready reserved all-0s value. If authors of the RFC believe it is unnecessa= ry then I’m more than happy with the proposed resolution.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

 

Hi Greg,

 

I'm returning to this after = an indecent interval.

 

I checked with IANA and they= are OK that we can make this sort of change with an Errata Report and they= are happy.

 

So now we have to agree what= it should say.

 

There is an error in your su= ggested change, I think because in the first table you show 65533 as IETF r= eview, and in the second as reserved for experimentation.=

 

I am keen to make only the m= inimal changes to fix the obvious bugs. Therefore I think there is no need = to reserve 65535 and it can remain as an experimental value.

 

That leaves us with...<= /o:p>

 

    IANA has created the= "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM<= /span>

    Configuration Regist= ry" as follows:

 

    Range  &nb= sp;    | Note        = ;            &n= bsp;    | Registration Procedures

    ------------+---= ---------------------------|------------------------

    0-31  &nbs= p;     | Generic Sub-TLVs     =         | IETF Review<= /p>

   32-65533   = | Technology-specific Sub-TLVs | IETF Review

    65534-65535 | Experi= mental Sub-TLVs        | Reserved for

      &nb= sp;             = ;            &n= bsp;            = ;  |   Experimental Use

 

    IANA has populated t= he registry as follows:

 

       Su= b-TLV Type | Description        &nb= sp;          | Reference<= /o:p>

       --= -----------+-------------------------------+----------

      &nb= sp;    0        | Reserve= d            &n= bsp;         | [RFC7260]=

      &nb= sp;    1        | OAM Fun= ction Flags Sub-TLV    | [RFC7260]

      &nb= sp;    2-65533  | Unassigned    &nb= sp;            =    |

       65= 534-65535  | Reserved for Experimental Use | [RFC7260]

 

Is everyone OK with that cha= nge?

 

Thanks,

Adrian

--_000_7347100B5761DC41A166AC17F22DF1121B8AE285eusaamb103erics_-- From nobody Sun Dec 7 06:12:08 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37221A8761; Sun, 7 Dec 2014 06:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 9HDaEj9wy2bW; Sun, 7 Dec 2014 06:12:00 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8ECE1A020B; Sun, 7 Dec 2014 06:11:59 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB7EBdDD017137; Sun, 7 Dec 2014 14:11:39 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB7EBZ0D017084 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 7 Dec 2014 14:11:36 GMT From: "Adrian Farrel" To: "'Gregory Mirsky'" References: <20140908192308.6BD2B180015@rfc-editor.org> <11ca01d010a2$fff2c130$ffd84390$@olddog.co.uk> <7347100B5761DC41A166AC17F22DF1121B8AE1B5@eusaamb103.ericsson.se> <136501d01220$834958e0$89dc0aa0$@olddog.co.uk> <7347100B5761DC41A166AC17F22DF1121B8AE285@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AE285@eusaamb103.ericsson.se> Date: Sun, 7 Dec 2014 14:11:31 -0000 Message-ID: <137d01d01227$b4cf8db0$1e6ea910$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_137E_01D01227.B4DD4950" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG4SRPFXWGhuDh/2iDRqFsJvZBrdwJVG1MLAq+ETkMCJJNeqgHQfTZynGvvpXA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21156.007 X-TM-AS-Result: No--28.309-10.0-31-10 X-imss-scan-details: No--28.309-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtHr/497FfFvZumc4/pDEQa2DWfZBggWU3XYpRv5miLGfLnx hIt+8oeIfgsZQfgAz7k2O3qnaevuHOO1ibGOrN1Rma6DzXaohvMS12tj9Zvd8/002DXYmoa1Arf whXClRwmV18eyPf5mlE+LVhi2IFxT0orU+fkIj1DISPeZE8elXkKzuF0egUUDwaaX3YWNLhHc61 fkELl2KgLcypum82RLSHCGonA+tRaqDnzRgK0zcwlPus/MSqC7TJDl9FKHbrkHWPn2mj7oRCacn bShnMCcr3SNFzMXxmcig+A3HEvrTVDV9sDqOQY/syNb+yeIRAoDlsejEAvAg9zOQo7mTgA+o0/t 1gD0V8M22uoEm245fkFWCvm86w840sXpjQvtH9BwUSK4/EeOxbRfRjDbtW6i5DjmdW0+qbGuwVT xTDkELrK2YHb/kidP/PEgL0tqyq50bnu2kHqixLMsPmSZxbpkE7JInT4wddoTjfkO3pb+WD0msI gSyun3H/Z71HJDNaFacyhB9L1arxJ3qw6ad/ljABhihvAhvAJIeNYTP8OmTPk3SjZMcZFkUlBh+ kbitM8/DUc/B6QpkmRGSnUqeCO9OQRl+99vaMkMH4SsGvRsA1qvZZ9/gpIhpRezBf/GshIGk2pT PAu+9//55Kkc+9/6c91xMYNqHkVw5YMyIgibAuRw69tAYXNGl2F9+KxZd8cL/50zj0KL7BY+750 9sPX7ZLNHiJlyaWEtY3smclWYCYIiDu0n/+6xi+m1DDPm2yL/fHyH+MCF5RUZTfM00s4+akcq2R AHKcqx/667QIps1TBOwaDA4JnNo27w8ee4WC+eAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDxzdxDi jdbMze36sKKy4ePbKzPKXQyq+DoapKYjd0qfEBuuR0SGCAefki7cVK33ib3MjKNSXX/RQ== Archived-At: http://mailarchive.ietf.org/arch/msg/teas/ZE-I4_hn8nlOcKB_Ra4b8tKpKGc Cc: ccamp@ietf.org, 'Attila Takacs' , teas@ietf.org, akatlas@gmail.com, hejia@huawei.com, lberger@labn.net, don.fedyk@hp.com, dbrungard@att.com Subject: Re: [Teas] [Technical Errata Reported] RFC7260 (4106) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 14:12:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_137E_01D01227.B4DD4950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nope, that's OK. I'll handle it. Cheers, Adrian From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: 07 December 2014 13:49 To: adrian@olddog.co.uk Cc: ccamp@ietf.org; teas@ietf.org; Attila Takacs; don.fedyk@hp.com; hejia@huawei.com; akatlas@gmail.com; lberger@labn.net; dbrungard@att.com Subject: RE: [Technical Errata Reported] RFC7260 (4106) Hi Adrian, I agree with the resolution you've proposed. Please let me know if I need to make changes to the Errata or it can be resolved based on your proposal. Regards, Greg From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Sunday, December 07, 2014 9:20 PM To: Gregory Mirsky Cc: ccamp@ietf.org; teas@ietf.org; Attila Takacs; don.fedyk@hp.com; hejia@huawei.com; akatlas@gmail.com; lberger@labn.net; dbrungard@att.com Subject: RE: [Technical Errata Reported] RFC7260 (4106) Thanks Greg, I think we could reserve all-1s. But that would need an RFC not an Errata Report. The point of the report is to fix the text is accidentally different from what the authors intended. Cheers, Adrian From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: 07 December 2014 01:22 To: adrian@olddog.co.uk Cc: ccamp@ietf.org; teas@ietf.org; Attila Takacs; don.fedyk@hp.com; hejia@huawei.com; akatlas@gmail.com; lberger@labn.net; dbrungard@att.com Subject: RE: [Technical Errata Reported] RFC7260 (4106) Hi Adrian, thank you for your suggestions. My motivation to make all-1s reserved was to have symmetry with already reserved all-0s value. If authors of the RFC believe it is unnecessary then I'm more than happy with the proposed resolution. Regards, Greg From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, December 05, 2014 11:49 PM To: Gregory Mirsky Cc: ccamp@ietf.org; teas@ietf.org; Attila Takacs; don.fedyk@hp.com; hejia@huawei.com; akatlas@gmail.com; lberger@labn.net; dbrungard@att.com Subject: RE: [Technical Errata Reported] RFC7260 (4106) Hi Greg, I'm returning to this after an indecent interval. I checked with IANA and they are OK that we can make this sort of change with an Errata Report and they are happy. So now we have to agree what it should say. There is an error in your suggested change, I think because in the first table you show 65533 as IETF review, and in the second as reserved for experimentation. I am keen to make only the minimal changes to fix the obvious bugs. Therefore I think there is no need to reserve 65535 and it can remain as an experimental value. That leaves us with... IANA has created the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM Configuration Registry" as follows: Range | Note | Registration Procedures ------------+------------------------------|------------------------ 0-31 | Generic Sub-TLVs | IETF Review 32-65533 | Technology-specific Sub-TLVs | IETF Review 65534-65535 | Experimental Sub-TLVs | Reserved for | Experimental Use IANA has populated the registry as follows: Sub-TLV Type | Description | Reference -------------+-------------------------------+---------- 0 | Reserved | [RFC7260] 1 | OAM Function Flags Sub-TLV | [RFC7260] 2-65533 | Unassigned | 65534-65535 | Reserved for Experimental Use | [RFC7260] Is everyone OK with that change? Thanks, Adrian ------=_NextPart_000_137E_01D01227.B4DD4950 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nope, that's OK. I'll = handle it.

 

Cheers,

Adrian

 

From: Gregory Mirsky = [mailto:gregory.mirsky@ericsson.com]
Sent: 07 December 2014 = 13:49
To: adrian@olddog.co.uk
Cc: ccamp@ietf.org; = teas@ietf.org; Attila Takacs; don.fedyk@hp.com; hejia@huawei.com; = akatlas@gmail.com; lberger@labn.net; = dbrungard@att.com
Subject: RE: [Technical Errata Reported] = RFC7260 (4106)

 

Hi = Adrian,

I agree with the = resolution you’ve proposed.

Please let me know if I = need to make changes to the Errata or it can be resolved based on your = proposal.

 <= /p>

    &= nbsp;           = Regards,

    &= nbsp;           &n= bsp;           &nb= sp;   Greg

 <= /p>

From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: = Sunday, December 07, 2014 9:20 PM
To: Gregory = Mirsky
Cc: ccamp@ietf.org; teas@ietf.org; Attila Takacs; = don.fedyk@hp.com; hejia@huawei.com; akatlas@gmail.com; lberger@labn.net; = dbrungard@att.com
Subject: RE: [Technical Errata Reported] = RFC7260 (4106)

 

Thanks = Greg,

 

I think we could reserve = all-1s. But that would need an RFC not an Errata = Report.

The point of the report is to fix the text is = accidentally different from what the authors = intended.

 

Cheers,

Adrian

 

From: Gregory Mirsky [mailto:gregory.mirsky@ericsso= n.com]
Sent: 07 December 2014 01:22
To: adrian@olddog.co.uk
Cc:= ccamp@ietf.org; teas@ietf.org; Attila Takacs; don.fedyk@hp.com; hejia@huawei.com; akatlas@gmail.com; lberger@labn.net; dbrungard@att.com
Subject: RE: [Technical Errata Reported] RFC7260 = (4106)

 

Hi = Adrian,

thank you for your = suggestions. My motivation to make all-1s reserved was to have symmetry = with already reserved all-0s value. If authors of the RFC believe it is = unnecessary then I’m more than happy with the proposed = resolution.

 <= /p>

    &= nbsp;           = Regards,

    &= nbsp;           &n= bsp;           &nb= sp;   Greg

 <= /p>

From: Adrian Farrel [mailto:adrian@olddog.co.uk] =
Sent: Friday, December 05, 2014 11:49 PM
To: = Gregory Mirsky
Cc: ccamp@ietf.org; teas@ietf.org; Attila Takacs; don.fedyk@hp.com; hejia@huawei.com; akatlas@gmail.com; lberger@labn.net; dbrungard@att.com
Subject: RE: [Technical Errata Reported] RFC7260 = (4106)

 

Hi Greg,

 

I'm = returning to this after an indecent interval.

 

I = checked with IANA and they are OK that we can make this sort of change = with an Errata Report and they are happy.

 

So now = we have to agree what it should say.

 

There = is an error in your suggested change, I think because in the first table = you show 65533 as IETF review, and in the second as reserved for = experimentation.

 

I am = keen to make only the minimal changes to fix the obvious bugs. Therefore = I think there is no need to reserve 65535 and it can remain as an = experimental value.

 

That = leaves us with...

 

    IANA has created = the "OAM Sub-TLVs" sub-registry of the "RSVP-TE = OAM

    Configuration = Registry" as follows:

 

    = Range       | = Note           &nb= sp;           &nbs= p; | Registration Procedures

    = ------------+------------------------------|------------------------=

    = 0-31        | Generic = Sub-TLVs           = ;  | IETF Review

   = 32-65533    | Technology-specific Sub-TLVs | IETF = Review

    65534-65535 | = Experimental Sub-TLVs        | = Reserved for

        =             &= nbsp;           &n= bsp;           &nb= sp;  |   Experimental Use

 

    IANA has = populated the registry as follows:

 

       = Sub-TLV Type | = Description          &n= bsp;        | = Reference

       = -------------+-------------------------------+----------

           = 0        | = Reserved           = ;           | = [RFC7260]

           = 1        | OAM Function Flags = Sub-TLV    | [RFC7260]

           = 2-65533  | = Unassigned          &nb= sp;         = |

       = 65534-65535  | Reserved for Experimental Use | = [RFC7260]

 

Is = everyone OK with that change?

 

Thanks,

Adrian

------=_NextPart_000_137E_01D01227.B4DD4950-- From nobody Mon Dec 8 03:24:16 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7731A6FE0; Sun, 7 Dec 2014 23:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 efw09rw-XOtA; Sun, 7 Dec 2014 23:30:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11ED81A6FDF; Sun, 7 Dec 2014 23:30:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMO81575; Mon, 08 Dec 2014 07:30:27 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 8 Dec 2014 07:30:26 +0000 Received: from SZXEMA507-MBS.china.huawei.com ([169.254.6.247]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Mon, 8 Dec 2014 15:30:21 +0800 From: "Hejia (Jia)" To: "adrian@olddog.co.uk" , "gregory.mirsky@ericsson.com" Thread-Topic: [Technical Errata Reported] RFC7260 (4106) Thread-Index: AQG4SRPFXWGhuDh/2iDRqFsJvZBrd5ywq2ZggAQz+pA= Date: Mon, 8 Dec 2014 07:30:21 +0000 Message-ID: <735916399E11684EAF4EB4FB376B719551B22454@szxema507-mbs.china.huawei.com> References: <20140908192308.6BD2B180015@rfc-editor.org> <11ca01d010a2$fff2c130$ffd84390$@olddog.co.uk> In-Reply-To: <11ca01d010a2$fff2c130$ffd84390$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.169] Content-Type: multipart/alternative; boundary="_000_735916399E11684EAF4EB4FB376B719551B22454szxema507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/teas/1hdrLhn0qybaAK46gPNLQwpNZhk X-Mailman-Approved-At: Mon, 08 Dec 2014 03:24:13 -0800 Cc: "ccamp@ietf.org" , "attila.takacs@ericsson.com" , "teas@ietf.org" , "akatlas@gmail.com" , "lberger@labn.net" , "don.fedyk@hp.com" , "dbrungard@att.com" Subject: Re: [Teas] [Technical Errata Reported] RFC7260 (4106) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 07:30:32 -0000 --_000_735916399E11684EAF4EB4FB376B719551B22454szxema507mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adrian, I'm OK with your proposal. B.R. Jia From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, December 05, 2014 11:49 PM To: gregory.mirsky@ericsson.com Cc: ccamp@ietf.org; teas@ietf.org; attila.takacs@ericsson.com; don.fedyk@hp= .com; Hejia (Jia); akatlas@gmail.com; lberger@labn.net; dbrungard@att.com Subject: RE: [Technical Errata Reported] RFC7260 (4106) Hi Greg, I'm returning to this after an indecent interval. I checked with IANA and they are OK that we can make this sort of change wi= th an Errata Report and they are happy. So now we have to agree what it should say. There is an error in your suggested change, I think because in the first ta= ble you show 65533 as IETF review, and in the second as reserved for experi= mentation. I am keen to make only the minimal changes to fix the obvious bugs. Therefo= re I think there is no need to reserve 65535 and it can remain as an experi= mental value. That leaves us with... IANA has created the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM Configuration Registry" as follows: Range | Note | Registration Procedures ------------+------------------------------|------------------------ 0-31 | Generic Sub-TLVs | IETF Review 32-65533 | Technology-specific Sub-TLVs | IETF Review 65534-65535 | Experimental Sub-TLVs | Reserved for | Experimental Use IANA has populated the registry as follows: Sub-TLV Type | Description | Reference -------------+-------------------------------+---------- 0 | Reserved | [RFC7260] 1 | OAM Function Flags Sub-TLV | [RFC7260] 2-65533 | Unassigned | 65534-65535 | Reserved for Experimental Use | [RFC7260] Is everyone OK with that change? Thanks, Adrian --_000_735916399E11684EAF4EB4FB376B719551B22454szxema507mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adrian,

 

I’m OK with your proposal.

 

B.R.

Jia

 

From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Friday, December 05, 2014 11:49 PM
To: gregory.mirsky@ericsson.com
Cc: ccamp@ietf.org; teas@ietf.org; attila.takacs@ericsson.com; don.f= edyk@hp.com; Hejia (Jia); akatlas@gmail.com; lberger@labn.net; dbrungard@at= t.com
Subject: RE: [Technical Errata Reported] RFC7260 (4106)

 

Hi Greg,

 

I'm returning to this after = an indecent interval.

 

I checked with IANA and they= are OK that we can make this sort of change with an Errata Report and they= are happy.

 

So now we have to agree what= it should say.

 

There is an error in your su= ggested change, I think because in the first table you show 65533 as IETF r= eview, and in the second as reserved for experimentation.=

 

I am keen to make only the m= inimal changes to fix the obvious bugs. Therefore I think there is no need = to reserve 65535 and it can remain as an experimental value.

 

That leaves us with...<= /o:p>

 

    IANA has created the "OAM Sub-TLV= s" sub-registry of the "RSVP-TE OAM

    Configuration Registry" as follow= s:

 

    Range     &nb= sp; | Note           = ;            &n= bsp; | Registration Procedures

    ------------+---------------------= ---------|------------------------

    0-31     &nbs= p;  | Generic Sub-TLVs        =      | IETF Review

   32-65533    | Technology-spec= ific Sub-TLVs | IETF Review

    65534-65535 | Experimental Sub-TLVs&nb= sp;       | Reserved for

         &nb= sp;            =             &nb= sp;            |&nbs= p;  Experimental Use

 

    IANA has populated the registry as fol= lows:

 

       Sub-TLV Type | Descr= iption           &nb= sp;       | Reference

       -------------+--= -----------------------------+----------

         &nb= sp; 0        | Reserved   = ;            &n= bsp;      | [RFC7260]

         &nb= sp; 1        | OAM Function Flags Sub-TL= V    | [RFC7260]

         &nb= sp; 2-65533  | Unassigned       &nb= sp;            |

       65534-65535  | = Reserved for Experimental Use | [RFC7260]

 

Is everyone OK with that cha= nge?

 

Thanks,

Adrian

--_000_735916399E11684EAF4EB4FB376B719551B22454szxema507mbschi_-- From nobody Mon Dec 8 12:51:43 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789911A0377 for ; Mon, 8 Dec 2014 12:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.618 X-Spam-Level: **** X-Spam-Status: No, score=4.618 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SORTED_RECIPS=2.499, SPF_PASS=-0.001, SUSPICIOUS_RECIPS=2.51, T_DKIM_INVALID=0.01] autolearn=no 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 mR9ihsrtC0oJ for ; Mon, 8 Dec 2014 12:50:38 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 3A4391A036E for ; Mon, 8 Dec 2014 12:50:38 -0800 (PST) Received: (qmail 17794 invoked by uid 0); 8 Dec 2014 20:50:36 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 8 Dec 2014 20:50:36 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id R8qQ1p00l2SSUrH018qT6Y; Mon, 08 Dec 2014 13:50:36 -0700 X-Authority-Analysis: v=2.1 cv=B+wqjodM c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=M0qlLD3ORKjP_og02BIA:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=XOCKMQ1vjz2Ia8yNDTl6SZ02sXUGFLUihCrdjcdgIi8=; b=H4hmED3oE9g5VMAau0wS78OPVHf8JjAjYugdmt6EDK+GgQ46FNs8l8hxR2MGC3EUn+QXQ6C+1Tn4h2SmPyChW6NYsl1fLKM5WqyPPG4sDwhraalT99e67Zv+/PJauXmB; Received: from box313.bluehost.com ([69.89.31.113]:45184 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Xy5GC-0007Qo-Bt; Mon, 08 Dec 2014 13:50:24 -0700 Message-ID: <54860F0D.9090900@labn.net> Date: Mon, 08 Dec 2014 15:50:21 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: draft-ietf-ccamp-gmpls-resource-sharing-proc@tools.ietf.org, draft-ietf-ccamp-interconnected-te-info-exchange@tools.ietf.org, draft-ietf-ccamp-lsp-attribute-ro@tools.ietf.org, draft-ietf-ccamp-lsp-diversity@tools.ietf.org, draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org, draft-ietf-ccamp-network-assigned-upstream-label@tools.ietf.org, draft-ietf-ccamp-rsvp-te-domain-subobjects@tools.ietf.org, draft-ietf-ccamp-rsvp-te-li-lb@tools.ietf.org, draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org, draft-ietf-ccamp-te-metric-recording@tools.ietf.org, draft-ietf-mpls-p2mp-loose-path-reopt@tools.ietf.org, draft-ietf-mpls-rsvp-egress-protection@tools.ietf.org, draft-ietf-mpls-rsvp-ingress-protection@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/mN1RGiTBub0b4-AqmZp-6gqBspw X-Mailman-Approved-At: Mon, 08 Dec 2014 12:51:42 -0800 Cc: TEAS WG Subject: [Teas] Please republish re-homed TEAS WG documents X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 20:50:39 -0000 Hello, As discussed in the last meeting, the drafts listed in the To: lines above have been moved over to the new TEAS WG. (See https://datatracker.ietf.org/wg/teas/documents/) The current state shows the right WG ownership, but wrong draft names. To correct this: Authors, Please republish your draft as draft-ietf-teas-...-00 as soon as you can. *without any other changes please*. Once the draft is uploaded, it will be approved and we will set the replace-by information to maintain history. This will also result in only the -00 version being listed under teas. Note that there are 4 documents that are in or post LC. Authors should still follow the above direction, i.e., resubmit the version that is in / went through LC as the -00 version. LC related updates should then be made to the -01 versions of the draft. Much thanks, Lou (and Deborah) From nobody Mon Dec 8 12:58:23 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3725D1A03F9 for ; Mon, 8 Dec 2014 12:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 rCE0ID3bplUp for ; Mon, 8 Dec 2014 12:58:21 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 0A91C1A039D for ; Mon, 8 Dec 2014 12:58:20 -0800 (PST) Received: (qmail 6147 invoked by uid 0); 8 Dec 2014 20:58:16 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy10.mail.unifiedlayer.com with SMTP; 8 Dec 2014 20:58:16 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id R8yB1p00e2SSUrH018yEqe; Mon, 08 Dec 2014 13:58:16 -0700 X-Authority-Analysis: v=2.1 cv=Hd2HEE08 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=g3TyfaYqeXDKModwy48A:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=ZuKNXjS8bv9YCxoEddeaCX6eocwuN9VJaS4hGCCKZIw=; b=CpURO1FDDDVIunGjWKu21LZBy/F6fV73reDtMEQRUw7Tvq2nSVsoiF6uMnfKRMd0kVhpNFL8eCTd/7tjkyRCtnYIqdlqZAzMpN4EX05t922iHGMVDqH+daPrmrtgRggO; Received: from box313.bluehost.com ([69.89.31.113]:45893 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Xy5Nj-0001FY-Ar; Mon, 08 Dec 2014 13:58:11 -0700 Message-ID: <548610E0.4040605@labn.net> Date: Mon, 08 Dec 2014 15:58:08 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: CCAMP , "" , TEAS WG References: <546F49D6.3000305@labn.net> In-Reply-To: <546F49D6.3000305@labn.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/bSpQxoGZbBqM7QiEPbUtPx61Aik Subject: Re: [Teas] [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-attribute-ro-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 20:58:22 -0000 The WG LC is now closed for this now *TEAS* WG document. (Yes this is a really odd side effect of the WG changes.) Please direct future discussion, including follow up to LC comments, on this document to the TEAS WG. Authors, Please discuss any issues raised (on the TEAS WG list) and submit updates using the name draft-ietf-teas-lsp-attribute-ro. As mentioned on the TEAS list, please first republish draft-ietf-ccamp-lsp-attribute-ro-05 as draft-ietf-teas-lsp-attribute-ro-= 00. Thank you! Lou (and Deborah) On 11/21/2014 9:19 AM, Lou Berger wrote: > All, > =20 > This starts a two-week working group last call on > draft-ietf-ccamp-lsp-attribute-ro-05. > =20 > This working group last call ends on Friday December 5th. Please send y= our > comments to the CCAMP mailing list. > =20 > As noted, there is one IPR disclosed. > =20 > Thanks, > Lou (and Deborah) > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From nobody Mon Dec 8 15:20:39 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5B61A0073 for ; Mon, 8 Dec 2014 15:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 3TVpDJyPRCGz for ; Mon, 8 Dec 2014 15:20:33 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C33B1A010C for ; Mon, 8 Dec 2014 15:20:33 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB8NKUsB018410; Mon, 8 Dec 2014 23:20:30 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB8NKTdZ018404 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2014 23:20:30 GMT From: "Adrian Farrel" To: "'Lou Berger'" References: <54860F0D.9090900@labn.net> In-Reply-To: <54860F0D.9090900@labn.net> Date: Mon, 8 Dec 2014 23:20:24 -0000 Message-ID: <027f01d0133d$8c0eb010$a42c1030$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLBxcTe8Qd6Yp9oTnNnMDLMrXoYtpqi7y7w Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21160.003 X-TM-AS-Result: No--14.498-10.0-31-10 X-imss-scan-details: No--14.498-10.0-31-10 X-TMASE-MatchedRID: +f/wAVSGjugE0a017aLD3eEbUg4xvs+wIHYIZed9zXUQRrduf9tzCBia W/0fL8qeTWLw2jvbfpxS13xU66XgGlXXZeCGvpCTO8dpCBNpmLVl0qH7/7HRjjCmUYns3FLTsVD 6Qn5cw6IlagwmNxqT+LUG51zosr3w7K35r0y1/568coKUcaOOvRlgDfyCPcHEymP/1piI/6H8k0 Y8XCLqDfJCSj70XrhVw0abA3xfU73C/uSBpQr0lpmug812qIbzTJDl9FKHbrljEZl+QzZVx6Anf GXpAxOBsMQ61NSlVI/wEqkUumfAnj/1plBLyxmnBu2zRCSrLjaeimGtNywjtpsoi2XrUn/JyeMt MD9QOgCk8oKXKhRLPI2j49Ftap9EOwBXM346/+yXSwC99U+5tS2C2d9jtO/lvVdKLejXx4n45cZ TbQfLBiLTvHZWgUYd Archived-At: http://mailarchive.ietf.org/arch/msg/teas/sxACaOvd7TVKaDUu155mpIQQ1X8 Cc: 'TEAS WG' Subject: Re: [Teas] Please republish re-homed TEAS WG documents X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 23:20:36 -0000 Done for draft-ietf-teas-interconnected-te-info-exchange although I expect we'll have to come back and fix the references. > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: 08 December 2014 20:50 > To: draft-ietf-ccamp-gmpls-resource-sharing-proc@tools.ietf.org; draft-ietf- > ccamp-interconnected-te-info-exchange@tools.ietf.org; draft-ietf-ccamp-lsp- > attribute-ro@tools.ietf.org; draft-ietf-ccamp-lsp-diversity@tools.ietf.org; draft- > ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org; draft-ietf-ccamp- > network-assigned-upstream-label@tools.ietf.org; draft-ietf-ccamp-rsvp-te- > domain-subobjects@tools.ietf.org; draft-ietf-ccamp-rsvp-te-li-lb@tools.ietf.org; > draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org; draft-ietf-ccamp-te-metric- > recording@tools.ietf.org; draft-ietf-mpls-p2mp-loose-path-reopt@tools.ietf.org; > draft-ietf-mpls-rsvp-egress-protection@tools.ietf.org; draft-ietf-mpls-rsvp- > ingress-protection@tools.ietf.org > Cc: TEAS WG > Subject: Please republish re-homed TEAS WG documents > > Hello, > As discussed in the last meeting, the drafts listed in the To: lines > above have been moved over to the new TEAS WG. (See > https://datatracker.ietf.org/wg/teas/documents/) The current state shows > the right WG ownership, but wrong draft names. To correct this: > > Authors, > Please republish your draft as draft-ietf-teas-...-00 as soon as you > can. *without any other changes please*. > > Once the draft is uploaded, it will be approved and we will set the > replace-by information to maintain history. This will also result in > only the -00 version being listed under teas. > > Note that there are 4 documents that are in or post LC. Authors should > still follow the above direction, i.e., resubmit the version that is in > / went through LC as the -00 version. LC related updates should then be > made to the -01 versions of the draft. > > Much thanks, > Lou (and Deborah) > From nobody Mon Dec 8 16:41:33 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495E01A00C2; Mon, 8 Dec 2014 15:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 5I9A_Ney-VO8; Mon, 8 Dec 2014 15:18:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9C1A0073; Mon, 8 Dec 2014 15:18:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141208231854.18028.43465.idtracker@ietfa.amsl.com> Date: Mon, 08 Dec 2014 15:18:54 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/WydABVoObR_dw0qFg8G_R2NMGLE X-Mailman-Approved-At: Mon, 08 Dec 2014 16:41:30 -0800 Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-interconnected-te-info-exchange-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 23:18:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks Authors : Adrian Farrel John Drake Nabil Bitar George Swallow Daniele Ceccarelli Xian Zhang Filename : draft-ietf-teas-interconnected-te-info-exchange-00.txt Pages : 56 Date : 2014-12-08 Abstract: In Traffic Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more network from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. The availability of TE information is usually limited to within a network (such as an IGP area) often referred to as a domain. In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network, but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information. This document sets out the problem statement and architecture for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment. For reasons that are explained in the document, this work is limited to simple TE constraints and information that determine TE reachability. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-interconnected-te-info-exchange-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 8 16:47:47 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB631A1A7E; Mon, 8 Dec 2014 16:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 5B7fG7JMWlt6; Mon, 8 Dec 2014 16:47:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C95B41A1A87; Mon, 8 Dec 2014 16:47:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141209004741.27581.96816.idtracker@ietfa.amsl.com> Date: Mon, 08 Dec 2014 16:47:41 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/NGlRYeHD4snIn94d1pL-jsdrfL8 Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-gmpls-resource-sharing-proc-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 00:47:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : RSVP-TE Signaling Procedure for GMPLS Restoration and Resource Sharing- based LSP Setup and Teardown Authors : Xian Zhang Haomian Zheng Rakesh Gandhi Zafar Ali Gabriele Maria Galimberti Pawel Brzozowski Filename : draft-ietf-teas-gmpls-resource-sharing-proc-00.txt Pages : 19 Date : 2014-12-08 Abstract: In transport networks, there are requirements where Generalized Multi-Protocol Label Switching (GMPLS) end-to-end recovery scheme needs to employ restoration Label Switched Path (LSP) while keeping resources for the working and/or restoration LSPs reserved in the network after the failure occurs. This document reviews how the LSP association is to be provided using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the context of GMPLS end- to-end recovery when using restoration LSP where failed LSP is not torn down. This document compliments existing standards by explaining the missing pieces of information during the RSVP-TE signaling procedure in support of resource sharing-based LSP setup/teardown in GMPLS-controlled circuit networks. No new procedures or mechanisms are defined by this document, and it is strictly informative in nature. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-resource-sharing-proc/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-gmpls-resource-sharing-proc-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 8 16:53:18 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFF61A1ABB; Mon, 8 Dec 2014 16:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ZUoh5X9AC48z; Mon, 8 Dec 2014 16:53:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C00821A1A79; Mon, 8 Dec 2014 16:53:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141209005311.31815.10817.idtracker@ietfa.amsl.com> Date: Mon, 08 Dec 2014 16:53:11 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/ZgRlisPVs9hR0Ul5gO__uOmtRb8 Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 00:53:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : RSVP-TE Extensions for Associated Bidirectional LSPs Authors : Fei Zhang Ruiquan Jing Rakesh Gandhi Filename : draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-00.txt Pages : 18 Date : 2014-12-08 Abstract: This document describes Resource reSerVation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single sided provisioning. The REVERSE_LSP Object is also defined to enable a single endpoint to specify all the parameters of an associated LSP in the single sided provisioning case. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 8 16:56:31 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABFD1A1B11; Mon, 8 Dec 2014 16:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 AOd61c51oaEd; Mon, 8 Dec 2014 16:56:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F4A1A1AE0; Mon, 8 Dec 2014 16:56:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141209005618.32473.78172.idtracker@ietfa.amsl.com> Date: Mon, 08 Dec 2014 16:56:18 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/EwHGQdictYqixIDF2vGzQYMyaZY Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-p2mp-loose-path-reopt-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 00:56:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Extensions to Resource Reservation Protocol For Re-optimization of Loosely Routed Point-to-Multipoint Traffic Engineering LSPs Authors : Tarek Saad Rakesh Gandhi Zafar Ali Robert H. Venator Yuji Kamite Filename : draft-ietf-teas-p2mp-loose-path-reopt-00.txt Pages : 15 Date : 2014-12-08 Abstract: For a Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Path (LSP), it is preferable in some cases to re-evaluate and re-optimize the entire P2MP-TE LSP by re-signaling all its Source-to-Leaf (S2L) sub-LSP(s). Existing mechanisms, a mechanism for an ingress Label Switched Router (LSR) to trigger a new path re- evaluation request and a mechanism for a mid-point LSR to notify an availability of a preferred path, operate on an individual or a sub- group of S2L sub-LSP(s) basis only. This document defines RSVP-TE signaling extensions to allow an ingress node of a P2MP-TE LSP to request the re-evaluation of the entire LSP tree containing one or more S2L sub-LSPs whose paths are loose (or abstract) hop expanded, and for a mid-point LSR to notify to the ingress node that a preferable tree exists for the entire P2MP-TE LSP. This document also defines markers to indicate beginning and end of a S2L sub-LSP descriptor list when RSVP message needs to be fragmented due to large number of S2L sub-LSPs when performing re-optimization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-p2mp-loose-path-reopt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-p2mp-loose-path-reopt-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 8 19:20:21 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA981A1B39; Mon, 8 Dec 2014 19:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 qfoysURUltb3; Mon, 8 Dec 2014 19:20:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E18E1A1A1C; Mon, 8 Dec 2014 19:20:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141209032016.28335.16439.idtracker@ietfa.amsl.com> Date: Mon, 08 Dec 2014 19:20:16 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/NYsXohgJmCn6MzZ19iZEzqajZgg Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-domain-subobjects-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 03:20:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Domain Subobjects for Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) Authors : Dhruv Dhody Udayasree Palle Venugopal Reddy Kondreddy Ramon Casellas Filename : draft-ietf-teas-rsvp-te-domain-subobjects-00.txt Pages : 17 Date : 2014-12-08 Abstract: The Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) specification and the Generalized Multiprotocol Label Switching (GMPLS) extensions to RSVP-TE allow abstract nodes and resources to be explicitly included in a path setup. Further Exclude Routes extensions to RSVP-TE allow abstract nodes and resources to be explicitly excluded in a path setup. This document specifies new subobjects to include or exclude domains during path setup where domain is a collection of network elements within a common sphere of address management or path computational responsibility (such as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS)). Note that the use of AS as an abstract node representing domain is already defined in existing RSVP-TE specefications, albeit with a 2-Byte AS number. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-domain-subobjects/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-rsvp-te-domain-subobjects-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 9 10:36:33 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75CB1A1A47; Tue, 9 Dec 2014 10:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 CKS_cBARX86F; Tue, 9 Dec 2014 10:36:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A64351A01C6; Tue, 9 Dec 2014 10:36:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141209183627.3866.99288.idtracker@ietfa.amsl.com> Date: Tue, 09 Dec 2014 10:36:27 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/AdK1ZQR-9fK12zKNXIKWUkZkBE4 Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-lsp-attribute-ro-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 18:36:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : LSP Attribute in ERO Authors : Cyril Margaria Giovanni Martinelli Steve Balls Ben Wright Filename : draft-ietf-teas-lsp-attribute-ro-00.txt Pages : 12 Date : 2014-12-09 Abstract: RFC5420 extends RSVP-TE to specify or record generic attributes which apply to the whole of the path of an LSP. This document proposes an extension to the RSVP ERO and RRO objects to allow it to specify or record generic attributes which apply to a given hop. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 9 11:20:54 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35811A1A6B; Tue, 9 Dec 2014 11:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 sZpe4kCz9swa; Tue, 9 Dec 2014 11:20:46 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E08D1A1A0B; Tue, 9 Dec 2014 11:20:45 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB9JKiJ1029373; Tue, 9 Dec 2014 19:20:44 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB9JKhKi029359 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2014 19:20:43 GMT From: "Adrian Farrel" To: Date: Tue, 9 Dec 2014 19:20:38 -0000 Message-ID: <050101d013e5$374bafd0$a5e30f70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAT5TLZXbyXtQx0T72HlD0vpLYw0g== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21162.002 X-TM-AS-Result: No--22.025-10.0-31-10 X-imss-scan-details: No--22.025-10.0-31-10 X-TMASE-MatchedRID: 1EoU6PB/jT52f9pIfWMIbfHkpkyUphL9Ud7Bjfo+5jQGA3wiVVULSL6p QeH6jDekr3SNFzMXxmcig+A3HEvrTVDV9sDqOQY/ws9cphnKwlFKDzk/xkzLhvgnJH5vm2+gySZ h5ZDH/3dCEdV72rVr0l5CZfzX+mwoEXIhhl7oVxJCvapcIkxJX3+ogtHzaKWZqPm/sjj9KBhLbT Uf+O4SvEqUGrx94sBhN5PbzyayxNRfwHKlL7+0Q51U1lojafr/8GRhP/nTHNbmdb+WuOoLvCTCV wyY5KnUW95FEoC89hza0suL45wI5mk5Fql3Faa7akB4HtfbNkrAvdwvBqgdnkX5hc8ioB2+oXNW ARb9UYkOA4UfQTwRSFNEJON/RPQzy89ZiJ9C0P2RGzV8Bxg0cSIEB/X0tggGmyiLZetSf8nJ4y0 wP1A6AKEwgORH8p/Ar92rc8XRCCvdB/CxWTRRuyUIayx+Skid Archived-At: http://mailarchive.ietf.org/arch/msg/teas/lf2LNjulh-mwDjhUtaT8auF8n_Q Cc: ccamp@ietf.org Subject: [Teas] FW: [IANA #797657] IANA action consequent to RFC7260 (4106) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 19:20:49 -0000 FYI, IANA has completed actions on this Errata Report. Adrian > -----Original Message----- > From: Amanda Baber via RT [mailto:iana-issues@iana.org] > Sent: 09 December 2014 19:00 > To: Attila.Takacs@ericsson.com; adrian@olddog.co.uk; ccamp- > chairs@tools.ietf.org; don.fedyk@hp.com; gregory.mirsky@ericsson.com; > hejia@huawei.com > Subject: [IANA #797657] IANA action consequent to RFC7260 (4106) > > Hi, > > The registry now reads as follows: > > OAM Sub-TLVs > Reference: [RFC7260][RFC Errata 4106] > > Range Registration Procedures Note > 0-31 IETF Review Generic Sub-TLVs > 32-65533 IETF Review Technology-specific Sub-TLVs > 65534-65535 Reserved for Experimental Use Experimental Sub-TLVs > > Type Description Reference > 0 Reserved [RFC7260] > 1 OAM Function Flags Sub-TLV [RFC7260] > 2-31 Unassigned > 32 Ethernet OAM Configuration Sub-TLV [RFC7369] > 33-65533 Unassigned > 65534-65535 Reserved for Experimental Use [RFC7260][RFC Errata 4106] > > Please see > http://www.iana.org/assignments/rsvp-te-oam > > thanks, > > Amanda Baber > IANA Request Specialist > ICANN > > On Sun Dec 07 14:33:35 2014, adrian@olddog.co.uk wrote: > > Hi IANA, > > > > Could you please make the updates to > > https://www.iana.org/assignments/rsvp-te-oam/rsvp-te-oam.xhtml#oam- > > sub-tlvs as > > described in Errata Report 4106. > > > > Many thanks, > > Adrian > > > > > -----Original Message----- > > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > > Sent: 07 December 2014 14:22 > > > To: gregory.mirsky@ericsson.com; attila.takacs@ericsson.com; > > > don.fedyk@hp.com; hejia@huawei.com > > > Cc: adrian@olddog.co.uk; iesg@ietf.org; ccamp@ietf.org; rfc- > > editor@rfc- > > > editor.org > > > Subject: [Errata Verified] RFC7260 (4106) > > > > > > The following errata report has been verified for RFC7260, > > > "GMPLS RSVP-TE Extensions for Operations, Administration, and > > Maintenance > > > (OAM) Configuration". > > > > > > -------------------------------------- > > > You may review the report below and at: > > > http://www.rfc-editor.org/errata_search.php?rfc=7260&eid=4106 > > > > > > -------------------------------------- > > > Status: Verified > > > Type: Technical > > > > > > Reported by: Gregory Mirsky > > > Date Reported: 2014-09-08 > > > Verified by: Adrian Farrel (IESG) > > > > > > Section: 5.5.2 > > > > > > Original Text > > > ------------- > > > IANA has created the "OAM Sub-TLVs" sub-registry of the "RSVP-TE > > OAM > > > Configuration Registry" as follows: > > > > > > Range | Note | Registration > > Procedures > > > ------------+------------------------------ > > |------------------------ > > > 0-31 | Generic Sub-TLVs | IETF Review > > > 32-65534 | Technology-specific Sub-TLVs | IETF Review > > > 65535-65536 | Experimental Sub-TLVs | Reserved for > > > | | Experimental Use > > > > > > IANA has populated the registry as follows: > > > > > > Sub-TLV Type | Description | Reference > > > -------------+-------------------------------+---------- > > > 0 | Reserved | [RFC7260] > > > 1 | OAM Function Flags Sub-TLV | [RFC7260] > > > 2-65534 | Unassigned | > > > 65535-65536 | Reserved for Experimental Use | [RFC7260] > > > > > > > > > > > > Corrected Text > > > -------------- > > > IANA has created the "OAM Sub-TLVs" sub-registry of the "RSVP-TE > > OAM > > > Configuration Registry" as follows: > > > > > > Range | Note | Registration > > Procedures > > > ------------+------------------------------ > > |------------------------ > > > 0-31 | Generic Sub-TLVs | IETF Review > > > 32-65533 | Technology-specific Sub-TLVs | IETF Review > > > 65534-65535 | Experimental Sub-TLVs | Reserved for > > > | | Experimental Use > > > > > > IANA has populated the registry as follows: > > > > > > Sub-TLV Type | Description | Reference > > > -------------+-------------------------------+---------- > > > 0 | Reserved | [RFC7260] > > > 1 | OAM Function Flags Sub-TLV | [RFC7260] > > > 2-65533 | Unassigned | > > > 65534-65535 | Reserved for Experimental Use | [RFC7260] > > > > > > > > > Notes > > > ----- > > > Because the Type field is two octets long the value 65536 is > > unrealizable. > > > Nevertheless, it was the intention of the working group to assign to > > values as > > > experimental. > > > > > > -------------------------------------- > > > RFC7260 (draft-ietf-ccamp-oam-configuration-fwk-13) > > > -------------------------------------- > > > Title : GMPLS RSVP-TE Extensions for Operations, > > Administration, > > and > > > Maintenance (OAM) Configuration > > > Publication Date : June 2014 > > > Author(s) : A. Takacs, D. Fedyk, J. He > > > Category : PROPOSED STANDARD > > > Source : Common Control and Measurement Plane > > > Area : Routing > > > Stream : IETF > > > Verifying Party : IESG > > > From nobody Tue Dec 9 12:26:38 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0571A87CC for ; Tue, 9 Dec 2014 12:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 lVg685-6aBVO for ; Tue, 9 Dec 2014 12:26:32 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 5A86F1A87A2 for ; Tue, 9 Dec 2014 12:26:32 -0800 (PST) Received: (qmail 24607 invoked by uid 0); 9 Dec 2014 20:26:32 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 9 Dec 2014 20:26:31 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id RYST1p01H2SSUrH01YSW6y; Tue, 09 Dec 2014 13:26:31 -0700 X-Authority-Analysis: v=2.1 cv=dfgTgxne c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=r0y3BzD95n6FMLYuCL0A:9 a=wPNLvfGTeEIA:10 a=FRcMPD0NWuMA:10 a=_eJ8-KOQ5FkA:10 a=8ourH-WQn04A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=SOYQwLqdDgf/RoxzkA+gHCiAdEOg5cwCrtbyImWJM7k=; b=pplG/8/f8X5mzgPIyGZeyaHmd8jpeYkEjfPEm8zfAGY1V6JNmNZjvo1cly6c6HowNe44+kxQ+WXFJwh08tVL5UihfbLKGH9JVOREnKkB3ARCGrSREFez2B4TBZMGlqgV; Received: from box313.bluehost.com ([69.89.31.113]:41372 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XyRMZ-0001TB-Pl for teas@ietf.org; Tue, 09 Dec 2014 13:26:27 -0700 Message-ID: <54875AF2.3000409@labn.net> Date: Tue, 09 Dec 2014 15:26:26 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: TEAS WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/I0lluDMJedUjRhUp0FdfmbMfSi4 Subject: [Teas] TEAS WG Secretary X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 20:26:33 -0000 All, Matt Hartley will be the new TEAS WG Secretary. We received multiple volunteers for the role and we are very appreciative of all. Deborah and Lou From nobody Tue Dec 9 12:46:24 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF8A1A8876 for ; Tue, 9 Dec 2014 12:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 9mHd-dPSxWMq for ; Tue, 9 Dec 2014 12:46:21 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 085EF1A884F for ; Tue, 9 Dec 2014 12:46:20 -0800 (PST) Received: (qmail 12167 invoked by uid 0); 9 Dec 2014 20:46:19 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy5.mail.unifiedlayer.com with SMTP; 9 Dec 2014 20:46:19 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id RYmC1p00l2SSUrH01YmF2x; Tue, 09 Dec 2014 13:46:19 -0700 X-Authority-Analysis: v=2.1 cv=B+wqjodM c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=RWIhyqvsOIb-bm_tU_EA:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=DWgaxvWCFIv/swcrXB3SG6vXpyTShdg39UUYdoFcwV4=; b=ztwllilPCGYo6LBF66WDQxATEL/ulVQ99TdTUzIlEtPkMX9gY8UJ8dMmH09lF1pS8O+wguMbKv1ErkUjGPLeWsu5G7YLZSeDzbOkIcV4RzgFP6Ty2VVVPX7hvWD5X5M7; Received: from box313.bluehost.com ([69.89.31.113]:43179 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XyRfg-0006C7-8r; Tue, 09 Dec 2014 13:46:12 -0700 Message-ID: <54875F93.5050803@labn.net> Date: Tue, 09 Dec 2014 15:46:11 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: TEAS WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/vahtaEczCV1UySvY4rd1ipX4kc8 Cc: Matt Hartley , "BRUNGARD, DEBORAH A \(ATTLABS\)" Subject: [Teas] Call for virtual interim meeting agenda items X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 20:46:22 -0000 Hello, As previously announced, the TEAS WG will be holding a virtual interim meeting Thursday, Dec. 18, on the topic of the TE Topology Yang Model. The objective of the meeting is to discuss what this model covers and how it relates/ties-in to other work. If you'd like to present or discuss a particular topic, please let us (TEAS Chairs and Secretary) know by the end of the weekend, Dec. 14. We know the time isn't perfect for all, particularly those in Asia, and this will be considered when scheduling future virtual interim meetings. Thank you, Lou and Deborah From nobody Tue Dec 9 14:12:18 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EB21A1A46 for ; Tue, 9 Dec 2014 14:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 eKnC7Vf2hPWJ for ; Tue, 9 Dec 2014 14:12:14 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 250951A1A5C for ; Tue, 9 Dec 2014 14:12:08 -0800 (PST) Received: (qmail 18683 invoked by uid 0); 9 Dec 2014 22:12:07 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 9 Dec 2014 22:12:07 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id RaC41p0102SSUrH01aC7r9; Tue, 09 Dec 2014 15:12:07 -0700 X-Authority-Analysis: v=2.1 cv=W++rC3mk c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=Dyy578mpo6Co7ZfKBJwA:9 a=wPNLvfGTeEIA:10 a=yIPp8LBKVi4A:10 a=pzq3OyBkAV0A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=p8pdYTStQFjb9efwf/4lfzU0FD/bSTOEdjfyTuQacqg=; b=rspyEAbotVzKei8EAbCcHex3b3JntDL6QGU0FpcQmMrIHTJO3nxTljxhR7P4euoPRD6jRJhIX5yTTQcb+vPhk3u5iqHGLDEJlRp7in+kxVEnwAkgr3ybhTP+D9JCfZOd; Received: from box313.bluehost.com ([69.89.31.113]:51457 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XyT0m-00037V-CO for teas@ietf.org; Tue, 09 Dec 2014 15:12:04 -0700 Message-ID: <548773B3.1060302@labn.net> Date: Tue, 09 Dec 2014 17:12:03 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: TEAS WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/oLfkXBdme_fV0BlvwzUXGMk44xU Subject: [Teas] WG Milestones X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 22:12:16 -0000 All, The initial set of milestones for the WG have been posted, see https://datatracker.ietf.org/wg/teas/charter/ . The milestones can be updated as new (in charter) work is accepted by the WG. Let us know if you have any comments. Thanks, Lou (and Deborah) From nobody Tue Dec 9 14:14:03 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899E11A0162 for ; Tue, 9 Dec 2014 14:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 AuokHRjVCZQO for ; Tue, 9 Dec 2014 14:07:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2AE1A03C7 for ; Tue, 9 Dec 2014 14:07:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141209220715.8600.36967.idtracker@ietfa.amsl.com> Date: Tue, 09 Dec 2014 14:07:15 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/teas/KkhLc46Rd-iChVufQpL_1uQkxuk X-Mailman-Approved-At: Tue, 09 Dec 2014 14:14:01 -0800 Subject: [Teas] Milestones changed for teas WG X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 22:07:24 -0000 Added milestone "Transition in charter work from MPLS and CCAMP WGs", due December 2014. Added milestone "Initiate TE Yang Model work via interim and Design Teams", due December 2014. Added milestone "Adopt Requirements for Very Fast Setup", due December 2014. Added milestone "Submit -mpls-tp-rsvpte-ext-associated-lsp to IESG for publication", due December 2014. Added milestone "Submit -lsp-attribute-ro to IESG for publication", due January 2015. Added milestone "Submit -rsvp-te-li-lb to IESG for publication", due January 2015. Added milestone "Submit -ietf-ccamp-rsvp-te-srlg-collect to IESG for publication", due January 2015. Added milestone "Initial TE LSP Yang Model WG document", due April 2015. Added milestone "Initial TE Topology Yang Model WG document", due April 2015. Added milestone "Close initial TE Yang Model Design Teams", due April 2015. Added milestone "Submit loose path reoptimization to IESG for publication", due April 2015. Added milestone "Submit metric recording to IESG for publication", due May 2015. Added milestone "Submit XRO based LSP Diversity to IESG for publication", due July 2015. Added milestone "Submit ingress/egress protection documents to IESG for publication", due August 2015. Added milestone "Adopt interconnected TE network solution document", due August 2015. Added milestone "Submit domain subobjects to IESG for publication", due September 2015. Added milestone "Adopt Very Fast Setup informational document", due November 2015. Added milestone "Submit network assigned upstream label to IESG for publication", due December 2015. Added milestone "Submit Requirements for Very Fast Setup to IESG for publication", due December 2015. Added milestone "Submit Resource sharing draft to IESG for publication", due January 2016. Added milestone "Submit first interconnected TE network document to IESG for publication", due March 2016. Added milestone "Submit TE LSP Yang Models to IESG for publication", due June 2016. Added milestone "Submit TE Topology Yang Models to IESG for publication", due June 2016. Added milestone "Submit interconnected TE network solution document to IESG for publication", due September 2016. Added milestone "Submit Very Fast Setup informational document to IESG for publication", due November 2016. Added milestone "Revisit WG status (close if no milestones/deliverables)", due November 2016. URL: http://datatracker.ietf.org/wg/teas/charter/ From nobody Tue Dec 9 14:14:04 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFCF1A1A17 for ; Tue, 9 Dec 2014 14:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 9Q8yjVGxsvH0 for ; Tue, 9 Dec 2014 14:09:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D791A0074 for ; Tue, 9 Dec 2014 14:09:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141209220913.12344.70806.idtracker@ietfa.amsl.com> Date: Tue, 09 Dec 2014 14:09:13 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/teas/q_XjgG3TwHZ4NaR871y85IHjfkM X-Mailman-Approved-At: Tue, 09 Dec 2014 14:14:01 -0800 Subject: [Teas] Milestones changed for teas WG X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 22:09:21 -0000 Changed milestone "Adopt interconnected TE network solution document", removed draft-ietf-teas-interconnected-te-info-exchange from milestone. URL: http://datatracker.ietf.org/wg/teas/charter/ From nobody Tue Dec 9 17:15:49 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D73C1A1AD0; Tue, 9 Dec 2014 17:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 WtumYGpXUU8e; Tue, 9 Dec 2014 17:15:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CA11A036E; Tue, 9 Dec 2014 17:15:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210011546.10066.70433.idtracker@ietfa.amsl.com> Date: Tue, 09 Dec 2014 17:15:46 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/-WNecD-4nTlpDBkze5hIkwydlfw Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-network-assigned-upstream-label-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 01:15:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Network Assigned Upstream-Label Authors : Vishnu Pavan Beeram Igor Bryskin Filename : draft-ietf-teas-network-assigned-upstream-label-00.txt Pages : 9 Date : 2014-12-09 Abstract: This document discusses a GMPLS RSVP-TE protocol mechanism that enables the network to assign an upstream-label for a given LSP. This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream-label on its own and needs to rely on the network to pick an appropriate label. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-network-assigned-upstream-label/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-network-assigned-upstream-label-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 10 22:27:07 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8841A88C2; Wed, 10 Dec 2014 22:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham 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 hIpYS1BYishV; Wed, 10 Dec 2014 22:26:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8111A19E3; Wed, 10 Dec 2014 22:26:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141211062657.18100.87430.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 22:26:57 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/NTEAzFQ4EEscBojUIxgFD_TOfBY Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-lsp-diversity-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 06:27:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route Authors : Zafar Ali George Swallow Fatai Zhang Dieter Beller Filename : draft-ietf-teas-lsp-diversity-00.txt Pages : 27 Date : 2014-12-10 Abstract: RFC 4874 specifies methods by which path exclusions can be communicated during RSVP-TE signaling in networks where precise explicit paths are not computed by the LSP source node. This document specifies procedures for additional route exclusion subobject based on Paths currently existing or expected to exist within the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-lsp-diversity-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 10 22:27:32 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3811A854A; Wed, 10 Dec 2014 22:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham 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 4DyHjxC_rTNl; Wed, 10 Dec 2014 22:27:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0EB1A8942; Wed, 10 Dec 2014 22:27:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141211062718.22336.25250.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 22:27:18 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/cR0JQsne-wxxcqgTdzOAM6OhDs8 Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-te-metric-recording-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 06:27:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for recording TE Metric of a Label Switched Path Authors : Zafar Ali George Swallow Clarence Filsfils Matt Hartley Kenji Kumaki Deutsche Telekom AG Filename : draft-ietf-teas-te-metric-recording-00.txt Pages : 15 Date : 2014-12-10 Abstract: There are many scenarios in which Traffic Engineering (TE) metrics such as cost, latency and latency variation associated with a Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched Path (LSP) are not available to the ingress and egress nodes. This draft provides extensions for the Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) for the support of the discovery of cost, latency and latency variation of an LSP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-te-metric-recording/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-te-metric-recording-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 11 02:58:43 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5171ACD89 for ; Thu, 11 Dec 2014 02:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 XyTC4ggqDrdQ for ; Thu, 11 Dec 2014 02:58:37 -0800 (PST) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7701A878C for ; Thu, 11 Dec 2014 02:58:36 -0800 (PST) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B0D072F0604; Thu, 11 Dec 2014 11:58:33 +0100 (CET) Received: from ESTGVMSP105.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id A13652F05E2; Thu, 11 Dec 2014 11:58:33 +0100 (CET) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.51) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 11 Dec 2014 11:58:33 +0100 Received: from AM2PR06MB0657.eurprd06.prod.outlook.com (25.161.18.151) by AM2PR06MB0658.eurprd06.prod.outlook.com (25.161.18.152) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 11 Dec 2014 10:58:32 +0000 Received: from AM2PR06MB0657.eurprd06.prod.outlook.com ([25.161.18.151]) by AM2PR06MB0657.eurprd06.prod.outlook.com ([25.161.18.151]) with mapi id 15.01.0031.000; Thu, 11 Dec 2014 10:58:32 +0000 From: OSCAR GONZALEZ DE DIOS To: Lou Berger , "draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org" Thread-Topic: Please republish re-homed TEAS WG documents Thread-Index: AQHQEzeV2kx/ATSMmkas8bGzIYRcQZyKTR6A Date: Thu, 11 Dec 2014 10:58:31 +0000 Message-ID: References: <54860F0D.9090900@labn.net> In-Reply-To: <54860F0D.9090900@labn.net> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [195.235.92.36] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:AM2PR06MB0658; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:AM2PR06MB0658; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(51704005)(189002)(199003)(479174003)(107046002)(92566001)(101416001)(106356001)(77156002)(36756003)(102836002)(62966003)(68736005)(15975445007)(120916001)(40100003)(20776003)(86362001)(21056001)(64706001)(97736003)(83506001)(122556002)(46102003)(4396001)(105586002)(76176999)(99396003)(54356999)(87936001)(2656002)(50986999)(19580395003)(66066001)(31966008)(19580405001)(106116001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR06MB0658; H:AM2PR06MB0657.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <17CA1B8FAB7BE045A691DEDCC2EBC5C9@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/teas/vIvmVF4FbknpEGJyru9hZhgZMKY Cc: TEAS WG Subject: Re: [Teas] Please republish re-homed TEAS WG documents X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 10:58:40 -0000 Dear Lou, Deborah draft-ietf-ccamp-rsvp-te-srlg-collect-09 has been posted as draft-ietf-teas-rsvp-te-srlg-collect-00. The submission is pending your approval. Best Regards, =D3scar El 08/12/14 21:50, "Lou Berger" escribi=F3: >Hello, > As discussed in the last meeting, the drafts listed in the To: lines >above have been moved over to the new TEAS WG. (See >https://datatracker.ietf.org/wg/teas/documents/) The current state shows >the right WG ownership, but wrong draft names. To correct this: > >Authors, > Please republish your draft as draft-ietf-teas-...-00 as soon as you >can. *without any other changes please*. > >Once the draft is uploaded, it will be approved and we will set the >replace-by information to maintain history. This will also result in >only the -00 version being listed under teas. > >Note that there are 4 documents that are in or post LC. Authors should >still follow the above direction, i.e., resubmit the version that is in >/ went through LC as the -00 version. LC related updates should then be >made to the -01 versions of the draft. > >Much thanks, >Lou (and Deborah) > > > ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o From nobody Thu Dec 11 05:07:50 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289C91ACE46 for ; Thu, 11 Dec 2014 05:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 r8Io8mF5Kcwh for ; Thu, 11 Dec 2014 05:07:37 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id A965B1ACE2E for ; Thu, 11 Dec 2014 05:07:37 -0800 (PST) Received: (qmail 25565 invoked by uid 0); 11 Dec 2014 13:07:27 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 11 Dec 2014 13:07:27 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id SD7P1p01G2SSUrH01D7S6A; Thu, 11 Dec 2014 06:07:28 -0700 X-Authority-Analysis: v=2.1 cv=OJu0g0qB c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=OUXY8nFuAAAA:8 a=pmb6BNNbAAAA:8 a=OTfaxyS_AAAA:8 a=0FD05c-RAAAA:8 a=AUd_NHdVAAAA:8 a=FmoMKUsJAAAA:8 a=U1k2Jpg8bEbLqpgLyY0A:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=dnfLvBDt5yER/ipMR33BL1hyyHR9F53Blb3agGjIgbE=; b=1auvKjWlsvQ0BpkAKMo9zl/8ESa2Y4lrBOlzOViRBNNrU6XB3aLsxK+tcIfn4h1QkxujCV8W0sN+UFvUm5i5F+SrdRdVyFZkDZqXfy9Mq39cal/gMFo+gEXM9PsSIh/Z; Received: from box313.bluehost.com ([69.89.31.113]:38098 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Xz3Sj-0001pR-Tz for teas@ietf.org; Thu, 11 Dec 2014 06:07:23 -0700 Message-ID: <5489970B.7070108@labn.net> Date: Thu, 11 Dec 2014 08:07:23 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: TEAS WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/OBMi06MBwUATkIQJ5xtChML-ppo Subject: [Teas] TE Topology YANG Model Design Team X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 13:07:48 -0000 All, We have formed a WG Design Team whose objective is to deliver a TE Topology YANG Model draft in time for discussion in Dallas. It is our intent that the document will become a TEAS WG draft post Dallas. The scope of the design team is intentionally narrow and the work of the DT will need to be coordinated with other related YANG work -- and such coordination is the focus of next week's interim meeting*. The DT will be closed once we have a WG document adopted on this topic. While the DT has limited membership (and a limited lifespan), how the DT works to produce it's individual draft(s) is up to the DT. For example they may choose to publicize their calls/progress or not. We do appreciate that not all who volunteered are include. Those who are willing to provide input to the DT should contact them directly. Keep in mind that there will be plenty of opportunity for input, per normal WG process, once the DT's individual draft(s) are adopted as WG documents. Again, thank you to all who volunteered. * - Next week's interim is of course open to all -- and we have an open call for those who wish a discussion slot. The focus of the interim is on the scope of the TE Topology YANG model and how it relates/ties-in to other work. The members of the DT are: Vishnu Pavan Beeram Igor Bryskin Oscar Gonzalez De Dios Xufeng Liu Tarek Saad Himanshu Shah Deborah and Lou From nobody Thu Dec 11 19:59:43 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB421A1B0A for ; Thu, 11 Dec 2014 19:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4e8Yx8dAMY9Z for ; Thu, 11 Dec 2014 19:59:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5CE11A889A for ; Thu, 11 Dec 2014 19:59:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMT51710; Fri, 12 Dec 2014 03:59:38 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 12 Dec 2014 03:59:37 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.128]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 12 Dec 2014 11:59:30 +0800 From: "Dongjie (Jimmy)" To: Lou Berger Thread-Topic: [Teas] Please republish re-homed TEAS WG documents Thread-Index: AQHQEyjKs5mIFrh4fkq2gjtchjZFwpyLWMqg Date: Fri, 12 Dec 2014 03:59:29 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927337E4CC5@nkgeml512-mbx.china.huawei.com> References: <54860F0D.9090900@labn.net> In-Reply-To: <54860F0D.9090900@labn.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/teas/ohSzc95WcCidDmRbD1viYNS1pgg Cc: TEAS WG Subject: Re: [Teas] Please republish re-homed TEAS WG documents X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 03:59:42 -0000 Dear Chairs, I have posted draft-ietf-teas-rsvp-te-li-lb-00, the submission is pending f= or your approval.=20 Best regards, Jie > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Tuesday, December 09, 2014 4:50 AM > To: draft-ietf-ccamp-gmpls-resource-sharing-proc@tools.ietf.org; > draft-ietf-ccamp-interconnected-te-info-exchange@tools.ietf.org; > draft-ietf-ccamp-lsp-attribute-ro@tools.ietf.org; > draft-ietf-ccamp-lsp-diversity@tools.ietf.org; > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org; > draft-ietf-ccamp-network-assigned-upstream-label@tools.ietf.org; > draft-ietf-ccamp-rsvp-te-domain-subobjects@tools.ietf.org; > draft-ietf-ccamp-rsvp-te-li-lb@tools.ietf.org; > draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org; > draft-ietf-ccamp-te-metric-recording@tools.ietf.org; > draft-ietf-mpls-p2mp-loose-path-reopt@tools.ietf.org; > draft-ietf-mpls-rsvp-egress-protection@tools.ietf.org; > draft-ietf-mpls-rsvp-ingress-protection@tools.ietf.org > Cc: TEAS WG > Subject: [Teas] Please republish re-homed TEAS WG documents >=20 > Hello, > As discussed in the last meeting, the drafts listed in the To: lines = above have > been moved over to the new TEAS WG. (See > https://datatracker.ietf.org/wg/teas/documents/) The current state shows = the > right WG ownership, but wrong draft names. To correct this: >=20 > Authors, > Please republish your draft as draft-ietf-teas-...-00 as soon as you = can. > *without any other changes please*. >=20 > Once the draft is uploaded, it will be approved and we will set the repla= ce-by > information to maintain history. This will also result in only the -00 v= ersion > being listed under teas. >=20 > Note that there are 4 documents that are in or post LC. Authors should s= till > follow the above direction, i.e., resubmit the version that is in / went = through > LC as the -00 version. LC related updates should then be made to the -01 > versions of the draft. >=20 > Much thanks, > Lou (and Deborah) >=20 >=20 >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Fri Dec 12 03:32:02 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE94C1ACCDF; Fri, 12 Dec 2014 03:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 VP16FCQvEb40; Fri, 12 Dec 2014 03:31:58 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0671ACCFC; Fri, 12 Dec 2014 03:31:58 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id c22da845.0.1681344.00-2275.4674903.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 12 Dec 2014 11:31:58 +0000 (UTC) X-MXL-Hash: 548ad22e473d978d-16e1b6ed395809ffc0dc127b4f06cd3616420112 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id sBCBVuLu032530; Fri, 12 Dec 2014 06:31:56 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id sBCBVlqL032440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Dec 2014 06:31:52 -0500 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 12 Dec 2014 11:31:26 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.4]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 06:31:25 -0500 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" , "teas@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-malis-ccamp-fast-lsps-04.txt WGdocument-finished Thread-Index: AdAV/x5rmS/jDkcwS6KbwxHaWaBsEw== Date: Fri, 12 Dec 2014 11:31:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.100.206] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C81671FEB2MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=PLW4D4WC c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=qGeyq6bnXw8A:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=6395D88C4x] X-AnalysisOut: [ZvPChkB50A:9 a=CjuIK1q_8ugA:10 a=yMhMjlubAAAA:8 a=SSmOFEAC] X-AnalysisOut: [AAAA:8 a=G28er6LM9AxeAaCjsaoA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L] X-AnalysisOut: [4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=VT9ElSU5Y2] X-AnalysisOut: [7axtdY:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/teas/hh5LCvbPX8azCIhGvzLVA1_WL7g Subject: Re: [Teas] [CCAMP] Poll on making draft-malis-ccamp-fast-lsps-04.txt WGdocument-finished X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 11:32:01 -0000 --_000_F64C10EAA68C8044B33656FA214632C81671FEB2MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This poll is over. We have good support for being a WG document. Authors, please upload as (take note of the slight title change): draft-iet= f-teas-fast-lsps-requirements-00 Thanks, Deborah and Lou From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH = A Sent: Wednesday, November 26, 2014 1:06 PM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-malis-ccamp-fast-lsps-04.txt WG docum= ent All, This is start a two week poll on making the above draft a ccamp working gro= up document. Please send email to the list indicating "yes/support" or "no/= do not support". If indicating no, please state your technical reservations= with the document. The poll ends Thursday, Dec. 11th. Thanks, Deborah and Lou --_000_F64C10EAA68C8044B33656FA214632C81671FEB2MISOUT7MSGUSRDE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This poll is over. We hav= e good support for being a WG document.

 <= /p>

Authors, please upload as= (take note of the slight title change): draft-ietf-teas-fast-lsps-requirem= ents-00

 <= /p>

Thanks,=

Deborah and Lou

 <= /p>

 <= /p>

From: CCAMP [m= ailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Wednesday, November 26, 2014 1:06 PM
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-malis-ccamp-fast-lsps-04.txt W= G document

 

All,

 

This is start a two week poll on making= the above draft a ccamp working group document. Please send email to the l= ist indicating “yes/support” or “no/do not support”= . If indicating no, please state your technical reservations with the document.=

 

The poll ends Thursday, Dec. 11th.=

 

Thanks,

Deborah and Lou

 

--_000_F64C10EAA68C8044B33656FA214632C81671FEB2MISOUT7MSGUSRDE_-- From nobody Fri Dec 12 05:29:43 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EC51A6FFA; Fri, 12 Dec 2014 05:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ARgWrhJq7uTD; Fri, 12 Dec 2014 05:29:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5820A1A1B07; Fri, 12 Dec 2014 05:29:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141212132936.27258.93503.idtracker@ietfa.amsl.com> Date: Fri, 12 Dec 2014 05:29:36 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/l4C7TXV8ZSsV28A56D8PjzI0Kwg Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 13:29:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : GMPLS RSVP-TE Extensions for Lock Instruct and Loopback Authors : Jie Dong Mach(Guoyi) Chen Zhenqiang Li Daniele Ceccarelli Filename : draft-ietf-teas-rsvp-te-li-lb-00.txt Pages : 9 Date : 2014-12-10 Abstract: This document specifies extensions to Resource Reservation Protocol- Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies which use Generalized Multi-Protocol Label Switching (GMPLS) as control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-li-lb/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-rsvp-te-li-lb-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 12 05:32:04 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0EB1A1EEA; Fri, 12 Dec 2014 05:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Dl9sDSe5cQAf; Fri, 12 Dec 2014 05:31:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9981A8A48; Fri, 12 Dec 2014 05:31:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141212133159.27258.13341.idtracker@ietfa.amsl.com> Date: Fri, 12 Dec 2014 05:31:59 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/-zq7MCSeZiueePhl_nxshdn2gJk Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 13:32:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : RSVP-TE Extensions for Collecting SRLG Information Authors : Fatai Zhang Oscar Gonzalez de Dios Dan Li Cyril Margaria Matt Hartley Zafar Ali Filename : draft-ietf-teas-rsvp-te-srlg-collect-00.txt Pages : 13 Date : 2014-12-11 Abstract: This document provides extensions for the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 12 05:37:46 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE871ACD1C for ; Fri, 12 Dec 2014 05:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 RGJ-U-jySIwe for ; Fri, 12 Dec 2014 05:37:43 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 9EB911ACD11 for ; Fri, 12 Dec 2014 05:37:43 -0800 (PST) Received: (qmail 25120 invoked by uid 0); 12 Dec 2014 13:37:43 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy9.mail.unifiedlayer.com with SMTP; 12 Dec 2014 13:37:43 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id Sddg1p00S2SSUrH01ddjAd; Fri, 12 Dec 2014 06:37:43 -0700 X-Authority-Analysis: v=2.1 cv=OJu0g0qB c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=WNqqlRACvrdKLM01WFkA:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=rC4F7HoJgxKoImzRMOvgCCwkZurt0U0O4AXfk4YTiAA=; b=KxTGku4jakoRZ0ybIrGgSlrzh9bsbPMLnUUOX4BoVX2lYJTi+aSax3OA5oX4k8CnMv9sxFCIOCDmcIA8m9PS0d5EfOz+wLI3hf+yGtl/S4Rf7osczB/a2SceVk0OoQME; Received: from box313.bluehost.com ([69.89.31.113]:54822 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XzQPc-0007Q5-07; Fri, 12 Dec 2014 06:37:40 -0700 Message-ID: <548AEFAB.50708@labn.net> Date: Fri, 12 Dec 2014 08:37:47 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: CCAMP , TEAS WG , "draft-ietf-ccamp-rsvp-te-li-lb@tools.ietf.org" References: <547650A3.3090007@labn.net> In-Reply-To: <547650A3.3090007@labn.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/ubqvOLUfvpmO9rnDXmf3S0jG_RI Subject: Re: [Teas] [CCAMP] WG Last Call on draft-ietf-ccamp-rsvp-te-li-lb-06 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 13:37:44 -0000 The WG LC is now closed for this now *TEAS* WG document. (Yes this continues the really odd side effect of the WG changes.) Please direct future discussion, including follow up to LC comments, on this document to the TEAS WG. Note draft-ietf-ccamp-rsvp-te-li-lb-06 has already been republished as draft-ietf-teas-rsvp-te-li-lb-00. Authors, Please discuss any issues raised (on the TEAS WG list) and submit updates using the name draft-ietf-teas-rsvp-te-li-lb. Thank you! Lou (and Deborah) On 11/26/2014 5:13 PM, Lou Berger wrote: > All, > This starts a two-week working group last call on > draft-ietf-ccamp-rsvp-te-li-lb-06. > > This working group last call ends on Thursday December 11th. Please > send your comments to the CCAMP mailing list. > > As is always the case, positive comments, e.g., "I've reviewed this > document and believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Thanks, > Lou (and Deborah) > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From nobody Fri Dec 12 05:40:43 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1221ACD27 for ; Fri, 12 Dec 2014 05:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 J_9o719p_jG6 for ; Fri, 12 Dec 2014 05:40:32 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id EE3441ACD1C for ; Fri, 12 Dec 2014 05:40:31 -0800 (PST) Received: (qmail 31378 invoked by uid 0); 12 Dec 2014 13:40:31 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy9.mail.unifiedlayer.com with SMTP; 12 Dec 2014 13:40:31 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id SdgN1p0062SSUrH01dgRGt; Fri, 12 Dec 2014 06:40:31 -0700 X-Authority-Analysis: v=2.1 cv=W++rC3mk c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=WNqqlRACvrdKLM01WFkA:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=IPPCUzGlLYXO5BHOloZE4VdIKgPULB5B5AS2FfPL/kw=; b=jbugHf5A9qwHnnUI07xWXFv68uYt6tKqbfY3JajJysy1+GvVH82rBX38Q6PlBKUZT2l+n1LsE+0Stl9DKgc3IEYygCNrL62DdRVtn41oNMWJXHqregfS7G7f0G+BP70L; Received: from box313.bluehost.com ([69.89.31.113]:55260 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XzQSD-00089M-UB; Fri, 12 Dec 2014 06:40:22 -0700 Message-ID: <548AF04D.6080207@labn.net> Date: Fri, 12 Dec 2014 08:40:29 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: CCAMP , TEAS WG , "draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org" References: <5476508D.7040807@labn.net> In-Reply-To: <5476508D.7040807@labn.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/dTulWi8lASsJIoUi7onP6NNLyZs Subject: Re: [Teas] [CCAMP] WG Last Call on draft-ietf-ccamp-rsvp-te-srlg-collect-09 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 13:40:33 -0000 The WG LC is now closed for this now *TEAS* WG document. (Yes this completes the really odd side effect of the WG changes.) Please direct future discussion, including follow up to LC comments, on this document to the TEAS WG. Note draft-ietf-ccamp-rsvp-te-srlg-collect-09 has already been republished as draft-ietf-teas-rsvp-te-srlg-collect-00. Authors, Please discuss any issues raised (on the TEAS WG list) and submit updates using the name draft-ietf-teas-rsvp-te-srlg-collect. Thank you! Lou (and Deborah) On 11/26/2014 5:13 PM, Lou Berger wrote: > All, > This starts a two-week working group last call on > draft-ietf-ccamp-rsvp-te-srlg-collect-09. > > This working group last call ends on Thursday December 11th. Please > send your comments to the CCAMP mailing list. > > As is always the case, positive comments, e.g., "I've reviewed this > document and believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Note, IPR has been disclosed on this draft. > > Thanks, > Lou (and Deborah) > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From nobody Fri Dec 12 05:55:37 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56941A047A; Fri, 12 Dec 2014 05:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 GmAXTzOojnRS; Fri, 12 Dec 2014 05:55:32 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7E281AC399; Fri, 12 Dec 2014 05:55:31 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id e89so5481476qgf.10 for ; Fri, 12 Dec 2014 05:55:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/1JmKkDVq41U4CH6u54f79YKXU/QtEzHx7cpSrGJQRQ=; b=IiaC7F6WRCKDRlltqrv65Ka8wdoFhmLg/BHa6bWg28ttc2+jZ/3paATIHY0pzNTtr6 G6IaBlfgV4SKKNXfOC/BmuXEYOKfKXEwtl87xCdiy2cJETQ0eHtuVATXjB2b6cvLP7DC 8W5Hj/JfEpChmoMr11FIFKVHfFCwsTFo/jHrMjlLHFXDW8WeEZwl+goCV20z04GY/oly gD5f75wUuwYLhKFB8T1WpBNQvzMGO8jJCotJx/Z9cg3amXsIC/V4LHcxCN9g65erdS9l D4oAnau5tPxoXwxixS8JqCgnu9I/ru/1I/urFhYZb/EHSyfeWhDtKc6omuHoy4HFj/4x S/Pg== X-Received: by 10.224.93.6 with SMTP id t6mr30683910qam.93.1418392530805; Fri, 12 Dec 2014 05:55:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.20.143 with HTTP; Fri, 12 Dec 2014 05:55:10 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Fri, 12 Dec 2014 08:55:10 -0500 Message-ID: To: "BRUNGARD, DEBORAH A" Content-Type: multipart/alternative; boundary=089e01495028f3692a050a053e9e Archived-At: http://mailarchive.ietf.org/arch/msg/teas/88_wc7kbjVTRnQ8CpjSsodKLlXk Cc: "ccamp@ietf.org" , "teas@ietf.org" Subject: Re: [Teas] [CCAMP] Poll on making draft-malis-ccamp-fast-lsps-04.txt WGdocument-finished X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 13:55:34 -0000 --089e01495028f3692a050a053e9e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Deborah, I've just submitted draft-ietf-teas-fast-lsps-requirements-00 for your approval. The only changes are the draft's name and date. Thanks, Andy On Fri, Dec 12, 2014 at 6:31 AM, BRUNGARD, DEBORAH A wrote= : > This poll is over. We have good support for being a WG document. > > > > Authors, please upload as (take note of the slight title change): > draft-ietf-teas-fast-lsps-requirements-00 > > > > Thanks, > > Deborah and Lou > > > > > > *From:* CCAMP [mailto:ccamp-bounces@ietf.org] *On Behalf Of *BRUNGARD, > DEBORAH A > *Sent:* Wednesday, November 26, 2014 1:06 PM > *To:* ccamp@ietf.org > *Subject:* [CCAMP] Poll on making draft-malis-ccamp-fast-lsps-04.txt WG > document > > > > All, > > > > This is start a two week poll on making the above draft a ccamp working > group document. Please send email to the list indicating =E2=80=9Cyes/sup= port=E2=80=9D or > =E2=80=9Cno/do not support=E2=80=9D. If indicating no, please state your = technical > reservations with the document. > > > > The poll ends Thursday, Dec. 11th. > > > > Thanks, > > Deborah and Lou > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > --089e01495028f3692a050a053e9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Deborah,

I've just submitted=C2=A0<= span style=3D"color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size= :15px">draft-ietf-teas-fast-lsps-requirements-00 for your ap= proval. The only changes are the draft's name and date.

Thanks,
An= dy

On Fri, Dec 12, 2014 at 6:31 AM, BRUNGARD, DEBORAH A = <db3546@att.com&= gt; wrote:

This poll is over. We hav= e good support for being a WG document.

=C2=A0

Authors, please upload as= (take note of the slight title change): draft-ietf-teas-fast-lsps-requirem= ents-00

=C2=A0

Thanks,

Deborah and Lou=

=C2=A0

=C2=A0

From: CCAMP [m= ailto:ccamp-bou= nces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Wednesday, November 26, 2014 1:06 PM
To: ccamp@ietf.o= rg
Subject: [CCAMP] Poll on making draft-malis-ccamp-fast-lsps-04.txt W= G document

=C2=A0<= /p>

All,

=C2=A0

This is start a two week poll on making= the above draft a ccamp working group document. Please send email to the l= ist indicating =E2=80=9Cyes/support=E2=80=9D or =E2=80=9Cno/do not support= =E2=80=9D. If indicating no, please state your technical reservations with the document.=

=C2=A0

The poll ends Thursday, Dec. 11th.

=C2=A0

Thanks,

Deborah and Lou

=C2=A0


_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas


--089e01495028f3692a050a053e9e-- From nobody Fri Dec 12 05:55:43 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7951ACCDF for ; Fri, 12 Dec 2014 05:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 GE71zr4KI0bM for ; Fri, 12 Dec 2014 05:55:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DE01ACD2D for ; Fri, 12 Dec 2014 05:55:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141212135537.5656.35755.idtracker@ietfa.amsl.com> Date: Fri, 12 Dec 2014 05:55:37 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/teas/Wi3sF9K9OjdKNzlNurqllkbFCKk Subject: [Teas] Milestones changed for teas WG X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 13:55:41 -0000 Changed milestone "Submit -rsvp-te-li-lb to IESG for publication", added draft-ietf-teas-rsvp-te-li-lb to milestone, removed draft-ietf-ccamp-rsvp-te-li-lb from milestone. Changed milestone "Submit -ietf-ccamp-rsvp-te-srlg-collect to IESG for publication", added draft-ietf-teas-rsvp-te-srlg-collect to milestone, removed draft-ietf-ccamp-rsvp-te-srlg-collect from milestone. Changed milestone "Submit metric recording to IESG for publication", added draft-ietf-teas-te-metric-recording to milestone, removed draft-ietf-ccamp-te-metric-recording from milestone. Changed milestone "Submit XRO based LSP Diversity to IESG for publication", added draft-ietf-teas-lsp-diversity to milestone, removed draft-ietf-ccamp-lsp-diversity from milestone. Changed milestone "Submit network assigned upstream label to IESG for publication", added draft-ietf-teas-network-assigned-upstream-label to milestone, removed draft-ietf-ccamp-network-assigned-upstream-label from milestone. URL: http://datatracker.ietf.org/wg/teas/charter/ From nobody Fri Dec 12 06:28:13 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CBB1ACD49; Fri, 12 Dec 2014 06:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 6t1B5lmPKSe8; Fri, 12 Dec 2014 06:28:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4F51ACD13; Fri, 12 Dec 2014 06:28:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141212142806.12903.67914.idtracker@ietfa.amsl.com> Date: Fri, 12 Dec 2014 06:28:06 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/mRMsdptGe-BDYTAUzsAgw8H5NwE Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-fast-lsps-requirements-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 14:28:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Requirements for Very Fast Setup of GMPLS LSPs Authors : Andrew G. Malis Ronald A. Skoog Haim Kobrinski George Clapp Vishnu Shukla Filename : draft-ietf-teas-fast-lsps-requirements-00.txt Pages : 8 Date : 2014-12-12 Abstract: Establishment and control of Label Switch Paths (LSPs) have become mainstream tools of commercial and government network providers. One of the elements of further evolving such networks is scaling their performance in terms of LSP bandwidth and traffic loads, LSP intensity (e.g., rate of LSP creation, deletion, and modification), LSP set up delay, quality of service differentiation, and different levels of resilience. The goal of this document is to present target scaling objectives and the related protocol requirements for Generalized Multi-Protocol Label Switching (GMPLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-fast-lsps-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-fast-lsps-requirements-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 12 09:26:13 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BE81A1A9C; Fri, 12 Dec 2014 09:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 HVtXCKwestrE; Fri, 12 Dec 2014 09:26:02 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00CCA1A1AF6; Fri, 12 Dec 2014 09:26:01 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-ef-548b2527dea6 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9C.90.04231.7252B845; Fri, 12 Dec 2014 18:26:00 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.89]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 18:25:59 +0100 From: Daniele Ceccarelli To: Lou Berger , CCAMP , TEAS WG , "draft-ietf-ccamp-rsvp-te-li-lb@tools.ietf.org" Thread-Topic: [Teas] [CCAMP] WG Last Call on draft-ietf-ccamp-rsvp-te-li-lb-06 Thread-Index: AQHQFhDSWQnpi2fZKU6b8NTjjsM8PpyMNNVA Date: Fri, 12 Dec 2014 17:25:59 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481280DEA9@ESESSMB301.ericsson.se> References: <547650A3.3090007@labn.net> <548AEFAB.50708@labn.net> In-Reply-To: <548AEFAB.50708@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvja6GaneIwb8WVosnc26wWHSuL7Do aH7LYtH6YweLA4vHkiU/mTw+bGpm8/hy+TNbAHMUl01Kak5mWWqRvl0CV8bJrmfsBZ18Fe8a +hgbGDdwdzFyckgImEgsenCDHcIWk7hwbz1bFyMXh5DAEUaJudOesoEkhAQWM0o8+OfUxcjB wSZgJfHkkA9IjYjAdkaJuxseMoPUCAv4SizouglmiwgESEzb2MwGUi8iYCTxYq4QSJhFQFXi c/szVhCbF6j8bsdOVojxjhJNrbcZQco5BdQkdl63AwkzCshKTNi9iBHEZhYQl7j1ZD4TxJkC Ekv2nGeGsEUlXj7+xwphK0msPbydBaJeT+LG1ClsELa2xLKFr5kh1gpKnJz5hGUCo+gsJGNn IWmZhaRlFpKWBYwsqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjEC4+fglt+6OxhXv3Y8xCjA wajEw1swqStEiDWxrLgy9xCjNAeLkjjvonPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw zr950v8ck9Dht9vKp4i4TmM1jGDbo7/5IHuxa+Osjbq6PRrp+f5XX9tlzfgp5nb9eO0+R5lV 7gfk/l0OznD/5+MTaxqvP0f2CdM2A8+ta+/mM/C8XvonVjZCqHP+vZO3xSrduXfetHw1RWXv v4ndYX8FLa60RUqErtQsua5YsGsa52Vnr50uSizFGYmGWsxFxYkAipn6fIACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/teas/MsBJVCM57jxjojHy5iyTFHOsBz8 Subject: Re: [Teas] [CCAMP] WG Last Call on draft-ietf-ccamp-rsvp-te-li-lb-06 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 17:26:10 -0000 TEAS will be the most efficient WG ever...plenty of -00 drafts becoming RFC= s :) BR Daniele > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: venerd=EC 12 dicembre 2014 14:38 > To: CCAMP; TEAS WG; draft-ietf-ccamp-rsvp-te-li-lb@tools.ietf.org > Subject: Re: [Teas] [CCAMP] WG Last Call on draft-ietf-ccamp-rsvp-te-li-l= b- > 06 >=20 > The WG LC is now closed for this now *TEAS* WG document. (Yes this > continues the really odd side effect of the WG changes.) >=20 > Please direct future discussion, including follow up to LC comments, on t= his > document to the TEAS WG. >=20 > Note draft-ietf-ccamp-rsvp-te-li-lb-06 has already been republished as dr= aft- > ietf-teas-rsvp-te-li-lb-00. >=20 > Authors, > Please discuss any issues raised (on the TEAS WG list) and submit upd= ates > using the name draft-ietf-teas-rsvp-te-li-lb. >=20 >=20 > Thank you! > Lou (and Deborah) >=20 > On 11/26/2014 5:13 PM, Lou Berger wrote: > > All, > > This starts a two-week working group last call on > > draft-ietf-ccamp-rsvp-te-li-lb-06. > > > > This working group last call ends on Thursday December 11th. Please > > send your comments to the CCAMP mailing list. > > > > As is always the case, positive comments, e.g., "I've reviewed this > > document and believe it is ready for publication", are welcome! > > This is useful and important, even from authors. > > > > Thanks, > > Lou (and Deborah) > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Fri Dec 12 13:26:59 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729791A1B55 for ; Fri, 12 Dec 2014 13:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 pFgOYvhK7mZP for ; Fri, 12 Dec 2014 13:26:56 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 8DFE31A1A58 for ; Fri, 12 Dec 2014 13:26:56 -0800 (PST) Received: (qmail 20079 invoked by uid 0); 12 Dec 2014 21:26:56 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy8.mail.unifiedlayer.com with SMTP; 12 Dec 2014 21:26:56 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id SlSt1p0062SSUrH01lSwfe; Fri, 12 Dec 2014 14:26:56 -0700 X-Authority-Analysis: v=2.1 cv=W++rC3mk c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=TBTM1mQdaEIA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=rM3QaBNKWLk2qvXY3VMA:9 a=pILNOxqGKmIA:10 a=so19vaU-6qMA:10 a=jpbbSxOCxi8A:10 a=IRj_x8AE27oA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=0HW5p2eSsBQlK5RE2IZ2gY6EO31e34rnenMgkw2Loco=; b=i4h2nN/B6t5mbtSPITMJCUSFgAOOSLGvN/yxbVjnfH3sTYZnF+ca/AJyatcEqu+4KEdpYzgH7oaTV4JXCp7k+/3uHEb5MHjBZWDqwGbUea3qTtJiK7Cv6NQXg7p8p7MG; Received: from box313.bluehost.com ([69.89.31.113]:47798 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XzXjg-0008Ir-Rv for teas@ietf.org; Fri, 12 Dec 2014 14:26:52 -0700 Message-ID: <548B5DA8.1060700@labn.net> Date: Fri, 12 Dec 2014 16:27:04 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: TEAS WG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/1Lrbj2AyhWp2L8L2BuQoTGzI7Kk Subject: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 21:26:57 -0000 All, This is start of a two week poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a TEAS working group document. Please send email to the list indicating “yes/support” or “no/do not support”. If indicating no, please state your technical reservations with the document. The poll ends Friday December 26th. Thanks, Deborah and Lou From nobody Fri Dec 12 15:39:06 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AA01A01CB for ; Fri, 12 Dec 2014 15:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 7AQ8sw6ayYJB for ; Fri, 12 Dec 2014 15:39:03 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814E41A00FF for ; Fri, 12 Dec 2014 15:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=655; q=dns/txt; s=iport; t=1418427543; x=1419637143; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PJoZtauq0SrzQssIXu03M9R8US5iToH1WIFxO8sN7FM=; b=kX/rTB6DNjEBo+PGZ2aNKgexnRRm3Dce+2FhPz7ScuKVaHvCgI1oyxdp kBsCD/R4xR5VOh5OQFxXv5DHVgdYpmKQ4W2JGKoAa1KHGGY/GV3QmFeqC ZvdIxUtRIR12qJKy+77p8UJwNB7L5Db/OF3tw1DWiXZR4ThE9ewdopyPT 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwFALx7i1StJV2b/2dsb2JhbABZgwZSWATFcwqFcgKBFRYBAQEBAX2EDQEBBAEBAWsLEgEIDl8LJQIEAQ0FiCwN2CYBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI8QEQFQB4QpAQSJE4RsiG+BC4JeihaDOCKCMIE8boEMOX4BAQE X-IronPort-AV: E=Sophos;i="5.07,567,1413244800"; d="scan'208";a="105333289" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 12 Dec 2014 23:39:02 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sBCNd2Pf014938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Dec 2014 23:39:02 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.173]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 17:39:02 -0600 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document Thread-Index: AQHQFlJeWNEXLVsItkaiNSBPlr4JxpyMrbaA Date: Fri, 12 Dec 2014 23:39:02 +0000 Message-ID: In-Reply-To: <548B5DA8.1060700@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.86.245.238] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2045DC900209F4489D42EB0C632CF24C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/gkq8vquCSvzOC8ZPe4P0i5sllE0 Cc: "Mike Taillon \(mtaillon\)" , "manav@ionosnetworks.com" , "frederic.jounay@orange.ch" , "lizho.jin@gmail.com" , "Tarek Saad \(tsaad\)" , "Zafar Ali \(zali\)" Subject: Re: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 23:39:05 -0000 Hi WG, Chairs, Yes/support (as a co-author). thanks, Rakesh On 2014-12-12 4:27 PM, "Lou Berger" wrote: >All, > >This is start of a two week poll on making >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a TEAS working group >document. Please send email to the list indicating =B3yes/support=B2 or >=B3no/do not support=B2. If indicating no, please state your technical >reservations with the document. > >The poll ends Friday December 26th. > >Thanks, > >Deborah and Lou > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas From nobody Sat Dec 13 06:02:31 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70741A00B9 for ; Sat, 13 Dec 2014 05:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 eRQ0rWGunydD for ; Sat, 13 Dec 2014 05:53:38 -0800 (PST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D5C1A006D for ; Sat, 13 Dec 2014 05:53:37 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id id10so4230702vcb.5 for ; Sat, 13 Dec 2014 05:53:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jDIf71ZV6hOe3Nrb5w0Oyxzu2Unx8HBlbjlfs4JffMM=; b=jh7DDYpjDWnPLaBOAMkwV4DDiEcX+LXWf4kqMlYXuSwZ5UnorS/7mBZsOhoRAohOKG p9wPc5FF0Kmp4ZCBHzaYZ/FRnJ1QtjJrOq85O4JJ0ipyqvKIMhcVXEGtIMQPtx1cmV4N DGXjZgDxbiPvWvkbdxZlf/0+zngygmhy+18XoISolsGzLLEkVVVM9Dy4gCQUskYJk7ii irNno13h1ohL4DfzjkPEDDUy3gNnQxMv3nHFegOHjoIVbpx75kT20VWYxhz0KBxwljKw jp9/yxaO8t7cxzQ0o9h6rcHvrOgzJIdL8dPfB2bWfaUZfm230FcHXYq4Jh5Ae+DWUfuB GoPw== X-Gm-Message-State: ALoCoQkddX2ZXK3cEyDqcrHYPZ8KGosbYkW99pBV1TPKUmzBXyiMlpC3bOO918Fa7sm4vDzMyzZy MIME-Version: 1.0 X-Received: by 10.220.99.68 with SMTP id t4mr13067845vcn.14.1418478816789; Sat, 13 Dec 2014 05:53:36 -0800 (PST) Received: by 10.31.58.144 with HTTP; Sat, 13 Dec 2014 05:53:36 -0800 (PST) In-Reply-To: References: <548B5DA8.1060700@labn.net> Date: Sat, 13 Dec 2014 19:23:36 +0530 Message-ID: From: Manav Bhatia To: "Rakesh Gandhi (rgandhi)" Content-Type: multipart/alternative; boundary=001a11c1c33cff1db3050a19554e Archived-At: http://mailarchive.ietf.org/arch/msg/teas/y84fd5ZfpIfkreYPa7HlrxlnQs4 X-Mailman-Approved-At: Sat, 13 Dec 2014 06:02:29 -0800 Cc: "Mike Taillon \(mtaillon\)" , "frederic.jounay@orange.ch" , TEAS WG , "lizho.jin@gmail.com" , "Tarek Saad \(tsaad\)" , Lou Berger , "Zafar Ali \(zali\)" Subject: Re: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 13:53:40 -0000 --001a11c1c33cff1db3050a19554e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Support this document. Cheers, Manav On Sat, Dec 13, 2014 at 5:09 AM, Rakesh Gandhi (rgandhi) wrote: > > Hi WG, Chairs, > > Yes/support (as a co-author). > > thanks, > Rakesh > > > On 2014-12-12 4:27 PM, "Lou Berger" wrote: > > >All, > > > >This is start of a two week poll on making > >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a TEAS working group > >document. Please send email to the list indicating =C2=B3yes/support=C2= =B2 or > >=C2=B3no/do not support=C2=B2. If indicating no, please state your techn= ical > >reservations with the document. > > > >The poll ends Friday December 26th. > > > >Thanks, > > > >Deborah and Lou > > > >_______________________________________________ > >Teas mailing list > >Teas@ietf.org > >https://www.ietf.org/mailman/listinfo/teas > > --001a11c1c33cff1db3050a19554e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Support this document.
Cheers, Manav

On Sat, Dec 13, 2014 at 5:09 AM, Rakesh Gandhi (rgandh= i) <rgandhi@cisco.com> wrote:
= Hi WG, Chairs,

Yes/support (as a co-author).

thanks,
Rakesh


On 2014-12-12 4:27 PM, "Lou Berger" <lberger@labn.net> wrote:

>All,
>
>This is start of a two week poll on making
>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a TEAS working group<= br> >document. Please send email to the list indicating =C2=B3yes/support=C2= =B2 or
>=C2=B3no/do not support=C2=B2. If indicating no, please state your tech= nical
>reservations with the document.
>
>The poll ends Friday December 26th.
>
>Thanks,
>
>Deborah and Lou
>
>_______________________________________________
>Teas mailing list
>Teas@ietf.org
>https://www.ietf.org/mailman/listinfo/teas

--001a11c1c33cff1db3050a19554e-- From nobody Sun Dec 14 00:09:53 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AEB1A6EEF; Sun, 14 Dec 2014 00:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 SyO42QrbTFbn; Sun, 14 Dec 2014 00:09:44 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A70801A1BCA; Sun, 14 Dec 2014 00:09:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9765; q=dns/txt; s=iport; t=1418544584; x=1419754184; h=from:to:cc:subject:date:message-id:mime-version; bh=/NM6RRP6rHdmCinF5CkMVRCIwz1QwfnWHidWJupYJUU=; b=EXPI7HDA68HqFsrpsPBh4KdFoVZFdEkEJmzpl9HCQn0EEINSmdPuzsDI dYDOf/ZceJN6xQB1pRdQE1icdAELGUF3KGoQRSVwxUaHPhL+RSORvqyjI 1WMetBINoe8aqBRDZHk38sFa5VIGK+jwv8pE7AMc/q3X1k4o/QneJaJDG E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIFAHpEjVStJV2S/2dsb2JhbABAFwOCQ0NSWATFV4VwgRIWAQEBAQF9hBNVERMSAQ8lBAw8JAMBAwENiDENN79ikB8BAQEBAQEBAQEBAQEBAQEBAQEBAQEXjy5ABBAIB4QRBYUfiGODPoM+gXOBCw0jgi6KFoM4IoMeTm4BgUR+AQEB X-IronPort-AV: E=Sophos;i="5.07,574,1413244800"; d="scan'208,217";a="112622673" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by mtv-iport-2.cisco.com with ESMTP; 14 Dec 2014 08:09:43 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sBE89gGx005897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Dec 2014 08:09:42 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.121]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Sun, 14 Dec 2014 02:09:42 -0600 From: "Zafar Ali (zali)" To: "ccamp@ietf.org" , "Teas@ietf.org" Thread-Topic: Informal meeting for discussions on GMPLS TED Yang Thread-Index: AQHQF3VQYpeR4lUVIkqFxIW1HUPrYw== Date: Sun, 14 Dec 2014 08:09:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.243.220] Content-Type: multipart/alternative; boundary="_000_D0B2B16FE43D5zaliciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/FGSZwH2jUlDVq4etKeTMXa5-SCw Cc: "George Swallow \(swallow\)" , "adrian@olddog.co.uk" , "lberger@labn.net" , "Tarek Saad \(tsaad\)" , "'BRUNGARD, DEBORAH A'" Subject: [Teas] Informal meeting for discussions on GMPLS TED Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 08:09:49 -0000 --_000_D0B2B16FE43D5zaliciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear WGs: Some of us (esp. authors of documents related to TED Yang) are informally m= eeting on Wed. 12/17 at 2:00 PM, ET. We will focus on GMPLS TED Yang, inclu= ding optical TED. Details for the webEx call are as follows. Please join us= if you are interested. Thanks Regards =85 Zafar +---+---+---+---+---+---+---+---+---+---+---+ Please do not edit text below this line. You are invited to an online meeting using WebEx. Meeting Number: 304382101 Meeting Password: GMPLSTED ------------------------------------------------------- To join this meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/cisco/j.php?MTID=3Dm1d40879454e67c8fec3c30= cafa96e13d 2. Enter the meeting password: GMPLSTED 3. Click 'Join Now'. 4. Follow the instructions that appear on your screen. ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.co= m/en/US/about/doing_business/conferencing/index.html) 2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 http://www.webex.com CCP:+14085256800x304382101# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_D0B2B16FE43D5zaliciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Dear WGs: 

Some of us (esp. authors of documents related to TED Yang) are informa= lly meeting on Wed. 12/17 at 2:00 PM, ET. We will focus on GMPLS TED Yang, including optical TED. Details for the webEx call are as follows. Please join us if you are interested. 

Thanks

Regards =85 Zafar

+---+---+---&#= 43;---+---+---+---+---+---+---+---+ 

Please do not edit text be= low this line. 

You are invited to an onli= ne meeting using WebEx. 


Meeting Number: 304382101&= nbsp;

Meeting Password: GMPLSTED=  


--------------------------= ----------------------------- 

To join this meeting (Now = from mobile devices!) 

--------------------------= ----------------------------- 

1. Go to https://cisco.webex.com/cisco/j.php?MTID=3Dm1d40879454e67c8fec3c30cafa96e= 13d


2. Enter the meeting passw= ord: GMPLSTED 

3. Click 'Join Now'. =

4. Follow the instructions= that appear on your screen. 



--------------------------= -------------------------------------- 

ALERT:Toll-Free Dial Restr= ictions for (408) and (919) Area Codes 

--------------------------= -------------------------------------- 


The affected toll free num= bers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 = for the RTP area. 


Please dial the local acce= ss number for your area from the list below: 

- San Jose/Milpitas (408) = area: 525-6800 

- RTP (919) area: 392-3330=  


--------------------------= ----------------------------- 

To join the teleconference= only 

--------------------------= ----------------------------- 

1. Dial into Cisco WebEx (= view all Global Access Numbers at http://cisco.com/en/US/about/do= ing_business/conferencing/index.html) 

2. Follow the prompts to e= nter the Meeting Number (listed above) or Access Code followed by the # sig= n. 


San Jose, CA: +1.408.5= 25.6800 

RTP: +1.919.392.3330&n= bsp;


US/Canada: +1.866.432.= 9903 

United Kingdom: +44.20= .8824.0117 


India: +91.80.4350.111= 1 

Germany: +49.619.6773.= 9002 


Japan: +81.3.5763.9394=  

China: +86.10.8515.566= 6 


http://www.webex.com


CCP:+14085256800x30438= 2101# 


IMPORTANT NOTICE: This Web= Ex service includes a feature that allows audio and any documents and other= materials exchanged or viewed during the session to be recorded. By joinin= g this session, you automatically consent to such recordings. If you do not consent to the recording, discus= s your concerns with the meeting host prior to the start of the recording o= r do not join the session. Please note that any such recordings may be subj= ect to discovery in the event of litigation.    



--_000_D0B2B16FE43D5zaliciscocom_-- From nobody Sun Dec 14 06:46:10 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682FC1A6FB0 for ; Sun, 14 Dec 2014 06:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 K0CD4SeEyDUT for ; Sun, 14 Dec 2014 06:46:06 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 022581A6FA8 for ; Sun, 14 Dec 2014 06:46:02 -0800 (PST) Received: (qmail 12261 invoked by uid 0); 14 Dec 2014 14:45:59 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 14 Dec 2014 14:45:59 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id TSlt1p00P2SSUrH01SlwEX; Sun, 14 Dec 2014 07:45:59 -0700 X-Authority-Analysis: v=2.1 cv=OLu0g0qB c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=ZSdzdHkL1-cA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=9iDbn-4jx3cA:10 a=cKsnjEOsciEA:10 a=gZbpxnkM3yUA:10 a=AUd_NHdVAAAA:8 a=NojvYFcnAAAA:8 a=48vgC7mUAAAA:8 a=jk1WxxplDMvWMTSQxZoA:9 a=bi05y7tEeed-C3Bv:21 a=BqMjUjbtNo0opoEC:21 a=QEXdDO2ut3YA:10 a=DuFuz0vnU34A:10 a=gg8VKjMKdhQA:10 a=SnIUDNMdgG0A:10 a=Sk0WS7PdEOYA:10 a=9SiWvIfi6awA:10 a=gX8DQM9zqB8A:10 a=ULth79YsAAUA:10 a=V_L1f3CK-Je1SOcF1qUA:9 a=BTTrGSkndD7pPsIG:21 a=dWrMEOCPMJOSaNTZ:21 a=HSG9H9wbCNF2yiyQ:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=yh2Rx/ByPRjWgH0j7zpy3teCoWjAOKE/FgSQJp2aLTo=; b=ZFSS5v/cIQqc8Ce0Ca2znUtjrkgVh8Q3zkdpW6HgoXDiHwbVFo4eKiycNi2HAVOayY2M7S2d8/xWaN8eSG/WevGVuhhOdGbBK0RF71vyaCBin7sKlG1t1LgE3+Uex5Nq; Received: from box313.bluehost.com ([69.89.31.113]:46015 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Y0AQi-0006pq-Vp; Sun, 14 Dec 2014 07:45:53 -0700 Message-ID: <548DA29E.1030908@labn.net> Date: Sun, 14 Dec 2014 09:45:50 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Zafar Ali (zali)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040305070704050402050805" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/_7R9uLUliEaej3fbEhmjqSHKKLA Cc: "George Swallow \(swallow\)" , "'BRUNGARD, DEBORAH A'" , ccamp@ietf.org, Teas@ietf.org, "Tarek Saad \(tsaad\)" , adrian@olddog.co.uk Subject: Re: [Teas] Informal meeting for discussions on GMPLS TED Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 14:46:08 -0000 This is a multi-part message in MIME format. --------------040305070704050402050805 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Zafar, Per process, anyone can have any informal discussion on any topic that they'd like and submit any individual document that they author. And all this energy around YANG at the moment is fabulous. But please keep in mind that on this *exact* topic there has been a TEAS WG design team announced, and a virtual interim meeting scheduled for the 18th. I encourage you (and anyone else who is interested) to contribute to these WG efforts. For example, you could send mail to the design team letting them know that you would like to contribute, or if you have something more concrete to contribute, you could ask for a slot at the interim. While the DT has no specific direction or restriction on how they conduct their work, I would be surprised if they didn't base their work on the existing drafts in the area. To be clear, "the area" means generic TE Topology wherever the information comes from / is targeted, i.e., MPLS, GMPLS, PCE, config, etc. While the DT will also need to consider how data plane specific (e.g., WSON, labeled packets) information fits in to a/their generic TE model, such modeling work will be done in CCAMP and MPLS -- and presumably in sync with the generic mode= l. If you think you have additional generic TE information that needs to be modeled that is beyond what is covered in the DT's scope (and the other discussions that are currently happening in MPLS), this would be a good subject for you to raise at (and request a discussion slot for) the interim meeting. If your focus is within the scope of the DT, I expect that we will hear from the DT at the interim so this will present a good opportunity to hear and discuss how they plan to conduct their work and how others might contribute before there is a WG document on the topic. Lou On December 14, 2014 3:10:25 AM "Zafar Ali (zali)" wrote= : > Dear WGs:=20 > > Some of us (esp. authors of documents related to TED Yang) are > informally meeting on Wed. 12/17 at 2:00 PM, ET. We will focus on > GMPLS TED Yang, including optical TED. Details for the webEx call are > as follows. Please join us if you are interested.=20 > > Thanks > > Regards =C3=A2=C2=80=C2=A6 Zafar > > +---+---+---+---+---+---+---+---+---+---+---+=20 > > Please do not edit text below this line.=20 > > You are invited to an online meeting using WebEx.=20 > > > Meeting Number: 304382101=20 > > Meeting Password: GMPLSTED=20 > > > -------------------------------------------------------=20 > > To join this meeting (Now from mobile devices!)=20 > > -------------------------------------------------------=20 > > 1. Go > to https://cisco.webex.com/cisco/j.php?MTID=3Dm1d40879454e67c8fec3c30ca= fa96e13d > > > 2. Enter the meeting password: GMPLSTED=20 > > 3. Click 'Join Now'.=20 > > 4. Follow the instructions that appear on your screen.=20 > > > > ----------------------------------------------------------------=20 > > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes=20 > > ----------------------------------------------------------------=20 > > > The affected toll free numbers are: (866) 432-9903 for the San > Jose/Milpitas area and (866) 349-3520 for the RTP area.=20 > > > Please dial the local access number for your area from the list below: = > > - San Jose/Milpitas (408) area: 525-6800=20 > > - RTP (919) area: 392-3330=20 > > > -------------------------------------------------------=20 > > To join the teleconference only=20 > > -------------------------------------------------------=20 > > 1. Dial into Cisco WebEx (view all Global Access Numbers > at http://cisco.com/en/US/about/doing_business/conferencing/index.html)= =20 > > 2. Follow the prompts to enter the Meeting Number (listed above) or > Access Code followed by the # sign.=20 > > > San Jose, CA: +1.408.525.6800=20 > > RTP: +1.919.392.3330=20 > > > US/Canada: +1.866.432.9903=20 > > United Kingdom: +44.20.8824.0117=20 > > > India: +91.80.4350.1111=20 > > Germany: +49.619.6773.9002=20 > > > Japan: +81.3.5763.9394=20 > > China: +86.10.8515.5666=20 > > > http://www.webex.com > > > CCP:+14085256800x304382101#=20 > > > IMPORTANT NOTICE: This WebEx service includes a feature that allows > audio and any documents and other materials exchanged or viewed during > the session to be recorded. By joining this session, you automatically > consent to such recordings. If you do not consent to the recording, > discuss your concerns with the meeting host prior to the start of the > recording or do not join the session. Please note that any such > recordings may be subject to discovery in the event of litigation. =20 > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --------------040305070704050402050805 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Zafar,

Per process, anyone can have any informal discussion on any topic that they'd like and submit any individual document that they author. And all this energy around YANG at the moment is fabulous.

But please keep in mind that on this *exact* topic there has been a TEAS WG design team announced, and a virtual interim meeting scheduled for the 18th.  I encourage you (and anyone else who is interested) to contribute to these WG efforts.

For example, you could send mail to the design team letting them know that you would like to contribute, or if you have something more concrete to contribute, you could ask for a  slot at the interim.

While the DT has no specific direction or restriction on how they conduct their work, I would be surprised if they didn't base their work on the existing drafts in the area. To be clear, "the area" means generic TE Topology wherever the information comes from / is targeted, i.e., MPLS, GMPLS, PCE, config, etc.  While the DT will also need to consider how data plane specific (e.g., WSON, labeled packets) information fits in to a/their generic TE model, such modeling work will be done in CCAMP and MPLS -- and presumably in sync with the generic model.

If you think you have additional generic TE information that needs to be modeled that is  beyond what is covered in the DT's scope (and the other discussions that are currently happening in MPLS), this would be a good subject for you to raise at (and request a discussion slot for) the interim meeting.

If your focus is within the scope of the DT, I expect that we will hear from the DT at the interim so this will present a good opportunity to hear and discuss how they plan to conduct their work and how others might contribute before there is a WG document on the topic.

Lou

On December 14, 2014 3:10:25 AM "Zafar Ali (zali)" <zali@cisco.com> wrote:

Dear WGs: 

Some of us (esp. authors of documents related to TED Yang) are informally meeting on Wed. 12/17 at 2:00 PM, ET. We will focus on GMPLS TED Yang, including optical TED. Details for the webEx call are as follows. Please join us if you are interested. 

Thanks

Regards … Zafar

+---+---+---+---+---+---+---+---+---+---+---+ 

Please do not edit text below this line. 

You are invited to an online meeting using WebEx. 


Meeting Number: 304382101 

Meeting Password: GMPLSTED 


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

To join this meeting (Now from mobile devices!) 

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

1. Go to https://cisco.webex.com/cisco/j.php?MTID=m1d40879454e67c8fec3c30cafa96e13d


2. Enter the meeting password: GMPLSTED 

3. Click 'Join Now'. 

4. Follow the instructions that appear on your screen. 



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

ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes 

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


The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. 


Please dial the local access number for your area from the list below: 

- San Jose/Milpitas (408) area: 525-6800 

- RTP (919) area: 392-3330 


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

To join the teleconference only 

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

1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html) 

2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. 


San Jose, CA: +1.408.525.6800 

RTP: +1.919.392.3330 


US/Canada: +1.866.432.9903 

United Kingdom: +44.20.8824.0117 


India: +91.80.4350.1111 

Germany: +49.619.6773.9002 


Japan: +81.3.5763.9394 

China: +86.10.8515.5666 


http://www.webex.com


CCP:+14085256800x304382101# 


IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.    



_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas

--------------040305070704050402050805-- From nobody Sun Dec 14 08:29:54 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2361A00EA for ; Sat, 13 Dec 2014 07:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 qc2Sdhh-kyq2 for ; Sat, 13 Dec 2014 07:41:31 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7FB61A006D for ; Sat, 13 Dec 2014 07:41:30 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id rd3so9070322pab.14 for ; Sat, 13 Dec 2014 07:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=q2FouBDt3Au4oy5OStKQFnaJyIWS02G8U4zIl0EoDtQ=; b=jqR4+9A8Vm7Y+TdWbxwEdfIGnlVd+ic0weADK8JnPkkPWRvJeE9aIA+sN2SyPsEvij idCiTW0lCnnI+JVWdPrSXMz12UwTUDtrNOjlYiyAA2r6zwBo6GRqpLyU2ylhehChDCZ1 qjGDPabBFQquFKbg0f2LYCIDWseT6QhkkwiYoA6e4bCE140vgTGYlznZ7DPCNDlZ5WSY 9xDlAYuDlZz7mOazewWIfz5ccrj/aaejIU+7bUKEubBo47d54zaRNsh4z0tuygIni9Cp HD/d30LbItWrncLQ73W+/xsOxHmxBfvGnTC4+GvCdUFqTIpfIclo/BVTpaxJrvguQW9l Fu1A== X-Received: by 10.67.12.236 with SMTP id et12mr36487671pad.31.1418485289992; Sat, 13 Dec 2014 07:41:29 -0800 (PST) Received: from LIZHONGJ ([140.206.204.87]) by mx.google.com with ESMTPSA id ds16sm4530607pdb.65.2014.12.13.07.41.22 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 13 Dec 2014 07:41:29 -0800 (PST) From: "Lizhong Jin" To: "'Lou Berger'" , "'TEAS WG'" References: <548B5DA8.1060700@labn.net> In-Reply-To: Date: Sat, 13 Dec 2014 23:41:14 +0800 Message-ID: <013401d016eb$42ac0600$c8041200$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKRJtQckpnXClo76bP4acQn3zgV7ZsLiEuw Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/teas/_Wly68msXUCdvKCGmWYg29TM-_c X-Mailman-Approved-At: Sun, 14 Dec 2014 08:29:52 -0800 Cc: "'Mike Taillon \(mtaillon\)'" , manav@ionosnetworks.com, frederic.jounay@orange.ch, "'Rakesh Gandhi \(rgandhi\)'" , "'Tarek Saad \(tsaad\)'" , "'Zafar Ali \(zali\)'" Subject: Re: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 15:41:36 -0000 Hi, Yes, support as co-author. Lizhong > -----Original Message----- > From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] > Sent: 2014=D2=B412=EA=C513=EC=ED 7:39 > To: Lou Berger; TEAS WG > Cc: Zafar Ali (zali); Tarek Saad (tsaad); Mike Taillon (mtaillon); > manav@ionosnetworks.com; lizho.jin@gmail.com; > frederic.jounay@orange.ch > Subject: Re: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp- > fastreroute-05 a WG document >=20 > Hi WG, Chairs, >=20 > Yes/support (as a co-author). >=20 > thanks, > Rakesh >=20 >=20 > On 2014-12-12 4:27 PM, "Lou Berger" wrote: >=20 > >All, > > > >This is start of a two week poll on making > >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a TEAS working = group > >document. Please send email to the list indicating = =A9=F8yes/support=A9=F7 or > >=A9=F8no/do not support=A9=F7. If indicating no, please state your = technical > >reservations with the document. > > > >The poll ends Friday December 26th. > > > >Thanks, > > > >Deborah and Lou > > > >_______________________________________________ > >Teas mailing list > >Teas@ietf.org > >https://www.ietf.org/mailman/listinfo/teas From nobody Sun Dec 14 08:29:55 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E020F1A0163 for ; Sat, 13 Dec 2014 07:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Zz1HnT2v0ee2 for ; Sat, 13 Dec 2014 07:46:42 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615B11A0162 for ; Sat, 13 Dec 2014 07:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=954; q=dns/txt; s=iport; t=1418485602; x=1419695202; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dIC1uOlJkVjDMZ01vcxNl+igdrLlfmyItNbG3P9bs6Q=; b=QhXrc6+igZkFk+tzMdn6T5GWZWLnFHlvBQVA9iVycK+MTPWX1CrgxnMW NoMwpQY9taV5niblREnLcxbE51UuT8SwT0XY2prglzONcXpeSrExDwV4L 5ty//fVPGRg5/WY5uD96+yUKxpfCH0oC78YFLCsRd+TK+UmN23suqVhfU E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAGAMpejFStJA2I/2dsb2JhbABZgwZSWASDAsMBCoVyAhx5FgEBAQEBfYQNAQEEAQEBMToLEgEIDgoEKAQlCyUCBAENBYgsDaQfnFcGlX4BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEbjXURATUbB4JigUcBBI4CiG+BC4JeihaDOCKCMIE8boEMOX4BAQE X-IronPort-AV: E=Sophos;i="5.07,571,1413244800"; d="scan'208";a="105591559" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP; 13 Dec 2014 15:46:41 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBDFkfwh013507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Dec 2014 15:46:41 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.121]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Sat, 13 Dec 2014 09:46:41 -0600 From: "Zafar Ali (zali)" To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document Thread-Index: AQHQFlJeWNEXLVsItkaiNSBPlr4JxpyMrbaAgAEQIQA= Date: Sat, 13 Dec 2014 15:46:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.246.97] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/eI1hplzgvRFBdZ3TM4y-g01f_fM X-Mailman-Approved-At: Sun, 14 Dec 2014 08:29:52 -0800 Cc: "Mike Taillon \(mtaillon\)" , "frederic.jounay@orange.ch" , "Tarek Saad \(tsaad\)" , "manav@ionosnetworks.com" , "lizho.jin@gmail.com" Subject: Re: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 15:46:44 -0000 RGVhciBXRyBhbmQgQ2hhaXJzOg0KDQpZZXMvc3VwcG9ydCAoYXMgYSBjby1hdXRob3IpDQoNCg0K VGhhbmtzDQoNClJlZ2FyZHMgoaYgWmFmYXINCg0KDQo+DQo+T24gMjAxNC0xMi0xMiA0OjI3IFBN LCAiTG91IEJlcmdlciIgPGxiZXJnZXJAbGFibi5uZXQ+IHdyb3RlOg0KPg0KPj5BbGwsDQo+Pg0K Pj5UaGlzIGlzIHN0YXJ0IG9mIGEgdHdvIHdlZWsgcG9sbCBvbiBtYWtpbmcNCj4+ZHJhZnQtdHNh YWQtY2NhbXAtcnN2cHRlLWJpZGlyLWxzcC1mYXN0cmVyb3V0ZS0wNSBhIFRFQVMgd29ya2luZyBn cm91cA0KPj5kb2N1bWVudC4gUGxlYXNlIHNlbmQgZW1haWwgdG8gdGhlIGxpc3QgaW5kaWNhdGlu ZyCp+Hllcy9zdXBwb3J0qfcgb3INCj4+qfhuby9kbyBub3Qgc3VwcG9ydKn3LiBJZiBpbmRpY2F0 aW5nIG5vLCBwbGVhc2Ugc3RhdGUgeW91ciB0ZWNobmljYWwNCj4+cmVzZXJ2YXRpb25zIHdpdGgg dGhlIGRvY3VtZW50Lg0KPj4NCj4+VGhlIHBvbGwgZW5kcyBGcmlkYXkgRGVjZW1iZXIgMjZ0aC4N Cj4+DQo+PlRoYW5rcywNCj4+DQo+PkRlYm9yYWggYW5kIExvdQ0KPj4NCj4+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+VGVhcyBtYWlsaW5nIGxpc3QN Cj4+VGVhc0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RlYXMNCj4NCg0K From nobody Sun Dec 14 21:21:10 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E441A1A03; Sun, 14 Dec 2014 21:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 7yz1qXb32rZT; Sun, 14 Dec 2014 21:21:02 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C87271A19E9; Sun, 14 Dec 2014 21:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24959; q=dns/txt; s=iport; t=1418620861; x=1419830461; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=VD4MtFA8XW20T7oLmmbIhCmcHq9E/Pyrax50ri02+wc=; b=Wdde5Ca0NHcF6g2ydmCQO9WCpOi0hMl17tIQpD0d/uj0gfFG87xwOfWc cvrF8eLwHgYFq06ODCh43PD7NTXK6FfYQpo6p9uIs2eGdfka9ofSoYAsw HsKQYOUNmKMlJErZgezilr8gYGmlmi2EahNdoGEG/f1l/s1v4yOLoudQp M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAGAE1vjlStJA2G/2dsb2JhbABAFwOCQ0NSWASDAsJQAQuFcAIcdxYBAQEBAX2EDAEBAQQBAQEgMhEICxIBBgIHBwMDAQIVBAwDAwIEJQsUCQcBAgEDDgWILA03nkWcX4UtkEkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjxAQAgELKQoBDAQHAgcIB4JQgUEFhR+IY4M+gz6Bc4ELDSOCLooWgzgigx5ObgGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.07,578,1413244800"; d="scan'208,217";a="105838389" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP; 15 Dec 2014 05:21:00 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sBF5L0O7002755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Dec 2014 05:21:00 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.121]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Sun, 14 Dec 2014 23:21:00 -0600 From: "Zafar Ali (zali)" To: Lou Berger Thread-Topic: [Teas] Informal meeting for discussions on GMPLS TED Yang Thread-Index: AQHQF3VQYpeR4lUVIkqFxIW1HUPrY5yPjvgAgACicQA= Date: Mon, 15 Dec 2014 05:20:59 +0000 Message-ID: In-Reply-To: <548DA29E.1030908@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.243.128] Content-Type: multipart/alternative; boundary="_000_D0B3D8D8E443Bzaliciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/_5-ic_bJ57iBOYIrhixCl0jSLPg Cc: "George Swallow \(swallow\)" , "'BRUNGARD, DEBORAH A'" , "ccamp@ietf.org" , "Teas@ietf.org" , "Tarek Saad \(tsaad\)" , "adrian@olddog.co.uk" Subject: Re: [Teas] Informal meeting for discussions on GMPLS TED Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 05:21:06 -0000 --_000_D0B3D8D8E443Bzaliciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG91LQ0KDQpUaGUgaWRlYSBoZXJlIHdhcyBub3QgdG8gYnkgcGFzcyB0aGUgRFQgYnV0IHRv IHdvcmsgd2l0aCB0aGUgc2FtZS4gSSBoYXZlIGJlZW4gcGFydGljaXBhdGluZyBpbiBiaS13ZWVr bHkgY2FsbHMuIFdlIHdvdWxkIGxpa2UgdG8gbWFrZSBwcm9ncmVzcyBvbiAoT3B0aWNhbCkgVEVE IGFyZWEgYW5kIGhlbmNlIGJhc2VkIG9uIHByaXZhdGUgZW1haWwgZGlzY3Vzc2lvbiB3aXRoIHlv dSwgQWRyaWFuIGFuZCBvdGhlcnMgSSB0YXVnaHQgdGhpcyBtZWV0aW5nIHdpbGwganVzdCBjb21w bGltZW50IHRoZSBleGlzdGluZyB3b3JrLiBJbiBhbnkgY2FzZSwgSSB3aWxsIGNhbmNlbCB0aGUg MTIvMTcgY2FsbC4gV2lsbCB3YWl0IGZvciBtb3JlIHNwZWNpZmljIGRpcmVjdGlvbnMgaW4gMTIv MTgncyB2aXJ0dWFsIGludGVyaW0gbWVldGluZy4NCg0KVGhhbmtzDQoNClJlZ2FyZHMg4oCmIFph ZmFyDQoNCkZyb206ICJsYmVyZ2VyQGxhYm4ubmV0PG1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0PiIg PGxiZXJnZXJAbGFibi5uZXQ8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+Pg0KRGF0ZTogU3VuZGF5 LCBEZWNlbWJlciAxNCwgMjAxNCA5OjQ1IEFNDQpUbzogemFsaSA8emFsaUBjaXNjby5jb208bWFp bHRvOnphbGlAY2lzY28uY29tPj4NCkNjOiAiY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGll dGYub3JnPiIgPGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4+LCAiVGVhc0Bp ZXRmLm9yZzxtYWlsdG86VGVhc0BpZXRmLm9yZz4iIDxUZWFzQGlldGYub3JnPG1haWx0bzpUZWFz QGlldGYub3JnPj4sICJHZW9yZ2UgU3dhbGxvdyAoc3dhbGxvdykiIDxzd2FsbG93QGNpc2NvLmNv bTxtYWlsdG86c3dhbGxvd0BjaXNjby5jb20+PiwgImFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRv OmFkcmlhbkBvbGRkb2cuY28udWs+IiA8YWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFu QG9sZGRvZy5jby51az4+LCAiVGFyZWsgU2FhZCAodHNhYWQpIiA8dHNhYWRAY2lzY28uY29tPG1h aWx0bzp0c2FhZEBjaXNjby5jb20+PiwgIidCUlVOR0FSRCwgREVCT1JBSCBBJyIgPGRiMzU0NkBh dHQuY29tPG1haWx0bzpkYjM1NDZAYXR0LmNvbT4+DQpTdWJqZWN0OiBSZTogW1RlYXNdIEluZm9y bWFsIG1lZXRpbmcgZm9yIGRpc2N1c3Npb25zIG9uIEdNUExTIFRFRCBZYW5nDQoNCg0KWmFmYXIs DQoNClBlciBwcm9jZXNzLCBhbnlvbmUgY2FuIGhhdmUgYW55IGluZm9ybWFsIGRpc2N1c3Npb24g b24gYW55IHRvcGljIHRoYXQgdGhleSdkIGxpa2UgYW5kIHN1Ym1pdCBhbnkgaW5kaXZpZHVhbCBk b2N1bWVudCB0aGF0IHRoZXkgYXV0aG9yLiBBbmQgYWxsIHRoaXMgZW5lcmd5IGFyb3VuZCBZQU5H IGF0IHRoZSBtb21lbnQgaXMgZmFidWxvdXMuDQoNCkJ1dCBwbGVhc2Uga2VlcCBpbiBtaW5kIHRo YXQgb24gdGhpcyAqZXhhY3QqIHRvcGljIHRoZXJlIGhhcyBiZWVuIGEgVEVBUyBXRyBkZXNpZ24g dGVhbSBhbm5vdW5jZWQsIGFuZCBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIHNjaGVkdWxlZCBm b3IgdGhlIDE4dGguICBJIGVuY291cmFnZSB5b3UgKGFuZCBhbnlvbmUgZWxzZSB3aG8gaXMgaW50 ZXJlc3RlZCkgdG8gY29udHJpYnV0ZSB0byB0aGVzZSBXRyBlZmZvcnRzLg0KDQpGb3IgZXhhbXBs ZSwgeW91IGNvdWxkIHNlbmQgbWFpbCB0byB0aGUgZGVzaWduIHRlYW0gbGV0dGluZyB0aGVtIGtu b3cgdGhhdCB5b3Ugd291bGQgbGlrZSB0byBjb250cmlidXRlLCBvciBpZiB5b3UgaGF2ZSBzb21l dGhpbmcgbW9yZSBjb25jcmV0ZSB0byBjb250cmlidXRlLCB5b3UgY291bGQgYXNrIGZvciBhICBz bG90IGF0IHRoZSBpbnRlcmltLg0KDQpXaGlsZSB0aGUgRFQgaGFzIG5vIHNwZWNpZmljIGRpcmVj dGlvbiBvciByZXN0cmljdGlvbiBvbiBob3cgdGhleSBjb25kdWN0IHRoZWlyIHdvcmssIEkgd291 bGQgYmUgc3VycHJpc2VkIGlmIHRoZXkgZGlkbid0IGJhc2UgdGhlaXIgd29yayBvbiB0aGUgZXhp c3RpbmcgZHJhZnRzIGluIHRoZSBhcmVhLiBUbyBiZSBjbGVhciwgInRoZSBhcmVhIiBtZWFucyBn ZW5lcmljIFRFIFRvcG9sb2d5IHdoZXJldmVyIHRoZSBpbmZvcm1hdGlvbiBjb21lcyBmcm9tIC8g aXMgdGFyZ2V0ZWQsIGkuZS4sIE1QTFMsIEdNUExTLCBQQ0UsIGNvbmZpZywgZXRjLiAgV2hpbGUg dGhlIERUIHdpbGwgYWxzbyBuZWVkIHRvIGNvbnNpZGVyIGhvdyBkYXRhIHBsYW5lIHNwZWNpZmlj IChlLmcuLCBXU09OLCBsYWJlbGVkIHBhY2tldHMpIGluZm9ybWF0aW9uIGZpdHMgaW4gdG8gYS90 aGVpciBnZW5lcmljIFRFIG1vZGVsLCBzdWNoIG1vZGVsaW5nIHdvcmsgd2lsbCBiZSBkb25lIGlu IENDQU1QIGFuZCBNUExTIC0tIGFuZCBwcmVzdW1hYmx5IGluIHN5bmMgd2l0aCB0aGUgZ2VuZXJp YyBtb2RlbC4NCg0KSWYgeW91IHRoaW5rIHlvdSBoYXZlIGFkZGl0aW9uYWwgZ2VuZXJpYyBURSBp bmZvcm1hdGlvbiB0aGF0IG5lZWRzIHRvIGJlIG1vZGVsZWQgdGhhdCBpcyAgYmV5b25kIHdoYXQg aXMgY292ZXJlZCBpbiB0aGUgRFQncyBzY29wZSAoYW5kIHRoZSBvdGhlciBkaXNjdXNzaW9ucyB0 aGF0IGFyZSBjdXJyZW50bHkgaGFwcGVuaW5nIGluIE1QTFMpLCB0aGlzIHdvdWxkIGJlIGEgZ29v ZCBzdWJqZWN0IGZvciB5b3UgdG8gcmFpc2UgYXQgKGFuZCByZXF1ZXN0IGEgZGlzY3Vzc2lvbiBz bG90IGZvcikgdGhlIGludGVyaW0gbWVldGluZy4NCg0KSWYgeW91ciBmb2N1cyBpcyB3aXRoaW4g dGhlIHNjb3BlIG9mIHRoZSBEVCwgSSBleHBlY3QgdGhhdCB3ZSB3aWxsIGhlYXIgZnJvbSB0aGUg RFQgYXQgdGhlIGludGVyaW0gc28gdGhpcyB3aWxsIHByZXNlbnQgYSBnb29kIG9wcG9ydHVuaXR5 IHRvIGhlYXIgYW5kIGRpc2N1c3MgaG93IHRoZXkgcGxhbiB0byBjb25kdWN0IHRoZWlyIHdvcmsg YW5kIGhvdyBvdGhlcnMgbWlnaHQgY29udHJpYnV0ZSBiZWZvcmUgdGhlcmUgaXMgYSBXRyBkb2N1 bWVudCBvbiB0aGUgdG9waWMuDQoNCkxvdQ0KDQpPbiBEZWNlbWJlciAxNCwgMjAxNCAzOjEwOjI1 IEFNICJaYWZhciBBbGkgKHphbGkpIiA8emFsaUBjaXNjby5jb20+PG1haWx0bzp6YWxpQGNpc2Nv LmNvbT4gd3JvdGU6DQoNCkRlYXIgV0dzOg0KDQpTb21lIG9mIHVzIChlc3AuIGF1dGhvcnMgb2Yg ZG9jdW1lbnRzIHJlbGF0ZWQgdG8gVEVEIFlhbmcpIGFyZSBpbmZvcm1hbGx5IG1lZXRpbmcgb24g V2VkLiAxMi8xNyBhdCAyOjAwIFBNLCBFVC4gV2Ugd2lsbCBmb2N1cyBvbiBHTVBMUyBURUQgWWFu ZywgaW5jbHVkaW5nIG9wdGljYWwgVEVELiBEZXRhaWxzIGZvciB0aGUgd2ViRXggY2FsbCBhcmUg YXMgZm9sbG93cy4gUGxlYXNlIGpvaW4gdXMgaWYgeW91IGFyZSBpbnRlcmVzdGVkLg0KDQpUaGFu a3MNCg0KUmVnYXJkcyDDouKCrMKmIFphZmFyDQoNCg0KKy0tLSstLS0rLS0tKy0tLSstLS0rLS0t Ky0tLSstLS0rLS0tKy0tLSstLS0rDQoNClBsZWFzZSBkbyBub3QgZWRpdCB0ZXh0IGJlbG93IHRo aXMgbGluZS4NCg0KWW91IGFyZSBpbnZpdGVkIHRvIGFuIG9ubGluZSBtZWV0aW5nIHVzaW5nIFdl YkV4Lg0KDQoNCk1lZXRpbmcgTnVtYmVyOiAzMDQzODIxMDENCg0KTWVldGluZyBQYXNzd29yZDog R01QTFNURUQNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNClRvIGpvaW4gdGhpcyBtZWV0aW5nIChOb3cgZnJvbSBtb2JpbGUgZGV2 aWNlcyEpDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KMS4gR28gdG8gaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY28vai5waHA/ TVRJRD1tMWQ0MDg3OTQ1NGU2N2M4ZmVjM2MzMGNhZmE5NmUxM2QNCg0KDQoyLiBFbnRlciB0aGUg bWVldGluZyBwYXNzd29yZDogR01QTFNURUQNCg0KMy4gQ2xpY2sgJ0pvaW4gTm93Jy4NCg0KNC4g Rm9sbG93IHRoZSBpbnN0cnVjdGlvbnMgdGhhdCBhcHBlYXIgb24geW91ciBzY3JlZW4uDQoNCg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCkFMRVJUOlRvbGwtRnJlZSBEaWFsIFJlc3RyaWN0aW9ucyBmb3IgKDQwOCkg YW5kICg5MTkpIEFyZWEgQ29kZXMNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNClRoZSBhZmZlY3RlZCB0b2xsIGZy ZWUgbnVtYmVycyBhcmU6ICg4NjYpIDQzMi05OTAzIGZvciB0aGUgU2FuIEpvc2UvTWlscGl0YXMg YXJlYSBhbmQgKDg2NikgMzQ5LTM1MjAgZm9yIHRoZSBSVFAgYXJlYS4NCg0KDQpQbGVhc2UgZGlh bCB0aGUgbG9jYWwgYWNjZXNzIG51bWJlciBmb3IgeW91ciBhcmVhIGZyb20gdGhlIGxpc3QgYmVs b3c6DQoNCi0gU2FuIEpvc2UvTWlscGl0YXMgKDQwOCkgYXJlYTogNTI1LTY4MDANCg0KLSBSVFAg KDkxOSkgYXJlYTogMzkyLTMzMzANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRvIGpvaW4gdGhlIHRlbGVjb25mZXJlbmNlIG9u bHkNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQoxLiBEaWFsIGludG8gQ2lzY28gV2ViRXggKHZpZXcgYWxsIEdsb2JhbCBBY2Nlc3Mg TnVtYmVycyBhdCBodHRwOi8vY2lzY28uY29tL2VuL1VTL2Fib3V0L2RvaW5nX2J1c2luZXNzL2Nv bmZlcmVuY2luZy9pbmRleC5odG1sKQ0KDQoyLiBGb2xsb3cgdGhlIHByb21wdHMgdG8gZW50ZXIg dGhlIE1lZXRpbmcgTnVtYmVyIChsaXN0ZWQgYWJvdmUpIG9yIEFjY2VzcyBDb2RlIGZvbGxvd2Vk IGJ5IHRoZSAjIHNpZ24uDQoNCg0KU2FuIEpvc2UsIENBOiArMS40MDguNTI1LjY4MDANCg0KUlRQ OiArMS45MTkuMzkyLjMzMzANCg0KDQpVUy9DYW5hZGE6ICsxLjg2Ni40MzIuOTkwMw0KDQpVbml0 ZWQgS2luZ2RvbTogKzQ0LjIwLjg4MjQuMDExNw0KDQoNCkluZGlhOiArOTEuODAuNDM1MC4xMTEx DQoNCkdlcm1hbnk6ICs0OS42MTkuNjc3My45MDAyDQoNCg0KSmFwYW46ICs4MS4zLjU3NjMuOTM5 NA0KDQpDaGluYTogKzg2LjEwLjg1MTUuNTY2Ng0KDQoNCmh0dHA6Ly93d3cud2ViZXguY29tPGh0 dHA6Ly93d3cud2ViZXguY29tLz4NCg0KDQpDQ1A6KzE0MDg1MjU2ODAweDMwNDM4MjEwMSMNCg0K DQpJTVBPUlRBTlQgTk9USUNFOiBUaGlzIFdlYkV4IHNlcnZpY2UgaW5jbHVkZXMgYSBmZWF0dXJl IHRoYXQgYWxsb3dzIGF1ZGlvIGFuZCBhbnkgZG9jdW1lbnRzIGFuZCBvdGhlciBtYXRlcmlhbHMg ZXhjaGFuZ2VkIG9yIHZpZXdlZCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQuIEJ5 IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2gg cmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIHRoZSByZWNvcmRpbmcsIGRpc2N1 c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBtZWV0aW5nIGhvc3QgcHJpb3IgdG8gdGhlIHN0YXJ0 IG9mIHRoZSByZWNvcmRpbmcgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uIFBsZWFzZSBub3Rl IHRoYXQgYW55IHN1Y2ggcmVjb3JkaW5ncyBtYXkgYmUgc3ViamVjdCB0byBkaXNjb3ZlcnkgaW4g dGhlIGV2ZW50IG9mIGxpdGlnYXRpb24uDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClRlYXMgbWFpbGluZyBsaXN0DQpUZWFzQGlldGYub3JnPG1h aWx0bzpUZWFzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90ZWFzDQoNCg== --_000_D0B3D8D8E443Bzaliciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <526EEEFC62C47040B24ED95AE3552152@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+DQo8ZGl2Pkhp IExvdS0mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBpZGVhIGhlcmUg d2FzIG5vdCB0byBieSBwYXNzIHRoZSBEVCBidXQgdG8gd29yayB3aXRoIHRoZSBzYW1lLiBJIGhh dmUgYmVlbiBwYXJ0aWNpcGF0aW5nIGluIGJpLXdlZWtseSBjYWxscy4gV2Ugd291bGQgbGlrZSB0 byBtYWtlIHByb2dyZXNzIG9uIChPcHRpY2FsKSBURUQgYXJlYSBhbmQgaGVuY2UgYmFzZWQgb24g cHJpdmF0ZSBlbWFpbCBkaXNjdXNzaW9uIHdpdGggeW91LCBBZHJpYW4gYW5kIG90aGVycyBJIHRh dWdodCB0aGlzDQogbWVldGluZyB3aWxsIGp1c3QgY29tcGxpbWVudCB0aGUgZXhpc3Rpbmcgd29y ay4gSW4gYW55IGNhc2UsIEkgd2lsbCBjYW5jZWwgdGhlIDEyLzE3IGNhbGwuIFdpbGwgd2FpdCBm b3IgbW9yZSBzcGVjaWZpYyBkaXJlY3Rpb25zIGluIDEyLzE4J3MmbmJzcDt2aXJ0dWFsIGludGVy aW0gbWVldGluZy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj5U aGFua3M8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHMg4oCmIFphZmFyPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JD X0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNp emU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVk aXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsg UEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRk ZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDs8YSBo cmVmPSJtYWlsdG86bGJlcmdlckBsYWJuLm5ldCI+bGJlcmdlckBsYWJuLm5ldDwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Ij5sYmVyZ2VyQGxhYm4ubmV0PC9h PiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlN1 bmRheSwgRGVjZW1iZXIgMTQsIDIwMTQgOTo0NSBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5UbzogPC9zcGFuPnphbGkgJmx0OzxhIGhyZWY9Im1haWx0bzp6YWxpQGNpc2Nv LmNvbSI+emFsaUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+ Y2NhbXBAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5v cmciPmNjYW1wQGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpUZWFzQGll dGYub3JnIj5UZWFzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRlYXNA aWV0Zi5vcmciPlRlYXNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7R2VvcmdlDQogU3dhbGxvdyAo c3dhbGxvdykmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzd2FsbG93QGNpc2NvLmNvbSI+c3dh bGxvd0BjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRk b2cuY28udWsiPmFkcmlhbkBvbGRkb2cuY28udWs8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86YWRyaWFuQG9sZGRvZy5jby51ayI+YWRyaWFuQG9sZGRvZy5jby51azwvYT4mZ3Q7LCAmcXVv dDtUYXJlayBTYWFkICh0c2FhZCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0c2FhZEBjaXNj by5jb20iPnRzYWFkQGNpc2NvLmNvbTwvYT4mZ3Q7LA0KICZxdW90OydCUlVOR0FSRCwgREVCT1JB SCBBJyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRiMzU0NkBhdHQuY29tIj5kYjM1NDZAYXR0 LmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6 IDwvc3Bhbj5SZTogW1RlYXNdIEluZm9ybWFsIG1lZXRpbmcgZm9yIGRpc2N1c3Npb25zIG9uIEdN UExTIFRFRCBZYW5nPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg aWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVG VDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8 ZGl2Pg0KPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiBibGFjazsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IGJsYWNrOyI+DQo8cCBzdHlsZT0i bWFyZ2luOiAwIDAgMWVtIDA7IGNvbG9yOiBibGFjazsiPlphZmFyLDwvcD4NCjxwIHN0eWxlPSJt YXJnaW46IDAgMCAxZW0gMDsgY29sb3I6IGJsYWNrOyI+UGVyIHByb2Nlc3MsIGFueW9uZSBjYW4g aGF2ZSBhbnkgaW5mb3JtYWwgZGlzY3Vzc2lvbiBvbiBhbnkgdG9waWMgdGhhdCB0aGV5J2QgbGlr ZSBhbmQgc3VibWl0IGFueSBpbmRpdmlkdWFsIGRvY3VtZW50IHRoYXQgdGhleSBhdXRob3IuIEFu ZCBhbGwgdGhpcyBlbmVyZ3kgYXJvdW5kIFlBTkcgYXQgdGhlIG1vbWVudCBpcyBmYWJ1bG91cy4N CjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDAgMCAxZW0gMDsgY29sb3I6IGJsYWNrOyI+QnV0IHBs ZWFzZSBrZWVwIGluIG1pbmQgdGhhdCBvbiB0aGlzICpleGFjdCogdG9waWMgdGhlcmUgaGFzIGJl ZW4gYSBURUFTIFdHIGRlc2lnbiB0ZWFtIGFubm91bmNlZCwgYW5kIGEgdmlydHVhbCBpbnRlcmlt IG1lZXRpbmcgc2NoZWR1bGVkIGZvciB0aGUgMTh0aC4mbmJzcDsgSSBlbmNvdXJhZ2UgeW91IChh bmQgYW55b25lIGVsc2Ugd2hvIGlzIGludGVyZXN0ZWQpIHRvIGNvbnRyaWJ1dGUNCiB0byB0aGVz ZSBXRyBlZmZvcnRzLjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDAgMCAxZW0gMDsgY29sb3I6IGJs YWNrOyI+Rm9yIGV4YW1wbGUsIHlvdSBjb3VsZCBzZW5kIG1haWwgdG8gdGhlIGRlc2lnbiB0ZWFt IGxldHRpbmcgdGhlbSBrbm93IHRoYXQgeW91IHdvdWxkIGxpa2UgdG8gY29udHJpYnV0ZSwgb3Ig aWYgeW91IGhhdmUgc29tZXRoaW5nIG1vcmUgY29uY3JldGUgdG8gY29udHJpYnV0ZSwgeW91IGNv dWxkIGFzayBmb3IgYSZuYnNwOyBzbG90IGF0IHRoZSBpbnRlcmltLg0KPC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjogMCAwIDFlbSAwOyBjb2xvcjogYmxhY2s7Ij5XaGlsZSB0aGUgRFQgaGFzIG5vIHNw ZWNpZmljIGRpcmVjdGlvbiBvciByZXN0cmljdGlvbiBvbiBob3cgdGhleSBjb25kdWN0IHRoZWly IHdvcmssIEkgd291bGQgYmUgc3VycHJpc2VkIGlmIHRoZXkgZGlkbid0IGJhc2UgdGhlaXIgd29y ayBvbiB0aGUgZXhpc3RpbmcgZHJhZnRzIGluIHRoZSBhcmVhLiBUbyBiZSBjbGVhciwgJnF1b3Q7 dGhlIGFyZWEmcXVvdDsgbWVhbnMgZ2VuZXJpYyBURQ0KIFRvcG9sb2d5IHdoZXJldmVyIHRoZSBp bmZvcm1hdGlvbiBjb21lcyBmcm9tIC8gaXMgdGFyZ2V0ZWQsIGkuZS4sIE1QTFMsIEdNUExTLCBQ Q0UsIGNvbmZpZywgZXRjLiZuYnNwOyBXaGlsZSB0aGUgRFQgd2lsbCBhbHNvIG5lZWQgdG8gY29u c2lkZXIgaG93IGRhdGEgcGxhbmUgc3BlY2lmaWMgKGUuZy4sIFdTT04sIGxhYmVsZWQgcGFja2V0 cykgaW5mb3JtYXRpb24gZml0cyBpbiB0byBhL3RoZWlyIGdlbmVyaWMgVEUgbW9kZWwsIHN1Y2gg bW9kZWxpbmcgd29yaw0KIHdpbGwgYmUgZG9uZSBpbiBDQ0FNUCBhbmQgTVBMUyAtLSBhbmQgcHJl c3VtYWJseSBpbiBzeW5jIHdpdGggdGhlIGdlbmVyaWMgbW9kZWwuPC9wPg0KPHAgc3R5bGU9Im1h cmdpbjogMCAwIDFlbSAwOyBjb2xvcjogYmxhY2s7Ij5JZiB5b3UgdGhpbmsgeW91IGhhdmUgYWRk aXRpb25hbCBnZW5lcmljIFRFIGluZm9ybWF0aW9uIHRoYXQgbmVlZHMgdG8gYmUgbW9kZWxlZCB0 aGF0IGlzJm5ic3A7IGJleW9uZCB3aGF0IGlzIGNvdmVyZWQgaW4gdGhlIERUJ3Mgc2NvcGUgKGFu ZCB0aGUgb3RoZXIgZGlzY3Vzc2lvbnMgdGhhdCBhcmUgY3VycmVudGx5IGhhcHBlbmluZyBpbiBN UExTKSwgdGhpcyB3b3VsZCBiZSBhDQogZ29vZCBzdWJqZWN0IGZvciB5b3UgdG8gcmFpc2UgYXQg KGFuZCByZXF1ZXN0IGEgZGlzY3Vzc2lvbiBzbG90IGZvcikgdGhlIGludGVyaW0gbWVldGluZy48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwIDAgMWVtIDA7IGNvbG9yOiBibGFjazsiPklmIHlvdXIg Zm9jdXMgaXMgd2l0aGluIHRoZSBzY29wZSBvZiB0aGUgRFQsIEkgZXhwZWN0IHRoYXQgd2Ugd2ls bCBoZWFyIGZyb20gdGhlIERUIGF0IHRoZSBpbnRlcmltIHNvIHRoaXMgd2lsbCBwcmVzZW50IGEg Z29vZCBvcHBvcnR1bml0eSB0byBoZWFyIGFuZCBkaXNjdXNzIGhvdyB0aGV5IHBsYW4gdG8gY29u ZHVjdCB0aGVpciB3b3JrIGFuZCBob3cgb3RoZXJzIG1pZ2h0DQogY29udHJpYnV0ZSBiZWZvcmUg dGhlcmUgaXMgYSBXRyBkb2N1bWVudCBvbiB0aGUgdG9waWMuPGJyPg0KPC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjogMCAwIDFlbSAwOyBjb2xvcjogYmxhY2s7Ij5Mb3U8YnI+DQo8L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImNvbG9yOiBibGFjazsiPg0KPHAgc3R5bGU9ImNvbG9yOiBibGFjazsgZm9u dC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWwsDQogICAgICAgICAgc2Fucy1zZXJpZjsg bWFyZ2luOiAxMHB0IDA7Ij4NCk9uIERlY2VtYmVyIDE0LCAyMDE0IDM6MTA6MjUgQU0gJnF1b3Q7 WmFmYXIgQWxpICh6YWxpKSZxdW90OyA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBo cmVmPSJtYWlsdG86emFsaUBjaXNjby5jb20iPg0KJmx0O3phbGlAY2lzY28uY29tJmd0OzwvYT4g d3JvdGU6PC9wPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0ibWFyZ2luOiAwIDAgMA0KICAgICAgICAgIDAuNzVleDsgYm9yZGVyLWxlZnQ6IDFweCBz b2xpZCAjODA4MDgwOyBwYWRkaW5nLWxlZnQ6IDAuNzVleDsiPg0KPGRpdj5EZWFyIFdHczombmJz cDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNvbWUgb2YgdXMgKGVzcC4gYXV0aG9y cyBvZiBkb2N1bWVudHMgcmVsYXRlZCB0byBURUQgWWFuZykgYXJlIGluZm9ybWFsbHkmbmJzcDtt ZWV0aW5nIG9uIFdlZC4gMTIvMTcgYXQgMjowMCBQTSwgRVQuJm5ic3A7PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBDYWxpYnJpOyAiPldlIHdpbGwgZm9jdXMgb24gR01QTFMgVEVEIFlhbmcsIGlu Y2x1ZGluZyBvcHRpY2FsIFRFRC48L3NwYW4+Jm5ic3A7RGV0YWlscyBmb3IgdGhlIHdlYkV4IGNh bGwgYXJlIGFzIGZvbGxvd3MuDQogUGxlYXNlIGpvaW4gdXMgaWYgeW91IGFyZSBpbnRlcmVzdGVk LiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2PlRoYW5rczwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkcyDDouKCrMKmIFphZmFyPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBm b250LWZhbWlseTogQ2FsaWJyaTsgIj4mIzQzOy0tLSYjNDM7LS0tJiM0MzstLS0mIzQzOy0tLSYj NDM7LS0tJiM0MzstLS0mIzQzOy0tLSYjNDM7LS0tJiM0MzstLS0mIzQzOy0tLSYjNDM7LS0tJiM0 MzsmbmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJp OyAiPlBsZWFzZSBkbyBub3QgZWRpdCB0ZXh0IGJlbG93IHRoaXMgbGluZS4mbmJzcDs8L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyAiPllvdSBhcmUgaW52 aXRlZCB0byBhbiBvbmxpbmUgbWVldGluZyB1c2luZyBXZWJFeC4mbmJzcDs8L3A+DQo8cCBzdHls ZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtaW4taGVpZ2h0Og0KICAgICAg ICAgICAgICAxN3B4OyAiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1m YW1pbHk6IENhbGlicmk7ICI+TWVldGluZyBOdW1iZXI6IDMwNDM4MjEwMSZuYnNwOzwvcD4NCjxw IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7ICI+TWVldGluZyBQYXNz d29yZDogR01QTFNURUQmbmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFt aWx5OiBDYWxpYnJpOyBtaW4taGVpZ2h0Og0KICAgICAgICAgICAgICAxN3B4OyAiPjxicj4NCjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7ICI+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZuYnNwOzwv cD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7ICI+VG8gam9p biB0aGlzIG1lZXRpbmcgKE5vdyBmcm9tIG1vYmlsZSBkZXZpY2VzISkmbmJzcDs8L3A+DQo8cCBz dHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyAiPi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mbmJzcDs8L3A+DQo8cCBz dHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyAiPjEuIEdvIHRvJm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY28vai5waHA/TVRJRD1tMWQ0MDg3 OTQ1NGU2N2M4ZmVjM2MzMGNhZmE5NmUxM2QiPmh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nv L2oucGhwP01USUQ9bTFkNDA4Nzk0NTRlNjdjOGZlYzNjMzBjYWZhOTZlMTNkPC9hPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7IG1pbi1oZWlnaHQ6DQog ICAgICAgICAgICAgIDE3cHg7ICI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBm b250LWZhbWlseTogQ2FsaWJyaTsgIj4yLiBFbnRlciB0aGUgbWVldGluZyBwYXNzd29yZDogR01Q TFNURUQmbmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxp YnJpOyAiPjMuIENsaWNrICdKb2luIE5vdycuJm5ic3A7PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjog MHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsgIj40LiBGb2xsb3cgdGhlIGluc3RydWN0aW9ucyB0 aGF0IGFwcGVhciBvbiB5b3VyIHNjcmVlbi4mbmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAw cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtaW4taGVpZ2h0Og0KICAgICAgICAgICAgICAxN3B4 OyAiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGli cmk7IG1pbi1oZWlnaHQ6DQogICAgICAgICAgICAgIDE3cHg7ICI+PGJyPg0KPC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsgIj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJm5ic3A7PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsgIj5BTEVSVDpU b2xsLUZyZWUgRGlhbCBSZXN0cmljdGlvbnMgZm9yICg0MDgpIGFuZCAoOTE5KSBBcmVhIENvZGVz Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsg Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tJm5ic3A7PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTog Q2FsaWJyaTsgbWluLWhlaWdodDoNCiAgICAgICAgICAgICAgMTdweDsgIj48YnI+DQo8L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyAiPlRoZSBhZmZlY3Rl ZCB0b2xsIGZyZWUgbnVtYmVycyBhcmU6ICg4NjYpIDQzMi05OTAzIGZvciB0aGUgU2FuIEpvc2Uv TWlscGl0YXMgYXJlYSBhbmQgKDg2NikgMzQ5LTM1MjAgZm9yIHRoZSBSVFAgYXJlYS4mbmJzcDs8 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtaW4taGVp Z2h0Og0KICAgICAgICAgICAgICAxN3B4OyAiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7ICI+UGxlYXNlIGRpYWwgdGhlIGxvY2FsIGFjY2Vz cyBudW1iZXIgZm9yIHlvdXIgYXJlYSBmcm9tIHRoZSBsaXN0IGJlbG93OiZuYnNwOzwvcD4NCjxw IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7ICI+LSBTYW4gSm9zZS9N aWxwaXRhcyAoNDA4KSBhcmVhOiA1MjUtNjgwMCZuYnNwOzwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7ICI+LSBSVFAgKDkxOSkgYXJlYTogMzkyLTMzMzAm bmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyBt aW4taGVpZ2h0Og0KICAgICAgICAgICAgICAxN3B4OyAiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7ICI+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZuYnNwOzwvcD4NCjxwIHN0eWxlPSJt YXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7ICI+VG8gam9pbiB0aGUgdGVsZWNvbmZl cmVuY2Ugb25seSZuYnNwOzwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6 IENhbGlicmk7ICI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSZuYnNwOzwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6 IENhbGlicmk7ICI+MS4gRGlhbCBpbnRvIENpc2NvIFdlYkV4ICh2aWV3IGFsbCBHbG9iYWwgQWNj ZXNzIE51bWJlcnMgYXQmbmJzcDs8YSBocmVmPSJodHRwOi8vY2lzY28uY29tL2VuL1VTL2Fib3V0 L2RvaW5nX2J1c2luZXNzL2NvbmZlcmVuY2luZy9pbmRleC5odG1sIj5odHRwOi8vY2lzY28uY29t L2VuL1VTL2Fib3V0L2RvaW5nX2J1c2luZXNzL2NvbmZlcmVuY2luZy9pbmRleC5odG1sPC9hPikm bmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyAi PjIuIEZvbGxvdyB0aGUgcHJvbXB0cyB0byBlbnRlciB0aGUgTWVldGluZyBOdW1iZXIgKGxpc3Rl ZCBhYm92ZSkgb3IgQWNjZXNzIENvZGUgZm9sbG93ZWQgYnkgdGhlICMgc2lnbi4mbmJzcDs8L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtaW4taGVpZ2h0 Og0KICAgICAgICAgICAgICAxN3B4OyAiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBw eDsgZm9udC1mYW1pbHk6IENhbGlicmk7ICI+U2FuIEpvc2UsIENBOiAmIzQzOzEuNDA4LjUyNS42 ODAwJm5ic3A7PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJy aTsgIj5SVFA6ICYjNDM7MS45MTkuMzkyLjMzMzAmbmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtaW4taGVpZ2h0Og0KICAgICAgICAgICAgICAx N3B4OyAiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENh bGlicmk7ICI+VVMvQ2FuYWRhOiAmIzQzOzEuODY2LjQzMi45OTAzJm5ic3A7PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsgIj5Vbml0ZWQgS2luZ2RvbTog JiM0Mzs0NC4yMC44ODI0LjAxMTcmbmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZv bnQtZmFtaWx5OiBDYWxpYnJpOyBtaW4taGVpZ2h0Og0KICAgICAgICAgICAgICAxN3B4OyAiPjxi cj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7ICI+ SW5kaWE6ICYjNDM7OTEuODAuNDM1MC4xMTExJm5ic3A7PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjog MHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsgIj5HZXJtYW55OiAmIzQzOzQ5LjYxOS42NzczLjkw MDImbmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJp OyBtaW4taGVpZ2h0Og0KICAgICAgICAgICAgICAxN3B4OyAiPjxicj4NCjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7ICI+SmFwYW46ICYjNDM7ODEuMy41 NzYzLjkzOTQmbmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBD YWxpYnJpOyAiPkNoaW5hOiAmIzQzOzg2LjEwLjg1MTUuNTY2NiZuYnNwOzwvcD4NCjxwIHN0eWxl PSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7IG1pbi1oZWlnaHQ6DQogICAgICAg ICAgICAgIDE3cHg7ICI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZh bWlseTogQ2FsaWJyaTsgIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7 ICI+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vIj5odHRwOi8vd3d3LndlYmV4LmNvbTwv YT48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJy aTsgbWluLWhlaWdodDoNCiAgICAgICAgICAgICAgMTdweDsgIj48YnI+DQo8L3A+DQo8cCBzdHls ZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyAiPkNDUDomIzQzOzE0MDg1MjU2 ODAweDMwNDM4MjEwMSMmbmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFt aWx5OiBDYWxpYnJpOyBtaW4taGVpZ2h0Og0KICAgICAgICAgICAgICAxN3B4OyAiPjxicj4NCjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7ICI+SU1QT1JU QU5UIE5PVElDRTogVGhpcyBXZWJFeCBzZXJ2aWNlIGluY2x1ZGVzIGEgZmVhdHVyZSB0aGF0IGFs bG93cyBhdWRpbyBhbmQgYW55IGRvY3VtZW50cyBhbmQgb3RoZXIgbWF0ZXJpYWxzIGV4Y2hhbmdl ZCBvciB2aWV3ZWQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLiBCeSBqb2luaW5n IHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkNCiBjb25zZW50IHRvIHN1Y2ggcmVjb3Jk aW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIHRoZSByZWNvcmRpbmcsIGRpc2N1c3MgeW91 ciBjb25jZXJucyB3aXRoIHRoZSBtZWV0aW5nIGhvc3QgcHJpb3IgdG8gdGhlIHN0YXJ0IG9mIHRo ZSByZWNvcmRpbmcgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uIFBsZWFzZSBub3RlIHRoYXQg YW55IHN1Y2ggcmVjb3JkaW5ncyBtYXkgYmUgc3ViamVjdCB0byBkaXNjb3ZlcnkgaW4gdGhlIGV2 ZW50IG9mDQogbGl0aWdhdGlvbi4gJm5ic3A7ICZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NClRlYXMgbWFpbGluZyBsaXN0PGJyPg0KPGEgY2xhc3M9 Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOlRlYXNAaWV0Zi5vcmciPlRl YXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgY2xhc3M9ImFxbS1hdXRvbGluayBhcW0tYXV0b3dyYXAi IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhcyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzPC9hPjxicj4NCjxicj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D0B3D8D8E443Bzaliciscocom_-- From nobody Mon Dec 15 06:31:00 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45B31A6FE8 for ; Mon, 15 Dec 2014 06:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 N0xvxEOfdRlL for ; Mon, 15 Dec 2014 06:30:53 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 20ACB1A6FE5 for ; Mon, 15 Dec 2014 06:30:53 -0800 (PST) Received: (qmail 2748 invoked by uid 0); 15 Dec 2014 14:30:46 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 15 Dec 2014 14:30:46 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id TqWj1p00c2SSUrH01qWmXf; Mon, 15 Dec 2014 07:30:46 -0700 X-Authority-Analysis: v=2.1 cv=B+wqjodM c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=GLD-xdxnQi9oTvv26GYA:9 a=nKoPvr6NYjWjhrXQ:21 a=Fq6x5PhVV9lvd_DH:21 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=BzSdf5LhSEzBadiKmo2c41O/nJgyZlOJFjvn08y0nXE=; b=k7d3In4ggUGNW/zW0JE6eG1jQVkzZHMsC0FSBvaByH7UgcOktJ9K7sdpSx4rbIW4lLC+BxJkC/GHL1tbBq3j++jCFOCQBKq43UElBOx18prUbprQCeA4UTqwROQ0fKra; Received: from box313.bluehost.com ([69.89.31.113]:56311 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Y0Wfb-0004tS-3m; Mon, 15 Dec 2014 07:30:43 -0700 Message-ID: <548EF0B9.9020805@labn.net> Date: Mon, 15 Dec 2014 09:31:21 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Fatai Zhang References: <20141205160224.15830.11974.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/cJz_lr1iQlZhXnNsddSkZm28x_s Cc: "ccamp@ietf.org" , "ietf@ietf.org" , "teas@ietf.org" Subject: Re: [Teas] [CCAMP] TEAS WG Virtual Interim Meeting: December 18, starting at 20:00 UTC (formerly CCAMP WG Virtual Interim) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 14:30:57 -0000 Fatai, On 12/15/2014 3:31 AM, Fatai Zhang wrote: > Hi Lou and Deborah, > > I assume that this interim meeting is open for the whole TEAS WG, Per IETF process, interim meetings *must* be open to any/all who wish to attend, and this virtual interim is no different. The webex information will be posted to the TEAS WG along with the agenda, probably sometime tomorrow. > but I think the time is not so comfortable for the Asian, who might be interested, :-) > I understand, and we're not happy about this. Personally I'm not a big fan of virtual interim meetings (and think they must be judiciously used/scheduled) for exactly this reason, i.e. no matter what time is picked, it'll difficult for someone to attend. That said, interims can still be valuable. We will try to not make it difficult for the same group/region if/when we schedule a virtual interim in the future. It's my understanding that a recording of the webex session will be available. Lou > > > > Best Regards > > Fatai > > > -----Original Message----- > From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of IESG Secretary > Sent: Saturday, December 06, 2014 12:02 AM > To: IETF Announcement List > Cc: ccamp@ietf.org; teas@ietf.org > Subject: [CCAMP] TEAS WG Virtual Interim Meeting: December 18, starting at 20:00 UTC (formerly CCAMP WG Virtual Interim) > > The previously announced TE Topology Yang Model Virtual Interim will be > held as announced, but will be hosted by the new TEAS WG rather than > the CCAMP WG. The original announcement is below. > > > On Dec 3, 2014, at 12:26 PM, IESG Secretary wrote: >> TE Topology Yang Model Virtual Interim (CCAMP) >> >> There is a cluster of work around YANG models for topology and the TED >> (TE Topology Database). The Routing ADs are planning to have the TEAS >> working group formalized soon and the group is expected to have an >> explicit deliverable of a YANG model for the TED. We, the current >> CCAMP chairs, have been asked to get this effort moving by arranging a >> virtual interim meeting on the topic. >> >> The primary objectives of the meeting are to (a) get some basic >> agreement on TE topology model 'use cases' (e.g., driven by I2RS, PCE, >> ALTO, TEAS), (b) establish the dependencies/relationships of a TE >> topology model to other models (e.g., router, topology, routing >> protocols, ...) and finally, (c) to provide the needed foundation for >> a TEAS design team to be formed and deliver a TE Topology Yang Model >> draft by Dallas. >> >> A related activity has also started in the MPLS WG on a TE LSP Yang >> Model. This topic will *not* be the focus of this interim and we >> expect that work to continue concurrently. >> >> The Virtual interim is scheduled for 2-3 hours on December 18, >> starting at 20:00 UTC. >> >> The agenda and other logistic information for the meeting will be >> posted & discussed on the CCAMP and new TEAS mailing list >> (ccamp@ietf.org and teas@ietf.org). >> >> The existing set of related drafts includes: >> draft-liu-yang-abstract-te-topo >> draft-clemm-i2rs-yang-l3-topo >> draft-clemm-i2rs-yang-network-topo >> draft-amante-i2rs-topology-use-cases >> draft-chen-mpls-te-yang-cfg (LSP focused) >> draft-gandhi-mpls-te-yang-model (LSP focused) >> draft-ietf-netmod-routing-cfg (Foundational work, not topology >> specific) >> >> Deborah and Lou >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > From nobody Mon Dec 15 08:19:03 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30161A6FC3 for ; Mon, 15 Dec 2014 08:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Ye5xf4dOmOZP for ; Mon, 15 Dec 2014 08:18:59 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8356F1A8033 for ; Mon, 15 Dec 2014 08:18:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3343; q=dns/txt; s=iport; t=1418660334; x=1419869934; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ts4y87MU2ZP2sFByPqNMGjc8RYi5PxVWrj04qfcMZwQ=; b=HEWq3bYept12jtJI1KoZv+nD2+SiZRr3rQVy47Wv+vByaOotZEXfbQuR xNB+CBbke625VAM0ZqUvDdjKRcqm02r0WOQny8DGcmeMRvqdD5fbmkroH J+wFaxQv9NPW+fUCuDAl9Pkb/crlL3ukisFd0xF4zeS6AO1OIoyrihr+i k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4GAJEJj1StJV2c/2dsb2JhbABagkNDUlgEgwLCTQEJhXICHIEBFgEBAQEBfYQNAQEEAQEBawsQAgEIBAE6BQICJQsUEQIEAQ0FiCwNoG6cVwaWGwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjxARATUXBAeCYoFHBY4CiG+BC4JeihaDOCKCMIE8boEMOX4BAQE X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208,217";a="113007704" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by mtv-iport-4.cisco.com with ESMTP; 15 Dec 2014 16:18:54 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sBFGIqOC008500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Dec 2014 16:18:53 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.252]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 10:18:52 -0600 From: "Tarek Saad (tsaad)" To: "Mike Taillon (mtaillon)" , TEAS WG , Lou Berger Thread-Topic: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document Thread-Index: AQHQFlJeWNEXLVsItkaiNSBPlr4JxpyMrbaAgASLYQD//7CmAA== Date: Mon, 15 Dec 2014 16:18:51 +0000 Message-ID: References: <0F2C9154-B417-438E-A6A4-BAFFDB16E35A@cisco.com> In-Reply-To: <0F2C9154-B417-438E-A6A4-BAFFDB16E35A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.86.243.124] Content-Type: multipart/alternative; boundary="_000_D0B4739B15E9DAtsaadciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/Au9xXuDh09P1IuAEH9cxGThUPaw Cc: "Rakesh Gandhi \(rgandhi\)" , "frederic.jounay@orange.ch" , "Zafar Ali \(zali\)" , "manav@ionosnetworks.com" , "lizho.jin@gmail.com" Subject: Re: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 16:19:00 -0000 --_000_D0B4739B15E9DAtsaadciscocom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 WWVzL3N1cHBvcnQgYXMgYSBjby1hdXRob3IuDQoNClJlZ2FyZHMsDQpUYXJlaw0KDQpPbiAyMDE0 LTEyLTEyIDQ6MjcgUE0sICJMb3UgQmVyZ2VyIiA8bGJlcmdlckBsYWJuLm5ldDxtYWlsdG86bGJl cmdlckBsYWJuLm5ldD4+IHdyb3RlOg0KDQoNCkFsbCwNCg0KVGhpcyBpcyBzdGFydCBvZiBhIHR3 byB3ZWVrIHBvbGwgb24gbWFraW5nDQpkcmFmdC10c2FhZC1jY2FtcC1yc3ZwdGUtYmlkaXItbHNw LWZhc3RyZXJvdXRlLTA1IGEgVEVBUyB3b3JraW5nIGdyb3VwDQpkb2N1bWVudC4gUGxlYXNlIHNl bmQgZW1haWwgdG8gdGhlIGxpc3QgaW5kaWNhdGluZyCp+Hllcy9zdXBwb3J0qfcgb3INCqn4bm8v ZG8gbm90IHN1cHBvcnSp9y4gSWYgaW5kaWNhdGluZyBubywgcGxlYXNlIHN0YXRlIHlvdXIgdGVj aG5pY2FsDQpyZXNlcnZhdGlvbnMgd2l0aCB0aGUgZG9jdW1lbnQuDQoNClRoZSBwb2xsIGVuZHMg RnJpZGF5IERlY2VtYmVyIDI2dGguDQoNClRoYW5rcywNCg0KRGVib3JhaCBhbmQgTG91DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUZWFzIG1haWxp bmcgbGlzdA0KVGVhc0BpZXRmLm9yZzxtYWlsdG86VGVhc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhcw0KDQo= --_000_D0B4739B15E9DAtsaadciscocom_ Content-Type: text/html; charset="euc-kr" Content-ID: <6B7F8A61D988CA46AB0D5E941BC5DC0E@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+WWVzL3N1cHBv cnQgYXMgYSBjby1hdXRob3IuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9M S19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyAiPg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRpdj5UYXJlazxicj4NCjxkaXY+PGZv bnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGNvbG9yPSIjMjI2MGM1Ij48YnI+DQo8L2ZvbnQ+ T24gMjAxNC0xMi0xMiA0OjI3IFBNLCAmcXVvdDtMb3UgQmVyZ2VyJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86bGJlcmdlckBsYWJuLm5ldCI+bGJlcmdlckBsYWJuLm5ldDwvYT4mZ3Q7IHdyb3Rl Ojxicj4NCjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBjb2xvcj0iIzIyNjBjNSI+PGJy Pg0KPGJyPg0KPC9mb250Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PkFsbCw8YnI+ DQo8YnI+DQpUaGlzIGlzIHN0YXJ0IG9mIGEgdHdvIHdlZWsgcG9sbCBvbiBtYWtpbmc8YnI+DQpk cmFmdC10c2FhZC1jY2FtcC1yc3ZwdGUtYmlkaXItbHNwLWZhc3RyZXJvdXRlLTA1IGEgVEVBUyB3 b3JraW5nIGdyb3VwPGJyPg0KZG9jdW1lbnQuIFBsZWFzZSBzZW5kIGVtYWlsIHRvIHRoZSBsaXN0 IGluZGljYXRpbmcgqfh5ZXMvc3VwcG9ydKn3IG9yPGJyPg0Kqfhuby9kbyBub3Qgc3VwcG9ydKn3 LiBJZiBpbmRpY2F0aW5nIG5vLCBwbGVhc2Ugc3RhdGUgeW91ciB0ZWNobmljYWw8YnI+DQpyZXNl cnZhdGlvbnMgd2l0aCB0aGUgZG9jdW1lbnQuPGJyPg0KPGJyPg0KVGhlIHBvbGwgZW5kcyBGcmlk YXkgRGVjZW1iZXIgMjZ0aC48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KPGJyPg0KRGVib3JhaCBh bmQgTG91PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpUZWFzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUZWFz QGlldGYub3JnIj5UZWFzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90ZWFzPC9hPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D0B4739B15E9DAtsaadciscocom_-- From nobody Mon Dec 15 16:30:54 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A421A90D3 for ; Mon, 15 Dec 2014 16:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 hOpkV40qFmui for ; Mon, 15 Dec 2014 16:30:52 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260951A90CD for ; Mon, 15 Dec 2014 16:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=630; q=dns/txt; s=iport; t=1418689852; x=1419899452; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=PHwY3WAct8T9uCsXDyUbIcHHi962GR5C188t0vOuSn8=; b=WDjThfKepZgBj5BmbE4jyh4INBj6iQtF1dQPs95e002h2+DmMlcLNjd8 BASK8ljz3G8QeMgB7sLzQAY/M1kmgsV9aBkOTO4UGVS6M0F0kxJOiBVqq ESfCAPEMAW4OGgZSdp3/YlY1diNOxpHTLaEkzY1WbfTi78W+PDu3aTNsA Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQFAGl8j1StJV2d/2dsb2JhbABagwZSWATFUgqFcgKBIhYBAQEBAX2EDQEBBAEBAWsLEAIBCCIkJwslAgQOBQiIJA3UYwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjxARAR8xgx2BEwWJFYRtiXqCXooWgzgigjCBPG6BDDl+AQEB X-IronPort-AV: E=Sophos;i="5.07,583,1413244800"; d="scan'208";a="106006975" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 16 Dec 2014 00:30:51 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sBG0Uolf001565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Dec 2014 00:30:51 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.210]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 18:30:50 -0600 From: "Siva Sivabalan (msiva)" To: "teas@ietf.org" Thread-Topic: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document Thread-Index: AQHQFlJeWNEXLVsItkaiNSBPlr4JxpyRYJ6AgAAAYWCAAAFdsA== Date: Tue, 16 Dec 2014 00:30:49 +0000 Message-ID: References: <548B5DA8.1060700@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.107.243] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/FGkbumJ_96ZdjimOT5dQHQcj7Xk Cc: "lberger@labn.net" Subject: Re: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 00:30:53 -0000 yes/support. Thanks , Siva On 2014-12-12 4:27 PM, "Lou Berger" wrote: >All, > >This is start of a two week poll on making >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a TEAS working group=20 >document. Please send email to the list indicating =B3yes/support=B2 or=20 >=B3no/do not support=B2. If indicating no, please state your technical=20 >reservations with the document. > >The poll ends Friday December 26th. > >Thanks, > >Deborah and Lou > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas From nobody Tue Dec 16 08:24:48 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91671A1B75 for ; Tue, 16 Dec 2014 08:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 F1Hgg5w-ah1A for ; Tue, 16 Dec 2014 08:24:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24BE61A1B5B for ; Tue, 16 Dec 2014 08:24:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMY41977; Tue, 16 Dec 2014 16:24:36 +0000 (GMT) Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 16 Dec 2014 16:24:35 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml701-chm ([10.193.5.50]) with mapi id 14.03.0158.001; Tue, 16 Dec 2014 08:24:25 -0800 From: Leeyoung To: Lou Berger , TEAS WG Thread-Topic: [Teas] TE Topology YANG Model Design Team Thread-Index: AQHQFUN828phWg28AUSMeRwajb3b15ySbI7A Date: Tue, 16 Dec 2014 16:24:24 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C6C0B7@dfweml706-chm> References: <5489970B.7070108@labn.net> In-Reply-To: <5489970B.7070108@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/teas/vC-lhxPPec1-6ppaTzImvH8dtuw Subject: Re: [Teas] TE Topology YANG Model Design Team X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:24:47 -0000 Hi Lou, Just wondering if you consider other individual contributions on TE Topolog= y YANG model other than DT's contribution? Another question is what is the = scope of this DT's YANG model effort? There can be many aspects of TE YANG = model (e.g., integrated multi-layer vs. multiple individual single-layer, e= tc.) If you can define the clear work scope of the DT, that will be great. If th= e WG would not allow other individual contributions, I have some concerns o= n the issue of fairness.=20 Best regards, Young -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Thursday, December 11, 2014 7:07 AM To: TEAS WG Subject: [Teas] TE Topology YANG Model Design Team All, We have formed a WG Design Team whose objective is to deliver a TE Topo= logy YANG Model draft in time for discussion in Dallas. It is our intent = that the document will become a TEAS WG draft post Dallas. The scope of th= e design team is intentionally narrow and the work of the DT will need to b= e coordinated with other related YANG work -- and such coordination is the = focus of next week's interim meeting*. The DT will be closed once we have = a WG document adopted on this topic. While the DT has limited membership (and a limited lifespan), how the DT wo= rks to produce it's individual draft(s) is up to the DT. For example they m= ay choose to publicize their calls/progress or not. We do appreciate that n= ot all who volunteered are include. Those who are willing to provide input= to the DT should contact them directly. Keep in mind that there will be p= lenty of opportunity for input, per normal WG process, once the DT's indivi= dual draft(s) are adopted as WG documents. Again, thank you to all who volu= nteered. * - Next week's interim is of course open to all -- and we have an open cal= l for those who wish a discussion slot. The focus of the interim is on the= scope of the TE Topology YANG model and how it relates/ties-in to other w= ork. The members of the DT are: Vishnu Pavan Beeram Igor Bryskin Oscar Gonzalez De Dios Xufeng Liu Tarek Saad Himanshu Shah Deborah and Lou _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Tue Dec 16 09:28:03 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923D41A6EFC for ; Tue, 16 Dec 2014 09:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 35h02CRnJRuU for ; Tue, 16 Dec 2014 09:27:59 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCBD51A1B98 for ; Tue, 16 Dec 2014 09:27:58 -0800 (PST) Received: from MUC-SRV-MBX2.advaoptical.com ([172.20.1.96]) by muc-vsrv-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id sBGHRuJC029389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Dec 2014 18:27:56 +0100 Received: from MUC-SRV-MBX1.advaoptical.com (172.20.1.95) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 16 Dec 2014 18:27:56 +0100 Received: from MUC-SRV-MBX1.advaoptical.com ([fe80::cddd:2336:31f7:688d]) by MUC-SRV-MBX1.advaoptical.com ([fe80::cddd:2336:31f7:688d%18]) with mapi id 15.00.1044.021; Tue, 16 Dec 2014 18:27:55 +0100 From: =?windows-1257?Q?Pawe=F9_Brzozowski?= To: "teas@ietf.org" Thread-Topic: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document Thread-Index: AQHQFlJf6/QuQXJSn0+NuwIRCVZ49ZyRYJ6AgAAAYWCAAAFdsIABHCMj Date: Tue, 16 Dec 2014 17:27:54 +0000 Message-ID: <1418750891156.48503@advaoptical.com> References: <548B5DA8.1060700@labn.net> , In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.27.50] Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-16_05:2014-12-16,2014-12-16,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/aE90hlPRRFvvH0qOTrpONSO9CxE Cc: "lberger@labn.net" Subject: [Teas] ODP: Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:28:00 -0000 yes/support.=0A= =0A= Thanks ,=0A= Pawel=0A= =0A= =0A= On 2014-12-12 4:27 PM, "Lou Berger" wrote:=0A= =0A= >All,=0A= >=0A= >This is start of a two week poll on making=0A= >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a TEAS working group=0A= >document. Please send email to the list indicating =B3yes/support=B2 or=0A= >=B3no/do not support=B2. If indicating no, please state your technical=0A= >reservations with the document.=0A= >=0A= >The poll ends Friday December 26th.=0A= >=0A= >Thanks,=0A= >=0A= >Deborah and Lou=0A= >=0A= >_______________________________________________=0A= >Teas mailing list=0A= >Teas@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/teas=0A= =0A= _______________________________________________=0A= Teas mailing list=0A= Teas@ietf.org=0A= https://www.ietf.org/mailman/listinfo/teas=0A= From nobody Tue Dec 16 09:50:48 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6051A7026 for ; Tue, 16 Dec 2014 09:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 9PhPbs-HdYDJ for ; Tue, 16 Dec 2014 09:50:45 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 0A7E71A7022 for ; Tue, 16 Dec 2014 09:50:43 -0800 (PST) Received: (qmail 26077 invoked by uid 0); 16 Dec 2014 17:50:43 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 16 Dec 2014 17:50:43 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id UHq21p00x2SSUrH01Hq5Yn; Tue, 16 Dec 2014 10:50:05 -0700 X-Authority-Analysis: v=2.1 cv=OJu0g0qB c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=OUXY8nFuAAAA:8 a=pmb6BNNbAAAA:8 a=OTfaxyS_AAAA:8 a=0FD05c-RAAAA:8 a=AUd_NHdVAAAA:8 a=FmoMKUsJAAAA:8 a=tTFsOIkknbtRjLEsWJYA:9 a=ehbY1JSv7xT0kZDz:21 a=sbawgGQFXAWyYc2w:21 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=QWbkUsHxM/SgKbAAnLKLddnXTbvhrWlzClyDt4BQ6As=; b=ajrfcJd1ANyPLKxJ0mBP/Tk4/FiNb9Eo5qgojuu6oA/7W/TvrCaGqayfGOoRNvsoJfjlTJlgBeuOz190WediOm+CAndLvVgrPUfc6zXb/u8GVWlNNjGQU1v4167xVQa9; Received: from box313.bluehost.com ([69.89.31.113]:42507 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Y0wG0-0002Ux-E9; Tue, 16 Dec 2014 10:50:01 -0700 Message-ID: <549070D0.8010006@labn.net> Date: Tue, 16 Dec 2014 12:50:08 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Leeyoung References: <5489970B.7070108@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C6C0B7@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C6C0B7@dfweml706-chm> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/b70RwOsreigTz8WYcyszIgcXc1Y Cc: TEAS WG Subject: Re: [Teas] TE Topology YANG Model Design Team X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:50:47 -0000 Young, On 12/16/2014 11:24 AM, Leeyoung wrote: > Hi Lou, > > Just wondering if you consider other individual contributions on TE Top= ology YANG model other than DT's contribution? Another question is what i= s the scope of this DT's YANG model effort? There can be many aspects of = TE YANG model (e.g., integrated multi-layer vs. multiple individual singl= e-layer, etc.) There is no restriction on individual work just because there is a design team. In fact, you can even author individual documents when there is a WG topic on a subject. It is for the WG to judge if it is work to be supported. It would be most helpful though to try to work with the DT. Their mission is to develop a draft in time for discussion in Dallas, and they are free to work as they see fit, much like any other individual draft.=20 Once we have a WG draft on the topic, the WG as a whole has control on the content of the draft. The details of their work is a largely up to them. They will be basing their work on published individual work, so I expect it to be aligned with what we can see in those documents. You are welcome to comment on those to the DT and on the list. You (and anyone else) can attend Thursday's virtual Interim as well as request a discussion slot, if you have something to add -- we are particularly interested to hear about what may be missing from the scope perspective. > If you can define the clear work scope of the DT, that will be great.=20 I'm not sure what additional clarity you are looking for. If it's for more details on the content of the TE Topology YANG models, I think we will wait to see what the DT produces and chooses to include/exclude.=20 There's a complexity/progress tradeoff to be made at this point and the choice is theirs. This will be reviewed at the interim, and you should feel free to raise any questions you have during the meeting. > If the WG would not allow other individual contributions, I have some c= oncerns on the issue of fairness.=20 Sure, anyone can submit anything they choose at any point. Such input, as is the output of the DT, always subject to approval, rejection or=20 modification by the WG as a whole. Lou > > Best regards, > Young > > > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Thursday, December 11, 2014 7:07 AM > To: TEAS WG > Subject: [Teas] TE Topology YANG Model Design Team > > > All, > We have formed a WG Design Team whose objective is to deliver a TE = Topology YANG Model draft in time for discussion in Dallas. It is our i= ntent that the document will become a TEAS WG draft post Dallas. The sco= pe of the design team is intentionally narrow and the work of the DT will= need to be coordinated with other related YANG work -- and such coordina= tion is the focus of next week's interim meeting*. The DT will be closed= once we have a WG document adopted on this topic. > > While the DT has limited membership (and a limited lifespan), how the D= T works to produce it's individual draft(s) is up to the DT. For example = they may choose to publicize their calls/progress or not. We do appreciat= e that not all who volunteered are include. Those who are willing to pro= vide input to the DT should contact them directly. Keep in mind that the= re will be plenty of opportunity for input, per normal WG process, once t= he DT's individual draft(s) are adopted as WG documents. Again, thank you= to all who volunteered. > > * - Next week's interim is of course open to all -- and we have an open= call for those who wish a discussion slot. The focus of the interim is = on the scope of the TE Topology YANG model and how it relates/ties-in to= other work. > > The members of the DT are: > Vishnu Pavan Beeram > Igor Bryskin > Oscar Gonzalez De Dios > Xufeng Liu > Tarek Saad > Himanshu Shah > > Deborah and Lou > > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Tue Dec 16 11:40:44 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E321A874A for ; Tue, 16 Dec 2014 11:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 I2OEQqGxXxCa for ; Tue, 16 Dec 2014 11:40:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7E301A1BD2 for ; Tue, 16 Dec 2014 11:40:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQD59488; Tue, 16 Dec 2014 19:40:28 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 16 Dec 2014 19:40:26 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Tue, 16 Dec 2014 11:40:16 -0800 From: Leeyoung To: Lou Berger Thread-Topic: [Teas] TE Topology YANG Model Design Team Thread-Index: AQHQFUN828phWg28AUSMeRwajb3b15ySbI7AgACgfQD//5iUsA== Date: Tue, 16 Dec 2014 19:40:15 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C6C1A7@dfweml706-chm> References: <5489970B.7070108@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C6C0B7@dfweml706-chm> <549070D0.8010006@labn.net> In-Reply-To: <549070D0.8010006@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/teas/mRSv9OK2_2Qnd8FxWKw3Qvs-cNU Cc: TEAS WG Subject: Re: [Teas] TE Topology YANG Model Design Team X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 19:40:43 -0000 Lou, Thanks, this helps.=20 Young -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Tuesday, December 16, 2014 11:50 AM To: Leeyoung Cc: TEAS WG Subject: Re: [Teas] TE Topology YANG Model Design Team Young, On 12/16/2014 11:24 AM, Leeyoung wrote: > Hi Lou, > > Just wondering if you consider other individual contributions on TE=20 > Topology YANG model other than DT's contribution? Another question is=20 > what is the scope of this DT's YANG model effort? There can be many=20 > aspects of TE YANG model (e.g., integrated multi-layer vs. multiple=20 > individual single-layer, etc.) There is no restriction on individual work just because there is a design t= eam. In fact, you can even author individual documents when there is a WG = topic on a subject. It is for the WG to judge if it is work to be supported= . It would be most helpful though to try to work with the DT. Their mission = is to develop a draft in time for discussion in Dallas, and they are free t= o work as they see fit, much like any other individual draft.=20 Once we have a WG draft on the topic, the WG as a whole has control on the= content of the draft. The details of their work is a largely up to them. They will be basing the= ir work on published individual work, so I expect it to be aligned with wha= t we can see in those documents. You are welcome to comment on those to the DT and on the list. You (and an= yone else) can attend Thursday's virtual Interim as well as request a discu= ssion slot, if you have something to add -- we are particularly interested = to hear about what may be missing from the scope perspective. > If you can define the clear work scope of the DT, that will be great.=20 I'm not sure what additional clarity you are looking for. If it's for more= details on the content of the TE Topology YANG models, I think we will wai= t to see what the DT produces and chooses to include/exclude.=20 There's a complexity/progress tradeoff to be made at this point and the cho= ice is theirs. This will be reviewed at the interim, and you should feel free to raise any= questions you have during the meeting. > If the WG would not allow other individual contributions, I have some con= cerns on the issue of fairness.=20 Sure, anyone can submit anything they choose at any point. Such input, as = is the output of the DT, always subject to approval, rejection or modificat= ion by the WG as a whole. Lou > > Best regards, > Young > > > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Thursday, December 11, 2014 7:07 AM > To: TEAS WG > Subject: [Teas] TE Topology YANG Model Design Team > > > All, > We have formed a WG Design Team whose objective is to deliver a TE To= pology YANG Model draft in time for discussion in Dallas. It is our inten= t that the document will become a TEAS WG draft post Dallas. The scope of = the design team is intentionally narrow and the work of the DT will need to= be coordinated with other related YANG work -- and such coordination is th= e focus of next week's interim meeting*. The DT will be closed once we hav= e a WG document adopted on this topic. > > While the DT has limited membership (and a limited lifespan), how the DT = works to produce it's individual draft(s) is up to the DT. For example they= may choose to publicize their calls/progress or not. We do appreciate that= not all who volunteered are include. Those who are willing to provide inp= ut to the DT should contact them directly. Keep in mind that there will be= plenty of opportunity for input, per normal WG process, once the DT's indi= vidual draft(s) are adopted as WG documents. Again, thank you to all who vo= lunteered. > > * - Next week's interim is of course open to all -- and we have an open c= all for those who wish a discussion slot. The focus of the interim is on t= he scope of the TE Topology YANG model and how it relates/ties-in to other= work. > > The members of the DT are: > Vishnu Pavan Beeram > Igor Bryskin > Oscar Gonzalez De Dios > Xufeng Liu > Tarek Saad > Himanshu Shah > > Deborah and Lou > > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Tue Dec 16 12:45:52 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93091A87D7 for ; Tue, 16 Dec 2014 12:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.054 X-Spam-Level: X-Spam-Status: No, score=-98.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, GB_SUMOF=1, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no 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 356rHK4IhGx3 for ; Tue, 16 Dec 2014 12:45:46 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBBB1A87A3 for ; Tue, 16 Dec 2014 12:45:46 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: References: <024901d0196f$d4901120$7db03360$@ndzh.com> In-Reply-To: <024901d0196f$d4901120$7db03360$@ndzh.com> Date: Tue, 16 Dec 2014 15:45:41 -0500 Message-ID: <029701d01971$421b0410$c6510c30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0298_01D01947.5946F7E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDZIfl2DhDYVmSWECl5t11mEQWKVJ6AnmkA Content-Language: en-us X-Authenticated-User: skh@ndzh.com X-IsFriend: Archived-At: http://mailarchive.ietf.org/arch/msg/teas/WwDqShOXbG7h2XaaRwna_ukDfzo Cc: 'Jeffrey Haas' , shares@ndzh.com Subject: [Teas] FW: [i2rs] minutes and slides for the I2RS interim X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 20:45:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0298_01D01947.5946F7E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0299_01D01947.5946F7E0" ------=_NextPart_001_0299_01D01947.5946F7E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The I2RS has held two interims during December to discuss use cases, yang models for RIB and topology, and the I2RS requirements on protocol. These minutes of these meetings are attached. You can find slides and minutes for the December 11th, 2014 meeting at: http://www.ietf.org/proceedings/interim/2014/12/11/i2rs/proceedings.html You can find slides and minutes for the December 11th, 2014 meeting at: http://www.ietf.org/proceedings/interim/2014/12/16/i2rs/proceedings.html Please let us know if you have any questions we can answer regarding the I2RS current status. Sue Hares ------=_NextPart_001_0299_01D01947.5946F7E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The I2RS = has held two interims during December to discuss use cases, yang models = for RIB and topology, and the I2RS requirements on protocol.  These = minutes of these meetings are attached.

 

You can find = slides and minutes for the December 11th, 2014 meeting at: =

http://www.ietf.org/proceedings/interim/2014/12/11/i2rs/proceedi= ngs.html

 

You can find slides and minutes for the December = 11th, 2014 meeting at:

http://www.ietf.org/proceedings/interim/2014/12/16/i2rs/proceedi= ngs.html

 

Please let us know if you have any questions we can = answer regarding the I2RS current status.

 

Sue Hares =  

------=_NextPart_001_0299_01D01947.5946F7E0-- ------=_NextPart_000_0298_01D01947.5946F7E0 Content-Type: text/plain; name="i2rs-interim-minutes-2014-12-16.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="i2rs-interim-minutes-2014-12-16.txt" I2RS interim, December 16, 2014. 10:00-11:40 ET Attendees: Hariharan Ananthakrishnan Alia Atlas Ignas Bagdonas Nitin Bahadur Lou Berger Andy Bierman Deborah Brungard Alexander Clemm Amit Dass Dhruv Dhody Jie Dong=20 Jan Medved Jie Dong Don Fedyk Cary FitzGarald Jeff Haas=20 Joel Halpern Susan Hares=20 Ace Linden Xufeng Liu Jan Medved=20 Dan Romascanu Ju=C3=ABrgen Sch=C3=B6nw=C3=A4lder Himanshu Shah Robert Varga Lixing Wang =20 Michael Wang Kent Watsen Qin (Bill) Wu=20 Agenda Discussion on I2RS RIB Info Drafts [10:00 - 10:30 (zctual)] discussing: = 1) Interaction between RIB Yang Model and draft-ietf-netmod-routing-cfg 2) Nexthop structures proposed in RIB Info Model = [draft-ietf-i2rs-rib-info-model-04]=20 Discussion of I2RS topology drafts [10:30 - 11:15] =20 Overview and PBR {Sue Hares] [10:30 - 10:35] Yang Model for Network Topologies: [Alexander Clemm] [10:35-10:45]=20 draft-clemm-i2rs-yang-network-topo-01.txt draft-clemm-i2rs-yang-l3-topo =20 Yang Model for L2 Topologies [Jie Dong] [10:45 - 10:50] =20 draft-dong-i2rs-yang-l2-network-topology=20 =20 Yang Model for Service Topologies [Qin Wu/Sue Hares] [10:50 - 11:00]=20 = http://datatracker.ietf.org/doc/draft-hares-i2rs-info-model-service-topo/= Discussion on topology drafts [10:35 - 10:45]=20 =09 Protocol Discussion: [11:05 - 11:30] =20 1) Simple protocol option - [Dean Bogdanovic]=20 2) Complex Protocol option - [Sue Hares]=20 3) pub-sub option [Alexander Clemm, Eric Voit]=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I2RS Adoption calls in December-January=20 I2RS will make an adoption call for RIB Yang/IM model after 12/16/2014 = meeting. =20 Topics for 1/8/2015 and 1/23/2015 I2RS interim: =20 1) Protocol Requirements for I2RS=20 2) Topology drafts =20 3) RIB Info drafts.=20 =20 1) Document status:=20 Traceability draft has been adopted. We dovetail our Yang modules with netconf and netmod.=20 =3D=3D=3D=3D 2) Rib Info Yang model - Amit [slides] High level differences.=20 What are unique for i2rs? I2RS is not covering the default rib model, compared to the netmod-cfg = they do. Using capabilities for tunnel encap types. Propose add RPC from agent to client for route changes Q: Juergen - why do we need rpc vs. notification?=20 Lixing: Example from BGP use case. =E2=80=A6 Sue: This is for pub-sub, for retrieving history. From BGP use cases. Jan: Do we need both info and data model now? Sue: Alia says one draft. Alia: That=E2=80=99s up to WG. IM could proceed separately from DM = since we=E2=80=99re not yet rechartered for DM. Jeff: Notification in I2RS. Does it also belong in netmod-cfg? Amit: They should align. Sooner or later, we should come back and = revisit it. Alia: Amit and Lixing, very useful comparison vs. netmod rtg-cfg model. = Thanks for doing it. =20 There=E2=80=99s a recent draft by Eric et al. and motivations for = pub-sub.=20 Does it describe the rib model requirements? Useful for i2rs to discuss = and netconf to review. Sue: See end presentation. Nitin: Lots of questions raised. Is there a design team to resolve this? Sue: Yes. We are taking volunteers for that team. Nitin: Feel free to add me to it. =3D=3D=3D=3D=3D 3) Protocol Independent (Topology) Data Models - Sue [slides] 3.1 Contrast topology dependent vs. independent. PBR - Sits underneath the rib list, above the BNP. Default RIB? PBR needs a default RIB for failover. We are only proposing groups, rules. ------ 3.2 Network topology Models - Alex Clemm [slides] Represents both horizontal and vertical layering Lou B: Will you be in Thursday=E2=80=99s TEAS interim? Alex: Yes. Lou: Will defer. Grappling with issue of control plane topo vs. data = plane topology. L3 IGPs they=E2=80=99re the same. SDN, TE - = they=E2=80=99re not necessarily the same. Sue: PBR is a forwarding data plane focus. Qin will cover service = topology and Jie will cover Layer 2. Many people will join you on = Thursday. ------- 3.3 Yang data model for L2 topology - Jie Dong [slides] Jeff: Your model includes layer 2 physical info (vlan etc.) Does this = belong in our I2RS stuff? Alex=E2=80=99s draft lets you look between = layers. Do we want this level of detail in our model? Jie: Topo use case draft suggests we want to gather the sum of the info = from across the network. What about layer 3/2/1? Agree it needs = discussion. Alex: Reasonable to do this. Fine line between abstraction model vs. = other info, but not specific to topology. Discuss on case by case = basis. If not tied to topology properties, should go to inventory. Jie: Agreed. Sue: As Lou put it we have forwarding layer at l2 and control plane at = l2. Alex, when you speak at abstract, which do you mean? Alex: Both. Even with service. Jeff: If we allow write, then the l2 config details matter. Sue: Need active discussions on mail list. Tie into use case. 3.4 Service Topology Info Model - Qin Wu and Sue Hares=20 [slides] Joel: *Who* knows the info needed to populate this model? Service = topology needs to be more than just tunnels. Sue: Abstract topology to lay on top of network topology. We=E2=80=99re = describing this using UML. Joel: Starting to cover my questions. Let=E2=80=99s keep going. Lou: I think you made an important clarification. You mean TEAS requests = to I2RS. Juergen: Concerned with restconf extensions and netconf extensions being = called out in UML. They should work in both. Sue: Thanks for correction, will fix in next rev. [slides] Sue: Note how this ties back to Alex=E2=80=99s model. Additional = questions? Lou: Document has TE data. This doesn=E2=80=99t get covered in these = slides. Is that still there? Sue: We had removed it. Expect to harmonize with Alex. Lou: Usage of TE is not the normal use of it. Perhaps better term, like = NAT load balancer, etc.=20 TED is different than normal usage of TED. =20 Sue: I think you=E2=80=99re correct. We=E2=80=99ll update it, happy to = take further feedback. Don Fedyk: There is a lot more commonality in models in layer 3 models = and others.=20 They could be harmonize a bit more. Jeff: What is the additional harmonization=20 My point was the Yang Model for L3 (as presented) seemed to outline L3, = Service and Optical and missed L2 totally. (Not saying this is one document but one = architecture as presented). Then the L2 Presentation had some L2 but missed several L2 capabilities. = (VPLS, EVPN, VXLAN, PBB etc.)=20 If you look at this more generically each layer (l3,l2,l1) has:=20 Data path, Tunneling/Multiplexor/Virtual network, Topology, Topology = data base, TE extensions,=20 Control Plane. Each layer can and may use IS-IS or OSPF (and even BGP) = for some address distribution VPN information, connection coordination, TE information, = within the context of an Instance/VPN. Each layer can and may offer a service, p2p, p2mp, = mp2mp,(some type of persistent connection or set of connections that may have their own = resiliency mechanisms) at the layer or up to a higher layer.=20 Layers can be skipped and upper layers may be unaware of lower layers.=20 Lou Berger (from email response): My comment on control plane vs data = plane is very much in line with this comment. And Don has begun some of the discussion I was = hoping to talk a bit more about in Thursday's TEAS interim. (At least the TE aspects, as well = as the possible formal representation of control plane separately from data plane.) =E2=80=94=E2=80=94 Subscribing to datastore push updates - Alex Clemm [slides] XXX - transport and subscription decoupling =E2=80=94 Simple vs. Complex I2RS - Dean Bogdanovich and Sue (via mailing list) [slides] Joel: This was discussed in WG. Defining granularity at which we = conflict=20 should be in model. Not sure what we=E2=80=99re discussing here. Sue: Trying to come to some conclusion about ephemeral database from = ietf-91. Dean Bogdanovic thought there might be a different way to look at it. Joel: I don=E2=80=99t think these things are really primitives. = We=E2=80=99re only interacting with some properties of the interface. Same for route - only changing = some property. Jeff: Example of route, ownership is internal. Joel: Correct myself from route vs. route-table. Route-table handles = that arbitration. Jeff: Russ White basically says just interact with routing table, it is = much simpler. Joel: Have discussed with Russ - who does not believe we have covered = the scope properly. Sue: Agree that things are complex, like next hops, recursive nexthops. = Let us have more of this discussion on the mail list. =20 RFC 6095 may help here, per netconf folk. Don: Distinction is based on ability override something in config vs. = the ownership of that=20 thing. Objects that are simple can be easily made to override some = properties. Ownership is still in config. Only need this relationship if config is involved. Jeff: Had presented this override picture at last ietf. Covered by = option 4 =E2=80=9Cpanes of glass model=E2=80=9D. Sue: need to continue this on mailing list. Put more questions out on = list. Need to pick=20 this up for Jan 8 meeting. We had hoped this discussin would clarify = things, but=20 we need to go a few more rounds. ------=_NextPart_000_0298_01D01947.5946F7E0 Content-Type: text/plain; name="i2rs-interim-minutes-2014-12-11-final-v2.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="i2rs-interim-minutes-2014-12-11-final-v2.txt" I2RS interim meeting December 11, 2014. Chairs Sue Hares, Jeffrey Haas. 10:00-11:00 ET Attendees: Jeff, Sue, Alia Amit Dass Dhruv Dhoty Hariharan Anathakakrishnan Igneous Bagdonas Lixing Wang Juergen Schoenwaelder Alexander Clemm Cary FitzGerald Dean Bogdanovich Don Fedyk Yael Frank Zafar Ali Status =3D=3D=3D=3D=3D=3D=3D RIB model looking for design team members. Currently, Amit and Lixing. Use case summary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dean: The main issue with the protocol selection was does I2rs want to = talk directly to daemons or via configuration? Do we want to focus on managing = primitives such as routes, interfaces, etc. or do we want to manage more complex objects such as = VPNs (l3vpn, l2vpn, etc.) =20 If we can figure out what we want to do, it will make selecting protocol = behaviors a bit easier. Maybe even outside of the IETF since there already exist some solutions. = =20 What do we want to enable through the agent? E.g. Apache Thrift is an = interesting protocol=20 if we are dealing with primitives. Sue: Use cases have both. E.g. virtual topology. Can these be done = with just primitives? =20 One option is we can take a protocol selection that works for just the = primitives, but we know that BGP is something that people want to do and BGP cannot be solved = with just primitives. [slide Virtual topology cases] 25 reqs. that are in-charter. =20 [slide Discussion questions] Is it okay to just use primitives or do we need complex objects? Dean: If we do not want to support bgp vpns, only need primitives. =20 Ignas: One of the important thing is transactions. If we have both, = there is a lot of flexibility. =20 If transactions are not in protocol level but are in client agent = interaction or some other entity,=20 then we have to worry about deterministic issues. Jeff: Speed may require two distinct mechanisms. Ignas: Speed? Possible. Depends on use case. Maybe makes sense. Alia: In architecture, we do not have the idea of transactions. You may = have multiple operations in single exchange with agent. Trying to add transaction = complexity will rat-hole us. The concept of going to two mechanisms if the more complex use cases = sounds much better than trying to push more complexity into the simpler use cases. =20 Jeff: Getting state out of the system is also important. Dean: This might push us into duplicating cases already elsewhere? If = you can already do complex stuff via configuration - e.g. l3vpn - many components, each particular daemon = has work to do.=20 If we can do it using primitives as well, but exposing those interfaces = adds complexity. =20 Know from two vendors that we have different approaches; this would lead = to vendor specific issues. =20 Sue: Your suggestion is we go through config process for everything or = complex? Dean: Primitives should go through daemons - [it is] faster. But then = you limit flexibility. Complex always should go through config; already a solved problem. What = is open? Do we want to have two different ways to do this? Jeff: Simple, complex, issues may have protocol impacts. See discussion = about netconf vs. restconf. Sue: Dean, you know about this in thrift? Dean: Yes, have done some implementation. Sue: We should split this into simple or complex. Next week, let = discuss having the protocol split-up between complex and simple.=20 Dean: I=E2=80=99ve already done that split up, can send to list. Sue: Want to focus on protocol independent items and topology. = Alexander, could you do the analysis on your topology items? Alexander: Ok I can present that. Jeff: IETF session broke things down into interactions with config state = vs. i2rs injected state. This discussion clarified we need to further break this down to simple = vs. complex. Rib Info Models=E2=80=A6 [slides] Nitin and Sriganesh are in Asia and don=E2=80=99t think they can = present. They=E2=80=99ll talk info model next week. RIB yang model [technical issues with Amit and Lixing presenting=E2=80=A6] Jeff: How to do the multiple encaps. Is this a good idea? Amit: Good idea, best idea to date? =20 Jeff: Overlap with rtg-cfg? Amit: Not yet.=20 Hari: I did some of this. Collaborating with Lada. Will work with = Amit. There is some confusion about who is the derived model of whom.=20 Dean: Many discussions about rtg-cfg model. When we started modeling = other protocols such as ospf, we realized we could not do that work yet due to inconsistencies in = rtg-cfg. IMO, should be used as base for all rtg-cfg models. Jeff: Motivation for asking is overlap with regard to complex config vs. = primitives. Hari: Should be complementing? Sue: For next week, figure out how this relates to rtg-cfg. Amit will come back with that information to the next interim.=20 Sue: let=E2=80=99s talk about this on list. Can you drive it Dean, Amit, = Lixing? Alex, for your model? Jeff: Juergen general recursion for 1.1, 2.0? Juergen: 1.1, no. 2.0 no clue. Jeff: Raise on netmod mailing list? Juergen: yes.=20 Jeff: Will raise on netmod. EOF. ------=_NextPart_000_0298_01D01947.5946F7E0-- From nobody Tue Dec 16 13:33:33 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DAE1A877E for ; Tue, 16 Dec 2014 13:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 y-se4zk1BrBI for ; Tue, 16 Dec 2014 13:33:26 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE831A8752 for ; Tue, 16 Dec 2014 13:33:25 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id 425a0945.0.3894185.00-2249.10869726.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 16 Dec 2014 21:33:26 +0000 (UTC) X-MXL-Hash: 5490a5261b7ed072-68539b72756af6d2892478a69dfcfbae6a430a0a Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id sBGLXN6f029586 for ; Tue, 16 Dec 2014 16:33:24 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id sBGLX9fM029405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 16 Dec 2014 16:33:18 -0500 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi407.sfdc.sbc.com (RSA Interceptor) for ; Tue, 16 Dec 2014 21:32:51 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.4]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 16:32:50 -0500 From: "BRUNGARD, DEBORAH A" To: "teas@ietf.org" Thread-Topic: TEAS - Virtual Interim Meeting Agenda Thread-Index: AdAZd8yI/oNhUklVRXOGqhGhzgM2WQ== Date: Tue, 16 Dec 2014 21:32:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.231] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8167214CFMISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=UofUwZMB c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ECdp0B9LA44A:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=A92cGCtB03wA:10 a=NojvYFcnAAAA:8 a=iIdvF12_3G] X-AnalysisOut: [FXJ44igsgA:9 a=CjuIK1q_8ugA:10 a=NU7HZUQD-k8A:10 a=T8E0iRN] X-AnalysisOut: [_syYA:10 a=9uUzcS5Nrb8A:10 a=PUKWmN_3uV-uUXYT:21 a=-t8OOQf] X-AnalysisOut: [z9vkofGYV:21 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=vzWskwO] X-AnalysisOut: [gtE0eCl6x:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/teas/W5L3zHg5Q-ke2DgsHd87zQuwmW8 Subject: [Teas] TEAS - Virtual Interim Meeting Agenda X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 21:33:31 -0000 --_000_F64C10EAA68C8044B33656FA214632C8167214CFMISOUT7MSGUSRDE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda - TEAS Virtual Interim Dec. 18, 2014 20:00 UTC (Target: 2 hour duration) https://ietf.webex.com/ietf/j.php?MTID=3Dm2c971eab8a0059f69b228fbf2549532f Meeting number: 641 996 091 Meeting password: 1234 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 641 996 091 Meeting Objective: Clarify the relationship of a TE Topology YANG model to = other models in development (including models for non-TE topology, TE tunnel/LSP, control plane protoco= ls, specific data planes) - 10 min - Agenda/Intro - 10 min - I2RS Related Activities (Sue) - 10 min - TE RSVP/Tunnel/LSP YANG Discussions (Tarek) - 5 min - TE Topology YANG Model Design Team Introduction (Chairs) - Design Team Led Discussion - Open Discussion The existing set of related drafts includes: draft-liu-yang-abstract-te-topo draft-clemm-i2rs-yang-l3-topo draft-clemm-i2rs-yang-network-topo draft-chen-mpls-te-yang-cfg (LSP focused) draft-gandhi-mpls-te-yang-model (LSP focused) draft-ietf-netmod-routing-cfg (Foundational work, not topology specific) draft-hares-i2rs-info-model-service-topo (Topology only) draft-vergara-flexigrid-yang (Data plane technology specific) draft-dharini-netmod-g-698-2-yang (Data plane technology specific) draft-dong-i2rs-yang-l2-network-topology(Data plane technology specific) --_000_F64C10EAA68C8044B33656FA214632C8167214CFMISOUT7MSGUSRDE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Agenda - TEAS Virtual Interim
Dec. 18, 2014 20:00 UTC (Target: 2 hour duration)
 
 
Meeting number:  641 996 091
Meeting password:       1234
 
Join by phone
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 641 996 091
 
 
Meeting Objective: Clarify the relationship of a TE Topology YANG mode= l to other models in development
(including models for non-TE topology, TE tunnel/LSP, control plane pr= otocols, specific data planes)
 
- 10 min - Agenda/Intro
- 10 min - I2RS Related Activities (Sue)
- 10 min - TE RSVP/Tunnel/LSP YANG Discussions (Tarek)
-  5 min - TE Topology YANG Model Design Team Introduction (Chair= s)
– Design Team Led Discussion
- Open Discussion
 
The existing set of related drafts includes:
draft-liu-yang-abstract-te-topo
draft-clemm-i2rs-yang-l3-topo
draft-clemm-i2rs-yang-network-topo
draft-chen-mpls-te-yang-cfg (LSP focused)
draft-gandhi-mpls-te-yang-model (LSP focused)
draft-ietf-netmod-routing-cfg (Foundational work, not topology specifi= c)
draft-hares-i2rs-info-model-service-topo (Topology only)
draft-vergara-flexigrid-yang (Data plane technology specific)
draft-dharini-netmod-g-698-2-yang (Data plane technology specific)
draft-dong-i2rs-yang-l2-network-topology(Data plane technology specifi= c)
 
 
 --_000_F64C10EAA68C8044B33656FA214632C8167214CFMISOUT7MSGUSRDE_-- From nobody Tue Dec 16 17:10:47 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FA61A1A20 for ; Tue, 16 Dec 2014 17:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 iTAv0rvIOdAk for ; Tue, 16 Dec 2014 17:10:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC0D1A0060 for ; Tue, 16 Dec 2014 17:10:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQD74389; Wed, 17 Dec 2014 01:10:37 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 17 Dec 2014 01:10:36 +0000 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.250]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Wed, 17 Dec 2014 09:10:24 +0800 From: Fatai Zhang To: Lou Berger , Leeyoung Thread-Topic: [Teas] TE Topology YANG Model Design Team Thread-Index: AQHQFUN828phWg28AUSMeRwajb3b15ySbI7A//+URACAAP8+AA== Date: Wed, 17 Dec 2014 01:10:23 +0000 Message-ID: References: <5489970B.7070108@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C6C0B7@dfweml706-chm> <549070D0.8010006@labn.net> In-Reply-To: <549070D0.8010006@labn.net> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/teas/ejqXy1xkLHE_PqhZ_X1ci9RrGfI Cc: TEAS WG Subject: Re: [Teas] TE Topology YANG Model Design Team X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 01:10:42 -0000 Hi Lou, Thanks. Just one more comment for clarification. You said: >It would be most helpful though to try to work with the DT. Their mission= is to develop a draft in time for discussion in Dallas, and they are free = to work as they see fit, much=20 >like any other individual draft. Once we have a WG draft on the topic, the= WG as a whole has control on the content of the draft. [Fatai] Did you mean the DT's mission is to produce a WG draft directly? I = assume that any (normal) drafts should be passed by IETF process, e.g., WG = poll is necessary before an individual draft becomes a WG draft, am I right= ? Best Regards Fatai -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Wednesday, December 17, 2014 1:50 AM To: Leeyoung Cc: TEAS WG Subject: Re: [Teas] TE Topology YANG Model Design Team Young, On 12/16/2014 11:24 AM, Leeyoung wrote: > Hi Lou, > > Just wondering if you consider other individual contributions on TE Topol= ogy YANG model other than DT's contribution? Another question is what is th= e scope of this DT's YANG model effort? There can be many aspects of TE YAN= G model (e.g., integrated multi-layer vs. multiple individual single-layer,= etc.) There is no restriction on individual work just because there is a design team. In fact, you can even author individual documents when there is a WG topic on a subject. It is for the WG to judge if it is work to be supported. It would be most helpful though to try to work with the DT. Their mission is to develop a draft in time for discussion in Dallas, and they are free to work as they see fit, much like any other individual draft.=20 Once we have a WG draft on the topic, the WG as a whole has control on the content of the draft. The details of their work is a largely up to them. They will be basing their work on published individual work, so I expect it to be aligned with what we can see in those documents. You are welcome to comment on those to the DT and on the list. You (and anyone else) can attend Thursday's virtual Interim as well as request a discussion slot, if you have something to add -- we are particularly interested to hear about what may be missing from the scope perspective. > If you can define the clear work scope of the DT, that will be great.=20 I'm not sure what additional clarity you are looking for. If it's for more details on the content of the TE Topology YANG models, I think we will wait to see what the DT produces and chooses to include/exclude.=20 There's a complexity/progress tradeoff to be made at this point and the choice is theirs. This will be reviewed at the interim, and you should feel free to raise any questions you have during the meeting. > If the WG would not allow other individual contributions, I have some con= cerns on the issue of fairness.=20 Sure, anyone can submit anything they choose at any point. Such input, as is the output of the DT, always subject to approval, rejection or=20 modification by the WG as a whole. Lou > > Best regards, > Young > > > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Thursday, December 11, 2014 7:07 AM > To: TEAS WG > Subject: [Teas] TE Topology YANG Model Design Team > > > All, > We have formed a WG Design Team whose objective is to deliver a TE To= pology YANG Model draft in time for discussion in Dallas. It is our inten= t that the document will become a TEAS WG draft post Dallas. The scope of = the design team is intentionally narrow and the work of the DT will need to= be coordinated with other related YANG work -- and such coordination is th= e focus of next week's interim meeting*. The DT will be closed once we hav= e a WG document adopted on this topic. > > While the DT has limited membership (and a limited lifespan), how the DT = works to produce it's individual draft(s) is up to the DT. For example they= may choose to publicize their calls/progress or not. We do appreciate that= not all who volunteered are include. Those who are willing to provide inp= ut to the DT should contact them directly. Keep in mind that there will be= plenty of opportunity for input, per normal WG process, once the DT's indi= vidual draft(s) are adopted as WG documents. Again, thank you to all who vo= lunteered. > > * - Next week's interim is of course open to all -- and we have an open c= all for those who wish a discussion slot. The focus of the interim is on t= he scope of the TE Topology YANG model and how it relates/ties-in to other= work. > > The members of the DT are: > Vishnu Pavan Beeram > Igor Bryskin > Oscar Gonzalez De Dios > Xufeng Liu > Tarek Saad > Himanshu Shah > > Deborah and Lou > > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Tue Dec 16 18:09:47 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C947B1A0203 for ; Tue, 16 Dec 2014 18:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 0W-0WnY7RTMM for ; Tue, 16 Dec 2014 18:09:21 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A261A0235 for ; Tue, 16 Dec 2014 18:09:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6268; q=dns/txt; s=iport; t=1418782162; x=1419991762; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hEC5794HiSbDvDLiMOwCxprVcRdthQClSe5skASKZXM=; b=mIqp5ywIolFBr4ntsuiRoYdOP4U4yO1euS2dDS4Ja2HliX6G5rozrST3 z8TGs8HbPlms/YE68+ZBTG4edepC5jj7Ngkrr25hj2YSEZlDBD/sN2wyP 0JifFq9pCE9fZ02zf2jKMx+BrWH4YH/4HM9ekcP80vYF6xXdpEZJ74W4X s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYFAJ/kkFStJA2F/2dsb2JhbABagwZSWATFdgqFcgKBHhYBAQEBAX2EDAEBAQMBAQEBGh00CwUHBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIiBwIDdRPAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKCoUQJwYrBwaDEIETBY4Hmikig2xugQNCfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,590,1413244800"; d="scan'208";a="106232424" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP; 17 Dec 2014 02:09:19 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sBH29I0L003681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 02:09:18 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.194]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 20:09:18 -0600 From: "Matt Hartley (mhartley)" To: Fatai Zhang , Lou Berger , Leeyoung Thread-Topic: [Teas] TE Topology YANG Model Design Team Thread-Index: AQHQFUN828phWg28AUSMeRwajb3b15ySbI7AgAB+9gCAAHsBgP//q0uw Date: Wed, 17 Dec 2014 02:09:18 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC289BBF54@xmb-rcd-x03.cisco.com> References: <5489970B.7070108@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C6C0B7@dfweml706-chm> <549070D0.8010006@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.243.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/uFUG8GsgpHixc3kPraycIfljAzo Cc: "Matt Hartley \(mhartley\)" , TEAS WG Subject: Re: [Teas] TE Topology YANG Model Design Team X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 02:09:40 -0000 Fatai, My understanding is that the DT will come out with an individual draft to b= e presented in Dallas, but the expectation is that this will probably becom= e a WG draft fairly soon afterwards through the normal process... but the n= ormal process will not be bypassed, so I'd expect the usual IPR and adoptio= n polls. Cheers Matt > Hi Lou, >=20 > Thanks. Just one more comment for clarification. >=20 > You said: > >It would be most helpful though to try to work with the DT. Their > >mission is to develop a draft in time for discussion in Dallas, and they > are free to work as they see fit, much like any other individual draft. > Once we have a WG draft on the topic, the WG as a whole has control on th= e > content of the draft. >=20 > [Fatai] Did you mean the DT's mission is to produce a WG draft directly? = I > assume that any (normal) drafts should be passed by IETF process, e.g., W= G > poll is necessary before an individual draft becomes a WG draft, am I > right? >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Wednesday, December 17, 2014 1:50 AM > To: Leeyoung > Cc: TEAS WG > Subject: Re: [Teas] TE Topology YANG Model Design Team >=20 > Young, >=20 >=20 > On 12/16/2014 11:24 AM, Leeyoung wrote: > > Hi Lou, > > > > Just wondering if you consider other individual contributions on TE > > Topology YANG model other than DT's contribution? Another question is > > what is the scope of this DT's YANG model effort? There can be many > > aspects of TE YANG model (e.g., integrated multi-layer vs. multiple > > individual single-layer, etc.) >=20 > There is no restriction on individual work just because there is a design > team. In fact, you can even author individual documents when there is a > WG topic on a subject. It is for the WG to judge if it is work to be > supported. >=20 > It would be most helpful though to try to work with the DT. Their missio= n > is to develop a draft in time for discussion in Dallas, and they are free > to work as they see fit, much like any other individual draft. > Once we have a WG draft on the topic, the WG as a whole has control on > the content of the draft. >=20 > The details of their work is a largely up to them. They will be basing > their work on published individual work, so I expect it to be aligned wit= h > what we can see in those documents. >=20 > You are welcome to comment on those to the DT and on the list. You (and > anyone else) can attend Thursday's virtual Interim as well as request a > discussion slot, if you have something to add -- we are particularly > interested to hear about what may be missing from the scope perspective. >=20 > > If you can define the clear work scope of the DT, that will be great. > I'm not sure what additional clarity you are looking for. If it's for > more details on the content of the TE Topology YANG models, I think we > will wait to see what the DT produces and chooses to include/exclude. > There's a complexity/progress tradeoff to be made at this point and the > choice is theirs. >=20 > This will be reviewed at the interim, and you should feel free to raise > any questions you have during the meeting. >=20 > > If the WG would not allow other individual contributions, I have some > concerns on the issue of fairness. >=20 > Sure, anyone can submit anything they choose at any point. Such input, a= s > is the output of the DT, always subject to approval, rejection or > modification by the WG as a whole. >=20 > Lou >=20 > > > > Best regards, > > Young > > > > > > -----Original Message----- > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > > Sent: Thursday, December 11, 2014 7:07 AM > > To: TEAS WG > > Subject: [Teas] TE Topology YANG Model Design Team > > > > > > All, > > We have formed a WG Design Team whose objective is to deliver a TE > Topology YANG Model draft in time for discussion in Dallas. It is our > intent that the document will become a TEAS WG draft post Dallas. The > scope of the design team is intentionally narrow and the work of the DT > will need to be coordinated with other related YANG work -- and such > coordination is the focus of next week's interim meeting*. The DT will b= e > closed once we have a WG document adopted on this topic. > > > > While the DT has limited membership (and a limited lifespan), how the D= T > works to produce it's individual draft(s) is up to the DT. For example > they may choose to publicize their calls/progress or not. We do appreciat= e > that not all who volunteered are include. Those who are willing to > provide input to the DT should contact them directly. Keep in mind that > there will be plenty of opportunity for input, per normal WG process, onc= e > the DT's individual draft(s) are adopted as WG documents. Again, thank yo= u > to all who volunteered. > > > > * - Next week's interim is of course open to all -- and we have an open > call for those who wish a discussion slot. The focus of the interim is o= n > the scope of the TE Topology YANG model and how it relates/ties-in to > other work. > > > > The members of the DT are: > > Vishnu Pavan Beeram > > Igor Bryskin > > Oscar Gonzalez De Dios > > Xufeng Liu > > Tarek Saad > > Himanshu Shah > > > > Deborah and Lou > > > > > > > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > >=20 >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Tue Dec 16 18:30:10 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCD61A0072 for ; Tue, 16 Dec 2014 18:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gnEAwkKxcNhJ for ; Tue, 16 Dec 2014 18:30:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100C81A0248 for ; Tue, 16 Dec 2014 18:29:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQD78441; Wed, 17 Dec 2014 02:29:47 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 17 Dec 2014 02:29:46 +0000 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.250]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Wed, 17 Dec 2014 10:29:36 +0800 From: Fatai Zhang To: "Matt Hartley (mhartley)" , Lou Berger , Leeyoung Thread-Topic: [Teas] TE Topology YANG Model Design Team Thread-Index: AQHQFUN828phWg28AUSMeRwajb3b15ySbI7A//+URACAAP8+AP//jDoAgACLVwA= Date: Wed, 17 Dec 2014 02:29:36 +0000 Message-ID: References: <5489970B.7070108@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C6C0B7@dfweml706-chm> <549070D0.8010006@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC289BBF54@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC289BBF54@xmb-rcd-x03.cisco.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/teas/JHYh_DXpWqGTkQHEFOaVI8QSv_0 Cc: TEAS WG Subject: Re: [Teas] TE Topology YANG Model Design Team X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 02:30:08 -0000 Hi Matt, What you said is my understanding, and I think that is fair. Best Regards Fatai -----Original Message----- From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com]=20 Sent: Wednesday, December 17, 2014 10:09 AM To: Fatai Zhang; Lou Berger; Leeyoung Cc: TEAS WG; Matt Hartley (mhartley) Subject: RE: [Teas] TE Topology YANG Model Design Team Fatai, My understanding is that the DT will come out with an individual draft to b= e presented in Dallas, but the expectation is that this will probably becom= e a WG draft fairly soon afterwards through the normal process... but the n= ormal process will not be bypassed, so I'd expect the usual IPR and adoptio= n polls. Cheers Matt > Hi Lou, >=20 > Thanks. Just one more comment for clarification. >=20 > You said: > >It would be most helpful though to try to work with the DT. Their > >mission is to develop a draft in time for discussion in Dallas, and they > are free to work as they see fit, much like any other individual draft. > Once we have a WG draft on the topic, the WG as a whole has control on th= e > content of the draft. >=20 > [Fatai] Did you mean the DT's mission is to produce a WG draft directly? = I > assume that any (normal) drafts should be passed by IETF process, e.g., W= G > poll is necessary before an individual draft becomes a WG draft, am I > right? >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Wednesday, December 17, 2014 1:50 AM > To: Leeyoung > Cc: TEAS WG > Subject: Re: [Teas] TE Topology YANG Model Design Team >=20 > Young, >=20 >=20 > On 12/16/2014 11:24 AM, Leeyoung wrote: > > Hi Lou, > > > > Just wondering if you consider other individual contributions on TE > > Topology YANG model other than DT's contribution? Another question is > > what is the scope of this DT's YANG model effort? There can be many > > aspects of TE YANG model (e.g., integrated multi-layer vs. multiple > > individual single-layer, etc.) >=20 > There is no restriction on individual work just because there is a design > team. In fact, you can even author individual documents when there is a > WG topic on a subject. It is for the WG to judge if it is work to be > supported. >=20 > It would be most helpful though to try to work with the DT. Their missio= n > is to develop a draft in time for discussion in Dallas, and they are free > to work as they see fit, much like any other individual draft. > Once we have a WG draft on the topic, the WG as a whole has control on > the content of the draft. >=20 > The details of their work is a largely up to them. They will be basing > their work on published individual work, so I expect it to be aligned wit= h > what we can see in those documents. >=20 > You are welcome to comment on those to the DT and on the list. You (and > anyone else) can attend Thursday's virtual Interim as well as request a > discussion slot, if you have something to add -- we are particularly > interested to hear about what may be missing from the scope perspective. >=20 > > If you can define the clear work scope of the DT, that will be great. > I'm not sure what additional clarity you are looking for. If it's for > more details on the content of the TE Topology YANG models, I think we > will wait to see what the DT produces and chooses to include/exclude. > There's a complexity/progress tradeoff to be made at this point and the > choice is theirs. >=20 > This will be reviewed at the interim, and you should feel free to raise > any questions you have during the meeting. >=20 > > If the WG would not allow other individual contributions, I have some > concerns on the issue of fairness. >=20 > Sure, anyone can submit anything they choose at any point. Such input, a= s > is the output of the DT, always subject to approval, rejection or > modification by the WG as a whole. >=20 > Lou >=20 > > > > Best regards, > > Young > > > > > > -----Original Message----- > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > > Sent: Thursday, December 11, 2014 7:07 AM > > To: TEAS WG > > Subject: [Teas] TE Topology YANG Model Design Team > > > > > > All, > > We have formed a WG Design Team whose objective is to deliver a TE > Topology YANG Model draft in time for discussion in Dallas. It is our > intent that the document will become a TEAS WG draft post Dallas. The > scope of the design team is intentionally narrow and the work of the DT > will need to be coordinated with other related YANG work -- and such > coordination is the focus of next week's interim meeting*. The DT will b= e > closed once we have a WG document adopted on this topic. > > > > While the DT has limited membership (and a limited lifespan), how the D= T > works to produce it's individual draft(s) is up to the DT. For example > they may choose to publicize their calls/progress or not. We do appreciat= e > that not all who volunteered are include. Those who are willing to > provide input to the DT should contact them directly. Keep in mind that > there will be plenty of opportunity for input, per normal WG process, onc= e > the DT's individual draft(s) are adopted as WG documents. Again, thank yo= u > to all who volunteered. > > > > * - Next week's interim is of course open to all -- and we have an open > call for those who wish a discussion slot. The focus of the interim is o= n > the scope of the TE Topology YANG model and how it relates/ties-in to > other work. > > > > The members of the DT are: > > Vishnu Pavan Beeram > > Igor Bryskin > > Oscar Gonzalez De Dios > > Xufeng Liu > > Tarek Saad > > Himanshu Shah > > > > Deborah and Lou > > > > > > > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > >=20 >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Wed Dec 17 04:42:23 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA60C1A89F6 for ; Wed, 17 Dec 2014 04:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 GBWnm3JEPw57 for ; Wed, 17 Dec 2014 04:42:20 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id E8A581A89F2 for ; Wed, 17 Dec 2014 04:42:19 -0800 (PST) Received: (qmail 24446 invoked by uid 0); 17 Dec 2014 12:42:15 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 17 Dec 2014 12:42:15 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id UciC1p00B2SSUrH01ciFwF; Wed, 17 Dec 2014 05:42:15 -0700 X-Authority-Analysis: v=2.1 cv=OLu0g0qB c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ORHgswgCnHsA:10 a=kj9zAlcOel0A:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=HN7Y1fBPuC0A:10 a=A92cGCtB03wA:10 a=i0EeH86SAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=OUXY8nFuAAAA:8 a=pmb6BNNbAAAA:8 a=OTfaxyS_AAAA:8 a=0FD05c-RAAAA:8 a=FmoMKUsJAAAA:8 a=krc8oroZvk7skJnBAXQA:9 a=dy2D6YipR4HUhF3Q:21 a=6SmXrFKpqHD5SfNd:21 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=u+bUJtGuX3cLPj5fWO9scyATOEenSEX3/hVC+reNo14=; b=wyGZvmEMgmdKtulo7LwwRVLc2N/7ZtadO3Fhcp95n+1TcKNzC6FvIsLiSdOlKSg+XisAqHr8CX4d+0gHlMSzYYrJrvzadKR2i8OCThdlQsr06pvswBIy0mJUaDeBYPYo; Received: from [172.56.3.56] (port=60641 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Y1Dvf-00031J-Sv; Wed, 17 Dec 2014 05:42:12 -0700 From: Lou Berger To: Fatai Zhang , "Matt Hartley (mhartley)" , Leeyoung Date: Wed, 17 Dec 2014 07:42:11 -0500 Message-ID: <14a58450918.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <5489970B.7070108@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C6C0B7@dfweml706-chm> <549070D0.8010006@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC289BBF54@xmb-rcd-x03.cisco.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.0.19 (build: 2100846) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.56.3.56 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/QZPeWcbRqZ7a13dNmzzzuIZS8Rk Cc: TEAS WG Subject: Re: [Teas] TE Topology YANG Model Design Team X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 12:42:22 -0000 Fatai, Matt did a reasonable job reiterating what we said before. Adopting working group drafts based on working group feedback, and after the important step of the ipr poll, is both typical and good practice. And this is the plan for any DT produced drafts. > WG poll is necessary before an individual draft becomes a WG draft, am I right? Actually, while this statement does reflect common practice, it does not reflect a required step from IETF process perspective. From a formal process perspective, all that is required for a document to be a working document is for a chair to approve it as such. There are RFCs on this. Lou On December 16, 2014 9:31:46 PM Fatai Zhang wrote: > Hi Matt, > > What you said is my understanding, and I think that is fair. > > > > > > Best Regards > > Fatai > > > -----Original Message----- > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > Sent: Wednesday, December 17, 2014 10:09 AM > To: Fatai Zhang; Lou Berger; Leeyoung > Cc: TEAS WG; Matt Hartley (mhartley) > Subject: RE: [Teas] TE Topology YANG Model Design Team > > Fatai, > > My understanding is that the DT will come out with an individual draft to > be presented in Dallas, but the expectation is that this will probably > become a WG draft fairly soon afterwards through the normal process... but > the normal process will not be bypassed, so I'd expect the usual IPR and > adoption polls. > > Cheers > > Matt > > > Hi Lou, > > > > Thanks. Just one more comment for clarification. > > > > You said: > > >It would be most helpful though to try to work with the DT. Their > > >mission is to develop a draft in time for discussion in Dallas, and they > > are free to work as they see fit, much like any other individual draft. > > Once we have a WG draft on the topic, the WG as a whole has control on the > > content of the draft. > > > > [Fatai] Did you mean the DT's mission is to produce a WG draft directly? I > > assume that any (normal) drafts should be passed by IETF process, e.g., WG > > poll is necessary before an individual draft becomes a WG draft, am I > > right? > > > > > > > > Best Regards > > > > Fatai > > > > > > -----Original Message----- > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > > Sent: Wednesday, December 17, 2014 1:50 AM > > To: Leeyoung > > Cc: TEAS WG > > Subject: Re: [Teas] TE Topology YANG Model Design Team > > > > Young, > > > > > > On 12/16/2014 11:24 AM, Leeyoung wrote: > > > Hi Lou, > > > > > > Just wondering if you consider other individual contributions on TE > > > Topology YANG model other than DT's contribution? Another question is > > > what is the scope of this DT's YANG model effort? There can be many > > > aspects of TE YANG model (e.g., integrated multi-layer vs. multiple > > > individual single-layer, etc.) > > > > There is no restriction on individual work just because there is a design > > team. In fact, you can even author individual documents when there is a > > WG topic on a subject. It is for the WG to judge if it is work to be > > supported. > > > > It would be most helpful though to try to work with the DT. Their mission > > is to develop a draft in time for discussion in Dallas, and they are free > > to work as they see fit, much like any other individual draft. > > Once we have a WG draft on the topic, the WG as a whole has control on > > the content of the draft. > > > > The details of their work is a largely up to them. They will be basing > > their work on published individual work, so I expect it to be aligned with > > what we can see in those documents. > > > > You are welcome to comment on those to the DT and on the list. You (and > > anyone else) can attend Thursday's virtual Interim as well as request a > > discussion slot, if you have something to add -- we are particularly > > interested to hear about what may be missing from the scope perspective. > > > > > If you can define the clear work scope of the DT, that will be great. > > I'm not sure what additional clarity you are looking for. If it's for > > more details on the content of the TE Topology YANG models, I think we > > will wait to see what the DT produces and chooses to include/exclude. > > There's a complexity/progress tradeoff to be made at this point and the > > choice is theirs. > > > > This will be reviewed at the interim, and you should feel free to raise > > any questions you have during the meeting. > > > > > If the WG would not allow other individual contributions, I have some > > concerns on the issue of fairness. > > > > Sure, anyone can submit anything they choose at any point. Such input, as > > is the output of the DT, always subject to approval, rejection or > > modification by the WG as a whole. > > > > Lou > > > > > > > > Best regards, > > > Young > > > > > > > > > -----Original Message----- > > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > > > Sent: Thursday, December 11, 2014 7:07 AM > > > To: TEAS WG > > > Subject: [Teas] TE Topology YANG Model Design Team > > > > > > > > > All, > > > We have formed a WG Design Team whose objective is to deliver a TE > > Topology YANG Model draft in time for discussion in Dallas. It is our > > intent that the document will become a TEAS WG draft post Dallas. The > > scope of the design team is intentionally narrow and the work of the DT > > will need to be coordinated with other related YANG work -- and such > > coordination is the focus of next week's interim meeting*. The DT will be > > closed once we have a WG document adopted on this topic. > > > > > > While the DT has limited membership (and a limited lifespan), how the DT > > works to produce it's individual draft(s) is up to the DT. For example > > they may choose to publicize their calls/progress or not. We do appreciate > > that not all who volunteered are include. Those who are willing to > > provide input to the DT should contact them directly. Keep in mind that > > there will be plenty of opportunity for input, per normal WG process, once > > the DT's individual draft(s) are adopted as WG documents. Again, thank you > > to all who volunteered. > > > > > > * - Next week's interim is of course open to all -- and we have an open > > call for those who wish a discussion slot. The focus of the interim is on > > the scope of the TE Topology YANG model and how it relates/ties-in to > > other work. > > > > > > The members of the DT are: > > > Vishnu Pavan Beeram > > > Igor Bryskin > > > Oscar Gonzalez De Dios > > > Xufeng Liu > > > Tarek Saad > > > Himanshu Shah > > > > > > Deborah and Lou > > > > > > > > > > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org > > > https://www.ietf.org/mailman/listinfo/teas > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org > > > https://www.ietf.org/mailman/listinfo/teas > > > > > > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > From nobody Wed Dec 17 08:03:00 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872451A1A30; Mon, 15 Dec 2014 00:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 aQHYxmM-8u3J; Mon, 15 Dec 2014 00:31:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BD91A0179; Mon, 15 Dec 2014 00:31:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQB11253; Mon, 15 Dec 2014 08:31:49 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 15 Dec 2014 08:31:49 +0000 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.250]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Mon, 15 Dec 2014 16:31:44 +0800 From: Fatai Zhang To: "ietf@ietf.org" , IETF Announcement List Thread-Topic: [CCAMP] TEAS WG Virtual Interim Meeting: December 18, starting at 20:00 UTC (formerly CCAMP WG Virtual Interim) Thread-Index: AQHQEKVahuroNE+EZ0ewfidwVwQyrpyQYKfA Date: Mon, 15 Dec 2014 08:31:43 +0000 Message-ID: References: <20141205160224.15830.11974.idtracker@ietfa.amsl.com> In-Reply-To: <20141205160224.15830.11974.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/teas/l_YIWYropm-b6LpX0ONUTiuxhQ0 X-Mailman-Approved-At: Wed, 17 Dec 2014 08:02:58 -0800 Cc: "ccamp@ietf.org" , "teas@ietf.org" Subject: Re: [Teas] [CCAMP] TEAS WG Virtual Interim Meeting: December 18, starting at 20:00 UTC (formerly CCAMP WG Virtual Interim) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 08:31:53 -0000 Hi Lou and Deborah, I assume that this interim meeting is open for the whole TEAS WG, but I thi= nk the time is not so comfortable for the Asian, who might be interested, := -) Best Regards Fatai -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Saturday, December 06, 2014 12:02 AM To: IETF Announcement List Cc: ccamp@ietf.org; teas@ietf.org Subject: [CCAMP] TEAS WG Virtual Interim Meeting: December 18, starting at = 20:00 UTC (formerly CCAMP WG Virtual Interim) The previously announced TE Topology Yang Model Virtual Interim will be held as announced, but will be hosted by the new TEAS WG rather than the CCAMP WG. The original announcement is below. On Dec 3, 2014, at 12:26 PM, IESG Secretary wrote: > TE Topology Yang Model Virtual Interim (CCAMP) >=20 > There is a cluster of work around YANG models for topology and the TED > (TE Topology Database). The Routing ADs are planning to have the TEAS > working group formalized soon and the group is expected to have an > explicit deliverable of a YANG model for the TED. We, the current=20 > CCAMP chairs, have been asked to get this effort moving by arranging a=20 > virtual interim meeting on the topic. >=20 > The primary objectives of the meeting are to (a) get some basic > agreement on TE topology model 'use cases' (e.g., driven by I2RS, PCE, > ALTO, TEAS), (b) establish the dependencies/relationships of a TE > topology model to other models (e.g., router, topology, routing > protocols, ...) and finally, (c) to provide the needed foundation for=20 > a TEAS design team to be formed and deliver a TE Topology Yang Model=20 > draft by Dallas. >=20 > A related activity has also started in the MPLS WG on a TE LSP Yang > Model. This topic will *not* be the focus of this interim and we=20 > expect that work to continue concurrently. >=20 > The Virtual interim is scheduled for 2-3 hours on December 18,=20 > starting at 20:00 UTC. >=20 > The agenda and other logistic information for the meeting will be=20 > posted & discussed on the CCAMP and new TEAS mailing list=20 > (ccamp@ietf.org and teas@ietf.org). >=20 > The existing set of related drafts includes: > draft-liu-yang-abstract-te-topo > draft-clemm-i2rs-yang-l3-topo > draft-clemm-i2rs-yang-network-topo > draft-amante-i2rs-topology-use-cases > draft-chen-mpls-te-yang-cfg (LSP focused) > draft-gandhi-mpls-te-yang-model (LSP focused) > draft-ietf-netmod-routing-cfg (Foundational work, not topology=20 > specific) >=20 > Deborah and Lou >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From nobody Wed Dec 17 08:03:53 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306331A802D for ; Mon, 15 Dec 2014 08:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 RwOCma9sPdYM for ; Mon, 15 Dec 2014 08:03:34 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEAC61A7D84 for ; Mon, 15 Dec 2014 08:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2330; q=dns/txt; s=iport; t=1418659369; x=1419868969; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=r1pq8OQMFiJusFcg2Y0UWQM7d8t5pGeFklqMccDn5w8=; b=VbkCLEhi/54PR7Z/OnYVDSGlVr2GCAOvkn53M16cmYurCmGdtqDqABYc gfeNArSLToO1jYh2vgn9MnBzwqNPD6b8PvSg+7Tji8NE7ol44HR7NuOCO WaOQnyUyWaVbrwAtIDAGjPQw6oGyFZMO1JaSgeNw8ekP4zO+mA6Lbboty U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUFAMsFj1StJV2P/2dsb2JhbABagwZSWATFTwEJhXICgR0WAQEBAQF9hA0BAQQBAQFrCxACAQgEAToHJwsUEQIEAQ0FiCwN01QBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI8QEQFQB4MWgRMFiRWEbYhvgQuCXooWgzgigjCBPG6BDDl+AQEB X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208,217";a="109750420" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by mtv-iport-1.cisco.com with ESMTP; 15 Dec 2014 16:02:49 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sBFG2mLl015362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Dec 2014 16:02:49 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.81]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 10:02:48 -0600 From: "Mike Taillon (mtaillon)" To: TEAS WG , Lou Berger Thread-Topic: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document Thread-Index: AQHQFlJeWNEXLVsItkaiNSBPlr4JxpyMrbaAgASLYQA= Date: Mon, 15 Dec 2014 16:02:47 +0000 Message-ID: <0F2C9154-B417-438E-A6A4-BAFFDB16E35A@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.41] Content-Type: multipart/alternative; boundary="_000_0F2C9154B417438EA6A4BAFFDB16E35Aciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/FphbaklQByy24YR_vXrzYvK36WY X-Mailman-Approved-At: Wed, 17 Dec 2014 08:03:50 -0800 Cc: "manav@ionosnetworks.com" , "frederic.jounay@orange.ch" , "lizho.jin@gmail.com" , "Rakesh Gandhi \(rgandhi\)" , "Tarek Saad \(tsaad\)" , "Zafar Ali \(zali\)" Subject: Re: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 16:03:36 -0000 --_000_0F2C9154B417438EA6A4BAFFDB16E35Aciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes/support (as a co-author) -mike On 2014-12-12 4:27 PM, "Lou Berger" > wrote: All, This is start of a two week poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a TEAS working group document. Please send email to the list indicating =B3yes/support=B2 or =B3no/do not support=B2. If indicating no, please state your technical reservations with the document. The poll ends Friday December 26th. Thanks, Deborah and Lou _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --_000_0F2C9154B417438EA6A4BAFFDB16E35Aciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <12A0AF23DC464A49AB91265850DF5083@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Yes/support  (as a co-author)

-mike

On 2014-12-12 4:27 PM, "Lou Berger" <lberger@labn.net> wrote:
All,

This is start of a two week poll on making
draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a TEAS working group
document. Please send email to the list indicating =B3yes/support=B2 or
=B3no/do not support=B2. If indicating no, please state your technical
reservations with the document.

The poll ends Friday December 26th.

Thanks,

Deborah and Lou

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas

--_000_0F2C9154B417438EA6A4BAFFDB16E35Aciscocom_-- From nobody Wed Dec 17 08:03:55 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D641A90CC for ; Mon, 15 Dec 2014 16:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 q5kYtmib-38l for ; Mon, 15 Dec 2014 16:27:36 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9C11A90C4 for ; Mon, 15 Dec 2014 16:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=628; q=dns/txt; s=iport; t=1418689656; x=1419899256; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yoxju42RnZl34qtcnwSZjW0SzF/rKRWCp1o3Phsmk3s=; b=K+n5O+JHWnF/8X1zQJOIF+QDgy3khJiRX5kAxxG22+tOXFKEB3fs5XCJ YHa0K8/0KYeayoN3UG9hbwaK5BDZXxXG0bDKSw3AjVXJc25sdiHwjqS66 G07t3TInlO83UpSlQMlCW1HtdrxDSdKsSu7SfCxKTyrfzIHZoCn6n5sTY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQFACN8j1StJA2J/2dsb2JhbABagwZSWATFUgqFcgKBIhYBAQEBAX2EDQEBBAEBAWsLEAIBCCIkJwslAgQOBQiIJA3UZAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjxARAR8xB4MWgRMFiRWEbYl6gl6KFoM4IoIwgTxugQw5fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,583,1413244800"; d="scan'208";a="377418107" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-9.cisco.com with ESMTP; 16 Dec 2014 00:27:36 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sBG0RZVX000722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Dec 2014 00:27:35 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.210]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 18:27:35 -0600 From: "Siva Sivabalan (msiva)" To: "teas@ietf.org" Thread-Topic: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document Thread-Index: AQHQFlJeWNEXLVsItkaiNSBPlr4JxpyRYJ6AgAAAYWA= Date: Tue, 16 Dec 2014 00:27:35 +0000 Message-ID: References: <548B5DA8.1060700@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.107.243] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/s1n0S2mWjv_tpCltRT51rxPQP7g X-Mailman-Approved-At: Wed, 17 Dec 2014 08:03:51 -0800 Cc: "lberger@labn.net" Subject: Re: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 00:27:39 -0000 yes/support. Thanks , Siva On 2014-12-12 4:27 PM, "Lou Berger" wrote: >All, > >This is start of a two week poll on making >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a TEAS working group=20 >document. Please send email to the list indicating =B3yes/support=B2 or=20 >=B3no/do not support=B2. If indicating no, please state your technical=20 >reservations with the document. > >The poll ends Friday December 26th. > >Thanks, > >Deborah and Lou > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas From nobody Thu Dec 18 08:09:50 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBA91A8AD3 for ; Thu, 18 Dec 2014 08:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no 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 0SRCEIPIe5L9 for ; Thu, 18 Dec 2014 08:09:31 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id DA01D1A1B39 for ; Thu, 18 Dec 2014 08:09:30 -0800 (PST) Received: (qmail 22245 invoked by uid 0); 18 Dec 2014 16:09:30 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 18 Dec 2014 16:09:30 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id V49Q1p00m2SSUrH0149Tuv; Thu, 18 Dec 2014 09:09:30 -0700 X-Authority-Analysis: v=2.1 cv=IqONLtPg c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=NojvYFcnAAAA:8 a=74KYpssIr6rZxW40ZuoA:9 a=wSviYPG5bvzypXOL:21 a=TpVEjrJG_qHd5UCh:21 a=pILNOxqGKmIA:10 a=NU7HZUQD-k8A:10 a=T8E0iRN_syYA:10 a=M0c-BsepF_cA:10 a=9uUzcS5Nrb8A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=i9b9GZAb4TKpyn83CowKz1LoFWikAPu3HQaBD0CegdY=; b=DnLYhDGh2gyoiYPWSZp9CByRQKCvEgh+0Lm9LhisOUVJRQFufNYi/l0N4wB+B4qoeqxvPFz1p8N2Y+U4Wec8ki2KZzl2u1b+9Fw6ZLnAvT6A3OV5PClkP4Nk3dTNQsJ6; Received: from box313.bluehost.com ([69.89.31.113]:59626 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Y1ddj-0002So-UW; Thu, 18 Dec 2014 09:09:24 -0700 Message-ID: <5492FC44.6020607@labn.net> Date: Thu, 18 Dec 2014 11:09:40 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A" , "teas@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/6UQ8No9_i9bnvWgizKyyWG7uzTM Subject: Re: [Teas] TEAS - Virtual Interim Meeting Agenda X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 16:09:46 -0000 Just a reminder that this is scheduled for later today. Material is posted (although I expect one set to be updated before the meeting): http://www.ietf.org/proceedings/interim/2014/12/18/teas/proceedings.html Etherpad for the meeting is at: http://etherpad.tools.ietf.org:9000/p/notes-ietf-92-teas Lou (and Deborah) On 12/16/2014 4:32 PM, BRUNGARD, DEBORAH A wrote: > Agenda - TEAS Virtual Interim > Dec. 18, 2014 20:00 UTC (Target: 2 hour duration) > _https://ietf.webex.com/ietf/j.php?MTID=3Dm2c971eab8a0059f69b228fbf2549= 532f_ > Meeting number: 641 996 091 > Meeting password: 1234 > Join by phone > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 641 996 091 > Meeting Objective: Clarify the relationship of a TE Topology YANG > model to other models in development > (including models for non-TE topology, TE tunnel/LSP, control plane > protocols, specific data planes) > - 10 min - Agenda/Intro > - 10 min - I2RS Related Activities (Sue) > - 10 min - TE RSVP/Tunnel/LSP YANG Discussions (Tarek) > - 5 min - TE Topology YANG Model Design Team Introduction (Chairs) > =96 Design Team Led Discussion > - Open Discussion > The existing set of related drafts includes: > draft-liu-yang-abstract-te-topo > draft-clemm-i2rs-yang-l3-topo > draft-clemm-i2rs-yang-network-topo > draft-chen-mpls-te-yang-cfg (LSP focused) > draft-gandhi-mpls-te-yang-model (LSP focused) > draft-ietf-netmod-routing-cfg (Foundational work, not topology specific= ) > draft-hares-i2rs-info-model-service-topo (Topology only) > draft-vergara-flexigrid-yang (Data plane technology specific) > draft-dharini-netmod-g-698-2-yang (Data plane technology specific) > draft-dong-i2rs-yang-l2-network-topology(Data plane technology specific= ) > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Thu Dec 18 11:46:03 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621B01A6F17 for ; Thu, 18 Dec 2014 11:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no 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 SGy1Bq_VSCPZ for ; Thu, 18 Dec 2014 11:46:00 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 2BCEB1A1B16 for ; Thu, 18 Dec 2014 11:46:00 -0800 (PST) Received: (qmail 1340 invoked by uid 0); 18 Dec 2014 19:45:55 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy5.mail.unifiedlayer.com with SMTP; 18 Dec 2014 19:45:55 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id V7lq1p00g2SSUrH017ltSA; Thu, 18 Dec 2014 12:45:55 -0700 X-Authority-Analysis: v=2.1 cv=EL+VjTpC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=NojvYFcnAAAA:8 a=48vgC7mUAAAA:8 a=B1k6CEwHIn21VN64-C4A:9 a=qGRRlgYpBMSzs-gR:21 a=MioX7TMuo45C3PUg:21 a=pILNOxqGKmIA:10 a=NU7HZUQD-k8A:10 a=T8E0iRN_syYA:10 a=M0c-BsepF_cA:10 a=9uUzcS5Nrb8A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=6wef0z+lFe+Z4ZBVrHL9NygaXdaQDgvDzRVvNLTCHtM=; b=mAfzTrCOOisOoGa6woUX3fH30LHluQx6BbnLKrZBLs3xlo2/ujI2sujEXfiyAeHyx3mTKrWqcAbxZ3drAy+Sq7rol2sqP7+M7PLZUNqu9qMv/POk0EbgLQmDWgmC7x39; Received: from box313.bluehost.com ([69.89.31.113]:38087 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Y1h1C-0004ol-9L for teas@ietf.org; Thu, 18 Dec 2014 12:45:50 -0700 Message-ID: <54932F00.6040405@labn.net> Date: Thu, 18 Dec 2014 14:46:08 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "teas@ietf.org" References: <5492FC44.6020607@labn.net> In-Reply-To: <5492FC44.6020607@labn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/zOWa705P15BoDK-ZYKlMTFCgWVk Subject: Re: [Teas] TEAS - Virtual Interim Meeting Agenda X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:46:01 -0000 FYI - Looks like Jabber isn't yet active for teas. Please use etherpad or webex chat during the meeting. Webex: https://ietf.webex.com/ietf/j.php?MTID=3Dm2c971eab8a0059f69b228fbf2549532= f Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-92-teas Lou On 12/18/2014 11:09 AM, Lou Berger wrote: > Just a reminder that this is scheduled for later today. > > Material is posted (although I expect one set to be updated before the > meeting): > http://www.ietf.org/proceedings/interim/2014/12/18/teas/proceedings.htm= l > > Etherpad for the meeting is at: > http://etherpad.tools.ietf.org:9000/p/notes-ietf-92-teas > > Lou (and Deborah) > > On 12/16/2014 4:32 PM, BRUNGARD, DEBORAH A wrote: >> Agenda - TEAS Virtual Interim >> Dec. 18, 2014 20:00 UTC (Target: 2 hour duration) >> _https://ietf.webex.com/ietf/j.php?MTID=3Dm2c971eab8a0059f69b228fbf254= 9532f_ >> Meeting number: 641 996 091 >> Meeting password: 1234 >> Join by phone >> 1-877-668-4493 Call-in toll free number (US/Canada) >> 1-650-479-3208 Call-in toll number (US/Canada) >> Access code: 641 996 091 >> Meeting Objective: Clarify the relationship of a TE Topology YANG >> model to other models in development >> (including models for non-TE topology, TE tunnel/LSP, control plane >> protocols, specific data planes) >> - 10 min - Agenda/Intro >> - 10 min - I2RS Related Activities (Sue) >> - 10 min - TE RSVP/Tunnel/LSP YANG Discussions (Tarek) >> - 5 min - TE Topology YANG Model Design Team Introduction (Chairs) >> =96 Design Team Led Discussion >> - Open Discussion >> The existing set of related drafts includes: >> draft-liu-yang-abstract-te-topo >> draft-clemm-i2rs-yang-l3-topo >> draft-clemm-i2rs-yang-network-topo >> draft-chen-mpls-te-yang-cfg (LSP focused) >> draft-gandhi-mpls-te-yang-model (LSP focused) >> draft-ietf-netmod-routing-cfg (Foundational work, not topology specifi= c) >> draft-hares-i2rs-info-model-service-topo (Topology only) >> draft-vergara-flexigrid-yang (Data plane technology specific) >> draft-dharini-netmod-g-698-2-yang (Data plane technology specific) >> draft-dong-i2rs-yang-l2-network-topology(Data plane technology specifi= c) >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Thu Dec 18 14:14:21 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA08E1A907F for ; Thu, 18 Dec 2014 14:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham 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 a2JYQXfEKFu7 for ; Thu, 18 Dec 2014 14:14:17 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF0B1A8AAB for ; Thu, 18 Dec 2014 14:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13977; q=dns/txt; s=iport; t=1418940857; x=1420150457; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=H/Nhh/t8mNZOsWIbpqLeDZ8FM4eqDIXOWvkKZkwL1NM=; b=Iv8jUGjZgeSATU/DCuAsgbdF/l8eWYHd7CjVpi3OQDUgwJjLQor5PtnD cKbgpD34vJ0I4WJ2gSWbF8y4awUh9CIxj04bnw37h1KDdz3S0pk23Klmj bz29V/LjAAWTYhJIEAdOT16+UtxUXROFt58zQ6+gWYcTF3lpjXFUwSpPJ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAAJRk1StJV2b/2dsb2JhbABbgwZSWATGH4VyAoEmFgEBAQEBfYQOAQQ6PxIBKhRCJgEEDg2IJA3PRAEBAQEBAQEBAQEBAQEBAQEBARYEj0Exgx2BEwWOCoM+hj+CYYocgzgig2xvgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,603,1413244800"; d="scan'208";a="106734644" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 18 Dec 2014 22:14:15 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sBIMEFVE024638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Dec 2014 22:14:15 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.194]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 16:14:15 -0600 From: "Matt Hartley (mhartley)" To: "TEAS WG (teas@ietf.org)" Thread-Topic: Interim meeting raw mintes Thread-Index: AdAbDzm9CVyzMFO3TBK+IResU0facA== Date: Thu, 18 Dec 2014 22:14:14 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC289BFEA8@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.243.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/EXtxH4VWHtqX78TFEbhOXQeUE64 Cc: "Matt Hartley \(mhartley\)" Subject: [Teas] Interim meeting raw mintes X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 22:14:21 -0000 All, Raw minutes from the interim meeting that's just finished are below. If any= one wants to change anything, the etherpad is at http://etherpad.tools.ietf= .org:9000/p/notes-ietf-92-teas - please go in and do it! Cheers Matt =20 Attendance copied from Webex during the meeting... Adrian Farrel Lou Berger Aihua Guo Alia Atlas Cyril Margaria Daniel King Deborah Brungard Don Fedyk Fred Gruman George Swallow Ignas Bogdanas Igor Bryskin Jonathan Sadler Kam Lam (Young?) Lee Lyndon (Ong?) Matt Hartley Matthew Bocci M Waldman Oscar Gonzalez de Dios Pawel Brzozowski Rakesh Gandhi Scott Mansfield Susan Hares Tarek Saad Victor Lopez Vishnu Pavan Beeram Xufeng Liu Yuji Tochio Zafar Ali > - 10 min - Agenda/Intro (Lou) Welcome, ususal IETF note well Meeting is being recorded Scope: mostly about TE topology yang model Everyone should please look at draft-ietf-netmod-routing-cfg, as Adrian kee= ps pointing out Tarek has been coordinating TE yang model work in MPLS, which will transiti= on to TEAS In general, generic stuff will be in TEAS and dataplane-specific things wil= l be in CCAMP L2 network topologies are in I2RS, not TE focussed yet > - 10 min - I2RS Related Activities (Sue) Protocol-Independent Data Models and RIB are part of I2RS' charter Lou: question going forward: how does TE fit in? And where do things like T= E-specific OSPF stuff go? Sue: IGP chairs are in agreement that TE stuff specifically discussed in OS= PF/ISIS docs are part of the OSPF/ISIS WGs. Same goes for BGP. Lou: Yang aspects of BGP-LS are still in BGP? Sue: yes. Some operators have suggested a yang model. Igor: you mentioned TE-OSPF and TE-ISIS, but what does that mean? Once info= rmation is in the TED it doesn't matter how it got there. Do you see any di= fference between OSPF and ISIS? Sue (very firmly as an individual :) there's a difference in the handling o= f information in the IGP, but not once it gets to TE Igor: OK, so there's no such thing as OSPF-TE and ISIS-TE yang models?=20 Sue: there is a difference; if you're tracking information in OSPF or ISIS = that relates to TE then that's part of OSPF/ISIS Lou: something like an opaque LSA would end up in the TED, but other things= might not. Zafar: TE topology is independent of OSPF or ISIS topology Sue: yes. Abstract topologies have a link back to the TE topology Zafar: so what's the definition of an abstract topology here? Sue: The slide reflects the current level of discussion, which proposes an = abstract topology. Alex Clemm is pushing for a topology where the highest l= evel is abstact, and then things buildon top of that. This is being discuss= ed in I2RS Kam: As to the Protocol Independent, you are talking about that for topolog= y Independent, but it is not Management Protocol Independent.=20 Sue: I2RS is focusing on topologies that aren't linked to a protocol. If to= pology is attached to a protocol it needs to link to that protocol's config Kam: but next slide talks about protocol-dependent IM, so what's up with th= at? The term "protocol" is overloaded Sue: yes, I'm giving you I2RS' current definition of it. Important as I2RS = is focussing on RIB and protocol-independent stuff first Igor: should we look at topologies from user perspective, ie who's using th= em and why? e.g. Which protocol was used to build the TED is unimportant (u= nles there's some conflict) Sue: agree, but there's work to be done in I2RS on this too. There's a bit = of a grey line here. Sue: Zafar: slide 7: we have a draft for the network topology, is that the same = as the abstract topology? Sue: no, they're different. Things are a bit mixed up at the moment and I t= hink you need to have a clean definition; Clemm tends not to. This is still= in discussion. Lou: I'd expect TE stuff to be addressed by the DT, and then we'll have to = integrate with other models above this. Zafar: I'd like to know more about how the WG can participate. Lou: we'll get to this in a bit. Sue: I2RS will carry on examining protocol-independent modules as we need t= o know if netconf/restconf will need changes. > - 10 min - TE RSVP/Tunnel/LSP YANG Discussions (Tarek) Tarek: Design team has been meeting weekly Multiple drafts presented in Homolulu, need coordinating so DT was formed (= draft co-authors + other intersted people) Meetings have been announced on MPLS WG mailer, will also be on TEAS going = forward Zafar: where does generic RSVP work go? Lou: I don't think there is one but we'll need to discuss the division of w= ork as this stuff goes to TEAS. We should have a placeholder yang model for= RSVP that the TE-specific stuff can hang off. We also need to worry about = how GMPLS fits in and how we coordinate the generic work in TEAS and the da= taplane-specific stuff in CCAMP. Tarek: so you think GMPLS should bind into TE? Lou: as we move to TEAS we should have a TE model that covers both MPLS-TE = and GMPLS Igor: agree. igor: new question. So there will be groupings common to RSVP and TE? e.g E= RO, node, link... so how do we reconcile these common definitions? Can we c= reate as many reusable libraries as we need that can be imported wherever n= eeded? Tarek: we plan tohave a module with all this stuff igor: I'd rather see it in smaller chunks Tarek: OK, DT will take feedback on board Tarek: Lou: what does generic mean? RSVP-TE vs SR? Tarek: agnostic of RSVP-TE or SR. Lou: I understand it to also mean generic across dataplanes, not just contr= ol planes. We'll need to be careful about terminology here. Tarek: Igor: what's a path-template? Tarek: LSP template applies to all LSPs, path-template applies to all paths= that are defined, e.g. to set all hops strict or loose or something Rakesh: so if you want to have many LSPs take the same path you can do this= . Igor: so where does the definition go and how does it get shared? Tarek: in te-base, at the moment. Igor: so we should define atomic libraries for little things so that the en= tire model doesn't have to be imported Lou: so maybe we should have a te-types for this Tarek: Igor: so where would SRLGs go? In types? Tarek: yes Tarek: Zafar: dataplane should be separate. Tarek: yes. Lou: having discussions both on-list and in DT calls makes sense. What's th= e schedule for the next few calls? Tarek: one today, then resume in January Lou: instead of ietf-mpls-te, call it... so that te can augment th= e rsvp model > - 5 min - TE Topology YANG Model Design Team Introduction (Chairs) Deborah Zafar: work requires a lot of interaction and collaboration. not good if WG= members who want to contribute aren't there. Weekly calls are good. Can we= do this for the TED design team? Deborah: this is up to the DT in the short term... but in the longer term t= his will be a normal WG document, or the DT's work could be rejected if the= WG doesn't like it. Lou: bear in mind this is also only until Dallas, and we'll poll the WG on = what's been produced. There will be plenty of time for everyone to contribu= te both before and after we have a WG doc. Zafar: why can't you do wwhat the TE DT is doing? Igor: premature to open discussion to too many people; will make no progres= s at all. DT was selected to have repesentation from a variety of vendors a= nd operators Lou: DT members really just came from different drafts. You can work with c= olleagues at your company or collaborators on draft you already have. Deborah: bear in mind also that TEAS has only just started so we have no ba= seline. many folks are interested in this and we needed to get a core group= together. This is a temproary arrangement, not a new way of doing things. Kam: topology should be independent of management protocol in use (netconf,= etc). There's a draft on this. Lou: it'd be good to see the doc, and then worry about which WG to put it i= n. > - Design Team Led Discussion https://github.com/ietf-mpls-yang/te and https://github.com/ietf-mpls-yang/= te/blob/master/draft-liu-ted.yang Pavan: Zafar: there's also a TED model Igor: it's just a library, not a full model Pavan: Pavan: any questions on logistics? Pavan: what about dependencies on network topology, etc? Igor: need to decide whether to reuse concepts like nodes, links, etc or wh= ether to define our own. I think we should define our own so that we can do= what we like with them. ISTR Lou questioned this in Honolulu Lou: no. Higher-level model doens't need to define where lower-level model = comes in, but lower model needs to define where it fits in. Igor: the problem is that a lot of the basic stuff isn't working for the TE= model. Looking at it another way: from a Chair's POV, would it be OK to ha= ve no base model? So we don't assume where the topology comes from or how i= t's used? Lou: from Chair perspective, we need to look at where we can re-use stuff o= r minimize duplication... but the DT doesn't necessarily need to worry too = much about it. We can tidy this stuff up later once the various models are = more mature. However, it needs doing before we end the WG process. igor: good. That's what we're doing. Lou: it'd be good if the doc captures open issues and flags this as a to-do Pavan: not slowing us down yet, so if it's OK to just flag it that's OK. Xufeng: if we want to base this onthe generic topology, we'd need many chan= ges from the base topology, and the base isnt' moving forward very fast Matt: should this go to the Area yang list? Lou: syncing up models needs doing; the question is when. igor: but we don't want to get into a situation where models are so diverse= that we cant' reconcile them. We'll need to keep in touch with Alex, etc b= ut we'll push on Adrian: if one lot of peope have a dependency on another and progress isn't= fast enough, contribute there too and help them out to remove the roadbloc= k. Xufeng: so can we take the base topology to other WGs? Lou: no, make comments on the base docs in other WGs Igor: if we know how to improve things, we can contribute. But if we don't = know how to change things...? Lou: so send a message to the list and talk to authors to see what can be d= one. Igor: we did, and we weren't happy with the answers. We thought we could in= herit the idea of overlay/underlay, but we realized we can't, so we defined= a te-path element which is not generic Lou: sounds like these are good things to flag in the doc. These are areas = where we'll have to work across WGs. Sue: I'd like to continue this discussion... I2RS will have interim meeting= s and we'd like to keep communication going. Young: if the yang model doesn't provide what we need in TE, could we augme= nt/inherit to add what we need? Can we add new semantics? Xufeng: we've been talking about augmenting the netowrk topology model to c= reate the TE model Young: so since yang allows augmentation we can just go ahead? igor: want to define model so things we can re-use are in separate librarie= s. I think it's a good idea to define stuff we need and then make stuff com= mon when we see a need to do so. Young: sounds good Zafar: where do we send comments on specific bits of the model? Pavan: TEAS list Lou: list is good. You're welcome to send stuff privately if you like Kam: idea of common information model that people can pick from is a good o= ne. we can ensure consistency between models and divergence/inconcistency i= n future. We presented a draft in Honolulu. draft-betts-netmod-framework-da= ta-schema-uml-00. From webex chat: "describes a framework for how interface= protocol specific data schema can be systematically derived from an underl= ying common information model, focusing upon the networking and forwarding = domain. The benefit of using such an approach in interface specification d= evelopment is to promote convergence, interoperability, and efficiency." Lou: almost officially out of time; I think we've achieved our main objecti= ves. Before we carry on, are there any high-level issues to discuss before = people start to leave? Pavan: next thing: dependencies on MPLS-TE-specific models. We'll be collab= orating with Tarek and that DT, especially on common stuff, but there may b= e other stuff that's TED-specific. Any other comments? Igor: it'd be good to be able to carry on with the various models in parall= el and independently. So it'd be a good plan to have the common stuff defin= ed ASAP. Tarek: agreed. Igor: also need to have the granularity correct. And need to think about wh= ich bits can be reused elsewhere when defining models Pavan: Technology-specific TE-topology models. We wanted to get the abstrac= t/agnostic stuff done first, but how do we coordinate? Zafar: yes. What's the timeline? Submit before next IETF? Pavan; yes Lou: how much is it reasonable to do in that timeframe? Details are out of = scope for DT. Zafar: that's fine. We can work offline on specific questions. Lou: to be clear, DT should not be producing technology-specific models as = part of its effort (but individuals can do what they like) Pavan: are there any other topology models that will have a dependency on o= urs? At the moment, we're OK as a lot of stuff will be in common libraries = so other models can use that. Any comments? > - Open Discussion Lou: anything else? igor: meeting has been a good experience and I'd like to thank the organize= rs. We can do other things in parallel :) Lou: etherpad has notes. Raw notes will go to list. From nobody Thu Dec 18 18:28:40 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9851A9133 for ; Thu, 18 Dec 2014 18:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham 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 wBtjiWfdd9A3 for ; Thu, 18 Dec 2014 18:28:35 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30721A9105 for ; Thu, 18 Dec 2014 18:28:34 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id uz6so9968453obc.2 for ; Thu, 18 Dec 2014 18:28:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=6bKlejHIKiw7LLQz9L8Pf9ecfpEMZOOmLAo+omUuO1M=; b=UQCASJicIFuqOZaj32XskMeAR1VPDH3otOGcyvHre6CjqfM8jmFc2ISxUwMoRzyV9p F2e0aPQilD88Ay/MfnGgMFFA7rYSrULKytSFh6iundeLrWCFhhRSL5kWycSVdiNYBbnE 5SpxHRxKWIQf79SSAoKGsLL4cS8BlSd05kdM9S9B/d2xz3/lRgvVUUll41zom7VmQkw3 FgmCZwV8evOdLI+QfQXNqGT3minpZRVnXk28v/ZoDJR0AFpnJkdi0H7ONR+bGjoE1O4x L7uWMozHOf5Gp9dScGb6uDyniTm0uu5UnisYTs/Dw2encYFM7JTqkJZENgwHeObR5Np0 bpHQ== MIME-Version: 1.0 X-Received: by 10.107.154.198 with SMTP id c189mr5319701ioe.68.1418956113857; Thu, 18 Dec 2014 18:28:33 -0800 (PST) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.154.68 with HTTP; Thu, 18 Dec 2014 18:28:33 -0800 (PST) In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC289BFEA8@xmb-rcd-x03.cisco.com> References: <9D50FCE7413E3D4EA5E42331115FB5BC289BFEA8@xmb-rcd-x03.cisco.com> Date: Fri, 19 Dec 2014 07:58:33 +0530 X-Google-Sender-Auth: Z7sJuSuWyQiUfjbu3891gJur0-c Message-ID: From: Dhruv Dhody To: "Matt Hartley (mhartley)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/teas/YJC39AdL82WwPJnrCYrgbDH_zms Cc: "TEAS WG \(teas@ietf.org\)" Subject: Re: [Teas] Interim meeting raw mintes X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 02:28:39 -0000 Hi Matt, Thanks for this. Is there a webex recording as well for those of us in deep slumber at the time of interim. Thanks, Dhruv On Fri, Dec 19, 2014 at 3:44 AM, Matt Hartley (mhartley) wrote: > All, > > Raw minutes from the interim meeting that's just finished are below. If a= nyone wants to change anything, the etherpad is at http://etherpad.tools.ie= tf.org:9000/p/notes-ietf-92-teas - please go in and do it! > > Cheers > > Matt > > > Attendance copied from Webex during the meeting... > Adrian Farrel > Lou Berger > Aihua Guo > Alia Atlas > Cyril Margaria > Daniel King > Deborah Brungard > Don Fedyk > Fred Gruman > George Swallow > Ignas Bogdanas > Igor Bryskin > Jonathan Sadler > Kam Lam > (Young?) Lee > Lyndon (Ong?) > Matt Hartley > Matthew Bocci > M Waldman > Oscar Gonzalez de Dios > Pawel Brzozowski > Rakesh Gandhi > Scott Mansfield > Susan Hares > Tarek Saad > Victor Lopez > Vishnu Pavan Beeram > Xufeng Liu > Yuji Tochio > Zafar Ali > >> - 10 min - Agenda/Intro (Lou) > Welcome, ususal IETF note well > Meeting is being recorded > Scope: mostly about TE topology yang model > Everyone should please look at draft-ietf-netmod-routing-cfg, as Adrian k= eeps pointing out > Tarek has been coordinating TE yang model work in MPLS, which will transi= tion to TEAS > In general, generic stuff will be in TEAS and dataplane-specific things w= ill be in CCAMP > L2 network topologies are in I2RS, not TE focussed yet > >> - 10 min - I2RS Related Activities (Sue) > Protocol-Independent Data Models and RIB are part of I2RS' charter > Lou: question going forward: how does TE fit in? And where do things like= TE-specific OSPF stuff go? > Sue: IGP chairs are in agreement that TE stuff specifically discussed in = OSPF/ISIS docs are part of the OSPF/ISIS WGs. Same goes for BGP. > Lou: Yang aspects of BGP-LS are still in BGP? > Sue: yes. Some operators have suggested a yang model. > Igor: you mentioned TE-OSPF and TE-ISIS, but what does that mean? Once in= formation is in the TED it doesn't matter how it got there. Do you see any = difference between OSPF and ISIS? > Sue (very firmly as an individual :) there's a difference in the handling= of information in the IGP, but not once it gets to TE > Igor: OK, so there's no such thing as OSPF-TE and ISIS-TE yang models? > Sue: there is a difference; if you're tracking information in OSPF or ISI= S that relates to TE then that's part of OSPF/ISIS > Lou: something like an opaque LSA would end up in the TED, but other thin= gs might not. > Zafar: TE topology is independent of OSPF or ISIS topology > Sue: yes. Abstract topologies have a link back to the TE topology > Zafar: so what's the definition of an abstract topology here? > Sue: The slide reflects the current level of discussion, which proposes a= n abstract topology. Alex Clemm is pushing for a topology where the highest= level is abstact, and then things buildon top of that. This is being discu= ssed in I2RS > Kam: As to the Protocol Independent, you are talking about that for topol= ogy Independent, but it is not Management Protocol Independent. > Sue: I2RS is focusing on topologies that aren't linked to a protocol. If = topology is attached to a protocol it needs to link to that protocol's conf= ig > Kam: but next slide talks about protocol-dependent IM, so what's up with = that? The term "protocol" is overloaded > Sue: yes, I'm giving you I2RS' current definition of it. Important as I2R= S is focussing on RIB and protocol-independent stuff first > Igor: should we look at topologies from user perspective, ie who's using = them and why? e.g. Which protocol was used to build the TED is unimportant = (unles there's some conflict) > Sue: agree, but there's work to be done in I2RS on this too. There's a bi= t of a grey line here. > Sue: > Zafar: slide 7: we have a draft for the network topology, is that the sam= e as the abstract topology? > Sue: no, they're different. Things are a bit mixed up at the moment and I= think you need to have a clean definition; Clemm tends not to. This is sti= ll in discussion. > Lou: I'd expect TE stuff to be addressed by the DT, and then we'll have t= o integrate with other models above this. > Zafar: I'd like to know more about how the WG can participate. > Lou: we'll get to this in a bit. > Sue: I2RS will carry on examining protocol-independent modules as we need= to know if netconf/restconf will need changes. > >> - 10 min - TE RSVP/Tunnel/LSP YANG Discussions (Tarek) > Tarek: > Design team has been meeting weekly > Multiple drafts presented in Homolulu, need coordinating so DT was formed= (draft co-authors + other intersted people) > Meetings have been announced on MPLS WG mailer, will also be on TEAS goin= g forward > Zafar: where does generic RSVP work go? > Lou: I don't think there is one but we'll need to discuss the division of= work as this stuff goes to TEAS. We should have a placeholder yang model f= or RSVP that the TE-specific stuff can hang off. We also need to worry abou= t how GMPLS fits in and how we coordinate the generic work in TEAS and the = dataplane-specific stuff in CCAMP. > Tarek: so you think GMPLS should bind into TE? > Lou: as we move to TEAS we should have a TE model that covers both MPLS-T= E and GMPLS > Igor: agree. > igor: new question. So there will be groupings common to RSVP and TE? e.g= ERO, node, link... so how do we reconcile these common definitions? Can we= create as many reusable libraries as we need that can be imported wherever= needed? > Tarek: we plan tohave a module with all this stuff > igor: I'd rather see it in smaller chunks > Tarek: OK, DT will take feedback on board > Tarek: > Lou: what does generic mean? RSVP-TE vs SR? > Tarek: agnostic of RSVP-TE or SR. > Lou: I understand it to also mean generic across dataplanes, not just con= trol planes. We'll need to be careful about terminology here. > Tarek: > Igor: what's a path-template? > Tarek: LSP template applies to all LSPs, path-template applies to all pat= hs that are defined, e.g. to set all hops strict or loose or something > Rakesh: so if you want to have many LSPs take the same path you can do th= is. > Igor: so where does the definition go and how does it get shared? > Tarek: in te-base, at the moment. > Igor: so we should define atomic libraries for little things so that the = entire model doesn't have to be imported > Lou: so maybe we should have a te-types for this > Tarek: > Igor: so where would SRLGs go? In types? > Tarek: yes > Tarek: > Zafar: dataplane should be separate. > Tarek: yes. > Lou: having discussions both on-list and in DT calls makes sense. What's = the schedule for the next few calls? > Tarek: one today, then resume in January > Lou: instead of ietf-mpls-te, call it... so that te can augment = the rsvp model > >> - 5 min - TE Topology YANG Model Design Team Introduction (Chairs) > Deborah > Zafar: work requires a lot of interaction and collaboration. not good if = WG members who want to contribute aren't there. Weekly calls are good. Can = we do this for the TED design team? > Deborah: this is up to the DT in the short term... but in the longer term= this will be a normal WG document, or the DT's work could be rejected if t= he WG doesn't like it. > Lou: bear in mind this is also only until Dallas, and we'll poll the WG o= n what's been produced. There will be plenty of time for everyone to contri= bute both before and after we have a WG doc. > Zafar: why can't you do wwhat the TE DT is doing? > Igor: premature to open discussion to too many people; will make no progr= ess at all. DT was selected to have repesentation from a variety of vendors= and operators > Lou: DT members really just came from different drafts. You can work with= colleagues at your company or collaborators on draft you already have. > Deborah: bear in mind also that TEAS has only just started so we have no = baseline. many folks are interested in this and we needed to get a core gro= up together. This is a temproary arrangement, not a new way of doing things= . > Kam: topology should be independent of management protocol in use (netcon= f, etc). There's a draft on this. > Lou: it'd be good to see the doc, and then worry about which WG to put it= in. > >> - Design Team Led Discussion > https://github.com/ietf-mpls-yang/te and https://github.com/ietf-mpls-yan= g/te/blob/master/draft-liu-ted.yang > Pavan: > Zafar: there's also a TED model > Igor: it's just a library, not a full model > Pavan: > Pavan: any questions on logistics? > > Pavan: what about dependencies on network topology, etc? > Igor: need to decide whether to reuse concepts like nodes, links, etc or = whether to define our own. I think we should define our own so that we can = do what we like with them. ISTR Lou questioned this in Honolulu > Lou: no. Higher-level model doens't need to define where lower-level mode= l comes in, but lower model needs to define where it fits in. > Igor: the problem is that a lot of the basic stuff isn't working for the = TE model. Looking at it another way: from a Chair's POV, would it be OK to = have no base model? So we don't assume where the topology comes from or how= it's used? > Lou: from Chair perspective, we need to look at where we can re-use stuff= or minimize duplication... but the DT doesn't necessarily need to worry to= o much about it. We can tidy this stuff up later once the various models ar= e more mature. However, it needs doing before we end the WG process. > igor: good. That's what we're doing. > Lou: it'd be good if the doc captures open issues and flags this as a to-= do > Pavan: not slowing us down yet, so if it's OK to just flag it that's OK. > Xufeng: if we want to base this onthe generic topology, we'd need many ch= anges from the base topology, and the base isnt' moving forward very fast > Matt: should this go to the Area yang list? > Lou: syncing up models needs doing; the question is when. > igor: but we don't want to get into a situation where models are so diver= se that we cant' reconcile them. We'll need to keep in touch with Alex, etc= but we'll push on > Adrian: if one lot of peope have a dependency on another and progress isn= 't fast enough, contribute there too and help them out to remove the roadbl= ock. > Xufeng: so can we take the base topology to other WGs? > Lou: no, make comments on the base docs in other WGs > Igor: if we know how to improve things, we can contribute. But if we don'= t know how to change things...? > Lou: so send a message to the list and talk to authors to see what can be= done. > Igor: we did, and we weren't happy with the answers. We thought we could = inherit the idea of overlay/underlay, but we realized we can't, so we defin= ed a te-path element which is not generic > Lou: sounds like these are good things to flag in the doc. These are area= s where we'll have to work across WGs. > Sue: I'd like to continue this discussion... I2RS will have interim meeti= ngs and we'd like to keep communication going. > Young: if the yang model doesn't provide what we need in TE, could we aug= ment/inherit to add what we need? Can we add new semantics? > Xufeng: we've been talking about augmenting the netowrk topology model to= create the TE model > Young: so since yang allows augmentation we can just go ahead? > igor: want to define model so things we can re-use are in separate librar= ies. I think it's a good idea to define stuff we need and then make stuff c= ommon when we see a need to do so. > Young: sounds good > Zafar: where do we send comments on specific bits of the model? > Pavan: TEAS list > Lou: list is good. You're welcome to send stuff privately if you like > Kam: idea of common information model that people can pick from is a good= one. we can ensure consistency between models and divergence/inconcistency= in future. We presented a draft in Honolulu. draft-betts-netmod-framework-= data-schema-uml-00. From webex chat: "describes a framework for how interfa= ce protocol specific data schema can be systematically derived from an unde= rlying common information model, focusing upon the networking and forwardin= g domain. The benefit of using such an approach in interface specification= development is to promote convergence, interoperability, and efficiency." > Lou: almost officially out of time; I think we've achieved our main objec= tives. Before we carry on, are there any high-level issues to discuss befor= e people start to leave? > > Pavan: next thing: dependencies on MPLS-TE-specific models. We'll be coll= aborating with Tarek and that DT, especially on common stuff, but there may= be other stuff that's TED-specific. Any other comments? > Igor: it'd be good to be able to carry on with the various models in para= llel and independently. So it'd be a good plan to have the common stuff def= ined ASAP. > Tarek: agreed. > Igor: also need to have the granularity correct. And need to think about = which bits can be reused elsewhere when defining models > Pavan: Technology-specific TE-topology models. We wanted to get the abstr= act/agnostic stuff done first, but how do we coordinate? > Zafar: yes. What's the timeline? Submit before next IETF? > Pavan; yes > Lou: how much is it reasonable to do in that timeframe? Details are out o= f scope for DT. > Zafar: that's fine. We can work offline on specific questions. > Lou: to be clear, DT should not be producing technology-specific models a= s part of its effort (but individuals can do what they like) > Pavan: are there any other topology models that will have a dependency on= ours? At the moment, we're OK as a lot of stuff will be in common librarie= s so other models can use that. Any comments? > > >> - Open Discussion > > Lou: anything else? > igor: meeting has been a good experience and I'd like to thank the organi= zers. We can do other things in parallel :) > Lou: etherpad has notes. Raw notes will go to list. > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Fri Dec 19 08:45:59 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2800C1A89E9 for ; Fri, 19 Dec 2014 08:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham 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 Milnr40haLR7 for ; Fri, 19 Dec 2014 08:45:51 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id A1B401A89B5 for ; Fri, 19 Dec 2014 08:45:51 -0800 (PST) Received: (qmail 3991 invoked by uid 0); 19 Dec 2014 16:45:48 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 19 Dec 2014 16:45:48 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id VUlk1p00J2SSUrH01Ulnx4; Fri, 19 Dec 2014 09:45:48 -0700 X-Authority-Analysis: v=2.1 cv=Lo0BlBtc c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=xSRs65CQCjkA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=NojvYFcnAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=4jTUvs1G9Td7U7E_V8UA:9 a=RRH-HBZpzmdwxwt5:21 a=ro6EiV6uwe_tkOKR:21 a=pILNOxqGKmIA:10 a=L4dRxlfgLVMA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=pJ+CYbNZzQZCsvcEdUekukrz1rleTbmVmEJvxXwLIYs=; b=wAw8vypXF8r7qcgY7CIja0qxZdwdWe0TeHf+AMAGvlk4m1qMQY7ajvHH5EwEbf8fJtl/6fzfKxyVhbRfudMqxFgs17TG3QyzEweor/VhtzQs3fQxHp6yOkNemXq/GHqc; Received: from box313.bluehost.com ([69.89.31.113]:37904 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Y20gR-0007ND-MN; Fri, 19 Dec 2014 09:45:44 -0700 Message-ID: <5494564C.2010807@labn.net> Date: Fri, 19 Dec 2014 11:46:04 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Dhruv Dhody References: <9D50FCE7413E3D4EA5E42331115FB5BC289BFEA8@xmb-rcd-x03.cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/nvpoBm5-DTCS1dBkNMEyAnpMdoQ Cc: "Matt Hartley \(mhartley\)" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Teas] Interim meeting raw mintes X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 16:45:58 -0000 Just got the link (also posted it to the etherpad minutes): https://ietf.webex.com/ietf/ldr.php?RCID=fe6635b449db2141f7270c03617fe5ce Lou On 12/18/2014 9:28 PM, Dhruv Dhody wrote: > Hi Matt, > > Thanks for this. > > Is there a webex recording as well for those of us in deep slumber at > the time of interim. > > Thanks, > Dhruv > > On Fri, Dec 19, 2014 at 3:44 AM, Matt Hartley (mhartley) > wrote: >> All, >> >> Raw minutes from the interim meeting that's just finished are below. If anyone wants to change anything, the etherpad is at http://etherpad.tools.ietf.org:9000/p/notes-ietf-92-teas - please go in and do it! >> >> Cheers >> >> Matt >> >> >> Attendance copied from Webex during the meeting... >> Adrian Farrel >> Lou Berger >> Aihua Guo >> Alia Atlas >> Cyril Margaria >> Daniel King >> Deborah Brungard >> Don Fedyk >> Fred Gruman >> George Swallow >> Ignas Bogdanas >> Igor Bryskin >> Jonathan Sadler >> Kam Lam >> (Young?) Lee >> Lyndon (Ong?) >> Matt Hartley >> Matthew Bocci >> M Waldman >> Oscar Gonzalez de Dios >> Pawel Brzozowski >> Rakesh Gandhi >> Scott Mansfield >> Susan Hares >> Tarek Saad >> Victor Lopez >> Vishnu Pavan Beeram >> Xufeng Liu >> Yuji Tochio >> Zafar Ali >> >>> - 10 min - Agenda/Intro (Lou) >> Welcome, ususal IETF note well >> Meeting is being recorded >> Scope: mostly about TE topology yang model >> Everyone should please look at draft-ietf-netmod-routing-cfg, as Adrian keeps pointing out >> Tarek has been coordinating TE yang model work in MPLS, which will transition to TEAS >> In general, generic stuff will be in TEAS and dataplane-specific things will be in CCAMP >> L2 network topologies are in I2RS, not TE focussed yet >> >>> - 10 min - I2RS Related Activities (Sue) >> Protocol-Independent Data Models and RIB are part of I2RS' charter >> Lou: question going forward: how does TE fit in? And where do things like TE-specific OSPF stuff go? >> Sue: IGP chairs are in agreement that TE stuff specifically discussed in OSPF/ISIS docs are part of the OSPF/ISIS WGs. Same goes for BGP. >> Lou: Yang aspects of BGP-LS are still in BGP? >> Sue: yes. Some operators have suggested a yang model. >> Igor: you mentioned TE-OSPF and TE-ISIS, but what does that mean? Once information is in the TED it doesn't matter how it got there. Do you see any difference between OSPF and ISIS? >> Sue (very firmly as an individual :) there's a difference in the handling of information in the IGP, but not once it gets to TE >> Igor: OK, so there's no such thing as OSPF-TE and ISIS-TE yang models? >> Sue: there is a difference; if you're tracking information in OSPF or ISIS that relates to TE then that's part of OSPF/ISIS >> Lou: something like an opaque LSA would end up in the TED, but other things might not. >> Zafar: TE topology is independent of OSPF or ISIS topology >> Sue: yes. Abstract topologies have a link back to the TE topology >> Zafar: so what's the definition of an abstract topology here? >> Sue: The slide reflects the current level of discussion, which proposes an abstract topology. Alex Clemm is pushing for a topology where the highest level is abstact, and then things buildon top of that. This is being discussed in I2RS >> Kam: As to the Protocol Independent, you are talking about that for topology Independent, but it is not Management Protocol Independent. >> Sue: I2RS is focusing on topologies that aren't linked to a protocol. If topology is attached to a protocol it needs to link to that protocol's config >> Kam: but next slide talks about protocol-dependent IM, so what's up with that? The term "protocol" is overloaded >> Sue: yes, I'm giving you I2RS' current definition of it. Important as I2RS is focussing on RIB and protocol-independent stuff first >> Igor: should we look at topologies from user perspective, ie who's using them and why? e.g. Which protocol was used to build the TED is unimportant (unles there's some conflict) >> Sue: agree, but there's work to be done in I2RS on this too. There's a bit of a grey line here. >> Sue: >> Zafar: slide 7: we have a draft for the network topology, is that the same as the abstract topology? >> Sue: no, they're different. Things are a bit mixed up at the moment and I think you need to have a clean definition; Clemm tends not to. This is still in discussion. >> Lou: I'd expect TE stuff to be addressed by the DT, and then we'll have to integrate with other models above this. >> Zafar: I'd like to know more about how the WG can participate. >> Lou: we'll get to this in a bit. >> Sue: I2RS will carry on examining protocol-independent modules as we need to know if netconf/restconf will need changes. >> >>> - 10 min - TE RSVP/Tunnel/LSP YANG Discussions (Tarek) >> Tarek: >> Design team has been meeting weekly >> Multiple drafts presented in Homolulu, need coordinating so DT was formed (draft co-authors + other intersted people) >> Meetings have been announced on MPLS WG mailer, will also be on TEAS going forward >> Zafar: where does generic RSVP work go? >> Lou: I don't think there is one but we'll need to discuss the division of work as this stuff goes to TEAS. We should have a placeholder yang model for RSVP that the TE-specific stuff can hang off. We also need to worry about how GMPLS fits in and how we coordinate the generic work in TEAS and the dataplane-specific stuff in CCAMP. >> Tarek: so you think GMPLS should bind into TE? >> Lou: as we move to TEAS we should have a TE model that covers both MPLS-TE and GMPLS >> Igor: agree. >> igor: new question. So there will be groupings common to RSVP and TE? e.g ERO, node, link... so how do we reconcile these common definitions? Can we create as many reusable libraries as we need that can be imported wherever needed? >> Tarek: we plan tohave a module with all this stuff >> igor: I'd rather see it in smaller chunks >> Tarek: OK, DT will take feedback on board >> Tarek: >> Lou: what does generic mean? RSVP-TE vs SR? >> Tarek: agnostic of RSVP-TE or SR. >> Lou: I understand it to also mean generic across dataplanes, not just control planes. We'll need to be careful about terminology here. >> Tarek: >> Igor: what's a path-template? >> Tarek: LSP template applies to all LSPs, path-template applies to all paths that are defined, e.g. to set all hops strict or loose or something >> Rakesh: so if you want to have many LSPs take the same path you can do this. >> Igor: so where does the definition go and how does it get shared? >> Tarek: in te-base, at the moment. >> Igor: so we should define atomic libraries for little things so that the entire model doesn't have to be imported >> Lou: so maybe we should have a te-types for this >> Tarek: >> Igor: so where would SRLGs go? In types? >> Tarek: yes >> Tarek: >> Zafar: dataplane should be separate. >> Tarek: yes. >> Lou: having discussions both on-list and in DT calls makes sense. What's the schedule for the next few calls? >> Tarek: one today, then resume in January >> Lou: instead of ietf-mpls-te, call it... so that te can augment the rsvp model >> >>> - 5 min - TE Topology YANG Model Design Team Introduction (Chairs) >> Deborah >> Zafar: work requires a lot of interaction and collaboration. not good if WG members who want to contribute aren't there. Weekly calls are good. Can we do this for the TED design team? >> Deborah: this is up to the DT in the short term... but in the longer term this will be a normal WG document, or the DT's work could be rejected if the WG doesn't like it. >> Lou: bear in mind this is also only until Dallas, and we'll poll the WG on what's been produced. There will be plenty of time for everyone to contribute both before and after we have a WG doc. >> Zafar: why can't you do wwhat the TE DT is doing? >> Igor: premature to open discussion to too many people; will make no progress at all. DT was selected to have repesentation from a variety of vendors and operators >> Lou: DT members really just came from different drafts. You can work with colleagues at your company or collaborators on draft you already have. >> Deborah: bear in mind also that TEAS has only just started so we have no baseline. many folks are interested in this and we needed to get a core group together. This is a temproary arrangement, not a new way of doing things. >> Kam: topology should be independent of management protocol in use (netconf, etc). There's a draft on this. >> Lou: it'd be good to see the doc, and then worry about which WG to put it in. >> >>> - Design Team Led Discussion >> https://github.com/ietf-mpls-yang/te and https://github.com/ietf-mpls-yang/te/blob/master/draft-liu-ted.yang >> Pavan: >> Zafar: there's also a TED model >> Igor: it's just a library, not a full model >> Pavan: >> Pavan: any questions on logistics? >> >> Pavan: what about dependencies on network topology, etc? >> Igor: need to decide whether to reuse concepts like nodes, links, etc or whether to define our own. I think we should define our own so that we can do what we like with them. ISTR Lou questioned this in Honolulu >> Lou: no. Higher-level model doens't need to define where lower-level model comes in, but lower model needs to define where it fits in. >> Igor: the problem is that a lot of the basic stuff isn't working for the TE model. Looking at it another way: from a Chair's POV, would it be OK to have no base model? So we don't assume where the topology comes from or how it's used? >> Lou: from Chair perspective, we need to look at where we can re-use stuff or minimize duplication... but the DT doesn't necessarily need to worry too much about it. We can tidy this stuff up later once the various models are more mature. However, it needs doing before we end the WG process. >> igor: good. That's what we're doing. >> Lou: it'd be good if the doc captures open issues and flags this as a to-do >> Pavan: not slowing us down yet, so if it's OK to just flag it that's OK. >> Xufeng: if we want to base this onthe generic topology, we'd need many changes from the base topology, and the base isnt' moving forward very fast >> Matt: should this go to the Area yang list? >> Lou: syncing up models needs doing; the question is when. >> igor: but we don't want to get into a situation where models are so diverse that we cant' reconcile them. We'll need to keep in touch with Alex, etc but we'll push on >> Adrian: if one lot of peope have a dependency on another and progress isn't fast enough, contribute there too and help them out to remove the roadblock. >> Xufeng: so can we take the base topology to other WGs? >> Lou: no, make comments on the base docs in other WGs >> Igor: if we know how to improve things, we can contribute. But if we don't know how to change things...? >> Lou: so send a message to the list and talk to authors to see what can be done. >> Igor: we did, and we weren't happy with the answers. We thought we could inherit the idea of overlay/underlay, but we realized we can't, so we defined a te-path element which is not generic >> Lou: sounds like these are good things to flag in the doc. These are areas where we'll have to work across WGs. >> Sue: I'd like to continue this discussion... I2RS will have interim meetings and we'd like to keep communication going. >> Young: if the yang model doesn't provide what we need in TE, could we augment/inherit to add what we need? Can we add new semantics? >> Xufeng: we've been talking about augmenting the netowrk topology model to create the TE model >> Young: so since yang allows augmentation we can just go ahead? >> igor: want to define model so things we can re-use are in separate libraries. I think it's a good idea to define stuff we need and then make stuff common when we see a need to do so. >> Young: sounds good >> Zafar: where do we send comments on specific bits of the model? >> Pavan: TEAS list >> Lou: list is good. You're welcome to send stuff privately if you like >> Kam: idea of common information model that people can pick from is a good one. we can ensure consistency between models and divergence/inconcistency in future. We presented a draft in Honolulu. draft-betts-netmod-framework-data-schema-uml-00. From webex chat: "describes a framework for how interface protocol specific data schema can be systematically derived from an underlying common information model, focusing upon the networking and forwarding domain. The benefit of using such an approach in interface specification development is to promote convergence, interoperability, and efficiency." >> Lou: almost officially out of time; I think we've achieved our main objectives. Before we carry on, are there any high-level issues to discuss before people start to leave? >> >> Pavan: next thing: dependencies on MPLS-TE-specific models. We'll be collaborating with Tarek and that DT, especially on common stuff, but there may be other stuff that's TED-specific. Any other comments? >> Igor: it'd be good to be able to carry on with the various models in parallel and independently. So it'd be a good plan to have the common stuff defined ASAP. >> Tarek: agreed. >> Igor: also need to have the granularity correct. And need to think about which bits can be reused elsewhere when defining models >> Pavan: Technology-specific TE-topology models. We wanted to get the abstract/agnostic stuff done first, but how do we coordinate? >> Zafar: yes. What's the timeline? Submit before next IETF? >> Pavan; yes >> Lou: how much is it reasonable to do in that timeframe? Details are out of scope for DT. >> Zafar: that's fine. We can work offline on specific questions. >> Lou: to be clear, DT should not be producing technology-specific models as part of its effort (but individuals can do what they like) >> Pavan: are there any other topology models that will have a dependency on ours? At the moment, we're OK as a lot of stuff will be in common libraries so other models can use that. Any comments? >> >> >>> - Open Discussion >> Lou: anything else? >> igor: meeting has been a good experience and I'd like to thank the organizers. We can do other things in parallel :) >> Lou: etherpad has notes. Raw notes will go to list. >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Mon Dec 22 07:43:11 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972261A9112 for ; Mon, 22 Dec 2014 07:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 h6Z_VVd-nWET for ; Mon, 22 Dec 2014 07:43:08 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 B0F3A1A1A69 for ; Mon, 22 Dec 2014 07:43:08 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 2CECACAE6EDF1; Mon, 22 Dec 2014 15:43:03 +0000 (GMT) Received: from destgsu0709.de.alcatel-lucent.com (slsv7at.de.alcatel-lucent.com [149.204.245.107]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sBMFh3E7032075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2014 16:43:06 +0100 Received: from [135.244.177.116] (beller.lra.lucent.com [135.244.177.116]) (authenticated bits=0) by destgsu0709.de.alcatel-lucent.com (8.14.3/8.13.8) with ESMTP id sBMFh015017302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 22 Dec 2014 16:43:02 +0100 (CET) Message-ID: <54983C03.8050806@alcatel-lucent.com> Date: Mon, 22 Dec 2014 16:42:59 +0100 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Lou Berger , TEAS WG References: <548B5DA8.1060700@labn.net> In-Reply-To: <548B5DA8.1060700@labn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/teas/P_lr4iU7rqcpBEzzeupxoRLLXo8 Subject: Re: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 15:43:10 -0000 Hi all, yes/support Thanks, Dieter On 12.12.2014 22:27, Lou Berger wrote: > All, > > This is start of a two week poll on making > draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a TEAS working group > document. Please send email to the list indicating “yes/support” or > “no/do not support”. If indicating no, please state your technical > reservations with the document. > > The poll ends Friday December 26th. > > Thanks, > > Deborah and Lou > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Wed Dec 24 14:45:38 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC651A1B7C for ; Wed, 24 Dec 2014 14:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 6lShfoJ8v2EF for ; Wed, 24 Dec 2014 14:45:34 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5041A1B72 for ; Wed, 24 Dec 2014 14:45:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=867; q=dns/txt; s=iport; t=1419461134; x=1420670734; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Oam5T5OOT9eELdNCbHiJ48Xx8yreNVlkrtcluCzcHu8=; b=I6lkHdtFVEnJrjdpmy8N/QMaw2Oq4cd9dIDxAYe8UjDkAD3e3PNP03ZV DH8lEs+7GKq/exgHECqBKzx2thIk/nGqWcg3ffS90QP8c9Gzr/TZNToth HQpPev0VEdnGghSkydXlLZmUkmhWP63LdtynWCOusUK29plWKqiJfa8tC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFANJAm1StJA2D/2dsb2JhbABcgmQiUlgExkoKhXECgRAWAQEBAQF9hAwBAQEEAQEBNzQXBAIBCA4DBAEBCxQJBycLFAkIAgQBEgiIJAEMyhcBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI8QEQEfOAaDEIETBYw+gVeKAIJliiWDOSKCMoE8b4EMOX4BAQE X-IronPort-AV: E=Sophos;i="5.07,639,1413244800"; d="scan'208";a="382529146" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 24 Dec 2014 22:45:33 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBOMjXMu030674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Dec 2014 22:45:33 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Wed, 24 Dec 2014 16:45:32 -0600 From: "Nobo Akiya (nobo)" To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document Thread-Index: AQHQFlJeRxqUgQcqg0yZemRAYQjBdJyfWenw Date: Wed, 24 Dec 2014 22:45:32 +0000 Message-ID: References: <548B5DA8.1060700@labn.net> In-Reply-To: <548B5DA8.1060700@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.231.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/VtKuAiMmPP2EQvMra8cA7J8LjYk Subject: Re: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 22:45:36 -0000 Hi Deborah and Lou, yes/support Thanks! -Nobo > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Friday, December 12, 2014 4:27 PM > To: TEAS WG > Subject: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp- > fastreroute-05 a WG document >=20 > All, >=20 > This is start of a two week poll on making > draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a TEAS working group > document. Please send email to the list indicating "yes/support" or "no/d= o > not support". If indicating no, please state your technical reservations = with > the document. >=20 > The poll ends Friday December 26th. >=20 > Thanks, >=20 > Deborah and Lou >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Wed Dec 24 14:46:24 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E477E1A1B7E for ; Wed, 24 Dec 2014 14:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 A-laE-I5dBt8 for ; Wed, 24 Dec 2014 14:46:16 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE2D1A1B77 for ; Wed, 24 Dec 2014 14:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28946; q=dns/txt; s=iport; t=1419461172; x=1420670772; h=from:to:cc:subject:date:message-id:mime-version; bh=9qQeLBpw/gncMZh8KCiizUBNCM9UrTqJAFJJLgDGwtM=; b=WzX8v79RJGrma64TvUKKgbKWsvPP3FbJ2w/EdHoMbhiaDHdxiZidFijt Ps1wcNkJ4UlPZWf7J0EaAN6y4r2AJKdJ+ottDW6HTybOffigGN5xSSVsO ydFYlNOriZ4evcxMv1pfIVHLWOIEI4g0GR6ybJBpDuO45TL40TYHw07qB M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAPRBm1StJV2U/2dsb2JhbABcgkMhIlJczEUCgRAWAQEBAQF9hA4BBC1MEgEqFgE/JgEEDg2IJAHKIAEBAQEBAQEBAQEBAQEBAQEBAQEBARePIQEBHjGDHYETBYUnhxeBV4oAgmWCM4srIoNugXs5fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,639,1413244800"; d="scan'208,217";a="382482748" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP; 24 Dec 2014 22:45:56 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sBOMjt5N004492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Dec 2014 22:45:55 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 24 Dec 2014 16:45:55 -0600 From: "Nobo Akiya (nobo)" To: "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org" Thread-Topic: Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute Thread-Index: AdAfw4yPXwLBG3MFToqlKPshDlwAgg== Date: Wed, 24 Dec 2014 22:45:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.231.160] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943F67A92Cxmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/MaBzihMq5bfLDiEVa0c7wAF0r2M Cc: TEAS WG Subject: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 22:46:21 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943F67A92Cxmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors, Happy Holidays! I read draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 (as part of its WG= adoption poll), and had some questions/comments. Please find them below. 1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT subobject may be eas= ier to understand if "list" is used. [OLD] The BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE object prior to adding the node's IP address in the node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT subobject without also adding a Node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT subobject without also adding an IPv4 or IPv6 subobject. [NEW] When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE object: o The BYPASS_ASSIGNMENT subobject MUST be added prior to the node-ID subobject describing the node's IP address. o The Node-ID subobject MUST also be added. o The IPv4 or IPv6 subobject MUST also be added. 2) Section 4.4.1 - First sentence of the third paragraph was quite difficul= t to read/understand. Perhaps adding some commas and quotations may improve= its readability. [OLD] The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT subobject whose bypass tunnel and the node-ID subobject when used as a bypass tunnel source terminates locally assigns the matching bidirectional bypass tunnel in the reverse direction, and forwards the RSVP Path message downstream. [NEW] The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT subobject, whose bypass tunnel and the node-ID subobject when used as a "bypass tunnel source" terminates locally, assigns the matching bidirectional bypass tunnel in the reverse direction, and forwards the RSVP Path message downstream. 3) Section 4.4.1 - I have a slight concern regarding below statement. [snip] In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR does not assign a bypass tunnel in the reverse direction. This allows the downstream PLR to always initiate the bypass assignment and upstream PLR to simply reflect the bypass assignment. In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT subobjects from multiple downstream PLRs, the decision of selecting a bypass tunnel in the reverse direction can be based on local policy, for example, prefer link protection versus node protection bypass tunnel, or prefer the most upstream versus least upstream node protection bypass tunnel. [snip] When LSRs within a bidirectional LSP employ different policies, as describe= d above, then we can result in pockets where there are no protections. For example: Node A uses node protection. Node B and C use link protection. +---------+ / +-+ \ / / \ \ / / v v A ----- B ----- C ^ / \ / +-+ The result of above is that, in the reverse direction, there will not be an= y protection between nodes B and A. Another example: Node A and C use node protection. Node B use link protection. +---------+ / +-+ \ / / \ \ / / v v A ----- B ----- C ^ / \ / +----------+ The result of above is that, in the reverse direction, there will not be an= y protection between nodes B and A. In both cases, if there is a breakage of the link connecting nodes A and B,= then node C receives the RSVP PATH message. If node C follows procedures d= escribed in Section 6.2, then it will not find a matching bypass tunnel. If I'm off track, then I apologize for the noise. If above is indeed a prob= lem, then this limitation should at least be described in the document, fol= lowed by a recommendation of all LSRs within a bidirectional tunnel employi= ng the same policy. It may be possible to (be brave and) address this but it will require more = procedures. I'll leave the decision and further investigation to the author= s. 4) Section 4.4.1 - Should there be SHOULD or MUST in this paragraph? [snip] In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR does not assign a bypass tunnel in the reverse direction. This allows the downstream PLR to always initiate the bypass assignment and upstream PLR to simply reflect the bypass assignment. [snip] I'm guessing that there should be a SHOULD ... 5) Section 6.2 - "If" and "If not" in below text do not correspond to each = other (thus a bit confusing). [snip] - If found, checks whether the primary LSP traffic and signaling are already rerouted over the found bypass tunnel. If not, PRR R5 activates FRR reroute procedures to direct traffic and RSVP Resv over the found bypass tunnel T2 in the reverse direction. [snip] If we write above with a psuedocode, then it will be: if (bypass tunnel found) { // "If found" is this line check if already rerouted if (not already rerouted) { // "If not" is this line active FRR reroute } } It might make the texts easier to read/understand if you can rephrase it a= bit? Thanks! -Nobo --_000_CECE764681BE964CBE1DFF78F3CDD3943F67A92Cxmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Authors,

 

Happy Holidays!

 

I read draft-tsaad-ccamp-rsv= pte-bidir-lsp-fastreroute-05 (as part of its WG adoption poll), and had som= e questions/comments. Please find them below.

 

 

1) Section 4.4.1 - The rules= for the BYPASS_ASSIGNMENT subobject may be easier to understand if “= list” is used.

 

[OLD]

   The BYPASS_ASSI= GNMENT subobject is added in the RECORD_ROUTE object

   prior to adding= the node's IP address in the node-ID subobject.  A<= /p>

   node MUST NOT a= dd a BYPASS_ASSIGNMENT subobject without also adding a

   Node-ID subobje= ct.  A node MUST NOT add a BYPASS_ASSIGNMENT subobject

   without also ad= ding an IPv4 or IPv6 subobject.

 

[NEW]

   When the BYPASS= _ASSIGNMENT subobject is added in the RECORD_ROUTE

   object:

 

   o  The BYP= ASS_ASSIGNMENT subobject MUST be added prior to the node-ID

    &nbs= p; subobject describing the node's IP address.

 

   o  The Nod= e-ID subobject MUST also be added.

 

   o  The IPv= 4 or IPv6 subobject MUST also be added.

 

 

2) Section 4.4.1 - First sen= tence of the third paragraph was quite difficult to read/understand. Perhap= s adding some commas and quotations may improve its readability.=

 

[OLD]

   The upstream PL= R (downstream MP) that detects a BYPASS_ASSIGNMENT

   subobject whose= bypass tunnel and the node-ID subobject when used as

   a bypass tunnel= source terminates locally assigns the matching

   bidirectional b= ypass tunnel in the reverse direction, and forwards

   the RSVP Path m= essage downstream.

 

[NEW]

   The upstream PL= R (downstream MP) that detects a BYPASS_ASSIGNMENT

   subobject, whos= e bypass tunnel and the node-ID subobject when used as

   a "bypass = tunnel source" terminates locally, assigns the matching

   bidirectional b= ypass tunnel in the reverse direction, and forwards

   the RSVP Path m= essage downstream.

 

 

3) Section 4.4.1 - I have a = slight concern regarding below statement.

 

[snip]

   In the absence = of BYPASS_ASSIGNMENT subobject, the upstream PLR does

   not assign a by= pass tunnel in the reverse direction.  This allows the

   downstream PLR = to always initiate the bypass assignment and upstream

   PLR to simply r= eflect the bypass assignment.

 

   In the case of = upstream PLR receiving multiple BYPASS_ASSIGNMENT

   subobjects from= multiple downstream PLRs, the decision of selecting a

   bypass tunnel i= n the reverse direction can be based on local policy,

   for example, pr= efer link protection versus node protection bypass

   tunnel, or pref= er the most upstream versus least upstream node

   protection bypa= ss tunnel.

[snip]

 

When LSRs within a bidirecti= onal LSP employ different policies, as described above, then we can result = in pockets where there are no protections.

 

For example:

 

Node A uses node protection.=

Node B and C use link protec= tion.

 

    +---------+<= /p>

   /       +-= + \

  /       /  = ; \ \

/       /   =   v v

A ----- B ----- C

         ^ &= nbsp;   /

          \&= nbsp;  /

         &nb= sp; +-+

         &nb= sp;          

The result of above is that,= in the reverse direction, there will not be any protection between nodes B= and A.

 

Another example:<= /span>

 

Node A and C use node protec= tion.

Node B use link protection.<= o:p>

 

    +---------+<= /p>

   /       +-= + \

  /       /  = ; \ \

/       /   =   v v

A ----- B ----- C

^         &n= bsp;    /

  \        &= nbsp;   /

   +----------+

 

The result of above is that,= in the reverse direction, there will not be any protection between nodes B= and A.

 

In both cases, if there is a= breakage of the link connecting nodes A and B, then node C receives the RS= VP PATH message. If node C follows procedures described in Section 6.2, the= n it will not find a matching bypass tunnel.

 

If I’m off track, then= I apologize for the noise. If above is indeed a problem, then this limitat= ion should at least be described in the document, followed by a recommendat= ion of all LSRs within a bidirectional tunnel employing the same policy.

 

It may be possible to (be br= ave and) address this but it will require more procedures. I’ll leave= the decision and further investigation to the authors.

 

 

4) Section 4.4.1 - Should th= ere be SHOULD or MUST in this paragraph?

 

[snip]

   In the absence of BYPASS_ASSIGNMENT = subobject, the upstream PLR does

   not assign a bypass tunnel in the re= verse direction.  This allows the

   downstream PLR to always initiate th= e bypass assignment and upstream

   PLR to simply reflect the bypass ass= ignment.

[snip]

 

I’m guessing that there should be a SHOULD = …

 

 

5) Section 6.2 - “If” and “If n= ot” in below text do not correspond to each other (thus a bit confusi= ng).

 

[snip]

      - If found, checks= whether the primary LSP traffic and signaling

        are al= ready rerouted over the found bypass tunnel.  If not, PRR

        R5 act= ivates FRR reroute procedures to direct traffic and

        RSVP R= esv over the found bypass tunnel T2 in the

        revers= e direction.

[snip]

 

If we write above with a psuedocode, then it will= be:

 

    if (bypass tunnel found) {    &nb= sp; // “If found” is this line

        check if already rerouted

        if (not already rerouted) { /= / “If not” is this line

            = active FRR reroute

        }

    }

 

It  might make the texts easier to read/unde= rstand if you can rephrase it a bit?

 

 

Thanks!

 

-Nobo

 

--_000_CECE764681BE964CBE1DFF78F3CDD3943F67A92Cxmbalnx01ciscoc_-- From nobody Wed Dec 24 15:26:21 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03551A3B9C for ; Wed, 24 Dec 2014 15:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 5GSZKnQ3rCI0 for ; Wed, 24 Dec 2014 15:26:15 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D1E51A3B9B for ; Wed, 24 Dec 2014 15:26:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32768; q=dns/txt; s=iport; t=1419463575; x=1420673175; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=fADoRsYBerO3fTvXvVvb3fL2H6bh9vWKdhdtFhfoAys=; b=JhRIQIDsJj2oeTvZLs+oXLGK6cIjqo70cPl7KPb1TVIj+wikoh+KzKl6 Gxq95P0kR8pPo4/3DDSHH0yILvcnAtRc9Od7ZMnVCKmgd8nkqawkcQHNd WCctEOEltRsSLjCiAgLn09Q+MR0n7mz46CorInMP50WsuXYt4ADPNXaql g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAB1Lm1StJA2L/2dsb2JhbABcgkNDUlgEzEUCgRAWAQEBAQF9hAwBAgQtTBIBCBEDAQIhAQYoERQJCAEBBAENBYgYAxHEMw2FCQEBAQEBAQEBAQEBAQEBAQEBAQEBAReNSoFXAQE+EQcGhCMFhSeHF4FXhy+BRIENgmWCM4VUgh6DOSKDbm+BDDl+AQEB X-IronPort-AV: E=Sophos;i="5.07,639,1413244800"; d="scan'208,217";a="382539369" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP; 24 Dec 2014 23:26:14 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sBONQEpO015212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Dec 2014 23:26:14 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.173]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Wed, 24 Dec 2014 17:26:13 -0600 From: "Rakesh Gandhi (rgandhi)" To: "Nobo Akiya (nobo)" , "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org" Thread-Topic: Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute Thread-Index: AdAfw4yPXwLBG3MFToqlKPshDlwAggAFdR6A Date: Wed, 24 Dec 2014 23:25:56 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.82.209.65] Content-Type: multipart/alternative; boundary="_000_D0C0B55D490FCrgandhiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/J9Vma-jHnLqaBqqKJEAtFVvblMo Cc: TEAS WG Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 23:26:18 -0000 --_000_D0C0B55D490FCrgandhiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you Nobo for your detailed review comments. We will address these in the next revision. Happy holidays. Thanks, Rakesh From: "Nobo Akiya (nobo)" > Date: Wednesday, 24 December, 2014 5:45 PM To: "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org" > Cc: TEAS WG > Subject: Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute Resent-From: > Resent-To: "frederic.jounay@orange.ch" >, "Lizhong com>"= >, >, "=3DSMTP:mtaillon@cisco. com" >, Rakesh Gandhi >, >, Zafar = Ali > Resent-Date: Wednesday, 24 December, 2014 5:46 PM Hi Authors, Happy Holidays! I read draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 (as part of its WG= adoption poll), and had some questions/comments. Please find them below. 1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT subobject may be eas= ier to understand if =93list=94 is used. [OLD] The BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE object prior to adding the node's IP address in the node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT subobject without also adding a Node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT subobject without also adding an IPv4 or IPv6 subobject. [NEW] When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE object: o The BYPASS_ASSIGNMENT subobject MUST be added prior to the node-ID subobject describing the node's IP address. o The Node-ID subobject MUST also be added. o The IPv4 or IPv6 subobject MUST also be added. 2) Section 4.4.1 - First sentence of the third paragraph was quite difficul= t to read/understand. Perhaps adding some commas and quotations may improve= its readability. [OLD] The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT subobject whose bypass tunnel and the node-ID subobject when used as a bypass tunnel source terminates locally assigns the matching bidirectional bypass tunnel in the reverse direction, and forwards the RSVP Path message downstream. [NEW] The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT subobject, whose bypass tunnel and the node-ID subobject when used as a "bypass tunnel source" terminates locally, assigns the matching bidirectional bypass tunnel in the reverse direction, and forwards the RSVP Path message downstream. 3) Section 4.4.1 - I have a slight concern regarding below statement. [snip] In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR does not assign a bypass tunnel in the reverse direction. This allows the downstream PLR to always initiate the bypass assignment and upstream PLR to simply reflect the bypass assignment. In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT subobjects from multiple downstream PLRs, the decision of selecting a bypass tunnel in the reverse direction can be based on local policy, for example, prefer link protection versus node protection bypass tunnel, or prefer the most upstream versus least upstream node protection bypass tunnel. [snip] When LSRs within a bidirectional LSP employ different policies, as describe= d above, then we can result in pockets where there are no protections. For example: Node A uses node protection. Node B and C use link protection. +---------+ / +-+ \ / / \ \ / / v v A ----- B ----- C ^ / \ / +-+ The result of above is that, in the reverse direction, there will not be an= y protection between nodes B and A. Another example: Node A and C use node protection. Node B use link protection. +---------+ / +-+ \ / / \ \ / / v v A ----- B ----- C ^ / \ / +----------+ The result of above is that, in the reverse direction, there will not be an= y protection between nodes B and A. In both cases, if there is a breakage of the link connecting nodes A and B,= then node C receives the RSVP PATH message. If node C follows procedures d= escribed in Section 6.2, then it will not find a matching bypass tunnel. If I=92m off track, then I apologize for the noise. If above is indeed a pr= oblem, then this limitation should at least be described in the document, f= ollowed by a recommendation of all LSRs within a bidirectional tunnel emplo= ying the same policy. It may be possible to (be brave and) address this but it will require more = procedures. I=92ll leave the decision and further investigation to the auth= ors. 4) Section 4.4.1 - Should there be SHOULD or MUST in this paragraph? [snip] In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR does not assign a bypass tunnel in the reverse direction. This allows the downstream PLR to always initiate the bypass assignment and upstream PLR to simply reflect the bypass assignment. [snip] I=92m guessing that there should be a SHOULD =85 5) Section 6.2 - =93If=94 and =93If not=94 in below text do not correspond = to each other (thus a bit confusing). [snip] - If found, checks whether the primary LSP traffic and signaling are already rerouted over the found bypass tunnel. If not, PRR R5 activates FRR reroute procedures to direct traffic and RSVP Resv over the found bypass tunnel T2 in the reverse direction. [snip] If we write above with a psuedocode, then it will be: if (bypass tunnel found) { // =93If found=94 is this line check if already rerouted if (not already rerouted) { // =93If not=94 is this line active FRR reroute } } It might make the texts easier to read/understand if you can rephrase it a= bit? Thanks! -Nobo --_000_D0C0B55D490FCrgandhiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <31B58D9FABEE7A4BBEC17E45C1394C44@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thank you Nobo for your detailed review comments.

We will address these in the next revision.

Happy holidays.

Thanks,
Rakesh 


From: "Nobo Akiya (nobo)"= <nobo@cisco.com>
Date: Wednesday, 24 December, 2014 = 5:45 PM
To: "draft-tsaad-ccamp-r= svpte-bidir-lsp-fastreroute@tools.ietf.org" <draft-tsaad-= ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org>
Cc: TEAS WG <teas@ietf.org>
Subject: Mail regarding draft-tsaad= -ccamp-rsvpte-bidir-lsp-fastreroute
Resent-From: <draft-alias-bounces@tools.ietf.org&= gt;
Resent-To: "frederic.jounay@orange.ch" <frederic.jounay@orange.ch>, &q= uot;Lizhong com>" <lizho.= jin@gmail.com>, <manav@ionosnetworks.com= >, "=3DSMTP:mtaillon@cisco. com" <mtaillon@cisco.com>, Rakesh Gandhi <rgandhi@cisco.com>, <tsaad@cisco.com>, Zafar Ali <zali@cisco.com>
Resent-Date: Wednesday, 24 December= , 2014 5:46 PM

Hi Authors,

 

Happy Holidays!

 

I read draft-tsaad-ccamp-rsv= pte-bidir-lsp-fastreroute-05 (as part of its WG adoption poll), and had som= e questions/comments. Please find them below.

 

 

1) Section 4.4.1 - The rules= for the BYPASS_ASSIGNMENT subobject may be easier to understand if =93list= =94 is used.

 

[OLD]

   The BYPASS_ASSI= GNMENT subobject is added in the RECORD_ROUTE object

   prior to adding= the node's IP address in the node-ID subobject.  A<= /p>

   node MUST NOT a= dd a BYPASS_ASSIGNMENT subobject without also adding a

   Node-ID subobje= ct.  A node MUST NOT add a BYPASS_ASSIGNMENT subobject

   without also ad= ding an IPv4 or IPv6 subobject.

 

[NEW]

   When the BYPASS= _ASSIGNMENT subobject is added in the RECORD_ROUTE

   object:

 

   o  The BYP= ASS_ASSIGNMENT subobject MUST be added prior to the node-ID

    &nbs= p; subobject describing the node's IP address.

 

   o  The Nod= e-ID subobject MUST also be added.

 

   o  The IPv= 4 or IPv6 subobject MUST also be added.

 

 

2) Section 4.4.1 - First sen= tence of the third paragraph was quite difficult to read/understand. Perhap= s adding some commas and quotations may improve its readability.=

 

[OLD]

   The upstream PL= R (downstream MP) that detects a BYPASS_ASSIGNMENT

   subobject whose= bypass tunnel and the node-ID subobject when used as

   a bypass tunnel= source terminates locally assigns the matching

   bidirectional b= ypass tunnel in the reverse direction, and forwards

   the RSVP Path m= essage downstream.

 

[NEW]

   The upstream PL= R (downstream MP) that detects a BYPASS_ASSIGNMENT

   subobject, whos= e bypass tunnel and the node-ID subobject when used as

   a "bypass = tunnel source" terminates locally, assigns the matching

   bidirectional b= ypass tunnel in the reverse direction, and forwards

   the RSVP Path m= essage downstream.

 

 

3) Section 4.4.1 - I have a = slight concern regarding below statement.

 

[snip]

   In the absence = of BYPASS_ASSIGNMENT subobject, the upstream PLR does

   not assign a by= pass tunnel in the reverse direction.  This allows the

   downstream PLR = to always initiate the bypass assignment and upstream

   PLR to simply r= eflect the bypass assignment.

 

   In the case of = upstream PLR receiving multiple BYPASS_ASSIGNMENT

   subobjects from= multiple downstream PLRs, the decision of selecting a

   bypass tunnel i= n the reverse direction can be based on local policy,

   for example, pr= efer link protection versus node protection bypass

   tunnel, or pref= er the most upstream versus least upstream node

   protection bypa= ss tunnel.

[snip]

 

When LSRs within a bidirecti= onal LSP employ different policies, as described above, then we can result = in pockets where there are no protections.

 

For example:

 

Node A uses node protection.=

Node B and C use link protec= tion.

 

    +---------+

   /       +-+ \=

  /       /   \ \

/       /     = v v

A ----- B ----- C

         ^  &n= bsp;  /

          \ &n= bsp; /

           = 3;-+

          &nbs= p;         

The result of above is that,= in the reverse direction, there will not be any protection between nodes B= and A.

 

Another example:<= /span>

 

Node A and C use node protec= tion.

Node B use link protection.<= o:p>

 

    +---------+

   /       +-+ \=

  /       /   \ \

/       /     = v v

A ----- B ----- C

^          &nb= sp;   /

  \         &n= bsp;  /

   +----------+

 

The result of above is that,= in the reverse direction, there will not be any protection between nodes B= and A.

 

In both cases, if there is a= breakage of the link connecting nodes A and B, then node C receives the RS= VP PATH message. If node C follows procedures described in Section 6.2, the= n it will not find a matching bypass tunnel.

 

If I=92m off track, then I a= pologize for the noise. If above is indeed a problem, then this limitation = should at least be described in the document, followed by a recommendation = of all LSRs within a bidirectional tunnel employing the same policy.

 

It may be possible to (be br= ave and) address this but it will require more procedures. I=92ll leave the= decision and further investigation to the authors.

 

 

4) Section 4.4.1 - Should th= ere be SHOULD or MUST in this paragraph?

 

[snip]

   In the absence of BYPASS_ASSIGNMENT = subobject, the upstream PLR does

   not assign a bypass tunnel in the re= verse direction.  This allows the

   downstream PLR to always initiate th= e bypass assignment and upstream

   PLR to simply reflect the bypass ass= ignment.

[snip]

 

I=92m guessing that there should be a SHOULD =85<= o:p>

 

 

5) Section 6.2 - =93If=94 and =93If not=94 in bel= ow text do not correspond to each other (thus a bit confusing).<= /p>

 

[snip]

      - If found, checks= whether the primary LSP traffic and signaling

        are al= ready rerouted over the found bypass tunnel.  If not, PRR

        R5 act= ivates FRR reroute procedures to direct traffic and

        RSVP R= esv over the found bypass tunnel T2 in the

        revers= e direction.

[snip]

 

If we write above with a psuedocode, then it will= be:

 

&nbs= p;   if (bypass tunnel found) {      // = =93If found=94 is this line

&nbs= p;       check if already rerouted=

&nbs= p;       if (not already rerouted) { // =93If= not=94 is this line

&nbs= p;            active= FRR reroute

&nbs= p;       }

&nbs= p;   }

 

It  might make the texts easier to read/unde= rstand if you can rephrase it a bit?

 

 

Thanks!

 

-Nobo

 

 --_000_D0C0B55D490FCrgandhiciscocom_-- From nobody Wed Dec 24 18:19:33 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541BB1A6FA3 for ; Wed, 24 Dec 2014 18:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ft7Qsoa8YrYW for ; Wed, 24 Dec 2014 18:19:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A891A6FA0 for ; Wed, 24 Dec 2014 18:19:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQL55257; Thu, 25 Dec 2014 02:19:26 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 25 Dec 2014 02:19:24 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.43]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Thu, 25 Dec 2014 10:19:21 +0800 From: "Zhangxian (Xian)" To: Lou Berger , "teas@ietf.org" Thread-Topic: Re: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document Thread-Index: AdAf6TEvY7ABF2iaSemLOXLonyFj8g== Date: Thu, 25 Dec 2014 02:19:21 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B4714EB26SZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/teas/EtJY3zXlfVBmDhvZ8SS_SlsOP1I Subject: Re: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 02:19:31 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B4714EB26SZXEMA512MBSchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes/support. Regards, Xian On 2014-12-12 4:27 PM, "Lou Berger" > wrote: >All, > >This is start of a two week poll on making >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a TEAS working group >document. Please send email to the list indicating =B3yes/support=B2 or >=B3no/do not support=B2. If indicating no, please state your technical >reservations with the document. > >The poll ends Friday December 26th. > >Thanks, > >Deborah and Lou > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas --_000_C636AF2FA540124E9B9ACB5A6BECCE6B4714EB26SZXEMA512MBSchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Yes/support.

 

Regards,

Xian

 

On 2014-12-12 4:27 PM, "= ;Lou Berger" <lberger@labn.net<= /a>> wrote:

 

>All,

> =

>This is start of a two w= eek poll on making

>draft-tsaad-ccamp-rsvpte= -bidir-lsp-fastreroute-05 a TEAS working group

>document. Please send em= ail to the list indicating = =B3yes/support=B2 or

>=B3no/do not support=B2. If indicating no, pl= ease state your technical

>reservations with the do= cument.

> =

>The poll ends Friday Dec= ember 26th.

> =

>Thanks,

> =

>Deborah and Lou

> =

>________________________= _______________________

>Teas mailing list

>Teas@ietf.org

>https://www.ietf.org/mailman/listinfo/teas

 

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B4714EB26SZXEMA512MBSchi_-- From nobody Wed Dec 24 20:50:38 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2F31A86F7 for ; Wed, 24 Dec 2014 20:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Bmti9InaHKtT for ; Wed, 24 Dec 2014 20:50:29 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E87C1A86F5 for ; Wed, 24 Dec 2014 20:50:28 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.191.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 194691801590; Thu, 25 Dec 2014 05:50:24 +0100 (CET) Message-ID: <549B978B.6080603@pi.nu> Date: Thu, 25 Dec 2014 12:50:19 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Rakesh Gandhi (rgandhi)" , "Nobo Akiya (nobo)" , "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/teas/W2vYWs_mECsRZzhWf7Rc2W8gKZw Cc: TEAS WG Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 04:50:33 -0000 Working Group, I was almost through my review of this document, saw Nobo's review and found that he had found everything I found and a bit more :). With that and with Rakesh's statement that the comments will be addressed I souppor the adoption of the document as a wg doc. /Loa On 2014-12-25 07:25, Rakesh Gandhi (rgandhi) wrote: > Thank you Nobo for your detailed review comments. > > We will address these in the next revision. > > Happy holidays. > > Thanks, > Rakesh > > > From: "Nobo Akiya (nobo)" > > Date: Wednesday, 24 December, 2014 5:45 PM > To: "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org > " > > > Cc: TEAS WG > > Subject: Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute > Resent-From: > > Resent-To: "frederic.jounay@orange.ch > " >, "Lizhong com>" >, >, "=SMTP:mtaillon@cisco. com" > >, Rakesh Gandhi > >, >, Zafar Ali > > Resent-Date: Wednesday, 24 December, 2014 5:46 PM > > Hi Authors, > > Happy Holidays! > > I read draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 (as part of its > WG adoption poll), and had some questions/comments. Please find them below. > > 1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT subobject may be > easier to understand if “list” is used. > > [OLD] > > The BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE object > > prior to adding the node's IP address in the node-ID subobject. A > > node MUST NOT add a BYPASS_ASSIGNMENT subobject without also adding a > > Node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT subobject > > without also adding an IPv4 or IPv6 subobject. > > [NEW] > > When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE > > object: > > o The BYPASS_ASSIGNMENT subobject MUST be added prior to the node-ID > > subobject describing the node's IP address. > > o The Node-ID subobject MUST also be added. > > o The IPv4 or IPv6 subobject MUST also be added. > > 2) Section 4.4.1 - First sentence of the third paragraph was quite > difficult to read/understand. Perhaps adding some commas and quotations > may improve its readability. > > [OLD] > > The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT > > subobject whose bypass tunnel and the node-ID subobject when used as > > a bypass tunnel source terminates locally assigns the matching > > bidirectional bypass tunnel in the reverse direction, and forwards > > the RSVP Path message downstream. > > [NEW] > > The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT > > subobject, whose bypass tunnel and the node-ID subobject when used as > > a "bypass tunnel source" terminates locally, assigns the matching > > bidirectional bypass tunnel in the reverse direction, and forwards > > the RSVP Path message downstream. > > 3) Section 4.4.1 - I have a slight concern regarding below statement. > > [snip] > > In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR does > > not assign a bypass tunnel in the reverse direction. This allows the > > downstream PLR to always initiate the bypass assignment and upstream > > PLR to simply reflect the bypass assignment. > > In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT > > subobjects from multiple downstream PLRs, the decision of selecting a > > bypass tunnel in the reverse direction can be based on local policy, > > for example, prefer link protection versus node protection bypass > > tunnel, or prefer the most upstream versus least upstream node > > protection bypass tunnel. > > [snip] > > When LSRs within a bidirectional LSP employ different policies, as > described above, then we can result in pockets where there are no > protections. > > For example: > > Node A uses node protection. > > Node B and C use link protection. > > +---------+ > > / +-+ \ > > / / \ \ > > / / v v > > A ----- B ----- C > > ^ / > > \ / > > +-+ > > The result of above is that, in the reverse direction, there will not be > any protection between nodes B and A. > > Another example: > > Node A and C use node protection. > > Node B use link protection. > > +---------+ > > / +-+ \ > > / / \ \ > > / / v v > > A ----- B ----- C > > ^ / > > \ / > > +----------+ > > The result of above is that, in the reverse direction, there will not be > any protection between nodes B and A. > > In both cases, if there is a breakage of the link connecting nodes A and > B, then node C receives the RSVP PATH message. If node C follows > procedures described in Section 6.2, then it will not find a matching > bypass tunnel. > > If I’m off track, then I apologize for the noise. If above is indeed a > problem, then this limitation should at least be described in the > document, followed by a recommendation of all LSRs within a > bidirectional tunnel employing the same policy. > > It may be possible to (be brave and) address this but it will require > more procedures. I’ll leave the decision and further investigation to > the authors. > > 4) Section 4.4.1 - Should there be SHOULD or MUST in this paragraph? > > [snip] > > In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR does > > not assign a bypass tunnel in the reverse direction. This allows the > > downstream PLR to always initiate the bypass assignment and upstream > > PLR to simply reflect the bypass assignment. > > [snip] > > I’m guessing that there should be a SHOULD … > > 5) Section 6.2 - “If” and “If not” in below text do not correspond to > each other (thus a bit confusing). > > [snip] > > - If found, checks whether the primary LSP traffic and signaling > > are already rerouted over the found bypass tunnel. If not, PRR > > R5 activates FRR reroute procedures to direct traffic and > > RSVP Resv over the found bypass tunnel T2 in the > > reverse direction. > > [snip] > > If we write above with a psuedocode, then it will be: > > if (bypass tunnel found) { // “If found” is this line > > check if already rerouted > > if (not already rerouted) { // “If not” is this line > > active FRR reroute > > } > > } > > It might make the texts easier to read/understand if you can rephrase > it a bit? > > Thanks! > > -Nobo > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Dec 24 23:51:54 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B851A874B for ; Wed, 24 Dec 2014 23:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 rjDKffg0vSnX for ; Wed, 24 Dec 2014 23:51:48 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962611A874A for ; Wed, 24 Dec 2014 23:51:47 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-6a-549b70e761c4 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 5A.5C.03307.7E07B945; Thu, 25 Dec 2014 03:05:27 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0195.001; Thu, 25 Dec 2014 02:51:39 -0500 From: Gregory Mirsky To: Loa Andersson , "Rakesh Gandhi (rgandhi)" , "Nobo Akiya (nobo)" , "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org" Thread-Topic: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute Thread-Index: AQHQH/5YrpjNjKgiDky+ptAkRBgJ1Zyf6ZMQ Date: Thu, 25 Dec 2014 07:51:37 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8C7EEB@eusaamb103.ericsson.se> References: <549B978B.6080603@pi.nu> In-Reply-To: <549B978B.6080603@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXSPn+7zgtkhBhfbFS0evj7OYvFv7hxm i9kd8RZTmzrYLFp/7GBxYPWY8nsjq8eSJT+ZPGZNb2Pz+HL5M1sASxSXTUpqTmZZapG+XQJX xu/eV2wFE90rHq/7ydLAuNqsi5GTQ0LARGJV30sWCFtM4sK99WxdjFwcQgJHGCV61n+GcpYz SvxpvcIGUsUmYCTxYmMPO0hCROAno8TDlw1MIAlmAWmJtqtvWUFsYYFgiTNP3gPZHEBFIRKv rvlBmEYSbx4Ig1SwCKhKrJx2F2wkr4CvxNwLTxhBbCEBd4klq3eATeEEqjmz4jo7iM0IdNz3 U2ugNolL3HoynwniaAGJJXvOM0PYohIvH/9jhbCVJOa8vsYMUa8jsWD3JzYIW1ti2cLXzBB7 BSVOznzCMoFRbBaSsbOQtMxC0jILScsCRpZVjBylxalluelGBpsYgVF1TIJNdwfjnpeWhxgF OBiVeHgNeGeHCLEmlhVX5h5ilOZgURLnnVU7L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD 4wLd/GtzD1nEKHl+2jTtF1PLzp5Ph1IE/J01CwQM3Z2aOd+VtIYqTJVcvrvxRyHPf/noo8eE uvm4O2dIe//4bOl9SmTfyh1vJ/9w5z88e85U5mC280Vh3z5Z7rb/FPTjinnMgpr4oxNyVnLE a04ufsH6snhRoIY6m/tPr62bt56ccbviT++b50osxRmJhlrMRcWJALc05XWLAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/teas/YdxnRx8VAdevp-sKEBiLjZGcPXg Cc: TEAS WG Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 07:51:51 -0000 Dear All, I think that node protection mode for bidirectional co-routed LSP FRR is cu= mbersome and, at best, likely cause out-of-order delivery and more service = disruption (switching reverse direction on R5 from R4 onto R3 triggered by = tunneled RSVP Path message). I believe that extension of RFC 4090 for bidir= ectional co-routed LSP FRR is viable only for link protection mode and node= protection must be referred to segment protection and use of RSVP ASSOCIAT= ION object (RFC 4872 and RFC 6689). Without such change in the scope of the= draft I cannot support its adoption by the WG. Regards, Greg -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Wednesday, December 24, 2014 8:50 PM To: Rakesh Gandhi (rgandhi); Nobo Akiya (nobo); draft-tsaad-ccamp-rsvpte-bi= dir-lsp-fastreroute@tools.ietf.org Cc: TEAS WG Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastr= eroute Working Group, I was almost through my review of this document, saw Nobo's review and foun= d that he had found everything I found and a bit more :). With that and with Rakesh's statement that the comments will be addressed I= souppor the adoption of the document as a wg doc. /Loa On 2014-12-25 07:25, Rakesh Gandhi (rgandhi) wrote: > Thank you Nobo for your detailed review comments. > > We will address these in the next revision. > > Happy holidays. > > Thanks, > Rakesh > > > From: "Nobo Akiya (nobo)" > > Date: Wednesday, 24 December, 2014 5:45 PM > To: "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org > " > > > > Cc: TEAS WG > > Subject: Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute > Resent-From: > > Resent-To: "frederic.jounay@orange.ch > " >, "Lizhong com>"=20 > >,=20 > >, "=3DSMTP:mtai= llon@cisco. com" > >, Rakesh Gandhi=20 > >, >, Zafar Ali > > Resent-Date: Wednesday, 24 December, 2014 5:46 PM > > Hi Authors, > > Happy Holidays! > > I read draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 (as part of=20 > its WG adoption poll), and had some questions/comments. Please find them = below. > > 1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT subobject may=20 > be easier to understand if "list" is used. > > [OLD] > > The BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE=20 > object > > prior to adding the node's IP address in the node-ID subobject. A > > node MUST NOT add a BYPASS_ASSIGNMENT subobject without also=20 > adding a > > Node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT=20 > subobject > > without also adding an IPv4 or IPv6 subobject. > > [NEW] > > When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE > > object: > > o The BYPASS_ASSIGNMENT subobject MUST be added prior to the=20 > node-ID > > subobject describing the node's IP address. > > o The Node-ID subobject MUST also be added. > > o The IPv4 or IPv6 subobject MUST also be added. > > 2) Section 4.4.1 - First sentence of the third paragraph was quite=20 > difficult to read/understand. Perhaps adding some commas and=20 > quotations may improve its readability. > > [OLD] > > The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT > > subobject whose bypass tunnel and the node-ID subobject when used=20 > as > > a bypass tunnel source terminates locally assigns the matching > > bidirectional bypass tunnel in the reverse direction, and forwards > > the RSVP Path message downstream. > > [NEW] > > The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT > > subobject, whose bypass tunnel and the node-ID subobject when used=20 > as > > a "bypass tunnel source" terminates locally, assigns the matching > > bidirectional bypass tunnel in the reverse direction, and forwards > > the RSVP Path message downstream. > > 3) Section 4.4.1 - I have a slight concern regarding below statement. > > [snip] > > In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR=20 > does > > not assign a bypass tunnel in the reverse direction. This allows=20 > the > > downstream PLR to always initiate the bypass assignment and=20 > upstream > > PLR to simply reflect the bypass assignment. > > In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT > > subobjects from multiple downstream PLRs, the decision of=20 > selecting a > > bypass tunnel in the reverse direction can be based on local=20 > policy, > > for example, prefer link protection versus node protection bypass > > tunnel, or prefer the most upstream versus least upstream node > > protection bypass tunnel. > > [snip] > > When LSRs within a bidirectional LSP employ different policies, as=20 > described above, then we can result in pockets where there are no=20 > protections. > > For example: > > Node A uses node protection. > > Node B and C use link protection. > > +---------+ > > / +-+ \ > > / / \ \ > > / / v v > > A ----- B ----- C > > ^ / > > \ / > > +-+ > > The result of above is that, in the reverse direction, there will not=20 > be any protection between nodes B and A. > > Another example: > > Node A and C use node protection. > > Node B use link protection. > > +---------+ > > / +-+ \ > > / / \ \ > > / / v v > > A ----- B ----- C > > ^ / > > \ / > > +----------+ > > The result of above is that, in the reverse direction, there will not=20 > be any protection between nodes B and A. > > In both cases, if there is a breakage of the link connecting nodes A=20 > and B, then node C receives the RSVP PATH message. If node C follows=20 > procedures described in Section 6.2, then it will not find a matching=20 > bypass tunnel. > > If I'm off track, then I apologize for the noise. If above is indeed a=20 > problem, then this limitation should at least be described in the=20 > document, followed by a recommendation of all LSRs within a=20 > bidirectional tunnel employing the same policy. > > It may be possible to (be brave and) address this but it will require=20 > more procedures. I'll leave the decision and further investigation to=20 > the authors. > > 4) Section 4.4.1 - Should there be SHOULD or MUST in this paragraph? > > [snip] > > In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR=20 > does > > not assign a bypass tunnel in the reverse direction. This allows=20 > the > > downstream PLR to always initiate the bypass assignment and=20 > upstream > > PLR to simply reflect the bypass assignment. > > [snip] > > I'm guessing that there should be a SHOULD ... > > 5) Section 6.2 - "If" and "If not" in below text do not correspond to=20 > each other (thus a bit confusing). > > [snip] > > - If found, checks whether the primary LSP traffic and=20 > signaling > > are already rerouted over the found bypass tunnel. If not,=20 > PRR > > R5 activates FRR reroute procedures to direct traffic and > > RSVP Resv over the found bypass tunnel T2 in the > > reverse direction. > > [snip] > > If we write above with a psuedocode, then it will be: > > if (bypass tunnel found) { // "If found" is this line > > check if already rerouted > > if (not already rerouted) { // "If not" is this line > > active FRR reroute > > } > > } > > It might make the texts easier to read/understand if you can rephrase=20 > it a bit? > > Thanks! > > -Nobo > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Mon Dec 29 07:00:32 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5061A6FED for ; Mon, 29 Dec 2014 07:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 M1elaQJmex8A for ; Mon, 29 Dec 2014 07:00:29 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 4D0901A6FEA for ; Mon, 29 Dec 2014 07:00:29 -0800 (PST) Received: (qmail 30439 invoked by uid 0); 29 Dec 2014 15:00:25 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy10.mail.unifiedlayer.com with SMTP; 29 Dec 2014 15:00:25 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id ZT061p01w2SSUrH01T09ua; Mon, 29 Dec 2014 08:00:25 -0700 X-Authority-Analysis: v=2.1 cv=Lo0BlBtc c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=xSRs65CQCjkA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=sBqZ53QybVFr9e7iZIYA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=uWHyi+LzRa9D5cVL0R4kqV71ZyYgaFpPXe8JPgZiqY4=; b=tkGPcbzUpjhRgk2TIsFrhREZI2fpwXBXQU1mFw0dXzs9aZgkgyUHQSECsKXyFA2K3W3/aSEx1b834zJVkzWgh82gxeuBwa5JRrCcJ3OQfSXnGXsUG3gz9pdidyRa4wj5; Received: from box313.bluehost.com ([69.89.31.113]:50633 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Y5bni-0000iV-NE; Mon, 29 Dec 2014 08:00:06 -0700 Message-ID: <54A16C71.6080408@labn.net> Date: Mon, 29 Dec 2014 10:00:01 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: TEAS WG References: <548B5DA8.1060700@labn.net> In-Reply-To: <548B5DA8.1060700@labn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/19WtO8oNcPCllA1ksaNFKhNaKDo Cc: draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org Subject: Re: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 15:00:30 -0000 All, This poll is closed. The document has both support to adopted and clearly some work to be done before it is complete -- a good place to sta= rt! Authors, Please republish draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 as draft-ietf-teas-gmpls-lsp-fastreroute-00 without technical changes.=20 Please also, as appropriate, respond to comments received during the poll or, if no discussion is needed, address comments in version -01. Thank you, Lou (and Deborah) On 12/12/2014 4:27 PM, Lou Berger wrote: > All, > > This is start of a two week poll on making > draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a TEAS working group > document. Please send email to the list indicating =93yes/support=94 or= > =93no/do not support=94. If indicating no, please state your technical > reservations with the document. > > The poll ends Friday December 26th. > > Thanks, > > Deborah and Lou > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Mon Dec 29 07:44:31 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7AD1A8770 for ; Mon, 29 Dec 2014 07:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 QlLiHC86fjTH for ; Mon, 29 Dec 2014 07:44:27 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 1210B1A8751 for ; Mon, 29 Dec 2014 07:44:20 -0800 (PST) Received: (qmail 1349 invoked by uid 0); 29 Dec 2014 15:44:19 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 29 Dec 2014 15:44:19 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id ZTk71p00C2SSUrH01TkAYf; Mon, 29 Dec 2014 08:44:18 -0700 X-Authority-Analysis: v=2.1 cv=eOCA0hZ1 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=xSRs65CQCjkA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=NFQB3QJdfZzfAXuP-_IA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=/6ZDX1nGzI7zhV0GenBwzsGXha2XiF/3zyQSeG4RIv4=; b=IPJ+UoZ7R0kHLd3gtW5SS7XRggh5UPb1xZDpB0gGzoRMQKalNySw7C6UfYgZv1SL4wrde/AAa8ILOYw3v3iRpkeoabpNYnh0xa26vv0iIJ7z4vOzrKn/c+GFmP+1EMxl; Received: from box313.bluehost.com ([69.89.31.113]:53227 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Y5cUJ-0007vY-4o; Mon, 29 Dec 2014 08:44:07 -0700 Message-ID: <54A176C2.6040108@labn.net> Date: Mon, 29 Dec 2014 10:44:02 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: draft-ietf-teas-lsp-attribute-ro@tools.ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/bC8v_3Q0m9Ud8gskhdGhCXOECq8 Cc: TEAS WG Subject: [Teas] progressing draft-ietf-teas-lsp-attribute-ro X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 15:44:28 -0000 Authors (WG), I'm the shepherd for this document. I was hoping to put in the publication request for this document today as it would have been nice to have a publication request in 2014! Unfortunately, I see some minor comments that were not addressed from the LC. In particular the ones from Matt (but unfortunately off list -- please don't worry about the abbreviations, the RFC editor will fix if/where needed). When do you expect to have this revision ready? Thanks, Lou PS Matt, If you don't mind, could you summarize the comments you expect to be addressed on the WG list? It would be good for the WG to understand the coming changes and have an opportunity to provide comments if so desired.= From nobody Mon Dec 29 07:58:25 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36E81A882D for ; Mon, 29 Dec 2014 07:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 aBrbi8w61JQy for ; Mon, 29 Dec 2014 07:58:22 -0800 (PST) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id BABB61A87C2 for ; Mon, 29 Dec 2014 07:58:22 -0800 (PST) Received: (qmail 13314 invoked by uid 0); 29 Dec 2014 15:58:17 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy1.mail.unifiedlayer.com with SMTP; 29 Dec 2014 15:58:17 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id ZTy81p0012SSUrH01TyBpK; Mon, 29 Dec 2014 08:58:18 -0700 X-Authority-Analysis: v=2.1 cv=fJeqg/qe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=xSRs65CQCjkA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=JtdKPrM4gIBQURarXsoA:9 a=QEXdDO2ut3YA:10 a=2JOtklbuwVsA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=agOlZoFEIuLHSlGTzbQpFqkOUUZMHgqfvILHsqyzWlI=; b=iKelSlojWbVQQpcsNU/gve6+ScGfOxMmiH9wADY3i+MXIeJdPMWIptkFXHFpKQIH1eeL7qHoMWDRoyjvXM3OavQKStlYvuOTCHJRCavQfSskq3FJKETkbrZ1qoC3G73r; Received: from box313.bluehost.com ([69.89.31.113]:54043 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Y5chq-0002Kz-L4; Mon, 29 Dec 2014 08:58:07 -0700 Message-ID: <54A17A0A.6030305@labn.net> Date: Mon, 29 Dec 2014 10:58:02 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/EIFhFe-7I75Ed1e5CS1rtirD3n0 Cc: TEAS WG Subject: [Teas] progressing draft-ietf-teas-rsvp-te-li-lb X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 15:58:24 -0000 Authors (WG), I'm the shepherd for this document. I was hoping to put in the publication request for this document today as it would have been nice to have a publication request in 2014! Unfortunately, I see some comments that were not addressed from before the LC. In particular, from the thread starting with http://www.ietf.org/mail-archive/web/ccamp/current/threads.html : >From: Dongjie (Jimmy): >... >>From: Lou Berger >... >> WRT section 2.1. Extensions for Lock Instruct: >> - What extension is defined in this subsection. What do you think about >> replacing section 2.1 with something along the lines of? >> >> 2.1. Lock Instruct Indication >> >> In order to indicate the lock/unlock of the LSP, the A >> (Administratively down) bit in ADMIN_STATUS object [RFC3471] >> [RFC3473] is used. >> > > Agree with your suggestion. This could make section 2.1 much clearer. I think this means that the object format and bit definitions are to be removed. >>> Where is the Loopback (B) bit / Attribute Flag defined? This document, right? ... >> This said, you still need to mention where it is defined (e.g., in section 3.1, add >> "defined above" the first time you mention the bit) and add it to the IANA >> section. >Will fix this in the new revision. You still use "(B)" in Section 3.2, but nowhere else. Please replace all instances of "Loopback (B) bit" and "Loopback flag" with "Loopback Attribute Flag". Finally, WRT the discussion on 2119 language, there is also one more "SHOULD" I have a question about: When an LSP is put in lock mode, the subsequent Path and Resv messages SHOULD keep the A bit in ADMIN_STATUS Object set. Why isn't this a "MUST"? That's it, please let us/me know when to expect the next revision. Thank you, Lou From nobody Mon Dec 29 08:26:06 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF441A8857; Mon, 29 Dec 2014 08:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 e_G_UYeQc20x; Mon, 29 Dec 2014 08:26:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9EC1A876D; Mon, 29 Dec 2014 08:26:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141229162603.16559.78794.idtracker@ietfa.amsl.com> Date: Mon, 29 Dec 2014 08:26:03 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/b9loKeOxGu964b07uGkFGivXYPc Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-gmpls-lsp-fastreroute-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 16:26:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Extensions to Resource Reservation Protocol For Fast Reroute of Traffic Engineering GMPLS LSPs Authors : Mike Taillon Tarek Saad Rakesh Gandhi Zafar Ali Manav Bhatia Lizhong Jin Frederic Jounay Filename : draft-ietf-teas-gmpls-lsp-fastreroute-00.txt Pages : 13 Date : 2014-12-29 Abstract: This document defines Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling extensions to support Fast Reroute (FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling extensions allow the coordination of bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these extensions enable the re-direction of bidirectional traffic and signaling onto bypass tunnels that ensure co-routedness of data and signaling paths in the forward and reverse directions after FRR to avoid RSVP soft-state timeout. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-gmpls-lsp-fastreroute-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 29 08:32:10 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0851A8935 for ; Mon, 29 Dec 2014 08:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 tXUl8c7x_gxk for ; Mon, 29 Dec 2014 08:32:04 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C9D1A88EF for ; Mon, 29 Dec 2014 08:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1487; q=dns/txt; s=iport; t=1419870724; x=1421080324; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Eos7rzeUOuvgG+P33lWNULD6+Y/oPewag6UQ+aNd3Zw=; b=WkTNdNS+T5UlhaWroC9zQi2R4BV55+V8KyJhC/eEFcx39qGkjR/LyV9+ fmJkq5XDTheeQi9R5IzN/drVsDvTgwjf+adNju+cvQVYjqXWjes2QOxEn N7Cl42yLyjI20KEaSHVniwKtsV7wgf3Lf1vfbOajVudgApQozxj03Zt6J 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAFuBoVStJV2Q/2dsb2JhbABcgwZSWATGYwqFcwKBDRYBAQEBAX2EDQEBBAEBAWsLEgEIDgpVCyUCBAENBYgsDcJYAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSPFREBUAeEKQWJIYR0iHOBDYJliiWDOSKCMoE8b4EMOX4BAQE X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="380095748" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP; 29 Dec 2014 16:32:03 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sBTGW3LC003294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Dec 2014 16:32:03 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.173]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Mon, 29 Dec 2014 10:32:02 -0600 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document Thread-Index: AQHQFlJeWNEXLVsItkaiNSBPlr4JxpynKC2A///F3wA= Date: Mon, 29 Dec 2014 16:31:35 +0000 Message-ID: In-Reply-To: <54A16C71.6080408@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.82.254.160] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/mPafM84PXn1jUJY8DlHnzBXYcsM Cc: "Mike Taillon \(mtaillon\)" , Manav Bhatia , "frederic.jounay@orange.ch" , "Lizhong com>" , "Tarek Saad \(tsaad\)" , "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org" , "Zafar Ali \(zali\)" Subject: Re: [Teas] Poll on making draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 16:32:08 -0000 Hi Lou, WG, We have uploaded the document with draft-ietf-teas-gmpls-lsp-fastreroute-00 name. Ack, we will address the comments received during the poll. Thanks, Rakesh On 2014-12-29 10:00 AM, "Lou Berger" wrote: >All, > This poll is closed. The document has both support to adopted and >clearly some work to be done before it is complete -- a good place to >start! > >Authors, > Please republish draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 >as draft-ietf-teas-gmpls-lsp-fastreroute-00 without technical changes. >Please also, as appropriate, respond to comments received during the >poll or, if no discussion is needed, address comments in version -01. > >Thank you, >Lou (and Deborah) > >On 12/12/2014 4:27 PM, Lou Berger wrote: >> All, >> >> This is start of a two week poll on making >> draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 a TEAS working group >> document. Please send email to the list indicating =B3yes/support=B2 or >> =B3no/do not support=B2. If indicating no, please state your technical >> reservations with the document. >> >> The poll ends Friday December 26th. >> >> Thanks, >> >> Deborah and Lou >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> > > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas From nobody Mon Dec 29 15:57:56 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727511ACE70; Mon, 29 Dec 2014 15:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 0dCDSAbNhm5j; Mon, 29 Dec 2014 15:57:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A148C1ACE6F; Mon, 29 Dec 2014 15:57:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141229235741.30709.3581.idtracker@ietfa.amsl.com> Date: Mon, 29 Dec 2014 15:57:41 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/jsb4Yhz9j13l10qrrvM7rgCiCSY Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-egress-protection-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 23:57:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Extensions to RSVP-TE for LSP Egress Local Protection Authors : Huaimo Chen Zhenbin Li Ning So Autumn Liu Tarek Saad Fengman Xu Mehmet Toy Lu Huang Lei Liu Filename : draft-ietf-teas-rsvp-egress-protection-00.txt Pages : 16 Date : 2014-12-29 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting egress nodes of a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-egress-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-rsvp-egress-protection-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 29 18:17:14 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2D41ACEC1; Mon, 29 Dec 2014 18:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 G62FjsdnKGEh; Mon, 29 Dec 2014 18:17:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 127D21A9034; Mon, 29 Dec 2014 18:17:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141230021708.9414.98859.idtracker@ietfa.amsl.com> Date: Mon, 29 Dec 2014 18:17:08 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/fhQBzUTu2GPRjEASdB6DiSBkmpY Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 02:17:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : GMPLS RSVP-TE Extensions for Lock Instruct and Loopback Authors : Jie Dong Mach(Guoyi) Chen Zhenqiang Li Daniele Ceccarelli Filename : draft-ietf-teas-rsvp-te-li-lb-01.txt Pages : 8 Date : 2014-12-29 Abstract: This document specifies extensions to Resource Reservation Protocol- Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies which use Generalized Multi-Protocol Label Switching (GMPLS) as control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-li-lb/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-rsvp-te-li-lb-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-li-lb-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 29 18:27:18 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5F01ABC0F for ; Mon, 29 Dec 2014 18:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 iDC-O8ecR7Hs for ; Mon, 29 Dec 2014 18:27:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02CDE1A9034 for ; Mon, 29 Dec 2014 18:27:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQQ01604; Tue, 30 Dec 2014 02:27:12 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 30 Dec 2014 02:27:10 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.128]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 30 Dec 2014 10:27:03 +0800 From: "Dongjie (Jimmy)" To: Lou Berger , "draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org" Thread-Topic: [Teas] progressing draft-ietf-teas-rsvp-te-li-lb Thread-Index: AQHQI4BM8rhPgmrsKEu1O1NWggWFRpynYi8A Date: Tue, 30 Dec 2014 02:27:02 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927337F121B@nkgeml512-mbx.china.huawei.com> References: <54A17A0A.6030305@labn.net> In-Reply-To: <54A17A0A.6030305@labn.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/teas/YAxK2tQr0i-jN8RgaiFuAhdQc48 Cc: TEAS WG Subject: Re: [Teas] progressing draft-ietf-teas-rsvp-te-li-lb X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 02:27:16 -0000 Hi Lou,=20 Thanks a lot for pointing out these comments, I just submitted a new revisi= on (-01) to solve all of them.=20 And please see my replies inline:=20 > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Monday, December 29, 2014 11:58 PM > To: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org > Cc: TEAS WG > Subject: [Teas] progressing draft-ietf-teas-rsvp-te-li-lb >=20 > Authors (WG), > I'm the shepherd for this document. I was hoping to put in the > publication request for this document today as it would have been nice to= have > a publication request in 2014! Unfortunately, I see some comments that we= re > not addressed from before the LC. In particular, from the thread startin= g with > http://www.ietf.org/mail-archive/web/ccamp/current/threads.html : >=20 > >From: Dongjie (Jimmy): > >... > >>From: Lou Berger > >... > >> WRT section 2.1. Extensions for Lock Instruct: > >> - What extension is defined in this subsection. What do you think > >> about replacing section 2.1 with something along the lines of? > >> > >> 2.1. Lock Instruct Indication > >> > >> In order to indicate the lock/unlock of the LSP, the A > >> (Administratively down) bit in ADMIN_STATUS object [RFC3471] > >> [RFC3473] is used. > >> > > > > Agree with your suggestion. This could make section 2.1 much clearer. >=20 > I think this means that the object format and bit definitions are to be r= emoved. Yes, my intention was to remove them, but somehow they were kept in the pre= vious version. Now they are removed. > >>> Where is the Loopback (B) bit / Attribute Flag defined? This > document, right? > ... > >> This said, you still need to mention where it is defined (e.g., in > section 3.1, add > >> "defined above" the first time you mention the bit) and add it to the > IANA > >> section. > >Will fix this in the new revision. >=20 > You still use "(B)" in Section 3.2, but nowhere else. Please replace all = instances > of "Loopback (B) bit" and "Loopback flag" with "Loopback Attribute Flag". Now they are substituted by "Loopback Attribute Flag". > Finally, WRT the discussion on 2119 language, there is also one more "SHO= ULD" > I have a question about: > When an LSP is put in lock mode, the subsequent Path and Resv > messages SHOULD keep the A bit in ADMIN_STATUS Object set. >=20 > Why isn't this a "MUST"? Good catch. Have changed this one and another "SHOULD" in similar case to "= MUST". > That's it, please let us/me know when to expect the next revision. The new revision has just been submitted. Sorry for any inconvenience cause= d. Many thanks, Jie > Thank you, > Lou >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Tue Dec 30 01:06:55 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC6B1A01AE; Tue, 30 Dec 2014 01:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 ikMi1nncfHNk; Tue, 30 Dec 2014 01:06:50 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9810C1A0111; Tue, 30 Dec 2014 01:06:50 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBU96dvJ015053; Tue, 30 Dec 2014 09:06:39 GMT Received: from 950129200 (089144214054.atnat0023.highway.a1.net [89.144.214.54]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBU96beC015034 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2014 09:06:38 GMT From: "Adrian Farrel" To: , References: <20141229225358.20071.64464.idtracker@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E1729C6E785@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C6E785@dfweml706-chm> Date: Tue, 30 Dec 2014 09:06:40 -0000 Message-ID: <026d01d0240f$edd4a5b0$c97df110$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMFBYXgp8QoshBfRDqcSGySstC2gGgrD0wmyLxoFA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21210.006 X-TM-AS-Result: No--5.389-10.0-31-10 X-imss-scan-details: No--5.389-10.0-31-10 X-TMASE-MatchedRID: QfHZjzml1E+31G6CKdUG1VEp96PnqFJs6Pzo2DwBrIo3xO2R3boBWIps 1mGCoqp/ENk7CmZmYLgLt8T2ka0+Ezgcoj/JqpGbzNY33yIEF4b6S5pTqlNeArV5fSMRD1zqPQl KJ9DUxnlnigcbxZqJW6l8sEIkt5BhMXcNC6jzBtqzLnNN4Vs42/qPNYK78GMcM+iVqkzCnQh6ll TJDoR4NZaOK2Lud0lj+6bI4L940xy9m85LuhaMZp1U1lojafr/dnrMZEmwlHR95Y/d46AYrqPFj JEFr+olA6QGdvwfwZZWRVlrjsKO8N0H8LFZNFG7CKFCmhdu5cXiaSq7q1CR1KHG7pdj1earjmll NbWQleW1q3udMon7r55R1IOVeba76mePORsCuuOfAnGokBfMGpQwcUqXtBKkoP+nu2xyeMoJAp5 AN4f59Q+9NXX1QIs7ki/Tr7VHGv3uvg+PNpx4a56oP1a0mRIj Archived-At: http://mailarchive.ietf.org/arch/msg/teas/9mJ6zR-9W8R2WZMTJY3zkTEdwYI Cc: 'Leeyoung' Subject: Re: [Teas] New Version Notification - draft-ietf-ccamp-general-constraint-encode-16.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 09:06:52 -0000 All [Re-sending to CCAMP, which was Young's intention, I think. Adding = TEAS] I've requested the Secretariat to start the IETF last call. Please *do* = comment if any of Young's changes gives you an issue. We'll treat your = comments as last call comments. Thanks. Adrian > -----Original Message----- > From: Leeyoung [mailto:leeyoung@huawei.com] > Sent: 29 December 2014 23:06 > To: internet-drafts@ietf.org; ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp- > general-constraint-encode@tools.ietf.org; adrian@olddog.co.uk > Subject: RE: New Version Notification - = draft-ietf-ccamp-general-constraint- > encode-16.txt >=20 > Hi CCAMPers, >=20 > The revision has a wire behavior change of a field Conn (Connection = Type) from 8 > bits to 4 bits per AD's suggestion. > Please see Section 2.1 for this change. >=20 > Other changes are mostly editorial and improvement for clarity = (Section 2.4/2.5 > for LSP setup/pre-emption rules). > We'd appreciate your review and comment (support or not). >=20 > Thanks, Happy new year! > Young >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, December 29, 2014 4:54 PM > To: ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-general-constraint- > encode@tools.ietf.org; adrian@olddog.co.uk > Subject: New Version Notification - = draft-ietf-ccamp-general-constraint-encode- > 16.txt >=20 >=20 > A new version (-16) has been submitted for = draft-ietf-ccamp-general-constraint- > encode: > = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-general-constraint- > encode-16.txt >=20 > Sub state has been changed to AD Followup from Revised ID Needed >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > = https://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-enco= de/ >=20 > Diff from previous version: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-general-constraint-en= code-16 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > IETF Secretariat. From nobody Tue Dec 30 08:15:42 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB83F1A0004 for ; Tue, 30 Dec 2014 08:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 0RBpbTFEKbeJ for ; Tue, 30 Dec 2014 08:15:35 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 912671A000B for ; Tue, 30 Dec 2014 08:15:34 -0800 (PST) Received: (qmail 31200 invoked by uid 0); 30 Dec 2014 16:15:27 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 30 Dec 2014 16:15:27 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id ZsFK1p00z2SSUrH01sFNgD; Tue, 30 Dec 2014 09:15:27 -0700 X-Authority-Analysis: v=2.1 cv=eOCA0hZ1 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=xSRs65CQCjkA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=NwP7oIszpxyU6WMrjvAA:9 a=pILNOxqGKmIA:10 a=2JOtklbuwVsA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=N6yv+MpNnD8tjsdeXcC5TVacG7fEWbrcB352t8NSm74=; b=E7jh0KgX2Sp0SRBrz3Ms/pc+UKDSp6cGL4Gj9up9OqLnErJ8N9Am/13AMiQcL1knU+ubcF8YKYB4fMnjpOM/kcf3Oso+JmufuRWg0vPpkPCnsULxd2f14iRLrC4fCdYs; Received: from box313.bluehost.com ([69.89.31.113]:46057 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Y5zS3-0005Z1-Ss; Tue, 30 Dec 2014 09:15:20 -0700 Message-ID: <54A2CF92.7050604@labn.net> Date: Tue, 30 Dec 2014 11:15:14 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Dongjie (Jimmy)" , "draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org" References: <54A17A0A.6030305@labn.net> <76CD132C3ADEF848BD84D028D243C927337F121B@nkgeml512-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927337F121B@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/UsVPKCsD1hjwRt-xy6GrLlWnhXI Cc: TEAS WG Subject: Re: [Teas] progressing draft-ietf-teas-rsvp-te-li-lb X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 16:15:41 -0000 Kudos on the very fast response! Thank you, Lou On 12/29/2014 9:27 PM, Dongjie (Jimmy) wrote: > Hi Lou, > > Thanks a lot for pointing out these comments, I just submitted a new revision (-01) to solve all of them. > > And please see my replies inline: > >> -----Original Message----- >> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger >> Sent: Monday, December 29, 2014 11:58 PM >> To: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org >> Cc: TEAS WG >> Subject: [Teas] progressing draft-ietf-teas-rsvp-te-li-lb >> >> Authors (WG), >> I'm the shepherd for this document. I was hoping to put in the >> publication request for this document today as it would have been nice to have >> a publication request in 2014! Unfortunately, I see some comments that were >> not addressed from before the LC. In particular, from the thread starting with >> http://www.ietf.org/mail-archive/web/ccamp/current/threads.html : >> >>> From: Dongjie (Jimmy): >>> ... >>>> From: Lou Berger >>> ... >>>> WRT section 2.1. Extensions for Lock Instruct: >>>> - What extension is defined in this subsection. What do you think >>>> about replacing section 2.1 with something along the lines of? >>>> >>>> 2.1. Lock Instruct Indication >>>> >>>> In order to indicate the lock/unlock of the LSP, the A >>>> (Administratively down) bit in ADMIN_STATUS object [RFC3471] >>>> [RFC3473] is used. >>>> >>> Agree with your suggestion. This could make section 2.1 much clearer. >> I think this means that the object format and bit definitions are to be removed. > Yes, my intention was to remove them, but somehow they were kept in the previous version. Now they are removed. > >>>>> Where is the Loopback (B) bit / Attribute Flag defined? This >> document, right? >> ... >>>> This said, you still need to mention where it is defined (e.g., in >> section 3.1, add >>>> "defined above" the first time you mention the bit) and add it to the >> IANA >>>> section. >>> Will fix this in the new revision. >> You still use "(B)" in Section 3.2, but nowhere else. Please replace all instances >> of "Loopback (B) bit" and "Loopback flag" with "Loopback Attribute Flag". > Now they are substituted by "Loopback Attribute Flag". > >> Finally, WRT the discussion on 2119 language, there is also one more "SHOULD" >> I have a question about: >> When an LSP is put in lock mode, the subsequent Path and Resv >> messages SHOULD keep the A bit in ADMIN_STATUS Object set. >> >> Why isn't this a "MUST"? > Good catch. Have changed this one and another "SHOULD" in similar case to "MUST". > >> That's it, please let us/me know when to expect the next revision. > The new revision has just been submitted. Sorry for any inconvenience caused. > > Many thanks, > Jie > >> Thank you, >> Lou >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas From nobody Tue Dec 30 08:40:55 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEBA1A0338 for ; Tue, 30 Dec 2014 08:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 C0zBbstceFKw for ; Tue, 30 Dec 2014 08:40:53 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11B21A02F1 for ; Tue, 30 Dec 2014 08:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1614; q=dns/txt; s=iport; t=1419957653; x=1421167253; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OltGwIF8aIOhaDBEYRmNLaKQiGZ1o/k5x9MTxPfapSQ=; b=WR+j+fLgRC+G1Jy62HCW/Gk7rSVQkH8mkUnemLGY56+1wppjEfMKH2Rm hZ6Fg3Kw0KuOjKwgHOKtgxNxlDssieYv9UJ6xmQtmtPHiBNK6TrAlsIxr YOggVNSqVf4c6nL1kNhP8geJAwKfog5UPIbS3PqH3skuYA2va9gEQ4gpd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFADHVolStJV2P/2dsb2JhbABcgwaBLsxLAoEIFgEBAQEBfYQNAQEDAScTPwULAgEIDhQUEDIlAgQBDQ2IHAjFIAEBAQEBAQEBAQEBAQEBAQEBAQEBARePRjEHgxaBEwEEjhWaQyKDboI0fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,666,1413244800"; d="scan'208";a="383369062" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP; 30 Dec 2014 16:40:40 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sBUGecmW032716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Dec 2014 16:40:39 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.169]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 30 Dec 2014 10:40:38 -0600 From: "Matt Hartley (mhartley)" To: Lou Berger , "draft-ietf-teas-lsp-attribute-ro@tools.ietf.org" Thread-Topic: [Teas] progressing draft-ietf-teas-lsp-attribute-ro Thread-Index: AQHQI35XrTCwmzYbdUK+ZxwzeqDmT5yoU4KA Date: Tue, 30 Dec 2014 16:40:38 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC289CC9C1@xmb-rcd-x03.cisco.com> References: <54A176C2.6040108@labn.net> In-Reply-To: <54A176C2.6040108@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/ogemppE5GAiCgAwdrR_-2KC5_r0 Cc: "Matt Hartley \(mhartley\)" , TEAS WG Subject: Re: [Teas] progressing draft-ietf-teas-lsp-attribute-ro X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 16:40:54 -0000 > PS Matt, > If you don't mind, could you summarize the comments you expect to be > addressed on the WG list? It would be good for the WG to understand the > coming changes and have an opportunity to provide comments if so desired. My comments to be addressed. This isn't a complete list of the comments I a= ctually made; there were a couple more that won't be addressed for one reas= on or another, which I'm OK with. Section 1: " Explicit Route (ERO) object" -> "Explicit Route object (ERO)" Section 1.1 is empty. Section 2: expand SERO (first use) Section 3.1: expand OF (first use) Section 3.1: reserved bits... why have you specified that the MUST be set t= o 0 on transmission? Isn't it more usual to say that this SHOULD be done (i= f only to allow for future use for the field)? Also: "when a node process t= he ERO" -> "when a node processes the ERO". Section 4.1: reserved bits... same comments as for 3.1. 4.2.1: "pair of Subobject" -> "pair of Subobjects" 4.2.1: expand LSR (first use) 4.2.3: "Head end nodes not supporting the RRO_HOP_ATTRIBUTE will drop the i= nformation." - presumably this is a backward-compatibility note, so it migh= t be an idea to specify where this behavior is defined (RFC3209 section-4.4= .5). Also: "Head end" -> "Ingress"? Isn't that the usual term? On my comment on MUST vs SHOULD for setting reserved bits to 0 on transmiss= ion: Cyril did a lot of looking through other RFCs and it seems that there'= s no real consensus on the right thing to do here, so I'm OK with leaving i= t as it stands. Cheers Matt From nobody Tue Dec 30 08:53:05 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96491A036F for ; Tue, 30 Dec 2014 08:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 MHyN4ohlGMXs for ; Tue, 30 Dec 2014 08:52:51 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id E984A1A037A for ; Tue, 30 Dec 2014 08:52:50 -0800 (PST) Received: (qmail 1099 invoked by uid 0); 30 Dec 2014 16:52:50 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 30 Dec 2014 16:52:50 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id Zssm1p0042SSUrH01sspN6; Tue, 30 Dec 2014 09:52:50 -0700 X-Authority-Analysis: v=2.1 cv=Lo0BlBtc c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=xSRs65CQCjkA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=UeoEX90uDBPaYJ9EFXkA:9 a=QEXdDO2ut3YA:10 a=ORRGVvHr8bUA:10 a=shEa1P4w-rsA:10 a=cGCMCpMrLPIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=lw1UC5I93dDaWwvjrYkeNmv5tdC93NRD8varNCKsuyU=; b=I+a41LLjmYWz/KLkwwX5ZZmGmAYHd3+qwe32wcyNRfIneQmsw6k3Hshh9PZx6rrISb7DSu6/RmAfFGrXxLHGRJxsrgOKDNcYNGz7IsbVqmcQ26TEAYBv7n2ad/7YhV/j; Received: from box313.bluehost.com ([69.89.31.113]:48353 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Y602H-0002ao-Tx for teas@ietf.org; Tue, 30 Dec 2014 09:52:46 -0700 Message-ID: <54A2D854.1020908@labn.net> Date: Tue, 30 Dec 2014 11:52:36 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: TEAS WG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/g4JGCZ6J_JHN-HCj5kOQq20i-e4 Subject: [Teas] 1st TEAS Publication request - draft-ietf-teas-rsvp-te-li-lb-01 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 16:52:58 -0000 All, The publication request for draft-ietf-teas-rsvp-te-li-lb-01 has been submitted via datatracker. If interested, take a look at: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-li-lb/ Happy New Year! Lou From nobody Wed Dec 31 09:57:57 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6F51A9121; Wed, 31 Dec 2014 09:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 7UWvdsm1hBGC; Wed, 31 Dec 2014 09:57:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EF61A0363; Wed, 31 Dec 2014 09:57:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141231175752.10527.33025.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 09:57:52 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/dhJ5z0HcuV96MDHjjOyo0943QS8 Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-lsp-attribute-ro-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 17:57:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : LSP Attribute in ERO Authors : Cyril Margaria Giovanni Martinelli Steve Balls Ben Wright Filename : draft-ietf-teas-lsp-attribute-ro-01.txt Pages : 11 Date : 2014-12-31 Abstract: RFC5420 extends RSVP-TE to specify or record generic attributes which apply to the whole of the path of an LSP. This document proposes an extension to the RSVP ERO and RRO objects to allow it to specify or record generic attributes which apply to a given hop. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-lsp-attribute-ro-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 31 10:03:48 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D58E1A0379 for ; Wed, 31 Dec 2014 10:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ZGUQl55ePwyC for ; Wed, 31 Dec 2014 10:03:43 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0321A1A0372 for ; Wed, 31 Dec 2014 10:03:42 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so25898372wiv.14 for ; Wed, 31 Dec 2014 10:03:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RhW3ECh47XGsg7vbYM8ezQY6fsQNMmTLf9w52/I6qpw=; b=yE310U7avWGIM3wAdsLuaJQOEYrkvGDjc7KKTo4rsnLeR+Dn8tp9OwpZ85IabbXUHA f5I7osoGe2AFylCq9vy19sGFVcajzdvDMfTyXQi/LGGna1oJgB5WNHozTk7+DCcNJE28 Y3q9p4IXJfdOjQaPDomc1aB6MPkjeu4S6LBuUR4ho8Gxwa7nl7NpS+P/CBs6f9HGasJs Fi5dvIR33TgqNU+jQIvbPGRLbwo9FeXzHgKY6mVujK+idwdCEoe6ni5c8AgLn6jLMsqm k3hqwwTs+lc5P+Bb7kYBX4K3TAtZUnjjIFSEDvUeDGlcE2Fba5KM+2MnOcV+e7XcNY47 ObPQ== MIME-Version: 1.0 X-Received: by 10.180.21.225 with SMTP id y1mr19969270wie.42.1420049021671; Wed, 31 Dec 2014 10:03:41 -0800 (PST) Received: by 10.27.89.133 with HTTP; Wed, 31 Dec 2014 10:03:41 -0800 (PST) In-Reply-To: <20141231175752.10527.33025.idtracker@ietfa.amsl.com> References: <20141231175752.10527.33025.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 13:03:41 -0500 Message-ID: From: Cyril Margaria To: Lou Berger , draft-ietf-teas-lsp-attribute-ro@tools.ietf.org, Matt Hartley , Dhruv Dhody , teas@ietf.org Content-Type: multipart/alternative; boundary=047d7bb70988801f53050b86ed40 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/27JAx7pRnCXwESEWYHIKWFhspwc Subject: [Teas] Fwd: I-D Action: draft-ietf-teas-lsp-attribute-ro-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 18:03:46 -0000 --047d7bb70988801f53050b86ed40 Content-Type: text/plain; charset=UTF-8 Hi, The following version integrates all the LC review comments. The changes are mainly editorial. Best Regards, Happy New Year Cyril Margaria ---------- Forwarded message ---------- From: Date: 31 December 2014 at 12:57 Subject: I-D Action: draft-ietf-teas-lsp-attribute-ro-01.txt To: i-d-announce@ietf.org Cc: teas@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : LSP Attribute in ERO Authors : Cyril Margaria Giovanni Martinelli Steve Balls Ben Wright Filename : draft-ietf-teas-lsp-attribute-ro-01.txt Pages : 11 Date : 2014-12-31 Abstract: RFC5420 extends RSVP-TE to specify or record generic attributes which apply to the whole of the path of an LSP. This document proposes an extension to the RSVP ERO and RRO objects to allow it to specify or record generic attributes which apply to a given hop. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-lsp-attribute-ro-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --047d7bb70988801f53050b86ed40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

The f= ollowing version integrates all the LC review comments.
The change= s are mainly editorial.

Best Regards,
Happy New Year=
Cyril Margaria



---------- Forwarded message ----------
From: <internet-drafts@ietf.org>=
Date: 31 December 2014 at 12:57
Subject: I-D Action: draft-ietf-teas= -lsp-attribute-ro-01.txt
To: i-d-announce@ietf.org
Cc: teas@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Traffic Engineering Architecture and= Signaling Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= LSP Attribute in ERO
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Cyri= l Margaria
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Giovanni Martinelli
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Steve Balls
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ben Wright
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-teas-lsp-attribute-ro-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-12-31

Abstract:
=C2=A0 =C2=A0RFC5420 extends RSVP-TE to specify or record generic attribute= s which
=C2=A0 =C2=A0apply to the whole of the path of an LSP.=C2=A0 This document = proposes an
=C2=A0 =C2=A0extension to the RSVP ERO and RRO objects to allow it to speci= fy or
=C2=A0 =C2=A0record generic attributes which apply to a given hop.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-= attribute-ro/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-= ro-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tea= s-lsp-attribute-ro-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--047d7bb70988801f53050b86ed40-- From nobody Wed Dec 31 11:47:53 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A47C1A1A58 for ; Wed, 31 Dec 2014 11:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 UC4nEG3VSm_S for ; Wed, 31 Dec 2014 11:47:51 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 62E8B1A1A56 for ; Wed, 31 Dec 2014 11:47:51 -0800 (PST) Received: (qmail 6983 invoked by uid 0); 31 Dec 2014 19:47:50 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 31 Dec 2014 19:47:50 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id aKnn1p00d2SSUrH01KnqaF; Wed, 31 Dec 2014 12:47:50 -0700 X-Authority-Analysis: v=2.1 cv=BvIOn+n5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZDBkZx-UmFUA:10 a=kj9zAlcOel0A:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=OivZS1VFXtoA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=TbTkganAATKIaXNKLlUA:9 a=CjuIK1q_8ugA:10 a=iHI339dtj1oA:10 a=O3jCxFIDNLYA:10 a=uuXcTBWz4w0A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:In-Reply-To:Message-ID:Date:To:From; bh=j3bIsYIFuUIfFCOUgcdOxT+m2UPJSP/cqZSX01NpvMU=; b=YAaS8+JjbCG3QGKxnQtELAZyypJZpykgrBns3EKI6Pgi2a7ygUajce9Pgmj8QOJfKSDaHEQTY7KkxV6mvO5nUXM9qIzHU+GX3Mgt2VicMOLuAAiIu1RESCbY2BvJ3peI; Received: from [172.56.3.84] (port=60257 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Y6PFD-0007st-E1 for teas@ietf.org; Wed, 31 Dec 2014 12:47:47 -0700 From: Lou Berger To: TEAS WG Date: Wed, 31 Dec 2014 14:47:46 -0500 Message-ID: <14aa1e3b330.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <54A3FB38.70604@labn.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.1.9 (build: 2102009) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.56.3.84 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/teas/DiR5Zak0t13mHEwRl2CsYxe8pqU Subject: [Teas] TEAS Publication request - draft-ietf-teas-lsp-attribute-ro-01 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 19:47:52 -0000 All, The publication request for draft-ietf-teas-lsp-attribute-ro-01 has been submitted via datatracker. If interested, take a look at: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/ Happy New Year! Lou From nobody Wed Dec 31 12:23:33 2014 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604571A1AC7; Wed, 31 Dec 2014 12:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 WnqMZ2svDXy8; Wed, 31 Dec 2014 12:23:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBF31A1AB9; Wed, 31 Dec 2014 12:23:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141231202329.9252.52362.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 12:23:29 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/LQmKj_ddVNBxl4h9lru-GncmTfc Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 20:23:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Extensions to RSVP-TE for LSP Ingress Local Protection Authors : Huaimo Chen Raveendra Torvi Filename : draft-ietf-teas-rsvp-ingress-protection-00.txt Pages : 23 Date : 2014-12-31 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-ingress-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-rsvp-ingress-protection-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/