Subject: Comments on draft-ietf-rtgwg-remote-lfa

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 22 Sep 2014 22:55:54 +0000

Hi!

After a long wait, I finally got to this..

I do have some comments (minor and nits) that I would like addressed.  As you look at these I will get the write up ready to send to the IESG — you can either address my comments now/before the IESG gets the publication request or with any comments that come from them.

Thanks!

Alvaro.

Minor Issues

  1.  4.2.1.3 states that "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. . .there is no common node and hence no viable repair tunnel end-point."  The immediately following section (4.2.2) starts with "The mechanisms described above will identify all the possible repair tunnel end points that can be used to protect a particular link."   So..you're saying that there are no viable end-points (which is technically true because you're using the P-space)..and then you say that you figured out all the possible repair points, which is obviously not true because in the previous section you didn't mention the union of the Q-space and the extended-P-space.   All this is to say that a reader may be confused — adding mention of the extended p-space in 4.2.1.3 should clear it up.
  2.  Section 5 (Example).  "When a failure occurs on the link between PE1 and P2", but the figure doesn't show these 2 routers as connected..so I'm assuming you're talking about PE1 and P1 (and later in the text PE2 and P2).
  3.  Section 6.  What is the "null strategy"?  Please explain and/or clarify.
  4.  Section 7.  "Ideally this is provided by the remote LFA repair target advertising this address in the IGP in use. . .out of scope for this document and must be specified in an IGP specific RFC."  What's the importance of even mentioning this here?  If the extensions don't exist and there is a mechanism that does (using the router ID, as mentioned), then why include something that doesn't exist..?  IMHO, if you want those extensions to be available, then go define them and then point back to this draft as a way to know where to establish the session.

Nits

  1.  Terminology.  It would be nice to reorder this section so that terms defined later are not used to define terms earlier.  For example, P-space is used in the definition on Extended P-space.
  2.  Introduction. s/many topologies[RFC6571]/many topologies [RFC6571]  (missing space)  There are several other places where the space is missing, which sort of screws up the references in the html version..maybe something that the RFC Editor will pick up on..I hope.
  3.  Introduction. s/This technique describes in this document/The technique described in this document
  4.  Repair Paths. s/[I-D.ietf-rtgwg-lfa-manageability].]/[I-D.ietf-rtgwg-lfa-manageability].
  5.
4.2 s/protected link S-E.,/protected link S-E,
  6.  4.2 s/When released, tunneled packets/When released, packets (not in the tunnel anymore)
  7.  4.2.1 s/Finally we how to compute/Finally we show to compute
  8.  4.2.1 s/is provide in/is provided in
  9.  4.2.2 s/that member of the set/that the member of the set
  10. 4.3 s/pseudo-code provides/pseudo-code provided
  11. rfc3137 has been obsoleted by rfc6987
  12. 7. s/for the emote LFA/for the remote LFA
  13. Section 8.
     *   I always like results in an Appendix, but that's just me..there may have been a discussion already about it (similar to the pseudo-code).
     *   There are some places where some explanation could be useful: what does the fact that the PQ session could not be established mean?  What is the significance of the percentiles?  Etc..  Just to have a more complete report.
     *   The last few sentences of the section propose other solutions in case the intersection between P and Q spaces is empty.  I think that is out of scope and should be taken out.  As with the suggestion of IGP extensions (section 7), if there is a specific/complete solution then it should be specified.
  14. Section 10 ends with "The following section motivates..",  but there is no such section.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 23 Sep 2014 14:30:52 +0000

A couple more comments as I'm writing the shepherd's doc:

  1.  Please don't forget to look at the idnits: https://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-remote-lfa-06.txt
  2.  All the references are identified as Informational.  I'm thinking that rfc5286 and rfc2119 should be Normative.

Thanks!

Alvaro.

On 9/22/14 6:55 PM, "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi!

Thanks!

Alvaro.

Minor Issues

Nits

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 24 Sep 2014 16:48:09 +0100

Alvaro

Thanks. Please see inline.

