RE: I-D ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt

"PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be> Mon, 09 July 2007 21:19 UTC

Return-path: <owner-ccamp@ops.ietf.org>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80dw-0003p5-Nf for ccamp-archive@ietf.org; Mon, 09 Jul 2007 17:19:40 -0400
Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I80dw-0002TU-6W for ccamp-archive@ietf.org; Mon, 09 Jul 2007 17:19:40 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1I80Vv-00052O-DT for ccamp-data@psg.com; Mon, 09 Jul 2007 21:11:23 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8
Received: from [64.208.49.27] (helo=smail5.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from <Dimitri.Papadimitriou@alcatel-lucent.be>) id 1I80Vj-00051p-6b for ccamp@ops.ietf.org; Mon, 09 Jul 2007 21:11:17 +0000
Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l69L9Dc8015003; Mon, 9 Jul 2007 23:09:13 +0200
Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 9 Jul 2007 23:11:00 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
Date: Mon, 09 Jul 2007 23:10:47 +0200
Message-ID: <8144761F31F48D43AD53D09F5350E3809FCF35@FRVELSMBS22.ad2.ad.alcatel.com>
In-Reply-To: <6.0.0.20.2.20070709105344.0871a610@imf.m.ecl.ntt.co.jp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: I-D ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
Thread-Index: AcfBzteD35sQEXiCT6OuSZcuBb3BtQAjN7rg
From: PAPADIMITRIOU Dimitri <Dimitri.Papadimitriou@alcatel-lucent.be>
To: Tomonori TAKEDA <takeda.tomonori@lab.ntt.co.jp>, ccamp@ops.ietf.org
X-OriginalArrivalTime: 09 Jul 2007 21:11:00.0834 (UTC) FILETIME=[A6C28C20:01C7C26D]
X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017

tomonori


reading through this doc still unclear to me why there is no statement
that says (at the end) that the sole issue is due to the fact that
ingress node do not see both protecting and working LSPs (by definition
of diversity) and therefore across that domain, mechanisms are needed:


1. since the problem is only considered in its linear version and
associated protecting and working LSP are are both following the same
sequence, one needs to resolve the intra-domain/intra-AS trap issue (at
the SRLG/node/ link level) and prevent that that two ingress nodes (of
the same domain) do not select the same egress node (of that domain) to
reach the next domain for both protecting and working LSP ?


2. when computation is not simultaneous per domain (independently of
whether sequentially distributed or centralized) and does not result in
strict hops only (implicitly or explcitly), the only thing that remains
possible is to condition the first LSP setup with additional constraints
during its establishment


this would for me streamline this analysis in a protocol independent way
(observe that point 2 is totally independent of whether PCEs are used or
not)


now if a protocol analysis needs to be done it needs to account for call
segments in which case and compared to BRPC the discussion would be
about sequential computation along the downstream or the upstream (or
combination)


thanks,
-d.






> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Tomonori TAKEDA
> Sent: Monday, July 09, 2007 4:04 AM
> To: ccamp@ops.ietf.org
> Subject: Fwd: I-D 
> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
> 
> Hi,
> 
> A new version of inter-domain recovery analysis I-D have been 
> published.
> 
> Here are major changes:
> - Added text on security considerations section
> - Cleaned up text marked "for further study" (various places)
> - Added a reference to [PCEP-XRO]
> - Enhanced text on computing diverse paths sequentially with 
> confidentiality
>    (Section 5.4.1)
> - Moved "terminology" section into "introduction" section
> - Removed manageability considerations section
> - Polished text
> 
> Authors believe the document is now completed and ready for 
> WG last call.
> 
> Thanks,
> Tomonori
> 
>  >To: i-d-announce@ietf.org
>  >From: Internet-Drafts@ietf.org
>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
>  >X-Spam-Score: 0.0 (/)
>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
>  >Cc: ccamp@ops.ietf.org
>  >Subject: I-D 
> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >X-BeenThere: i-d-announce@ietf.org
>  >X-Mailman-Version: 2.1.5
>  >Reply-To: internet-drafts@ietf.org
>  >List-Id: i-d-announce.ietf.org
>  >List-Unsubscribe:
>  
> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
> :i-d-announce-request@ietf.org?subject=unsubscribe>
>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
>  >List-Post: <mailto:i-d-announce@ietf.org>
>  >List-Help: <mailto:i-d-announce-request@ietf.org?subject=help>
>  >List-Subscribe:
>  
> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
> :i-d-announce-request@ietf.org?subject=subscribe>
>  >X-Junkmail: UCE(35)
>  >X-Junkmail-Status: score=35/10, host=sfs2.omr.ecl.ntt.co.jp
>  >X-Junkmail-SD-Raw:
>  
> >score=suspect(0),refid=str=0001.0A090207.468E8745.0129,ss=2,f
> gs=0,ip=156.154.16.145,so=2007-03-13 
> 
>  >10:31:19,dmn=5.3.14/2007-05-31
>  >
>  >A New Internet-Draft is available from the on-line Internet-Drafts
>  >directories.
>  >This draft is a work item of the Common Control and 
> Measurement Plane
>  >Working Group of the IETF.
>  >
>  >	Title		: Analysis of Inter-domain Label 
> Switched Path (LSP) Recovery
>  >	Author(s)	: T. Takeda, et al.
>  >	Filename	: 
> draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >	Pages		: 23
>  >	Date		: 2007-7-6
>  >
>  >This document analyzes various schemes to realize 
> Multiprotocol Label
>  >   Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path
>  >   (LSP) recovery in multi-domain networks based on the existing
>  >   framework for multi-domain LSPs.
>  >
>  >   The main focus for this document is on establishing end-to-end
>  >   diverse Traffic Engineering (TE) LSPs in multi-domain 
> networks. It
>  >   presents various diverse LSP setup schemes based on existing
>  >   functional elements.
>  >
>  >A URL for this Internet-Draft is:
>  
> >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do
> main-recovery-analysis-01.txt
>  >
>  >To remove yourself from the I-D Announcement list, send a message to
>  >i-d-announce-request@ietf.org with the word unsubscribe in 
> the body of
>  >the message.
>  >You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
>  >to change your subscription settings.
>  >
>  >Internet-Drafts are also available by anonymous FTP. Login with the
>  >username "anonymous" and a password of your e-mail address. After
>  >logging in, type "cd internet-drafts" and then
>  >"get draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
>  >
>  >A list of Internet-Drafts directories can be found in
>  >http://www.ietf.org/shadow.html
>  >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>  >
>  >Internet-Drafts can also be obtained by e-mail.
>  >
>  >Send a message to:
>  >	mailserv@ietf.org.
>  >In the body type:
>  >	"FILE 
> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
> is-01.txt".
>  >
>  >NOTE:	The mail server at ietf.org can return the document in
>  >	MIME-encoded form by using the "mpack" utility.  To use this
>  >	feature, insert the command "ENCODING mime" before the "FILE"
>  >	command.  To decode the response(s), you will need "munpack" or
>  >	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
>  >	exhibit different behavior, especially when dealing with
>  >	"multipart" MIME messages (i.e. documents which have been split
>  >	up into multiple messages), so check your local documentation on
>  >	how to manipulate these messages.
>  >
>  >Below is the data which will enable a MIME compliant mail reader
>  >implementation to automatically retrieve the ASCII version of the
>  >Internet-Draft.
>  >
>  >Content-Type: text/plain
>  >Content-ID: <2007-7-6134934.I-D@ietf.org>
>  >
>  >ENCODING mime
>  >FILE 
> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
> is-01.txt
>  >
>  >
>  
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do
> main-recovery-analysis-01.txt>
>  >_______________________________________________
>  >I-D-Announce mailing list
>  >I-D-Announce@ietf.org
>  >https://www1.ietf.org/mailman/listinfo/i-d-announce 
> 
> 
> 
>