Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt

From: [email-masked]
Date: Thu, 20 Oct 2005 18:50:01 -0400

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		: A Per-domain path computation method for establishing
                          Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs)
	Author(s)	: J. Vasseur, et al.
	Filename	: draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt
	Pages		: 18
	Date		: 2005-10-20
	
This document specifies a per-domain path computation technique for 
establishing inter-domain Traffic Engineering (TE) Multiprotocol Label 
Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths 
(LSPs). In this document a domain refers to a collection of network 
elements within a common sphere of address management or path 
computational responsibility such as IGP areas and Autonomous Systems. 
 
Per-domain computation applies where the full path of an inter-domain 
TE LSP cannot be or is not determined at the ingress node of the TE 
LSP, and is not signaled across domain boundaries. This is most likely 
to arise owing to TE visibility limitations. The signaling message 
indicates the destination and nodes up to the next domain boundary. It 
may also indicate further domain boundaries or domain identifiers. The 
path through each domain, possibly including the choice of exit point 
from the domain, must be determined within the domain.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-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-pd-path-comp-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-pd-path-comp-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.

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 21 Oct 2005 11:27:16 -0400

Arthi, JP

I have a problem with the auto-discovery mechanism you described in the
draft (one that is based on query to IGP or BGP to determine outgoing
ABR/ASBR).

1. Destination ID must be network unique but it does not have to be IP
routable, for example, it could be a numbered link ID.

2. Even in case when destination is IP address, the path computing node can
only obtain the ID of an ABR or ASBR that advertises IP route to the
destination, which would be one that knows about the shortest IP path to the
destination. However, it does not mean that properly constrained TE path
from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is not
suboptimal compared to one from some other ABR/ASBR which knows about worse
IP path to the destination and hence will not be reported to the computing
entity by the routing sub-system.

I wonder why not to use the remote PCE service for this purpose. For
instance a PCC may ask a PCE to determine either the ID of the outgoing
domain border node or entire path in terms of domain border nodes. You may
ask why not to request explicit path(s) in this case? Several reasons why
the PCC wouldn't want to do so:

a) it could be easier and faster for the PCE to determine domain border node
in direction towards the destination rather than explicit path(s). For
instance, the latter may require cooperation of other PCEs;

b) security considerations - PCE may not want to reveal remote domain
topology(ies)

c) it may be desirable to compute and setup services on per-domain basis,
for instance, to have each domain take separate care for service
restoration.

What do you think?

Igor

----- Original Message ----- 

From: <[email-masked]>

To: <[email-masked]>

Cc: <[email-masked]>

Sent: Thursday, October 20, 2005 6:50 PM

Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 21 Oct 2005 19:20:30 +0100

Hi Igor,

I think you have to set the context of this I-D carefully, and then
understand the limited scope that is additionally proposed.

The context of the I-D is limited to the per-domain computation case.
Hence, consulting an external PCE is out of scope. This is not to say that
it is not valid to consult a PCE (in fact, you might expect JP and me to
support that technique), but this I-D is demonstrating what we can do and
how we can solve the problem without using PCE.

With respect to the use of the IP reachability, you may recall that I
raised this concern in Paris and on the list. The conclusion was that if
you have no other way of determining an exit router for your domain, then
attempting to use the IP reachability is no worse than giving up, and may
be much better.

In the cases you raise:
1. Yes, an interface address may be unreachable.
    Do we lose anything by consulting IP reachability in this case?
    No.
2. Yes, the IP reachability may give us a sub-optimal TE path.
    Is this path worse than no path?
    No.

So I asked the authors to be clear that what they are suggesting has
limitations, and should not be applied in some specific cases. I haven't
looked at the text yet, but I hope they have covered this.

Cheers,
Adrian
----- Original Message ----- 
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>; "Arthi Ayyangar" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 21, 2005 4:27 PM
Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt

> > [email-masked] with the word unsubscribe in the body of
the
> message.
> > "FILE
/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt".

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 21 Oct 2005 14:31:30 -0400

Adrian,

I understand and agree with what you are saying. My point was that a) when
PCE is available, the PCE service could be a better way for determining the
outgoing domain border node, and b) per-domain path computation could be
useful even when you have PCE service available.

In other words I was just suggesting an alternative method for per-domain
path computation, that's all.

Igor

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>; <[email-masked]>; "Arthi Ayyangar"
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 21, 2005 2:20 PM
Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 21 Oct 2005 15:59:18 -0400

Adrian,

>     Do we lose anything by consulting IP reachability in this case?

This is not what I was talking about, which was a destination located in
some remote domain and TE reachable to the source while not IP routable
(because destination is a numbered link ID, this is a very usual case in a
multi-area GMPLS non-packet network). The only guy who would know about such
destination is a PCE with sufficient TE visibility. There is no point in
such case to consult IP routing and we do loose by doing so rather than
consulting PCE (provided, of course, that PCE is available)

>     Is this path worse than no path?

Again, the path provided by IP has nothing to do with the TE path, and PCE
is certainly in a better position to provide (albeit loose) path specifying
a list of proper border nodes or just the next border node.

