> 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]. 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] > == > > · 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, 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). > 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). > · 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 > > Thank you. > > Cheers, > Med > > De : lisp [mailto:[email protected]] De la part de Dino Farinacci > Envoyé : vendredi 14 avril 2017 20:34 > À : [email protected] list > Objet : [lisp] Fwd: I-D Action: draft-ietf-lisp-rfc6833bis-03.txt > > Folks, since RFC8113 was recently published, I made this small change to > draft-ietf-lisp-rfc6833bis-03: > > <image002.png> > > Thanks, > Dino > > > Begin forwarded message: > > From: [email protected] > Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-03.txt > Date: April 14, 2017 at 11:32:14 AM PDT > To: <[email protected]> > Cc: [email protected] > > > 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/ > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
