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

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

hi tomonori,

> -----Original Message-----
> From: Tomonori TAKEDA [mailto:[e-mail]] 
> Sent: Thursday, July 12, 2007 6:34 AM
> To: PAPADIMITRIOU Dimitri; [e-mail]
> Subject: RE: I-D 
> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
> 
> Hi Dimitri,
> 
> Please see in-line.
> 
> At 19:54 07/07/10, PAPADIMITRIOU Dimitri wrote:
>  >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)
> 
> Section 1.3 and section 2 state the problem space. This 
> document does not 
> restrict that the number of border nodes must be 2.

exactly my point. 

there are lot's of "outside the scope" statement so
imho you should have in this document a problem space 
section and a reduced problem space section that you
actually cover by the analysis

>  >> 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
> 
> I think this document is based on existing framework (or 
> schemes), which is 
> RFC4726. RFC4726 states several schemes for inter-domain TE, 
> like domain 
> boundary computation (per-domain path computation) and PCE-based 
> computation (inter-domain collaborative path computation).

apparently, this is not what's assumed in section 1.5

"The description in this document of diverse LSP setup is agnostic in 
relation to the signaling option used, unless otherwise specified." 

> I think this document is not heavily dependent on protocols 
> (but dependent on existing framework).

i should have been more specific, it does not dig into
the signaling protocol details but pre-assumes that the
exchanges for path comp. purposes would be exclusively
based on PCE (if you look at the above comment you will
see that such assumption is protocol dependent)

> - Is there any missing scheme (other than listed in sections 4 and 5)?

a scheme that makes use of parallel associated segments 
(in each AS/area) before both end-to-end LSPs are setup

> - Is there anything to add/modify for some schemes?
> - Or something else?

above, i mentioned the need for a section that is more
specific about what the document covers in its analysis

that analysis must be agnostic to the PC exchange and
better see what are the key elements not wrt what these
exchanges are involving (see point 1 here above) in
terms of needed protocol mechanisms 

after this you can dig in the PC protocol details and
other mechanisms that are existing or not.

thanks,
-d.
> Thanks,
> Tomonori
> 
>  >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
>  >>  >>
>  >>  >>
>  >>  >>
>  >>  >>
>  >>
>  >> 
> 
> 
>