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 PROTECTED]> Reply-To: Adrian Farrel <[EMAIL PROTECTED]> Date: Mon, 24 Mar 2008 19:40:47 -0000 To: JP Vasseur <[EMAIL PROTECTED]>, <[email protected]> Subject: Re: [Pce] BRPC last call comments 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 <http://gwydir.demon.co.uk/jo/minerals/otherquartz.htm> ) JP> ;-) 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. JP> Well does not hurt ;-) I added it, thanks. >> 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). JP> If you do not like ³concatenate² no big deal, this text works. >> 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 <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). 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. >> 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. 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
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
