Subject: WGLC for draft-ietf-rtgwg-remote-lfa

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 4 Dec 2013 13:35:36 +0000

Hi!

After what I thought was a productive set of feedback and discussion related to this draft, both in the mailing list as well as at the meeting in Vancouver, I would like to start a Working Group Last Call.  This call will close by EOD (pick your favorite time zone) on December 19, 2013.

http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa

Please provide specific feedback as to why you support (or not) the advancement of this draft.  Please avoid "+1"-type responses.

Thanks!

Alvaro.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 4 Dec 2013 20:26:07 +0000

Hi Stewart/Alvaro,

It maybe a very late, but I wanted to point the following issue with the algorithm/psuedocode text provided in section 4.3.

      /////////////////////////////////////////////////////////////////
      //
      // Calculate extended P-space
      //
      // Note the strictly less than operator is needed to
      // avoid ECMP issues.

      Compute_Extended_P_Space(fail_intf)
          foreach node y in network
              y.in_extended_P_space = false
              // Extend P-space to the P-spaces of all reachable
              // neighbours
              foreach interface intf in self
[Pushpasis] From definition of intf.remote_node, there maybe multiple 'remote_node's for a given 'intf' (specially if the 'intf' is a LAN intf. So there should be another 'foreach intf.remote_node in intf' loop here in this algorithm text.
                  if (intf.remote_node != fail_intf.remote_node)
                      if ( D_opt(intf.remote_node, y) <
                           D_opt(intf.remote_node, self) +
                           D_opt(self,fail_intf.remote_node) +
                           D_opt(fail_intf.remote_node,y) )
                       y.in_extended_P_space = true

      /////////////////////////////////////////////////////////////////
      //
      // Compute the nodes in Q-space
      //

      Compute_Q_Space(fail_intf)
          // Compute the cost from every node the network to the
          // node normally reachable across the failed link
          Compute_and_Store_Reverse_SPF(fail_intf.remote_node)

          // Compute the cost from every node the network to self
          Compute_and_Store_Reverse_SPF(self)

          foreach node y in network
[Pushpasis] Again from definition of intf.remote_node, there maybe multiple 'remote_node's for a given 'fail_intf' (specially if the 'fail_intf' is a LAN intf. So there should be another 'foreach intf.remote_node in intf' loop here in this algorithm text. Also there is a question of which 'remote_node' will the below inequality be evaluated on in this case. This needs to be clarified.
              if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) +
                      D_opt(self,fail_intf.remote_node) )
                  y.in_Q_space = true
              else
                  y.in_Q_space = false

      /////////////////////////////////////////////////////////////////
      //
      // Compute set of nodes in both extended P-space and in Q-space

      Intersect_Extended_P_and_Q_Space()
[Pushpasis] The PQ-space is a function of the 'fail_intf'. One node maybe PQ-node for one 'fail_intf' and still not be the PQ-node for another 'fail_intf'. So the 'fail_intf' should be a input parameter for this procedure. Also the flags in_extended_P_space and in_Q_space for node y should be defined per 'fail_intf'.
          foreach node y in network
              if ( y.in_extended_P_space && y.in_Q_space )
                  y.valid_tunnel_endpoint = true
              else
                  y.valid_tunnel_endpoint = false

The current text needs to be enhanced and clarified with more details to achieve completeness in my opinion. Once again regret the late response.

Thanks
-Pushpasis

From: Alvaro Retana (aretana) [mailto:[email-masked]]
Sent: Wednesday, December 04, 2013 7:06 PM
To: [email-masked]
Cc: [email-masked]
Subject: WGLC for draft-ietf-rtgwg-remote-lfa

Hi!

Thanks!

Alvaro.

---

From: Alia Atlas <[email-masked]>
Date: Fri, 6 Dec 2013 18:03:09 -0500

I've given this draft a thorough reading (except for commenting on the
cost-based algorithm that Pushpasis already gave feedback on).

I have two major concerns.  First, I see no discussion at all about how
multipoint interfaces are handled.  Nothing indicates that they are out of
scope for protection nor does the discussion describe how to handle
avoiding the pseudo-nodes or related computation.  Second, as a
standards-track document, I see almost no description of what MUST or even
SHOULD be implemented.  What would conformance mean?

Here are my detailed comments - in going through the draft order, not by
priority.

0)Sec 2: Can you add a paragraph describing the extended-P space and
Q-space for the example in Figure 2?  It's fine to have the
definitions, but it is jarring to run into Q-space in Sec 4 without
any other reference.  For instance, just adding:

"In [Figure 1], S can reach A, B, and C without going via E; these
form S's extended P-space.  The routers that can reach E without going
through S-E will be E's Q-space; these are D and C.  B has equal-cost
paths via B-A-S-E and B-C-D-E and so may go through S-E.  The single
node in both S's P-space and E's Q-space is C; thus node C is selected
as the repair tunnel's end-point.  For more details on the reasoning
behind these calculations, please see [Sec 4.2]"

1) Sec 3, 2nd paragraph, 1 sentence:
  "A tunneled repair path tunnels traffic to some staging point in the
   network from which it is assumed that, in the absence of multiple
   failures, it will travel to its destination using normal forwarding
   without looping back."

First, can you replace "assumed" with precalculated or the like?  This
isn't an assumption - it is based on shortest-path forwarding and is
carefully determined.

Second, "in the absence of multiple failures" should be "in the
absence of a worse failure (e.g. node or SRLG) or multiple failures".

2) Sec 3.1: For clarity, could you add a sentence indicating that the
tunnel itself must also avoid going over the link S-E?

3) Sec 3.2, 2nd paragraph:  "In order for S to obtain
   the correct inner label it is necessary to establish a directed LDP
   session[RFC5036] to the tunnel end point."

