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

[Tomonori TAKEDA <[e-mail]>]

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: [e-mail]
 >> [mailto:[e-mail]] On Behalf Of Tomonori TAKEDA
 >> Sent: Monday, July 09, 2007 4:04 AM
 >> To: [e-mail]
 >> 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: [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,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
 >>  >[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-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: <[e-mail]>
 >>  >
 >>  >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
 >>  >[e-mail]
 >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
 >>
 >>
 >>
 >>