[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
Hi Dimitri,
Thanks for your comments.
Please see in-line.
At 06:10 07/07/10, PAPADIMITRIOU Dimitri wrote:
>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 ?
This is true when there are only two border nodes (ingress and egress) for
each domain (well, SRLG diversity where nodes/links in different domains
belong to the same SRLG is a bit hard, though).
However, when there are more than two border nodes, we need to pick up a
good pair of border nodes. Please see my separate email to Meral which
shows such an example.
>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
I am not sure whether I understand correctly, but if border nodes are
already selected, the only thing that remains is to select the route within
each domain.
Thanks,
Tomonori
>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
>>
>>
>>
>>