Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)
draft-ietf-rtgwg-remote-lfa-11

[Ballot comment]
Throughout the doc there is a word we see.
The queen would be so proud of what we write.
For we are so amused by this strange use,
it is some sixteen times "we" does appear.
Perhaps we'd like the passive voice instead.

[Ballot comment]

- 3.2 1st para: I'm sure that IPsec would have
downsides (possibly fatal) as a tunneling mechanism,
but OTOH, it might also have some benefits if the
endpoints are in the same domain but not all
non-endpoints traversed by the tunnel are.  That's
probably too much of a change to include unless you
really wanted to, but I thought I'd just ask in case.

- 4.3 - this is probably insignificant but is there a
potential DoS if I can try force a node to run this (or
an equivalent) algorithm frequently?

- I agree with Adrian's points about the security
considerations. One question on that (I only skimmed
this, sorry) - Adrian said: "You can add a note about
what traffic can be placed into a repair tunnel. You
already have this earlier in the document, and it is
worth restating." Which text is that? Is there a
requirement somewhere that the new tunnel described
here SHOULD have the same security properties as the
link(s) for which it's a backup?

[Ballot comment]
Thanks for your work on this draft.

I support Adrian's comments on additions/changes for the security considerations section and would like to see them added.

Additionally, Adrian raised the point of having the introduction first.  As someone outside of routing, I think this would make the draft easier to read. 

The terminology section should state that it is using figure 1 in each of the definitions.  When the order is changed so this section follows the introduction, that may be more clear, but a statement to that effect would be helpful IMO.

[Ballot comment]
Stewart and Mike have been diligent in discussing my concerns and
updating the document (specifically the definitions) to produce a
version that lets me clear my Discuss. They also picked up some of my
Comments along the way so I have pruned them from this page. There are
still a number of Comments I'd love them to address, but none of these
is blocking.

===

Although it causes some pain with abbreviations and a little more care
in explanation, you need to put the Introduction as the first section in
the document. The RFC editor will insist on this, so it is better if you
do it now and get the wording exactly how you would like it.

---

You are using RFC 5714 as a Normative Reference by making me go there
for the definition of terms. Please move it to the correct section.

---

IMHO your definition of FIB is rather loose.  Fortunately (?) "FIB" is
barely used in this document, so it might not be important, but if you
wanted to fix it:
- you are talking about IP packets in this document
- the actions are, I think, limited to forwarding actions

---

Throughout the text, the terms P-space, Q-space, and extended P-space
are used rather loosely. For example, when discussing Figure 1 you say
"S's extended P-space", but this is really "S's extended P-space with
respect to S-E". Someone familiar with the work might say that it is
obvious from the context that we are discussing the link S-E, and it is,
but the terminology needs to be tight.

---

Section 2

  B
  has equal-cost paths via B-A-S-E and B-C-D-E and so may go through
  S-E.

I don't think B is going anywhere. Maybe...

  B
  has equal-cost paths to E via B-A-S-E and B-C-D-E and so may reach E
  through S-E.

---

Section 2

  In MPLS networks the targeted LDP
  protocol needed to learn the label binding at the repair tunnel
  endpoint is a well understood and widely deployed technology.

But it would still benefit from a citation or a forward reference to
section 7.

---

I enjoyed 3.2

  relatively rare as is the incidence of failure in a well managed
  network.

So, managing my network well is protection against back-hoes. Nice.

---

In 3.2

  Multiple
  repairs MAY share a tunnel end point.

1. s/repairs/repair tunnels/
2. s/MAY/may/ since this is not an implementation or operational choice,
  but a fact of life.

---

In 4.2 you have truncated...

  The repair tunnel endpoint needs to be a node in the network
  reachable from S without traversing S-E.

...and...

  o  The repair tunneled point MUST be reachable from the tunnel source
      without traversing the failed link; and

You mean "reachable using the normal FIB", I think.

---

Section 4.3

  The preceding text has mostly described the computation of the remote
  LFA repair target (PQ) in terms of the intersection of two
  reachability graphs computed using SPFs.

"mostly"?

"reachability graphs"? Were they? Or were they reachability sets?

---

Your pseducode in 4.3 invokes an unresolved (and undescribed) function
Compute_Forward_SPF().

Actually, I think this is a bogus line that can be deleted.

---

I think the introduction of "pseudonode" in 4.3 may be a little without
context.

---

Section 7
  If for any reason the TLDP session cannot
  not be established

s/cannot not/cannot/

---

