> 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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
