Sorry for my Lag, I had a long weekend of ice-hockey officiating.
On 31/10/11 7:46 AM, "Jari Arkko" <[email protected]> wrote: > 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. > The important thing was understanding that the header had parts in it which fell (at the time) out of charter - yet still being as complete as possible in documenting what we can. It made very little sense to just specify the Instance ID type codes without pointing to one of the major reasons for having them in the first place. But not stomping all over the charter and making sensitive people angry at us for promulgating the LCAF values direct to an IANA registry without IETF review of the LCAF document. > 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. > Perhaps this text helps: Instance ID type codes have a range from 0 to 15, of which 0 and 1 have been allocated. New Type Codes MUST be allocated consecutively starting at 2. Type Codes 2 - 10 are to be assigned by IETF Review or IESG Approval. 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 Since Instance IDs are in the header format with the use of the I bit justifies it. >> >> >>>> 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 >>> - S >> Terry needs to respond to this. Yes, this needs to be done - sorry I didn't notice it in my review. For all the namespaces, I'm happy with IETF Review or IESG Approval. > > 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). > <comment: specify the values, it makes life easier for many> These are: Reserved: 0 b'0000' LISP Map-Request: 1 b'0001' LISP Map-Reply: 2 b'0010' LISP Map-Register: 3 b'0011' LISP Map-Notify: 4 b'0100' LISP Encapsulated Control Message: 8 b'1000' > 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). These are: (0) No-Action: The map-cache is kept alive and no packet encapsulation occurs. (1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded. (2) Send-Map-Request: The packet invokes sending a Map-Request. (3) Drop: A packet that matches this map-cache entry is dropped. An ICMP Unreachable message SHOULD be sent. > > 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. > For binary flags, I agree. For anything that has more than 2 options/types/sub-types and if it hits the wire, for interop, I always go looking at what a registry says, to then give me the right set of RFCs to consider for behaviour. Or have I missed your meaning Jari? I would feel much more comfortable with IANA tracking a namespaces than having them sit untracked in RFCs. Cheers Terry _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