I think [RFC5424] and [RFC3411] are pretty poor references to give in
section 7. You appear to be saying that an implementation that cannot
establish a TLDP session should write a MIB module, standardise it, and
then report an error.

Can't you find an existing LDP MIB module that reports Session-up
failures?

Or maybe just delete "using any well known mechanism such as Syslog
[RFC5424] or SNMP [RFC3411]."

---

I think you can strengthen the security considerations. You have:

  To prevent their use as an attack vector IP repair tunnel endpoints
  (where used) SHOULD be assigned from a set of addresses that are not
  reachable from outside the routing domain.

1. "To prevent their use" is surely consistent with a "MUST".
  The fact that you want to say "SHOULD" means that you need to turn
  the text around...

  IP repair tunnel endpoints (where used) SHOULD be assigned from a set
  of addresses that are not reachable from outside the routing domain.
  This would prevent their use as an attack vector.

2. You can add a note about what traffic can be placed into a repair
  tunnel. You already have this earlier in the document, and it is
  worth restating.

3. I think you should also make note of whether the repair tunnel is
  advertised by the routing protocol as an available link.

[Ballot comment]
The title should be changed to "Remote Loop-Free Alternate (LFA) Fast Re-Route (FRR)", but it's not critical to do that now: the RFC Editor will do it if you don't.

Otherwise: I found this to be an easy and understandable read. Thanks.

[Ballot discuss]
I'm placing this Discuss because I found the description of the
algorithm in 4.2.1 and the worked example in Section 2 to be at odds
with the definitions of P-space, extended P-space, and Q-space.

I have been able to make things work by messing with the algorithm and
keeping the current definitions. You could probably do it by keeping
the algorithm and messing with the definitions.

My workings were as follows, based on the example in Section 2:

>            S---E
>          /    \
>          A      D
>          \    /
>            B---C
>
>  In Figure 1 S can reach A, B, and C without going via E;
>  these form S's extended P-space.

First, this should say "via S-E" and "extended P-space with respect to
S-E".

But...
>  Extended P-space
>                The union of the P-space of the neighbours of a
>                specific router with respect to the protected link

(Noting that 4.2.1.2 changes this definition *significantly* by saying
that the neighbour at the far end of the failing link - i.e., E in this
case - must be excised from the list of neighbours whose P-spaces are
combined).

...and...
>  P-space        P-space is the set of routers reachable from a
>                specific router using the normal FIB, without any path
>                (including equal cost path splits) transiting the
>                protected link.

Now, S's neighbours are A and E.
The P-space of A with respect to S-E is {B, C}
And the P-space of E with respect to S-E is {C, D}
So the extended P-Space of S with respect to S-E is {B, C, D}

Something is broken!
{A, B, C} is not even the (not extended) P-space of S with respect to
S-E which is {A, B} since C is not in that set because of SEDC.
On the other hand {A, B, C} *is* the extended P-space of E wrt S-E.

Although, I would observe that the pseudocode in 4.2.1 does derive
A, B, C as the extended P-space of S wrt S-E, but I think that is
because it has an entirely different definition of an extended P-space.

Now...
>  Q-space        Q-space is the set of routers from which a specific
>                router can be reached without any path (including
>                equal cost path splits) transiting the protected link.
...so the Q-space of S wrt S-E is {A, B} since CDES.
And, for the record, the Q-space or E wrt S-E is {C, D}

Now, to compound the confusion, the example determines the PQ nodes for
S wrt S-E by taking the intersection of the extended P-space for S wrt
S-E  and the Q-space of E wrt S-E. This is done notwithstanding the
definition...

>  PQ node        A node which is a member of both the P-space and the
>                Q-space.  Where extended P-space is in use it is 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.

This definition gives the PQ nodes of S wrt SE as either
- the intersection of {A, B} and {A, B} if P-space is being discussed
or
- the intersection of {B, C, D} and {A, B} if extended P-space is being
  used.

So the correct tunnel end point for your example is B.
But it clearly doesn't work since traffic to E that is tunneled to B may
still be ECMP routed back along BAS.

So I think in this whole example, you sit at S and you say "I want to
protect traffic to E". Then you work out the extended P-space of *E* wrt
S-E (which is {A, B, C}) and the Q-space of *E* wrt S-E (which is
{C, D}) giving you the correct PQ node for S to use to protect traffic
to E in the event of a failure of S-E as C.

It is simple! All you have to do is update the text to describe the
actual process and not the wrong one. Then the right result will pop
out :-)

The replacement is
OLD
  In Figure 1 S can reach A, B, and C without going via E;
  these form S's extended P-space.
