From nobody Mon Aug 4 01:07:12 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B8A1B28AD for ; Mon, 4 Aug 2014 01:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 9FJ_bazyXdOM for ; Mon, 4 Aug 2014 01:07:04 -0700 (PDT) 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 F0EB91B286C for ; Mon, 4 Aug 2014 01:07:03 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s74870KY013967 for ; Mon, 4 Aug 2014 09:07:00 +0100 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 s7486x5A013958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 4 Aug 2014 09:07:00 +0100 From: "Adrian Farrel" To: Subject: Code Points, Internet-Drafts, and Early Implementation Date: Mon, 4 Aug 2014 09:07:05 +0100 Message-ID: <03e601cfafbb$15356640$3fa032c0$@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: Ac+vuqkehEixRUQvSoGSNOSLIM4XMw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20858.006 X-TM-AS-Result: No--3.410-10.0-31-10 X-imss-scan-details: No--3.410-10.0-31-10 X-TMASE-MatchedRID: H2YtPLBkOQ/MHUInqqZ02mivjLE8DPtZfS0Ip2eEHny+qryzYw2E8M4b ajgO0kgvgZK4jdUf7rULbigRnpKlKZx+7GyJjhAU6iKhBxgq1Bdb3gkB0QBhXYiGLF+Qy97xyLh ncyHF5mP9bzoC408/QTztFzjbmDGGqHQ+DYZXNwG0FnfILcTQLWY9sEVWBgnY9HmAsM11v0u45m jKIIYY3xiCad9aBKWfm9p/RC99TJ5Lhb8xGEnVfg== Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/HOsBpXnWzN3G2SRsWtjnfDelV_c X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 08:07:10 -0000 I added some text to the Routing Area Wiki on the use of code points in Internet-Drafts. http://trac.tools.ietf.org/area/rtg/trac/wiki/WikiStart Adrian From nobody Thu Aug 7 02:18:56 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DACE1B2A1E; Thu, 7 Aug 2014 02:18:52 -0700 (PDT) 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 FSINBby3URKa; Thu, 7 Aug 2014 02:18:50 -0700 (PDT) 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 A87DC1B2966; Thu, 7 Aug 2014 02:18:49 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s779Ik24022668; Thu, 7 Aug 2014 10:18:47 +0100 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 s779Ie7b022554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Aug 2014 10:18:40 +0100 From: "Adrian Farrel" To: , , Subject: FW: [Anima] ANIMA draft charter Date: Thu, 7 Aug 2014 10:18:44 +0100 Message-ID: <00e501cfb220$96ec9b60$c4c5d220$@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: Ac+yIJXnSb9CvN3lQke+XTLssv1IYg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20864.006 X-TM-AS-Result: No--40.121-10.0-31-10 X-imss-scan-details: No--40.121-10.0-31-10 X-TMASE-MatchedRID: D2G27ZgZra/YMEqhScrQBUhEDfw/93BuH181YDtIVapF+YXPIqAdvrMj 3GAElQGEHWONFZT/prr3YiuFkZiOxGResrHRY7dK8eSmTJSmEv2S3G9UxpYxsMoNup+2nV/XmkL u0+871bV2HZRu5knIkaCQCfo/jPYbVd/GARVyJ51GypC5CVFOH978NWlYojkr2viB/Jr4D1TNCc A6Zdzj70jpvQu/TgjHcP8NoorbT3V1KobyH4zskSe1T5r1VA3IyeUl7aCTy8jczkKO5k4APhZZd YKgpK9DdxS9fNW9kSZLqpudr4MRIM/BlZO+W2WhtNMyJ72jQd22awxxVfk3ByWy0DEOFuGQ3ogi kAEqSiqRLq2ylp66OeDz4wU7tmbcvXtlm87JVdowiJTf3kjwfaGuPOIOnqBBS5TspQkQ8sGOytA lmFixKqYoxrZu+cZeaw6jvnhkER4dSjum6JPhtyZm6wdY+F8KguwtqyXlE6EhvFjBsLEZNEJb3b 5D8E1yCs950MJfLPLBdLgSSOxM9wnW8iiCcRSGiFoorQjboWkZYA38gj3BxOVs8DNq02hCeIJ7x 1WhBehKW3Ex8kbLqbLDlVGk98URY+SEAY1Jo3eJQ9k+Ypk5CcLiFiL0BG1uEd+K6O5Nt53zb5km gp405bfqHaErmu92kZOl7WKIImq0P2qkGU0XylZ0V5tYhzdWxEHRux+uk8jpP8tMOyYmaA== Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/uW_NnK_DMRT3tobkyZVFq-n2dc4 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 09:18:52 -0000 Please excuse the spam. There is a discussion about forming a working group for autonomic networking that may be of interest to a number of you. Please continue the discussion on the ANIMA mailing list (i.e., not here!) Thanks, Adrian > -------- Original Message -------- > Subject: [Anima] ANIMA draft charter > Date: Tue, 5 Aug 2014 08:19:15 +0000 > From: Michael Behringer (mbehring) > To: anima@ietf.org > > At the BoF in Toronto there was rough consensus to continue the work on an > autonomic infrastructure. Brian, Sheng, Toerless, > Laurent and I have now drafted a potential WG charter with the input of our ADs. > Note that this is not yet a formal charter > proposal, it's for discussion only so far. > > The assumption is that more general aspects of autonomics will continue to be > discussed in the NMRG group. > > If we were to go ahead with a WG, the goal would be to focus on realistic > deliverables. So the plan is to start with a small, > achievable set of deliverables, and, if successful and useful, expand after re- > chartering. > > Please comment here on this draft charter proposal. > > Thanks, > Michael > > > Autonomic Networking Integrated Model and Approach (ANIMA) WG > > Description of Working Group > > Autonomic Networking focuses on self-management of network elements. An > autonomic function works in a distributed way across > various network elements, allowing however central guidance and reporting. > Autonomic functions already exist today, for example > IGP routing protocols such as OSPF. However, all such functions have their own > discovery, transport, messaging and security > mechanisms. > > To transform the somewhat abstract Autonomic Networking concept into > concrete, realisable requirements, the first stage, > undertaken in the Network Management Research Group (NMRG) of the IRTF, > was to define terminology and design goals, and to > derive a high-level gap analysis. The definitions and design goals, as well as a > simple architecture model are defined in > draft-irtf-nmrg-autonomic-network-definitions; the gap analysis for AN is > described in draft-irtf-nmrg-an-gap-analysis. The UCAN > BoF at IETF 90 discussed use cases and some existing solutions. All the above > work serves as a baseline for this working group. > > This working group defines solutions for an initial set of components of an > autonomic networking infrastructure, based on the > simple architecture and design goals defined in draft-irtf-nmrg-autonomic- > network-definitions. Future work may include a more > detailed systems architecture to support the development of autonomic service > agents. The Anima working group will initially > focus on enterprise, ISP networks and IoT. > > The solutions target to cover the following areas: > o identity of nodes > o common security model > o discovery model > o negotiation model > o a secure and logically separated communications channel > o an example for an autonomic management model > > The goals of this working group are: > > o Definition of a generic discovery and negotiation protocol for autonomic > functions > Starting point: draft-jiang-config-negotiation-protocol > o Definition of a mechanism to bootstrap a trust infrastructure > Starting point: draft-pritikin-bootstrapping-keyinfrastructures > o Definition of an logically separated Autonomic Control Plane > Starting point: draft-behringer-autonomic-control-plane > > In addition, autonomic service agents will need to be defined for specific use > cases. The working group will initially consider > one simple example as a test case for further work. > > o Definition of > Starting point: draft-use-case-tbd > > The initial set of work items is limited to the above list to stay focused and avoid > "boiling the ocean". Additional documents > concerning policy intent, other autonomic infrastructure components, use cases > or autonomic service agents are strongly > encouraged, as individual submissions, but are not planned as working group > deliverables for now. No additional work items will > be accepted in the working group without re-chartering. > > Milestones > > Nov 2014 - WG formation and adoption of drafts > - Mar IETF - > Jun 2015 - WGLC for draft-generic-discovery-negotiation-protocol > - Jul IETF - > Aug 2015 - submit draft-generic-discovery-negotiation-protocol to IESG > (standards track) > Oct 2015 - WGLC draft-keyinfrastructure-bootstrap > Oct 2015 - WGLC draft-use-case-tbd > - Nov IETF - > Dec 2015 - submit draft-keyinfrastructure-bootstrap to IESG (standards track) > Dec 2015 - submit draft-use-case-tbd to IESG (standards track) > Jan 2016 - WGLC draft-autonomic-common-control-plane > - Mar IETF - > Apr 2016 - submit draft-autonomic-common-control-plane to IESG (standards > track) > Jul 2016 - recharter if needed, or close > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Aug 7 03:35:02 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD911B27E5; Thu, 7 Aug 2014 03:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 4eUFQTN2Ft5t; Thu, 7 Aug 2014 03:34:57 -0700 (PDT) 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 1D1B81A00EA; Thu, 7 Aug 2014 03:34:57 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 4777EA6B5A27B; Thu, 7 Aug 2014 10:34:53 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s77AYpF4019688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Aug 2014 12:34:54 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 7 Aug 2014 12:34:51 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: "adrian@olddog.co.uk" , "routing-discussion@ietf.org" , "manet@ietf.org" , "roll@ietf.org" Subject: RE: [Anima] ANIMA draft charter Thread-Topic: [Anima] ANIMA draft charter Thread-Index: Ac+yIJXnSb9CvN3lQke+XTLssv1IYgAA85og Date: Thu, 7 Aug 2014 10:34:50 +0000 Message-ID: <84675BAA8C49154AB81E2587BE8BDF83234331DF@FR711WXCHMBA07.zeu.alcatel-lucent.com> References: <00e501cfb220$96ec9b60$c4c5d220$@olddog.co.uk> In-Reply-To: <00e501cfb220$96ec9b60$c4c5d220$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/0sURL9pH62hFyNmL0KYd6kZNDeE X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 10:35:00 -0000 Hi Adrian, all Thanks for sharing. Reading this charter, the following statement escapes m= e "Autonomic functions already exist today, for example IGP routing protocols= such as OSPF." I would have said OSPF like any other IGP is adaptive (and from the current= state only -not previous states-) but it is not autonomous: the same input= leads to the same output (decision), i.e., there is no improvement of qual= ity of the decision process over time and on the other hand there is no mea= n by which OSPF can by itself overcome degradation of performance (at best = mitigate if pre-configured to execute fixed sequences for a sub-set of pre-= determined conditions, cf.RFC 4222, so again driven by open control loops). Setting of configurable constants is mainly driven by open control loops. M= oreover individual routers can't make autonomous decisions in terms of area= parameters configuration as all routers belonging to an area must agree on= that area's configuration). Thanks, -dimitri. > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On > Behalf Of Adrian Farrel > Sent: Thursday, August 07, 2014 11:19 AM > To: routing-discussion@ietf.org; manet@ietf.org; roll@ietf.org > Subject: FW: [Anima] ANIMA draft charter >=20 > Please excuse the spam. >=20 > There is a discussion about forming a working group for autonomic > networking that may be of interest to a number of you. >=20 > Please continue the discussion on the ANIMA mailing list (i.e., not here!= ) >=20 > Thanks, > Adrian >=20 > > -------- Original Message -------- > > Subject: [Anima] ANIMA draft charter > > Date: Tue, 5 Aug 2014 08:19:15 +0000 > > From: Michael Behringer (mbehring) > > To: anima@ietf.org > > > > At the BoF in Toronto there was rough consensus to continue the work > > on an autonomic infrastructure. Brian, Sheng, Toerless, Laurent and I > > have now drafted a potential WG charter with the input of our > ADs. > > Note that this is not yet a formal charter proposal, it's for > > discussion only so far. > > > > The assumption is that more general aspects of autonomics will > > continue to be discussed in the NMRG group. > > > > If we were to go ahead with a WG, the goal would be to focus on > > realistic deliverables. So the plan is to start with a small, > > achievable set of deliverables, and, if successful and useful, expand > > after > re- > > chartering. > > > > Please comment here on this draft charter proposal. > > > > Thanks, > > Michael > > > > > > Autonomic Networking Integrated Model and Approach (ANIMA) WG > > > > Description of Working Group > > > > Autonomic Networking focuses on self-management of network elements. > > An autonomic function works in a distributed way across various > > network elements, allowing however central guidance and reporting. > > Autonomic functions already exist today, for example IGP routing > > protocols such as OSPF. However, all such functions have their own > > discovery, transport, messaging and security mechanisms. > > > > To transform the somewhat abstract Autonomic Networking concept into > > concrete, realisable requirements, the first stage, undertaken in the > > Network Management Research Group (NMRG) of the IRTF, was to define > > terminology and design goals, and to derive a high-level gap analysis. > > The definitions and design goals, as well as > a > > simple architecture model are defined in > > draft-irtf-nmrg-autonomic-network-definitions; the gap analysis for AN > > is described in draft-irtf-nmrg-an-gap-analysis. The UCAN BoF at IETF > > 90 discussed use cases and some existing solutions. All the above work > > serves as a baseline for this working group. > > > > This working group defines solutions for an initial set of components > > of an autonomic networking infrastructure, based on the simple > > architecture and design goals defined in draft-irtf-nmrg-autonomic- > > network-definitions. Future work may include a more detailed systems > > architecture to support the development of autonomic service agents. > > The Anima working group will initially focus on enterprise, ISP > > networks and IoT. > > > > The solutions target to cover the following areas: > > o identity of nodes > > o common security model > > o discovery model > > o negotiation model > > o a secure and logically separated communications channel o an example > > for an autonomic management model > > > > The goals of this working group are: > > > > o Definition of a generic discovery and negotiation protocol for > > autonomic functions > > Starting point: draft-jiang-config-negotiation-protocol > > o Definition of a mechanism to bootstrap a trust infrastructure > > Starting point: draft-pritikin-bootstrapping-keyinfrastructures > > o Definition of an logically separated Autonomic Control Plane > > Starting point: draft-behringer-autonomic-control-plane > > > > In addition, autonomic service agents will need to be defined for > > specific use cases. The working group will initially consider one > > simple example as a test case for further work. > > > > o Definition of > > Starting point: draft-use-case-tbd > > > > The initial set of work items is limited to the above list to stay > > focused and > avoid > > "boiling the ocean". Additional documents concerning policy intent, > > other autonomic infrastructure components, use cases or autonomic > > service agents are strongly encouraged, as individual submissions, but > > are not planned as working group deliverables for now. No additional > > work items will be accepted in the working group without > > re-chartering. > > > > Milestones > > > > Nov 2014 - WG formation and adoption of drafts > > - Mar IETF - > > Jun 2015 - WGLC for draft-generic-discovery-negotiation-protocol > > - Jul IETF - > > Aug 2015 - submit draft-generic-discovery-negotiation-protocol to IESG > > (standards track) Oct 2015 - WGLC draft-keyinfrastructure-bootstrap > > Oct 2015 - WGLC draft-use-case-tbd > > - Nov IETF - > > Dec 2015 - submit draft-keyinfrastructure-bootstrap to IESG > > (standards track) Dec 2015 - submit draft-use-case-tbd to IESG > > (standards track) Jan 2016 - WGLC draft-autonomic-common-control-plane > > - Mar IETF - > > Apr 2016 - submit draft-autonomic-common-control-plane to IESG > > (standards > > track) > > Jul 2016 - recharter if needed, or close > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Wed Aug 13 12:30:39 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579E21A066A for ; Wed, 13 Aug 2014 12:30:35 -0700 (PDT) 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 4pz9kdY2kZ0T for ; Wed, 13 Aug 2014 12:30:34 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 3E1B61A0679 for ; Wed, 13 Aug 2014 12:30:26 -0700 (PDT) Received: (qmail 4478 invoked by uid 0); 13 Aug 2014 19:30:17 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 13 Aug 2014 19:30:17 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id eRWB1o00q2SSUrH01RWECu; Wed, 13 Aug 2014 19:30:16 -0600 X-Authority-Analysis: v=2.1 cv=KvHehwmN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=oEG3kIKJLzwA:10 a=_1-nmO3vHs0A:10 a=HFCU6gKsb0MA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=48vgC7mUAAAA:8 a=82PJw7FNzwLkxu7pL1wA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA: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=eh8zkBHQhWJA43eyeowwRDpHgGkIxendvO/OgdpGCiE=; b=sLo049PetJSESzaieFyuZsdtfxIYZF963/tjI8psjZkQx4wt393+hB683mymFuVdfdIBZCJj0mNcRYce4rHAUbVZluyMZrb1vo1fOWfbAayr11xti2YfT4DfNpMecFcc; Received: from box313.bluehost.com ([69.89.31.113]:55635 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XHeFR-0006E9-62; Wed, 13 Aug 2014 13:30:13 -0600 Message-ID: <53EBBD01.5000505@labn.net> Date: Wed, 13 Aug 2014 15:31:13 -0400 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: Adrian Farrel , Alia Atlas Subject: Re: Summary of RTG Tuning as presented to IESG/IAB References: <067e01cfa83a$54cca120$fe65e360$@olddog.co.uk> In-Reply-To: <067e01cfa83a$54cca120$fe65e360$@olddog.co.uk> 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/routing-discussion/7Xt0t0e9CCPwsXAT8xCuI_aHM5E Cc: IESG , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 19:30:35 -0000 Hi Adrian, I've been struggling a bit with the process around your routing reorganization plan and how to broach this topic. It really has struck me that it has been developed without much transparency (the first public discussion was in the Toronto routing area meeting, without any public advance notice), or public indication of consensus (the only public discussion otook place in the rtg meeting and the plan was presented as a feit accompli) . I personally am fine with some changes, think others can be really helpful once refined a bit, and others I'm less sure of. But I think all changes should be made as part of a publicly discussed plan that has explicit community consensus; even if it is rough and even if the resulting plan is identical to what you presented as *the plan*. I guess my question boils down to shouldn't there be some public discussion of the plan to gauge its consensus? (even the change to the IETF mail list has had more public discussion!) Perhaps a different question is does anyone else care? I know that there is presure to get these changes in place quickly, and as mentioned in the lunch meeting, the goal is to complete all changes before a new AD is installed in your place, but it seems to me that the plan should have sufficient merit and consensus to withstand a change in leadership. =20 Thanks, Lou On 7/25/2014 2:57 PM, Adrian Farrel wrote: > Hi, > > I just presented a summary of our discussions about tuning the work-spl= it in > Routing to bring the IESG and IAB up to speed. > > Here it is for your information. Do please continue to discuss and shar= e this as > you see fit. > > Thanks for all the input received so far. > > Remember that until these changes are implemented, all work should cont= inue as > currently. > > Adrian > > =3D=3D=3D=3D > > Wide discussion and some sort of general agreementishiness > - Mailing lists > - Chairs/Directorate lunch > - Area meeting > - Corridors > > ADs' opinions and proposals were modified by discussion > > All current work remains in the Area > > All WG I-Ds will remain as WG I-Ds > > No new work at the moment > > Same number of WGs in the Area > > 12 WGs completely unchanged > > 2 minor tweaks > - PIM has more multicast oversight > - RTGWG has stronger Dispatch element > > Merge and shuffle to achieve 6 WGs > - BGP Enabled ServiceS (L3VPN, L2VPN, NVO3) BESS > - Pseudowire- and LDP-enabled Services (L2VPN, PWE3) PALS > - Traffic Engineering Architecture and Signaling (MPLS, CCAMP) TEAS > - CCAMP (CCAMP minus TEAS) > - MPLS (MPLS minus TEAS) > - NVO3 (NVO3 minus BESS) > > Plan of action > - Starting to think about chairs now > - Starting to draft charters now > - Plan to have changes up and running before IETF-91 > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > From nobody Wed Aug 20 07:49:32 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC73C1A0435 for ; Wed, 20 Aug 2014 07:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 GDXO6_7IkH_H for ; Wed, 20 Aug 2014 07:49:26 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FCBD1A03F0 for ; Wed, 20 Aug 2014 07:49:26 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id f73so7006924yha.31 for ; Wed, 20 Aug 2014 07:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ujomLwM4VaNznfMi+O5z8OdCymLhAGmRQQnabsG3+2M=; b=frI1/n+VzuCeF0kFhDXl9DViALw3G2pTb7bFo3+S4Lk63EkpmUbdy1UHka42dGQZ/Q L/D6f8zHkVKR6dMT7IlqgWIOL5t3teF8hF7WvAAHzsISVzE2GW2bt5MPgrFoHhVb2s1+ pMj8BXya1bUzFdC42ZPNIYhzEqg3c9h92r8sY0/B5fPscz7ffhkhJd65oecpVr/aDUUs 4SzPSr1mx4navodUMMoEgdl4SG1dJHTWVGY02lxXOcLh47Lcp27QJRmr11H1aoefGL77 mPnI9j0zdydyI0JA+/VgTrmWFdPG3+4IGJfEVZEfPRJenVvD7dctTTSIxCBMr5sP99Xa 4PZQ== MIME-Version: 1.0 X-Received: by 10.236.85.208 with SMTP id u56mr74878484yhe.48.1408546165394; Wed, 20 Aug 2014 07:49:25 -0700 (PDT) Received: by 10.170.110.17 with HTTP; Wed, 20 Aug 2014 07:49:25 -0700 (PDT) Date: Wed, 20 Aug 2014 10:49:25 -0400 Message-ID: Subject: WG Document QA process starting From: Alia Atlas To: "routing-discussion@ietf.org" Content-Type: multipart/alternative; boundary=20cf301af725d692ea050110b5f5 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/DKIYA3nrl2ezMX8Wfx0Zim79Gsg X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 14:49:28 -0000 --20cf301af725d692ea050110b5f5 Content-Type: text/plain; charset=UTF-8 Before and at IETF 90, we talked briefly about a new WG Document QA process that is intended to better use the routing directorate and get drafts reviewed earlier when significant improvements can be made. The wiki - specifically http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa - has all the details. We have requested that routing WG chairs start using this process now. There has already been some limited use. Regards, Alia --20cf301af725d692ea050110b5f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Before and at IETF 90, we talked briefly about a new WG Do= cument QA process that is intended to better use the routing directorate an= d get drafts reviewed earlier when significant improvements can be made.

W= e have requested that routing WG chairs start using this process now. =C2= =A0There has already been some limited use.

