Subject: [Pce] clarification on draft-ietf-pce-architecture-03.txt

From: [email-masked]
Date: Thu, 5 Jan 2006 00:49:20 +0100

arch. document section 6.6 mentions

   "The path computation request may include a significant set of
   requirements including:

   - the source and destination of the path"

... there is an underlying question beside this, is it the 
source/destination of the LSP or is it the source/destination between 
which path computation has to be performed and that may correspond to the 
source/destination of the LSP itself

the side point is that in that the notion of path was since so far linked 
to the signaling protocol hence linked to the notion of LSP, but it in the 
context of a PCE this notion does not necessarily hold anymore, e.g., one 
coudl request for the computation of a path between point A and point B (A 
being not the sourceof the LSP and B being not the destination of the LSP) 
even if there is no a 1:1 relationship between the entity corresponding to 
the path between A and B and the way the signaling protocol translate the 
"path segment" between A and B

some clarification would be welcome here in the context of this document

thanks,
- dimitri; 

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: JP Vasseur <[email-masked]>
Date: Wed, 4 Jan 2006 22:21:44 -0500

Hi Dimitri,

On Jan 4, 2006, at 6:49 PM, [email-masked] wrote:

> ... there is an underlying question beside this, is it the source/ 
> destination of the LSP or is it the source/destination between  
> which path computation has to be performed and that may correspond  
> to the source/destination of the LSP itself
>
> the side point is that in that the notion of path was since so far  
> linked to the signaling protocol hence linked to the notion of LSP,  
> but it in the context of a PCE this notion does not necessarily  
> hold anymore, e.g., one coudl request for the computation of a path  
> between point A and point B (A being not the sourceof the LSP and B  
> being not the destination of the LSP) even if there is no a 1:1  
> relationship between the entity corresponding to the path between A  
> and B and the way the signaling protocol translate the "path  
> segment" between A and B

The request applies for a path computation between a point A and a  
point B (the source and destination). The text does not imply that  
the source and the destination of such path correspond to the source  
and destination of the TE LSP ?

Thanks.

JP.

---

From: [email-masked]
Date: Thu, 5 Jan 2006 10:18:12 +0100

hi j-p see in-line

The request applies for a path computation between a point A and a point B 
(the source and destination). The text does not imply that the source and 
the destination of such path correspond to the source and destination of 
the TE LSP ?

[dp] so, the source and destination (as listed) is the source and 
destination of the path to be computed and not the source and destination 
of the LSP (for which this computation is requested) it is thus worth 
dropping a couple of lines concerning this relationship to avoid any 
further confusion; indeed, when i look at the interpretation done in PCEP 
the situation is not the one described in the architecture document

       "7.5. END-POINTS Object 
 
       The END-POINTS object is used in a PCReq message to specify the 
       source IP address and the destination IP address of the TE LSP for 
       which a path computation is requested. Two END-POINTS objects (for 
       IPv4 and IPv6) are defined." 

this said, having the computation request scope decoupled from the LSP 
reach is of primary importance

thanks, 
- dimitri;

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 5 Jan 2006 11:15:34 -0000

Hi,

Changed the subject line since the comments now apply to section 7.5
draft-ietf-pce-pcep-00.txt

I agree with Dimitri.
The next needs to be cleaned a little because it implies that the end
points of the requested computation are the end points of the TE LSP.

It is also interesting to consider whether it would be useful to the PCE
to know the actual end points of the service for which this computation is
providing a segment. Fells like it might be, but unless we can actually
see that reason now, we should leave the information out, and only add it
when we discover the need.

Cheers,
Adrian

> the side point is that in that the notion of path was since so far
linked

---

From: JP Vasseur <[email-masked]>
Date: Thu, 5 Jan 2006 07:45:19 -0500

Hi Dimitri,

On Jan 5, 2006, at 4:18 AM, [email-masked] wrote:

> the source and the destination of such path correspond to the  
> source and destination of the TE LSP ?
>
> destination of the path to be computed and not the source and  
> destination of the LSP (for which this computation is requested) it  
> is thus worth dropping a couple of lines concerning this  
> relationship to avoid any further confusion; indeed, when i look at  
> the interpretation done in PCEP the situation is not the one  
> described in the architecture document
>
>        "7.5. END-POINTS Object
>

Agree, the definition of the END-POINT object in PCEP will be  
reworded in the next rev to avoid confusion indeed.

Thanks.

JP.

> this said, having the computation request scope decoupled from the  
> LSP reach is of primary importance
>
> thanks,
> - dimitri;

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 5 Jan 2006 09:40:27 -0500

Hi,

I agree with Dimitri.

Path computation is concerned only with definition of path(s) between a set of one or more sources and a set of one or more destinations and signaling of the resulting paths for the purpose of dynamic LSP provisioning is just one (of many) ways how PCE technology could be used. In my opinion all PCE related definitions should be decoupled from LSP related definitions as much as possible.

Igor
  ----- Original Message ----- 
  From: [email-masked] 
  To: JP Vasseur 
  Cc: [email-masked] ; [email-masked] 
  Sent: Thursday, January 05, 2006 4:18 AM
  Subject: Re: [Pce] clarification on draft-ietf-pce-architecture-03.txt

  hi j-p see in-line 

  ... there is an underlying question beside this, is it the source/destination of the LSP or is it the source/destination between which path computation has to be performed and that may correspond to the source/destination of the LSP itself 

  the side point is that in that the notion of path was since so far linked to the signaling protocol hence linked to the notion of LSP, but it in the context of a PCE this notion does not necessarily hold anymore, e.g., one coudl request for the computation of a path between point A and point B (A being not the sourceof the LSP and B being not the destination of the LSP) even if there is no a 1:1 relationship between the entity corresponding to the path between A and B and the way the signaling protocol translate the "path segment" between A and B 

  The request applies for a path computation between a point A and a point B (the source and destination). The text does not imply that the source and the destination of such path correspond to the source and destination of the TE LSP ? 

  [dp] so, the source and destination (as listed) is the source and destination of the path to be computed and not the source and destination of the LSP (for which this computation is requested) it is thus worth dropping a couple of lines concerning this relationship to avoid any further confusion; indeed, when i look at the interpretation done in PCEP the situation is not the one described in the architecture document 

         "7.5. END-POINTS Object 

  this said, having the computation request scope decoupled from the LSP reach is of primary importance

  thanks, 
  - dimitri; 

------------------------------------------------------------------------------

---

From: JP Vasseur <[email-masked]>
Date: Thu, 5 Jan 2006 09:50:20 -0500

Hi Igor,

As I said I also agree ... and this is in line with the architecture ID.

Thanks.

JP.

On Jan 5, 2006, at 9:40 AM, Igor Bryskin wrote:

> Hi,
>
> I agree with Dimitri.
>
> Path computation is concerned only with definition of path(s)  
> between a set of one or more sources and a set of one or more  
> destinations and signaling of the resulting paths for the purpose  
> of dynamic LSP provisioning is just one (of many) ways how PCE  
> technology could be used. In my opinion all PCE related definitions  
> should be decoupled from LSP related definitions as much as possible.
>
> Igor