Shouldn't that be a "targeted LDP session"?  I don't see directed at
all in RFC5036 and am personally only familiar with them being called
targeted LDP sessions.

4) Sec 3.2 3rd paragraph: "The performance of the encapsulation and
decapsulation is efficient as encapsulation is just a push of one
label (like conventional MPLS TE FRR) and the decapsulation occurs
naturally at the penultimate hop before the repair tunnel endpoint."

Decapsulation can occur at the penultimate hop, if the repair tunnel
endpoint so specifies.

5) Sec 3.2 3rd paragraph: "The time to establish the TLDP session and
acquire labels will limit the speed at which a new tunnel can be put
into service, but this will not be a problem in normal operation."

Can you please put some justification as to why this will not be a
problem in normal operation?  Is your assumption that the added delay
before the network is fully repaired acceptable because failure
analysis studies indicate the separation between failures is generally
at least X seconds and the time to establish a TLDP session and
exchange labels (how many) is no more than Y seconds (in a router that
is also dealing with reconvergence of all protocols beyond the IGP)?

The extra communication clearly adds some delay before protection is
available and a blanket assertion that it doesn't matter is more
marketing than engineering.

6) Given that this is a standards-track draft, is there a reason that
a minimum-to-implement tunnel type isn't specified?  I don't see/know
of any references for how a router can know if a remote router can
decapsulate IP-in-IP at speed or support GRE or even support a tLDP
session.

7) Sec 4.1: This seems to be ignoring the protection of per-prefix
LFA, which is a superset of "link LFA".  More critically, as you know,
doing per-prefix LFA can allow the protection of multi-homed prefixes.
Can you please update this section to indicate how and if remote LFA
applies to multi-homed prefixes?  As written, it sounds like it does
not.  It also sounds as if remote LFA is required even if there is a
per-prefix LFA for all destinations going via S-E.

8) Sec 4.2.1, 2nd paragraph: "We will proceed as follows: we will
describe how to compute the set of routers which can be reached from S
without traversing S-E."

For clarity, can you change this to: "how to compute the set of
routers which can be reached from S on the shortest-path tree without
traversing S-E"?  That may help remove some of the confusion when you
then define extended P-space - where clearly S can reach as well."

Please make the same change in the first sentence of 4.2.1.1.

9) Sec 4.2.1.1: First, can you explain why you remove those nodes that
are ECMP in the draft?  I assume it is because such nodes require a
directed first hop to avoid accidentally going through S-E.

Second, after describing "excising the sub-tree" - what about a quick
clue such as: "For example, if an SPF computation stores at each node
the next-hops to be used to reach that node from S, then one can
simply add a node to P-space if none of its next-hops are S-E"

10) How are multi-point interfaces handled?  I see no discussion of
that in Sec 4.2.1.1 or Sec 4.2.1.2.

11) In Sec 5, I am confused by the example and I believe it is because
there are typos?

"When a failure occurs on the link between PE1 and P2, PE1 does not
have an LFA for traffic reachable via P1.  Similarly, by symmetry, if
the link between PE2 and P1 fails, PE2 does not have an LFA for
traffic reachable via P2."

But PE2->P1 has a cost of 1000 and PE1's path to P1 isn't affected by
the failure of the link PE1-P2...  Could you please correct or clarify?

12) Sec 6: Given that [I-D.bryant-ipfrr-tunnels] is expired and not
intended for publication and this draft is heading towards RFC, is
there a reason not to accurately and fully pull out the problem
description into this draft?

13) Sec 6: The same problems can occur with SRLG failures.  Can you
please add a brief paragraph decribing how the different cases apply
for SRLG failure?  Also, please expand on the analysis recommendation.

14) Sec 7, 2nd paragraph: reference is to "Section 2" instead of
"Figure 2".

15) Sec 8: please update the "date of this draft" to be an actual date
- as the draft is revised and progresses, this would falsely imply
more recent data than will be there.

16) Sec 8: Can you please define what is meant by "protected
destinations" and "guaranteed node-protected destinations"?  Is the
first if a destination is protected from all sources against all link
failures?  Is it something more limited such as PLR/dest pairs?

17) Sec 8.4: typo - "saleability" should be "scaleability".

18) Sec 8.4:  The end of this section

"In the very few cases where P and Q spaces have an empty
intersection, one could select the closest node in the Q space and
signal an explicitly-routed RSVP TE LSP to that Q node.  A directed
LDP session is then established with the selected Q node and the rest
of the solution is identical to that described elsewhere in this
document.  Alternatively the segment routing technology being defined
in the IETF may be used to carry the traffic between non-collocated P
and Q nodes [I-D.filsfils-rtgwg-segment-routing-use-cases],
[I-D.filsfils-rtgwg-segment-routing],
[I-D.gredler-rtgwg-igp-label-advertisement]."

seems to be describing functionality that isn't fully specified or
mentioned elsewhere in the draft and that doesn't fall within RTGWG's
charter.  If we include explicit routing rather than hop-by-hop, we've
known how to do that for years.  At a minimum, it'd be useful to put
this paragraph in a section by itself that is "Potential Coverage
Improvements Via Explicit Routing" or the like.

On Wed, Dec 4, 2013 at 8:35 AM, Alvaro Retana (aretana)
<[email-masked]>wrote:

>  Hi!
>
>  After what I thought was a productive set of feedback and discussion
> related to this draft, both in the mailing list as well as at the meeting
> in Vancouver, I would like to start a Working Group Last Call.  This call
> will close by EOD (pick your favorite time zone) on December 19, 2013.
>
>  Please provide specific feedback as to why you support (or not) the
> advancement of this draft.  Please avoid "+1"-type responses.
>
>  Thanks!
>
>  Alvaro.
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>
>