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

[Ballot comment]

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.

[Ballot comment]
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".

IANA has reviewed draft-irtf-rrg-ilnp-v4opts and has the following comments:

IANA has questions about the IANA Actions requested in this document.

Upon approval of this document, IANA understands that a single action must be completed.

In the IP OPTION NUMBERS registry located at:

http://www.iana.org/assignments/ip-parameters

two new IP option numbers are to be registered for the ILNPv4 Identifier
option
and the ILNPv4 Nonce option.

IANA Question --> Do the authors intend that the copy flag be set to "1" ?

Copy: ?
Class: 0
Number: [ tbd at time of assignment ]
Value: [ tbd at time of assignment ]
Name: NID -- ILNPv4 Identifier
Reference: [ RFC-to-be ]

Copy: ?
Class: 0
Number: [ tbd at time of assignment ]
Value: [ tbd at time of assignment ]
Name: INONCE -- ILNPv4 Nonce
Reference: [ RFC-to-be ]

IANA understands that this is the only action required upon approval
of the document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

[Ballot comment]
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.

[Ballot discuss]
I respectfully disagree with the evaluation of the IESG shepherd WRT this document not being in conflict with existing IETF work.

The IETF is working to phase out IPv4, and yet the proposal here seems to be to extend the capabilities of IPv4, which is contra to that goal. If this draft is to be published it should surely go straight to historic status.

I do not think that we should be authorizing the assignment of IPv4 options to this protocol. The purpose of the protocol is to run an experiment and as such it should preferably be run on one of the existing experimental options. If the existing experimental options are not of a suitable type, a new experimental option could be considered.

[Ballot comment]
Re the para starting:

Currently deployed IPv4 routers from multiple router vendors use
packet forwarding silicon that is able to parse past IPv4 options
to examine the upper-layer protocol header at wire-speed on
reasonably fast (e.g. 1 Gbps or better) network interfaces.

I am not sure what routers designs the authors have evaluated, but I would have anticipated that a significant number of deployed routers will either drop or punt any packet that does not start with 45 in the first octet.

this is a request for the IESG to perform an RFC5742 review of the following drafts describing ILNP from the RRG, to be published as RFCs on the IRTF Stream:

- draft-irtf-rrg-ilnp-adv-02 (Experimental)
- draft-irtf-rrg-ilnp-arch-02 (Experimental)
- draft-irtf-rrg-ilnp-arp-02 (Experimental)
- draft-irtf-rrg-ilnp-dns-02 (Experimental)
- draft-irtf-rrg-ilnp-eng-02 (Experimental)
- draft-irtf-rrg-ilnp-icmpv4-02 (Experimental)
- draft-irtf-rrg-ilnp-icmpv6-02 (Experimental)
- draft-irtf-rrg-ilnp-noncev6-02 (Experimental)
- draft-irtf-rrg-ilnp-v4opts-02 (Experimental)

These documents have been approved for publication by the IRSG. See http://wiki.tools.ietf.org/group/irtf/trac/ticket/42 for details on prior reviews. Please copy all correspondence to the document shepherd, Tony Li (tony.li@tony.li).

Also, please note that several of these documents require IESG Approval for codepoint registrations in various IANA registries. In the process of reviewing these documents under RFC5742 (i.e., for conflicts with IETF work), please also approve the necessary codepoints to enable experimentation with ILNP.

Thanks,
Lars