[CCAMP] Routing Area Tuning - What I heard

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 26 August 2014 20:32 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@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" <adrian@olddog.co.uk>
To: <routing-discussion@ietf.org>
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/ccamp/Xt9leQQv_UMOnIIrdilVRdQzYqs
X-Mailman-Approved-At: Tue, 26 Aug 2014 14:01:26 -0700
Cc: 'Alia Atlas' <akatlas@gmail.com>
Subject: [CCAMP] Routing Area Tuning - What I heard
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=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