The bottom line: when PCE is available one should never consult IP routing
to determine the outgoing border node when one performs per-domain path
computation. If PCE is not available, than in case of IP network, I agree,
there is a value to consult IP routing. This is because in IP world TE
resources are still tightly coupled with IP interfaces. In the non-IP world,
I'd say, consulting IP routing makes much lesser sense: it could give you a
path when no TE path exists or, more importantly, fail the request when one
or more TE paths do exist. I'd suggest in this case rather than consulting
IP (which is as useful IMO as consulting somebody's Outlook address book) to
route the LSP towards any known domain border node and hope that the latter
will crankback the request specifying the proper border node if necessary.

Cheers,

Igor

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>; <[email-masked]>; "Arthi Ayyangar"
<[email-masked]>
Cc: <[email-masked]>

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 22 Oct 2005 23:04:08 +0200

hi,

i have specific comments - on the kernel section of this document 
(starting at section 4)

"    - If the domain is PSC (Packet Switch Capable) and uses in-band
       control channel "

which domain ? and how to ensure the sequence of domains to reach the 
"next-hop" are satisfying this constraint ?

"If the next-hop is reachable, then it SHOULD find a domain
boundary LSR (domain boundary point) to get to the next-hop. The
determination of domain boundary point based on routing information is
what we term as "auto-discovery" in this document. In the absence of
such an auto-discovery mechanism, a) the ABR in the case of inter-area
TE or the ASBR in the next-hop AS in the case of inter-AS TE should be
the signaled loose next-hop in the ERO and hence should be accessible
via the TED"

i don't understand the "the signaled loose next-hop in the ERO and hence 
should be accessible via the TED" would it be possible to clarify ? i 
have some troubles to understand the sentence: the ingress ASBR receives 
a ERO being e.g. a collection of ASs and then performs expansion e.g. 
strict route until the head-end ABR and then loose-hop until the 
tail-end ASBR within that AS but the latter will not necessarily be in 
the TED; still the procedure works this is classical loose routing; 
hence, the process shall be defined such as being recursive, and the 
"signaled loose next-hop" must be process as the initial "non-TE 
reachable but IP reachable next-hop" by the head-end ABR receiving the 
incoming ERO

on the other side, what is the specific "auto-discovery" mechanism ? and 
what is the "domain boundary point" ? the concern i have here is that 
the default loose routing case appears like the particular case when not 
delivering a mechanism which is not specified ?

the document should be constructed such that the process can provide 
BASE loose routing computation (local domain strict routing based on TE 
information and loose routing based on IP reachability) and allow for 
accommodating additional mechanism (and so information) when possible 
not the other way around;

thanks for clarifying,

ps: what the purpose of sections 3.2, 3.3, 4.1, and 4.2 ?

- dimitri.

Adrian Farrel wrote:

>>2. Even in case when destination is IP address, the path computing node
> 
> can
> 
>>destination, which would be one that knows about the shortest IP path to
> 
> the
> 
>>from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is
> 
> not
> 
>>suboptimal compared to one from some other ABR/ASBR which knows about
> 
> worse
> 
>>IP path to the destination and hence will not be reported to the
> 
> computing
> 
>>domain border node or entire path in terms of domain border nodes. You
> 
> may
> 
>>ask why not to request explicit path(s) in this case? Several reasons
> 
> why
> 
>>a) it could be easier and faster for the PCE to determine domain border
> 
> node
> 
>>c) it may be desirable to compute and setup services on per-domain
> 
> basis,
> 
>>>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.
>>
>>>                          Inter-domain Traffic Engineering (TE) Label
>>
>>Switched Paths (LSPs)
>>
>>>Internet-Drafts are also available by anonymous FTP. Login with the
>>
>>username
>>
> .

---

From: Cristel Pelsser <[email-masked]>
Date: Tue, 25 Oct 2005 09:43:57 -0400

Hi Igor, all,

I made some simulations with a per-domain path computation where the 
border node is selected by the PCE.
You can find a brief description of this path computation method at 
http://www.info.ucl.ac.be/~cpe/pelsser_conext2005.pdf
and http://www.info.ucl.ac.be/~cpe/poster_conext_cpe.pdf

Cristel

---

From: Arthi Ayyangar <[email-masked]>
Date: Tue, 25 Oct 2005 19:47:20 -0700 (PDT)

Hi Igor,

Just to reiterate what Adrian said, this ID is only intended to cover the 
case where you do not have a PCE.

I do, however, agree with what you say below in "The bottom line".

thanks,
-arthi

---

From: "Igor Bryskin" <[email-masked]>
Date: Wed, 26 Oct 2005 10:03:54 -0400

Arthi,

I think we are in complete agreement here.

Igor

----- Original Message ----- 
From: "Arthi Ayyangar" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, October 25, 2005 10:47 PM
Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt

> > Subject: Re: I-D
ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt
> >> Subject: Re: I-D
ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt
> >>>> You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: JP Vasseur <[email-masked]>
Date: Tue, 25 Oct 2005 09:51:42 -0400

Hi Igor,

On Oct 25, 2005, at 10:47 PM, Arthi Ayyangar wrote:

> Hi Igor,
>
> Just to reiterate what Adrian said, this ID is only intended to  
> cover the case where you do not have a PCE.
>

As I told you before the PCE case used to be in scenario 2 of the  
former inter-domain draft and will be resurrected and discussed in  
the PCE WG for IETF-65.

JP.