Subject: Re: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-03.txt

From: <[email-masked]>
Date: Tue, 2 May 2017 06:52:02 +0000

Hi Dino,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Dino Farinacci [mailto:[email-masked]]
> Envoyé : vendredi 28 avril 2017 19:53
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked] list
> Objet : Re: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-03.txt
> 
> > Hi Dino,
> >
> > Thank you for replying.
> 
> See responses. I cut out some email where I had no response.
> 
> >>> ·         At least the first sentence should be reworded to be aligned
> >> with RFC8113 (which is the reference for allocating LISP type values).
> If
> >> you want the bis document to be authoritative for that, the only way
> for
> >> that is to merge RFC8113 in the bis document.
> >>
> >> No, not really. RFC6833bis is authoritative for LISP Type values,
> >
> > [Med] No. For example, the allocation of a new LISP type will require a
> standard track document as per RFC8113. Such considertaons are not covered
> in the the bis document.
> 
> The type values that are listed are for messages that ARE ALREADY in the
> protocol. So please tell me what part of the wording you don’t agree with.
> 
[Med] OK. Your proposed modification says "summarizes for IANA the LISP Type codes assigned by this document". 
* Assignment are made by IANA not documents.
* NEW assignment requests are to be included in a dedicated IANA sub-section. 

> > RFC8113
> >> is authoriative for Type 15 sub-type values.
> >
> > [Med] Not only for that, but also for allocating future type values.
> 
> RFC8113 should not be used for future Type values.

[Med] I'm afraid there is a misunderstanding here. Please check https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml#lisp-packet-types. The bis should follow RFC8113 for new assignment requests. 

 Only for sub-type
> values for Type 15. Beacuse that is what the RFC documents.
> 
> >
> >
> >>
> >>> ·         I wouldn’t list “Not Assigned 9-14  b'1001'- b'1110'” here
> >> because these values can be allocated in the future. I would avoid
> >> mismatches with the IANA registry.
> >>
> >> When they are assigned, this document will change to reflect the new
> >> values. We want to be explicit to tell people they are not assigned
> versus
> >> not being listed at all.
> >
> > [Med] We have a registry for that. This information will be obsolete
> when new assignments show up. I reiterate my comment.
> 
> Yes, and the registry points to an RFC. And it should be RFC6833bis which
> is on standards track.

[Med] My point Dino is that we need to avoid including stale information in RFCs. We have other tools to better track assignments than RFC. 

> 
> > I
> >> cannot do it for type 7 since the NAT-traversal is not a working group
> >> document (yet).
> >
> > [Med] then, please remove Info-Request/Reply from this document.
> 
> NAT-traversal is a critical part of the LISP architecture when IPv4 is
> used as the underlay. And there are several implementations of NAT-
> travesal, so this is a case where the Info-Request/Info-Reply is an
> existing mechanism.
> 

[Med] I'm aware of that, Dino. My comments are:

* Info-Request/Info-Reply is not defined in this document. 
* There is no reference where Info-Request/Info-Reply.

If you think that Info-Request/Info-Reply is a mechanism that should be in the base spec, then consider including that part of the spec in the bis document. Lacking that, I reiterate my comments. 

> >
> >>
> >>>   The values in the ranges 5-7 and 9-14 can be assigned via Standards
> >>>   Action [RFC5226].  Documents that request for a new LISP packet type
> >>>   may indicate a preferred value in the corresponding IANA sections.
> >>
> >> I will add this text. Thanks.
> >>
> >>> ·         “LISP Map-Referral:      6     b'0110'” is about a temporary
> >> assignment not a permanent one.
> >>
> >> No it is permanent because LISP-DDT is progressing to RFC (standards
> >> track).
> >
> > [Med] the IANA registry says the following: "LISP DDT Map-Referral
> (TEMPORARY - registered 2017-04-19, expires 2018-04-19)". I know that
> value will be permanent assigned when DDT is in the standard track, but we
> are not yet there.
> 
> That is going to change in the coming weeks since LISP-DDT is about to
> come to RFC 8111.

[Med] The RFC-to-be 8111 can't change that for the following reason:

Internet Engineering Task Force (IETF)                         V. Fuller
Request for Comments: 8111                   VAF.NET Internet Consulting
Category: Experimental                                          D. Lewis
          ^^^^^^^^^^^^
ISSN: 2070-1721                                               V. Ermagan
                                                           Cisco Systems
                                                                 A. Jain
                                                        Juniper Networks
                                                              A. Smirnov
                                                           Cisco Systems
                                                              April 2017

   Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)

Type assignments require "Standards Action".

> 
> Your subsequent email said you have concerns with my update. So please be
> more specific and include your comments in another email.

[Med] My pending comments are: 
* Add a new IANA sub-section for new type assignment requests. This section should include a request for "Map-Notify-Ack" with a preferred value of 5.
* Remove "For Future Assignment" entry from the table of Section 4.1
* Remove LISP Info-Request/Reply from Section 4.1.
* Consider changing the "Current allocations are" wording as this may not be accurate in the future. 