On 22/09/2014 23:55, Alvaro Retana (aretana) wrote:
> I do have some comments (minor and nits) that I would like addressed.
> As you look at these I will get the write up ready to send to the IESG
> --- you can either address my comments now/before the IESG gets the
> publication request or with any comments that come from them.
>
> Thanks!
>
> Alvaro.
>
>
> Minor Issues
>
>  1. 4.2.1.3 states that "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. . .there is no common node and hence no viable repair
>     tunnel end-point." The immediately following section (4.2.2)
>     starts with "The mechanisms described above will identify all the
>     possible repair tunnel end points that can be used to protect a
>     particular link." So..you're saying that there are no viable
>     end-points (which is technically true because you're using the
>     P-space)..and then you say that you figured out all the possible
>     repair points, which is obviously not true because in the previous
>     section you didn't mention the union of the Q-space and the
>     extended-P-space. All this is to say that a reader may be confused
>     --- adding mention of the extended p-space in 4.2.1.3 should clear
>     it up.
>
I added some text to address this.
>
>  1. Section 5 (Example). "When a failure occurs on the link between
>     PE1 and P2", but the figure doesn't show these 2 routers as
>     connected..so I'm assuming you're talking about PE1 and P1 (and
>     later in the text PE2 and P2).
>
I think there were a couple of errors here. Please can people take a
look at -7 and makes sure I have not made any other silly errors.
>
>  1. Section 6. What is the "null strategy"? Please explain and/or clarify.
>
I have added some text just before to explain that you might assume that
node failures with microloops were sufficiently that you might choose to
ignore the case.
>
>  1. Section 7. "Ideally this is provided by the remote LFA repair
>     target advertising this address in the IGP in use. . .out of scope
>     for this document and must be specified in an IGP specific RFC."
>     What's the importance of even mentioning this here? If the
>     extensions don't exist and there is a mechanism that does (using
>     the router ID, as mentioned), then why include something that
>     doesn't exist..? IMHO, if you want those extensions to be
>     available, then go define them and then point back to this draft
>     as a way to know where to establish the session.
>
>
This text was debated a lot and I would prefer to see it go as is to the
next review stage.
> Nits
>
>  1. Terminology. It would be nice to reorder this section so that
>     terms defined later are not used to define terms earlier. For
>     example, P-space is used in the definition on Extended P-space.
>  2. Introduction. s/many topologies[RFC6571]/many topologies [RFC6571]
>     (missing space) There are several other places where the space is
>     missing, which sort of screws up the references in the html
>     version..maybe something that the RFC Editor will pick up on..I hope.
>  4. Repair Paths.
>     s/[I-D.ietf-rtgwg-lfa-manageability].]/[I-D.ietf-rtgwg-lfa-manageability].
> 5.
1..12 done
>
>  1. Section 8.
>       * I always like results in an Appendix, but that's just
>         me..there may have been a discussion already about it (similar
>         to the pseudo-code).
>
It has been here for a while, can we see what we get in the next round
of reviews.
>
> 1.
>       * There are some places where some explanation could be useful:
>         what does the fact that the PQ session could not be
>         established mean? What is the significance of the percentiles?
>         Etc.. Just to have a more complete report.
>
It is the number of cases where neither LFA nor simple RLFA was adequate
- I have added some text.
>
> 1.
>       * The last few sentences of the section propose other solutions
>         in case the intersection between P and Q spaces is empty. I
>         think that is out of scope and should be taken out. As with
>         the suggestion of IGP extensions (section 7), if there is a
>         specific/complete solution then it should be specified.
>
I have trimmed this down to

In the small number of cases where there is no intersection between the
(extended)P-space and the Q-space, a number of solutions to providing a
suitable path between such disjoint regions in the network have been
discussed in the working group. For example an explicitly routed LSP
between P and Q might be set up using RSVP-TE or using Segment Routing
[I-D.filsfils-rtgwg-segment-routing]. Such extended repair methods are
outside the scope of this document.

> 1.
>  2. Section 10 ends with "The following section motivates..", but
>     there is no such section.
>
Text deleted

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 24 Sep 2014 17:35:53 +0100

On 23/09/2014 15:30, Alvaro Retana (aretana) wrote:
>  1. Please don't forget to look at the
>     idnits: https://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-remote-lfa-06.txt
>
I think it's all historic stuff but I will do a final check.
>
>  1. All the references are identified as Informational.  I'm thinking
>     that rfc5286 and rfc2119 should be Normative.
>
Done.

- Stewart

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 24 Sep 2014 17:32:50 +0000

On 9/24/14 11:48 AM, "Stewart Bryant (stbryant)" <[email-masked]<mailto:[email-masked]>> wrote:

Stewart:

I'm ok with everything else..

  1.

In the small number of  cases where there is no intersection between the (extended)P-space and the Q-space, a number of solutions  to providing a suitable path between such disjoint regions in the network have  been discussed in the working group. For example an explicitly routed LSP between P and Q might be set up using RSVP-TE or using Segment Routing
[I-D.filsfils-rtgwg-segment-routing]. Such extended repair methods are outside the scope of this document.

I still think that it is unnecessary, but I'm ok if you want to leave it in.

I'm assuming that by "discussed in the working group" you mean that it came up on the list while discussing the draft, right?  Technically, those topics are not rtgwg topics..but that's just another nit.  BTW, the correct reference for Segment Routing is I-D.filsfils-spring-segment-routing.

Thanks!

Alvaro.