RtgDir review: draft-ietf-rtgwg-ipfrr-notvia-addresses-10

[Ross Callon <[e-mail]>]

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-rtgwg-ipfrr-notvia-addresses-10
Reviewer: Ross Callon
Review Date: January 28, 2013
IETF LC End Date: January 31, 2013
Intended Status: informational

Summary:  This document is basically ready for publication, but has nits that should be considered prior to publication.

Comments:

Generally this document is very well written and is very readable. I have only very minor comments that I think that you should consider prior to publication.

Major Issues:  No major issues found.

Minor Issues:

The first paragraph of 3.2 is a bit imprecise. It says that there are advantages of using not-via in combination with LFA, but then two of the three advantages cited don't actually apply to the combination, but only to using LFA without not-via (which of course has the disadvantage of not offering complete coverage, as is discussed in the next paragraph).

Up until section 4.1, the document pretty much reads as if we are talking about node protection. 4.1 then just sort of forgets (or generalizes) this and jumps into options for both node protection and link protection. I think that it is appropriate for section 3 to read the way that it currently does, since it is an overview and does a good job of introducing the technique without confusing the reader with complexities (which are appropriately covered later in the document). To me this implies that somewhere in section 4, prior to the current section 4.1, you might want a brief discussion of node protection versus link protection. You might consider adding something like:

  In general it may be difficult for a router to quickly distinguish between
  link failure and node failure. For example in figure 1 node S might see
  the link to node P suddenly totally fail. In general it is impossible to
  immediately determine whether node P has failed or if the link from S to P
  has failed (in some cases link layer indications might give information
  regarding what is going on, and the updates to link state packets from
  node P or from all neighbors of node P will eventually clarify what has
  failed once received and processed). For this reason it is generally
  safer to assume that node P has failed and where possible reroute
  traffic to the next node downstream from P. However, there may be cases
  where this is impossible. For example some destinations might be only
  reachable via node P, and in some topologies the failure of node P may
  partition the network. For this reason we need to consider both node and
  link failures.

Returning to section 4.1, I think that it would be a bit clearer if the last sentence of the first paragraph were its own paragraph. This would cause 4.1 to start with a general discussion, then have a paragraph about link protection, then have a paragraph about node protection.

The last sentence of section 4.1 is imprecise. It currently states: "In the case of link protection this simply means that the advertisement from P to S is suppressed, with the result that S and all other nodes compute a route to Ps which doesn't traverse S, as required". However, this does not actually compute a route that is guaranteed to not traverse node S, it computes a route that does not traverse the link from S to P. The sentence should read: "In the case of link protection this simply means that the advertisement from P to S is suppressed, with the result that S and all other nodes compute a route to Ps which doesn't traverse the link from S to P, as required".

Section 5.1, second paragraph: "ANY failure" should be "ANY single failure".

Section 6.1: At first glance it seemed somewhat drastic to have a MUST assume that all other links of the SRLG have failed. After reading the entire section and thinking about this for a while, I have come to the conclusion that you are correct. However, I am wondering whether just a bit more explanation might be useful. I am therefore wondering about additional explanation so that the first paragraph of section 6.1 might read:

   A Shared Risk Link Group (SRLG) is a set of links whose failure can
   be caused by a single action such as a conduit cut or line card
   failure.  When repairing the failure of a link that is a member of an
   SRLG, it is not immediately known whether the entire group has failed
   or only that link. In order to avoid multiple problems as explained
   below, it MUST be assumed that all the other links that are also
   members of the SRLG have also failed.  Consequently, any repair path
   MUST be computed to avoid not just the adjacent link, but also all
   the links which are members of the same SRLG.

Nit:

At first glance section 3.1 seems a bit terse. I am undecided whether it would be worthwhile to add a bit more explanation. The current text is clear enough to one well versed in the various routing technologies and what I have been able to think of as possible additional text seems almost too obvious. As an example the first paragraph could be added to, to read:

   A router can use an equal cost multi-path (ECMP) repair in place of a
   not-via repair. For example, if a router has multiple equal cost next hops
   to a particular destination, and the link to one fails, it just forwards all
   traffic to the other equal cost next hop(s) without using not-via.

Similarly the second paragraph could be added to, to read:

   A router computing a not-via repair path MAY subject the repair to
   ECMP. For example in figure 1 there may be multiple equal cost paths
   from S to Bp, each of which avoids node P. Since not-via encapsulates
   a packet to Bp, equal cost multipath will work in the normal way for
   computing and using paths from S to Bp.

Again these updates almost seem too trivial, so I have included this suggestion under "nits" and will leave it to the discretion of the authors whether they want to make any changes.