IETF Logo Mail Archive

Routing Area Tuning - Update

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 20 August 2014 22:07 UTC

Return-Path: <adrian@olddog.co.uk>
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 <routing-discussion@ietfa.amsl.com>; 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 <routing-discussion@ietfa.amsl.com>; 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 <routing-discussion@ietf.org>; 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 <adrian@olddog.co.uk>
To: routing-discussion@ietf.org
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 <routing-discussion.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/routing-discussion/>
List-Post: <mailto:routing-discussion@ietf.org>
List-Help: <mailto:routing-discussion-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=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

v2.23.0 | Report a Bug | By Email