Hi,
Thanks for keeping these ideas alive.
Here are some picky thoughts that you may want to include in the next
revision to make it more robust as a document. I don't have any issues with
the basic process.
Thanks,
Adrian
==
Is this I-D likely to be Informational or Standards Track? From Appendix A,
this looks like Standards Track. Can you remove Appendix A and put the
status in the usual place in the header?
==
It would be nice if the Abstract contained a pithy summary of brpc and/or
gave the motivation for the draft. For example, what is the method trying to
achieve that isn't achievable by other methods? Or, what is the fundamental
element of brpc that is not in other methods?
==
I'm assuming that section 1 is for short term information only and will be
deleted (in the next revision?)
==
Section 2. Terminology
s/ABR Router/ABR/
s/ASBR Router/ASBR/
Inter-area TE LSP: A TE LSP that crosses an IGP area.
... s/IGP area/IGP area boundary/
LSR ...please get this right!
==
Section 2
Boundary LSR
... the text seems to use 'boundary LSR', 'border node', 'boundary router'.
Can you find some consistency?
==
Section 2
I think draft-ietf-ccamp-inter-domain-framework would be a better reference
for definitions of stitching, contiguous and nesting
==
Section 3 para 3
s/proposes/defines/
==
Section 3
I think that the point about pd-path-comp is that it does not just provide a
mechanism for computing the paths, but it provides a mechanism for computing
and signaling the paths at the same time (although it could be adapted to be
just a computation technique, this is not what the pd-path-comp I-D is
describing). This is worth highlighting, because this draft is describing a
process for cooperation between PCEs in the absence of signaling (i.e. it is
truly a computation technique).
==
Section 3
Although one model consists of making the boundary
routers act as PCE,
I recommend removing this sentence. You could equally have said "although
one model consists of making every router with the lowest router ID in the
domain acting as a PCE". The sentence adds no value at this point in the
document since it is well-known that PCEs are just PCEs.
If a later example places the PCE function on the boundary routers then that
is where you should explain that it is only an example.
==
Section 3
The mechanisms proposed in this document are also applicable
to (G)MPLS TE domains other than areas and ASs.
s/proposed/defined/
I can smell an assertion! I suggest you add a section near the end of the
document to explain this statement, or remove it.
==
Section 4
Be careful to show that you mean MPLS TE, not simply TE.
==
Section 4
- No topology or resource information is distributed between domains
(as mandated per [RFC4105] and [RFC4216]), which is critical to
preserve IGP/BGP scalability and confidentiality in the case of TE
LSPs spanning multiple domains.
You should clarify what you are saying here, because many would argue that
reachability information (i.e. external routes) constitutes topology and
resource information.
But also, what has the fact that the TE LSP spans multiple domains got to do
with preserving routing protocol scalability? Probably just delete from "in
the case..." to the end of the sentence.
==
Section 4
- While certain constraints like bandwidth can be used across
different domains, certain other TE constraints like resource
affinity, color, metric, etc. as listed in [RFC2702] could be
translated at domain boundaries. If required, it is assumed that, at
the domain boundary LSRs, there will exist some sort of local mapping
based on offline policy agreement, in order to translate such
constraints across domain boundaries during the inter-PCE
communication process.
Why does the policy agreement need to be offline?
==
Section 5
No assumption is made on the actual path computation algorithm in use
by the PCE (it can be any variant of CSPF, algorithm based on linear-
programming to solve multi-constraints optimization problems and so
on).
Suggest that you delete the text in parenthesis because it is making
suggestions that border on assumptions!
==
Section 5
Some good work on clarifying things here since the previous version of the
I-D (sent to CCAMP). Thanks.
==
Section 5.1 and throughout
"BRPC path computation" seems to be tautologous
==
Section 5.1
I like the simplicity of section 5.1, but I think you need to point out that
if the sequence of domains is known a priori (can you determine it a
priori?) then the path computed might not be 'optimal' in the usual sense of
the word, but that this is OK because the ordered list of domains
constitutes an additional constraint on the computation so the resultant
path *is* optimal within the constraints applied.
==
Section 5.2
This is the second terminology section in the I-D, and there is some
duplication/overlap.
Jumping ahead of ourselves a bit, I can hear the IESG demanding that there
be only one terminology section per RFC.
==
Section 5.2
The introduction of the term Virtual Shortest Path Tree is hard to parse and
to my mind the definition is arse about tit. I think you could usefully add
some textual definition of what the VSPT is trying to achieve, before
presenting it in pictorial or abstract form.
Even more important (I think) is the fact that the tree as presented
"represents the shortest path between the destination and BR-en(j,i)..."
Frankly, we are building directional paths in exactly the oposite direction!
So the VSPT is still a tree, but it is an MP2P tree, not a P2MP tree as
described.
I suspect that this is just a textual descriptive issue rather than anything
broken in the process.
Lastly, I suggest you make it clearer that, as the tree is relayed back
along the PCE sequence, the VSPT is pruned so that it only ever (assuming no
support of node-congruent diverse paths) contains one path from and
BR-en(i,j) to the destination.
==
Section 5.2
Please be careful with the use of "BR(s)" as it looks like the notation for
a BR of domain s!
You are allowed to use "BRs" in the sense of "one or more BR"
==
Section 5.2
Note that PCE(i) would only consider BRs having connectivity with
BR(s) of domain(i-1) in the VSPT(i).
I think this can be re-written as
Note that PCE(i) only considers the entry BRs that provide
connectivity from domain(i-1). That is, the set BR-en(j,i) is
only those BRs that provide connectivity from domain (i-1) to
domain(i).
==
Section 5.2
I found your step 1 and step 2 to be accurate but very hard to parse as
steps. can you break them down into atomic actions?
For example:
Step 1
a. The PCC selects a PCE(1) to serve its computation request
b. The PCC sends the request to PCE(1)
c. PCE(1) forwards the request to PCE(2), and each PCE(n)
forwards the request to PCE(n+1). At each stage:
i. PCE(n) determines the next domain or domains to be
considered on the route. This may be achieved by
static information configured at PCE(n) or by information
encoded in the computation request, or through a combination
of the two pieces of information through the application of
policy.
ii. PCE(n) determines PCE(n+1) through the knowledge of the
next domain (domain(n+1)) and by configuration or discovery
of the PCEs that compute paths for domain(n+1). Where more
than one PCE is available for domain(n+1) PCE(n) makes the
selection using local configuration, information carried on the
path computation request, PCE capabilities, and policy.
iii. If, at any stage, PCE(n+1) cannot be determined or reached,
an error is returned to PCE(n-1) (see Section 7).
Do the same for Step 2 and the whole thing will be massively clearer.
==
Section 5.2
I suggest that you pull the note (Note: in term of computation...) out into
a separate section. It doesn't belong in the middle of section 5.2.
You will probably want to re-write the text as well since the unidirectional
limit is not necessary. Also to explain 'flood' - flood to where, and how,
and by whom? And you will want to add to pieces of information:
- the link to the I-D that defines how to do this
- a description of what happens if this process is not used.
==
Section 5.2
The paragraph that begins "BRPC guarantees to find the optimal..." is a
nascent Applicability Statement. I suggest moving this to another Section
and significantly beefing it up. You need to describe more fully:
- how ECMP works (the PCC has to request the return of more than one path)
- how diversity works (i.e. section 9 fits in here)
- how some freedom of selection of domains can be offered
- how to mix the method with other mechanisms
==
Section 6
I'm afraid that this is back on the process of providing reverse paths. Not
helpful in a TE environment where link properties may be unidirectional. The
requirements, therefore, is to supply paths from multiple entry points
towards a common destination (not the reverse).
==
Section 6
What is the VSPT object? It seems to be mentioned, but not defined.
Over time, I hope this section will be fleshed out to state exactly which
PCEP fields are used to carry what information on PCC-PCE(1) and
PCE(n)-PCE(n+1) requests, and PCE(1)-PCC, and PCE(n)-PCE(n-1) responses.
==
Section 7
If the BRPC procedure cannot be completed because a PCE along the
domain path does not support the procedure, a PCErr message is
returned by the upstream PCE with a Error-Type "BRPC procedure
completion failure". The PCErr message MUST be relayed to the
requesting PCC.
Not clear to me whether PCE(n) is supposed to know that PCE(n+1) does not
support brpc, presumably through capabilities
configuration/advertisement/negotiation, or whether PCE(n+1) is supposed to
respond to the path computation request saying that it does not support
bit-V of the RP object. If the latter, presumably the PCErr comes from
PCE(n+1) and not from PCE(n) as documented.
==
Section 7
Error-value
1: BRPC procedure not supported by one or PCEs
along the domain path
I think you want to work on this text a bit. In fact, the problem is that no
PCE that supports the brpc procedure can be found for a domain in the list
of required domains along the path.
==
Section 8
Metric normalisation is a great potential solution, but how does it fit with
AS topology confidentiality? What is the solution to providing discretion
about what TE connectivity is available within an AS, and operating brpc?
==
Section 9
As well as needing to fold this into a more general applicability section, I
would suggest throwing out the marketing text (if you need to say why this
is good, put it in the intro as part of the problem to be solved) and
introducing some description of how to achieve the function. Does it allow
domain diversity? Does it allow shared border routers?
==
Section 10
Some of this text has been seen before in this I-D
Why do you single out LSP stitching as possibly breaking end-to-end
optimality. There is functionally no difference between stitching and
nesting in this respect.
But further, your statement about stitching is pejorative! If you say that
"In the case where a domain has more than one BR-en or more than one BR-ex,
optimality after some network change within the domain can only be
guaranteed by re-executing the full brpc computation" then I would agree
with you. But as phrased, it implies that making a per-domain
re-optimisation could make the path *less* optimal. This (of course) is not
the case - per-domain optimisation will always improve or leave the same
end-to-end optimality (in the case where new resources are made available
this is obvious; in the case of a network failure, *any* path is better than
no path!)
And, lastly, the text about re-optimisation belongs in the next section, not
in this section.
==
Section 13
I would like you to discuss the issues of confidentiality of topology
information at greater length. It seems that you would possibly use this
technique in conjunction with path cookies, which is fine. But, are there
two things you cannot escape from?
- indicating which BR-en provides best connectivity
- indicating the metric for multiple BR-ens
Maybe there are some things that can be done here based on policy, including
not reporting all of the BR-ens, ranking rather than giving absolute
metrics, etc. But these would compromise optimality.
Maybe the PCE(n+1) should carefully monitor and limit (statistically and by
policy) brpc requests so that excessive information is not divulged?
==
I wouldn't mind seeing a Management Considerations section.
Do we need to be able to examine the pruned pieces of VSPT at transit PCEs?
What are the implications of reporting multiple VSPT branches in PCEP to the
MIB modules?
Is brpc support something that needs to be configured: per PCE?; per
PCE-neighbor?
What are the implications on existing protocols (IGPs? PCEP?) of using brpc?
etc.
==
I think Jean-Louis' email address needs updating
==
The document would benefit from a little care in the formatting, and you
could usefully re-read it for missing words, etc.
==
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