NEW
  In Figure 1 S can reach A and B without going via S-E, and
  D can reach B and C without going via S-E. So E's extended P-space
  with respect to S-E is the nodes A, B, and C.
END


BUT, given all of this, are you sure that Section 4.2.1 is right? I'm
not.

------

Shouldn't the pseudocode in 4.3 be enclosed in code component macros to
match with the copyright TLP etc.?

[Ballot comment]
This is not my area of expertise so please excuse the brevity of the
rest of this review.

---

Please s/draft/document/ throughout (except the boilerplate and
filename) so that it can be published as an RFC (which is not a draft).

---

Although it causes some pain with abbreviations and a little more care
in explanation, you need to put the Introduction as the first section in
the document.

---

You are using RFC 5714 as a Normative Reference by making me go there
for the definition of terms. Please move it to the correct section.

---

IMHO your definition of FIB is rather loose.  Fortunately (?) "FIB" is
barely used in this document, so it might not be important, but if you
wanted to fix it:
- you are talking about IP packets in this document
- the actions are, I think, limited to forwarding actions

---

This comment applies iff the resolution of the Discuss is not a complete
change to the terminology!

I think definitions need to be tighter or omitted from this part of the
document. The definitions in 4.2.1 are more verbose and probably for
good reason. If you feel you need to retain these definitions early in
the document and can't lift the text from 4.2.1 then you need to address
the concerns below.

  P-space        P-space is the set of routers reachable from a
                  specific router using the normal FIB, without any path
                  (including equal cost path splits) transiting the
                  protected link.

"the protected link"? There is only one protected link?

Since the example is worded as...

                  For example, the P-space of S with respect to link
                  S-E, is the set of routers that S can reach without
                  using the protected link S-E.                 

...I think you need...

  P-space        The P-space of a router with respect to a specific
                  protected link is the set of routers reachable from
                  the specific router using the normal FIB, without any
                  path (including equal cost path splits) transiting the
                  protected link.

Similarly, you need...

  Extended P-space
                  The union of the P-spaces of all of the neighbours of
                  a specific router with respect to a single specific
                  protected link (see Section 4.2.1.2).

But note that 4.2.1.2 makes a significant change to this definition.

  Q-space        The Q-space for a specific router with respect to a
                  specific protected link is the set of routers from
                  which the specific router can be reached without any
                  path (including equal cost path splits) transiting the
                  protected link.

  PQ node        A PQ node is a node which is a member of both the
                  P-space and the Q-space for the same router and with
                  respect to the same protected link.
                 
                  Where extended P-space is being discussed, a PQ node
                  is a node which is a member of both the extended
                  P-space and the Q-space for the same router and with
                  respect to the same protected link.
                 
                  In remote LFA the repair tunnel endpoint is a PQ node.

Throughout the text, however, the terms are used rather loosely. For
example, when discussing Figure 1 you say "S's extended P-space", but
this is really "S's extended P-space with respect to S-E". Someone
familiar with the work might say that it is obvious from the context
that we are discussing the link S-E, and it is, but the terminology
needs to be tight.

---

There is some difficult terminology in Section 2

  If all link costs are equal, the link S-E cannot be fully protected
  by LFAs.  The destination C is an ECMP from S, and so can be
  protected when S-E fails, but D and E are not protectable using LFAs.

Is it the link or the node that is protected (or the traffic)? Perhaps
this could be rewritten to be less ambiguous.

---

Section 2

  B
  has equal-cost paths via B-A-S-E and B-C-D-E and so may go through
  S-E.

I don't think B is going anywhere. Maybe...

  B
  has equal-cost paths to E via B-A-S-E and B-C-D-E and so may reach E
  through S-E.

---

Section 2

  In MPLS networks the targeted LDP
  protocol needed to learn the label binding at the repair tunnel
  endpoint is a well understood and widely deployed technology.

But it would still benefit from a citation or a forward reference to
section 7.

---

I enjoyed 3.2

  relatively rare as is the incidence of failure in a well managed
  network.

So, managing my network well is protection against back-hoes. Nice.

---

In 3.2

  Multiple
  repairs MAY share a tunnel end point.

1. s/repairs/repair tunnels/
2. s/MAY/may/ since this is not an implementation or operational choice,
  but a fact of life.

---

In 4.2 you have truncated...

  The repair tunnel endpoint needs to be a node in the network
  reachable from S without traversing S-E.

...and...

  o  The repair tunneled point MUST be reachable from the tunnel source
      without traversing the failed link; and

