Subject: RE: [Pce] Draft PCE WG Minutes - IETF-63

From: "Gray, Eric" <[email-masked]>
Date: Mon, 15 Aug 2005 10:47:50 -0400

Adrian, Igor, et al -

	Are we considering the option to have a PCC need to
serially consult multiple PCE in order to obtain a complete
path computation for a single path?  That is what it sounds 
like Igor said and Adrian included in his list of options.

	And - if we are considering this - are we doing so out
of some sort of "completeness criteria" or because there is
someone who thinks this is either a good idea or a necessary
evil?

	If we are considering this option out of a need to be
thorough, that's okay - but I hope we can quickly put this 
one to bed in analysis.  The one justification for this is if
it is more important to authenticate the requester than it is
to authenticate the request for extended path setup.  

	Just a few drawbacks to this approach revolve around the
complexity of:

o	PCC having to have contact information, authentication
	tokens, etc. for extensive networks of remote PCE - at 
	least on an as needed basis.
o	Protocol "tokens" to indicate to the PCC where to go for
	the next part of the path computation - and possibly how
	to contact (and possibly be authenticated by) that (or 
	those) PCE.
o	Protocol mechanisms to notify each consulted PCE if the 
	path ultimately cannot be computed.
o	Complexity in the PCE to support partial path allocation
	- possibly on a temporary basis - and mechanisms to get
	back resources if a PCC becomes non-respondent.
