Subject: [Pce] Path Computation Element (PCE) Architecture and mailing list,

From: "Zafar Ali" <[email-masked]>
Date: Fri, 8 Oct 2004 17:05:35 -0400

Hi Adrian, Jerry, JP, et al, 
 
Thanks for putting the PCE Architecture document
(http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt), I
found it very useful in scoping PCE WG and applicability of PCE in MPLS/
GMPLS TE networks. In the following I have a few questions/ comments about
this ID. 
 
I would also like to request about what would be a tentative agenda for PCE
BOF Part II in DC? I think the discussion in SD went very well in favor of
PCE WG, pending this architecture ID. What is the present plan of record? 
 
- What did you meant by "the level of robustness of the path resources", in
PCC-PCE communication? I am expecting that the client can also specify an
exclude list, include list (this is in addition of SRLG to include/
exclude).  
 
- Can you please elaborate more on advantages of Stateful PCE and what are
the pits fall of using Stateful PCE in a distributed PCE environment. You
have information about Out-of-band TED synchronization but I am thinking
there is some complexity involved in such mechanism and stateful PCE in a
distributed PCE setup. More description on the applicability of Stateful PCE
& Out-of-band TED synchronization would be useful to better scope core vs..
advanced features of PCE. 
 
- When PCE is distributed, are there any considerations in path computation
(minimum guidelines, like constraints based shortest path based on the
specified optimization criteria, optimization criteria does not change for
the same setup when multiple PCE are involved in path computation, etc.) to
make Path Computations in a distributed PCE scheme, that you think we need
to add to the text of this document. 
 
- When a number of disjoint paths are required, we need a mechanism to
specify if near disjoint Paths are acceptable (but this is need not to be in
architecture doc).  
 
The rest of the document look very good to me. 
 
Regards... Zafar
 
_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 8 Oct 2004 23:31:11 +0100

Hi Zafar,

[Recipients trimmed to leave out the MPLS and CCAMP mailing lists.]

> (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt),
> I found it very useful in scoping PCE WG and applicability of PCE in 
> MPLS/GMPLS TE networks. In the following I have a few questions/
> comments about this ID. 
 
> I would also like to request about what would be a tentative agenda
> for PCE BOF Part II in DC? I think the discussion in SD went very 
> well in favor of PCE WG, pending this architecture ID. What is the
> present plan of record? 

Yup, we have requested a BOF for Washington DC and hopefully this 
will appear on the meta-agenda soon. In order to request a BOF you
must supply the intended meeting agenda, and we have done. I will 
send separate mails to the list to cover the agenda and the proposed
charter. (Thanks for triggering me to do this!)

> - What did you meant by "the level of robustness of the path
>   resources", in PCC-PCE communication? I am expecting that 
>   the client can also specify an exclude list, include list 
>   (this is in addition of SRLG to include/exclude).  

This is in section 6.6.

Exclusions are covered by the bullet point:
   - resources, resource affinities and shared resource link 
     groups (SRLGs) to use/avoid

The point you are asking about:
   - the level of robustness of the path resources
