Skip to main content

IPv4 Options for the Identifier-Locator Network Protocol (ILNP)
draft-irtf-rrg-ilnp-v4opts-06

Yes

(Ron Bonica)

No Objection

(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Pete Resnick)
(Robert Sparks)
(Russ Housley)
(Sean Turner)
(Stephen Farrell)
(Wesley Eddy)

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

Ralph Droms Former IESG member
Yes
Yes (2012-05-30 for -05) Unknown
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 IESG member
Yes
Yes (for -05) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2012-05-23 for -03) Unknown
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 IESG member
No Objection
No Objection (for -03) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Stewart Bryant Former IESG member
(was Discuss) No Objection
No Objection (2012-05-31 for -05) Unknown
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 IESG member
No Objection
No Objection (for -03) Unknown