Hi Dino, Thank you for replying.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Dino Farinacci [mailto:farina...@gmail.com] > Envoyé : jeudi 27 avril 2017 19:52 > À : BOUCADAIR Mohamed IMT/OLN > Cc : lisp@ietf.org list; Dino Farinacci > Objet : Re: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-03.txt > > > 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, [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. > > > · 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. [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. > > > 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. > > > · 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? [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. > > Dino > > > > > Thank you. > > > > Cheers, > > Med > > > > De : lisp [mailto:lisp-boun...@ietf.org] De la part de Dino Farinacci > > Envoyé : vendredi 14 avril 2017 20:34 > > À : lisp@ietf.org 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: internet-dra...@ietf.org > > Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-03.txt > > Date: April 14, 2017 at 11:32:14 AM PDT > > To: <i-d-annou...@ietf.org> > > Cc: lisp@ietf.org > > > > > > 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 > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