covers a qualatative assessment of the vulnerability or fragility of the resources that may be used. For example, one might grade resources based on empirical evidence (mean time between failures), on known risks (there is major building work going on near this conduit), or on prejudice (vendor X's software is always crashing). A PCC could request that only robust resources be used, or allow any resource.

Of course, this information does not comprise part of the TE information advertise by IGPs. It must come from somewhere else.

Note that the likelihood of being preempted is also somewhat computable based on past experience and current network conditions.

> - Can you please elaborate more on advantages of Stateful
>   PCE and what are the pits fall of using Stateful PCE in
>   a distributed PCE environment. You have information about
>   Out-of-band TED synchronization but I am thinking there 
>   is some complexity involved in such mechanism and stateful
>   PCE in a distributed PCE setup. More description on the 
>   applicability of Stateful PCE & Out-of-band TED 
>   synchronization would be useful to better scope core vs..
 
Good points. We need to flesh this out a little. Eiji Oki has been raising similar questions because he sees a strong benefit in knowing what LSPs exist in the system and where they run.

A useful application would be placing a high priority LSP in a crowded network such that it preempted as few other LSPs as possible (note that preempting on the minimum number of links might not result in the smallest number of LSPs being disrupted).

Another application concerns the construction and maintenance of the Virtual Network Topolgy (see the MRN draft). It is helpful to understand which other LSPs exist in the network in order to decide how to manage the FAs that exist or need to be set up.

However, as you note, the maintenance of such a stateful database is non-trivial. Actually, that isn't quite true! If there is a single PCE for the whole network, stateful PCE is almost a simple matter of remembering all of the LSPs that you have computed - if you could guarantee that the LSPs were actually set up, and know when they were torn down...

As the number of PCEs increases you might go through a stage where the PCEs synchronize state by communicating with each other. But, when LSPs are set up using computation performed all over the network, the problem becomes larger and more complex.

This is clearly a need to understand the cost-benefit analysis for this type of proposal. if the need is great enough a solution will be found whatever the cost. However, if the solution is a huge drain on the network and the function doesn't buy much...

So this is a good area for further discussion.

> - When PCE is distributed, are there any considerations
>   in path computation (minimum guidelines, like constraints
>   based shortest path based on the specified optimization 
>   criteria, optimization criteria does not change for the
>   same setup when multiple PCE are involved in path 
>   computation, etc.) to make Path Computations in a 
>   distributed PCE scheme, that you think we need to add to
>   the text of this document. 

I'm not clear what you asking.

If you mean "is there any notable difference in service to the PCC?", then there are three cases to consider.

1. Cooperative mode is used. 
In this case we have the text (section 5.4)
  Note that a PCC cannot see the difference between centralized
  computation, and multiple PCE path computation with inter-PCE
  communication. That is, the PCC network node or component that
  requests the computation makes a single request and receives a
  full or partial path in response, but the response is actually
  achieved through the coordinated, cooperative efforts of more 
  than one PCE.
This is intended to imply that the PCC gets the same service.

2. PCC must make a choice between distributed PCEs
It is clearly important that the PCC knows the properties of the
available PCEs so that it can make an informed choice. However,
there is also an option that, provided the PCC expresses its
requirements correctly, its PCE will pass a request to another
PCE to make sure that the desired service is available.

3. Will different PCCs get the same service?
Yes and no. Really the question boils down to quesiton 2.

If my ramblings don't answer your question, can I suggest that you supply some text for inclusion in the draft. The architecture is as much your draft as anyone else's!

> - When a number of disjoint paths are required, we need a 
>   mechanism to specify if near disjoint Paths are acceptable
>   (but this is need not to be in architecture doc).  

Agree on both counts. There are a large number of types and grades of dijointedness.
 
> The rest of the document look very good to me. 

Very kind of you to say so!

Regards,
Adrian

---

From: [email-masked]
Date: Sat, 9 Oct 2004 10:45:47 -0400 (EDT)

Hi guys,

I think this is a vey sound document. I have a suggestion though.

It would be extreamely useful if a PCE could advertise its capabilities
such as:

a) set of constraints that it can account for (diversity, SRLGs, optical
impairements, wavelenght continuity, etc.)

b) number of switching capability layers (and which);

c) number of path selection criterias (and which);

d) whether it is a stateless path calculator or can send updates about
better paths that might be available in future;

e) whether it can compute P2MP trees (and which types);

f) whether it can ensure the resource sharing between backup tunnels;

g) etc.

This information would help a lot for a potential PCC that dynamically
learns about PCEs available on the network to decide which of them to use.

Igor

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 9 Oct 2004 18:55:47 +0100

[Pruned recipients]

Hi Igor,

> I think this is a vey sound document. I have a suggestion though.

Thanks, and thanks.

> learns about PCEs available on the network to decide which of them to use.

You're right. This should go in section 6.4.

In addition, it seems to me that a PCC might ask a PCE to perform a particular type of
service and receive a response that says, "Sorry, I can't do that, these are the things I
can do. Here is the address of a PCE that may be able to better fulfil your request."

We need to be careful not to get too far into the possible solutions at this stage, but I
think the point you raise is important for the architecture.