Regards,
Alia
--20cf301af725d692ea050110b5f5-- From nobody Wed Aug 20 15:07:52 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5611A6F01 for ; Wed, 20 Aug 2014 15:07:49 -0700 (PDT) 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 AoOqzv1Z0GWP for ; Wed, 20 Aug 2014 15:07:48 -0700 (PDT) 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 120B01A88E5 for ; Wed, 20 Aug 2014 15:07:47 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7KM7j5m015099; Wed, 20 Aug 2014 23:07:45 +0100 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 s7KM7i5S015089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Aug 2014 23:07:45 +0100 From: "Adrian Farrel" To: Subject: Routing Area Tuning - Update Date: Wed, 20 Aug 2014 23:07:42 +0100 Message-ID: <062701cfbcc3$2a295470$7e7bfd50$@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: Ac+8wyZusCFJ/2FATmmqnraiOjiHgQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20896.002 X-TM-AS-Result: No--15.479-10.0-31-10 X-imss-scan-details: No--15.479-10.0-31-10 X-TMASE-MatchedRID: AlsypQZbPISZXNuktGfA3ARH1Nr7oERdQKuv8uQBDjq7jklbuYgxDTLK vDBLmbBL3SakDUqFzYxQYegAD7HgpG1yv+64My/esBytgTF4TTQPiDnjK8eHs9qCxkzSpW/Xp40 t/vZty62AC3k2f/VWs/4Kft5IABRvdZWYmHGqGYhDP8uRDLPyZqgkPVIChYLxsp5O052MzLqTzZ tVqb05Wn4yPuTaUthvzAcm/EXvOrT1zIImtiPm1RmCYUYerLHrbt2yH3SWiGElP1vFxquW9nw93 dJCnn/PEeRlhKGK96cCL8NcleO++3Cfn8/a/bc1KWuiyZLRI4ArHkgIan9a0ckuAmnh0RPz+F2Q r5gL+Cri8zVgXoAltlwtzewu2M635MIx11wv+COQZS2ujCtcuA== Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/86GbZLV5MQRME8jAz1wAzhbaTPw X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 22:07:50 -0000 Hi, I wanted to take a moment to update you all on our progress and to poll you for some more opinions. Firstly there is a sense that this may all be a fait accompli with there being no point in raising any questions or concerns. I'm sorry if this is how it came over. The ADs have been thinking about this and discussing it for quite a while and we spent quite a bit of time before and during IETF 90 seeking out different viewpoints and having our opinions shaped. So we have built up strong views, but we do want to hear your views and we particularly want to be told what we have got wrong. One question we are still thinking about concerns the arrangement of TE-related work across the MPLS, CCAMP, and PCE working groups. An option we had discussed resulted in PCE unchanged, TEAS to take TE architecture and RSVP-TE, and CCAMP to do technology-specific protocol work. But there is another option which would leave: TEAS - TE architecture and requirement work, but no protocol work PCE - All PCEP work, PCE applicability and requirements, but PCE architecture goes to TEAS RSVP-TE - All generic protocol work for RSVP-TE from MPLS and CCAMP CCAMP - technology-specific protocol work. This thinking is somewhat motivated by the way the IGP work happens at the moment and somewhat by the thought that TEAS might be too large and have too many distractions if it has protocol and architecture, while the motivation for keeping architecture and protocol together in TEAS is that it provides for better energy and interaction. We would like to hear your opinions and get a better sense of the consensus around TEAS. At the moment Alia and I are recovering from Toronto and handling vacations, but we have formed a rough order for working on the working groups. First up is the RTGWG because that is a relatively straightforward tweak to an existing charter. Then we plan to group together {L2VPN, L3VPN, PWE3, NVO3} becoming {PALS, BESS, NVO3} Then we will look to work out how to handle the TE elements discussed above. We'll be taking a bit of a two-pronged approach: identify chair candidates; spin up draft charters. We plan to work on the draft charters with the future chairs and put them out on this list and on the relevant WG mailing lists as soon as we have them with the aim of getting review and discussion. One last point. All WGs should continue to operate according to their current charters. We can handle the transition if/when it happens, but this work should not get in the way of real technical work. Please let us know what you think. Adrian, per pro Alia From nobody Wed Aug 20 15:15:32 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3871A8935 for ; Wed, 20 Aug 2014 15:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 EBJlV-VjfhoM for ; Wed, 20 Aug 2014 15:15:24 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FFC1A8944 for ; Wed, 20 Aug 2014 15:15:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 6B2AC80754; Wed, 20 Aug 2014 15:15:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-198.clppva.east.verizon.net [70.106.135.198]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9D4DA80751; Wed, 20 Aug 2014 15:15:23 -0700 (PDT) Message-ID: <53F51DF9.5090703@joelhalpern.com> Date: Wed, 20 Aug 2014 18:15:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, routing-discussion@ietf.org Subject: Re: Routing Area Tuning - Update References: <062701cfbcc3$2a295470$7e7bfd50$@olddog.co.uk> In-Reply-To: <062701cfbcc3$2a295470$7e7bfd50$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/1ySHwBFWDkDhEB7Sx7tnzJy4rCo X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 22:15:30 -0000 I am a little concerned that the proposed approach has TEAS doing the requirements for work to be done as protocol in other WGs. While we made that work, for very good reasons, in KARP, it is frequently a source of friction and hinderance. Yours, Joel On 8/20/14, 6:07 PM, Adrian Farrel wrote: > Hi, > > I wanted to take a moment to update you all on our progress and to poll you for > some more opinions. > > Firstly there is a sense that this may all be a fait accompli with there being > no point in raising any questions or concerns. I'm sorry if this is how it came > over. The ADs have been thinking about this and discussing it for quite a while > and we spent quite a bit of time before and during IETF 90 seeking out different > viewpoints and having our opinions shaped. So we have built up strong views, but > we do want to hear your views and we particularly want to be told what we have > got wrong. > > One question we are still thinking about concerns the arrangement of TE-related > work across the MPLS, CCAMP, and PCE working groups. An option we had discussed > resulted in PCE unchanged, TEAS to take TE architecture and RSVP-TE, and CCAMP > to do technology-specific protocol work. But there is another option which would > leave: > TEAS - TE architecture and requirement work, but no protocol work > PCE - All PCEP work, PCE applicability and requirements, but PCE architecture > goes to TEAS > RSVP-TE - All generic protocol work for RSVP-TE from MPLS and CCAMP > CCAMP - technology-specific protocol work. > This thinking is somewhat motivated by the way the IGP work happens at the > moment and somewhat by the thought that TEAS might be too large and have too > many distractions if it has protocol and architecture, while the motivation for > keeping architecture and protocol together in TEAS is that it provides for > better energy and interaction. > > We would like to hear your opinions and get a better sense of the consensus > around TEAS. > > At the moment Alia and I are recovering from Toronto and handling vacations, but > we have formed a rough order for working on the working groups. > > First up is the RTGWG because that is a relatively straightforward tweak to an > existing charter. > Then we plan to group together {L2VPN, L3VPN, PWE3, NVO3} becoming {PALS, BESS, > NVO3} > Then we will look to work out how to handle the TE elements discussed above. > > We'll be taking a bit of a two-pronged approach: identify chair candidates; spin > up draft charters. > We plan to work on the draft charters with the future chairs and put them out on > this list and on the relevant WG mailing lists as soon as we have them with the > aim of getting review and discussion. > > One last point. All WGs should continue to operate according to their current > charters. We can handle the transition if/when it happens, but this work should > not get in the way of real technical work. > > Please let us know what you think. > > Adrian, > per pro Alia > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > From nobody Wed Aug 20 16:12:55 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7D91A023F for ; Wed, 20 Aug 2014 16:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 3NjjODM2ZG-l for ; Wed, 20 Aug 2014 16:12:49 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 5F7C61A01F3 for ; Wed, 20 Aug 2014 16:12:49 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id C4A4FF24ABE4A; Wed, 20 Aug 2014 23:12:43 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s7KNCkcA021936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Aug 2014 01:12:47 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 21 Aug 2014 01:12:46 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: "Joel M. Halpern" , "adrian@olddog.co.uk" , "routing-discussion@ietf.org" Subject: RE: Routing Area Tuning - Update Thread-Topic: Routing Area Tuning - Update Thread-Index: Ac+8wyZusCFJ/2FATmmqnraiOjiHgf//4KKA///YTUA= Date: Wed, 20 Aug 2014 23:12:46 +0000 Message-ID: <84675BAA8C49154AB81E2587BE8BDF832343F219@FR711WXCHMBA07.zeu.alcatel-lucent.com> References: <062701cfbcc3$2a295470$7e7bfd50$@olddog.co.uk> <53F51DF9.5090703@joelhalpern.com> In-Reply-To: <53F51DF9.5090703@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/x-241IQf2dHcM_GTpCr_l5gJ2lE X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 23:12:51 -0000 Hi Adrian,=20 It remembers me the TEWG approach; there were additional considerations at = that time also but IETF being an organization which produces protocols (oft= en bottom-up) and info/data-models if a working group has none of them in i= ts direct scope, this approach puts them from the start in a difficult posi= tion. On the other hand, limiting CCAMP to techno-specifics (and disconnect= them from TE) looks to me as the replay of the IPO WG (that ended in Atlan= ta 2002 in the general indifference). This being said, have you considered the following Include TEAS activities in CCAMP (as the latter is mostly about TE) ? and t= hen a set of protocol groups PCEP, Generic TE Routing protocols (IGP-TE + R= SVP-TE), MPLS + LDP --note it doesn't change the number of working groups. Thanks, -dimitri. > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On > Behalf Of Joel M. Halpern > Sent: Thursday, August 21, 2014 12:15 AM > To: adrian@olddog.co.uk; routing-discussion@ietf.org > Subject: Re: Routing Area Tuning - Update >=20 > I am a little concerned that the proposed approach has TEAS doing the > requirements for work to be done as protocol in other WGs. While we made > that work, for very good reasons, in KARP, it is frequently a source of > friction and hinderance. >=20 > Yours, > Joel >=20 > On 8/20/14, 6:07 PM, Adrian Farrel wrote: > > Hi, > > > > I wanted to take a moment to update you all on our progress and to > > poll you for some more opinions. > > > > Firstly there is a sense that this may all be a fait accompli with > > there being no point in raising any questions or concerns. I'm sorry > > if this is how it came over. The ADs have been thinking about this and > > discussing it for quite a while and we spent quite a bit of time > > before and during IETF 90 seeking out different viewpoints and having > > our opinions shaped. So we have built up strong views, but we do want > > to hear your views and we particularly want to be told what we have got > wrong. > > > > One question we are still thinking about concerns the arrangement of > > TE-related work across the MPLS, CCAMP, and PCE working groups. An > > option we had discussed resulted in PCE unchanged, TEAS to take TE > > architecture and RSVP-TE, and CCAMP to do technology-specific protocol > > work. But there is another option which would > > leave: > > TEAS - TE architecture and requirement work, but no protocol work > > PCE - All PCEP work, PCE applicability and requirements, but PCE > architecture > > goes to TEAS > > RSVP-TE - All generic protocol work for RSVP-TE from MPLS and CCAMP > > CCAMP - technology-specific protocol work. > > This thinking is somewhat motivated by the way the IGP work happens at > > the moment and somewhat by the thought that TEAS might be too large > > and have too many distractions if it has protocol and architecture, > > while the motivation for keeping architecture and protocol together > > in TEAS is that it provides for better energy and interaction. > > > > We would like to hear your opinions and get a better sense of the > > consensus around TEAS. > > > > At the moment Alia and I are recovering from Toronto and handling > > vacations, but we have formed a rough order for working on the working > groups. > > > > First up is the RTGWG because that is a relatively straightforward > > tweak to an existing charter. > > Then we plan to group together {L2VPN, L3VPN, PWE3, NVO3} becoming > > {PALS, BESS, NVO3} Then we will look to work out how to handle the TE > > elements discussed above. > > > > We'll be taking a bit of a two-pronged approach: identify chair > > candidates; spin up draft charters. > > We plan to work on the draft charters with the future chairs and put > > them out on this list and on the relevant WG mailing lists as soon as > > we have them with the aim of getting review and discussion. > > > > One last point. All WGs should continue to operate according to their > > current charters. We can handle the transition if/when it happens, but > > this work should not get in the way of real technical work. > > > > Please let us know what you think. > > > > Adrian, > > per pro Alia > > > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > > https://www.ietf.org/mailman/listinfo/routing-discussion > > >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Thu Aug 21 07:31:24 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF2C1A038F for ; Thu, 21 Aug 2014 07:31:14 -0700 (PDT) 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 65n1uIvI87QO for ; Thu, 21 Aug 2014 07:31:09 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509DC1A031A for ; Thu, 21 Aug 2014 07:31:09 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id m20so9429571qcx.10 for ; Thu, 21 Aug 2014 07:31:08 -0700 (PDT) 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=VU71s8dRHOvWmVZ27kQ/I9lm9Y7oA+HHYJsk5mP53xc=; b=BV56UpsaOZ4W+JK4H1rwsCFrMT4j1ySEFDx7Zt1kYqKfeBzC1bwPE9+sWh5atXyTBq gWa005eoCkC7VEQSE38MpgwVsjVfmhz4MiJvAcUOccj1MvZ5QQT7wDgwE96WC0iYbaF+ EzYiGiCA+bhD2IeFyQncFom0HRqC611b+HRD0owupk3SI68NrQO2pnrwr+BkEC54t3/Q 0lhg2FWfMl95tbpwWGYwRCnhYpBJcbJmJReWM4X0IAi3mSWhkAQP1MowmY2ICn7VzD0c PR/BjfJ+DBOLGDtlz7yzaMiGtZrH90EjW7LDkMVXT427J4A/iW2WOmjqxcdg13qtqj8A KQkg== X-Received: by 10.224.79.139 with SMTP id p11mr87355294qak.93.1408631468197; Thu, 21 Aug 2014 07:31:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.91.99 with HTTP; Thu, 21 Aug 2014 07:30:48 -0700 (PDT) In-Reply-To: <53F51DF9.5090703@joelhalpern.com> References: <062701cfbcc3$2a295470$7e7bfd50$@olddog.co.uk> <53F51DF9.5090703@joelhalpern.com> From: "Andrew G. Malis" Date: Thu, 21 Aug 2014 10:30:48 -0400 Message-ID: Subject: Re: Routing Area Tuning - Update To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=047d7bdc801a4816e005012492dc Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/qtP3PMc_I-cxpRRx50BUsfR_8LA Cc: Adrian Farrel , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:31:15 -0000 --047d7bdc801a4816e005012492dc Content-Type: text/plain; charset=UTF-8 I agree with Joel - I think people find it hard to get motivated to do the architecture and requirements if they also don't get to play around with the protocols (the fun stuff), while the people doing the protocol work also want their input into the architecture and requirements, since the choices made there constrain what the protocol will look like. Of course, you could have the same people tramping between two different WGs, but that seems silly. Cheers, Andy On Wed, Aug 20, 2014 at 6:15 PM, Joel M. Halpern wrote: > I am a little concerned that the proposed approach has TEAS doing the > requirements for work to be done as protocol in other WGs. While we made > that work, for very good reasons, in KARP, it is frequently a source of > friction and hinderance. > > Yours, > Joel > > > On 8/20/14, 6:07 PM, Adrian Farrel wrote: > >> Hi, >> >> I wanted to take a moment to update you all on our progress and to poll >> you for >> some more opinions. >> >> Firstly there is a sense that this may all be a fait accompli with there >> being >> no point in raising any questions or concerns. I'm sorry if this is how >> it came >> over. The ADs have been thinking about this and discussing it for quite a >> while >> and we spent quite a bit of time before and during IETF 90 seeking out >> different >> viewpoints and having our opinions shaped. So we have built up strong >> views, but >> we do want to hear your views and we particularly want to be told what we >> have >> got wrong. >> >> One question we are still thinking about concerns the arrangement of >> TE-related >> work across the MPLS, CCAMP, and PCE working groups. An option we had >> discussed >> resulted in PCE unchanged, TEAS to take TE architecture and RSVP-TE, and >> CCAMP >> to do technology-specific protocol work. But there is another option >> which would >> leave: >> TEAS - TE architecture and requirement work, but no protocol work >> PCE - All PCEP work, PCE applicability and requirements, but PCE >> architecture >> goes to TEAS >> RSVP-TE - All generic protocol work for RSVP-TE from MPLS and CCAMP >> CCAMP - technology-specific protocol work. >> This thinking is somewhat motivated by the way the IGP work happens at the >> moment and somewhat by the thought that TEAS might be too large and have >> too >> many distractions if it has protocol and architecture, while the >> motivation for >> keeping architecture and protocol together in TEAS is that it provides >> for >> better energy and interaction. >> >> We would like to hear your opinions and get a better sense of the >> consensus >> around TEAS. >> >> At the moment Alia and I are recovering from Toronto and handling >> vacations, but >> we have formed a rough order for working on the working groups. >> >> First up is the RTGWG because that is a relatively straightforward tweak >> to an >> existing charter. >> Then we plan to group together {L2VPN, L3VPN, PWE3, NVO3} becoming {PALS, >> BESS, >> NVO3} >> Then we will look to work out how to handle the TE elements discussed >> above. >> >> We'll be taking a bit of a two-pronged approach: identify chair >> candidates; spin >> up draft charters. >> We plan to work on the draft charters with the future chairs and put them >> out on >> this list and on the relevant WG mailing lists as soon as we have them >> with the >> aim of getting review and discussion. >> >> One last point. All WGs should continue to operate according to their >> current >> charters. We can handle the transition if/when it happens, but this work >> should >> not get in the way of real technical work. >> >> Please let us know what you think. >> >> Adrian, >> per pro Alia >> >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion >> >> > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > --047d7bdc801a4816e005012492dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Joel - I think people find it hard to get mot= ivated to do the architecture and requirements if they also don't get t= o play around with the protocols (the fun stuff), while the people doing th= e protocol work also want their input into the architecture and requirement= s, since the choices made there constrain what the protocol will look like.= Of course, you could have the same people tramping between two different W= Gs, but that seems silly.

Cheers,
Andy



On Wed, Aug 20, 2014 at= 6:15 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
I am a little concerned that the proposed ap= proach has TEAS doing the requirements for work to be done as protocol in o= ther WGs.=C2=A0 While we made that work, for very good reasons, in KARP, it= is frequently a source of friction and hinderance.

Yours,
Joel


On 8/20/14, 6:07 PM, Adrian Farrel wrote:
Hi,

I wanted to take a moment to update you all on our progress and to poll you= for
some more opinions.

Firstly there is a sense that this may all be a fait accompli with there be= ing
no point in raising any questions or concerns. I'm sorry if this is how= it came
over. The ADs have been thinking about this and discussing it for quite a w= hile
and we spent quite a bit of time before and during IETF 90 seeking out diff= erent
viewpoints and having our opinions shaped. So we have built up strong views= , but
we do want to hear your views and we particularly want to be told what we h= ave
got wrong.

One question we are still thinking about concerns the arrangement of=C2=A0 = TE-related
work across the MPLS, CCAMP, and PCE working groups. An option we had discu= ssed
resulted in PCE unchanged, TEAS to take TE architecture and RSVP-TE, and CC= AMP
to do technology-specific protocol work. But there is another option which = would
leave:
=C2=A0 =C2=A0 TEAS - TE architecture and requirement work, but no protocol = work
=C2=A0 =C2=A0 PCE - All PCEP work, PCE applicability and requirements, but = PCE architecture
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goes to TEAS
=C2=A0 =C2=A0 RSVP-TE - All generic protocol work for RSVP-TE from MPLS and= CCAMP
=C2=A0 =C2=A0 CCAMP - technology-specific protocol work.
This thinking is somewhat motivated by the way the IGP work happens at the<= br> moment and somewhat by the thought that TEAS might be too large and have to= o
many distractions if it has protocol and architecture, while the motivation= for
keeping=C2=A0 architecture and protocol together in TEAS is that it provide= s for
better energy and interaction.

We would like to hear your opinions and get a better sense of the consensus=
around TEAS.

At the moment Alia and I are recovering from Toronto and handling vacations= , but
we have formed a rough order for working on the working groups.

First up is the RTGWG because that is a relatively straightforward tweak to= an
existing charter.
Then we plan to group together {L2VPN, L3VPN, PWE3, NVO3} becoming {PALS, B= ESS,
NVO3}
Then we will look to work out how to handle the TE elements discussed above= .

We'll be taking a bit of a two-pronged approach: identify chair candida= tes; spin
up draft charters.
We plan to work on the draft charters with the future chairs and put them o= ut on
this list and on the relevant WG mailing lists as soon as we have them with= the
aim of getting review and discussion.

One last point. All WGs should continue to operate according to their curre= nt
charters. We can handle the transition if/when it happens, but this work sh= ould
not get in the way of real technical work.

Please let us know what you think.

Adrian,
per pro Alia

_______________________________________________
routing-discussion mailing list
routing-di= scussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion=


_______________________________________________
routing-discussion mailing list
routing-di= scussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion=

