Subject: [Pce] BRPC last call comments

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 21 Mar 2008 20:38:25 -0000

Hi,

Here are some last call comments on draft-ietf-pce-brpc-07.txt

Running idnits (http://tools.ietf.org/tools/idnits/) yields...
  ** There is 1 instance of too long lines in the document, the longest one
     being 5 characters in excess of 72.

  == Unused Reference: 'I-D.ietf-ccamp-inter-domain-rsvp-te' is defined on
     line 675, but no explicit reference was found in the text

  == Outdated reference: A later version (-11) exists of
     draft-ietf-pce-pcep-09

  ** Downref: Normative reference to an Informational RFC: RFC 4655

  == Outdated reference: draft-ietf-ccamp-inter-domain-pd-path-comp has been
     published as RFC 5152

  == Outdated reference: draft-ietf-ccamp-inter-domain-rsvp-te has been
     published as RFC 5151

  == Outdated reference: A later version (-03) exists of
     draft-ietf-pce-manageability-requirements-02

  == Outdated reference: A later version (-02) exists of
     draft-ietf-pce-path-key-01

====
General
Replace optional plurals "(s)" with normal plural "s" for correct grammar
Please fix indentation for bullets in sections 3, 4, and 7
Please ensure that all section headings use capitals
====
Document title
Please use capitalisation as...
 A Backward Recursive PCE-based Computation (BRPC) Procedure to Compute
     Shortest Inter-Domain Traffic Engineering Label Switched Paths
====
Document title
Should the title say "Shortest Constrained" rather than "Shortest"? The 
Abstract and the body of the text refered to "constrained".
====
Abstract
s/domain is referred to as a/domain is a/
s/as IGP areas and Autonomous Systems/as an IGP area or an Autonomous 
System/
s/in order to compute/to compute/
s/paths along a/paths across a/
s/determined sequence/predetermined sequence/
s/technique while preserving/technique. This technique preserves/
====
Section 1.
The RFC Editor requires that the first section is the Introduction.
Therefore...
- Swap section 1 and section 2
- Expand all acronyms on their first use in the Introduction
  This includes "(G)MPLS"
====
Terminology section
If you choose to include terms like ABR, can you also please include the 
acronym expansion.
====
Introduction
s/establishing inter-domain/establishing an inter-domain/
====
Introduction
You say...
   the entry
   boundary node of each domain (each node in charge of computing a
   section of an inter-domain TE LSP path is always along the path of
   such TE LSP).
This implies that the BN is not able to be a PCC and use a remote PCE. I 
don't think this limit applies.
Perhaps you mean to say "each node responsible for triggering the 
computation of a section...."
====
Introduction
s/Such path computation technique/This computation technique/
====
Introduction
I think you should add to the final paragraph the usual note about common 
understanding or metrics and objective functions (or the ability to provide 
suitable mappings) between the domains.
(This is exapnded on in section 3 bullet 3, but it is fundamental to the 
brpc paradigm.
====
Section 3, bullet 1
Why do you assume that OSPF-TE or ISIS-TE are being run.
I think your assumption is that each PCE has access to an up-to-date TED, 
and you might note that the normal way to achieve this would be by running 
OSPF-TE or ISIS-TE.
====
Section 3, final bullet
s/means that are/means that is/
====
Section 4
s/solve multi-constraints/solve multi-constraint/
====
Section 4.1
In section 3, final bullet, we see...
   - The domain path (set of domains traversed to reach the destination
   domain) is either administratively pre-determined or discovered by
   some means that are outside of the scope of this document.
But here in section 4.1...
   The sequence of domains to be
   traversed can either be determined a priori or during the path
   computation procedure.
I wonder if section 4.1 is trying to provide hints of how to do domain 
selection. Perhaps you could replace 4.1 with a simple statement that BRPC 
mechanisms might also be used to determine the sequence of domains, but that 
such procedures are out of scope of this document.
====
Section 4.2
Is "Definition of VSPT(i)" intended to be a subsection?
I find that the section leaps to rapidly into the definition of the VSPT. 
Shouldn't there be some discussion first (somewhere) about the sequence of 
exchange of information between PCC and PCEs? This isn't much information, 
but seeing the VSPT(i) described as "tree returned by PCE(i) to PCE(i-1)" 
makes me wonder how the PCEs are joined together.
====
Figure 1
s/BN-en((j), i)/BN-en(j,i)/
====
Section 4.2, paragraph after Figure 1
s/the number of entry BN/the number of entry BNs/
Delete "(identified by its TE Router-ID)"? This has nothing to do with the 
definition of the abstract VSPT.
====
Section 4.2
   Note that PCE(i) only considers the entry BNs that provide
   connectivity from domain(i-1).
According to the definition of "Entry BN of domain(n)" in the terminology 
section, this text is redundant.
Perhaps you mean to say...
   Note that PCE(i) only considers the entry BNs of domain(i). That is,
   only the BNs that provide connectivity from domain (i-1).
This, however, jars with the note in Figure 1 that "j <= [X-en(i)]" since 
the implication of that note and the subsequent text in 4.2 is that the set 
of entry nodes to domain(i) (X-en(i)) is actually considered to be the set 
of all BNs to domain(i).
You need to select a some terminology and then fix the text to be 
consistent.
Note, it is fine when you say:
   Furthermore, some BNs may be excluded according to policy
   constraints (either due to local policy or policies signaled in the
   path computation request).
This does allow j <= [X-en(i)]
====
Section 4.2
   The path computation request is then relayed until reaching a PCE(n)
   such that the TE LSP destination resides in the domain(n).  At each
   step of the process, the next PCE can either be statically configured
   or dynamically discovered via IGP/BGP extensions.
You need to be clear. Is it required that the PCEP request is forwarded in 
strict sequence PCE(i-1)-->PCE(i) for all i = 2 to n, or is it OK for the 
request to simply be forwarded direct to PCE(n)?
This leads to...
   If
   multiple PCEs are discovered, the PCE may select a subset of these
   PCEs based on some local policies or heuristics.
...should be clarified as...
   If PCE(i-1)
   discovers multiple PCEs for the adjacent domain(i), PCE(i) may
   select a subset of these PCEs based on some local policies or
   heuristics.
And hidden in here is the fact that PCE(i-1) may consult multiple PCE(i)s. 
This is fine, but is not exposed anywhere else in the document. In 
particular, the process does not say "PCE(i-1) MUST/SHOULD/MAY wait until it 
has heard responses from each PCE(i) that it has consulted."
====
Section 4.2
   Step i:

   - For i=n-1 to 2: PCE(i) concatenates the topology of domain(i)
   (using its TED) with the received VSPT(i+1).

I don't like "concatenates the topology". Don't you mean...
   Step i:

   - For i=n-1 to 2: PCE(i) computes the shortest constrained paths from
     each BN-en(i) to each BN-ex(i) that is identified in VSPT(i+1). It
     then concatenates the shortest of those paths to the paths in
     VSPT(i+1) to construct VSPT(i).

Then you can delete the following...
   Then PCE(i) computes VSPT(i) (MP2P (Multi-Point to Point) tree made
   of the shortest constrained paths between each BN-en(j,i) and the TE
   LSP destination).

====
Section 4.2
Replace...
   End
...with...
   Step n
====
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.
====
Section 6
s/from an ABR/from a BN/
s/PCERep/PCRep/
====
Section 9
Since the protocol extensions presented in this document are exactly that 
(protocol extensions) you must beware of backward compatibility issues. So 
when you have...
   If the BRPC procedure cannot be completed because a PCE along the
   domain path does not support the procedure, a PCErr message MUST be
   returned to the upstream PCE with a Error-Type "BRPC procedure
   completion failure".  The PCErr message MUST be relayed to the
   requesting PCC.
...you need to be aware that for PCE(i), not supporting BRPC (i.e. not 
recognising the VSPT bit) is going to be treated according to the main PCEP 
spec, and not according to any rules in this document.
But pcep-11 says...
   Unassigned bits are considered as reserved and MUST be set to zero on
   transmission.
...from which we assume that bits not understood are ignored and MAYBE 
forwarded in the next PCReq to PCE(i+1) or MAYBE dropped.

Ouch!
Not to late to fix the PCEP spec to say that an RP object carrying an 
unrecognised bit MUST be rejected with an Error Type of "Unknown Request 
Parameter" (or would you use "Capability Not Supported"?) and an Error Code 
to indicate the bit number. (You can't give names to the error codes because 
you don't know what the bits mean!)

That would leave you with the need to modify your document here as...
   If the BRPC procedure cannot be completed because a PCE along the
   domain path recognises but does not support the procedure, it MUST
   return a PCErr message to the upstream PCE with an Error-Type "BRPC
   procedure completion failure".

Note that if you do not fix the PCEP spec, you will have to handle the case 
where the PCE receives a PCRep from its downstream neighbor containing a 
VSPT that will be incomprehensible.

See also Section 14.1
====
Section 10.1
s/Such request MUST/Such requests MUST/
s/a set of diversely routed TE LSP/a set of diversely routed TE LSPs/
====
Section 13
s/meaningful, a metric normalization/meaningful, metric normalization/
s/thanks to the METRIC/using the METRIC/
====
Section 14.2
Not mandatory, but it would be useful to highlight what this MIB module 
actually needs to track.
Is it just the configuration widget in 14.1, or is there more stuff?
====
Section 14.4
Ha!
And how will you look at these TEDs?
Have a look at 8.4 of pcep-11
====
Appendix A
I think you can remove this now
====

Cheers,
Adrian 

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

---

From: JP Vasseur <[email-masked]>
Date: Mon, 24 Mar 2008 13:30:07 -0400

Hi Adrian,

Thanks for the great review, as usual.

I skipped all editorial comments that have been addressed.

> computation of a section...."

Absolutely. The case of the BN acting as a PCC is clarified in the document
but the wording here was not appropriate. Text fixed.

> (This is exapnded on in section 3 bullet 3, but it is fundamental to the

Yes, I added a sentence + a pointer to section 13.

> and you might note that the normal way to achieve this would be by running

Right. " i.e. running OSPF-TE or ISIS-TE and RSVP-TE" has simply be removed.

>    traversed can either be determined a priori or during the path

Heu ... I do not see any contradiction here?

> such procedures are out of scope of this document.

BRPC by itself is not itself used to determine the sequence of domains but
it can indeed perform the function. But we'd rather use the same wording
here. 

S/ The sequence of domains to be traversed can either be determined a priori
or during the path computation procedure/ The sequence of domains to be
traversed is either administratively pre-determined or discovered by
some means that is outside of the scope of this document.

> makes me wonder how the PCEs are joined together.

This is explained in the text right after. Do you think that we need to add
even more text there?

> of entry nodes to domain(i) (X-en(i)) is actually considered to be the set

I don't see an issue there since the note says "j<=[X-en(i)]", which does
not imply that the set is the set of all BNs to domain(i) ?

> This does allow j <= [X-en(i)]

Right,

> request to simply be forwarded direct to PCE(n)?

It was intentional not to be specific here since both are possible.

>    select a subset of these PCEs based on some local policies or

OK

> has heard responses from each PCE(i) that it has consulted."

It is implementation specific.

>    of the shortest constrained paths between each BN-en(j,i) and the TE

Not really since this is a different way to compute the path. We used to
terminology "concatenates" since for example PCE1 may not compute the
shortest paths from BN-en(1) to each BN-ex(1). It could indeed concatenate
VPST(2) with its TED and compute the path in one pass in the case of an ABR.

> the procedures. If it can't be done, we need protocol extensions.

We make the assumption that the sequence of domains is predetermined 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?

>    procedure completion failure".

Very good point. The proposed text has been added.

And indeed, we need to update the PCEP spec with:

Section 7.4: An RP object carrying an unrecognised bit MUST be rejected with
an Error Type of "Unknown Request Parameter.

Could be:
A new Error-Type
Or
10         Reception of an invalid object
               Error-value=1: reception of an object with P flag not set
               although the P-flag must be set according to this
               specification.

With a new Error-value.

> And how will you look at these TEDs?

It of course depends on how these TEDs are populated but this is in any case
the only way to verify correct operation.

> Have a look at 8.4 of pcep-11

Thanks.

JP.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 24 Mar 2008 19:40:47 -0000

Hi JP,

Thanks for the quick progress.

Snipped everything where we have reached conclusion...

> This is explained in the text right after. Do you think that we need to add

Well, I don't think it is crystal clear. Or rather, it *is* crystal clear, but the crystal is smokey quartz (http://gwydir.demon.co.uk/jo/minerals/otherquartz.htm)

How about a simple paragraph about the basic operation of BRPC such as...

The BRPC procedure relies on communication between cooperating PCEs. In particular, the PCC sends a PCReq to a PCE in its domain. The request is forwarded between PCEs, domain-by-domain until the PCE responsible for the domain containing the LSP destination is reached. The PCE in the destination domain creates a tree of potential paths to the destination (the Virtual Shortest Path Tree - VSPT) and passes this back to the previous PCE in a PCRep. Each PCE in turn adds to the VSPT and passes it back until the PCE in the source domain uses the VSPT to select an end-to-end path that it sends to the PCC.

> VPST(2) with its TED and compute the path in one pass in the case of an ABR.

OK.
The problem is with the "concatenate."

How about...

    Step i:
 
    - For i=n-1 to 2: PCE(i) computes VSPT(i), the tree made
      of the shortest constrained paths between each BN-en(j,i)
      and the TE LSP destination. It does this by considering
      its own TED and the information in VSPT(i+1).

> could include the PCE-ID object definition in BRPC and add some text here.

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).

But how does PCE(i) know that the next domain is domain(i+1)? How is the a priori knowledge passed to PCE(i)?

This isimportant, because knowing the sequence of PCEs is not enough to know the sequence of domains. A PCE may serve more than one domain.

> the only way to verify correct operation.
 
In section 8.4 of pcep-11 we took a completely different meaning of "correct operation" because we recognised that we are interested in the correct operation of the protocol, not the correct operation of the computation algorithm.

You should do the same here.

I think the only thing to add to the PCEP spec will be the trail of PCEs as discussed in the monitoring I-D.

A

---

From: JP Vasseur <[email-masked]>
Date: Mon, 31 Mar 2008 10:46:59 -0400

Hi,

Sorry for the one week interruption in the thread ... Back to addressing the
last comments, then I¹ll post the new revision.

See in line.

From: Adrian Farrel <[email-masked]>
Reply-To: Adrian Farrel <[email-masked]>
Date: Mon, 24 Mar 2008 19:40:47 -0000
To: JP Vasseur <[email-masked]>, <[email-masked]>
Subject: Re: [Pce] BRPC last call comments

Hi JP,

 
> This is explained in the text right after. Do you think that we need to add
Well, I don't think it is crystal clear. Or rather, it *is* crystal clear,
but the crystal is smokey quartz
(http://gwydir.demon.co.uk/jo/minerals/otherquartz.htm
<http://gwydir.demon.co.uk/jo/minerals/otherquartz.htm> )

JP> ;-)

The BRPC procedure relies on communication between cooperating PCEs. In
particular, the PCC sends a PCReq to a PCE in its domain. The request is
forwarded between PCEs, domain-by-domain until the PCE responsible for the
domain containing the LSP destination is reached. The PCE in the destination
domain creates a tree of potential paths to the destination (the Virtual
Shortest Path Tree - VSPT) and passes this back to the previous PCE in a
PCRep. Each PCE in turn adds to the VSPT and passes it back until the PCE in
the source domain uses the VSPT to select an end-to-end path that it sends
to the PCC.
 
JP> Well does not hurt ;-) I added it, thanks.

OK.
 
How about...
 
    Step i:

JP> If you do not like ³concatenate² no big deal, this text works.
 
> http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-01.txt
<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.
Well, I have no problems with "the sequence of domains is known a priori."
In fact, I strongly support it.

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).

JP> 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)?
 
