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

[<[e-mail]>]

Hi Dino,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Dino Farinacci [mailto:[e-mail]]
> Envoyé : vendredi 28 avril 2017 19:53
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [e-mail] 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