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

[Tomonori TAKEDA <[e-mail]>]

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:[e-mail]]
 >> Sent: Friday, July 13, 2007 6:53 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 16:24 07/07/12, PAPADIMITRIOU Dimitri wrote:
 >>  >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."
 >>
 >> 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: [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
 >>  >>  >>  >>
 >>  >>  >>  >>
 >>  >>  >>  >>
 >>  >>  >>  >>
 >>  >>  >>
 >>  >>  >>
 >>  >>
 >>  >>
 >>  >>
 >>
 >>
 >>