Subject: Re: [Pce] Remaining BRPC last call comment

From: "Peng He" <[email-masked]>
Date: Tue, 1 Apr 2008 13:13:56 -0400

Interesting discussion, please see inline...

On Tue, Apr 1, 2008 at 11:27 AM, Meral Shirazipour
<[email-masked]> wrote:
> Hi,
>    I see your point but please see counterarguments inline...
>
>
>  > Please see inline...
>  >
>  > On Mon, Mar 31, 2008 at 11:56 PM, Meral Shirazipour
>  > <[email-masked]> wrote:
>  > > Hi,
>  > >    Please see inline...
>  > >
>  > >
>  > >  > I agree with Adrian, the domain-sequence should be indicated
>  > >  > explicitly and kept consistency when passing through.
>  > >
>  > >  Again, I believe this is a plus but not a must.
>  > >  Some PCCs might not even have the capability to come up with such a domain
>  > >  sequence information.
>  > >
>  > >
>  >
>  > Well, it is not a must that PCCs know the domain sequence, but I think
>  > it is a must that somebody (e.g, either PCCs or PCEs) know it clearly
>  > and follow it during the process of path computation. I strongly
>  > support '"the series of domains is known a priori" means that it is
>  > known before path computation starts.', which is actually one of the
>  > very basic assumption of PCE architecture. Based on this assumption,
>  > PCE architecture is able to compute optimal inter-domain (area or AS)
>  > path. It should not be the task for PCEs to decide which (next) domain
>  > to go freely although sometime it might see the next domain is the
>  > best from its viewpoint.
>  >
>  > Since given a domain sequence, there might be several PCE sequences
>  > matched (different combinations), it is a one-to-many matching, I
>  > agree with Adrian that  "PCEP needs to be able to indicate the
>  > sequence of domains that should be traversed".
>
>  If the idea is just to add this functionality into PCEP and enable it to
>  communicate the complete domain sequence, I approve.

Ok.

>  However I completely disapprove that all path computation should provide this
>  information 'apriori'... This would imply that some entity (PCE or other) is
>  capable of coming up with this optimal? domain sequence... This in turn implies
>  that this entity has a global view of the network!

Yes and maybe.

> From my understanding, the
>  non-existence of such entity was the whole purpose of coming up with the PCE
>  architecture which would mainly function in a distributed fashion.
>

Yes.

>  By coming up with such a constraint on all path computations (constraint of
>  knowing the domain sequence), we will then have to come up with the details of
>  such entity, and I am afraid that to be functional this entity will have to
>  anyways implement many of the existing functionalities of the existing PCE
>  work.
>
>

That's why most PCE drafts didn't talk about this 'entity' and claimed
"it is out of the scope of this document" now.

>
>  > >  > But I don't understand "each PCE along the path would decide of the
>  > >  > "best next domain" to traverse next" , I suppose the domain-sequence
>  > >  > is kind of 'global optimality' by all means; then how does a PCE
>  > >  > decide  the 'best next domain', how do you define the term 'best', and
>  > >  > it might be 'local optimality' in most times as Adrian's example
>  > >  > indicates.
>  > >  Of course the term "best" would be of local significance, if the PCE
>  > making the
>  > >  decision does not have a global end to end view.
>  > >
>  > >
>  > >  > >   On the other hand, I think it remains crucial to be able to indicate
>  > the
>  > >  > >  domain(s) to exclude in the sequence of domains (for diversity or
>  > >  > political
>  > >  > >  reasons).
>  > >  >
>  > >  > If  the domain-sequence is decided by all means, then it might already
>  > >  > exclude the unwanted domain(s) I guess.
>  > >
>  > >  Again  I don't agree here. Not all PCCs will be able to come up with the
>  > domain
>  > >  sequence information. However, and mostly for diversity reasons, they will
>  > know
>  > >  the domains/PCEs they want to avoid.
>  >
>  > Similar example could be: they might want to include (not exclude)
>  > some domains for some reasons.
>
>  Then we could just add to PCEP enough to be able to signal domains to exclude
>  and/or to exclude from the path. That should solve the problem.

Yes :)

>
>
>  >I believe such domain-level decision
>  > should be decided by 'something' that is outside of PCE architecture.
>  > This 'something' provides the domain sequence (might not be optimal),
>
>  Why opt for non optimal when PCEs deciding of the next domain could end up with
>  a 'more' optimal path ?
>
>

If you don't have a global view, you can not claim any "more" optimal
path just by local computation in general; it might be less optimal
from the global view.

