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

[Tomonori TAKEDA <[e-mail]>]

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 <[e-mail]>:
 >
 >> 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: [e-mail]
 >>  >From: [e-mail]
 >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
 >>  >X-Spam-Score: 0.0 (/)
 >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
 >>  >Cc: [e-mail]
 >>  >Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >X-BeenThere: [e-mail]
 >>  >X-Mailman-Version: 2.1.5
 >>  >Reply-To: [e-mail]
 >>  >List-Id: i-d-announce.ietf.org
 >>  >List-Unsubscribe:
 >>
 >><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[e-mail]?subject=unsubscribe>
 >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
 >>  >List-Post: <mailto:[e-mail]>
 >>  >List-Help: <mailto:[e-mail]?subject=help>
 >>  >List-Subscribe:
 >>
 >><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[e-mail]?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
 >>  >[e-mail] 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:
 >>  >	[e-mail].
 >>  >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: <[e-mail]>
 >>  >
 >>  >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
 >>  >[e-mail]
 >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
 >>
 >>
 >>
 >>