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

["PAPADIMITRIOU Dimitri" <[e-mail]>]

hi tomonori - see inline 

> -----Original Message-----
> From: Tomonori TAKEDA [mailto:[e-mail]] 
> Sent: Tuesday, July 10, 2007 9:51 AM
> To: PAPADIMITRIOU Dimitri; [e-mail]
> Subject: 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).

this is what the diagrams and text infers

generalizing the number of edges/inter-connection
adds an additional constraints (select 2 among N)

> 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.

idem keep in mind here that enlarging the problem 
space and have a preferential selection between N
possible inter-domain links but achieve a non-
blocking situation is the base objective 

>  >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.

yes and the question boils down to the point mentioned
where intra-domain path comp. would result in blocking
the other
 
i don't see any answer to the below point ? which is at
the end the reason of my comment - this doc bundles the
protocol independent analysis with a protocol dependent
analysis in the latter case one should consider possible
solution space and not pre-assume any specific limitation

thanks,
-d.

> 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
>  >>
>  >>
>  >>
>  >> 
> 
> 
>