--047d7bdc801a4816e005012492dc-- From nobody Thu Aug 21 07:40:07 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AAD1A88EF for ; Thu, 21 Aug 2014 07:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 yLl8cULX3Ybf for ; Thu, 21 Aug 2014 07:40:02 -0700 (PDT) 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 5A2671A0334 for ; Thu, 21 Aug 2014 07:40:02 -0700 (PDT) Received: from [192.168.0.166] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id EB21E1802244 for ; Thu, 21 Aug 2014 16:40:00 +0200 (CEST) Message-ID: <53F604C0.6090704@pi.nu> Date: Thu, 21 Aug 2014 16:40:00 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: routing-discussion@ietf.org Subject: Re: Routing Area Tuning - Update References: <062701cfbcc3$2a295470$7e7bfd50$@olddog.co.uk> <53F51DF9.5090703@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/SztFg7OESao9OSQD6SAx2GgFM84 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:40:05 -0000 Folks, I agree with Andy and Joel, having had RSVP-TE split between two working groups, not along requirements and protocol, but along what they would be used for has been a strength. MPLS did requirements and protocol for "packet", while CCAMP did it for "GMPLS". That places the architectural issues as a coordination point between two wg, but that coordination was never hard. I understand that this could be taken as an argument to push MPLS and CCAMP back to where they were. But we have running code that this works. /Loa On 2014-08-21 16:30, Andrew G. Malis wrote: > I agree with Joel - I think people find it hard to get motivated to do > the architecture and requirements if they also don't get to play around > with the protocols (the fun stuff), while the people doing the protocol > work also want their input into the architecture and requirements, since > the choices made there constrain what the protocol will look like. Of > course, you could have the same people tramping between two different > WGs, but that seems silly. > > Cheers, > Andy > > > > On Wed, Aug 20, 2014 at 6:15 PM, Joel M. Halpern > wrote: > > I am a little concerned that the proposed approach has TEAS doing > the requirements for work to be done as protocol in other WGs. > While we made that work, for very good reasons, in KARP, it is > frequently a source of friction and hinderance. > > Yours, > Joel > > > On 8/20/14, 6:07 PM, Adrian Farrel wrote: > > Hi, > > I wanted to take a moment to update you all on our progress and > to poll you for > some more opinions. > > Firstly there is a sense that this may all be a fait accompli > with there being > no point in raising any questions or concerns. I'm sorry if this > is how it came > over. The ADs have been thinking about this and discussing it > for quite a while > and we spent quite a bit of time before and during IETF 90 > seeking out different > viewpoints and having our opinions shaped. So we have built up > strong views, but > we do want to hear your views and we particularly want to be > told what we have > got wrong. > > One question we are still thinking about concerns the > arrangement of TE-related > work across the MPLS, CCAMP, and PCE working groups. An option > we had discussed > resulted in PCE unchanged, TEAS to take TE architecture and > RSVP-TE, and CCAMP > to do technology-specific protocol work. But there is another > option which would > leave: > TEAS - TE architecture and requirement work, but no > protocol work > PCE - All PCEP work, PCE applicability and requirements, > but PCE architecture > goes to TEAS > RSVP-TE - All generic protocol work for RSVP-TE from MPLS > and CCAMP > CCAMP - technology-specific protocol work. > This thinking is somewhat motivated by the way the IGP work > happens at the > moment and somewhat by the thought that TEAS might be too large > and have too > many distractions if it has protocol and architecture, while the > motivation for > keeping architecture and protocol together in TEAS is that it > provides for > better energy and interaction. > > We would like to hear your opinions and get a better sense of > the consensus > around TEAS. > > At the moment Alia and I are recovering from Toronto and > handling vacations, but > we have formed a rough order for working on the working groups. > > First up is the RTGWG because that is a relatively > straightforward tweak to an > existing charter. > Then we plan to group together {L2VPN, L3VPN, PWE3, NVO3} > becoming {PALS, BESS, > NVO3} > Then we will look to work out how to handle the TE elements > discussed above. > > We'll be taking a bit of a two-pronged approach: identify chair > candidates; spin > up draft charters. > We plan to work on the draft charters with the future chairs and > put them out on > this list and on the relevant WG mailing lists as soon as we > have them with the > aim of getting review and discussion. > > One last point. All WGs should continue to operate according to > their current > charters. We can handle the transition if/when it happens, but > this work should > not get in the way of real technical work. > > Please let us know what you think. > > Adrian, > per pro Alia > > _________________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/__listinfo/routing-discussion > > > > _________________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/__listinfo/routing-discussion > > > > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Aug 21 07:45:36 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7F41A0323 for ; Thu, 21 Aug 2014 07:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.867 X-Spam-Level: X-Spam-Status: No, score=-4.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 mzZ8T4C0x_yC for ; Thu, 21 Aug 2014 07:45:33 -0700 (PDT) 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 0C6D81A031A for ; Thu, 21 Aug 2014 07:45:32 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id d0606f35.2b7306e1e940.5909494.00-2476.16524206.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 21 Aug 2014 14:45:33 +0000 (UTC) X-MXL-Hash: 53f6060d7c8f2a80-5548bebdd8f02b468860f3c37dc66f5149ddf236 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 30606f35.0.5909340.00-1979.16523746.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 21 Aug 2014 14:45:23 +0000 (UTC) X-MXL-Hash: 53f6060354ba12a3-1a4b4c862307d0871847ce884aefda6e6f93232d 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 s7LEjLpf005844; Thu, 21 Aug 2014 10:45:22 -0400 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 s7LEjA7S005719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Aug 2014 10:45:13 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 21 Aug 2014 14:44:56 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.149]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0195.001; Thu, 21 Aug 2014 10:44:56 -0400 From: "BRUNGARD, DEBORAH A" To: "Andrew G. Malis" , "Joel M. Halpern" Subject: RE: Routing Area Tuning - Update Thread-Topic: Routing Area Tuning - Update Thread-Index: Ac+8wyZusCFJ/2FATmmqnraiOjiHgQAIpvaAACIRNAAACBou0A== Date: Thu, 21 Aug 2014 14:44:55 +0000 Message-ID: References: <062701cfbcc3$2a295470$7e7bfd50$@olddog.co.uk> <53F51DF9.5090703@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.226] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8153F28DEMISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=PalIcFdd c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=pR15HSHCFqAA:10 a=ufBpKkTJRMAA:10 a=ofMgfj31e3cA:10 a=0dz] X-AnalysisOut: [XkfIBmA4A:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=ABeY7kuGAAAA:8 a=4PUqd97yPPA7J5f] X-AnalysisOut: [FKsMA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=chC_agHSu74A] X-AnalysisOut: [:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:10 a=] X-AnalysisOut: [UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsn] X-AnalysisOut: [liwV7b4A:10 a=dpSI0z7ShJ7pfXn-: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/routing-discussion/Bie4HKjixFLH-kvj40TgaRb7hcA Cc: Adrian Farrel , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:45:36 -0000 --_000_F64C10EAA68C8044B33656FA214632C8153F28DEMISOUT7MSGUSRDE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCkkgZmluZCB0aGUgZHluYW1pY3MgaW4gSUVURiBvZiBoYXZpbmcgYm90aCByZXF1aXJlbWVu dHMgYW5kIHByb3RvY29sIGV4cGVydHMgaW4gdGhlIHNhbWUgZ3JvdXAgdG8gYmUgb3B0aW11bS4g SW1tZWRpYXRlIGZlZWRiYWNrIHZzLiBtYW55IGN5Y2xlcyBvZiB0aHJvd2luZyBiYWNrIGFuZCBm b3J0aC4gQXMgd2UgaGF2ZSBmb3VuZCBtdWx0aXBsZSB0aW1lcywgd2hhdCBpcyB2aWV3ZWQgYXMg bmV3IHJlcXVpcmVtZW50cyBhcmUgb2Z0ZW4gYWxyZWFkeSBzdXBwb3J0ZWQgYnkgdGhlIHByb3Rv Y29sLiBNb3JlIG9mdGVuIHRoYW4gbm90LCB0aGUgcmVxdWlyZW1lbnRzIGFyZSBiYXNlZCBvbiBh IGJhZCBpbXBsZW1lbnRhdGlvbi4NCg0KDQpGcm9tOiByb3V0aW5nLWRpc2N1c3Npb24gW21haWx0 bzpyb3V0aW5nLWRpc2N1c3Npb24tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJl dyBHLiBNYWxpcw0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAyMSwgMjAxNCAxMDozMSBBTQ0KVG86 IEpvZWwgTS4gSGFscGVybg0KQ2M6IEFkcmlhbiBGYXJyZWw7IHJvdXRpbmctZGlzY3Vzc2lvbkBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFJvdXRpbmcgQXJlYSBUdW5pbmcgLSBVcGRhdGUNCg0KSSBh Z3JlZSB3aXRoIEpvZWwgLSBJIHRoaW5rIHBlb3BsZSBmaW5kIGl0IGhhcmQgdG8gZ2V0IG1vdGl2 YXRlZCB0byBkbyB0aGUgYXJjaGl0ZWN0dXJlIGFuZCByZXF1aXJlbWVudHMgaWYgdGhleSBhbHNv IGRvbid0IGdldCB0byBwbGF5IGFyb3VuZCB3aXRoIHRoZSBwcm90b2NvbHMgKHRoZSBmdW4gc3R1 ZmYpLCB3aGlsZSB0aGUgcGVvcGxlIGRvaW5nIHRoZSBwcm90b2NvbCB3b3JrIGFsc28gd2FudCB0 aGVpciBpbnB1dCBpbnRvIHRoZSBhcmNoaXRlY3R1cmUgYW5kIHJlcXVpcmVtZW50cywgc2luY2Ug dGhlIGNob2ljZXMgbWFkZSB0aGVyZSBjb25zdHJhaW4gd2hhdCB0aGUgcHJvdG9jb2wgd2lsbCBs b29rIGxpa2UuIE9mIGNvdXJzZSwgeW91IGNvdWxkIGhhdmUgdGhlIHNhbWUgcGVvcGxlIHRyYW1w aW5nIGJldHdlZW4gdHdvIGRpZmZlcmVudCBXR3MsIGJ1dCB0aGF0IHNlZW1zIHNpbGx5Lg0KDQpD aGVlcnMsDQpBbmR5DQoNCg0KT24gV2VkLCBBdWcgMjAsIDIwMTQgYXQgNjoxNSBQTSwgSm9lbCBN LiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t Pj4gd3JvdGU6DQpJIGFtIGEgbGl0dGxlIGNvbmNlcm5lZCB0aGF0IHRoZSBwcm9wb3NlZCBhcHBy b2FjaCBoYXMgVEVBUyBkb2luZyB0aGUgcmVxdWlyZW1lbnRzIGZvciB3b3JrIHRvIGJlIGRvbmUg YXMgcHJvdG9jb2wgaW4gb3RoZXIgV0dzLiAgV2hpbGUgd2UgbWFkZSB0aGF0IHdvcmssIGZvciB2 ZXJ5IGdvb2QgcmVhc29ucywgaW4gS0FSUCwgaXQgaXMgZnJlcXVlbnRseSBhIHNvdXJjZSBvZiBm cmljdGlvbiBhbmQgaGluZGVyYW5jZS4NCg0KWW91cnMsDQpKb2VsDQoNCg0KT24gOC8yMC8xNCwg NjowNyBQTSwgQWRyaWFuIEZhcnJlbCB3cm90ZToNCkhpLA0KDQpJIHdhbnRlZCB0byB0YWtlIGEg bW9tZW50IHRvIHVwZGF0ZSB5b3UgYWxsIG9uIG91ciBwcm9ncmVzcyBhbmQgdG8gcG9sbCB5b3Ug Zm9yDQpzb21lIG1vcmUgb3BpbmlvbnMuDQoNCkZpcnN0bHkgdGhlcmUgaXMgYSBzZW5zZSB0aGF0 IHRoaXMgbWF5IGFsbCBiZSBhIGZhaXQgYWNjb21wbGkgd2l0aCB0aGVyZSBiZWluZw0Kbm8gcG9p bnQgaW4gcmFpc2luZyBhbnkgcXVlc3Rpb25zIG9yIGNvbmNlcm5zLiBJJ20gc29ycnkgaWYgdGhp cyBpcyBob3cgaXQgY2FtZQ0Kb3Zlci4gVGhlIEFEcyBoYXZlIGJlZW4gdGhpbmtpbmcgYWJvdXQg dGhpcyBhbmQgZGlzY3Vzc2luZyBpdCBmb3IgcXVpdGUgYSB3aGlsZQ0KYW5kIHdlIHNwZW50IHF1 aXRlIGEgYml0IG9mIHRpbWUgYmVmb3JlIGFuZCBkdXJpbmcgSUVURiA5MCBzZWVraW5nIG91dCBk aWZmZXJlbnQNCnZpZXdwb2ludHMgYW5kIGhhdmluZyBvdXIgb3BpbmlvbnMgc2hhcGVkLiBTbyB3 ZSBoYXZlIGJ1aWx0IHVwIHN0cm9uZyB2aWV3cywgYnV0DQp3ZSBkbyB3YW50IHRvIGhlYXIgeW91 ciB2aWV3cyBhbmQgd2UgcGFydGljdWxhcmx5IHdhbnQgdG8gYmUgdG9sZCB3aGF0IHdlIGhhdmUN CmdvdCB3cm9uZy4NCg0KT25lIHF1ZXN0aW9uIHdlIGFyZSBzdGlsbCB0aGlua2luZyBhYm91dCBj b25jZXJucyB0aGUgYXJyYW5nZW1lbnQgb2YgIFRFLXJlbGF0ZWQNCndvcmsgYWNyb3NzIHRoZSBN UExTLCBDQ0FNUCwgYW5kIFBDRSB3b3JraW5nIGdyb3Vwcy4gQW4gb3B0aW9uIHdlIGhhZCBkaXNj dXNzZWQNCnJlc3VsdGVkIGluIFBDRSB1bmNoYW5nZWQsIFRFQVMgdG8gdGFrZSBURSBhcmNoaXRl Y3R1cmUgYW5kIFJTVlAtVEUsIGFuZCBDQ0FNUA0KdG8gZG8gdGVjaG5vbG9neS1zcGVjaWZpYyBw cm90b2NvbCB3b3JrLiBCdXQgdGhlcmUgaXMgYW5vdGhlciBvcHRpb24gd2hpY2ggd291bGQNCmxl YXZlOg0KICAgIFRFQVMgLSBURSBhcmNoaXRlY3R1cmUgYW5kIHJlcXVpcmVtZW50IHdvcmssIGJ1 dCBubyBwcm90b2NvbCB3b3JrDQogICAgUENFIC0gQWxsIFBDRVAgd29yaywgUENFIGFwcGxpY2Fi aWxpdHkgYW5kIHJlcXVpcmVtZW50cywgYnV0IFBDRSBhcmNoaXRlY3R1cmUNCiAgICAgICAgICAg ICAgIGdvZXMgdG8gVEVBUw0KICAgIFJTVlAtVEUgLSBBbGwgZ2VuZXJpYyBwcm90b2NvbCB3b3Jr IGZvciBSU1ZQLVRFIGZyb20gTVBMUyBhbmQgQ0NBTVANCiAgICBDQ0FNUCAtIHRlY2hub2xvZ3kt c3BlY2lmaWMgcHJvdG9jb2wgd29yay4NClRoaXMgdGhpbmtpbmcgaXMgc29tZXdoYXQgbW90aXZh dGVkIGJ5IHRoZSB3YXkgdGhlIElHUCB3b3JrIGhhcHBlbnMgYXQgdGhlDQptb21lbnQgYW5kIHNv bWV3aGF0IGJ5IHRoZSB0aG91Z2h0IHRoYXQgVEVBUyBtaWdodCBiZSB0b28gbGFyZ2UgYW5kIGhh dmUgdG9vDQptYW55IGRpc3RyYWN0aW9ucyBpZiBpdCBoYXMgcHJvdG9jb2wgYW5kIGFyY2hpdGVj dHVyZSwgd2hpbGUgdGhlIG1vdGl2YXRpb24gZm9yDQprZWVwaW5nICBhcmNoaXRlY3R1cmUgYW5k IHByb3RvY29sIHRvZ2V0aGVyIGluIFRFQVMgaXMgdGhhdCBpdCBwcm92aWRlcyBmb3INCmJldHRl ciBlbmVyZ3kgYW5kIGludGVyYWN0aW9uLg0KDQpXZSB3b3VsZCBsaWtlIHRvIGhlYXIgeW91ciBv cGluaW9ucyBhbmQgZ2V0IGEgYmV0dGVyIHNlbnNlIG9mIHRoZSBjb25zZW5zdXMNCmFyb3VuZCBU RUFTLg0KDQpBdCB0aGUgbW9tZW50IEFsaWEgYW5kIEkgYXJlIHJlY292ZXJpbmcgZnJvbSBUb3Jv bnRvIGFuZCBoYW5kbGluZyB2YWNhdGlvbnMsIGJ1dA0Kd2UgaGF2ZSBmb3JtZWQgYSByb3VnaCBv cmRlciBmb3Igd29ya2luZyBvbiB0aGUgd29ya2luZyBncm91cHMuDQoNCkZpcnN0IHVwIGlzIHRo ZSBSVEdXRyBiZWNhdXNlIHRoYXQgaXMgYSByZWxhdGl2ZWx5IHN0cmFpZ2h0Zm9yd2FyZCB0d2Vh ayB0byBhbg0KZXhpc3RpbmcgY2hhcnRlci4NClRoZW4gd2UgcGxhbiB0byBncm91cCB0b2dldGhl ciB7TDJWUE4sIEwzVlBOLCBQV0UzLCBOVk8zfSBiZWNvbWluZyB7UEFMUywgQkVTUywNCk5WTzN9 DQpUaGVuIHdlIHdpbGwgbG9vayB0byB3b3JrIG91dCBob3cgdG8gaGFuZGxlIHRoZSBURSBlbGVt ZW50cyBkaXNjdXNzZWQgYWJvdmUuDQoNCldlJ2xsIGJlIHRha2luZyBhIGJpdCBvZiBhIHR3by1w cm9uZ2VkIGFwcHJvYWNoOiBpZGVudGlmeSBjaGFpciBjYW5kaWRhdGVzOyBzcGluDQp1cCBkcmFm dCBjaGFydGVycy4NCldlIHBsYW4gdG8gd29yayBvbiB0aGUgZHJhZnQgY2hhcnRlcnMgd2l0aCB0 aGUgZnV0dXJlIGNoYWlycyBhbmQgcHV0IHRoZW0gb3V0IG9uDQp0aGlzIGxpc3QgYW5kIG9uIHRo ZSByZWxldmFudCBXRyBtYWlsaW5nIGxpc3RzIGFzIHNvb24gYXMgd2UgaGF2ZSB0aGVtIHdpdGgg dGhlDQphaW0gb2YgZ2V0dGluZyByZXZpZXcgYW5kIGRpc2N1c3Npb24uDQoNCk9uZSBsYXN0IHBv aW50LiBBbGwgV0dzIHNob3VsZCBjb250aW51ZSB0byBvcGVyYXRlIGFjY29yZGluZyB0byB0aGVp ciBjdXJyZW50DQpjaGFydGVycy4gV2UgY2FuIGhhbmRsZSB0aGUgdHJhbnNpdGlvbiBpZi93aGVu IGl0IGhhcHBlbnMsIGJ1dCB0aGlzIHdvcmsgc2hvdWxkDQpub3QgZ2V0IGluIHRoZSB3YXkgb2Yg cmVhbCB0ZWNobmljYWwgd29yay4NCg0KUGxlYXNlIGxldCB1cyBrbm93IHdoYXQgeW91IHRoaW5r Lg0KDQpBZHJpYW4sDQpwZXIgcHJvIEFsaWENCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnJvdXRpbmctZGlzY3Vzc2lvbiBtYWlsaW5nIGxpc3QNCnJv dXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZzxtYWlsdG86cm91dGluZy1kaXNjdXNzaW9uQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb3V0aW5nLWRpc2N1 c3Npb24NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnJvdXRpbmctZGlzY3Vzc2lvbiBtYWlsaW5nIGxpc3QNCnJvdXRpbmctZGlzY3Vzc2lvbkBpZXRm Lm9yZzxtYWlsdG86cm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb3V0aW5nLWRpc2N1c3Npb24NCg0K --_000_F64C10EAA68C8044B33656FA214632C8153F28DEMISOUT7MSGUSRDE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JiM0MzsxPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZmluZCB0aGUgZHluYW1pY3MgaW4gSUVURiBvZiBoYXZp bmcgYm90aCByZXF1aXJlbWVudHMgYW5kIHByb3RvY29sIGV4cGVydHMgaW4gdGhlIHNhbWUgZ3Jv dXAgdG8gYmUgb3B0aW11bS4gSW1tZWRpYXRlIGZlZWRiYWNrIHZzLiBtYW55IGN5Y2xlcyBvZiB0 aHJvd2luZw0KIGJhY2sgYW5kIGZvcnRoLiBBcyB3ZSBoYXZlIGZvdW5kIG11bHRpcGxlIHRpbWVz LCB3aGF0IGlzIHZpZXdlZCBhcyBuZXcgcmVxdWlyZW1lbnRzIGFyZSBvZnRlbiBhbHJlYWR5IHN1 cHBvcnRlZCBieSB0aGUgcHJvdG9jb2wuIE1vcmUgb2Z0ZW4gdGhhbiBub3QsIHRoZSByZXF1aXJl bWVudHMgYXJlIGJhc2VkIG9uIGEgYmFkIGltcGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IHJvdXRpbmctZGlzY3Vzc2lvbiBbbWFpbHRvOnJvdXRpbmctZGlzY3Vzc2lvbi1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmRyZXcgRy4gTWFsaXM8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAyMSwgMjAxNCAxMDozMSBBTTxicj4NCjxiPlRv OjwvYj4gSm9lbCBNLiBIYWxwZXJuPGJyPg0KPGI+Q2M6PC9iPiBBZHJpYW4gRmFycmVsOyByb3V0 aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFJvdXRpbmcg QXJlYSBUdW5pbmcgLSBVcGRhdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGFncmVlIHdpdGggSm9lbCAtIEkgdGhpbmsgcGVvcGxlIGZpbmQgaXQgaGFyZCB0byBnZXQg bW90aXZhdGVkIHRvIGRvIHRoZSBhcmNoaXRlY3R1cmUgYW5kIHJlcXVpcmVtZW50cyBpZiB0aGV5 IGFsc28gZG9uJ3QgZ2V0IHRvIHBsYXkgYXJvdW5kIHdpdGggdGhlIHByb3RvY29scyAodGhlIGZ1 biBzdHVmZiksIHdoaWxlIHRoZSBwZW9wbGUgZG9pbmcgdGhlIHByb3RvY29sIHdvcmsgYWxzbyB3 YW50IHRoZWlyDQogaW5wdXQgaW50byB0aGUgYXJjaGl0ZWN0dXJlIGFuZCByZXF1aXJlbWVudHMs IHNpbmNlIHRoZSBjaG9pY2VzIG1hZGUgdGhlcmUgY29uc3RyYWluIHdoYXQgdGhlIHByb3RvY29s IHdpbGwgbG9vayBsaWtlLiBPZiBjb3Vyc2UsIHlvdSBjb3VsZCBoYXZlIHRoZSBzYW1lIHBlb3Bs ZSB0cmFtcGluZyBiZXR3ZWVuIHR3byBkaWZmZXJlbnQgV0dzLCBidXQgdGhhdCBzZWVtcyBzaWxs eS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDIwLCAyMDE0IGF0IDY6MTUg UE0sIEpvZWwgTS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIGEgbGl0dGxlIGNvbmNlcm5l ZCB0aGF0IHRoZSBwcm9wb3NlZCBhcHByb2FjaCBoYXMgVEVBUyBkb2luZyB0aGUgcmVxdWlyZW1l bnRzIGZvciB3b3JrIHRvIGJlIGRvbmUgYXMgcHJvdG9jb2wgaW4gb3RoZXIgV0dzLiZuYnNwOyBX aGlsZSB3ZSBtYWRlIHRoYXQgd29yaywgZm9yIHZlcnkgZ29vZCByZWFzb25zLCBpbiBLQVJQLCBp dCBpcyBmcmVxdWVudGx5IGEgc291cmNlIG9mIGZyaWN0aW9uIGFuZCBoaW5kZXJhbmNlLjxicj4N Cjxicj4NCllvdXJzLDxicj4NCkpvZWw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KT24gOC8yMC8xNCwgNjowNyBQTSwgQWRyaWFu IEZhcnJlbCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGksPGJyPg0KPGJyPg0KSSB3YW50ZWQgdG8gdGFrZSBh IG1vbWVudCB0byB1cGRhdGUgeW91IGFsbCBvbiBvdXIgcHJvZ3Jlc3MgYW5kIHRvIHBvbGwgeW91 IGZvcjxicj4NCnNvbWUgbW9yZSBvcGluaW9ucy48YnI+DQo8YnI+DQpGaXJzdGx5IHRoZXJlIGlz IGEgc2Vuc2UgdGhhdCB0aGlzIG1heSBhbGwgYmUgYSBmYWl0IGFjY29tcGxpIHdpdGggdGhlcmUg YmVpbmc8YnI+DQpubyBwb2ludCBpbiByYWlzaW5nIGFueSBxdWVzdGlvbnMgb3IgY29uY2VybnMu IEknbSBzb3JyeSBpZiB0aGlzIGlzIGhvdyBpdCBjYW1lPGJyPg0Kb3Zlci4gVGhlIEFEcyBoYXZl IGJlZW4gdGhpbmtpbmcgYWJvdXQgdGhpcyBhbmQgZGlzY3Vzc2luZyBpdCBmb3IgcXVpdGUgYSB3 aGlsZTxicj4NCmFuZCB3ZSBzcGVudCBxdWl0ZSBhIGJpdCBvZiB0aW1lIGJlZm9yZSBhbmQgZHVy aW5nIElFVEYgOTAgc2Vla2luZyBvdXQgZGlmZmVyZW50PGJyPg0Kdmlld3BvaW50cyBhbmQgaGF2 aW5nIG91ciBvcGluaW9ucyBzaGFwZWQuIFNvIHdlIGhhdmUgYnVpbHQgdXAgc3Ryb25nIHZpZXdz LCBidXQ8YnI+DQp3ZSBkbyB3YW50IHRvIGhlYXIgeW91ciB2aWV3cyBhbmQgd2UgcGFydGljdWxh cmx5IHdhbnQgdG8gYmUgdG9sZCB3aGF0IHdlIGhhdmU8YnI+DQpnb3Qgd3JvbmcuPGJyPg0KPGJy Pg0KT25lIHF1ZXN0aW9uIHdlIGFyZSBzdGlsbCB0aGlua2luZyBhYm91dCBjb25jZXJucyB0aGUg YXJyYW5nZW1lbnQgb2YmbmJzcDsgVEUtcmVsYXRlZDxicj4NCndvcmsgYWNyb3NzIHRoZSBNUExT LCBDQ0FNUCwgYW5kIFBDRSB3b3JraW5nIGdyb3Vwcy4gQW4gb3B0aW9uIHdlIGhhZCBkaXNjdXNz ZWQ8YnI+DQpyZXN1bHRlZCBpbiBQQ0UgdW5jaGFuZ2VkLCBURUFTIHRvIHRha2UgVEUgYXJjaGl0 ZWN0dXJlIGFuZCBSU1ZQLVRFLCBhbmQgQ0NBTVA8YnI+DQp0byBkbyB0ZWNobm9sb2d5LXNwZWNp ZmljIHByb3RvY29sIHdvcmsuIEJ1dCB0aGVyZSBpcyBhbm90aGVyIG9wdGlvbiB3aGljaCB3b3Vs ZDxicj4NCmxlYXZlOjxicj4NCiZuYnNwOyAmbmJzcDsgVEVBUyAtIFRFIGFyY2hpdGVjdHVyZSBh bmQgcmVxdWlyZW1lbnQgd29yaywgYnV0IG5vIHByb3RvY29sIHdvcms8YnI+DQombmJzcDsgJm5i c3A7IFBDRSAtIEFsbCBQQ0VQIHdvcmssIFBDRSBhcHBsaWNhYmlsaXR5IGFuZCByZXF1aXJlbWVu dHMsIGJ1dCBQQ0UgYXJjaGl0ZWN0dXJlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2dvZXMgdG8gVEVBUzxicj4NCiZuYnNwOyAmbmJz cDsgUlNWUC1URSAtIEFsbCBnZW5lcmljIHByb3RvY29sIHdvcmsgZm9yIFJTVlAtVEUgZnJvbSBN UExTIGFuZCBDQ0FNUDxicj4NCiZuYnNwOyAmbmJzcDsgQ0NBTVAgLSB0ZWNobm9sb2d5LXNwZWNp ZmljIHByb3RvY29sIHdvcmsuPGJyPg0KVGhpcyB0aGlua2luZyBpcyBzb21ld2hhdCBtb3RpdmF0 ZWQgYnkgdGhlIHdheSB0aGUgSUdQIHdvcmsgaGFwcGVucyBhdCB0aGU8YnI+DQptb21lbnQgYW5k IHNvbWV3aGF0IGJ5IHRoZSB0aG91Z2h0IHRoYXQgVEVBUyBtaWdodCBiZSB0b28gbGFyZ2UgYW5k IGhhdmUgdG9vPGJyPg0KbWFueSBkaXN0cmFjdGlvbnMgaWYgaXQgaGFzIHByb3RvY29sIGFuZCBh cmNoaXRlY3R1cmUsIHdoaWxlIHRoZSBtb3RpdmF0aW9uIGZvcjxicj4NCmtlZXBpbmcmbmJzcDsg YXJjaGl0ZWN0dXJlIGFuZCBwcm90b2NvbCB0b2dldGhlciBpbiBURUFTIGlzIHRoYXQgaXQgcHJv dmlkZXMgZm9yPGJyPg0KYmV0dGVyIGVuZXJneSBhbmQgaW50ZXJhY3Rpb24uPGJyPg0KPGJyPg0K V2Ugd291bGQgbGlrZSB0byBoZWFyIHlvdXIgb3BpbmlvbnMgYW5kIGdldCBhIGJldHRlciBzZW5z ZSBvZiB0aGUgY29uc2Vuc3VzPGJyPg0KYXJvdW5kIFRFQVMuPGJyPg0KPGJyPg0KQXQgdGhlIG1v bWVudCBBbGlhIGFuZCBJIGFyZSByZWNvdmVyaW5nIGZyb20gVG9yb250byBhbmQgaGFuZGxpbmcg dmFjYXRpb25zLCBidXQ8YnI+DQp3ZSBoYXZlIGZvcm1lZCBhIHJvdWdoIG9yZGVyIGZvciB3b3Jr aW5nIG9uIHRoZSB3b3JraW5nIGdyb3Vwcy48YnI+DQo8YnI+DQpGaXJzdCB1cCBpcyB0aGUgUlRH V0cgYmVjYXVzZSB0aGF0IGlzIGEgcmVsYXRpdmVseSBzdHJhaWdodGZvcndhcmQgdHdlYWsgdG8g YW48YnI+DQpleGlzdGluZyBjaGFydGVyLjxicj4NClRoZW4gd2UgcGxhbiB0byBncm91cCB0b2dl dGhlciB7TDJWUE4sIEwzVlBOLCBQV0UzLCBOVk8zfSBiZWNvbWluZyB7UEFMUywgQkVTUyw8YnI+ DQpOVk8zfTxicj4NClRoZW4gd2Ugd2lsbCBsb29rIHRvIHdvcmsgb3V0IGhvdyB0byBoYW5kbGUg dGhlIFRFIGVsZW1lbnRzIGRpc2N1c3NlZCBhYm92ZS48YnI+DQo8YnI+DQpXZSdsbCBiZSB0YWtp bmcgYSBiaXQgb2YgYSB0d28tcHJvbmdlZCBhcHByb2FjaDogaWRlbnRpZnkgY2hhaXIgY2FuZGlk YXRlczsgc3Bpbjxicj4NCnVwIGRyYWZ0IGNoYXJ0ZXJzLjxicj4NCldlIHBsYW4gdG8gd29yayBv biB0aGUgZHJhZnQgY2hhcnRlcnMgd2l0aCB0aGUgZnV0dXJlIGNoYWlycyBhbmQgcHV0IHRoZW0g b3V0IG9uPGJyPg0KdGhpcyBsaXN0IGFuZCBvbiB0aGUgcmVsZXZhbnQgV0cgbWFpbGluZyBsaXN0 cyBhcyBzb29uIGFzIHdlIGhhdmUgdGhlbSB3aXRoIHRoZTxicj4NCmFpbSBvZiBnZXR0aW5nIHJl dmlldyBhbmQgZGlzY3Vzc2lvbi48YnI+DQo8YnI+DQpPbmUgbGFzdCBwb2ludC4gQWxsIFdHcyBz aG91bGQgY29udGludWUgdG8gb3BlcmF0ZSBhY2NvcmRpbmcgdG8gdGhlaXIgY3VycmVudDxicj4N CmNoYXJ0ZXJzLiBXZSBjYW4gaGFuZGxlIHRoZSB0cmFuc2l0aW9uIGlmL3doZW4gaXQgaGFwcGVu cywgYnV0IHRoaXMgd29yayBzaG91bGQ8YnI+DQpub3QgZ2V0IGluIHRoZSB3YXkgb2YgcmVhbCB0 ZWNobmljYWwgd29yay48YnI+DQo8YnI+DQpQbGVhc2UgbGV0IHVzIGtub3cgd2hhdCB5b3UgdGhp bmsuPGJyPg0KPGJyPg0KQWRyaWFuLDxicj4NCnBlciBwcm8gQWxpYTxicj4NCjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kcm91dGluZy1k aXNjdXNzaW9uIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpyb3V0aW5nLWRpc2N1 c3Npb25AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5yb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9yb3V0aW5nLWRpc2N1c3Npb24iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3JvdXRpbmctZGlzY3Vzc2lvbjwvYT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0Kcm91dGluZy1kaXNjdXNzaW9uIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpyb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5yb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb3V0aW5nLWRpc2N1c3Npb24iIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvdXRp bmctZGlzY3Vzc2lvbjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F64C10EAA68C8044B33656FA214632C8153F28DEMISOUT7MSGUSRDE_-- From nobody Thu Aug 21 08:05:11 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59DD1A8977 for ; Thu, 21 Aug 2014 08:04:57 -0700 (PDT) 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 BH7_L4Nar5lE for ; Thu, 21 Aug 2014 08:04:55 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002: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 945D81A06F5 for ; Thu, 21 Aug 2014 08:04:31 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id 29so8209529yhl.16 for ; Thu, 21 Aug 2014 08:04:31 -0700 (PDT) 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 :cc:content-type; bh=kB+ZE86uqwpRzABcvX/jzVOSPAeJmRq4w+Fb+2v+NCE=; b=B5A5YbP3UY8ZyQQjEbZHQYVPgshzYvdW6xjWVyXVpPw2QhxqaxFCvpRl9rSIc5S2AW 3Ycqz4YrRerpbFrh0sko4qROVRIA81DJL3wPheRycwgkkgPN86SZqPvAaXE3G7uTAzfb m+U7rjZcIbhENMw2a+acgNLVTwHl6ZOFgM7bTk7wkpdEYmPnXioqfotWfFcVA+1WTnQG +Pz/MwyHngT24gkqZgzqKQYitYMh0KVUjZyQ3ctKyn20YeaQD3LNibDO9JtF6lvvCTQg ICX0xpuMzrChd60/xeQa0z3d2MoGI4v7Z9qbhJo8qs8kyMdNR4tzy5LGifq/mqlzJiZK nv7g== MIME-Version: 1.0 X-Received: by 10.236.170.38 with SMTP id o26mr1262565yhl.182.1408633470902; Thu, 21 Aug 2014 08:04:30 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Thu, 21 Aug 2014 08:04:30 -0700 (PDT) In-Reply-To: <53F51DF9.5090703@joelhalpern.com> References: <062701cfbcc3$2a295470$7e7bfd50$@olddog.co.uk> <53F51DF9.5090703@joelhalpern.com> Date: Thu, 21 Aug 2014 17:04:30 +0200 Message-ID: Subject: Re: Routing Area Tuning - Update From: Abdussalam Baryun To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=20cf302d4e2aa6e627050125093c Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/TAC7G0OTqP1sx0-gTc72F9dlvUM Cc: "adrian@olddog.co.uk" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 15:04:58 -0000 --20cf302d4e2aa6e627050125093c Content-Type: text/plain; charset=UTF-8 On Wednesday, August 20, 2014, Joel M. Halpern wrote: > I am a little concerned that the proposed approach has TEAS doing the > requirements for work to be done as protocol in other WGs. I did not understand that from the proposal. Each work and work requirement is done in same WG, so TEAS is not doing work requirement for another WG. May be there are external and internal requirements. AB > > >> >> >> . >> >> --20cf302d4e2aa6e627050125093c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, August 20, 2014, Joel M. Halpern wrote:
I am a little concerned that the proposed approach ha= s TEAS doing the requirements for work to be done as protocol in other WGs.= =C2=A0=C2=A0

