[Mpls-interop] Progress with my editing work in Geneva
"Adrian Farrel" <adrian@olddog.co.uk> Wed, 03 December 2008 08:42 UTC
Return-Path: <mpls-interop-bounces@ietf.org>
X-Original-To: mpls-interop-archive@ietf.org
Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id A2E313A699A;
Wed, 3 Dec 2008 00:42:09 -0800 (PST)
X-Original-To: mpls-interop@core3.amsl.com
Delivered-To: mpls-interop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 6B8A53A699A
for <mpls-interop@core3.amsl.com>; Wed, 3 Dec 2008 00:42:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.343
X-Spam-Level:
X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.255,
BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id apuYESDgfmhq for <mpls-interop@core3.amsl.com>;
Wed, 3 Dec 2008 00:42:02 -0800 (PST)
Received: from protext01.itu.ch (protext01.itu.ch [156.106.192.41])
by core3.amsl.com (Postfix) with ESMTP id D29573A6B07
for <mpls-interop@ietf.org>; Wed, 3 Dec 2008 00:41:59 -0800 (PST)
Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with
Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Dec 2008 09:41:51 +0100
Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield
SMTP v4.5 MR3) id 1228293697164; Wed, 3 Dec 2008 09:41:37 +0100
Received: from your029b8cecfe ([156.106.216.176])
by mail6.itu.ch (8.14.3/8.14.3) with ESMTP id mB38fPiF387701
for <mpls-interop@ietf.org>; Wed, 3 Dec 2008 09:41:36 +0100 (MET)
Message-ID: <D4FAB2E7DFC0436091280D2142715FE6@your029b8cecfe>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <mpls-interop@ietf.org>
Date: Wed, 3 Dec 2008 08:39:22 -0000
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0
(mail6.itu.ch [156.106.192.22]);
Wed, 03 Dec 2008 09:41:37 +0100 (MET)
X-OriginalArrivalTime: 03 Dec 2008 08:41:51.0773 (UTC)
FILETIME=[FCF1E4D0:01C95522]
Subject: [Mpls-interop] Progress with my editing work in Geneva
X-BeenThere: mpls-interop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
List-Id: IETF MPLS Interoperability Design Team <mpls-interop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-interop>,
<mailto:mpls-interop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mpls-interop>
List-Post: <mailto:mpls-interop@ietf.org>
List-Help: <mailto:mpls-interop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-interop>,
<mailto:mpls-interop-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: mpls-interop-bounces@ietf.org
Errors-To: mpls-interop-bounces@ietf.org
Just to keep you up to date... Tuesday I had useful corridor discussions with several people about process, terminology, and "tandem connections". I think we made some movement toward mutual understanding. In particular of the use of (benefit of) an aggregation tunnel LSP over some segment of a path (what I call a Path Segment Tunnel) to carry one or more end-to-end LSPs and enable OAM and protection scaling. Last night we (mainly Nurit and me - some help from others, especially Stewart and Deborah) started to go through the requirements I-D (draft-ietf-mpls-tp-requirements-00.txt) and generated a number of comments (mainly clarification and editorial). We got as far as section 2.8 (Protection & Survivability requirements) which is the topic I want to make serious progress on. My plan is to do a significant rework of this section today. - I want to split out protection behavior requirements (i.e. data plane observed behavior, and data plane operational behavior) - We should have a subsection for protection requirements in ring topologies (even if it ends up that all of the requirements listed are copies of those in the general section, it will be helpful to expose that we have considered protection in ring topologies) - Separate sections are needed to describe each of: - Triggers for protection and restoration - Management plane operation of protection and restoration - Control plane operation of protection and restoration Once we have that text prepared we will be able to move on to the survivability framework draft (draft-sprecher-mpls-tp-survive-fwk). [Other people may work on other drafts!] Please note that here in Geneva there will be a joint session of Question 10 and Question 12 on Friday afternoon this week to review the four working group I-Ds. Adrian _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop
- [Mpls-interop] Progress with my editing work in G… Adrian Farrel