o	Complexity in the PCC to support partial path allocation
	at multiple PCE and reliable delivery of non-completion
	notification.

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Adrian Farrel
--> Sent: Sunday, August 14, 2005 5:51 AM
--> To: [email-masked]; JP Vasseur
--> Cc: [email-masked]
--> Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63
--> 
--> 
--> Hi,
--> 
--> Yes, we should record Igor's comments in the minutes as he 
--> made them.
--> 
--> However, I would like to tackle them here.
--> 
--> > 1. Architecture document
--> >
--> > I made a comment that I disagree with the current 
--> definition of the
--> > distributed path computation.
--> >
--> > In the document:
--> > centralized path computation = computation performed by a 
--> single PCE
--> > distributed path computation = computation performed by 
--> multiple PCEs
--> >
--> > In my opinion:
--> > centralized path computation = path computation that returns all
--> requested
--> > paths in the *explicit* form in the first response, so 
--> that no more
--> > requests will be needed neither from the original 
--> requestor nor from any
--> > other PCCs for the service in question
--> 
--> Hmmm. So in this model a single PCE would be responsible 
--> for returning the
--> complete path and no other PCE would be invoked. This is, 
--> of course, very
--> close to the existing definition of "centralized path 
--> computation" since
--> if there is only one PCE there is no option but to compute 
--> the entire path
--> on that PCE.
--> 
--> However, your definition would allow more than one PCE in 
--> the network, but
--> still have only one PCE consulted for any individual path. 
--> This mode of
--> operation is called "single PCE path computation" to contrast with
--> "multiple PCE path computation" in the draft.
--> 
--> > distributed path computation is when the original path computation
--> request
--> > is responded with at least one non-explicit path, so that 
--> more path
--> > computations will be issued from the original or some other PCCs.
--> 
--> This, of course, is strikingly similar to the definition of 
--> distributed
--> path computation in the draft. That is, the path is 
--> computed by more than
--> one PCE.
--> 
--> However, your definition states that a path will be 
--> computed by multiple
--> PCE consultation, while the current definition of distributed path
--> computation states that multiple PCEs are servicing the 
--> requests in the
--> network. Your definition matches the definition of 
--> "multiple PCE path
--> computation" in the draft.
--> 
--> I see absolutely zero value in quibbling about the name 
--> given to a concept
--> when the concepts are identical and are all covered by the 
--> existing I-D.
--> 
--> > In other words from the original requestor point of view (which is
--> > ultimate user of the PCE service) it does not matter how 
--> many PCEs will
--> be
--> > involved to satisfy its request, what is important is how many
--> additional
--> > path computations is needed (0 -centralised
--> > path computation, >0 - distributed path computation).
--> 
--> We agree that there may be some value in distinguishing the 
--> behavior from
--> the point of view of the requester. There are exactly three 
--> cases for the
--> requester:
--> 1. The requester sends a single request to exactly one PCE and gets
-->     enough information to make use of the response.
--> 2. The requester must send more than one request to exactly one
-->    PCE in order to get enough information to make use of the
-->    responses.
--> 3. The requester must send requests to more than one PCE to
-->    get enough information to make use of the responses.
--> In none of these case is the requester, the PCC, aware of 
--> whether some
--> other LSR in the network will subsequently need to consult 
--> other PCEs.
--> Arhcitecturally, it should not be aware of this fact. From 
--> a protocol
--> perspective it must not be aware of this fact.
--> 
--> Adding a description of the behavior from the persepective 
--> of the PCC can
--> be done. However, it will not change the definitions of the 
--> terms that
--> describe the overall architecture. It will introduce new 
--> terms to describe
--> the behavior.
--> 
--> > 2. WRT proposed PCEP solutions I made a comment that 
--> neither of them
--> > satisfies the requirement of the extensibility. Introducing new
--> > constraints, objection functions, diversity types, etc will be
--> extreamely
--> > painful. Hence a meta-language style protocol should be considered
--> 
--> You are correct that we should consider a meta-language 
--> style protocol
--> although unless someone brings a draft to the table we will 
--> not consider
--> one. That is, you cannot mandate that the working group 
--> must develop a
--> particular style of protocol - we can only consider what we 
--> have in front
--> of us in terms of proposals that people are prepared to develop and
--> implement.
--> 
--> I do not believe that you are correct to state that a 
--> TLV-based protocol
--> is extremely painful to extend. Our experience of very many 
--> such protocols
--> show that they are fairly simple to extend.
--> 
--> It is possible that you could supply a specific example of 
--> an extension
--> that you think is both likely to be required and which you 
--> consider would
--> be hard to encode in a TLV. To do this you would need to 
--> supply a detailed
--> description of the information that you want to encode - it 
--> would not be
--> enough to say "diversity types". Other people could then 
--> demonstrate that
--> such an extension could be encoded. I should point out, 
--> however, that a
--> TLV is capable of encoding a text string - this means that 
--> pretty much
--> anything can be encoded within a TLV.
--> 
--> Whatever, such a proof-by-example style of reasoning is 
--> unlikely to get us
--> very far. If a meta-language style protocol is to be 
--> considered, we need
--> to see it and know that it is being implemented.
--> 
--> Cheers,
--> Adrian
--> 
--> 
--> _______________________________________________
--> Pce mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/pce
--> 

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

---

From: "Igor Bryskin" <[email-masked]>
Date: Mon, 15 Aug 2005 11:46:06 -0400

Eric,

See my comments in-line.

Igor

----- Original Message ----- 
From: "Gray, Eric" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>; <[email-masked]>; "JP
Vasseur" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 15, 2005 10:47 AM
Subject: RE: [Pce] Draft PCE WG Minutes - IETF-63

> like Igor said and Adrian included in his list of options.

IB>> This scenario is possible but IMO is not typical. What I was referring
to are the following scenarios:

a) a PCC on the service ingress LSR requests a path computation from a
single PCE. The latter involves in the path computation 0 or more other
PCEs.
Eventually, the first PCE responds with one or several paths. If the paths
are explicit, than no more additional path computations will be requested
neither from
the ingress LSR nor from any transit LSRs. As far as the ingress LSR is
concerned this is the centralized path computation no matter how many PCEs
actually
participated in the path computation;

b) a PCC on the service ingress LSR requests a path computation from a
single PCE. The latter returns one or several paths with at least one of
them in the the non-explicit form, that is, containing loose hops and/or
abstract node subobjects. This is the case of the distributed path
computation, because somewhere downstream one or more transit LSRs will have
to request additional path computations (possibly from the same PCE)

> someone who thinks this is either a good idea or a necessary