I did not understand that from the proposal. Each work = and=C2=A0work requirement is done in same WG, so TEAS is not doing work req= uirement for=C2=A0another WG. May be there are external and internal requir= ements.=C2=A0

AB=C2=A0

=C2=A0



.

--20cf302d4e2aa6e627050125093c-- From nobody Thu Aug 21 08:07:19 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6960C1A6F0B for ; Thu, 21 Aug 2014 08:07:17 -0700 (PDT) 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, 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 lenOAiR5oQcg for ; Thu, 21 Aug 2014 08:07:15 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id B679B1A0721 for ; Thu, 21 Aug 2014 08:07:14 -0700 (PDT) Received: (qmail 19325 invoked by uid 0); 21 Aug 2014 15:07:13 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 21 Aug 2014 15:07:13 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id hZ751o00p2SSUrH01Z78qL; Thu, 21 Aug 2014 15:07:12 -0600 X-Authority-Analysis: v=2.1 cv=KvHehwmN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=pR15HSHCFqAA:10 a=ufBpKkTJRMAA:10 a=HFCU6gKsb0MA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=48vgC7mUAAAA:8 a=ABeY7kuGAAAA:8 a=z4S3t60yZ8xKJdm6qhwA:9 a=WGj97PA3LTQ2SHro:21 a=QYCoHYBvlAUIPA2m:21 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=chC_agHSu74A: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=q2KAt66M/Y2cSO1gkcVCBmE1d7BORK7pJHMInUEs9ek=; b=WW2CDbqK2sMLuSaCmInknQhMtBJp7H/9K5TSy++rQ3MMLP1yTra1euxZ+x5WjG93MoDiZ8rs/nfAkub1K/EDojr6vOzKh088Bj9Xy9c68rQe8HODjXcEmc6tX/MTNbpO; Received: from box313.bluehost.com ([69.89.31.113]:52120 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XKTxC-0001YA-Um; Thu, 21 Aug 2014 09:07:07 -0600 Message-ID: <53F60B69.3090304@labn.net> Date: Thu, 21 Aug 2014 11:08:25 -0400 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" , "Andrew G. Malis" , "Joel M. Halpern" Subject: Re: Routing Area Tuning - Update References: <062701cfbcc3$2a295470$7e7bfd50$@olddog.co.uk> <53F51DF9.5090703@joelhalpern.com> In-Reply-To: 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/routing-discussion/egfjM9Q79vRagyYPB7KY6HJYsag Cc: Adrian Farrel , Adrian Farrel , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 15:07:17 -0000 I'm not so sure.=20 I think the tradeoffs are (a) architecture fragmentation/coordination vs (b) protocol fragmentation/coordination vs (c) wg scope size, and a desire/need to choose two. With the approach presented in toronto we end up with architecture fragmented across PCE and TEAS, and TEAS only able to ensure protocol alignment between routing and signaling, but not PCE. Arguably, this is how CCAMP has operated -- and I'd hope can be improved upon. It also means that folks that care only about an RSVP change need to sit through / track all the architecture-related work (aka noise). I think a TEAS that is responsible for everything but the (routing, signaling, pce, ...) protocol details would do a better job at ensuring a consistent architecture/framework/model (and even encoding formats) and not be "too big" (c). Which is perhaps where Adrian was headed in his mail. If (c) wasn't an objective, I'd say have TEAS do all TE protocol extensions to address Joel's (and the supporting) comments . I think we can avoid a repeat of IPO in TEAS, even without it portion of the protocol work, and that it is better for it to have all the high level work (and ensure a consistent architecture/framework/model) than for it to have a fragment of the high in order for it to also have a fragment of the detail work.=20 Lou On 8/21/2014 10:44 AM, BRUNGARD, DEBORAH A wrote: > > +1 > > I find the dynamics in IETF of having both requirements and protocol > experts in the same group to be optimum. Immediate feedback vs. many > cycles of throwing back and forth. As we have found multiple times, > what is viewed as new requirements are often already supported by the > protocol. More often than not, the requirements are based on a bad > implementation. > > =20 > > =20 > > *From:*routing-discussion [mailto:routing-discussion-bounces@ietf.org] > *On Behalf Of *Andrew G. Malis > *Sent:* Thursday, August 21, 2014 10:31 AM > *To:* Joel M. Halpern > *Cc:* Adrian Farrel; routing-discussion@ietf.org > *Subject:* Re: Routing Area Tuning - Update > > =20 > > I agree with Joel - I think people find it hard to get motivated to do > the architecture and requirements if they also don't get to play > around with the protocols (the fun stuff), while the people doing the > protocol work also want their input into the architecture and > requirements, since the choices made there constrain what the protocol > will look like. Of course, you could have the same people tramping > between two different WGs, but that seems silly. > > =20 > > Cheers, > > Andy > > =20 > > =20 > > On Wed, Aug 20, 2014 at 6:15 PM, Joel M. Halpern > wrote: > > I am a little concerned that the proposed approach has TEAS doing the > requirements for work to be done as protocol in other WGs. While we > made that work, for very good reasons, in KARP, it is frequently a > source of friction and hinderance. > > Yours, > Joel > > > > On 8/20/14, 6:07 PM, Adrian Farrel wrote: > > Hi, > > I wanted to take a moment to update you all on our progress and to > poll you for > some more opinions. > > Firstly there is a sense that this may all be a fait accompli with > there being > no point in raising any questions or concerns. I'm sorry if this is > how it came > over. The ADs have been thinking about this and discussing it for > quite a while > and we spent quite a bit of time before and during IETF 90 seeking out > different > viewpoints and having our opinions shaped. So we have built up strong > views, but > we do want to hear your views and we particularly want to be told what > we have > got wrong. > > One question we are still thinking about concerns the arrangement of=20 > TE-related > work across the MPLS, CCAMP, and PCE working groups. An option we had > discussed > resulted in PCE unchanged, TEAS to take TE architecture and RSVP-TE, > and CCAMP > to do technology-specific protocol work. But there is another option > which would > leave: > TEAS - TE architecture and requirement work, but no protocol work > PCE - All PCEP work, PCE applicability and requirements, but PCE > architecture > goes to TEAS > RSVP-TE - All generic protocol work for RSVP-TE from MPLS and CCAMP= > CCAMP - technology-specific protocol work. > This thinking is somewhat motivated by the way the IGP work happens at = the > moment and somewhat by the thought that TEAS might be too large and > have too > many distractions if it has protocol and architecture, while the > motivation for > keeping architecture and protocol together in TEAS is that it > provides for > better energy and interaction. > > We would like to hear your opinions and get a better sense of the > consensus > around TEAS. > > At the moment Alia and I are recovering from Toronto and handling > vacations, but > we have formed a rough order for working on the working groups. > > First up is the RTGWG because that is a relatively straightforward > tweak to an > existing charter. > Then we plan to group together {L2VPN, L3VPN, PWE3, NVO3} becoming > {PALS, BESS, > NVO3} > Then we will look to work out how to handle the TE elements discussed > above. > > We'll be taking a bit of a two-pronged approach: identify chair > candidates; spin > up draft charters. > We plan to work on the draft charters with the future chairs and put > them out on > this list and on the relevant WG mailing lists as soon as we have them > with the > aim of getting review and discussion. > > One last point. All WGs should continue to operate according to their > current > charters. We can handle the transition if/when it happens, but this > work should > not get in the way of real technical work. > > Please let us know what you think. > > Adrian, > per pro Alia > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > > =20 > > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Thu Aug 21 10:06:24 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F343C1A06D0 for ; Thu, 21 Aug 2014 10:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 duUCJv_H9_IB for ; Thu, 21 Aug 2014 10:06:20 -0700 (PDT) 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 BC0621A06A3 for ; Thu, 21 Aug 2014 10:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3948; q=dns/txt; s=iport; t=1408640780; x=1409850380; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=M/BaX3q1ssTnQDseLPsZsZkFX+ChEb+Y06InIQaM6OQ=; b=XcsRuu4+F9ovLFkJ/R+R4RPylSLNFUhqRN2BgmF12meVAQf1Udf/M0EZ /4FErKH8eqgyZojBzydR4vlp1FWRyjxX7MR2N+SGgg33aYzluvEtaWcv4 dUn1yMJoFmB/i6bQa7L/YPD0LwnPG2TXmVGawRoTtsuCKzNhBpYjusBdM c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAE8m9lOtJA2I/2dsb2JhbABQCoMNU1cEzEUKhntTAYEPFneEBAEBBAEBATc0HQEIEgYeNwsXDgEBBAESiEINwn4TBI5wY4RMBZElhmOEP5UKg15sgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,909,1406592000"; d="scan'208";a="346192067" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP; 21 Aug 2014 17:06:16 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7LH6GdP017595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Aug 2014 17:06:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 21 Aug 2014 12:06:16 -0500 From: "George Swallow (swallow)" To: "Joel M. Halpern" , "adrian@olddog.co.uk" , "routing-discussion@ietf.org" Subject: Re: Routing Area Tuning - Update Thread-Topic: Routing Area Tuning - Update Thread-Index: Ac+8wyZusCFJ/2FATmmqnraiOjiHgQAKv2eAAB8c+IA= Date: Thu, 21 Aug 2014 17:06:15 +0000 Message-ID: In-Reply-To: <53F51DF9.5090703@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.86.253.50] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/zyTHm85zVI3RWLv0hihI6lBKz5M X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 17:06:23 -0000 In addition to Joel's concern, which I share, I'm also very concerned that we are replacing 3 WG with 5. All 5 would need to be mutually exclusive on the IETF meeting Agenda. Of course there are quite a few other Wgs that some of these would want to avoid colliding with. George On 8/20/14 6:15 PM, "Joel M. Halpern" wrote: >I am a little concerned that the proposed approach has TEAS doing the >requirements for work to be done as protocol in other WGs. While we >made that work, for very good reasons, in KARP, it is frequently a >source of friction and hinderance. > >Yours, >Joel > >On 8/20/14, 6:07 PM, Adrian Farrel wrote: >> Hi, >> >> I wanted to take a moment to update you all on our progress and to poll >>you for >> some more opinions. >> >> Firstly there is a sense that this may all be a fait accompli with >>there being >> no point in raising any questions or concerns. I'm sorry if this is how >>it came >> over. The ADs have been thinking about this and discussing it for quite >>a while >> and we spent quite a bit of time before and during IETF 90 seeking out >>different >> viewpoints and having our opinions shaped. So we have built up strong >>views, but >> we do want to hear your views and we particularly want to be told what >>we have >> got wrong. >> >> One question we are still thinking about concerns the arrangement of >>TE-related >> work across the MPLS, CCAMP, and PCE working groups. An option we had >>discussed >> resulted in PCE unchanged, TEAS to take TE architecture and RSVP-TE, >>and CCAMP >> to do technology-specific protocol work. But there is another option >>which would >> leave: >> TEAS - TE architecture and requirement work, but no protocol work >> PCE - All PCEP work, PCE applicability and requirements, but PCE >>architecture >> goes to TEAS >> RSVP-TE - All generic protocol work for RSVP-TE from MPLS and CCAMP >> CCAMP - technology-specific protocol work. >> This thinking is somewhat motivated by the way the IGP work happens at >>the >> moment and somewhat by the thought that TEAS might be too large and >>have too >> many distractions if it has protocol and architecture, while the >>motivation for >> keeping architecture and protocol together in TEAS is that it provides >>for >> better energy and interaction. >> >> We would like to hear your opinions and get a better sense of the >>consensus >> around TEAS. >> >> At the moment Alia and I are recovering from Toronto and handling >>vacations, but >> we have formed a rough order for working on the working groups. >> >> First up is the RTGWG because that is a relatively straightforward >>tweak to an >> existing charter. >> Then we plan to group together {L2VPN, L3VPN, PWE3, NVO3} becoming >>{PALS, BESS, >> NVO3} >> Then we will look to work out how to handle the TE elements discussed >>above. >> >> We'll be taking a bit of a two-pronged approach: identify chair >>candidates; spin >> up draft charters. >> We plan to work on the draft charters with the future chairs and put >>them out on >> this list and on the relevant WG mailing lists as soon as we have them >>with the >> aim of getting review and discussion. >> >> One last point. All WGs should continue to operate according to their >>current >> charters. We can handle the transition if/when it happens, but this >>work should >> not get in the way of real technical work. >> >> Please let us know what you think. >> >> Adrian, >> per pro Alia >> >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion >> > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Thu Aug 21 13:13:41 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6211A06A9 for ; Thu, 21 Aug 2014 13:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, 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 MLgMaFpKLzYV for ; Thu, 21 Aug 2014 13:13:39 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 3BF731A06E1 for ; Thu, 21 Aug 2014 13:13:39 -0700 (PDT) Received: (qmail 26277 invoked by uid 0); 21 Aug 2014 20:13:33 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 21 Aug 2014 20:13:33 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id hYDS1o00K2SSUrH01YDVZ5; Thu, 21 Aug 2014 14:13:32 -0600 X-Authority-Analysis: v=2.1 cv=LbyvtFvi c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=pR15HSHCFqAA:10 a=ufBpKkTJRMAA:10 a=HFCU6gKsb0MA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ABeY7kuGAAAA:8 a=48vgC7mUAAAA:8 a=db28nO7Ny0Lbcm4JuGIA:9 a=5mhuB0a9T9WjYECg:21 a=tdhiUvDVQv5KRrqf:21 a=wPNLvfGTeEIA:10 a=chC_agHSu74A:10 a=lZB815dzVvQA: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=WBZxc3SKI6UVffWUPz7GVk/UILDnaabHiKeg/OXxuss=; b=HfBKewt61nJUzk4ni/Hu8pdb2iC0zsjclfSO2lrG2FMi4ahYLlf+WL7yrUYoUx9sEdj0HOjBWS+ZQ/EVnmWXyGLPlJZCesb/ytYHy9rFH+66bY3v8FG3N++xuEL/cLCy; Received: from box313.bluehost.com ([69.89.31.113]:55828 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XKYjf-0001mz-72; Thu, 21 Aug 2014 14:13:27 -0600 Message-ID: <53F65335.3090501@labn.net> Date: Thu, 21 Aug 2014 16:14:45 -0400 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: "George Swallow (swallow)" , "Joel M. Halpern" , "adrian@olddog.co.uk" , "routing-discussion@ietf.org" Subject: Re: Routing Area Tuning - Update References: In-Reply-To: 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/routing-discussion/BzSssK1pjeVivNzGFzkmO8BWF2Y X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 20:13:41 -0000 I think there are some tradeoffs here with some not so clear answers.=20 Perhaps we should try the original proposal and see how it works out as current voices seem to support this, and I wouldn't call it "wrong", perhaps just "risky".=20 I actually think that the current TEAS + all TE architecture would be preferable, as splitting/fragmented architecture seems much more risky to me than splitting/fragmented protocol work. Given that this grouping was rejected already in Toronto, my next choice would be to consolidate all TE architecture/FW/Models/Encoding definition and break out protocol mechanisms into their respective WGs.=20 With this option we're likely end up with the same number of WG sessions as TEAS is likely to need two sessions to cover the high level and protocol extensions. (based on both the MPLS and CCAMP experience) The mutual exclusive list is 3 (MPLS, TEAS, CCAMP) rather than 4 (MPLS, TEAS, CCAMP, PCE) as PCE no longer has architecture. Conflicts between the protocol groups will be less critical as they are now just dealing with their own protocol details, although I suspect chairs are going to prefer to not conflict with TEAS as they'll want to track what's happening there. This split also has real benefits for folks just interested in specific protocol mechanism extensions. They no longer need to track/sit through the noise of TEAS, they just go/subscribe to the specific protocol WG. Perhaps I'm just wrong, but to me the approach of separating out the protocol work seems much "cleaner" and less likely to result in technology / inter-WG issues than breaking apart the architecture work.=20 (Of course, I'd really prefer having arch+tech in TEASE, but I recognize that this is even less likely/popular.) Lou On 8/21/2014 1:06 PM, George Swallow (swallow) wrote: > In addition to Joel's concern, which I share, I'm also very concerned > that we are replacing 3 WG with 5. All 5 would need to be mutually > exclusive on the IETF meeting Agenda. Of course there are quite a few > other Wgs that some of these would want to avoid colliding with. > George On 8/20/14 6:15 PM, "Joel M. Halpern" wrot= e: >> I am a little concerned that the proposed approach has TEAS doing the >> requirements for work to be done as protocol in other WGs. While we >> made that work, for very good reasons, in KARP, it is frequently a >> source of friction and hinderance. Yours, Joel On 8/20/14, 6:07 PM, >> Adrian Farrel wrote: >>> Hi, I wanted to take a moment to update you all on our progress and >>> to poll you for some more opinions. Firstly there is a sense that >>> this may all be a fait accompli with there being no point in raising >>> any questions or concerns. I'm sorry if this is how it came over. >>> The ADs have been thinking about this and discussing it for quite a >>> while and we spent quite a bit of time before and during IETF 90 >>> seeking out different viewpoints and having our opinions shaped. So >>> we have built up strong views, but we do want to hear your views and >>> we particularly want to be told what we have got wrong. One question >>> we are still thinking about concerns the arrangement of TE-related >>> work across the MPLS, CCAMP, and PCE working groups. An option we >>> had discussed resulted in PCE unchanged, TEAS to take TE >>> architecture and RSVP-TE, and CCAMP to do technology-specific >>> protocol work. But there is another option which would leave: TEAS - >>> TE architecture and requirement work, but no protocol work PCE - All >>> PCEP work, PCE applicability and requirements, but PCE architecture >>> goes to TEAS RSVP-TE - All generic protocol work for RSVP-TE from >>> MPLS and CCAMP CCAMP - technology-specific protocol work. This >>> thinking is somewhat motivated by the way the IGP work happens at >>> the moment and somewhat by the thought that TEAS might be too large >>> and have too many distractions if it has protocol and architecture, >>> while the motivation for keeping architecture and protocol together >>> in TEAS is that it provides for better energy and interaction. We >>> would like to hear your opinions and get a better sense of the >>> consensus around TEAS. At the moment Alia and I are recovering from >>> Toronto and handling vacations, but we have formed a rough order for >>> working on the working groups. First up is the RTGWG because that is >>> a relatively straightforward tweak to an existing charter. Then we >>> plan to group together {L2VPN, L3VPN, PWE3, NVO3} becoming {PALS, >>> BESS, NVO3} Then we will look to work out how to handle the TE >>> elements discussed above. We'll be taking a bit of a two-pronged >>> approach: identify chair candidates; spin up draft charters. We plan >>> to work on the draft charters with the future chairs and put them >>> out on this list and on the relevant WG mailing lists as soon as we >>> have them with the aim of getting review and discussion. One last >>> point. All WGs should continue to operate according to their current >>> charters. We can handle the transition if/when it happens, but this >>> work should not get in the way of real technical work. Please let us >>> know what you think. Adrian, per pro Alia >>> _______________________________________________ routing-discussion >>> mailing list routing-discussion@ietf.org >>> https://www.ietf.org/mailman/listinfo/routing-discussion=20 >> _______________________________________________ routing-discussion >> mailing list routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion=20 > _______________________________________________ routing-discussion > mailing list routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Thu Aug 21 14:34:39 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F80A1A0AD0 for ; Thu, 21 Aug 2014 14:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 G1f2LHRao79N for ; Thu, 21 Aug 2014 14:34:36 -0700 (PDT) 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 0517C1A009C for ; Thu, 21 Aug 2014 14:34:35 -0700 (PDT) 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 BLN37415; Thu, 21 Aug 2014 21:34:34 +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; Thu, 21 Aug 2014 22:34:33 +0100 Received: from DFWEML704-CHM.china.huawei.com ([10.193.5.141]) by dfweml701-chm.china.huawei.com ([169.254.1.129]) with mapi id 14.03.0158.001; Thu, 21 Aug 2014 14:34:27 -0700 From: Leeyoung To: "routing-discussion@ietf.org" Subject: Routing Area Tuning - Update Thread-Topic: Routing Area Tuning - Update Thread-Index: Ac+9h64S9zX9v8YqQXifYyM9Sa71gA== Date: Thu, 21 Aug 2014 21:34:26 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C23ABF@dfweml704-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.211] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C23ABFdfweml704chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/cYgfegLXQBfI9L5xJyNeRwgjm_4 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 21:34:38 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C23ABFdfweml704chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I just subscribed to routing-discussion list per Lou's email. If TEAS were to do no protocol work, I am not sure how it is going work in = a long run. Will TEAS's TE architecture/framework include new school of tho= ughts like source routing or any unforeseeable ways of doing TE from which = new protocol work may need to be defined? If yes, then I think it may be wo= rthy to explore; if not, then it may be hard to justify a new WG with no pr= otocol work (in the existing MPLS/GMPLS contexts). In principle, I prefer = not to separate protocol work from requirement/framework/architecture. Another thought is: Is CCAMP supposed to be working on Generalized MPLS? CC= AMP WG being narrowed down only to work on tech-specific area seems to me c= ount-intuitive. Young --_000_7AEB3D6833318045B4AE71C2C87E8E1729C23ABFdfweml704chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I just subscribed to routing-discussion list per Lou= ’s email.

 

If TEAS were to do no protocol work, I am not sure h= ow it is going work in a long run. Will TEAS’s TE architecture/framew= ork include new school of thoughts like source routing or any unforeseeable= ways of doing TE from which new protocol work may need to be defined? If yes, then I think it may be worthy to expl= ore; if not, then it may be hard to justify a new WG with no protocol work = (in the existing MPLS/GMPLS contexts).  In principle, I prefer not to = separate protocol work from requirement/framework/architecture.  

 

