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

[Tomonori TAKEDA <[e-mail]>]

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.

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

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

- Is there any missing scheme (other than listed in sections 4 and 5)?
- Is there anything to add/modify for some schemes?
- Or something else?


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