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

From: "Alvaro Retana" <[email-masked]>
Date: Mon, 30 Jan 2017 13:46:09 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-lisp-type-iana-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have a couple of points I think we should DISCUSS before moving this
document forward: the intended status and the definition of the
registry.

(1) Intended Status: The Datatracker indicates that the Intended RFC
status for this document is Proposed Standard (as does the Shepherd
WriteUp and the IETF LC), but the header on the document says
Experimental.  I note that the document header was changed after a
discussion on the WG list resulting from the RTG Directorate review [1],
but that happened after the WGLC.  Which is the right status?
 
(2) LISP Packet Types Registry Definition: It seems very odd to me that
the LISP Packet Types Registry uses Standard Action as the registration
policy given that the LISP work is currently Experimental -- and that the
other references in it would in fact be from an Experimental RFC
(rfc6380).  I know there's work on rfc6830bis (in the Standards Track),
but I think it would be better to have this registry defined in the base
specification (rfc6833bis, in this case)...or to wait for the publication
of that document to progress this one.

I think there's nothing procedurally wrong with having an Experimental
RFC define a Standard Action Registry and populate part of it with
references to Experimental RFC.  However, the solution just doesn't seem
clean to me -- so I would like to hear the justification for the rush
(and not waiting for rfc6380bis/rfc6388bis).

I have no issue with a document making use of the Code Point to describe
the new LISP Shared Extension Message Type (without creating the
Registry).  But given that the base LISP specification is still
Experimental, then this document should be too.  There shouldn't be an
issue with changing the Status of this document (in-place) once
rfc6380bis/rfc6388bis progress.

There's also the issue that RFC6830 (and rfc6833bis) contain the
following text: "This section will be the authoritative source for
allocating LISP Type values..."   Which means that (if the registry is to
be defined here), this document should at least Update RFC6830...

In summary, I think that the correct Status for this document is
Experimental.  I also think that it would be better to wait for
rfc6833bis to define the Registry.

[1]
https://mailarchive.ietf.org/arch/msg/lisp/m1EicCexdX1GI183pba-mcHJM7g/?qid=ada479dce3c434bfaf948b0ee8240996

----------------------------------------------------------------------
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.

b. The IANA Considerations Section says that "The value 15 is reserved
for Experimental Use [RFC5226]."  But it is being assigned to the new
LISP Shared Extension Message.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 30 Jan 2017 16:52:30 -0500

With regard to status, I think we can work with you.
But we really want to establish the registry now.
We already have proposals for code points beyond the experimental RFCs, 
and requests for room to experiment without writing an RFC.

As far as I can tell, the Working Group intent is that the registry 
allow reservation by experimental and informational RFCs, not just 
standards track RFCs.  We can fix that.

With regard to the revision to the base documents, to get them on the 
standards track, one of the important fixes is to stop claiming that the 
RFC defines all the values, and just update the registry entries where 
appropriate to reference the new RFC (once we have it.)

The rush is simply that it is already getting hard to keep track.  We 
should have established a registry in the first place.  So we are doing 
so now.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 30 Jan 2017 22:10:23 +0000

Joel:

Hi!

To clarify, there are two Registries being defined: LISP Packet Types and Sub-Types.

I don’t have an issue with the Sub-Types registry, which is the one that allows you to get new functionality up and going, with or without an RFC – it currently has a FCFS registration policy.  Maybe a little too open, but if this is what the WG wants, then I’m ok with it.

The LISP Packet Types Registry is the one I have an issue with being defined in this document.  It seems like the main motivation of the document is the new LISP Shared Extension Message Type, and that creating the registry only serves to assign type 15 to it.  But any other extensions would make use of the Sub-Types registry, and not this one.

Maybe I’m missing the subtleties of which space is used for what...

Thanks!

Alvaro.

On 1/30/17, 4:52 PM, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>> wrote:

[1]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 30 Jan 2017 17:18:59 -0500

Yes, 15 is the only new type at the moment.
But the existence of a request for new types raises the point that there 
may well be others.  So creating a registry seems the right thing to do. 
  Since the registry needs to allow experimental entries (the current 
protocol), it seems that we are better served getting it established now.

Yours,
Joel

On 1/30/17 5:10 PM, Alvaro Retana (aretana) wrote:
> I don’t have an issue with the Sub-Types registry, which is the one that
> allows you to get new functionality up and going, with or without an RFC
> – it currently has a FCFS registration policy.  Maybe a little too open,
> but if this is what the WG wants, then I’m ok with it.
>
>
>
> The LISP Packet Types Registry is the one I have an issue with being
> defined in this document.  It seems like the main motivation of the
> document is the new LISP Shared Extension Message Type, and that
> creating the registry only serves to assign type 15 to it.  But any
> other extensions would make use of the Sub-Types registry, and not this one.
>
>
>
>         Please refer to
>         https://www.ietf.org/iesg/statement/discuss-criteria.html
>

---

From: <[email-masked]>
Date: Tue, 31 Jan 2017 08:12:28 +0000

Hi Alvaro, all,

I confirm that the intended status is Experimental. Joel already explained why the WG wanted to create this registry now. 

See more inline.

Cheers,
Med

> -----Message d'origine-----
> De : Joel M. Halpern [mailto:[email-masked]]
> Envoyé : lundi 30 janvier 2017 22:53
> À : Alvaro Retana; The IESG
> Cc : [email-masked]; Luigi Iannone; lisp-
> [email-masked]; [email-masked]
> Objet : Re: Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with
> DISCUSS and COMMENT)
> 
> > https://mailarchive.ietf.org/arch/msg/lisp/m1EicCexdX1GI183pba-
> mcHJM7g/?qid=ada479dce3c434bfaf948b0ee8240996
> >
> >

[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.

> > LISP Shared Extension Message.

[Med] I deleted that sentence.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 31 Jan 2017 14:28:48 +0000

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

---

From: <[email-masked]>
Date: Tue, 31 Jan 2017 14:54:31 +0000

Hi Alvaro,

Please see inline.

Cheers,
Med

De : Alvaro Retana (aretana) [mailto:[email-masked]]
Envoyé : mardi 31 janvier 2017 15:29
À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; The IESG
Cc : [email-masked]; Luigi Iannone; [email-masked]; [email-masked]
Objet : Re: Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT)

Med:

Hi!

[Med] It makes sense to add an “Update” header to this document. Unless there is objection, I will add this change.

[Med] Agree.

[Med] The motivation for using FCFS is to avoid imposing heavy constraints on designers to register their extensions. Also, given that we have 4096 sub-type values, the full range cannot be consumed completely even with a FCFS policy. That’s said, I agree with you it might be more safe to secure a range for assignments via Standards Action (e.g., 0-1023) and leave the 1024-4095 for FCFS. I can make such change.

Thanks!
Alvaro.

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Tue, 31 Jan 2017 22:31:53 +0000

Hi Alvaro,

As you noted, the document’s status was changed from PS to Experimental based on the RTG Directorate Review. I’ve changed it on datatracker (missed it). Agree, no need to rerun Last Call for this.

Thanks,
Deborah

From: iesg [mailto:[email-masked]] On Behalf Of Alvaro Retana (aretana)
Sent: Tuesday, January 31, 2017 9:29 AM
To: [email-masked]; Joel M. Halpern <[email-masked]>; The IESG <[email-masked]>
Cc: Luigi Iannone <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT)

Med:

Hi!

Thanks!

Alvaro.