[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 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)
> 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: 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
> >>
> >>
> >>
> >>
>
>
>