[lisp] AD review of draft-ietf-lisp (part 7)

[Jari Arkko <[e-mail]>]

This is the last part of my review, as far as the actual document contents go. I will send another summary e-mail.

Technical:

> 14.1.  LISP Address Type Codes
>
>    Instance ID type codes have a range from 0 to 15, of which 0 and 1
>    have been allocated [LCAF].  New Type Codes MUST be allocated
>    starting at 2.  Type Codes 2 - 10 are to be assigned by IETF Review.
>    Type Codes 11 - 15 are available on a First Come First Served policy.
>
>    The following codes have been allocated:
>
>    Type 0:  Null Body Type
>
>    Type 1:  AFI List Type
>
>    See [LCAF] for details for other possible unapproved address
>    encodings.  The unapproved LCAF encodings are an area for further
>    study and experimentation.

To begin with, I did not understand this definition. I'm trying to understand where the LCAF draft actually makes the instance ID allocations, and I can't see it. In addition, the "Null Body Type" string only appears twice in this and the LCAF draft, and neither occurrence explains what it is. I think something is missing here.

Finally, I do not understand why this section is in -lisp. The string "LISP Address Type Code" does not appear in the rest of the document AFAICT. The allocations in the LCAF draft seem to be inside a format defined in that draft.  Shouldn't the IANA allocations and the creation of the registry be in that draft as well? This seems particularly important, given that the list of types in -lisp does not match the list in -lcaf.

Suggested edit: delete this section.

>
>     o  The following policies are used here with the meanings defined in
>        BCP 26  <http://tools.ietf.org/html/bcp26>: "Specification Required", "IETF Consensus", "Experimental
>        Use", "First Come First Served".
>

None of these terms are used in the rest of the document. (But see below.)

> 14.  IANA Considerations

This sections makes the right allocations from other, already existing registries (like UDP port numbers). But it should also define what the policies are for allocating new values with the various new number spaces that Lisp introduces:

- flags
- type
- reserved
- act
- unused flags
- ...

>     [BGP-SEC]  Lepinski, M., "An Overview of BGPSEC",
>                draft-lepinski-bgpsec-overview-00.txt  <http://tools.ietf.org/html/draft-lepinski-bgpsec-overview-00.txt>  (work in progress),
>                March 2011.
>
>     [KARP]     Lebovitz, G. and M. Bhatia, "Keying and Authentication for
>                Routing Protocols (KARP)Design Guidelines",
>                draft-ietf-karp-design-guide-02.txt  <http://tools.ietf.org/html/draft-ietf-karp-design-guide-02.txt>  (work in progress),
>                March 2011.

>     [RPKI]     Lepinski, M., "An Infrastructure to Support Secure
>                Internet Routing",draft-ietf-sidr-arch-13.txt  <http://tools.ietf.org/html/draft-ietf-sidr-arch-13.txt>  (work in
>                progress), February 2011.


I have a hard time seeing why these should be normative references. They are just mentioned as work that is in progress in securing the routing system. You do not need to read these to implement LISP as specified in this document, or even to understand what Lisp is or its impacts.

>     [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
>                STD 13,RFC 1034  <http://tools.ietf.org/html/rfc1034>, November 1987.
>

If you look at the way this is referenced from the text, it is clear that this should be a non-normative reference.

       The host obtains
       a destination EID the same way it obtains an destination address
       today, for example through a Domain Name System (DNS) [RFC1034]
       lookup or Session Invitation Protocol (SIP) [RFC3261] exchange.

>    [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
>               A., Peterson, J., Sparks, R., Handley, M., and E.
>               Schooler, "SIP: Session Initiation Protocol", RFC 3261,
>               June 2002.

Same as above.

>     [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
>                Traina, "Generic Routing Encapsulation (GRE)",RFC 2784  <http://tools.ietf.org/html/rfc2784>,
>                March 2000.
>

If you look at the way this is referenced from the text, I think this should be a non-normative reference.

   o  On an ITR, prepending a new IP header consists of adding more
       bytes to a MAC rewrite string and prepending the string as part of
       the outgoing encapsulation procedure.  Routers that support GRE
       tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already
       support this action.

GRE is here use as an example, not as normative behavior.

>     [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
>                via IPv4 Clouds",RFC 3056  <http://tools.ietf.org/html/rfc3056>, February 2001.
>

Same as above.

>
>     [RFC4866]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
>                Optimization for Mobile IPv6",RFC 4866  <http://tools.ietf.org/html/rfc4866>, May 2007.

I think this one can be non-normative or even be removed, depending on how the mobility section rewrite goes.

>
>     [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
>                Workshop on Routing and Addressing",RFC 4984  <http://tools.ietf.org/html/rfc4984>,
>                September 2007.
>

Background. Non-normative.

>     [AFI]      IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
>                NUMBERS
>                http://www.iana.org/assignments/address-family-numbers.
>
>     [AFI-REGISTRY]
>                IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
>                NUMBER registryhttp://www.iana.org/assignments/
>                address-family-numbers/
>                address-family-numbers.xml#address-family-numbers-1.

Is there really no better reference for this, an RFC perhaps?

I wish there were... and that RFC could be put in to the normative-reference section. If there is no suitable RFC I'm fine with the current two references as-is.

>     [INTERWORK]
>                Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
>                "Interworking LISP with IPv4 and IPv6",
>                draft-ietf-lisp-interworking-02.txt  <http://tools.ietf.org/html/draft-ietf-lisp-interworking-02.txt>  (work in progress).
>

I think this one should be normative. This is such a key piece of work to understanding Lisp, and the text seems to treat it as if it is a normative part. For instance:

   Proxy ITR (PITR):   A PITR is also known as a PTR is defined and
       described in [INTERWORK], a PITR acts like an ITR but does so on
       behalf of non-LISP sites which send packets to destinations at
       LISP sites.

>     [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
>                draft-ietf-lisp-ms-09.txt  <http://tools.ietf.org/html/draft-ietf-lisp-ms-09.txt>  (work in progress).
>

Isn't this normative as well? Here's an example of how the text refers to it:

   Map-Requests can also be LISP encapsulated using UDP destination port
    4342 with a LISP type value set to "Encapsulated Control Message",
    when sent from an ITR to a Map-Resolver.  Likewise, Map-Requests are
    LISP encapsulated the same way from a Map-Server to an ETR.  Details
    on encapsulated Map-Requests and Map-Resolvers can be found in
    [LISP-MS].

>
>     [VERSIONING]
>                Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
>                Versioning",draft-ietf-lisp-map-versioning-01.txt  <http://tools.ietf.org/html/draft-ietf-lisp-map-versioning-01.txt>  (work
>                in progress).
>

I suspect this is normative, too. See Section 6.6.3.

Jari