On 29/10/2013 16:36, Chris Bowers wrote:
The text in section 4.2.1 and 4.2.2 describing the (unextended) P-space
calculation should be removed.
I agree with the Editor's note below in the comments for the Compute_Extended_P_Space() function in the algorithm pseudocode that the "if statement may be redundant since the foreach interface intf in self loop catches all cases." That is, calculating (unextended) P-space is not needed.
The original algorithm text was written to mirror the existing description in section 4.2.2.
" Another way to describe extended P-space is that it is the union of (
un-extended ) P-space and the set of destinations for which S has a
per-prefix LFA protecting the link S-E. i.e. the repair tunnel end
point can be reached either directly or using a per-prefix LFA."
If we are in agreement that the (unextended) P-space is not needed, then sections 4.2.1 and 4.2.2 should be rewritten to eliminate or lessen the importance of (unextended) P-space since it doesn't serve a useful purpose in the text (except to motivate why it makes sense to use extended P-space.)
I think that it is useful to talk about P space and then show how we can
extend
it in terms of enabling the reader to understand the solution.
It is not clear whether we need uP or just eP, because the forwarding
actions are different (in eP the first hop is not the normal path to
that node
that is in the FIB).
A lot of this a matter for the implementer and not a matter of protocol
correctness.
In particular, section 4.2.1 contains the following definition of a PQ-node:
"In Figure 1 the intersection of the E's Q-space with S's P-space
defines the set of viable repair tunnel end-points, known as "PQ nodes". "
This definition contradicts the definition of the PQ node in section 1.
"PQ node- A node which is a member of both the extended P-space
and the Q-space."
I have changes this to "A node which is a member of both the (extended)
P-space and the Q-space. In remote LFA this is used as the repair tunnel
endpoint."
which covers both cases.
I am happy to provide new text for sections 4.2.1 and 4.2.2 if we are in basic agreement on this.
Chris
Please look at the revised text and if you are in Vancouver, perhaps we
can talk.
- Stewart
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
