[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 16:43 07/07/13, PAPADIMITRIOU Dimitri wrote:
>hi tomonori
>
>well ok, the whole discussion point boils down from
>your side as i don't depart from RFC 4726 that is
>informational in nature ?
>
>was 4726 expected to be forward looking ? knowing
>there are no placeholders at IETF ?
>
>4726 states
>
>"the aim of this document is not to detail each of those techniques,
> which are covered in separate documents referenced from the sections
> of this document that introduce the techniques, but rather to propose
> a framework for inter-domain MPLS Traffic Engineering."
>
>it does not state that nothing prevents additional
>techniques to complement existing mechanisms known
>at the time that RFC was produced
I agree. If there is a momentum, we should not close the door. I think it
is up to the WG to decide.
We will add a note that this document is based on the existing framework
(RFC4726), but does not intend to prevent development of additional
techniques where appropriate.
Thanks,
Tomonori
>-d.
>
>
>
>> -----Original Message-----
>> From: Tomonori TAKEDA [mailto:takeda.tomonori@lab.ntt.co.jp]
>> Sent: Friday, July 13, 2007 6:53 AM
>> To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org
>> Subject: RE: I-D
>> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>>
>> Hi Dimitri,
>>
>> Please see in-line.
>>
>> At 16:24 07/07/12, PAPADIMITRIOU Dimitri wrote:
>> >hi tomonori,
>> >
>> >> -----Original Message-----
>> >> From: Tomonori TAKEDA [mailto:takeda.tomonori@lab.ntt.co.jp]
>> >> Sent: Thursday, July 12, 2007 6:34 AM
>> >> To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org
>> >> 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: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.
>> >
>> >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."
>>
>> Well, this is about signaling.
>>
>> In addition, what it says is that most description is
>> agnostic to signaling
>> options (i.e., schemes are well-applicable to various
>> signaling options),
>> not that the document is restricting that description should
>> be agnostic to
>> signaling options.
>>
>> Please look at the begining of section 1.3.
>>
>> This document analyzes various schemes to realize
>> Multiprotocol Label
>> Switching (MPLS) and Generalized MPLS (GMPLS) LSP
>> recovery in multi-
>> domain networks based on the existing framework for
>> multi-domain LSP
>> setup [RFC4726].
>>
>> >> 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)
>>
>> For exchanges for path computation request/reply before
>> signaling, yes, we
>> mostly assume PCE, since PCE is, to my best knowledge, a
>> well-described
>> framework for inter-domain TE in RFC4726.
>>
>> There are other path computation techniques described in
>> RFC4726, and we
>> include such schemes as well. Please see Section 3.2, "Per
>> domain path
>> computation or inter-domain collaborative path computation" bullet.
>>
>> >> - 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
>>
>> I am not sure, but is this what section 4.3.2 says?
>>
>> If no, can you give me a reference where such framework is
>> described (e.g.,
>> in RFC4726)?
>>
>>
>> Thanks,
>> Tomonori
>>
>> >> - 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: 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
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>