Currently, the optimality of PCE architecture is based on giving an
exact domain sequence passing through. If no such domain sequence
given, the optimality of the computation results by PCE architecture
can not be guaranteed.

Of course it is expected that a globally-distributed optimization
process can be deployed in PCE-based architecture, in which no global
view maintained, no domain sequence given before each path
computation, only limited-and-non-confidential domain-specified info
is exchanged among these various distributed sub-process. However, no
such process being found yet, even in some theoretical work (e.g.,
using Nash bargaining and decomposition).

>  > then PCEs can compute optimal path following this domain sequence.
>  > PCEs should not have the right/capability to decide which domain(s) to
>  > go currently.
>
>  By removing this right from PCEs we will somehow partly force the local path
>  computation in the PCE's domain. Maybe not a problem...
>
>
>  >And it is not a must for PCCs to know this also.
>
>  If it is not the PCC nor the PCE, then another entity has to be described for
>  this task, and this is just redundant work for no real reason.
>

PCCs and PCEs should not have the right to decide the domain-level
path, at least for now. However, if a global-distributed-optimization
process I described above is found, there might be some changes.

>  Again I agree that it would be 'nice' to add this feature to PCEP, but I
>  completely disagree that it should be 'mandatory' for all path computations.
>  Making it mandatory would even go against the global/distributed vision the PCE
>  architectures has given to interested parties since it beginnings in 2004-2005.

There is no any limitation on any research work on this topic.
'mandatory' applied to current practical status I guess.

Regards,
Peng