> Thanks,
[Med] Thank you.

> Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 2 May 2017 13:21:41 -0700

See comments inline. I am going to need help from the chairs and Deborah perhaps on some of these items.

> * NEW assignment requests are to be included in a dedicated IANA sub-section. 

That is what Joel suggested.

> [Med] I'm afraid there is a misunderstanding here. Please check https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml#lisp-packet-types. The bis should follow RFC8113 for new assig…

Registries provide code-points and from the above URL you can see there is a refernece to RFC6830 which we are changing to RFC6833bis so we can have the most recent information documented.

> [Med] My point Dino is that we need to avoid including stale information in RFCs. We have other tools to better track assignments than RFC. 

RFC6833bis is a large effort to bring things current. We are removing stale information and updating with the latest information.

> * There is no reference where Info-Request/Info-Reply.

I can add a refernce. We do have I-D.ermagan-lisp-nat-traversal in the Informative Reference section but no pointer to it. It got lost in the shuffle of doing the bis documents. Good catch.

> If you think that Info-Request/Info-Reply is a mechanism that should be in the base spec, then consider including that part of the spec in the bis document. Lacking that, I reiterate my comments. 

It depends on too much NAT-traversal machinery. It would make the base spec very large. 

I would like the chairs to comment about putting a reference in RFC6833bis to a non-working NAT-traversal document.

> Type assignments require "Standards Action”.

Chairs? Deborah? 

> * Add a new IANA sub-section for new type assignment requests. This section should include a request for "Map-Notify-Ack" with a preferred value of 5.

Why call out a single message type. It will make the document look incremental and date it. The IANA request is for all types. They just need to be updated and point to RFC6833bis.

Chairs? Deborah?

> * Remove "For Future Assignment" entry from the table of Section 4.1

You have resolve this with Joel.

> * Remove LISP Info-Request/Reply from Section 4.1.

I would like to hear others comment about this.

> * Consider changing the "Current allocations are" wording as this may not be accurate in the future. 

I don’t think they can change to be honest. There are implementations out there. We have to be practical.

Thanks,
Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 2 May 2017 16:47:54 -0400

Top commenting on a few of the points, as co-chair.

1) With regard to LISP-DDT, the allocation issue has been resolved with 
the help of the document authors, IANA, our AD, and the RPC staff. 
Formally, we have made an early allocation for the code point DDT needs. 
  This gives us two years to get DDT onto the standards track.

2) My recommendation regarding the NAT Traversal would be to leave the 
Info_Request / Info_Reply to the NAT Traversal document.  We can use the 
early allocation approach there if we still deem NAT traversal as 
experimental when we finish it.

3) As far as I can tell, having this document update the references for 
the IANA table seems to be both appropriate and useful.

Yours,
Joel

PS: If we decide that the Standard track requirement for the registry is 
too onerous, we can relax it.  I would prefer not to do so, and it would 
take another RFC, but we can if we have to.

On 5/2/17 4:21 PM, Dino Farinacci wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 2 May 2017 17:34:27 -0700

> 1) With regard to LISP-DDT, the allocation issue has been resolved with the help of the document authors, IANA, our AD, and the RPC staff. Formally, we have made an early allocation for the code point DDT needs.  This gives us two years to get DDT onto the standards track.

Thanks.

> 2) My recommendation regarding the NAT Traversal would be to leave the Info_Request / Info_Reply to the NAT Traversal document.  We can use the early allocation approach there if we still deem NAT traversal as experimental when we finish it.

I’ll remove it.

> 3) As far as I can tell, having this document update the references for the IANA table seems to be both appropriate and useful.

Agree. See new version enclosed. I made the requested changes that Med wanted. Please comment Med.

Dino

---

From: <[email-masked]>
Date: Wed, 3 May 2017 06:12:35 +0000

Hi Dino,

This is better. Thanks.

I would remove the “Not Assigned” from the table because your introduction text is about “codes assigned by this document”.
I would add a note for asking IANA to formally assign type 5.

BTW, did you considered to use type code 4 for both Map-Notify and Map-Notify-Ack given that both messages have the same format and content? This is doable by using a reserved bit as follows:

OLD:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=4/5|             Reserved                 | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NEW:

        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

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |Type=4 |A|            Reserved                 | Record Count  |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A (Ack-bit): MUST be set to 0 for Map-Notify and to 1 for Map-Notify-Ack.

Cheers,

Med

De : Dino Farinacci [mailto:[email-masked]]
Envoyé : mercredi 3 mai 2017 02:34
À : Joel M. Halpern
Cc : BOUCADAIR Mohamed IMT/OLN; [email-masked] list
Objet : Re: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-03.txt

Thanks.

I’ll remove it.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 3 May 2017 09:20:47 -0700