Another thought is: Is CCAMP supposed to be working = on Generalized MPLS? CCAMP WG being narrowed down only to work on tech-spec= ific area seems to me count-intuitive.

 

Young

 

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C23ABFdfweml704chm_-- From nobody Fri Aug 22 03:11:22 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AE61A0202 for ; Fri, 22 Aug 2014 03:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, 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 LPDm6-kyuoRz for ; Fri, 22 Aug 2014 03:11:14 -0700 (PDT) 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 32D091A01E6 for ; Fri, 22 Aug 2014 03:11:12 -0700 (PDT) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CF8AF2F014E for ; Fri, 22 Aug 2014 12:11:09 +0200 (CEST) Received: from ESTGVMSP111.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 AFC882F0107 for ; Fri, 22 Aug 2014 12:11:09 +0200 (CEST) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.54) with Microsoft SMTP Server (TLS) id 14.3.146.2; Fri, 22 Aug 2014 12:11:08 +0200 Received: from AMSPR06MB104.eurprd06.prod.outlook.com (10.242.90.155) by AMSPR06MB102.eurprd06.prod.outlook.com (10.242.90.147) with Microsoft SMTP Server (TLS) id 15.0.1015.17; Fri, 22 Aug 2014 10:11:07 +0000 Received: from AMSPR06MB104.eurprd06.prod.outlook.com ([169.254.8.114]) by AMSPR06MB104.eurprd06.prod.outlook.com ([169.254.8.114]) with mapi id 15.00.1005.008; Fri, 22 Aug 2014 10:11:08 +0000 From: OSCAR GONZALEZ DE DIOS To: "routing-discussion@ietf.org" Subject: Splitting TE Architecture from protocol work Thread-Topic: Splitting TE Architecture from protocol work Thread-Index: AQHPvfFjYU3l0m888k6Po/OFJuJEng== Date: Fri, 22 Aug 2014 10:11:07 +0000 Message-ID: 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.26] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(53754006)(189002)(81542001)(2351001)(92726001)(92566001)(81342001)(76482001)(229853001)(2656002)(36756003)(66066001)(74502001)(31966008)(107046002)(4396001)(74662001)(107886001)(106356001)(85306004)(83072002)(77096002)(86362001)(64706001)(20776003)(79102001)(21056001)(16236675004)(99396002)(95666004)(46102001)(83322001)(106116001)(83506001)(50986999)(105586002)(80022001)(77982001)(101416001)(85852003)(54356999)(90102001)(87936001)(110136001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB102; H:AMSPR06MB104.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D01CE3D45ED24oscargonzalezdediostelefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/N9FMGnNC1_hMt2C2-uyEpf4Cfjw X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 10:11:20 -0000 --_000_D01CE3D45ED24oscargonzalezdediostelefonicacom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have also just joined the discussions per Lou's mail to ccamp and gone th= rough the mail archive, which I've found very interesting and constructive. One of the concerns that has been raised and shared by several people is th= e risk associated to splitting the architecture from the protocol work. One= the one hand, in a very well narrowed down scope, having both in the same = place works well (and produces nice running code). Of course, no friction a= mong architecture and protocol work (same people) However, when the scope i= s wider and the work needed is so big, there is a big risk, that WG contrib= utors focus on one WG, don't care about the others and repeated work and in= consistencies appear. A very good example is PCE and CCAMP (or MPLS for the packet world). Work i= n CCAMP has avoided for a long time to deal with PCE, just because it was i= n a different WG. This leads to having problems which are solved taking int= o account only part of the pieces in the equation. For example, one of the = latest discussed problems is the interconnection of TE domains. For a many = signaling and path computation had their own solutions, with an unclear rel= ation between them. Lately, Adrian's draft to tackle that problem included = considerations about path computation, with very good criteria. And it need= s also to consider the dissemination of Traffic Engineering in the equation= , adding more meat.. and thus needing to consider routing protocols. Summing up, from my very humble point of view, having a joint approach in t= he architecture for Traffic Engineering, in which signaling, path computati= on and routing are considered together, is positive and gives consistency. = I fully support Lou's view on the need of consistency. A different question= is how much work is needed just for this. Mechanisms, and the protocol ext= ensions needed to support the mechanisms, should be dealt in specific WGs = (as they are now). I just wonder what happens in the case of a mechanism that needs to enhance= functionalities in protocols of two different WGs. Will that lead to three= documents, one in TEAS, and one per protocol-specific extension? Regarding the possible content of TEAS, in addition to the architecture wor= k, can be home to informational RFCs / BCPS in which use cases using mechan= isms of different protocols are explained. =D3scar ________________________________ 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 --_000_D01CE3D45ED24oscargonzalezdediostelefonicacom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi all,

I have= also just joined the discussions per Lou’s mail to ccamp and gone th= rough the mail archive, which I’ve found very interesting and constru= ctive.

One of= the concerns that has been raised and shared by several people is the risk= associated to splitting the architecture from the protocol work. One the o= ne hand, in a very well narrowed down scope, having both in the same place works well (and produces nice running= code). Of course, no friction among architecture and protocol work (same p= eople) However, when the scope is wider and the work needed is so big, ther= e is a big risk, that WG contributors focus on one WG, don’t care about the others and repeated work and i= nconsistencies appear. 

A very= good example is PCE and CCAMP (or MPLS for the packet world). Work in CCAM= P has avoided for a long time to deal with PCE, just because it was in a di= fferent WG. This leads to having problems which are solved taking into account only part of the pieces in the equati= on. For example, one of the latest discussed problems is the interconnectio= n of TE domains. For a many signaling and path computation had their own so= lutions, with an unclear relation between them. Lately, Adrian’s draft to tackle that problem included= considerations about path computation, with very good criteria. And it nee= ds also to consider the dissemination of Traffic Engineering in the equatio= n, adding more meat.. and thus needing to consider routing protocols. 

Summin= g up, from my very humble point of view, having a joint approach in the arc= hitecture for Traffic Engineering, in which signaling, path computation and= routing are considered together, is positive and gives consistency. I fully support Lou’s view on the ne= ed of consistency. A different question is how much work is needed just for= this. Mechanisms, and the protocol extensions needed to support the mechan= isms,  should be dealt in specific WGs (as they are now). 

I just= wonder what happens in the case of a mechanism that needs to enhance funct= ionalities in protocols of two different WGs. Will that lead to three docum= ents, one in TEAS, and one per protocol-specific extension? 

Regard= ing the possible content of TEAS, in addition to the architecture work= , can be home to informational RFCs / BCPS in which use cases using mechani= sms of different protocols are explained.

=D3sca= r 


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 e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma 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 communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have 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, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_D01CE3D45ED24oscargonzalezdediostelefonicacom_-- From nobody Fri Aug 22 07:57:11 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCA71A031C for ; Fri, 22 Aug 2014 07:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 Wq64Srk1m1XM for ; Fri, 22 Aug 2014 07:57:05 -0700 (PDT) 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 2B5041A030B for ; Fri, 22 Aug 2014 07:57:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIQ15100; Fri, 22 Aug 2014 14:57:02 +0000 (GMT) Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 22 Aug 2014 15:57:01 +0100 Received: from DFWEML704-CHM.china.huawei.com ([10.193.5.141]) by dfweml701-chm.china.huawei.com ([169.254.1.129]) with mapi id 14.03.0158.001; Fri, 22 Aug 2014 07:56:50 -0700 From: Leeyoung To: OSCAR GONZALEZ DE DIOS , "routing-discussion@ietf.org" Subject: RE: Splitting TE Architecture from protocol work Thread-Topic: Splitting TE Architecture from protocol work Thread-Index: AQHPvfFjYU3l0m888k6Po/OFJuJEnpvcsmuQ Date: Fri, 22 Aug 2014 14:56:49 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C24C62@dfweml704-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.105] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C24C62dfweml704chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/5wlwxAdQWrNp4udxmM2cbS7BBSs X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 14:57:08 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C24C62dfweml704chm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, If TEAS WG were to be separated from protocol work, then how would a new ar= chitecture work (that requires protocol extension) proceed? Would TEAS have= to approve (adopt) this new work before this can be addressed in other WGs= that are responsible for protocol extension? Else, would this work be addr= essed in parallel in other WGs concurrently? If the former is true, certain= works will take a long time to be a standard although there are other meri= ts (as Oscar elaborated) to have TEAS focus on architecture issues that des= erve more time and discussion. This cross-WG relations should be understood more clearly. It would also be good if we understand the draft charter of new WGs as well= as existing WGs that are affected with this reorganization. Young From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of OSCAR GONZALEZ DE DIOS Sent: Friday, August 22, 2014 5:11 AM To: routing-discussion@ietf.org Subject: Splitting TE Architecture from protocol work Hi all, I have also just joined the discussions per Lou's mail to ccamp and gone th= rough the mail archive, which I've found very interesting and constructive. One of the concerns that has been raised and shared by several people is th= e risk associated to splitting the architecture from the protocol work. One= the one hand, in a very well narrowed down scope, having both in the same = place works well (and produces nice running code). Of course, no friction a= mong architecture and protocol work (same people) However, when the scope i= s wider and the work needed is so big, there is a big risk, that WG contrib= utors focus on one WG, don't care about the others and repeated work and in= consistencies appear. A very good example is PCE and CCAMP (or MPLS for the packet world). Work i= n CCAMP has avoided for a long time to deal with PCE, just because it was i= n a different WG. This leads to having problems which are solved taking int= o account only part of the pieces in the equation. For example, one of the = latest discussed problems is the interconnection of TE domains. For a many = signaling and path computation had their own solutions, with an unclear rel= ation between them. Lately, Adrian's draft to tackle that problem included = considerations about path computation, with very good criteria. And it need= s also to consider the dissemination of Traffic Engineering in the equation= , adding more meat.. and thus needing to consider routing protocols. Summing up, from my very humble point of view, having a joint approach in t= he architecture for Traffic Engineering, in which signaling, path computati= on and routing are considered together, is positive and gives consistency. = I fully support Lou's view on the need of consistency. A different question= is how much work is needed just for this. Mechanisms, and the protocol ext= ensions needed to support the mechanisms, should be dealt in specific WGs = (as they are now). I just wonder what happens in the case of a mechanism that needs to enhance= functionalities in protocols of two different WGs. Will that lead to three= documents, one in TEAS, and one per protocol-specific extension? Regarding the possible content of TEAS, in addition to the architecture wor= k, can be home to informational RFCs / BCPS in which use cases using mechan= isms of different protocols are explained. =D3scar ________________________________ 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 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C24C62dfweml704chm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 <= /p>

If TEAS WG were to be sep= arated from protocol work, then how would a new architecture work (that req= uires protocol extension) proceed? Would TEAS have to approve (adopt) this new work before this can be addressed in other WGs that are r= esponsible for protocol extension? Else, would this work be addressed in pa= rallel in other WGs concurrently? If the former is true, certain works will= take a long time to be a standard although there are other merits (as Oscar elaborated) to have TEAS focus o= n architecture issues that deserve more time and discussion.

 <= /p>

This cross-WG relations s= hould be understood more clearly.  

 <= /p>

It would also be good if = we understand the draft charter of new WGs as well as existing WGs that are= affected with this reorganization.

 <= /p>

Young

 <= /p>

From: routing-= discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf Of OSCAR GONZALEZ DE DIOS
Sent: Friday, August 22, 2014 5:11 AM
To: routing-discussion@ietf.org
Subject: Splitting TE Architecture from protocol work

 

Hi all,

 

I have also just joined the= discussions per Lou’s mail to ccamp and gone through the mail archiv= e, which I’ve found very interesting and constructive.

 

One of the concerns that ha= s been raised and shared by several people is the risk associated to splitt= ing the architecture from the protocol work. One the one hand, in a very well narrowed down scope, having both in the same place wo= rks well (and produces nice running code). Of course, no friction among arc= hitecture and protocol work (same people) However, when the scope is wider = and the work needed is so big, there is a big risk, that WG contributors focus on one WG, don’t care abou= t the others and repeated work and inconsistencies appear. =

 

A very good example is PCE = and CCAMP (or MPLS for the packet world). Work in CCAMP has avoided for a l= ong time to deal with PCE, just because it was in a different WG. This leads to having problems which are solved taking into account onl= y part of the pieces in the equation. For example, one of the latest discus= sed problems is the interconnection of TE domains. For a many signaling and= path computation had their own solutions, with an unclear relation between them. Lately, Adrian’s d= raft to tackle that problem included considerations about path computation,= with very good criteria. And it needs also to consider the dissemination o= f Traffic Engineering in the equation, adding more meat.. and thus needing to consider routing protocols. 

 

Summing up, from my very hu= mble point of view, having a joint approach in the architecture for Traffic= Engineering, in which signaling, path computation and routing are considered together, is positive and gives consistency. I fully suppor= t Lou’s view on the need of consistency. A different question is how = much work is needed just for this. Mechanisms, and the protocol extensions = needed to support the mechanisms,  should be dealt in specific WGs (as they are now). 

 

I just wonder what happens = in the case of a mechanism that needs to enhance functionalities in protoco= ls of two different WGs. Will that lead to three documents, one in TEAS, and one per protocol-specific extension? 

 

Regarding the possible cont= ent of TEAS, in addition to the architecture work, can be home to info= rmational RFCs / BCPS in which use cases using mechanisms of different protocols are explained.

 