>
>  > Regards,
>  > Peng
>
>  Regards,
>  Meral
>
>
>
>
>  > >
>  > >  > Regards,
>  > >  > Peng
>  > >  >
>  > >
>  > >  Regards,
>  > >  Meral
>  > >
>  > >
>  > >
>  > >
>  > >  > On Mon, Mar 31, 2008 at 5:45 PM, Meral Shirazipour
>  > >  > <[email-masked]> wrote:
>  > >  > > Hi Adrian,
>  > >  > >   I do not disagree with you that it would be a plus to be able to
>  > >  > 'sometimes'
>  > >  > >  indicate the sequence of domains we want the path to go through;
>  > however I
>  > >  > >  understood that in most cases, each PCE along the path would decide
>  > of the
>  > >  > >  "best next domain" to traverse next.
>  > >  > >
>  > >  > >   On the other hand, I think it remains crucial to be able to indicate
>  > the
>  > >  > >  domain(s) to exclude in the sequence of domains (for diversity or
>  > >  > political
>  > >  > >  reasons).
>  > >  > >
>  > >  > >  Regards,
>  > >  > >  Meral
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >  Selon Adrian Farrel <[email-masked]>:
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >  > Hi JP,
>  > >  > >  > Thanks for convergence.
>  > >  > >  >
>  > >  > >  > There is just one remaining issue for discussion.
>  > >  > >  > I've reproduced the thread here, but all the discussion is at the
>  > end.
>  > >  > >  >
>  > >  > >  > Cheers,
>  > >  > >  > Adrian
>  > >  > >  >
>  > >  > >  > >>>> Section 5
>  > >  > >  > >>>>
>  > >  > >  > >>>> Is it assumed that PCE(i) knows which domain the requesting
>  > >  > >  > >>>> PCE(i-1) represents?
>  > >  > >  > >>>> The reverse is obviously true because PCE(i-1) must select
>  > >  > >  > >>>> PCE(i) on this basis, but it seems to me that the PCReq could
>  > >  > >  > >>>> useful identify the neighboring (upstream) domain. This would
>  > >  > >  > >>>> be particularly useful in the case of a requesting PCE that
>  > >  > >  > >>>> represents multiple domains since it will allow PCE(i) to know
>  > >  > >  > >>>> which are the BN-en(i) nodes.
>  > >  > >  > >>>>
>  > >  > >  > >>>> Conversely, if PCE(i) has computation capabilities for
>  > multiple
>  > >  > >  > >>>> domains, it will need to be told which for domain(i) it should
>  > act.
>  > >  > >  > >>>> So we either need protocol extensions (requesting domain,
>  > >  > >  > >>>> computation domain) or we need to be told how to use existing
>  > >  > >  > >>>> protocol fields for this purpose.
>  > >  > >  > >>>>
>  > >  > >  > >>>> Furthermore :-( how although the sequence of domains is known
>  > >  > >  > >>>> (a priori) by the PCC, we need some way to convey the sequence
>  > >  > >  > >>>> in the PCReq so that PCE(i) knows that the next domain in the
>  > >  > >  > >>>> sequence is domain(i+1).
>  > >  > >  > >>>> If this can be achieved by existing protocol mechanism, you
>  > need
>  > >  > >  > >>>> to describe the procedures. If it can't be done, we need
>  > protocol
>  > >  > >  > >>>> extensions.
>  > >  > >  > >>>
>  > >  > >  > >>> We make the assumption that the sequence of domains is pre-
>  > >  > >  > >>> determined or discovered by some means that is outside of the
>  > >  > >  > >>> scope of this document.
>  > >  > >  > >>> You're right that we do not say that the sequence of PCE is
>  > also
>  > >  > >  > >>> predetermined or discovery by some means. Do you want us to
>  > >  > >  > >>> explicitly add this assumption?
>  > >  > >  > >>>
>  > >  > >  > >>> Consider the two following cases:
>  > >  > >  > >>> 1) Inter-area: obvious
>  > >  > >  > >>> 2) Inter-AS: if the sequences of domain and related PCEs are
>  > known,
>  > >  > >  > >>> there is no need for protocol extensions except if we want to
>  > >  > enforce
>  > >  > >  > >>> the sequence of PCEs, which can be done thanks to the PCE-ID
>  > >  > >  > >>> object defined in
>  > >  > >  > >>>
>  > http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-01.txt
>  > >  > >  > >>> We could include the PCE-ID object definition in BRPC and add
>  > >  > >  > >>> some text here.
>  > >  > >  > >>> Thoughts?
>  > >  > >  > >>
>  > >  > >  > >> Well, I have no problems with "the sequence of domains is known
>  > a
>  > >  > >  > >> priori." In fact, I strongly support it.
>  > >  > >  > >>
>  > >  > >  > >> However, to whom is this sequence known?
>  > >  > >  > >>
>  > >  > >  > >> Yes, if the ingress PCC or PCE knows the PCEs responsible for
>  > each
>  > >  > >  > >> domain, then it could provide a list of such PCEs. But this is
>  > more
>  > >  > >  > >> information than is implied in "the sequence of domains". My
>  > >  > assumption
>  > >  > >  > >> is that the default position is that PCE(i) will select
>  > PCE(i+1).
>  > >  > >  > >
>  > >  > >  > > This is what we referred to as ³discovered by some means² indeed.
>  > >  > >  > >
>  > >  > >  > >> But how does PCE(i) know that the next domain is domain(i+1)?
>  > How
>  > >  > >  > >> is the a priori knowledge passed to PCE(i)?
>  > >  > >  > >
>  > >  > >  > > By some means out of the scope of the document.
>  > >  > >  > > Example: inter-area + PCE on the ABR + PCE discovery
>  > >  > >  > > (RFC 5088/5089).
>  > >  > >  > > There are other mechanisms available but out of the scope of this
>  > >  > >  > > document.
>  > >  > >  > >
>  > >  > >  > >> This is important, because knowing the sequence of PCEs is not
>  > enough
>  > >  > >  > >> to know the sequence of domains. A PCE may serve more than one
>  > >  > >  > >> domain.
>  > >  > >  >
>  > >  > >  > OK
>  > >  > >  > The difference in our view point is, I think, what we mean by "the
>  > >  > series of
>  > >  > >  > domains is known a priori." Let's use ASes as the example, because
>  > it is
>  > >  > >  > slightly more complex.
>  > >  > >  > Here comes some ASCII Art (TM)
>  > >  > >  >
>  > >  > >  > <ascii-art>
>  > >  > >  >                 ---------
>  > >  > >  >                | AS-B    |
>  > >  > >  >  ---------     |         |     ---------
>  > >  > >  > | AS-A    |----|         |----| AS-D    |
>  > >  > >  > |         |    |         |    |         |
>  > >  > >  > |   PCC   |----|         |----|  Egress |
>  > >  > >  > |         |     ---------     |         |
>  > >  > >  > |         |       |   |       |         |
>  > >  > >  > |         |     ---------     |         |
>  > >  > >  > |         |----| AS-C    |----|         |
>  > >  > >  > |         |    |         |    |         |
>  > >  > >  > |         |----|         |----|         |
>  > >  > >  >  ---------     |         |     ---------
>  > >  > >  >                |         |
>  > >  > >  >                 ---------
>  > >  > >  > </ascii-art>
>  > >  > >  > Here we have 4 ASes and we want to get from the PCC to the Egress.
>  > >  > >  > The ASes are interconnected as shown.
>  > >  > >  > Let's assume that there are five PCEs. PCE-A, PCE-B, PCE-C and
>  > PCE-D
>  > >  > have
>  > >  > >  > obvious scope.
>  > >  > >  > PCE-E is special, it is capable of computing paths in AS-B and
>  > AS-C.
>  > >  > >  >
>  > >  > >  > So, in my book, "the series of domains is known a priori" means
>  > that it
>  > >  > is
>  > >  > >  > known before path computation starts. That means, either the PCC
>  > knows
>  > >  > the
>  > >  > >  > series of ASes (say, ABD) or the sequence is known by PCE-A.
>  > >  > >  >
>  > >  > >  > In the former case, we need a way for the PCC to pass that
>  > information
>  > >  > to
>  > >  > >  > PCE-A. Note that this is not a sequence of PCEs. It is a sequence
>  > of
>  > >  > >  > domains.
>  > >  > >  >
>  > >  > >  > Let's suppose that PCE-A now knows the series of domains, ABD. Let
>  > us
>  > >  > assume
>  > >  > >  > that it selects PCE-B as the next PCE in the series. How does it
>  > >  > communicate
>  > >  > >  > to PCE-B that the series of domains is ABD and not ABCD? One
>  > possible
>  > >  > way to
>  > >  > >  > do this, would be to signal the series of PCEs (PCE-A, PCE-B,
>  > PCE-D).
>  > >  > But
>  > >  > >  > that has some implication of a one-to-one relationship between PCEs
>  > and
>  > >  > >  > domains.
>  > >  > >  >
>  > >  > >  > So suppose PCE-A selects PCE-E as the next PCE in the series. How
>  > does
>  > >  > PCE-E
>  > >  > >  > know the pre-determined series of domains? How does it know that it
>  > has
>  > >  > been
>  > >  > >  > asked to find a path across AS-B and not AS-C? Do we suppose that
>  > this a
>  > >  > >  > priori knowledge permeates the ether? Or is it passed along with
>  > the
>  > >  > >  > request? Note that the sequence of PCEs PCE-A, PCE-E, PCE-D does
>  > not
>  > >  > help
>  > >  > >  > because we could still select a path through domains ABCD.
>  > >  > >  >
>  > >  > >  > So, I think that PCEP needs to be able to indicate the sequence of
>  > >  > domains
>  > >  > >  > that should be traversed. The additional ability to indicate the
>  > >  > sequence of
>  > >  > >  > PCEs is a great supplement.
>  > >  > >  >
>  > >  > >  >
>  > >  > >  > _______________________________________________
>  > >  > >  > Pce mailing list
>  > >  > >  > [email-masked]
>  > >  > >  > https://www.ietf.org/mailman/listinfo/pce
>  > >  > >  >
>  > >  > >  >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >  _______________________________________________
>  > >  > >  Pce mailing list
>  > >  > >  [email-masked]
>  > >  > >  https://www.ietf.org/mailman/listinfo/pce
>  > >  > >
>  > >  >
>  > >  >
>  > >
>  > >
>  > >
>  > >
>  >
>  >
>
>
>
>
_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: Meral Shirazipour <[email-masked]>
Date: Tue, 01 Apr 2008 15:00:00 -0400

