Dino,
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.
I now understand the background, thank you for the explanation. But I think the
WG still made the wrong call on this.
I would like to play the manager who tells you that the we need to ship your
product and this feature still has bugs in it. Lets rip it out and not endanger
our release schedule. In other words, I think other people will have the same
questions as I did about this part and there is no technical reason why it
needs to be here. I don't think the text is harmful by itself, but I predict
unnecessary questions. Lets remove it and move on.
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.
The standard model for this text is to include the terms that are used in
subsequent text. In any case, the terms above are also outdated after RFC 5226
came out.
I've taken this into account in my next proposed change (see below) and if you
use that text you do not need the above text any more.
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.
I'm not sure if we have seen a response, but I also don't think it is hard to
develop the text for this. This one needs to go in, because otherwise we don't
know how to manage the name spaces. It is a potential Discuss item from the
other ADs or even IANA if the process isn't clear. Here's a strawman text:
IANA should create a registry for managing the new namespaces within the LISP
protocol. This registry contains initially the following two new namespaces.
o New LISP Type values (Section 6.1.1) can be allocated through IETF Review or IESG Approval
<xref target="RFC5226"/>. Six values have already been allocated by this
specification (Section 6.1.1).
o New ACT values (Section 6.1.4) can be allocated through IETEF Review or IESG
Approval. Four values have already been allocated by this specification
(Section 6.1.4).
In addition, the LISP protocol has a number of flag and reserved fields, such
as the LISP header flags field (Section 5.3). New bits for flags can be taken
into use from these fields through IETF Review or IESG Approval, but these need
not be managed by IANA.
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