=D3scar 

 


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 e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma 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 communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have 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, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o<= /o:p>

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C24C62dfweml704chm_-- From nobody Sat Aug 23 21:54:01 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3264D1A6F98 for ; Sat, 23 Aug 2014 21:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 UVb3yEwY7ef0 for ; Sat, 23 Aug 2014 21:53:56 -0700 (PDT) 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 113011A6F8E for ; Sat, 23 Aug 2014 21:53:54 -0700 (PDT) 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 BLS09144; Sun, 24 Aug 2014 04:53:53 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 24 Aug 2014 05:53:52 +0100 Received: from DFWEML703-CHM.china.huawei.com ([10.193.5.130]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Sat, 23 Aug 2014 21:53:45 -0700 From: Linda Dunbar To: "Andrew G. Malis" , "Joel M. Halpern" Subject: RE: Routing Area Tuning - Update Thread-Topic: Routing Area Tuning - Update Thread-Index: Ac+8wyZusCFJ/2FATmmqnraiOjiHgQAO8EmAACIRNAAAPCO+EA== Date: Sun, 24 Aug 2014 04:53:44 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DC248B@dfweml703-chm.china.huawei.com> References: <062701cfbcc3$2a295470$7e7bfd50$@olddog.co.uk> <53F51DF9.5090703@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.211] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645DC248Bdfweml703chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/rPwy6mJagfnV7Glpe0UVMEOTU5c Cc: Adrian Farrel , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 04:53:59 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645DC248Bdfweml703chmchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEuDQoNCkRvZXMgYW55IFdHIGVuZm9yY2UgcHJvcG9zZWQgc29sdXRpb25zIHRvIG1lZXQgdGhl IFdH4oCZcyBlbmRvcnNlZCDigJxyZXF1aXJlbWVudOKAnSBkcmFmdD8gVmVyeSBvZnRlbiwgdGhl IG5ldyBzb2x1dGlvbiBkcmFmdHMgY2FuIGJlIHByb3Bvc2VkIHllYXJzIGFmdGVyIHRoZSBXR+KA mXMgcmVxdWlyZW1lbnQgZHJhZnQgYmVpbmcgcHVibGlzaGVkLiBEbyBwZW9wbGUgc3RpbGwgcmVt ZW1iZXIgd2hhdCBhcmUgc3BlY2lmaWVkIG9uIHRoZSByZXF1aXJlbWVudCBSRkM/DQoNCkxpbmRh DQoNCkZyb206IHJvdXRpbmctZGlzY3Vzc2lvbiBbbWFpbHRvOnJvdXRpbmctZGlzY3Vzc2lvbi1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5kcmV3IEcuIE1hbGlzDQpTZW50OiBUaHVy c2RheSwgQXVndXN0IDIxLCAyMDE0IDk6MzEgQU0NClRvOiBKb2VsIE0uIEhhbHBlcm4NCkNjOiBB ZHJpYW4gRmFycmVsOyByb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBS b3V0aW5nIEFyZWEgVHVuaW5nIC0gVXBkYXRlDQoNCkkgYWdyZWUgd2l0aCBKb2VsIC0gSSB0aGlu ayBwZW9wbGUgZmluZCBpdCBoYXJkIHRvIGdldCBtb3RpdmF0ZWQgdG8gZG8gdGhlIGFyY2hpdGVj dHVyZSBhbmQgcmVxdWlyZW1lbnRzIGlmIHRoZXkgYWxzbyBkb24ndCBnZXQgdG8gcGxheSBhcm91 bmQgd2l0aCB0aGUgcHJvdG9jb2xzICh0aGUgZnVuIHN0dWZmKSwgd2hpbGUgdGhlIHBlb3BsZSBk b2luZyB0aGUgcHJvdG9jb2wgd29yayBhbHNvIHdhbnQgdGhlaXIgaW5wdXQgaW50byB0aGUgYXJj aGl0ZWN0dXJlIGFuZCByZXF1aXJlbWVudHMsIHNpbmNlIHRoZSBjaG9pY2VzIG1hZGUgdGhlcmUg Y29uc3RyYWluIHdoYXQgdGhlIHByb3RvY29sIHdpbGwgbG9vayBsaWtlLiBPZiBjb3Vyc2UsIHlv dSBjb3VsZCBoYXZlIHRoZSBzYW1lIHBlb3BsZSB0cmFtcGluZyBiZXR3ZWVuIHR3byBkaWZmZXJl bnQgV0dzLCBidXQgdGhhdCBzZWVtcyBzaWxseS4NCg0KQ2hlZXJzLA0KQW5keQ0KDQoNCk9uIFdl ZCwgQXVnIDIwLCAyMDE0IGF0IDY6MTUgUE0sIEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxw ZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+IHdyb3RlOg0KSSBhbSBhIGxpdHRs ZSBjb25jZXJuZWQgdGhhdCB0aGUgcHJvcG9zZWQgYXBwcm9hY2ggaGFzIFRFQVMgZG9pbmcgdGhl IHJlcXVpcmVtZW50cyBmb3Igd29yayB0byBiZSBkb25lIGFzIHByb3RvY29sIGluIG90aGVyIFdH cy4gIFdoaWxlIHdlIG1hZGUgdGhhdCB3b3JrLCBmb3IgdmVyeSBnb29kIHJlYXNvbnMsIGluIEtB UlAsIGl0IGlzIGZyZXF1ZW50bHkgYSBzb3VyY2Ugb2YgZnJpY3Rpb24gYW5kIGhpbmRlcmFuY2Uu DQoNCllvdXJzLA0KSm9lbA0KDQoNCk9uIDgvMjAvMTQsIDY6MDcgUE0sIEFkcmlhbiBGYXJyZWwg d3JvdGU6DQpIaSwNCg0KSSB3YW50ZWQgdG8gdGFrZSBhIG1vbWVudCB0byB1cGRhdGUgeW91IGFs bCBvbiBvdXIgcHJvZ3Jlc3MgYW5kIHRvIHBvbGwgeW91IGZvcg0Kc29tZSBtb3JlIG9waW5pb25z Lg0KDQpGaXJzdGx5IHRoZXJlIGlzIGEgc2Vuc2UgdGhhdCB0aGlzIG1heSBhbGwgYmUgYSBmYWl0 IGFjY29tcGxpIHdpdGggdGhlcmUgYmVpbmcNCm5vIHBvaW50IGluIHJhaXNpbmcgYW55IHF1ZXN0 aW9ucyBvciBjb25jZXJucy4gSSdtIHNvcnJ5IGlmIHRoaXMgaXMgaG93IGl0IGNhbWUNCm92ZXIu IFRoZSBBRHMgaGF2ZSBiZWVuIHRoaW5raW5nIGFib3V0IHRoaXMgYW5kIGRpc2N1c3NpbmcgaXQg Zm9yIHF1aXRlIGEgd2hpbGUNCmFuZCB3ZSBzcGVudCBxdWl0ZSBhIGJpdCBvZiB0aW1lIGJlZm9y ZSBhbmQgZHVyaW5nIElFVEYgOTAgc2Vla2luZyBvdXQgZGlmZmVyZW50DQp2aWV3cG9pbnRzIGFu ZCBoYXZpbmcgb3VyIG9waW5pb25zIHNoYXBlZC4gU28gd2UgaGF2ZSBidWlsdCB1cCBzdHJvbmcg dmlld3MsIGJ1dA0Kd2UgZG8gd2FudCB0byBoZWFyIHlvdXIgdmlld3MgYW5kIHdlIHBhcnRpY3Vs YXJseSB3YW50IHRvIGJlIHRvbGQgd2hhdCB3ZSBoYXZlDQpnb3Qgd3JvbmcuDQoNCk9uZSBxdWVz dGlvbiB3ZSBhcmUgc3RpbGwgdGhpbmtpbmcgYWJvdXQgY29uY2VybnMgdGhlIGFycmFuZ2VtZW50 IG9mICBURS1yZWxhdGVkDQp3b3JrIGFjcm9zcyB0aGUgTVBMUywgQ0NBTVAsIGFuZCBQQ0Ugd29y a2luZyBncm91cHMuIEFuIG9wdGlvbiB3ZSBoYWQgZGlzY3Vzc2VkDQpyZXN1bHRlZCBpbiBQQ0Ug dW5jaGFuZ2VkLCBURUFTIHRvIHRha2UgVEUgYXJjaGl0ZWN0dXJlIGFuZCBSU1ZQLVRFLCBhbmQg Q0NBTVANCnRvIGRvIHRlY2hub2xvZ3ktc3BlY2lmaWMgcHJvdG9jb2wgd29yay4gQnV0IHRoZXJl IGlzIGFub3RoZXIgb3B0aW9uIHdoaWNoIHdvdWxkDQpsZWF2ZToNCiAgICBURUFTIC0gVEUgYXJj aGl0ZWN0dXJlIGFuZCByZXF1aXJlbWVudCB3b3JrLCBidXQgbm8gcHJvdG9jb2wgd29yaw0KICAg IFBDRSAtIEFsbCBQQ0VQIHdvcmssIFBDRSBhcHBsaWNhYmlsaXR5IGFuZCByZXF1aXJlbWVudHMs IGJ1dCBQQ0UgYXJjaGl0ZWN0dXJlDQogICAgICAgICAgICAgICBnb2VzIHRvIFRFQVMNCiAgICBS U1ZQLVRFIC0gQWxsIGdlbmVyaWMgcHJvdG9jb2wgd29yayBmb3IgUlNWUC1URSBmcm9tIE1QTFMg YW5kIENDQU1QDQogICAgQ0NBTVAgLSB0ZWNobm9sb2d5LXNwZWNpZmljIHByb3RvY29sIHdvcmsu DQpUaGlzIHRoaW5raW5nIGlzIHNvbWV3aGF0IG1vdGl2YXRlZCBieSB0aGUgd2F5IHRoZSBJR1Ag d29yayBoYXBwZW5zIGF0IHRoZQ0KbW9tZW50IGFuZCBzb21ld2hhdCBieSB0aGUgdGhvdWdodCB0 aGF0IFRFQVMgbWlnaHQgYmUgdG9vIGxhcmdlIGFuZCBoYXZlIHRvbw0KbWFueSBkaXN0cmFjdGlv bnMgaWYgaXQgaGFzIHByb3RvY29sIGFuZCBhcmNoaXRlY3R1cmUsIHdoaWxlIHRoZSBtb3RpdmF0 aW9uIGZvcg0Ka2VlcGluZyAgYXJjaGl0ZWN0dXJlIGFuZCBwcm90b2NvbCB0b2dldGhlciBpbiBU RUFTIGlzIHRoYXQgaXQgcHJvdmlkZXMgZm9yDQpiZXR0ZXIgZW5lcmd5IGFuZCBpbnRlcmFjdGlv bi4NCg0KV2Ugd291bGQgbGlrZSB0byBoZWFyIHlvdXIgb3BpbmlvbnMgYW5kIGdldCBhIGJldHRl ciBzZW5zZSBvZiB0aGUgY29uc2Vuc3VzDQphcm91bmQgVEVBUy4NCg0KQXQgdGhlIG1vbWVudCBB bGlhIGFuZCBJIGFyZSByZWNvdmVyaW5nIGZyb20gVG9yb250byBhbmQgaGFuZGxpbmcgdmFjYXRp b25zLCBidXQNCndlIGhhdmUgZm9ybWVkIGEgcm91Z2ggb3JkZXIgZm9yIHdvcmtpbmcgb24gdGhl IHdvcmtpbmcgZ3JvdXBzLg0KDQpGaXJzdCB1cCBpcyB0aGUgUlRHV0cgYmVjYXVzZSB0aGF0IGlz IGEgcmVsYXRpdmVseSBzdHJhaWdodGZvcndhcmQgdHdlYWsgdG8gYW4NCmV4aXN0aW5nIGNoYXJ0 ZXIuDQpUaGVuIHdlIHBsYW4gdG8gZ3JvdXAgdG9nZXRoZXIge0wyVlBOLCBMM1ZQTiwgUFdFMywg TlZPM30gYmVjb21pbmcge1BBTFMsIEJFU1MsDQpOVk8zfQ0KVGhlbiB3ZSB3aWxsIGxvb2sgdG8g d29yayBvdXQgaG93IHRvIGhhbmRsZSB0aGUgVEUgZWxlbWVudHMgZGlzY3Vzc2VkIGFib3ZlLg0K DQpXZSdsbCBiZSB0YWtpbmcgYSBiaXQgb2YgYSB0d28tcHJvbmdlZCBhcHByb2FjaDogaWRlbnRp ZnkgY2hhaXIgY2FuZGlkYXRlczsgc3Bpbg0KdXAgZHJhZnQgY2hhcnRlcnMuDQpXZSBwbGFuIHRv IHdvcmsgb24gdGhlIGRyYWZ0IGNoYXJ0ZXJzIHdpdGggdGhlIGZ1dHVyZSBjaGFpcnMgYW5kIHB1 dCB0aGVtIG91dCBvbg0KdGhpcyBsaXN0IGFuZCBvbiB0aGUgcmVsZXZhbnQgV0cgbWFpbGluZyBs aXN0cyBhcyBzb29uIGFzIHdlIGhhdmUgdGhlbSB3aXRoIHRoZQ0KYWltIG9mIGdldHRpbmcgcmV2 aWV3IGFuZCBkaXNjdXNzaW9uLg0KDQpPbmUgbGFzdCBwb2ludC4gQWxsIFdHcyBzaG91bGQgY29u dGludWUgdG8gb3BlcmF0ZSBhY2NvcmRpbmcgdG8gdGhlaXIgY3VycmVudA0KY2hhcnRlcnMuIFdl IGNhbiBoYW5kbGUgdGhlIHRyYW5zaXRpb24gaWYvd2hlbiBpdCBoYXBwZW5zLCBidXQgdGhpcyB3 b3JrIHNob3VsZA0Kbm90IGdldCBpbiB0aGUgd2F5IG9mIHJlYWwgdGVjaG5pY2FsIHdvcmsuDQoN ClBsZWFzZSBsZXQgdXMga25vdyB3aGF0IHlvdSB0aGluay4NCg0KQWRyaWFuLA0KcGVyIHBybyBB bGlhDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpy b3V0aW5nLWRpc2N1c3Npb24gbWFpbGluZyBsaXN0DQpyb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5v cmc8bWFpbHRvOnJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcm91dGluZy1kaXNjdXNzaW9uDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpyb3V0aW5nLWRpc2N1c3Npb24gbWFp bGluZyBsaXN0DQpyb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmc8bWFpbHRvOnJvdXRpbmctZGlz Y3Vzc2lvbkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cm91dGluZy1kaXNjdXNzaW9uDQoNCg== --_000_4A95BA014132FF49AE685FAB4B9F17F645DC248Bdfweml703chmchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiYjNDM7MS4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+RG9lcyBhbnkgV0cgZW5mb3JjZSBwcm9wb3NlZCBzb2x1dGlvbnMgdG8gbWVl dCB0aGUgV0figJlzIGVuZG9yc2VkIOKAnHJlcXVpcmVtZW504oCdIGRyYWZ0PyBWZXJ5IG9mdGVu LCB0aGUgbmV3IHNvbHV0aW9uIGRyYWZ0cyBjYW4gYmUgcHJvcG9zZWQgeWVhcnMgYWZ0ZXIgdGhl IFdH4oCZcw0KIHJlcXVpcmVtZW50IGRyYWZ0IGJlaW5nIHB1Ymxpc2hlZC4gRG8gcGVvcGxlIHN0 aWxsIHJlbWVtYmVyIHdoYXQgYXJlIHNwZWNpZmllZCBvbiB0aGUgcmVxdWlyZW1lbnQgUkZDPw0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5MaW5kYQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiByb3V0aW5nLWRpc2N1c3Npb24gW21haWx0 bzpyb3V0aW5nLWRpc2N1c3Npb24tYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+QW5kcmV3IEcuIE1hbGlzPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBdWd1c3QgMjEs IDIwMTQgOTozMSBBTTxicj4NCjxiPlRvOjwvYj4gSm9lbCBNLiBIYWxwZXJuPGJyPg0KPGI+Q2M6 PC9iPiBBZHJpYW4gRmFycmVsOyByb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFJvdXRpbmcgQXJlYSBUdW5pbmcgLSBVcGRhdGU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgd2l0aCBKb2VsIC0gSSB0 aGluayBwZW9wbGUgZmluZCBpdCBoYXJkIHRvIGdldCBtb3RpdmF0ZWQgdG8gZG8gdGhlIGFyY2hp dGVjdHVyZSBhbmQgcmVxdWlyZW1lbnRzIGlmIHRoZXkgYWxzbyBkb24ndCBnZXQgdG8gcGxheSBh cm91bmQgd2l0aCB0aGUgcHJvdG9jb2xzICh0aGUgZnVuIHN0dWZmKSwgd2hpbGUgdGhlIHBlb3Bs ZSBkb2luZyB0aGUgcHJvdG9jb2wgd29yayBhbHNvIHdhbnQgdGhlaXINCiBpbnB1dCBpbnRvIHRo ZSBhcmNoaXRlY3R1cmUgYW5kIHJlcXVpcmVtZW50cywgc2luY2UgdGhlIGNob2ljZXMgbWFkZSB0 aGVyZSBjb25zdHJhaW4gd2hhdCB0aGUgcHJvdG9jb2wgd2lsbCBsb29rIGxpa2UuIE9mIGNvdXJz ZSwgeW91IGNvdWxkIGhhdmUgdGhlIHNhbWUgcGVvcGxlIHRyYW1waW5nIGJldHdlZW4gdHdvIGRp ZmZlcmVudCBXR3MsIGJ1dCB0aGF0IHNlZW1zIHNpbGx5LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gV2VkLCBBdWcgMjAsIDIwMTQgYXQgNjoxNSBQTSwgSm9lbCBNLiBIYWxwZXJuICZsdDs8 YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBq b2VsaGFscGVybi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgYW0gYSBsaXR0bGUgY29uY2VybmVkIHRoYXQgdGhlIHByb3Bvc2VkIGFwcHJv YWNoIGhhcyBURUFTIGRvaW5nIHRoZSByZXF1aXJlbWVudHMgZm9yIHdvcmsgdG8gYmUgZG9uZSBh cyBwcm90b2NvbCBpbiBvdGhlciBXR3MuJm5ic3A7IFdoaWxlIHdlIG1hZGUgdGhhdCB3b3JrLCBm b3IgdmVyeSBnb29kIHJlYXNvbnMsIGluIEtBUlAsIGl0IGlzIGZyZXF1ZW50bHkgYSBzb3VyY2Ug b2YgZnJpY3Rpb24gYW5kIGhpbmRlcmFuY2UuPGJyPg0KPGJyPg0KWW91cnMsPGJyPg0KSm9lbDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnI+DQpPbiA4LzIwLzE0LCA2OjA3IFBNLCBBZHJpYW4gRmFycmVsIHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5I aSw8YnI+DQo8YnI+DQpJIHdhbnRlZCB0byB0YWtlIGEgbW9tZW50IHRvIHVwZGF0ZSB5b3UgYWxs IG9uIG91ciBwcm9ncmVzcyBhbmQgdG8gcG9sbCB5b3UgZm9yPGJyPg0Kc29tZSBtb3JlIG9waW5p b25zLjxicj4NCjxicj4NCkZpcnN0bHkgdGhlcmUgaXMgYSBzZW5zZSB0aGF0IHRoaXMgbWF5IGFs bCBiZSBhIGZhaXQgYWNjb21wbGkgd2l0aCB0aGVyZSBiZWluZzxicj4NCm5vIHBvaW50IGluIHJh aXNpbmcgYW55IHF1ZXN0aW9ucyBvciBjb25jZXJucy4gSSdtIHNvcnJ5IGlmIHRoaXMgaXMgaG93 IGl0IGNhbWU8YnI+DQpvdmVyLiBUaGUgQURzIGhhdmUgYmVlbiB0aGlua2luZyBhYm91dCB0aGlz IGFuZCBkaXNjdXNzaW5nIGl0IGZvciBxdWl0ZSBhIHdoaWxlPGJyPg0KYW5kIHdlIHNwZW50IHF1 aXRlIGEgYml0IG9mIHRpbWUgYmVmb3JlIGFuZCBkdXJpbmcgSUVURiA5MCBzZWVraW5nIG91dCBk aWZmZXJlbnQ8YnI+DQp2aWV3cG9pbnRzIGFuZCBoYXZpbmcgb3VyIG9waW5pb25zIHNoYXBlZC4g U28gd2UgaGF2ZSBidWlsdCB1cCBzdHJvbmcgdmlld3MsIGJ1dDxicj4NCndlIGRvIHdhbnQgdG8g aGVhciB5b3VyIHZpZXdzIGFuZCB3ZSBwYXJ0aWN1bGFybHkgd2FudCB0byBiZSB0b2xkIHdoYXQg d2UgaGF2ZTxicj4NCmdvdCB3cm9uZy48YnI+DQo8YnI+DQpPbmUgcXVlc3Rpb24gd2UgYXJlIHN0 aWxsIHRoaW5raW5nIGFib3V0IGNvbmNlcm5zIHRoZSBhcnJhbmdlbWVudCBvZiZuYnNwOyBURS1y ZWxhdGVkPGJyPg0Kd29yayBhY3Jvc3MgdGhlIE1QTFMsIENDQU1QLCBhbmQgUENFIHdvcmtpbmcg Z3JvdXBzLiBBbiBvcHRpb24gd2UgaGFkIGRpc2N1c3NlZDxicj4NCnJlc3VsdGVkIGluIFBDRSB1 bmNoYW5nZWQsIFRFQVMgdG8gdGFrZSBURSBhcmNoaXRlY3R1cmUgYW5kIFJTVlAtVEUsIGFuZCBD Q0FNUDxicj4NCnRvIGRvIHRlY2hub2xvZ3ktc3BlY2lmaWMgcHJvdG9jb2wgd29yay4gQnV0IHRo ZXJlIGlzIGFub3RoZXIgb3B0aW9uIHdoaWNoIHdvdWxkPGJyPg0KbGVhdmU6PGJyPg0KJm5ic3A7 ICZuYnNwOyBURUFTIC0gVEUgYXJjaGl0ZWN0dXJlIGFuZCByZXF1aXJlbWVudCB3b3JrLCBidXQg bm8gcHJvdG9jb2wgd29yazxicj4NCiZuYnNwOyAmbmJzcDsgUENFIC0gQWxsIFBDRVAgd29yaywg UENFIGFwcGxpY2FiaWxpdHkgYW5kIHJlcXVpcmVtZW50cywgYnV0IFBDRSBhcmNoaXRlY3R1cmU8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Z29lcyB0byBURUFTPGJyPg0KJm5ic3A7ICZuYnNwOyBSU1ZQLVRFIC0gQWxsIGdlbmVyaWMg cHJvdG9jb2wgd29yayBmb3IgUlNWUC1URSBmcm9tIE1QTFMgYW5kIENDQU1QPGJyPg0KJm5ic3A7 ICZuYnNwOyBDQ0FNUCAtIHRlY2hub2xvZ3ktc3BlY2lmaWMgcHJvdG9jb2wgd29yay48YnI+DQpU aGlzIHRoaW5raW5nIGlzIHNvbWV3aGF0IG1vdGl2YXRlZCBieSB0aGUgd2F5IHRoZSBJR1Agd29y ayBoYXBwZW5zIGF0IHRoZTxicj4NCm1vbWVudCBhbmQgc29tZXdoYXQgYnkgdGhlIHRob3VnaHQg dGhhdCBURUFTIG1pZ2h0IGJlIHRvbyBsYXJnZSBhbmQgaGF2ZSB0b288YnI+DQptYW55IGRpc3Ry YWN0aW9ucyBpZiBpdCBoYXMgcHJvdG9jb2wgYW5kIGFyY2hpdGVjdHVyZSwgd2hpbGUgdGhlIG1v dGl2YXRpb24gZm9yPGJyPg0Ka2VlcGluZyZuYnNwOyBhcmNoaXRlY3R1cmUgYW5kIHByb3RvY29s IHRvZ2V0aGVyIGluIFRFQVMgaXMgdGhhdCBpdCBwcm92aWRlcyBmb3I8YnI+DQpiZXR0ZXIgZW5l cmd5IGFuZCBpbnRlcmFjdGlvbi48YnI+DQo8YnI+DQpXZSB3b3VsZCBsaWtlIHRvIGhlYXIgeW91 ciBvcGluaW9ucyBhbmQgZ2V0IGEgYmV0dGVyIHNlbnNlIG9mIHRoZSBjb25zZW5zdXM8YnI+DQph cm91bmQgVEVBUy48YnI+DQo8YnI+DQpBdCB0aGUgbW9tZW50IEFsaWEgYW5kIEkgYXJlIHJlY292 ZXJpbmcgZnJvbSBUb3JvbnRvIGFuZCBoYW5kbGluZyB2YWNhdGlvbnMsIGJ1dDxicj4NCndlIGhh dmUgZm9ybWVkIGEgcm91Z2ggb3JkZXIgZm9yIHdvcmtpbmcgb24gdGhlIHdvcmtpbmcgZ3JvdXBz Ljxicj4NCjxicj4NCkZpcnN0IHVwIGlzIHRoZSBSVEdXRyBiZWNhdXNlIHRoYXQgaXMgYSByZWxh dGl2ZWx5IHN0cmFpZ2h0Zm9yd2FyZCB0d2VhayB0byBhbjxicj4NCmV4aXN0aW5nIGNoYXJ0ZXIu PGJyPg0KVGhlbiB3ZSBwbGFuIHRvIGdyb3VwIHRvZ2V0aGVyIHtMMlZQTiwgTDNWUE4sIFBXRTMs IE5WTzN9IGJlY29taW5nIHtQQUxTLCBCRVNTLDxicj4NCk5WTzN9PGJyPg0KVGhlbiB3ZSB3aWxs IGxvb2sgdG8gd29yayBvdXQgaG93IHRvIGhhbmRsZSB0aGUgVEUgZWxlbWVudHMgZGlzY3Vzc2Vk IGFib3ZlLjxicj4NCjxicj4NCldlJ2xsIGJlIHRha2luZyBhIGJpdCBvZiBhIHR3by1wcm9uZ2Vk IGFwcHJvYWNoOiBpZGVudGlmeSBjaGFpciBjYW5kaWRhdGVzOyBzcGluPGJyPg0KdXAgZHJhZnQg Y2hhcnRlcnMuPGJyPg0KV2UgcGxhbiB0byB3b3JrIG9uIHRoZSBkcmFmdCBjaGFydGVycyB3aXRo IHRoZSBmdXR1cmUgY2hhaXJzIGFuZCBwdXQgdGhlbSBvdXQgb248YnI+DQp0aGlzIGxpc3QgYW5k IG9uIHRoZSByZWxldmFudCBXRyBtYWlsaW5nIGxpc3RzIGFzIHNvb24gYXMgd2UgaGF2ZSB0aGVt IHdpdGggdGhlPGJyPg0KYWltIG9mIGdldHRpbmcgcmV2aWV3IGFuZCBkaXNjdXNzaW9uLjxicj4N Cjxicj4NCk9uZSBsYXN0IHBvaW50LiBBbGwgV0dzIHNob3VsZCBjb250aW51ZSB0byBvcGVyYXRl IGFjY29yZGluZyB0byB0aGVpciBjdXJyZW50PGJyPg0KY2hhcnRlcnMuIFdlIGNhbiBoYW5kbGUg dGhlIHRyYW5zaXRpb24gaWYvd2hlbiBpdCBoYXBwZW5zLCBidXQgdGhpcyB3b3JrIHNob3VsZDxi cj4NCm5vdCBnZXQgaW4gdGhlIHdheSBvZiByZWFsIHRlY2huaWNhbCB3b3JrLjxicj4NCjxicj4N ClBsZWFzZSBsZXQgdXMga25vdyB3aGF0IHlvdSB0aGluay48YnI+DQo8YnI+DQpBZHJpYW4sPGJy Pg0KcGVyIHBybyBBbGlhPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpyb3V0aW5nLWRpc2N1c3Npb24gbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOnJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvdXRpbmctZGlzY3Vzc2lvbiIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm91dGlu Zy1kaXNjdXNzaW9uPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpy b3V0aW5nLWRpc2N1c3Npb24gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJvdXRp bmctZGlzY3Vzc2lvbkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJvdXRpbmctZGlzY3Vzc2lv bkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3JvdXRpbmctZGlzY3Vzc2lvbiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm91dGluZy1kaXNjdXNzaW9uPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4A95BA014132FF49AE685FAB4B9F17F645DC248Bdfweml703chmchi_-- From nobody Sun Aug 24 20:19:29 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DBE1A89E1 for ; Sun, 24 Aug 2014 20:19:27 -0700 (PDT) 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, 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 INFGyaBieL4d for ; Sun, 24 Aug 2014 20:19:26 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id DB4801A89E0 for ; Sun, 24 Aug 2014 20:19:25 -0700 (PDT) Received: (qmail 23348 invoked by uid 0); 25 Aug 2014 03:19:19 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 25 Aug 2014 03:19:19 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id ixKC1o0012SSUrH01xKFj2; Mon, 25 Aug 2014 03:19:18 -0600 X-Authority-Analysis: v=2.1 cv=KvHehwmN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wCs-e6rjr3gA:10 a=B81tkwS81K4A:10 a=z_jJJMDF7VoA:10 a=HFCU6gKsb0MA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ABeY7kuGAAAA:8 a=48vgC7mUAAAA:8 a=dBlL-7-4U1aSBd2e0ZoA:9 a=QEXdDO2ut3YA:10 a=chC_agHSu74A:10 a=lZB815dzVvQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:Content-Transfer-Encoding:Date:MIME-Version:Message-ID:In-Reply-To:References:Cc:To:Subject:From; bh=c7bT4JrtMelmh6FL+b9YppKyg11eWRZh3XB5pynIliM=; b=c0VN1nd0JkiU804chDt3WzwmQmjj1eN0ArLHxfBaCXr/MvSRzsgW1PaoI2wOveVP4SpgKlA4L+rnlQ5fSgGoAudMRzK2yalV/e3DXGRHdzRW75qToQkqWzoqorp2ouHT; Received: from box313.bluehost.com ([69.89.31.113]:35085 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XLkoL-0005Cl-93; Sun, 24 Aug 2014 21:19:13 -0600 From: Lou Berger Subject: Keeping TE architecture in sync? (Was: Re: Routing Area Tuning - Update) To: "Andrew G. Malis" References: <062701cfbcc3$2a295470$7e7bfd50$@olddog.co.uk> <53F51DF9.5090703@joelhalpern.com> In-Reply-To: CAA=duU2mq0XBTBgMhJtcH43qXqxs-ZQyWTgJfz4AcZfBTGg9Jw@mail.gmail.com Message-ID: <398febb5.1408935718161@mail.labn.net> MIME-Version: 1.0 Date: Sun, 24 Aug 2014 23:19:08 -0400 (EDT) User-Agent: ProfiMailGo/4.16.00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 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/routing-discussion/3mkptGlfYAk4f9_Cvlwc7LvmhO8 Cc: Adrian Farrel , "Joel M. Halpern" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 03:19:28 -0000 Oscar alluded to some of the tensions in keeping PCE and ccamp in sync toda= te. TEAS and PCE will have more direct overlap (than PCE and ccamp). What's the plan for ensuring the two efforts stay in sync? What happens wh= en there are conflicting architecture models and in which group does the al= ignment/resolution take place? I had suggested that the solution was for TEAS be the authoritative WG for = TE. Do folks think this is a good/bad idea? Lou On August 21, 2014, 10:30 AM, Andrew G. Malis wrote: > I agree with Joel - I think people find it hard to get motivated to do th= e architecture and requirements if they also don't get to play around with = the protocols (the fun stuff), while the people doing the protocol work als= o want their input into the architecture and requirements, since the choice= s made there constrain what the protocol will look like. Of course, you cou= ld have the same people tramping between two different WGs, but that seems = silly. >=20 > Cheers, > Andy >=20 >=20 >=20 > On Wed, Aug 20, 2014 at 6:15 PM, Joel M. Halpern <> jmh@joelhalpern.com> = > wrote: > > I am a little concerned that the proposed approach has TEAS doing the r= equirements for work to be done as protocol in other WGs.=C2=A0 While we ma= de that work, for very good reasons, in KARP, it is frequently a source of = friction and hinderance. > >=20 > > Yours, > > Joel > >=20 > >=20 > > On 8/20/14, 6:07 PM, Adrian Farrel wrote: > > > Hi, > > >=20 > > > I wanted to take a moment to update you all on our progress and to po= ll you for > > > some more opinions. > > >=20 > > > Firstly there is a sense that this may all be a fait accompli with th= ere being > > > no point in raising any questions or concerns. I'm sorry if this is h= ow it came > > > over. The ADs have been thinking about this and discussing it for qui= te a while > > > and we spent quite a bit of time before and during IETF 90 seeking ou= t different > > > viewpoints and having our opinions shaped. So we have built up strong= views, but > > > we do want to hear your views and we particularly want to be told wha= t we have > > > got wrong. > > >=20 > > > One question we are still thinking about concerns the arrangement of= =C2=A0 TE-related > > > work across the MPLS, CCAMP, and PCE working groups. An option we had= discussed > > > resulted in PCE unchanged, TEAS to take TE architecture and RSVP-TE, = and CCAMP > > > to do technology-specific protocol work. But there is another option = which would > > > leave: > > > =C2=A0 =C2=A0 TEAS - TE architecture and requirement work, but no pro= tocol work > > > =C2=A0 =C2=A0 PCE - All PCEP work, PCE applicability and requirements= , but PCE architecture > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goes to TEAS > > > =C2=A0 =C2=A0 RSVP-TE - All generic protocol work for RSVP-TE from MP= LS and CCAMP > > > =C2=A0 =C2=A0 CCAMP - technology-specific protocol work. > > > This thinking is somewhat motivated by the way the IGP work happens a= t the > > > moment and somewhat by the thought that TEAS might be too large and h= ave too > > > many distractions if it has protocol and architecture, while the moti= vation for > > > keeping=C2=A0 architecture and protocol together in TEAS is that it p= rovides for > > > better energy and interaction. > > >=20 > > > We would like to hear your opinions and get a better sense of the con= sensus > > > around TEAS. > > >=20 > > > At the moment Alia and I are recovering from Toronto and handling vac= ations, but > > > we have formed a rough order for working on the working groups. > > >=20 > > > First up is the RTGWG because that is a relatively straightforward tw= eak to an > > > existing charter. > > > Then we plan to group together {L2VPN, L3VPN, PWE3, NVO3} becoming {P= ALS, BESS, > > > NVO3} > > > Then we will look to work out how to handle the TE elements discussed= above. > > >=20 > > > We'll be taking a bit of a two-pronged approach: identify chair candi= dates; spin > > > up draft charters. > > > We plan to work on the draft charters with the future chairs and put = them out on > > > this list and on the relevant WG mailing lists as soon as we have the= m with the > > > aim of getting review and discussion. > > >=20 > > > One last point. All WGs should continue to operate according to their= current > > > charters. We can handle the transition if/when it happens, but this w= ork should > > > not get in the way of real technical work. > > >=20 > > > Please let us know what you think. > > >=20 > > > Adrian, > > > per pro Alia > > >=20 > > > _______________________________________________ > > > routing-discussion mailing list > > > routing-discussion@ietf.org > > >=20 > > > https://www.ietf.org/mailman/listinfo/routing-discussion > > >=20 > > >=20 > >=20 > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > >=20 > > https://www.ietf.org/mailman/listinfo/routing-discussion > >=20 >=20 >=20 >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Sun Aug 24 22:00:55 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA661A8A0C for ; Sun, 24 Aug 2014 22:00:54 -0700 (PDT) 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 lES270jQRKkX for ; Sun, 24 Aug 2014 22:00:49 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 060071A8A13 for ; Sun, 24 Aug 2014 22:00:47 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id v1so10429194yhn.41 for ; Sun, 24 Aug 2014 22:00:47 -0700 (PDT) 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 :cc:content-type; bh=aUCR/C8yVgVVOI0UCBV2zu5alCqQ2EaU4ArTa3TdbLM=; b=vudqyvfx9VaLZLcp3Y3O6/SToTNzlgCADh9gIeXkOwtIRXXvkuvOakYMHV3sDG82/I 1HhL8khkEEp43YWBWdNjf5805EBhL9Cfffy/5sLnNHsr2dKNsRC2eKfcZvX+z436EozW XRbxDz/Ch/wBtsVvgEhexhbaqBb294HdedecAUUVoMahvoldvQah+jrvNAS1ASapeX1g qST7g/6oO111JsU4vSwPeELURsjFsMRHhb2lM85gPxvDDnjlE7XkxYkv4yVn4+O9UJ9R MiAQzWuirbFHlq8ILQTyUAWOPc7G1UlLxGu51tG4aSV6zf5PbsgPjqfFImhOC1VWmzig 9kgw== MIME-Version: 1.0 X-Received: by 10.236.117.196 with SMTP id j44mr21252162yhh.78.1408942846785; Sun, 24 Aug 2014 22:00:46 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Sun, 24 Aug 2014 22:00:46 -0700 (PDT) In-Reply-To: <398febb5.1408935718161@mail.labn.net> References: <062701cfbcc3$2a295470$7e7bfd50$@olddog.co.uk> <53F51DF9.5090703@joelhalpern.com> <398febb5.1408935718161@mail.labn.net> Date: Mon, 25 Aug 2014 07:00:46 +0200 Message-ID: Subject: Re: Keeping TE architecture in sync? (Was: Re: Routing Area Tuning - Update) From: Abdussalam Baryun To: Lou Berger Content-Type: multipart/alternative; boundary=20cf3011e35be43c9e05016d11b6 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/_feRBcIX4WG4BjH5VpQ9-I6esMY Cc: Adrian Farrel , "Joel M. Halpern" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 05:00:54 -0000 --20cf3011e35be43c9e05016d11b6 Content-Type: text/plain; charset=UTF-8 On Monday, August 25, 2014, Lou Berger wrote: > > Oscar alluded to some of the tensions in keeping PCE and ccamp in sync > todate. TEAS and PCE will have more direct overlap (than PCE and ccamp). > > What's the plan for ensuring the two efforts stay in sync? What happens > when there are conflicting architecture models and in which group does the > alignment/resolution take place? I think All IETF needs to sync related efforts/works, which is done through its LC and IESG reviews. > > I had suggested that the solution was for TEAS be the authoritative WG for > TE. Do folks think this is a good/bad idea? I don't know how the suggested authoritative WG will work with other WGs, not sure of the procedure. I think that authoritative job is the AD responsibility. AB --20cf3011e35be43c9e05016d11b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, August 25, 2014, Lou Berger wrote:

Oscar alluded to some of the tensions in keeping PCE and ccamp in sync toda= te. TEAS and PCE will have more direct overlap (than PCE and ccamp).

What's the plan for ensuring the two efforts stay in sync?=C2=A0 What h= appens when there are conflicting architecture models and in which group do= es the alignment/resolution take place?

I t= hink=C2=A0All IETF needs to sync related=C2=A0efforts/works, which is done = through its LC and IESG reviews.=C2=A0
=C2=A0

I had suggested that the solution was for TEAS be the authoritative WG for = TE. Do folks think this is a good/bad idea?

=C2=A0I don't know how the suggested=C2=A0authoritative WG will work w= ith other WGs, not sure of the procedure. I think that authoritative job=C2= =A0is the AD responsibility.=C2=A0

AB
--20cf3011e35be43c9e05016d11b6-- From nobody Mon Aug 25 08:19:18 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF721A909E for ; Mon, 25 Aug 2014 08:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 L-DvcP87jTnL for ; Mon, 25 Aug 2014 08:19:11 -0700 (PDT) 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 433F31A90C4 for ; Mon, 25 Aug 2014 08:18:34 -0700 (PDT) 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 BIS31711; Mon, 25 Aug 2014 15:18:32 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Aug 2014 16:18:29 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Mon, 25 Aug 2014 08:18:17 -0700 From: Leeyoung To: Abdussalam Baryun , Lou Berger Subject: RE: Keeping TE architecture in sync? (Was: Re: Routing Area Tuning - Update) Thread-Topic: Keeping TE architecture in sync? (Was: Re: Routing Area Tuning - Update) Thread-Index: AQHPwBNsPzEi2wTPvUqUEeHCv+k1k5vhOEEAgAA1nsA= Date: Mon, 25 Aug 2014 15:18:16 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C29CC5@dfweml706-chm> References: <062701cfbcc3$2a295470$7e7bfd50$@olddog.co.uk> <53F51DF9.5090703@joelhalpern.com> <398febb5.1408935718161@mail.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.192.11.132] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C29CC5dfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/XsAEdICos-xwp8NNKPSNIQtc9t4 Cc: Adrian Farrel , "Joel M. Halpern" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 15:19:15 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C29CC5dfweml706chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG91LA0KDQpXaXRoIHRoZSBjdXJyZW50IG9yZ2FuaXphdGlvbiBXRyBzdHJ1Y3R1cmUsIGlu IG9yZGVyIHRvIGdpdmUgVEVBUyBXRyB0aGUgYXV0aG9yaXR5IGZvciBURSB3b3JrLCBpdCByZXF1 aXJlcyBvdGhlciBURS1yZWxhdGVkIFdHcycgY29uc2VudC4gVGhpcyBtYXkgd29yayBvdXQgaW4g dGhlb3J5LiBCdXQgaXQgY29tZXMgdG8gcHJhY3RpY2UsIHdlIG5lZWQgbW9yZSB0aGFuIFdHIGxl dmVsIGNvbnNlbnQuIEFzIEFkYnVzc2FsYW0gYWxsdWRlZCwgdGhpcyBpcyBiZXlvbmQgV0figJlz IHJlc3BvbnNpYmlsaXR5LiBBbmQgSSBiZWxpZXZlIHRoaXMgd291bGQgcG90ZW50aWFsbHkgY2F1 c2Ugc29tZSBjb25mbGljdCBhY3Jvc3MgV0dzIHVubGVzcyBjcm9zcy1XRyByZWxhdGlvbnNoaXAg YW5kIGl0cyBhZ3JlZWQgdXBvbiBjaGFydGVycyB0aGF0IHNwZWxsIG91dCB0aGlzIGRlcGVuZGVu Y3kvYXV0aG9yaXR5IGNsZWFybHkgaGF2ZSB0byB3b3JrIG91dC4NCg0KWW91bmcNCg0KDQoNCg0K RnJvbTogcm91dGluZy1kaXNjdXNzaW9uIFttYWlsdG86cm91dGluZy1kaXNjdXNzaW9uLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBYmR1c3NhbGFtIEJhcnl1bg0KU2VudDogTW9uZGF5 LCBBdWd1c3QgMjUsIDIwMTQgMTI6MDEgQU0NClRvOiBMb3UgQmVyZ2VyDQpDYzogQWRyaWFuIEZh cnJlbDsgSm9lbCBNLiBIYWxwZXJuOyByb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBLZWVwaW5nIFRFIGFyY2hpdGVjdHVyZSBpbiBzeW5jPyAoV2FzOiBSZTogUm91dGlu ZyBBcmVhIFR1bmluZyAtIFVwZGF0ZSkNCg0KDQoNCk9uIE1vbmRheSwgQXVndXN0IDI1LCAyMDE0 LCBMb3UgQmVyZ2VyIHdyb3RlOg0KDQpPc2NhciBhbGx1ZGVkIHRvIHNvbWUgb2YgdGhlIHRlbnNp b25zIGluIGtlZXBpbmcgUENFIGFuZCBjY2FtcCBpbiBzeW5jIHRvZGF0ZS4gVEVBUyBhbmQgUENF IHdpbGwgaGF2ZSBtb3JlIGRpcmVjdCBvdmVybGFwICh0aGFuIFBDRSBhbmQgY2NhbXApLg0KDQpX aGF0J3MgdGhlIHBsYW4gZm9yIGVuc3VyaW5nIHRoZSB0d28gZWZmb3J0cyBzdGF5IGluIHN5bmM/ ICBXaGF0IGhhcHBlbnMgd2hlbiB0aGVyZSBhcmUgY29uZmxpY3RpbmcgYXJjaGl0ZWN0dXJlIG1v ZGVscyBhbmQgaW4gd2hpY2ggZ3JvdXAgZG9lcyB0aGUgYWxpZ25tZW50L3Jlc29sdXRpb24gdGFr ZSBwbGFjZT8NCg0KSSB0aGluayBBbGwgSUVURiBuZWVkcyB0byBzeW5jIHJlbGF0ZWQgZWZmb3J0 cy93b3Jrcywgd2hpY2ggaXMgZG9uZSB0aHJvdWdoIGl0cyBMQyBhbmQgSUVTRyByZXZpZXdzLg0K DQoNCkkgaGFkIHN1Z2dlc3RlZCB0aGF0IHRoZSBzb2x1dGlvbiB3YXMgZm9yIFRFQVMgYmUgdGhl IGF1dGhvcml0YXRpdmUgV0cgZm9yIFRFLiBEbyBmb2xrcyB0aGluayB0aGlzIGlzIGEgZ29vZC9i YWQgaWRlYT8NCg0KIEkgZG9uJ3Qga25vdyBob3cgdGhlIHN1Z2dlc3RlZCBhdXRob3JpdGF0aXZl IFdHIHdpbGwgd29yayB3aXRoIG90aGVyIFdHcywgbm90IHN1cmUgb2YgdGhlIHByb2NlZHVyZS4g SSB0aGluayB0aGF0IGF1dGhvcml0YXRpdmUgam9iIGlzIHRoZSBBRCByZXNwb25zaWJpbGl0eS4N Cg0KQUINCg== --_000_7AEB3D6833318045B4AE71C2C87E8E1729C29CC5dfweml706chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4 dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEwLjVwdDsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBMb3UsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPldpdGggdGhlIGN1cnJlbnQgb3JnYW5pemF0aW9uIFdHIHN0cnVj dHVyZSwgaW4gb3JkZXIgdG8gZ2l2ZSBURUFTIFdHIHRoZSBhdXRob3JpdHkgZm9yIFRFIHdvcmss IGl0IHJlcXVpcmVzIG90aGVyIFRFLXJlbGF0ZWQgV0dzJyBjb25zZW50LiBUaGlzIG1heSB3b3Jr IG91dCBpbiB0aGVvcnkuIEJ1dCBpdCBjb21lcyB0byBwcmFjdGljZSwgd2UgbmVlZCBtb3JlIHRo YW4gV0cgbGV2ZWwgY29uc2VudC4gQXMgQWRidXNzYWxhbQ0KIGFsbHVkZWQsIHRoaXMgaXMgYmV5 b25kIFdH4oCZcyByZXNwb25zaWJpbGl0eS4gQW5kIEkgYmVsaWV2ZSB0aGlzIHdvdWxkIHBvdGVu dGlhbGx5IGNhdXNlIHNvbWUgY29uZmxpY3QgYWNyb3NzIFdHcyB1bmxlc3MgY3Jvc3MtV0cgcmVs YXRpb25zaGlwIGFuZCBpdHMgYWdyZWVkIHVwb24gY2hhcnRlcnMgdGhhdCBzcGVsbCBvdXQgdGhp cyBkZXBlbmRlbmN5L2F1dGhvcml0eSBjbGVhcmx5IGhhdmUgdG8gd29yayBvdXQuDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+WW91bmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g cm91dGluZy1kaXNjdXNzaW9uIFttYWlsdG86cm91dGluZy1kaXNjdXNzaW9uLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFiZHVzc2FsYW0gQmFyeXVuPGJyPg0KPGI+U2Vu dDo8L2I+IE1vbmRheSwgQXVndXN0IDI1LCAyMDE0IDEyOjAxIEFNPGJyPg0KPGI+VG86PC9iPiBM b3UgQmVyZ2VyPGJyPg0KPGI+Q2M6PC9iPiBBZHJpYW4gRmFycmVsOyBKb2VsIE0uIEhhbHBlcm47 IHJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogS2Vl cGluZyBURSBhcmNoaXRlY3R1cmUgaW4gc3luYz8gKFdhczogUmU6IFJvdXRpbmcgQXJlYSBUdW5p bmcgLSBVcGRhdGUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Cjxicj4NCk9uIE1vbmRheSwgQXVndXN0IDI1LCAyMDE0LCBMb3UgQmVyZ2VyIHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KT3NjYXIgYWxsdWRlZCB0byBz b21lIG9mIHRoZSB0ZW5zaW9ucyBpbiBrZWVwaW5nIFBDRSBhbmQgY2NhbXAgaW4gc3luYyB0b2Rh dGUuIFRFQVMgYW5kIFBDRSB3aWxsIGhhdmUgbW9yZSBkaXJlY3Qgb3ZlcmxhcCAodGhhbiBQQ0Ug YW5kIGNjYW1wKS48YnI+DQo8YnI+DQpXaGF0J3MgdGhlIHBsYW4gZm9yIGVuc3VyaW5nIHRoZSB0 d28gZWZmb3J0cyBzdGF5IGluIHN5bmM/Jm5ic3A7IFdoYXQgaGFwcGVucyB3aGVuIHRoZXJlIGFy ZSBjb25mbGljdGluZyBhcmNoaXRlY3R1cmUgbW9kZWxzIGFuZCBpbiB3aGljaCBncm91cCBkb2Vz IHRoZSBhbGlnbm1lbnQvcmVzb2x1dGlvbiB0YWtlIHBsYWNlPzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayZuYnNwO0FsbCBJRVRGIG5lZWRzIHRv IHN5bmMgcmVsYXRlZCZuYnNwO2VmZm9ydHMvd29ya3MsIHdoaWNoIGlzIGRvbmUgdGhyb3VnaCBp dHMgTEMgYW5kIElFU0cgcmV2aWV3cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSSBoYWQgc3VnZ2VzdGVkIHRo YXQgdGhlIHNvbHV0aW9uIHdhcyBmb3IgVEVBUyBiZSB0aGUgYXV0aG9yaXRhdGl2ZSBXRyBmb3Ig VEUuIERvIGZvbGtzIHRoaW5rIHRoaXMgaXMgYSBnb29kL2JhZCBpZGVhPzxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7SSBk b24ndCBrbm93IGhvdyB0aGUgc3VnZ2VzdGVkJm5ic3A7YXV0aG9yaXRhdGl2ZSBXRyB3aWxsIHdv cmsgd2l0aCBvdGhlciBXR3MsIG5vdCBzdXJlIG9mIHRoZSBwcm9jZWR1cmUuIEkgdGhpbmsgdGhh dCBhdXRob3JpdGF0aXZlIGpvYiZuYnNwO2lzIHRoZSBBRCByZXNwb25zaWJpbGl0eS4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QUI8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7AEB3D6833318045B4AE71C2C87E8E1729C29CC5dfweml706chm_-- From nobody Mon Aug 25 08:37:56 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D014D1A0020 for ; Mon, 25 Aug 2014 08:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.308 X-Spam-Level: *** X-Spam-Status: No, score=3.308 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BIZ=0.288, HELO_MISMATCH_BIZ=0.443, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] 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 Ca2_5yF9QShi for ; Mon, 25 Aug 2014 08:37:51 -0700 (PDT) Received: from newdragon.webhostserver.biz (unknown [69.25.137.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 089091A001E for ; Mon, 25 Aug 2014 08:37:51 -0700 (PDT) Received: from localhost ([::1]:58890 helo=[127.0.0.1]) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XLwL7-0002TF-0t; Mon, 25 Aug 2014 19:37:49 +0400 Message-ID: <53FB584B.7020906@labn.net> Date: Mon, 25 Aug 2014 11:37:47 -0400 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: Abdussalam Baryun Subject: Re: Keeping TE architecture in sync? (Was: Re: Routing Area Tuning - Update) References: <062701cfbcc3$2a295470$7e7bfd50$@olddog.co.uk> <53F51DF9.5090703@joelhalpern.com> <398febb5.1408935718161@mail.labn.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/6mxUCDGgSj6fROZ8YmOrkOcZlO4 Cc: Adrian Farrel , "Joel M. Halpern" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: lberger@labn.net List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 15:37:52 -0000 Abdussalam, On 08/25/2014 01:00 AM, Abdussalam Baryun wrote: > > > On Monday, August 25, 2014, Lou Berger wrote: > > > Oscar alluded to some of the tensions in keeping PCE and ccamp in > sync todate. TEAS and PCE will have more direct overlap (than PCE > and ccamp). > > What's the plan for ensuring the two efforts stay in sync? What > happens when there are conflicting architecture models and in which > group does the alignment/resolution take place? > > > I think All IETF needs to sync related efforts/works, which is done > through its LC and IESG reviews. And WG scoping. > > > > I had suggested that the solution was for TEAS be the authoritative > WG for TE. Do folks think this is a good/bad idea? > > > I don't know how the suggested authoritative WG will work with other > WGs, not sure of the procedure. I think that authoritative job is the AD > responsibility. > Ultimately, yes and this is part of why they ultimately get to make the call -- but there's day-to-day operation/coordination that needs to be ironed out. If it's scoped to 1 WG, the chairs (and the 1 WG) get to work out the details. If multiple WGs, it's the ADs (with support of the appropriate WG chairs and WG participants) that need to define/understand the details -- and this what I was asking about. (I have previously suggest that scoping TE architecture to 1 WG as a solution, but that doesn't seem to be getting much support...) Lou > AB From nobody Mon Aug 25 09:44:23 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F26D1A00B7 for ; Mon, 25 Aug 2014 09:44:22 -0700 (PDT) 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 XKI9tlUU9yes for ; Mon, 25 Aug 2014 09:44:20 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1260B1A017A for ; Mon, 25 Aug 2014 09:37:25 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id 19so10481787ykq.16 for ; Mon, 25 Aug 2014 09:37:24 -0700 (PDT) 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 :cc:content-type; bh=c5KBfrXCw04tmA/NjgCbLyPdRLiuf2LskVqlDACMJ9A=; b=Mrsofe53p9yCD+84JGt1RizasDz1fuxSG5yZnw1AZub0v/dYDPHDNBxDVvo1oV7d+3 YpYjGnLHInoBiWNRyZcJy0YUZjhXxkiLTuayHbZCU46yODGnQSrMuHrLcaM5MplstDB3 /FD5jESZ5UdsSfCKqKTnjkiftxAQ1bg9ve1HPSrFxSzH/dxpQL7HXtnt/o3hYpBs2EVZ I/FxRILOGQYiQ2uJs/idUUk/tLXF80+Im3TKSa28/KxjKykf0cRvfT3Z8MQ1hPFS2aFm HGPvcNaBCrp837LztHmbzDs2+meeB3q4y9ItbWGLuCHxWHfPSGPvqa+aY/N074phw7v9 cnQg== MIME-Version: 1.0 X-Received: by 10.236.174.10 with SMTP id w10mr34699247yhl.30.1408984644438; Mon, 25 Aug 2014 09:37:24 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Mon, 25 Aug 2014 09:37:24 -0700 (PDT) In-Reply-To: <53FB584B.7020906@labn.net> References: <062701cfbcc3$2a295470$7e7bfd50$@olddog.co.uk> <53F51DF9.5090703@joelhalpern.com> <398febb5.1408935718161@mail.labn.net> <53FB584B.7020906@labn.net> Date: Mon, 25 Aug 2014 18:37:24 +0200 Message-ID: Subject: Re: Keeping TE architecture in sync? (Was: Re: Routing Area Tuning - Update) From: Abdussalam Baryun To: "lberger@labn.net" Content-Type: multipart/alternative; boundary=20cf305b0aac39d2cb050176cd0e Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/9BPQPHdGrqWxELQROvGEKCqL40k Cc: Adrian Farrel , "Joel M. Halpern" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 16:44:22 -0000 --20cf305b0aac39d2cb050176cd0e Content-Type: text/plain; charset=UTF-8 Hi Lou, On Monday, August 25, 2014, Lou Berger wrote: > > > If multiple WGs, it's the ADs (with support of > the appropriate WG chairs and WG participants) that need to > define/understand the details -- and this what I was asking about. > > (I have previously suggest that scoping TE architecture to 1 WG as a > solution, but that doesn't seem to be getting much support...) I support the proposed WG that works on architectures without protocols as I understood from Adrian's message proposal. It can work independently in the beginning, but in future we can see how community will shape it. I don't agree with authorities among WGs. IMHO all WGs are already working together and our WG chairs are already having high interaction. The one WG for routing area architectures will have many advantages for other WGs (they may use different architecture RFCs), but if we add authorities/policy to that WG then many disadvantage may appear for the area (better we leave area-authority to ADs rather than a WG). If any WG passes a proposal to IESG/LC then all area's participants/WGs should be responsible to improve the proposal, specially when the proposal is an architecture draft (that architecture WG will have some work dependencies and some challenges). AB --20cf305b0aac39d2cb050176cd0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lou,

