IPv4 Options for the Identifier-Locator Network Protocol (ILNP)
RFC 6746
Yes
No Objection
Note: This ballot was opened for revision 02 and is now closed.
(Ralph Droms; former steering group member) Yes
Thank you for publishing draft-irtf-rrg-ilnp-v4opts-05.txt, which revises the specification to use the IPv4 experimental option code. I have two minor editorial comments: In Figure 1, the option length fields should be "OL=20" and "OL=12". In Figure 3, the option length field should be "OL=12".
(Ron Bonica; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
I agree with Stewart's Discuss stating that there is no need to allocate IPv4 options for this experiment since it can be run on existing experimental options. The authors give a reason why using the existing values would not meet their requirements. I dispute the reason as follows: > In order to experiment with a new protocol, an experimental value may > be needed that won't collide with an existing or future usage. It is precisely the nature of experiments that they may colide if they are run in overlapping networks. There are sufficient code points available that this can be coordinated if there are multiple experiments. There are no existing experiments that immediately spring to mind. Future experiments will be less likely as IPv4 is sunsetted. --- The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says: This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation. An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on. It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text.
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
(Stewart Bryant; former steering group member) (was Discuss) No Objection
Thank you for addressing my discuss items. I would like to suggest that the authors verify that the IPv4 routers in their test network forward packets containing options with adequate performance before they invest significant time in the IPv4 Option approach.
(Wesley Eddy; former steering group member) No Objection