[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,
Please see in-line.
At 19:54 07/07/10, PAPADIMITRIOU Dimitri wrote:
>hi tomonori - see inline
>
>> -----Original Message-----
>> From: Tomonori TAKEDA [mailto:takeda.tomonori@lab.ntt.co.jp]
>> Sent: Tuesday, July 10, 2007 9:51 AM
>> To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org
>> 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: 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
>> >>
>> >>
>> >>
>> >>
>>
>>