> I would add a note for asking IANA to formally assign type 5.

I will add text to new 7.1 section I added.

> BTW, did you considered to use type code 4 for both Map-Notify and Map-Notify-Ack given that both messages have the same format and content? This is doable by using a reserved bit as follows:

We did not. But it is too late. There are implementations that already exist that use type 5. Also note, the Map-Register has the same format. In fact, all EID records in Map-Register, Map-Notiy, Map-Notify-Ack, and Map-Reply are the same. Ditto for RLOC-records. That is for using common parsing code in implementations.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 3 May 2017 10:18:44 -0700

> I would add a note for asking IANA to formally assign type 5.

See new update to include comment above. I’ll post tomorrow (Thu noon PDT time) if there are no objections.

Dino

---

From: <[email-masked]>
Date: Thu, 4 May 2017 05:56:51 +0000

Hi Dino,

I still have comments to this text:

“Values in the "For Future Assignment" range can be assigned according
                    to procedures in [RFC5226]. »

- replace RFC5226 with RFC8113. Pointing to RFC5226 does not make sense here.
- Your table that summarizes the assigned value includes a “not assigned” entry. I guess “"For Future Assignment" range” in the text above is referring to that entry. If you insist to maintain “not assigned” value in your table, then please use consistent wording in both the table and the text quoted above.

And also to this one in Section 7.1.

   “It is being requested that the IANA be authoritative for LISP Message
                    Type definitions and that it refers to this document as well as
                    [RFC8113] as references.”

- What is the purpose of this text? What actions are you requiring from IANA?

A minor comment about “This document requests IANA to add it to the LISP Message Type Registry.”
- The name of the registry is “LISP Packet Types” not “LISP Message Type”

Thank you.

Cheers,
Med

De : Dino Farinacci [mailto:[email-masked]]
Envoyé : mercredi 3 mai 2017 19:19
À : BOUCADAIR Mohamed IMT/OLN
Cc : Joel M. Halpern; [email-masked] list
Objet : Re: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-03.txt

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 4 May 2017 10:58:02 -0700

>                     to procedures in [RFC5226]. »

Yes it does and it was text added to get RFC6830 published. 

> - replace RFC5226 with RFC8113. Pointing to RFC5226 does not make sense here.

Pointing to 5226 indicates to look in the IANA considerations section. And in that section we make refernece to 8113.

> - Your table that summarizes the assigned value includes a “not assigned” entry. I guess “"For Future Assignment" range” in the text above is referring to that entry. If you insist to maintain “not…

I’ll fix.

> - What is the purpose of this text? What actions are you requiring from IANA?

To reflect Joel’s comment.

> - The name of the registry is “LISP Packet Types” not “LISP Message Type”

Will fix. Thanks.

I will post new documents now with these changes.

Dino

---

From: <[email-masked]>
Date: Fri, 5 May 2017 06:04:34 +0000

Hi Dino, 

Please see inine. 

Cheers,
Med

> Envoyé : jeudi 4 mai 2017 19:58
> Pointing to 5226 indicates to look in the IANA considerations section. And
> in that section we make refernece to 8113.

[Med] I see. Citing RFC5226 is odd then. Either you point to your IANA section in the document or to RFC8113.

> 
> > - Your table that summarizes the assigned value includes a “not
> assigned” entry. I guess “"For Future Assignment" range” in the text above
> is referring to that entry. If you insist to maintain “not assigned” value
> in your table, then please use consistent wording in both the table and
> the text quoted above.
> 
> I’ll fix.
[Med] Thanks.

> To reflect Joel’s comment.

[Med] I'm afraid I don't get this. Unless there is an action that is required from IANA, please remove that text. 

> > - The name of the registry is “LISP Packet Types” not “LISP Message

[Med] Thanks.

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 5 May 2017 09:19:23 -0400

With regard to the IANA considerations, there is an action for IANA. 
They have to update the table to refer to this document for the relevant 
code points.

Yours,
Joel

---

From: <[email-masked]>
Date: Fri, 5 May 2017 13:32:29 +0000

Re-,

I agree. Still, this needs to be said in the text. 

The same comment applies for ACT, ..

Cheers,
Med

> De : Joel Halpern Direct [mailto:[email-masked]]
> Envoyé : vendredi 5 mai 2017 15:19
> À : BOUCADAIR Mohamed IMT/OLN; Dino Farinacci
> Cc : [email-masked] list
> >>> - replace RFC5226 with RFC8113. Pointing to RFC5226 does not make
> sense
> >> here.
> >>
> >>>                     Type definitions and that it refers to this
> document
> >> as well as
> >>> - What is the purpose of this text? What actions are you requiring
> from
> >> IANA?
> >>
> > [Med] I'm afraid I don't get this. Unless there is an action that is
> required from IANA, please remove that text.
> >
> >>
> >>> A minor comment about “This document requests IANA to add it to the
> LISP
> >> Message Type Registry.”