Multicast-Only Fast Reroute
draft-ietf-rtgwg-mofrr-08

[Ballot comment]
options 2-4 in section 5 assume a certain amount of flow or application awareness that option 1 does not, option 1 is about control-plne awarness of topology and it seems reasonable to make that distinction.

[Ballot comment]
The following is a rant, and I do not expect any changes based on it (edit: or even a response):

The security considerations are of the form of "No new considerations beyond XXX". I have no opinion about the truth of that, but I wish draft authors would, in general, include some supporting discussion when making that sort of assertion.

[Ballot comment]
The following is a rant, and I do not expect any changes based on it:

The security considerations are of the form of "No new considerations beyond XXX". I have no opinion about the truth of that, but I wish draft authors would, in general, include some supporting discussion when making that sort of assertion.

[Ballot comment]
Russ Housley made some comments in his Gen-ART review, but I do not see a response to him, nor do I see any related changes in -07. Can you check if you need to do anything based on his review comments? Thanks.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-rtgwg-mofrr-06, 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:  (Multicast only Fast Re-Route) to Informational RFC


The IESG has received a request from the Routing Area Working Group WG
(rtgwg) to consider the following document:
- 'Multicast only Fast Re-Route'
  as Informational RFC

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 2015-04-30. 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


  As IPTV deployments grow in number and size, service providers are
  looking for solutions that minimize the service disruption due to
  faults in the IP network carrying the packets for these services.
  This document describes a mechanism for minimizing packet loss in a
  network when node or link failures occur.  Multicast only Fast Re-
  Route (MoFRR) works by making simple enhancements to multicast
  routing protocols such as PIM and mLDP.




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

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


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

  http://datatracker.ietf.org/ipr/2378/
  http://datatracker.ietf.org/ipr/2332/
  http://datatracker.ietf.org/ipr/1127/

I have two questions about missing content that I raised during my AD review.  Discussion can happen during IETF Last Call.

It would have been nice to have a sentence or two in there that considered the operational and troubleshooting aspects of MoFRR.  For instance, can mtrace work?  Would lsp-ping fail to work on the secondary UMH because of packets being dropped?

I also recall a private discussion about the interaction of MoFRR and IGP reconvergence after a failure and whether there can be relevant micro-forwarding loops as a result.  It would be very useful to have a sentence or two in this draft that discusses whether micro-forwarding loops are a concern that can either be frequently avoided because the secondary UMH or that needs to be considered in modeling or....