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

From: Tomonori TAKEDA <[email-masked]>
Date: Mon, 09 Jul 2007 11:04:03 +0900

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: [email-masked]
 >From: [email-masked]
 >Date: Fri, 06 Jul 2007 14:15:01 -0400
 >X-Spam-Score: 0.0 (/)
 >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
 >Cc: [email-masked]
 >Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >X-BeenThere: [email-masked]
 >X-Mailman-Version: 2.1.5
 >Reply-To: [email-masked]
 >List-Id: i-d-announce.ietf.org
 >List-Unsubscribe:
 ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]?subject=unsubscribe>
 >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
 >List-Post: <mailto:[email-masked]>
 >List-Help: <mailto:[email-masked]?subject=help>
 >List-Subscribe:
 ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]?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,fgs=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-domain-recovery-analysis-01.txt
 >
 >To remove yourself from the I-D Announcement list, send a message to
 >[email-masked] 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:
 >	[email-masked].
 >In the body type:
 >	"FILE /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-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: <[email-masked]>
 >
 >ENCODING mime
 >FILE /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >
 >
 ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt>
 >_______________________________________________
 >I-D-Announce mailing list
 >[email-masked]
 >https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: Tomonori TAKEDA <[email-masked]>
Date: Mon, 09 Jul 2007 16:35:04 +0900

Hi Meral,

Thanks for you comments. I copied CCAMP list here for sharing information.

Please see in-line.

At 13:07 07/07/09, Meral Shirazipour wrote:
 >Dear Tomonori,
 >   I just finished reading the draft. Below I have a few comments/suggestions,
 >mainly regarding typos and clarity.
 >
 >Warm Regards,
 >Meral
 >
 >[Page 2/16]
 >5.4 Inter-domain Collaborate Path Computation....................16
 >
 >Maybe Collaborative would be better?!

Thanks.

 >[Page 4]
 >section 1.2 Domain
 >"In such a scenarios,..."
 >
 >Should be "In such scenarios" or "In such a scenario"

Thanks.

 >section 1.3 Document Scope , third paragraph
 >"which can advantageously used"
 >Should be "which can advantageously be used"

Thanks.

 >[Page 6/7]
 >"Figure 2: Mesh Connectivity"  should be on page 6

OK.

 >[Page 9]
 >"An example of such a scheme is Backward Recursive Pause Computation (BRPC)
 >[brpc]"
 >
 >"Pause" should be replaced by "Path"

Thanks.

 >[Page 20]
 >[brpc]:
 >A Backward Recursive PCE-based Computation (BRPC) procedure to compute
 >shortest inter-domain Traffic Engineering Label Switched Paths
 >
 >Path with S

Thanks.

 >[Page 12]
 >first paragraph:"This scheme cannot guarantee to establish diverse LSPs (even if
 >they could exist) because the first LSP is established without consideration of
 >the need for a diverse recovery LSP. Crankback [crankback] may be used in
 >combination with this scheme in order to improve the possibility of successful
 >diverse LSP setup."
 >
 >How can crankback on the protection LSP help if the problem is the already
 >established working LSP ?!

There are several causes why the recovery LSP can not be computed. In one 
case, the recovery LSP can not be computed because the working LSP is 
blocking (there is no way). In another case, the recovery LSP can not be 
computed because the bad border node is selected, but crankback can fix 
this. We are not saying that the first case can be fixed by crankback.

Thanks,
Tomonori

 >
 >
 >
 >
 >
 >
 >Selon Tomonori TAKEDA <[email-masked]>:
 >
 >> Hi,
 >>
 >>  >	"FILE
 >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
 >>  >
 >>  >FILE
 >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >
 >>  >
 >>

---

From: Meral Shirazipour <[email-masked]>
Date: Mon, 09 Jul 2007 10:30:58 -0400

Dear Tomonori,
   Thank you for the explanation:
----------
>[Page 12]
>first paragraph:"This scheme cannot guarantee to establish diverse LSPs (even
>if they could exist) because the first LSP is established without
>consideration of the need for a diverse recovery LSP. Crankback [crankback]
>may be used in combination with this scheme in order to improve the
>possibility of successful diverse LSP setup."

----------

 Just to make sure that I understood well, crankback is used when the entity
that determined the diverse recovery LSP had only access to an out of date
information that did not include the recently deployed working LSP ?

Thanks again for taking the time...

Warm Regards,
Meral