JP> 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 isimportant, because knowing the sequence of PCEs is not enough to know
the sequence of domains. A PCE may serve more than one domain.
 
> the only way to verify correct operation.
 
In section 8.4 of pcep-11 we took a completely different meaning of "correct
operation" because we recognised that we are interested in the correct
operation of the protocol, not the correct operation of the computation
algorithm.

JP> Ah I see what you mean now. Sure that makes sense.

OLD:
Verifying the correct operation of BRPC can be done by looking at the TEDs
related to the various domains traversed by a TE LSP at the time the BRPC
procedure was invoked and verify that the path computed by the BRPC
procedure is the expected optimal inter-domain constrained path (the path
that would be obtained in the absence of multiple domains).

NEW:
Verifying the correct operation of BRPC can be performed by monitoring a set
of parameters. A BRPC implementation SHOULD provide the following
parameters: 
o Number of successful BRPC Procedure completions on a per PCE peer basis,
o Number of BRPC procedure completion failures because the VSPT flag was not
recognized (on a per PCE peer basis),
o Number of BRPC procedure completetion failures because the BRPC procedure
was not supported (on a per PCE peer basis),
 
I think the only thing to add to the PCEP spec will be the trail of PCEs as
discussed in the monitoring I-D.

JP> I guess that it will come with the monitoring ID.

