Hi JP,
Thanks for the quick progress.
Snipped everything where we have reached conclusion...
>> 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.
>
> This is explained in the text right after. Do you think that we need to add
> even more text there?
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.
>> 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).
>
> 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.
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).
>> 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 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?
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.
>> Section 14.4
>> Ha!
>> 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.
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_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
