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

[Dino Farinacci <[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.

The source-EID in an RLOC-probe may contain a null body encoding. Because there was no data packet that triggered this Map-Request. I will add that to the RLOC-probe section.

Instance-ID is defined in the LCAF draft as Type 2. Here is the packet format:

  Instance ID LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |    Rsvd1      |    Flags      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 2    |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Instance ID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      Instance ID field including the AFI field itself.

   Instance ID:  the low-order 24-bits that can go into a LISP data
      header when the I-bit is set.  See [LISP] for details.

   AFI = x:  x can be any AFI value from [AFI].

   This LISP Canonical Address Type can be used to encode either EID or
   RLOC addresses.

> 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.

We (the working group) have decided to put the in-charter values in this draft and keep the other values in the LCAF draft. So that is why values 0 and 1 are in this draft. Since instance-ID is part of a VPN use-case, this is why it is the next value assigned in the LCAF draft.

We received direction from Terry on this since he is expert in registries et al.

> 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.)

That is Terry text and seems to be standard.

>> 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
> - …

Terry needs to respond to this.

>>    [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.

Can yo and the chairs argue over this and make a decision. Then I will put it where you have agreed.

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

You guys decide where all of this should go (from my last comment to this line), and I'll make one change.

>>    [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

Dino