You mean "reachable using the normal FIB" I think.

---

Section 4.3

  The preceding text has mostly described the computation of the remote
  LFA repair target (PQ) in terms of the intersection of two
  reachability graphs computed using SPFs.

"mostly"?

"reachability graphs"? Were they? Or were they reachability sets?

---

Your pseducode in 4.3 invokes an unresolved (and undescribed) function
Compute_Forward_SPF().

Actually, I think this is a bogus line that can be deleted.

---

4.3 has

                          if ( D_opt(n, y) <
                                  D_opt(n,self) + D_opt)(self, y)

Surely this is

                          if ( D_opt(n, y) <
                                  D_opt(n,self) + D_opt(self, y) )

---

I think the introduction of "pseudonode" in 4.3 may be a little without
context.

---

Section 7
  If for any reason the TLDP session cannot
  not be established

s/cannot not/cannot/

---

I think [RFC5424] and [RFC3411] are pretty poor references to give in
section 7. You appear to be saying that an implementation that cannot
establish a TLDP session should write a MIB module, standardise it, and
then report an error.

Can't you find an existing LDP MIB module that reports Session-up
failures?

Or maybe just delete "using any well known mechanism such as Syslog
[RFC5424] or SNMP [RFC3411]."

---

Why is the discussion of microloops on network re-converges considered
to be a management consideration (by inclusion in Section 9). Surely it
is a deployment or operational consideration.

---

I think you can strengthen the security considerations. You have:

  To prevent their use as an attack vector IP repair tunnel endpoints
  (where used) SHOULD be assigned from a set of addresses that are not
  reachable from outside the routing domain.

1. "To prevent their use" is surely consistent with a "MUST".
  The fact that you want to say "SHOULD" means that you need to turn
  the text around...

  IP repair tunnel endpoints (where used) SHOULD be assigned from a set
  of addresses that are not reachable from outside the routing domain.
  This would prevent their use as an attack vector.

2. You can add a note about what traffic can be placed into a repair
  tunnel. You already have this earlier in the document, and it is
  worth restating.

3. I think you should also make note of whether the repair tunnel is
  advertised by the routing protocol as an available link.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-rtgwg-remote-lfa-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Remote LFA FRR) to Proposed Standard


The IESG has received a request from the Routing Area Working Group WG
(rtgwg) to consider the following document:
- 'Remote LFA FRR'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-12-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This draft describes an extension to the basic IP fast re-route
  mechanism described in RFC5286, that provides additional backup
  connectivity for point to point link failures when none can be
  provided by the basic mechanisms.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-rtgwg-remote-lfa/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-rtgwg-remote-lfa/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/2009/
  http://datatracker.ietf.org/ipr/1770/
  http://datatracker.ietf.org/ipr/2071/

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The Intended Status is 'Proposed Standard'.  The draft is properly labeled.

The draft describes an extension to the (also Standards Track) work in rfc5286.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This draft describes an extension to the basic IP fast re-route
  mechanism described in RFC5286, that provides additional backup
  connectivity for point to point link failures when none can be
  provided by the basic mechanisms.

Working Group Summary

  This draft has been thoroughly discussed in the WG.  The mechanism
  described protects against link failures.  Significant discussion
  took place related to the need to also protect against node failures. 
  The WG reached consensus by agreeing to address more complex topic
  of node protection in a separate draft
  (draft-psarkar-rtgwg-rlfa-node-protection).

Document Quality

  There are existing implementations and multiple vendors have shown
  significant interest in the topic.  Note that there is no technical
  requirement for the selection criteria to be consistent across all
  routers, but such consistency may be desirable from an operational
  point of view.

  Besides the discussion about node protection (see above), the
  acknowledged reviewers deserve a special mention because they went
  deep into the text/algorithms and contributed the cost-based algorithm
  text (which is one potential implementation option). 


Personnel

  Document Shepherd = Alvaro Retana
  Responsible Area Director = Alia Atlas


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  Besides monitoring the discussions on the list, the shepherd personally
  reviewed the document for readiness.  At this point, the document is
  ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

  No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Yes.  The authors have been asked (and they answered) on the WG
  list about IPR at every step of the process.  There haven't been
  any concerns raised on the list.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  The WG as a whole understands and agrees with it.  As mentioned above,
  significant discussion (including several vendors and operators)
  has taken place on the list.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  Done.  The authors have been informed.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  N/A


(13) Have all references within this document been identified as
either normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  The state of other documents remains unchanged.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  No IANA actions are needed.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  N/A