Hi,
  Very interesting indeed… If I sum up all this, you are saying that we should
make ‘mandatory’ that the initiating domain specifies the complete domain
sequence.
I am arguing that this should be possible but not ‘mandatory’.

My arguments among others are for instance:
1- Not all initiating domains can come up with this information
2- Some initiating domains might actually want to rely on the PCE architecture
to choose the best sequence of domains (by maybe just including the info on
domains to include/exclude)
3- Having the PCE’s choose the next domain could end up being the optimal
solution or at least the best possible solution as each domain/PCE has more
information on its neighboring domains than the entity in the initialing domain
would have on the entire PCE/domains in the sequence.

And if we argue that such entity would have a global view of the domains and
could indeed come up with an optimal sequence, then why not have this entity
calculate the whole path and forget about the PCE architecture!
Since such entity cannot exist (according to the whole discussions resulting in
the PCE architecture), I do not see why we should force such practice if having
the PCEs choose the next domain in sequence does not necessarily give any worse
performance.

As for all drafts considering the topic of finding the PCE sequence as out of
scope, I do not believe that they were insinuating that a separate 'entity'
would do this job.
I actually see this as they are leaving this decision for a maybe later
deployment issue, where one could decide to
a- rely on PCEs in the PCE architecture to choose the next domain
<<OR>>
b- rely on an external entity (or any other means) to come up with the complete
or partial domain sequence to be signaled with the path computation.

