The text should use "repair tunnel endpoint" instead of "PQ node" when not
specifically referring to a node identified by the cost-based RLFA algorithm in
section 4.3.
Section 3.1 describes the conditions that a node should satisfy to function as
a viable repair tunnel endpoint. In general, a node can be a valid repair
tunnel endpoint (satisfying the conditions of section 3.1) without being a
PQ-node (since the Q-space calculation is an approximation).
I propose the following changes in the text to address this:
Section 1:
"Remote LFA - The tail-end of a repair tunnel. This tail-end is a
member of both the extended-P space the Q space. It
is also termed a "PQ" node."
becomes:
"Remote LFA - The tail-end of a repair tunnel. A PQ node is always a viable
repair tunnel endpoint,
but a viable repair tunnel endpoint is not necessarily a PQ node. "
Section 3.1:
"In this document such a tunnel is termed a repair tunnel. The tail-end of
this tunnel is
called a "remote LFA" or a "PQ node".
becomes:
"In this document such a tunnel is termed a repair tunnel. The tail-end of
this tunnel is
called a "repair tunnel endpoint".
Section 3.2:
"The authors simply note that deployment in an MPLS/
LDP environment is extremely simple and straight-forward as an LDP
LSP from S to the PQ node is readily available,"
becomes:
"The authors simply note that deployment in an MPLS/
LDP environment is extremely simple and straight-forward as an LDP
LSP from S to the repair tunnel endpoint is readily available,"
"the decapsulation occurs naturally at the penultimate hop
before the PQ node."
becomes:
"the decapsulation occurs naturally at the penultimate hop
before the repair tunnel endpoint."
Section 4.2.1:
" 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". "
becomes:
" In Figure 1 the intersection of the E's Q-space with S's P-space defines a
set of
viable repair tunnel end-points, known as "PQ nodes". "
Section 6:
"1. Detect when a packet has arrived on some interface I that is also
the interface used to reach the first hop on the RLFA path to PQ,
and drop the packet. This is useful in the case of a ring
topology."
becomes:
1. Detect when a packet has arrived on some interface I that is also
the interface used to reach the first hop on the RLFA path to the
repair tunnel endpoint,
and drop the packet. This is useful in the case of a ring
topology."
And:
"2. Require that the path from PQ to destination D never passes
through E (including in the ECMP case), i.e. only use node
protecting paths in which the cost PQ to D is strictly less than
the cost PQ to E plus the cost E to D."
becomes:
"2. Require that the path from the tunnel endpoint to destination D never
passes
through E (including in the ECMP case), i.e. only use node
protecting paths in which the cost from tunnel endpoint to D is strictly
less than
the cost from tunnel endpoint to E plus the cost E to D."
Section 7 has several references to PQ where a generic reference to repair
tunnel endpoint is
more appropriate. Proposed text is shown below.
Where this technique is used in an MPLS network using LDP [RFC5036],
S will need to push two labels onto the repair packet. First it
needs to push the label used by the repair tunnel endpoint to reach the
destination, and then it needs to
push its own label for the tunnel endpoint. In the example Section 3.1
[sic], C plays the role
of the tunnel endpoint. S already has
the first hop (B) label for node C as a result of the
ordinary operation of LDP. To get the label used by C for the
destination (D), S needs to establish a targeted LDP session with C.
The label stack for normal operation and RLFA operation is shown
below in Figure 4.
To establish an targeted LDP session with a candidate tunnel endpoint node
the
repairing node (S) needs to know what IP address the tunnel endpoint is
willing to use
for targeted LDP sessions. Ideally this is provided by the tunnel endpoint
advertising this address in the IGP in use. Which address is used,
how this is advertised in the IGP, and whether this is a special IP
address or an IP address also used for some other purpose is out of
scope for this document and must be specified in an IGP specific RFC.
Note that the existing reference to "the example section 3.1" is not clear.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Stewart Bryant
Sent: Monday, October 28, 2013 2:03 PM
To: [email protected]
Subject: candidate-draft-ietf-rtgwg-remote-lfa-03.txt
I have edited draft-ietf-rtgwg-remote-lfa-03.txt, and in view of the cut-off
have put a copy here:
https://www.dropbox.com/s/kahbqvrsww40qua/candidate-draft-ietf-rtgwg-remote-lfa-03.txt
Stewart
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
