Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT)

["Alvaro Retana (aretana)" <[e-mail]>]

Med:

Hi!

I’ll clear my DISCUSS once the responsible AD confirms the status and changes the datatracker.  Just one more thing, I still think that this document should Update rfc6830 because even though it didn’t define a registry, it does say that it is “the authoritative source for allocating LISP Type values”. [This is a minor point knowing that rfc6830bis/rfc6833bis should soon render rfc6830 Obsolete.

FWIW, even though the IETF Last Call was made assuming a Proposed Standard, I don’t see the need to rerun it.  But that is up to the responsible AD.


About the text you proposed below…  The LISP Packet Type Registry (4.1, not 5.1) has only 15 possible values, 7 of which are assigned/reserved by this document, rfc6833bis assigns 3 more values, and this document mentions 5 potential extensions (“new message types are proposed in [I-D.ietf-lisp-ddt], [I-D.zhao-lisp-mn-extension], [I-D.boucadair-lisp-bulk], [I-D.ermagan-lisp-nat-traversal], or [I-D.boucadair-lisp-subscribe]” [*])…bringing the total up to 15.  Even if not all these new drafts make it, the LISP Packet Type Registry will soon have no more values to assign.  The result will be that the Sub-Types (in the LISP Shared Extension Message Type) will be used for production [1].

IOW, I don’t think you need a transition mechanism.  Instead, I think you need to recognize that the Sub-Types will be used for production deployments.  Suggestion:  consider changing the registration policy from FCFS to something where part of the space requires Standards Action, or maybe RFC Required or even Expert Review.  The result of FCFS is that anyone can request a value and get it: “There is no substantive review of the request, other than to ensure that it is well-formed and doesn't duplicate an existing assignment.” [rfc5226]

I didn’t make this last point a DISCUSS because the document was already discussed in the WG and went through IETF LC, but I think it is not a good idea to leave the Sub-Types registry as is.

Thanks!

Alvaro.


[*] BTW, I don’t think it is necessary for you to list these drafts since some of them may change or not make it all the way to publication.  The justification of generic new work should be enough.

[1] https://www.ietf.org/mail-archive/web/lisp/current/msg06459.html

On 1/31/17, 3:12 AM, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> wrote:


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> a. The Introduction justifies the extension as being used for
> experiments: "Because of the limited type space [RFC6830] and the need
to
> conduct experiments to assess new LISP extensions, this document
> specifies a shared LISP extension message type".  It seems clear later
in
> the text that the intent of the new message type is not just for
> experimentation, but that in fact the intent is for new functionality to
> be deployed using it.  Is that correct?  If it is, then please make it
> clear -- if not, then I would like to see how the authors propose a
> transition to happen between the experimental space and the production
> one.

[Med] What about adding this NEW text:

   Some LISP extensions that make use of the LISP shared extension
   message type may become eligible for an assigned LISP packet type
   (Section 5.1).  Once a LISP packet type is assigned to such LISP
   extension, an implementation SHOULD NOT use the LISP shared
   extension message type.

   To ensure backward compatibility during a transition period, an
   implementation MAY support a configuration parameter to instruct
   whether the LISP extension using the shared extension message is to
   be sent simultaneously with the LISP extension message using the
   assigned LISP packet type.  The default value of that configuration
   parameter is to disable sending both messages.  The use of the two
   message formats increases backward compatibility, but it has some
   implications on the LISP control load.  Such implications are
   expected to be limited in time and are fully under the control of the
   entity operating a LISP domain.