That being said, again I agree that the PCEP should be able to carry domain
information in different forms: e.g. 1-the complete domain/PCE sequence 
2-domains to include  3-domains to exclude.

Regards,
Meral

---

From: JP Vasseur <[email-masked]>
Date: Tue, 01 Apr 2008 16:12:34 -0400

Hi Adrian,

[snip]

> 
> So, I think that PCEP needs to be able to indicate the sequence of domains
> that should be traversed.

The easy way to handle this is by using the IRO object specified in PCEP. I
can add: 

"The sequence of domains to be traversed MAY be encoded in the IRO so that
it is available to all PCEs."

The additional ability to indicate the sequence of
> PCEs is a great supplement.

Which can be done thanks to the PCE-ID object defined in
draft-ietf-pce-monitoring.

Thanks.

Cheers.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 01 Apr 2008 16:21:08 -0400

Hi,

> From: Meral Shirazipour <[email-masked]>
> Date: Tue, 01 Apr 2008 11:27:48 -0400
> To: Peng He <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [Pce] Remaining BRPC last call comment
> 
> Hi,
> that this entity has a global view of the network! From my understanding, the

Absolutely.

> and/or to exclude from the path. That should solve the problem.

See my reply ... The ability to include some domains is already in PCEP. And
the ability to exclude domain is in
http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-xro-05.txt

> completely disagree that it should be 'mandatory' for all path computations.

For sure and this is what BRPC says already.

Thanks.

JP.

---

From: Mach Chen <[email-masked]>
Date: Mon, 07 Apr 2008 09:47:51 +0800

Hi JP and Adrian,

>it is available to all PCEs."

As Adrian pointed out:"A PCE may serve more than one domain." , and I am not sure whether there are multiple PCEes may serve one domain(for HA or load balance reason). If my assumption is reasonable, I am afriad just using the IRO is not the best idea. Becasue, just based on the IRO, for a specific PCE, how does it accurately know which domain(s) it should serve? 
For example:there are three domains(d1,d2,d3) and three PCEs(PCE1,PCE2,PCE3), PCE1 serves d1, PCE2 could serve d2 and d3, and PCE3 also could serve d2 and d3, for such condition, how does BRPC work? 

>draft-ietf-pce-monitoring.

Best regards,			
Mach Chen

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 7 Apr 2008 12:39:15 +0100

Hi Mach,

>>> So, I think that PCEP needs to be able to indicate
>>> the sequence of domains that should be traversed.
>>
>> The easy way to handle this is by using the IRO
>> object specified in PCEP. I can add:
>>
>> "The sequence of domains to be traversed MAY be
>>  encoded in the IRO so that it is available to all
>> PCEs."
>
> As Adrian pointed out:"A PCE may serve more than one
> domain." , and I am not sure whether there are multiple
> PCEes may serve one domain (for HA or load balance reason).

Absolutely. A domain may have multiple PCEs (for example, one at each domain 
border router).

> If my assumption is reasonable, I am afriad just using the
> IRO is not the best idea. Becasue, just based on the IRO,
> for a specific PCE, how does it accurately know which
> domain(s) it should serve?
> For example:there are three domains(d1,d2,d3) and three PCEs
> (PCE1,PCE2,PCE3), PCE1 serves d1, PCE2 could serve d2 and d3,
> and PCE3 also could serve d2 and d3, for such condition, how
> does BRPC work?

There are two questions to be answered by a PCE:
- which is the previous/next domain in the path?
- which is the next PCE to talk to?

We now have mechanisms to convey both pieces of information as follows:
- Use the IRO to include a list of domain identifiers
  to indicate the sequence of domains to be traversed.
  In your example, the PCReq from the original PCC (or
  maybe from the first PCE) would have an IRO showing
  the domain sequence d1, d2, d3
- Use the list of PCE-ID objects as described in
  draft-ietf-pce-monitoring-01.txt. In your example the
  sequence might be PCE1, PCE3.

The inclusion of these pieces of information would be optional. Failure to 
include sufficient information to enable path computation will (obviously) 
result in a failure.

In the BRPC case you mention, the IRO would need to be propagated from the 
source PCE to the final PCE as the PCReq is forwarded. The sequence of PCEs 
through which the PCReq is forwarded, can be determined either from the IRO 
or from the PCE-ID objects.

Hope this helps,
Adrian