SB> I changed the definition of remote LFA to

SB> The use of a PQ node rather than a neighbour of the repairing node as the next hop in an LFA repair.

SB> Which I think is more correct than the existing definition of the term.

SB> I have also changed the definition of PQ to

SB> 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.

SB> I also changed the text in 3.1 for consistency to
"In this document such a tunnel is termed a repair tunnel. The tail-end of this tunnel (the repair tunnel endpoint) is a "PQ node" and the repair mechanism is a “remote LFA”."



On 29/10/2013 15:38, Chris Bowers wrote:
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. "
SB> I think that we were wrong to call a remote LFA a node, remote LFA is surely
SB> a method.



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". "

SB> I think that the original is correct, since it is the set. Isn't it?

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.
SB> I have inspected all instances of PQ and used some combination of
SB> remote LFA repair target, PQ and remote LFA repair target (PQ) as
SB> seemed appropriate

- Stewart


-----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



.



--
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to