Thanks,
Adrian

---

From: "Zafar Ali" <[email-masked]>
Date: Sun, 10 Oct 2004 11:55:53 -0400

Dear Adrian, 
 
Thanks for your detailed reply. Please see in-line for some follow-ups.
 
Thanks
 
Regards... Zafar

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, October 08, 2004 6:31 PM
To: Zafar Ali; [email-masked]
Cc: 'Ash, Gerald R (Jerry), ALABS'; [email-masked]; [email-masked]
Subject: Re: Path Computation Element (PCE) Architecture and mailing list, 

Hi Zafar,

 

Great! 

This is in section 6.6.

The point you are asking about:
   - the level of robustness of the path resources
covers a qualatative assessment of the vulnerability or fragility of the
resources that may be used. For example, one might grade resources based on
empirical evidence (mean time between failures), on known risks (there is
major building work going on near this conduit), or on prejudice (vendor X's
software is always crashing). A PCC could request that only robust resources
be used, or allow any resource. 

Of course, this information does not comprise part of the TE information
advertise by IGPs. It must come from somewhere else. 

Note that the likelihood of being preempted is also somewhat computable
based on past experience and current network conditions.

>   advanced features of PCE. 
 
Good points. We need to flesh this out a little. Eiji Oki has been raising
similar questions because he sees a strong benefit in knowing what LSPs
exist in the system and where they run.
 
A useful application would be placing a high priority LSP in a crowded
network such that it preempted as few other LSPs as possible (note that
preempting on the minimum number of links might not result in the smallest
number of LSPs being disrupted).
 
Another application concerns the construction and maintenance of the Virtual
Network Topolgy (see the MRN draft). It is helpful to understand which other
LSPs exist in the network in order to decide how to manage the FAs that
exist or need to be set up.
 
However, as you note, the maintenance of such a stateful database is
non-trivial. Actually, that isn't quite true! If there is a single PCE for
the whole network, stateful PCE is almost a simple matter of remembering all
of the LSPs that you have computed - if you could guarantee that the LSPs
were actually set up, and know when they were torn down...
 
As the number of PCEs increases you might go through a stage where the PCEs
synchronize state by communicating with each other. But, when LSPs are set
up using computation performed all over the network, the problem becomes
larger and more complex.
 
This is clearly a need to understand the cost-benefit analysis for this type
of proposal. if the need is great enough a solution will be found whatever
the cost. However, if the solution is a huge drain on the network and the
function doesn't buy much... 

Like I mention, and you agree, that the synchronization of "Path
information" in a distribute d  PCE is much complex and prone to race
conditions , scalability concerns, etc.  Even if we know detailed
information of "ALL" the paths at "ALL" priorities and in "ALL layers
(MRN)", taken such information into account for computation of a new path
appears highly polynomial to me.   
 
In summary, I would like to know how do you plan to pursue this cost-benefit
tradeoff analysis? Do you plan to have some description along these lines in
the next version of the Architecture Document?, etc.  

 

I will discuss more on this off-line with you.  

If you mean "is there any notable difference in service to the PCC?", then
there are three cases to consider.

 

If my ramblings don't answer your question, can I suggest that you supply
some text for inclusion in the draft. The architecture is as much your draft
as anyone else's! 

>   (but this is need not to be in architecture doc).  
 
Agree on both counts. There are a large number of types and grades of
dijointedness.

Regards,
Adrian

---

From: "Igor Bryskin" <[email-masked]>
Date: Mon, 11 Oct 2004 10:00:40 -0400

See in-line.

Igor

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, October 09, 2004 1:55 PM
Subject: Re: Path Computation Element (PCE) Architecture and mailing list,

> can do. Here is the address of a PCE that may be able to better fulfil
your request."

IB>> It won't be necessary if PCE advertises its capabilities separately.
What you are suggesting will make the PCC-PCE protocol heavier without
giving actual benefits. But you are right, it is too early at this stage to
discuss the solution yet. I believe, though, that PCC-PCE and PCE-PCE
signalling protocols will be by far the biggest challenge, and we must not
complicate it unnecessarily.