On Monday, August 25, 2014, Lou Berger wrote:


=C2=A0 If multiple WGs, it's the ADs (with= support of
the appropriate WG chairs and WG participants) that need to
define/understand the details -- and this what I was asking about.

(I have previously suggest that scoping TE architecture to 1 WG as a
solution, but that doesn't seem to be getting much support...)

=C2=A0I support=C2=A0the proposed WG that works on = architectures=C2=A0without protocols=C2=A0as I=C2=A0understood from=C2=A0Ad= rian's message proposal.=C2=A0It can work independently in the beginnin= g, but in future we can see how community will shape it.=C2=A0I don't a= gree with authorities among=C2=A0WGs.=C2=A0IMHO=C2=A0all WGs are already wo= rking together and our=C2=A0WG chairs are already having high interaction.= =C2=A0

The one WG for routing area=C2=A0architectures will hav= e many advantages for other WGs (they may=C2=A0use different=C2=A0architect= ure=C2=A0RFCs),=C2=A0but if we add authorities/policy to that WG then many = disadvantage may appear for the area=C2=A0(better we leave area-authority t= o ADs rather than a=C2=A0WG).=C2=A0

If any WG passes a proposal to IESG/LC=C2=A0then all ar= ea's=C2=A0participants/WGs=C2=A0should be responsible to improve=C2=A0t= he proposal, specially when the proposal is an architecture draft (that arc= hitecture WG will have some=C2=A0work dependencies and some=C2=A0challenges= ).=C2=A0

AB
--20cf305b0aac39d2cb050176cd0e-- From nobody Tue Aug 26 13:32:39 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE771A883D; Tue, 26 Aug 2014 13:32:37 -0700 (PDT) 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 z7rUovC09t3S; Tue, 26 Aug 2014 13:32:35 -0700 (PDT) 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 99E701A02BC; Tue, 26 Aug 2014 13:32:31 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7QKWS4c019201; Tue, 26 Aug 2014 21:32:28 +0100 Received: from 950129200 ([66.129.246.4]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7QKWP2C019100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2014 21:32:27 +0100 From: "Adrian Farrel" To: Subject: Routing Area Tuning - What I heard Date: Tue, 26 Aug 2014 21:32:25 +0100 Message-ID: <080001cfc16c$da8b1350$8fa139f0$@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: Ac/BbNYNTPSbs7mmTiC8qEhRq5l5uw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20908.000 X-TM-AS-Result: No--17.976-10.0-31-10 X-imss-scan-details: No--17.976-10.0-31-10 X-TMASE-MatchedRID: Mj3NuCQGYzKBHLccdfPpxmzBijri5+RVEtdrY/Wb3fPa+IH8mvgPVDzA K7q1A+Iip4greFLbomXiKbEoKAv3hZe/bF1ays2SJmbrB1j4Xwqgo7yEQ1t1y8JuW1juhakm35d D76rzBff94EKC68/eHVIfAqDjzY8QZaaZcM4sp6NbuDP8ZuCmXr7xhVTyv5qoY0DjZWmXtn6jxY yRBa/qJX3mXSdV7KK4OubYLCVnBVG8QIu4z6HhEH7cGd19dSFd Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/5mvJGUZrmqPz8Zy9avZocvcB4ZE X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:32:38 -0000 Hi, [Please respond on routing-discussion@ietf.org even though I am spamming several lists] Thanks for the input on this topic. I heard a number of opinions about whether to split TE architecture away from RSVP-TE. I think this leads to some roughish consensus as follows: TEAS - core RSVP-TE - RSVP-TE for generic cases - IGP-TE extensions in coordination with IGP WGs - TE architecture - including the applicability of PCE for TE in association with PCE WG - relationships with - OSPF and ISIS as above - PCE as above - MPLS for generalisation of packet-specific protocol extensions - CCAMP for generalisation of non-packet-specific protocol extensions CCAMP - non-packet technology-specific RSVP-TE - non-packet technology-specific IGP-TE in association with IGP WGs - consideration to generalise all protocol extensions via TEAS That leaves... MPLS as it is today, except: - All RSVP-TE work that is not technology-specific for packet goes to TEAS - Any TE architecture work goes to TEAS PCE as it is today, except: - Architectural application of PCE for TE goes to TEAS with coord back to PCE Can you please let me know whether I misheard you badly. Is this a split you can live with? Are there show-stopper issues? Thanks, Adrian From nobody Tue Aug 26 14:10:02 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A32E1A8839 for ; Tue, 26 Aug 2014 14:09:52 -0700 (PDT) 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, 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 ot85xTofaixA for ; Tue, 26 Aug 2014 14:09:51 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id AA0291A87F1 for ; Tue, 26 Aug 2014 14:09:51 -0700 (PDT) Received: (qmail 7404 invoked by uid 0); 26 Aug 2014 21:09:47 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 26 Aug 2014 21:09:47 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id jf9f1o00q2SSUrH01f9isj; Tue, 26 Aug 2014 21:09:45 -0600 X-Authority-Analysis: v=2.1 cv=DIUcvU9b c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=Xfr_slu-DDIA:10 a=Uqz2qtt7z-4A:10 a=HFCU6gKsb0MA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=9Xcf_VUGW1lpGzolwhYA:9 a=wPNLvfGTeEIA:10 a=puUasoyRI94A:10 a=rrDK6-Xg4GMA:10 a=9zSy4RCZ2K8A: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=i5sJJAjoRFP/0TkgHrpNWVfFPA8UP6dom2B1F4khV/g=; b=vlPwNW9ru0c1j9zvz2QmbkEJ8COYHdcNBEgYIe6t2Hbzqb+RqkOfBgmiAKD6YVjokdgCA3D8SzXFov2ZxIfCVqbLXzwEW7LeIl/bYF85rRZwtA+J9onDGW3A4suGIrqK; Received: from box313.bluehost.com ([69.89.31.113]:55777 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XMNzp-0002Pv-67; Tue, 26 Aug 2014 15:09:41 -0600 Message-ID: <53FCF7EE.8090207@labn.net> Date: Tue, 26 Aug 2014 17:11:10 -0400 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: adrian@olddog.co.uk Subject: Re: [CCAMP] Routing Area Tuning - What I heard References: <080001cfc16c$da8b1350$8fa139f0$@olddog.co.uk> In-Reply-To: <080001cfc16c$da8b1350$8fa139f0$@olddog.co.uk> 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/routing-discussion/AAymu4cTw9m3UXm6g97eheUeGPM Cc: Adrian Farrel , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 21:09:53 -0000 On 8/26/2014 4:32 PM, Adrian Farrel wrote: > Is this a split you can live with? Yes. > Are there show-stopper issues? > We've heard from some new voices - so i think it was good/important that you (ADs) restarted this discussion on list. -- Much thanks, Lou From nobody Wed Aug 27 02:21:00 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256E81A03D2 for ; Wed, 27 Aug 2014 02:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 b49etPk0QpUn for ; Wed, 27 Aug 2014 02:20:55 -0700 (PDT) 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 CAE6A1A03BB for ; Wed, 27 Aug 2014 02:20:54 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id E13CD1802BB3; Wed, 27 Aug 2014 11:20:52 +0200 (CEST) Message-ID: <53FDA2F7.7020001@pi.nu> Date: Wed, 27 Aug 2014 11:20:55 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, routing-discussion@ietf.org Subject: Re: [mpls] Routing Area Tuning - What I heard References: <080001cfc16c$da8b1350$8fa139f0$@olddog.co.uk> In-Reply-To: <080001cfc16c$da8b1350$8fa139f0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/KSvAWTYy9ChykWgHbGk1TFf13ps X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 09:20:57 -0000 Adrian, Yes I think I can live with this, when we talk about "TE" and "TE architecture" this relates to RSVP-TE and extensions because of RSVP-TE to the IGPs, right? /Loa On 2014-08-26 22:32, Adrian Farrel wrote: > Hi, > > [Please respond on routing-discussion@ietf.org even though I am spamming several > lists] > > Thanks for the input on this topic. > > I heard a number of opinions about whether to split TE architecture away from > RSVP-TE. I think this leads to some roughish consensus as follows: > > TEAS > - core RSVP-TE > - RSVP-TE for generic cases > - IGP-TE extensions in coordination with IGP WGs > - TE architecture > - including the applicability of PCE for TE in association with PCE WG > - relationships with > - OSPF and ISIS as above > - PCE as above > - MPLS for generalisation of packet-specific protocol extensions > - CCAMP for generalisation of non-packet-specific protocol extensions > > CCAMP > - non-packet technology-specific RSVP-TE > - non-packet technology-specific IGP-TE in association with IGP WGs > - consideration to generalise all protocol extensions via TEAS > > That leaves... > > MPLS as it is today, except: > - All RSVP-TE work that is not technology-specific for packet goes to TEAS > - Any TE architecture work goes to TEAS > > PCE as it is today, except: > - Architectural application of PCE for TE goes to TEAS with coord back to PCE > > Can you please let me know whether I misheard you badly. Is this a split you can > live with? Are there show-stopper issues? > > Thanks, > Adrian > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- 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 Aug 27 13:54:05 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF521A02E1 for ; Wed, 27 Aug 2014 13:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 qR5b3uZ34GFx for ; Wed, 27 Aug 2014 13:54:02 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A058F1A0141 for ; Wed, 27 Aug 2014 13:54:02 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by BLUPR0501MB898.namprd05.prod.outlook.com (10.141.254.16) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Wed, 27 Aug 2014 20:54:00 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.1015.018; Wed, 27 Aug 2014 20:53:59 +0000 From: Ross Callon To: "adrian@olddog.co.uk" Subject: RE: [CCAMP] Routing Area Tuning - What I heard Thread-Topic: [CCAMP] Routing Area Tuning - What I heard Thread-Index: Ac/BbNYNTPSbs7mmTiC8qEhRq5l5uwABWxAAADGqxGA= Date: Wed, 27 Aug 2014 20:53:59 +0000 Message-ID: References: <080001cfc16c$da8b1350$8fa139f0$@olddog.co.uk> <53FCF7EE.8090207@labn.net> In-Reply-To: <53FCF7EE.8090207@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0316567485 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(479174003)(199003)(13464003)(24454002)(189002)(164054003)(74662001)(4396001)(74502001)(74316001)(33646002)(108616004)(85306004)(77982001)(90102001)(81542001)(46102001)(101416001)(21056001)(85852003)(76576001)(80022001)(66066001)(76482001)(2656002)(20776003)(110136001)(15975445006)(99396002)(19580395003)(107046002)(87936001)(50986999)(81342001)(79102001)(86362001)(92566001)(31966008)(106356001)(19580405001)(2351001)(83072002)(83322001)(105586002)(76176999)(99286002)(95666004)(64706001)(54356999)(2501001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR0501MB898; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/Yqvv0dIlAySglXtr8tQHSeg4yWg Cc: Adrian Farrel , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 20:54:04 -0000 > Is this a split you can live with?=20 Yes for me also. Thanks, Ross -----Original Message----- From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Lou Berger Sent: Tuesday, August 26, 2014 5:11 PM To: adrian@olddog.co.uk Cc: Adrian Farrel; routing-discussion@ietf.org Subject: Re: [CCAMP] Routing Area Tuning - What I heard On 8/26/2014 4:32 PM, Adrian Farrel wrote: > Is this a split you can live with?=20 Yes. > Are there show-stopper issues? > We've heard from some new voices - so i think it was good/important that you (ADs) restarted this discussion on list. -- Much thanks, Lou _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Wed Aug 27 16:55:09 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C791A030A for ; Wed, 27 Aug 2014 16:55:07 -0700 (PDT) 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 io3RWTzJd-pW for ; Wed, 27 Aug 2014 16:55:06 -0700 (PDT) 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 E91541A02FF for ; Wed, 27 Aug 2014 16:55:05 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7RNt3uX015308; Thu, 28 Aug 2014 00:55:03 +0100 Received: from 950129200 ([66.129.246.4]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7RNt15B015236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Aug 2014 00:55:02 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , Subject: RE: Routing Area Tuning - What I heard Date: Thu, 28 Aug 2014 00:55:00 +0100 Message-ID: <0afd01cfc252$51acce20$f5066a60$@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: Ac/CUk6KG7Khv2zkS+yYx/B1S9gVcQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20912.003 X-TM-AS-Result: No--11.809-10.0-31-10 X-imss-scan-details: No--11.809-10.0-31-10 X-TMASE-MatchedRID: e/tT8EyIjJQ4HKI/yaqRm0KcYi5Qw/RVf6iC0fNopZkgbNDlPT+rWy9z yzJUEnZknjJ4X3KSkTKKlO3LpEVWHwzyMxeMEX6wOX/V8P8ail3Yr6U3ZlQkdtmzcdRxL+xwKra uXd3MZDVPhpL23PqrvmVJ5Wwn2xBEJ0adrVTygA8qnWsHfZVn63XCHnO9cPmK Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/YGkLCbWzXWijM4_csd7qkhGmJgU X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 23:55:07 -0000 Hi Loa, > Yes I think I can live with this, when we talk about "TE" and > "TE architecture" this relates to RSVP-TE and extensions because of > RSVP-TE to the IGPs, right? Yeah. So I wrote: > > TEAS > > - core RSVP-TE > > - RSVP-TE for generic cases > > - IGP-TE extensions in coordination with IGP WGs And I think that extensions to the IGPs may be "because of RSVP-TE" or "enablers for RSVP-TE" or "general enablers of TE systems that also use RSVP-TE." A From nobody Wed Aug 27 18:22:24 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDFF1A0023 for ; Wed, 27 Aug 2014 18:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 io5doHEa5OuA for ; Wed, 27 Aug 2014 18:22:21 -0700 (PDT) Received: from mail-yh0-f46.google.com (mail-yh0-f46.google.com [209.85.213.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8601A0007 for ; Wed, 27 Aug 2014 18:22:21 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id t59so64672yho.5 for ; Wed, 27 Aug 2014 18:22:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=5h5h6bTJwpAgpb37gnsj4qiOaX1QuR3Jh8WchgaJSh0=; b=HlqU2TwhNyPgzKP13twPFl8BF0yCky4D3VzqHDteUOgNeImGPzYMEeX2akOZn7K3Ft S3s4b7cJqMAHO2Q0zHWzuzvwzpDPoesGYDNq4YG97iDed/N9hPT1qPsxoaOP+NblLnG9 73QMKMPC4fA5xlTAOvSEfcPl8IuemulSFjksIK4ywsZMddT8LhcL+G8KNd856eEDpD1N EN3zjlyI1sjEpV6bbiKBHwAWE1XaT1Bv2FqZ6Qe8w8zuYo7bU+1/ENZl8INGIMBTsoGX 4U/zjHY1SlBq23rZ2jxJEDG2BeGhmCiW27HcoppIvxrYDhDI7EQo7BnsynPOoeN3Ak6Q ROTw== X-Gm-Message-State: ALoCoQnzhEiQbaKj0uqLkMrqQaKa1XHmeOrxJm2DUcRe+ckzCdW+sIEn6HwIuLsNp1av9aHavJH+ X-Received: by 10.236.21.193 with SMTP id r41mr6098579yhr.179.1409188940805; Wed, 27 Aug 2014 18:22:20 -0700 (PDT) Received: from ?IPv6:2602:100:4473:9afe:94d1:d567:f0f:d346? ([2602:100:4473:9afe:94d1:d567:f0f:d346]) by mx.google.com with ESMTPSA id t6sm1052977yhg.44.2014.08.27.18.22.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Aug 2014 18:22:20 -0700 (PDT) From: Benson Schliesser Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: NVO3 re-charter discussion happening now Message-Id: <63A99049-7F00-4BC6-A507-76450BA05C94@queuefull.net> Date: Wed, 27 Aug 2014 21:22:21 -0400 To: routing-discussion@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/f-KxJBD2IJqDJmbbyrRbhN-CrLQ X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 01:22:23 -0000 Dear Routing-Discussion List - In the context of ongoing discussion about tweaking the Routing Area, = some of you may be interested to read the latest draft of proposed = charter text for NVO3. In this proposed charter, we make explicit = reference to the to-be-formed BESS WG, and generally try to fit into the = scope proposed by the ADs. The proposed charter can be found at = http://svn.tools.ietf.org/svn/wg/nvo3/charter-ietf-nvo3-01-rev-20140827.tx= t and discussion is taking place on the NVO3 mailing list. (PLEASE, if = you have specific comments on the proposed charter text, make them on = the NVO3 mailing list rather than routing-discussion!) Cheers, -Benson From nobody Thu Aug 28 09:54:51 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FF91A8828 for ; Thu, 28 Aug 2014 09:54:46 -0700 (PDT) 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 4yAwD44s60aj for ; Thu, 28 Aug 2014 09:54:42 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3099D1A87CA for ; Thu, 28 Aug 2014 09:54:19 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id 9so656500ykp.2 for ; Thu, 28 Aug 2014 09:54:18 -0700 (PDT) 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 :cc:content-type; bh=i4FafBYKjvO8mL9685P3hgs64KPuAVvgumtIskrqoxc=; b=tM34oPoQRMg1mXnB4m5gG9iiIeN5rOZYC+ps/Q+vXcJz7GlI0BX9X8mdN+qH6XZ1pA VYVnlX8XGsuLeSP6gAJeHZO1C6AtiAYa56kYgdNF6gTd23E27h56ur99hHk3W09c4FM2 hoPjY5CVBGi3HFH/TQIkPbyE4Fh0Dc+9Ku0NFh/fbh2iS1JOF/wEaHKEILeYrdbLdBoz +XK7koXbAR7a7lAH5Vgqf/hRwVAw3BcgnoSkv75N10nccff1LL2j3rXDLheCiCeb9Y2j +9SEajFE29ca/tbphzNf2Z/XHDWXmh3CBe2xcN2wwM+Gqnuxe2xQdkwddG26jeuHgIdP //nw== MIME-Version: 1.0 X-Received: by 10.236.32.227 with SMTP id o63mr6133382yha.31.1409244858438; Thu, 28 Aug 2014 09:54:18 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Thu, 28 Aug 2014 09:54:18 -0700 (PDT) In-Reply-To: <53FCF7EE.8090207@labn.net> References: <080001cfc16c$da8b1350$8fa139f0$@olddog.co.uk> <53FCF7EE.8090207@labn.net> Date: Thu, 28 Aug 2014 18:54:18 +0200 Message-ID: Subject: Routing Area Tuning - What I heard From: Abdussalam Baryun To: Lou Berger Content-Type: multipart/alternative; boundary=089e0160b3b8305b6b0501b36314 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/aqW5zJHiUVgOrnYi55kSQ6lmpZ0 Cc: "adrian@olddog.co.uk" , Adrian Farrel , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 16:54:47 -0000 --089e0160b3b8305b6b0501b36314 Content-Type: text/plain; charset=UTF-8 On Tuesday, August 26, 2014, Lou Berger wrote: > > On 8/26/2014 4:32 PM, Adrian Farrel wrote: > > Is this a split you can live with? > Yes. > > > Are there show-stopper issues? > > > We've heard from some new voices - so i think it was good/important that > you (ADs) restarted this discussion on list. > > I can live too with that. However, I think we can live with splits, but could we participate with similar efforts, is the key question. IMHO, we will need meeting consideration (as no conflicts in their timings so participants can attend these related WGs), or will need to know how many participants will attend these WGs, for example if A attends WG X before split will A attend X1 and X2 after split. In the proposal when it mentions "work", I usually understand it as work as standard track or experimental, but for informational drafts, I consider not all of them are working targets, but some are related to analysis of work or explanations of rationale (as explanation target). I suggest that if possible each WGs can do some informational drafts of that kind related to architecture (rationale, analysis) to show the WG considerations/recommendation (it will help in describing reasons of related WG designs). AB --089e0160b3b8305b6b0501b36314 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, August 26, 2014, Lou Berger wrote:

On 8/26/2014 4:32 PM, Adrian Farrel wrote:
>=C2=A0 Is this a split you can live with?
Yes.

> Are there show-stopper issues?
>
We've heard from some new voices - so i think it was good/important tha= t
you (ADs) restarted this discussion on list.


I can live too with that. However,=C2= =A0I think we can live with splits, but could we participate with similar e= fforts,=C2=A0is the key question.=C2=A0=C2=A0IMHO, we will need meeting con= sideration (as no conflicts in their timings so participants can attend the= se related=C2=A0WGs), or will need to know how many participants will atten= d these WGs, for example if A attends WG X=C2=A0before split will A attend = X1 and X2 after split.

In the proposal when it=C2=A0mentions "work",= =C2=A0I usually understand it as work as=C2=A0standard track or experimenta= l, but for informational drafts, I consider not all of them are=C2=A0workin= g targets,=C2=A0but some are related to analysis of work or explanations of= rationale (as explanation=C2=A0target). I suggest that if possible=C2=A0ea= ch=C2=A0WGs can do some informational=C2=A0drafts of that kind related to a= rchitecture=C2=A0(rationale, analysis)=C2=A0to show the WG considerations/r= ecommendation (it will help in describing reasons of related=C2=A0WG=C2=A0d= esigns).=C2=A0

AB
--089e0160b3b8305b6b0501b36314-- From nobody Thu Aug 28 10:43:28 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBB61A886C for ; Thu, 28 Aug 2014 10:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.5 X-Spam-Level: X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 VworN5qKjVYy for ; Thu, 28 Aug 2014 10:43:24 -0700 (PDT) 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 C45BF1A0B79 for ; Thu, 28 Aug 2014 10:43:23 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7SHhKu1015321; Thu, 28 Aug 2014 18:43:20 +0100 Received: from 950129200 ([66.129.246.4]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7SHhIsm015223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Aug 2014 18:43:19 +0100 From: "Adrian Farrel" To: "'Abdussalam Baryun'" References: <080001cfc16c$da8b1350$8fa139f0$@olddog.co.uk> <53FCF7EE.8090207@labn.net> In-Reply-To: Subject: RE: Routing Area Tuning - What I heard Date: Thu, 28 Aug 2014 18:43:17 +0100 Message-ID: <019601cfc2e7$8e9754f0$abc5fed0$@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: AQIL1mjfWCTZ7uuLaIuveIFStyqk+AMWPiu7AZL9eiqbSNQKgA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20914.000 X-TM-AS-Result: No--7.168-10.0-31-10 X-imss-scan-details: No--7.168-10.0-31-10 X-TMASE-MatchedRID: 8+bhjh9TQnE4HKI/yaqRm8pQKjU7fBXV8GRhP/nTHNY9lFqHcAo+RwCF m7CJDqdeDwMB0lawjhaZ40XoZ472BT2ZcPxkDATFzMBtrPS9VUfSL+EVfOJR04KwF4K/wIz9bYR v2N9oA1BnKXGjXjR7jcsYUK2CJEvfBkDg6ZABZiFj2Mi9Aq5L035Lmbb/xUua9ait85sNgkBfFG 0p9UU3w1JdxTw+pUsxcqxIfPJ6n6G68Mln9Nwu092pKQTXGeFKnvBHr/aFnM6InvV8Dy0ZaG7VO grp+MpHBADAKR4HKDWINCm51iEymmc0DJQHLmyXuIwLnB3Aqp27N+JgpmUHRoq9LAdn3PFUEWuf E/KUNJNcvJDWyrAQ1gfiO+cO1L/Kv1l2Uvx6idoLbigRnpKlKSPzRlrdFGDwjEM4fQv7McOkPv2 tBkuvFHqh68gCj+aeV9Ef/YJ7FSEDNRi7sATnkQ== Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/9W9eUkwQ0S6a3_5L-mMXiZZJmhk Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 17:43:25 -0000 > However, I think we can live with splits, but could we=20 > participate with similar efforts, is the key question. =20 > IMHO, we will need meeting consideration (as no=20 > conflicts in their timings so participants can attend > these related WGs), or will need to know how many > participants will attend these WGs, for example if A=20 > attends WG X before split will A attend X1 and X2 after > split. Yes, we already have to manage meeting conflicts. We do it pretty well = with the occasional fumble. Yes, the conflicts will change after these changes. I think we = understand what conflicts will exist and need to be avoided. Yes, the first time around will be some guesswork about attendance. Not = the hardest problem in my life at the moment. > In the proposal when it mentions "work", I usually=20 > understand it as work as standard track or experimental, > but for informational drafts, I consider not all of them are > working targets, but some are related to analysis of work > or explanations of rationale (as explanation target).=20 No, "work" is not a reserved word in the IETF. It has its usual meaning. I like "exertion or effort directed to produce or accomplish something" = and (in the context of the IETF) I am amused by "productive activity". In this context "work" means "stuff the working group is doing". And = that expands a bit roughly to "stuff that is happening with a view to = publishing RFCs." > I suggest that if possible each WGs can do some informational drafts > of that kind related to architecture (rationale, analysis) to show the = > WG considerations/recommendation (it will help in describing reasons > of related WG designs).=20 Yes? Well, I think you'll find that most WGs have done such things in the = past. Many have explicit charter items to do these things and are busy = developing them. Some WGs come up with additional documents (applicability statements, = implementation reports, etc.) in an ad hoc way and drive them through if = there is consensus to work on them and publish them. Business as usual, I think, but everyone can review and comment on new = charter proposals. These are starting to pop out now (see the email from = Benson about NVO3). Adrian From nobody Fri Aug 29 13:17:06 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D611A067F for ; Fri, 29 Aug 2014 13:17:03 -0700 (PDT) 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 VzAuyWdtyu3g for ; Fri, 29 Aug 2014 13:17:01 -0700 (PDT) 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 00A711A056D for ; Fri, 29 Aug 2014 13:17:00 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7TKGxi6002243 for ; Fri, 29 Aug 2014 21:16:59 +0100 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 s7TKGvUg002230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 29 Aug 2014 21:16:58 +0100 From: "Adrian Farrel" To: Subject: Who will be the next Routing AD? [FW: NOMCOM 2014 - Call for Nominations] Date: Fri, 29 Aug 2014 21:16:57 +0100 Message-ID: <012801cfc3c6$2fc38f40$8f4aadc0$@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: Ac/DxiyN2gYzRwZrTA2ly9taEYUMeA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20916.002 X-TM-AS-Result: No--22.229-10.0-31-10 X-imss-scan-details: No--22.229-10.0-31-10 X-TMASE-MatchedRID: LStfu7uUL3rDkHnJwIRKWy2EzAlnB8oRr4ukWaaTegB3UV216cq/2JYZ TSFHsr7FwKErLMX3Le/6/8A5t5NKXTgcoj/JqpGbzNY33yIEF4YNmVMWD55fO+KtmzNS0XPX0u5 faGP8ztT7a54nEeMn4diMzurdSUE32qOAkQrDumMaunX20lzOhSbL1+x3Q7ugoofVX5Ds9WRjaJ HsrxZyzHiJqN6sfpFLi15NOHNqpxVQFwI4HzSNosrT39PoDNtWUAjrAJWsTe+Y/Ue6G7XIMoQ7h +Ni+DYTKEzehF+FxuqIbFRsXjoxxb8pU887Y2CIbEOa88C4NLpkBDPLxNH5BvFJXtgF4GFLkQ+s ap+85FwPGw7IIe8FczX8QupZ52ovEG+/dYPP47WZroPNdqiG8+dt6GkoXKtR/5pZS64Rm1VUUdB 0rIxhszZ1r5/MrPZ9cIpLzO17IYrlDqmvWw4sE8tfHufnayoGhV0srjoqtx8Ga3t5IDRpjXERbS 7OZpEDbFkJe+xjiXIdirD4rHu+4bmolwcqE3SPrbCG6+RdmS227Ny1fq9nD7k3pFmM6y1kaKLxY aIH6NBANVLge+GyqNVuPsZd+OOar78SC5iivxyDGx/OQ1GV8v1vTGBiuZrt1GcRAJRT6POOhzOa 6g8KrZRMZUCEHkRt Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/WH8Zn4ANaQYkScNpOgNRyNO34AY X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 20:17:03 -0000 Please recall that I will not be standing again this year (three terms = are more than enough, thank you :-) Please think hard about suitable candidates, twist their arms, and put = their names forward. The IESG is strongest when NomCom is given a good range of people to = look at. Thanks, Adrian > -----Original Message----- > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf = Of > NomCom Chair 2014 > Sent: 29 August 2014 17:12 > To: IETF Announcement List > Cc: ietf@ietf.org > Subject: NOMCOM 2014 - Call for Nominations >=20 > The 2014-15 Nominating Committee (Nomcom) is seeking nominations > from now until October 11, 2014. The open positions being considered > by this year's Nomcom can be found at the end of this email and also = on > this year's Nomcom website: >=20 > https://datatracker.ietf.org/nomcom/2014/ >=20 > Nominations may be made by selecting the Nominate link at the top of > the Nomcom 2014 home page, or by visiting the following URL: >=20 > https://datatracker.ietf.org/nomcom/2014/nominate/ >=20 > {Note that nominations made using the web tool require an ietf.org > datatracker account. You can create a datatracker ietf.org account > if you don't have one already by visiting the following URL: > https://datatracker.ietf.org/accounts/create/ } >=20 > Nominations may also be made by email to nomcom13@ietf.org. > If use email, please include the word "Nominate" in the Subject and > indicate in the email who is being nominated, their email address (to > confirm acceptance of the nomination), and the position for which you > are making the nomination. If you wish to nominate someone via email > for more than one position, please use separate emails to do so. >=20 > Self-nomination is welcome! >=20 > NomCom 2014-15 will follow the policy for "Open Disclosure of Willing > Nominees" described in RFC 5680. As stated in RFC 5680: "The list of > nominees willing to be considered for positions under review in the > current Nomcom cycle is not confidential". Willing nominees for each > position will be listed in a publicly accessible way - anyone with a > datatracker account may access the lists. In all other ways, the > confidentiality requirements of RFC 3777/BCP10 remain in effect. All > feedback and all Nomcom deliberations will remain confidential and = will > not be disclosed. >=20 > In order to ensure time to collect sufficient community feedback about > each of the willing nominees, nominations must be received by the > Nomcom on or before October 11, 2013. >=20 > Please submit your nominations as early as possible for the sake of = your > nominees. Note that nominations should not wait for management = permission, > as it is easier to decline the nomination, than put one in late. > We've set the questionnaire submission deadline for October 25, 2014. >=20 > The Nomcom appoints individuals to fill the open slots on the > IAOC, the IAB, and the IESG. The list of people and posts whose terms > end with the March 2014 IETF meeting, and thus the positions for which > this Nomcom is responsible, follows: >=20 > IAOC: > Randy Bush >=20 > IAB: > Joel Halpern > Russ Housley > Eliot Lear > Xing Li > Andrew Sullivan > Dave Thaler >=20 > IESG: > Pete Resnick (Applications) > Ted Lemon (Internet) > Joel Jaeggli (Operations and Management) > Richard Barnes (RAI) > Adrian Farrel* (Routing) > Stephen Farrell (Security) > Spencer Dawkins (Transport) > Jari Arkko (Gen) >=20 > *- known to have decline to run again. >=20 > Please be resourceful in identifying possible candidates for these > positions, as developing our talent is a very crucial requirement for > the IETF, and also, please consider accepting a nomination. You'll > find extensive information about specific positions, developed by > the IAB, IESG, and IAOC, under individual tabs at: >=20 > https://datatracker.ietf.org/nomcom/2014/requirements/ >=20 > In addition to nominations, the Nomcom seeks community input on > the positions themselves. We need and welcome the community's > views and input on the jobs within each organization. If you > have ideas on the positions' responsibilities (more, less, > different), please let us know. >=20 > Please send suggestions and feedback about this to nomcom14@ietf.org. >=20 > Thank you for your help in identifying qualified nominees! >=20 > Michael Richardson > Nomcom Chair 2014-15 > nomcom-chair-2014@ietf.org, mcr+nomcom@sandelman.ca