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

[Tomonori TAKEDA <[e-mail]>]

Hi Meral,

Please see in-line.

At 23:30 07/07/09, Meral Shirazipour wrote:
 >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 ?

Out of date information is yet another case where the recovery LSP can not 
be computed. Crankback is also applicable when information is up-to-date 
(when there are more than two border nodes).

Here is an example.

     B----------E
   /              \
  /                \
A---C----------F---H
  \             |  /
   \            | /
     D----------G

- A,B,C,D belong to domain#1.
- E,F,G,H belong to domain#2.
- The working LSP is A->D->G->F->H.

Assume we are using per-domain sequential path computation, and trying to 
establish the recovery LSP from A to H.

For the recovery LSP, domain#1 may compute A->C. At domain#2 (or at F), we 
know that the recovery LSP can not be computed since the working LSP is 
blocking. Now crankback can fix this by notifying domain#1, and domain#1 
re-computes the recovery LSP as A->B.

Hope this clarifies.

Thanks,
Tomonori

 >Thanks again for taking the time...
 >
 >Warm Regards,
 >Meral
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >Selon 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
 >>  >>
 >>  >>
 >>  >>
 >>  >>
 >>
 >>
 >>
 >>