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: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