IB>> I personally think this is for the sake of completeness with an
exception of the off-line path computation.
> at multiple PCE and reliable delivery of non-completion

IB>> Well, all these issues are also true wrt the scenario:
PCC->PCE1->PCE2->PCE1->PCC (multi-PCE path computation), and since they have
to be addressed anyway I don't see how this scenario is different from the
point of view of complexities you described above compared to the scenario:
PCC->PCE1->PCC->PCE2->PCC.

Cheers,
Igor

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Aug 2005 13:23:51 +0100

Hi Igor...

> neither from the ingress LSR nor from any transit LSRs. As far as the
> ingress LSR is concerned this is the centralized path computation no
> matter how many PCEs actually participated in the path computation;

I repeat that it does not help to take an existing term that already
applies to an existing scenario and apply that term to another scenario.

Your scenario is valid and needs to be in the architecture I-D. But you
cannot use the term "centralized path computation" to describe it.

> computation, because somewhere downstream one or more transit LSRs
> will have to request additional path computations (possibly from the
same
> PCE)

Again, a valid scenario, but an unhelpful re-use of an existing term.

> exception of the off-line path computation.

Hmmm.
Well, we do not do things for the sake of completeness. We do things to be
implemented and deployed.

Nevertheless, we will include a section in the Architecture to describe
"The view from the PCC" that should cover your scenarios to your
satisfaction.

> PCC->PCE1->PCE2->PCE1->PCC (multi-PCE path computation),

Or, to more precisely use the language of the Architecture I-D, "Multiple
PCE Path Computation with Inter-PCE Communication"

> and since they have

Well you should think about implementation complexity for the PCC.
A first question might be "How does the PCC in your second example know
that it needs to invoke PCE2?"
If the answer is that it must parse the returned path and understand:
- that the path is not complete
- that PCE2 is responsible for completing part of the path
- the location of PCE2
then you have considerably increased the function that the PCC must
include.
For inter-domain cases, you are also significantly increasing the
complexity of policy.
I also wonder about the consequences for scaling.

But these are the points that Eric raised and you seem to think are not
important.

Adrian

---

From: "Igor Bryskin" <[email-masked]>
Date: Tue, 16 Aug 2005 11:43:25 -0400

Adrian,
See in-line.

Igor

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>; "Gray, Eric"
<[email-masked]>; "JP Vasseur" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 16, 2005 8:23 AM
Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63

> cannot use the term "centralized path computation" to describe it.

IB>> But this is the whole point of the discussion.
I repeat that current definitions for centralized and distributed path
computation are too one-sided. Note that the terms did exist
*before* the PCE architecture was introduced: when a PCE is a part of an
LSR's control plane, it is pretty clear what does distributed path
computation
mean: it comes down to how many additional path computation will be
*requested* for the service. From the TE and LSP setup blocking probability
point of view
it is important not because that the additional path computations will be
*performed*, rather, that the resulting paths will be worse compared to ones
produced by a single path computation performed on the ingress LSR (which
is/was the case of the centralized path computation). I don't see a reason
why the terms needed to be redefined.

> Again, a valid scenario, but an unhelpful re-use of an existing term.
IB>> the same comment

> I also wonder about the consequences for scaling.

IB>> Completely agree with you. For the very same reasons that you just
described I (as a PCC) wouldn't  use this mode for
an on-line path computation. However, for the off-line path computation when
I don't have time limitations - why not?  I have discovered two PCEs
in the domain, so I send identical requests simultaneously to both of them.
Once I get responses I compare the returned paths - costs, diversities,
expliticity, constraints that were honored, etc. - and select the better
set. Note that Eric has not raised the issue of scalability, his concerns
were, as I understood, security and additional complexity for coordination
of partial path computations. I am not worried about that because when a
federation of PCEs collectively satisfy a path computation request (example
1), the PCEs will have to address these issues anyway, and a PCC requesting
computations from several PCEs could use the same solution(s).

> But these are the points that Eric raised and you seem to think are not

IB>> exactly.

Cheers,
Igor