Selon Tomonori TAKEDA <[email-masked]>:

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

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Mon, 9 Jul 2007 23:10:47 +0200

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 ?

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

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tomonori TAKEDA
> Sent: Monday, July 09, 2007 4:04 AM
> To: [email-masked]
> Subject: Fwd: I-D 
> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
> :[email-masked]?subject=unsubscribe>
> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
> :[email-masked]?subject=subscribe>
>  >X-Junkmail: UCE(35)
>  >	Filename	: 
> draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >	Pages		: 23
>  >	Date		: 2007-7-6
>  >
>  >You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: Tomonori TAKEDA <[email-masked]>
Date: Tue, 10 Jul 2007 16:34:41 +0900

Hi Meral,

Please see in-line.

 >   Thank you for the explanation:

Out of date information is yet another case where the recovery LSP can not 
be computed. Crankback is also applicable when information is up-to-date 
(when there are more than two border nodes).

Here is an example.

     B----------E
   /              \
  /                \
A---C----------F---H
  \             |  /
   \            | /
     D----------G

- A,B,C,D belong to domain#1.
- E,F,G,H belong to domain#2.
- The working LSP is A->D->G->F->H.

Assume we are using per-domain sequential path computation, and trying to 
establish the recovery LSP from A to H.

For the recovery LSP, domain#1 may compute A->C. At domain#2 (or at F), we 
know that the recovery LSP can not be computed since the working LSP is 
blocking. Now crankback can fix this by notifying domain#1, and domain#1 
re-computes the recovery LSP as A->B.

Hope this clarifies.

Thanks,
Tomonori

---

From: Tomonori TAKEDA <[email-masked]>
Date: Tue, 10 Jul 2007 16:50:46 +0900

Hi Dimitri,

Thanks for your comments.

Please see in-line.

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

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.

 >possible is to condition the first LSP setup with additional constraints

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.

Thanks,
Tomonori

 >> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do>> 
main-recovery-analysis-01.txt>

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 10 Jul 2007 12:54:18 +0200

hi tomonori - see inline 

> From: Tomonori TAKEDA [mailto:[email-masked]] 
> Sent: Tuesday, July 10, 2007 9:51 AM
> To: PAPADIMITRIOU Dimitri; [email-masked]
> Subject: RE: I-D 

this is what the diagrams and text infers

generalizing the number of edges/inter-connection
adds an additional constraints (select 2 among N)

> good pair of border nodes. Please see my separate email to 

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 

> already selected, the only thing that remains is to select 

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.

---

From: Tomonori TAKEDA <[email-masked]>
Date: Thu, 12 Jul 2007 13:33:43 +0900

Hi Dimitri,

Please see in-line.

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

 >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

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 12 Jul 2007 09:24:03 +0200

hi tomonori,

> Sent: Thursday, July 12, 2007 6:34 AM

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

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

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

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

> - Is there anything to add/modify for some schemes?

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.
>  >>  >>  >List-Help: 
> <mailto:[email-masked]?subject=help>
>  >>  >>  >List-Subscribe:
>  >>  >>
>  >>  >>  >"get 
> draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
>  >>  >>  >

---

From: Tomonori TAKEDA <[email-masked]>
Date: Fri, 13 Jul 2007 13:53:28 +0900

Hi Dimitri,

Please see in-line.

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

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

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

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 13 Jul 2007 09:43:23 +0200

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.

> Sent: Friday, July 13, 2007 6:53 AM
>  >>  >>  >> A new version of inter-domain recovery analysis 
> I-D have been
>  >>  >>  >> published.
>  >>  >>  >>
>  >>  >>  >> Here are major changes:
>  >>  >>  >> - Enhanced text on computing diverse paths 
> sequentially with
>  >>  >>  >> confidentiality
>  >>  >>  >>    (Section 5.4.1)
>  >>  >>  >> Authors believe the document is now completed and 
> ready for
>  >>  >>  >> WG last call.
>  >>  >>  >>
>  >>  >>  >> Thanks,
>  >>  >>  >> Tomonori
>  >>  >>  >>
>  >>  >>  >>  >List-Archive: 
> <http://www1.ietf.org/pipermail/i-d-announce>
>  >>  >>  >>  >[email-masked] with the word 
> unsubscribe in
>  >>  >>  >> the body of
>  >>  >>  >>  >the message.
>  >>  >>  >>  >You can also visit
>  >>  >>  >>  >	a MIME-compliant mail reader.  
> Different MIME-compliant
>  >>  >>  >> mail readers

---

From: Tomonori TAKEDA <[email-masked]>
Date: Fri, 13 Jul 2007 20:14:57 +0900

Hi Dimitri,

Please see in-line.

 >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