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

From: [email-masked]
Date: Fri, 14 Apr 2017 11:32:14 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Locator/ID Separation Protocol of the IETF.

        Title           : Locator/ID Separation Protocol (LISP) Control-Plane
        Authors         : Vince Fuller
                          Dino Farinacci
                          Albert Cabellos
	Filename        : draft-ietf-lisp-rfc6833bis-03.txt
	Pages           : 38
	Date            : 2017-04-14

Abstract:
   This document describes the Control-Plane and Mapping Service for the
   Locator/ID Separation Protocol (LISP), implemented by two new types
   of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server
   -- that provides a simplified "front end" for one or more Endpoint ID
   to Routing Locator mapping databases.

   By using this control-plane service interface and communicating with
   Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and
   Egress Tunnel Routers (ETRs) are not dependent on the details of
   mapping database systems, which facilitates modularity with different
   database designs.  Since these devices implement the "edge" of the
   LISP infrastructure, connect directly to LISP-capable Internet end
   sites, and comprise the bulk of LISP-speaking devices, reducing their
   implementation and operational complexity should also reduce the
   overall cost and effort of deploying LISP.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-03
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6833bis-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6833bis-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 14 Apr 2017 11:33:44 -0700

Folks, since RFC8113 was recently published, I made this small change to draft-ietf-lisp-rfc6833bis-03:

Thanks,
Dino

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-03.txt
> Date: April 14, 2017 at 11:32:14 AM PDT
> To: <[email-masked]>
> Cc: [email-masked]
> 
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: <[email-masked]>
Date: Thu, 27 Apr 2017 08:52:47 +0000

Hi Dino, all,

Thank you for sharing this update.

I have some comments about the following text:

