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

Meral Shirazipour <meral.shirazipour@polymtl.ca> Mon, 09 July 2007 14:44 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 1I7uTZ-000742-7G for ccamp-archive@ietf.org; Mon, 09 Jul 2007 10:44:33 -0400
Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7uTY-0000oG-Kj for ccamp-archive@ietf.org; Mon, 09 Jul 2007 10:44:33 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1I7uGf-0007MM-9j for ccamp-data@psg.com; Mon, 09 Jul 2007 14:31:13 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8
Received: from [132.207.4.11] (helo=smtp.polymtl.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from <meral.shirazipour@polymtl.ca>) id 1I7uGT-0007KV-1d for ccamp@ops.ietf.org; Mon, 09 Jul 2007 14:31:07 +0000
Received: from localhost (imp-4-1.polymtl.ca [132.207.4.76]) by smtp.polymtl.ca (8.13.6/8.13.6) with ESMTP id l69EUuRL024093; Mon, 9 Jul 2007 10:30:57 -0400
Received: from chaplin.larim.polymtl.ca (chaplin.larim.polymtl.ca [132.207.67.80]) by www.imp.polymtl.ca (IMP) with HTTP for <meshi@132.207.4.132>; Mon, 09 Jul 2007 10:30:58 -0400
Message-ID: <1183991458.469246a233457@www.imp.polymtl.ca>
Date: Mon, 09 Jul 2007 10:30:58 -0400
From: Meral Shirazipour <meral.shirazipour@polymtl.ca>
To: Tomonori TAKEDA <takeda.tomonori@lab.ntt.co.jp>
Cc: "ccamp@ops.ietf.org" <ccamp@ops.ietf.org>
Subject: Re: Fwd: I-D ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
References: <6.0.0.20.2.20070709105344.0871a610@imf.m.ecl.ntt.co.jp> <1183954057.4691b4894b96a@www.imp.polymtl.ca> <6.0.0.20.2.20070709142721.08632eb0@imf.m.ecl.ntt.co.jp>
In-Reply-To: <6.0.0.20.2.20070709142721.08632eb0@imf.m.ecl.ntt.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.3
X-Originating-IP: 132.207.67.80
X-Poly-FromMTA: (imp-4-1.polymtl.ca [132.207.4.76]) at Mon, 9 Jul 2007 14:30:56 +0000
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90

Dear Tomonori,
   Thank you for the explanation:
----------
>[Page 12]
>first paragraph:"This scheme cannot guarantee to establish diverse LSPs (even
>if they could exist) because the first LSP is established without
>consideration of the need for a diverse recovery LSP. Crankback [crankback]
>may be used in combination with this scheme in order to improve the
>possibility of successful diverse LSP setup."
>How can crankback on the protection LSP help if the problem is the already
>established working LSP ?!

There are several causes why the recovery LSP can not be computed. In one
case, the recovery LSP can not be computed because the working LSP is
blocking (there is no way). In another case, the recovery LSP can not be
computed because the bad border node is selected, but crankback can fix
this. We are not saying that the first case can be fixed by crankback.
----------



 Just to make sure that I understood well, crankback is used when the entity
that determined the diverse recovery LSP had only access to an out of date
information that did not include the recently deployed working LSP ?

Thanks again for taking the time...

Warm Regards,
Meral









Selon Tomonori TAKEDA <takeda.tomonori@lab.ntt.co.jp>:

> Hi Meral,
>
> Thanks for you comments. I copied CCAMP list here for sharing information.
>
> Please see in-line.
>
> At 13:07 07/07/09, Meral Shirazipour wrote:
>  >Dear Tomonori,
>  >   I just finished reading the draft. Below I have a few
> comments/suggestions,
>  >mainly regarding typos and clarity.
>  >
>  >Warm Regards,
>  >Meral
>  >
>  >[Page 2/16]
>  >5.4 Inter-domain Collaborate Path Computation....................16
>  >
>  >Maybe Collaborative would be better?!
>
> Thanks.
>
>  >[Page 4]
>  >section 1.2 Domain
>  >"In such a scenarios,..."
>  >
>  >Should be "In such scenarios" or "In such a scenario"
>
> Thanks.
>
>  >section 1.3 Document Scope , third paragraph
>  >"which can advantageously used"
>  >Should be "which can advantageously be used"
>
> Thanks.
>
>  >[Page 6/7]
>  >"Figure 2: Mesh Connectivity"  should be on page 6
>
> OK.
>
>  >[Page 9]
>  >"An example of such a scheme is Backward Recursive Pause Computation (BRPC)
>  >[brpc]"
>  >
>  >"Pause" should be replaced by "Path"
>
> Thanks.
>
>  >[Page 20]
>  >[brpc]:
>  >A Backward Recursive PCE-based Computation (BRPC) procedure to compute
>  >shortest inter-domain Traffic Engineering Label Switched Paths
>  >
>  >Path with S
>
> Thanks.
>
>  >[Page 12]
>  >first paragraph:"This scheme cannot guarantee to establish diverse LSPs
> (even if
>  >they could exist) because the first LSP is established without
> consideration of
>  >the need for a diverse recovery LSP. Crankback [crankback] may be used in
>  >combination with this scheme in order to improve the possibility of
> successful
>  >diverse LSP setup."
>  >
>  >How can crankback on the protection LSP help if the problem is the already
>  >established working LSP ?!
>
> There are several causes why the recovery LSP can not be computed. In one
> case, the recovery LSP can not be computed because the working LSP is
> blocking (there is no way). In another case, the recovery LSP can not be
> computed because the bad border node is selected, but crankback can fix
> this. We are not saying that the first case can be fixed by crankback.
>
> Thanks,
> Tomonori
>
>  >
>  >
>  >
>  >
>  >
>  >
>  >Selon Tomonori TAKEDA <takeda.tomonori@lab.ntt.co.jp>:
>  >
>  >> 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,fgs=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-domain-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-analysis-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-analysis-01.txt
>  >>  >
>  >>  >
>  >>
> 
>><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt>
>  >>  >_______________________________________________
>  >>  >I-D-Announce mailing list
>  >>  >I-D-Announce@ietf.org
>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
>  >>
>  >>
>  >>
>  >>
>
>
>
>