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