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

["PAPADIMITRIOU Dimitri" <[e-mail]>]

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

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