[Pce] Remaining BRPC last call comment

["Adrian Farrel" <adrian at olddog.co.uk>]

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
Pce at ietf.org
https://www.ietf.org/mailman/listinfo/pce