Cheers,

JP.

A

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 31 Mar 2008 21:56:13 +0100

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.
>>> predetermined or discovery by some means. Do you want us to
>>> explicitly add this assumption?
>>>
>>> 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
>>> We could include the PCE-ID object definition in BRPC and add
>>> some text here.
>>> Thoughts?
>>
>> 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).
>> 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.

---

From: Meral Shirazipour <[email-masked]>
Date: Mon, 31 Mar 2008 17:45:47 -0400

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

---

From: "Peng He" <[email-masked]>
Date: Mon, 31 Mar 2008 18:35:10 -0400

I agree with Adrian, the domain-sequence should be indicated
explicitly and kept consistency when passing through.

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.

>  domain(s) to exclude in the sequence of domains (for diversity or political

If  the domain-sequence is decided by all means, then it might already
exclude the unwanted domain(s) I guess.

Regards,
Peng

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'
>  "best next domain" to traverse next.
>

---

From: Meral Shirazipour <[email-masked]>
Date: Mon, 31 Mar 2008 23:56:50 -0400

Hi,
   Please see inline...

> 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.

> it might be 'local optimality' in most times as Adrian's example
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.

> 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.

Regards,
Meral

---

From: "Peng He" <[email-masked]>
Date: Tue, 1 Apr 2008 09:15:48 -0400

Please see inline...

>  Some PCCs might not even have the capability to come up with such a domain

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".

>  the domains/PCEs they want to avoid.

Similar example could be: they might want to include (not exclude)
some domains for some reasons. 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),
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. And it is not a must for PCCs to know this also.

Regards,
Peng

---

From: Meral Shirazipour <[email-masked]>
Date: Tue, 01 Apr 2008 11:27:48 -0400

Hi,
   I see your point but please see counterarguments inline...

> 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.
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! 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.

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.

> 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.

>I believe such domain-level decision

Why opt for non optimal when PCEs deciding of the next domain could end up with
a 'more' optimal path ?

> 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.

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.

Regards,
Meral

> >  > >  > >> Well, I have no problems with "the sequence of domains is known
> a
> >  > >  > >> priori." In fact, I strongly support it.
> >  > >  > >>
> >  > >  > Let's assume that there are five PCEs. PCE-A, PCE-B, PCE-C and
> PCE-D
> >  > have
> >  > >  > obvious scope.
> >  > >  > 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
> >  > >  > In the former case, we need a way for the PCC to pass that
> information
> >  > to
> >  > >  > Let's suppose that PCE-A now knows the series of domains, ABD. Let
> us
> >  > assume
> >  > >  > 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
> >  > >  > 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
> >  > >  > request? Note that the sequence of PCEs PCE-A, PCE-E, PCE-D does
> not
> >  > help