Skip to main content

A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses
RFC 6981

Yes

(Adrian Farrel)

No Objection

(Barry Leiba)
(Brian Haberman)
(Gonzalo Camarillo)
(Pete Resnick)
(Ron Bonica)
(Sean Turner)

Recuse

(Stewart Bryant)

Note: This ballot was opened for revision 10 and is now closed.

(Adrian Farrel; former steering group member) Yes

Yes (for -10)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (for -10)

                            

(Benoît Claise; former steering group member) No Objection

No Objection (2013-02-07 for -10)
Some sentences using the RFC 2119 keywords are apparently wrong.
- The not-via approach provides complete repair coverage and therefore MAY be used as the sole repair mechanism.
- Note that if the path from B to the final destination includes one or more nodes that are included in the repair path, a packet MAY back track after the encapsulation is removed.  
- etc...

My advice is to review the sentences with MAY/SHOULD/MUST 
See RFC 2119 section 6

Note: I did beat Pete on this one ;-) but I doublechecked a few examples with him!

(Brian Haberman; former steering group member) No Objection

No Objection (for -10)

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (for -10)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (2013-02-07 for -10)
I wonder if Section 10. Encapsulation should mention that all of the tunnel methods might create MTU issues.

(Pete Resnick; former steering group member) (was Discuss) No Objection

No Objection (for -10)

                            

(Ralph Droms; former steering group member) No Objection

No Objection (2013-02-07 for -10)
I agree with the question about "why publish this document" and look forward to conversation about it.

(Robert Sparks; former steering group member) No Objection

No Objection (2013-02-06 for -10)
Please consider adding a sentence noting that this document should not be accepted as a normative downref from a standards track document. Any IETF review this document has received has been shaped by the disclaimer that this is just reference for future work and is not appropriate for implementation. When it becomes appropriate, it would be much better if the the relevant algorithms and ideas were copied forward into a standards track document or that this document were explicitly revised to be on the standards track than to incorporate it into the standards track via a downref.

(Ron Bonica; former steering group member) No Objection

No Objection (for -10)

                            

(Russ Housley; former steering group member) No Objection

No Objection (2013-02-05 for -10)
  Please consider the clarifications suggested in the Gen-ART Review by
  Suresh Krishnan on 4-feb-2013.  You can find there review here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg08156.html

(Sean Turner; former steering group member) No Objection

No Objection (for -10)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2013-02-05 for -10)
AAH is cute as is "mild security"

(Wesley Eddy; former steering group member) No Objection

No Objection (2013-02-06 for -10)
I'm not totally clear on the ultimate goal of publishing this as an RFC (rather than just a magazine or journal article), based on the IPR and lack of concrete specification.  I think the "Purpose of this Document" could be more clear, despite having a section of that name.  Normally we don't just capture a WG's thinking and move on, unless we're maybe declaring open issues and unsolved mysteries that require a bunch of long-term work, and I didn't get that impression from this document.

(Stewart Bryant; former steering group member) Recuse

Recuse (for -10)