==
   This section will be the authoritative source for allocating LISP
   Type values and for defining LISP control message formats.  For
   Shared Extension types, see [RFC8113<https://tools.ietf.org/html/rfc8113>].  Current allocations 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 Map-Notify-Ack:               5     b'0101'
    LISP Map-Referral:                 6     b'0110'
    LISP Info-Request/Reply:           7     b'0111'
    LISP Encapsulated Control Message: 8     b'1000'
    Not Assigned                       9-14  b'1001'- b'1110'
    LISP Shared Extension Message:     15    b'1111'           [RFC8113<https://tools.ietf.org/html/rfc8113>]
==

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

·         An IANA section is to be added to the bis document.

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

·         "LISP Map-Notify-Ack:               5     b'0101'" and "LISP Info-Request/Reply:           7     b'0111'" are not assigned yet by IANA. The document should include requests in the new IANA section; these values can be indicated as preferred values according to RFC8113:

   The values in the ranges 5-7 and 9-14 can be assigned via Standards

   Action [RFC5226<https://tools.ietf.org/html/rfc5226>].  Documents that request for a new LISP packet type

   may indicate a preferred value in the corresponding IANA sections.

·         "LISP Map-Referral:      6     b'0110'" is about a temporary assignment not a permanent one.

·         The document may include a discussion about the exhaustion of type values. That discussion can remind the reader that an extended space is provisioned for that purpose : "15.subtype(0-1023)".

·         The document should IMO include some text to encourage designers to use the "15.subtype(1024-4095)" in early stages of extension specifications. The WG will decide whether a type code will be assigned in the standard track ranges.

Thank you.

Cheers,
Med

De : lisp [mailto:[email-masked]] De la part de Dino Farinacci
Envoyé : vendredi 14 avril 2017 20:34
À : [email-masked] list
Objet : [lisp] Fwd: I-D Action: draft-ietf-lisp-rfc6833bis-03.txt

Thanks,
Dino

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-03.txt
Date: April 14, 2017 at 11:32:14 AM PDT
To: <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>

Abstract:

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 Apr 2017 10:51:39 -0700

>    Shared Extension types, see [RFC8113].  Current allocations are:
>  
>     Reserved:                          0     b'0000'
>     LISP Shared Extension Message:     15    b'1111'           [RFC8113]
> ==
>  

No, not really. RFC6833bis is authoritative for LISP Type values, RFC8113 is authoriative for Type 15 sub-type values.

> ·         An IANA section is to be added to the bis document.

Yes, I can do that since the packet formats moved from RFC6830 to RFC6833bis.

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

> ·         “LISP Map-Notify-Ack:               5     b'0101'” and “LISP Info-Request/Reply:           7     b'0111'” are not assigned yet by IANA. The document should include requests in the new IANA section; these values can be indicated as preferred values according to RFC8113:

I will do that for Map-Notify-Ack since it is part of standard protocol. I cannot do it for type 7 since the NAT-traversal is not a working group document (yet).

>    Action [RFC5226].  Documents that request for a new LISP packet type

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

> ·         The document may include a discussion about the exhaustion of type values. That discussion can remind the reader that an extended space is provisioned for that purpose : “15.subtype(0-1023)”.

It may but should it? Why don’t we cross that bridge when we come to it?

> ·         The document should IMO include some text to encourage designers to use the “15.subtype(1024-4095)” in early stages of extension specifications. The WG will decide whether a type code will be assigned in the standard track ranges.

I will add that. Thanks.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Apr 2017 14:36:43 -0400

It is unusual for an RFC to refer to itself as authoritative.  It is 
also not particularly helpful to use those words.
In particular, values from the range 9 - 14 may be assigned by other 
standards action without updating 6833bis.
(side-note, there is an long ongoing discussion on the IETF and 
rfc-interest list as to when documents should be marked as updating 
other documents.  I am refering here to actual updates, rather than to 
any question of marking the metadata.)

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 Apr 2017 11:39:23 -0700

> It is unusual for an RFC to refer to itself as authoritative.  It is also not particularly helpful to use those words.

Then please provide direction and more importantly words. 

> In particular, values from the range 9 - 14 may be assigned by other standards action without updating 6833bis.

So should we keep it?

> (side-note, there is an long ongoing discussion on the IETF and rfc-interest list as to when documents should be marked as updating other documents.  I am refering here to actual updates, rather than to any question of marking the metadata.)

Please advise what to do. Or more to theh point, can you respond to each of Mohamed’s comments providing your opinion?

Dino

---

From: <[email-masked]>
Date: Fri, 28 Apr 2017 05:55:24 +0000

Hi Dino,

Thank you for replying.

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Dino Farinacci [mailto:[email-masked]]
> Envoyé : jeudi 27 avril 2017 19:52
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked] list; Dino Farinacci
> Objet : Re: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-03.txt
> 
> > Hi Dino, all,
> >
> > ·         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. 

 RFC8113
> is authoriative for Type 15 sub-type values.

[Med] Not only for that, but also for allocating future type values. 

> Yes, I can do that since the packet formats moved from RFC6830 to

[Med] Thank you. Please list the type values to be assigned by IANA.

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

> 
> > ·         “LISP Map-Notify-Ack:               5     b'0101'” and “LISP
> Info-Request/Reply:           7     b'0111'” are not assigned yet by IANA.
> The document should include requests in the new IANA section; these values
> can be indicated as preferred values according to RFC8113:
> 
> I will do that for Map-Notify-Ack since it is part of standard protocol.

[Med] Ok, thanks.

 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.  

> No it is permanent because LISP-DDT is progressing to RFC (standards

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

> 
> > ·         The document may include a discussion about the exhaustion of
> type values. That discussion can remind the reader that an extended space
> is provisioned for that purpose : “15.subtype(0-1023)”.
> 

[Med] Perhaps, this will be trivial to cross that bridge, but I prefer to include an explicit sentence into the bis to call it out.    

> 
> > ·         The document should IMO include some text to encourage
> designers to use the “15.subtype(1024-4095)” in early stages of extension
> specifications. The WG will decide whether a type code will be assigned in
> the standard track ranges.
> 
> I will add that. Thanks.
[Med] Thank you.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 28 Apr 2017 10:52:42 -0700

> Thank you for replying.

See responses. I cut out some email where I had no response.

> [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] Not only for that, but also for allocating future type values. 

RFC8113 should not be used for future Type values. Only for sub-type values for Type 15. Beacuse that is what the RFC documents.

> [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] 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] 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…

That is going to change in the coming weeks since LISP-DDT is about to come to RFC 8111.

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

Thanks,
Dino