Igor

---

From: JP Vasseur <[email-masked]>
Date: Mon, 11 Oct 2004 19:43:25 -0400

Hi Igor,

> learns about PCEs available on the network to decide which of them to  

I cannot agree more ! See the two PCE cap related drafts:
	draft-vasseur-ospf--te-caps (and isis)

Such draft would probably ends up being discussed here, should we end  
up creating a WG.

JP.

>> for
>> PCE
>> resources",
>> in
>> distributed PCE setup. More description on the applicability of  
>> Stateful
>> PCE
>> the same setup when multiple PCE are involved in path computation,  
>> etc.)
>> to
>> specify if near disjoint Paths are acceptable (but this is need not  
>> to be
>> in
>> architecture doc).
>>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 11 Oct 2004 20:05:41 -0400

Hi Igor,

On Oct 11, 2004, at 10:00 AM, Igor Bryskin wrote:

>> service and receive a response that says, "Sorry, I can't do that, 
>> these
> are the things I

See my previous answer, I'm also a strong advocate for advertising PCE 
cap, such advertisement will be required anyway for the PCE discovery 
especially in multi-domain environments.

Thanks for your feed-backs.

Cheers

JP.

> Igor
>
>>
>> We need to be careful not to get too far into the possible solutions 
>> at
> this stage, but I

---

From: "Igor Bryskin" <[email-masked]>
Date: Tue, 12 Oct 2004 11:08:38 -0400

Hey JP,

Looks like we are in a wild agreement.

Igor

----- Original Message ----- 
From: "JP Vasseur" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Monday, October 11, 2004 8:05 PM
Subject: Re: [Pce] Re: Path Computation Element (PCE) Architecture and
mailing list,

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Tue, 12 Oct 2004 12:34:28 -0400

Hi Igor,

>Looks like we are in a wild agreement.

Perfect - let's continue the discussion on how to extend 
draft-vasseur-ospf-te-caps-00.txt and draft-vasseur-isis-te-caps-00.txt to 
cope with GMPLS specific parameters. Your input is very welcome.

Cheers.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 14 Oct 2004 17:18:08 -0400

Hi Igor,

> Looks like we are in a wild agreement.

Indeed, feel free to propose GMPLS PCE-cap that should be carried by 
the IGP extensions.

JP.

>>>>> learns about PCEs available on the network to decide which of them 
>>>>> to
>>> use.
>>>>
>>>> can do. Here is the address of a PCE that may be able to better 
>>>> fulfil
>>> your request."
>>>
>>> signalling protocols will be by far the biggest challenge, and we 
>>> must
>>> not

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 14 Oct 2004 18:41:13 -0400

JP,

Here is my comments on the document.

1. For some reason you define PCC as any head-end LSR. IMO PCC is any LSR
that requires remote path computation service. It could be any transit LSR
(e.g. to compute FRR backup tunnel);

2. The following capability bits are missing:

S: =1 - PCE keeps states for all PCE requests and may send updates later if
better path(s) become available.
    =0 -  PCE is stateless path calculator;

R:=1 -PCE is capable of computing paths crossing multiple switching layers
(regions)
    =0 - PCE can compute path only within a single switching layer;

X:= 1 - handles exclusions (links, nodes)
Y:= 1- handles inclusions, i.e. it is possible to specify ordered list(s) of
links/nodes (strictly or loosely) that will appear in the selected path(s)

3. Diversity

There should be TLV(s) specifying whether PCE can compute:
SRLG diverse,
node diverse,
link diverse,
best diverse  paths

4. Link level constraints
There should be TLVs specifying sub-TLVs of a TE LINK TLV that could be used
as constraints

5. Path level constraints
This would be most difficult thing to describe: max path end-to-end length,
delay/jitter, wavelength contnuity, etc.
For now I suggest a separate TLV per each constraint.

Igor

----- Original Message ----- 
From: "Jean Philippe Vasseur" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 12, 2004 12:34 PM
Subject: Re: [Pce] Re: Path Computation Element (PCE) Architecture and
mailing list,

to
fulfil
must