[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: I-D ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
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 <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
>> >>
>> >>
>> >>
>> >>
>>
>>
>>
>>