Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08

[Dino Farinacci <[e-mail]>]

Is there any status on the draft-ietf-lisp-ddt? This document is blocking many other documents in the RFC editor queue.

Dino

> On Nov 4, 2016, at 10:24 AM, Dino Farinacci <[e-mail]> wrote:
> 
> Okay, thanks for the effort.
> 
> Dino
> 
>> On Nov 4, 2016, at 9:15 AM, Anton Smirnov <[e-mail]> wrote:
>> 
>>  Hi Dino,
>> 
>>  given the scope of comments and need for review between authors it may be difficult. We will make an effort to achieve this date but right now I can't guarantee this.
>> 
>> Anton
>> 
>> On Tuesday 01 November 2016 22:55, Dino Farinacci wrote:
>>> Great to hear. Is the goal to publish the new draft on Monday of IETF week?
>>> 
>>> Dino
>>> 
>>>> On Nov 1, 2016, at 11:47 AM, Anton Smirnov <[e-mail]> wrote:
>>>> 
>>>>  Hello Dino,
>>>> 
>>>>  thanks for taking time to answer these concerns. Authors will work on the revised text to incorporate those points.
>>>> 
>>>> Anton
>>>> 
>>>> On Sunday 16 October 2016 22:43, Dino Farinacci wrote:
>>>>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>>>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>>>>> by the IESG for the IETF Chair.  Please treat these comments just
>>>>>> like any other last call comments.
>>>>>> 
>>>>>> For more information, please see the FAQ at
>>>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>>>> 
>>>>>> Document: draft-ietf-lisp-ddt-08
>>>>>> Reviewer: Dale R. Worley
>>>>>> Review Date: 2016-10-09
>>>>>> IETF LC End Date: 2016-10-17
>>>>>> IESG Telechat date: 2016-10-27
>>>>>> 
>>>>>> Summary: This draft is on the right track but has open issues,
>>>>>> described in the review.
>>>>> Thanks for the review Dale. Your comments are outstanding! And your suggestions even better.  ;-)
>>>>> 
>>>>> I am not an author but was involved in the LISP-DDT design early on so I would like to respond to some of your comments. Where I think text should change, I will suggest that to help the authors. To clarify understanding, I will comment inline.
>>>>> 
>>>>> One of the authors will make the changes.
>>>>> 
>>>>>> * In regard to XEIDs:  The concept of XEID unifies the treatment of
>>>>>> DBID, IID, AFI, and EID.  Essentially all of the processing in the
>>>>>> draft is simplified by expressing processing in terms of XEIDs.  For
>>>>>> instance, delegation based on DBID, IID, or AF becomes just a special
>>>>>> case of delegation based on XEID-prefix.  However, it's not clear to
>>>>>> me whether this concept is followed in the text.  For example:
>>>>> Yes, you interpreted the defintion of an extended-EID correctly. It is a multi-tuple entity that has hierarchy so we can delegate any tuple, as well as the tuple itself, downward on the tree.
>>>>> 
>>>>>> In section 3, definition "XEID-prefix" seems to assume that an
>>>>>> XEID-prefix will always contain a complete DBID, IID, and AFI.
>>>>> For a lookup yes. For a delegation, it can be any part of it as I explained above.
>>>>> 
>>>>>> In section 4.2.1:
>>>>>> 
>>>>>>  The root DDT node is the logical "top" of the database hierarchy:
>>>>>>  DBID=0, IID=0, AFI=0, EID-prefix=0/0.
>>>>>> 
>>>>>> But really, the condition of a root node is that it's authoritative
>>>>>> for the *empty* XEID-prefix.
>>>>> Well it is authoriative for everything, by default, but a Map-Referral return code will tell you exactly what it is authoritative for if configured for specficy XEIDs.
>>>>> 
>>>>>> There is also the suggestion here that an AFI of 0 is somehow a
>>>>>> wildcard match for any AFI value.  That is a special case that can be
>>>>>> eliminated by considering the entire XEID to be prefixable.
>>>>> Right, if a delegation is configured with solely the 2-tuple (DBID=0, IID=0), it would be the delegation represents all prefixes in all address families.
>>>>> 
>>>>> We should clarify that in the text.
>>>>> 
>>>>>> On the other hand, this text in 7.3.1 suggests that there is a "null
>>>>>> prefix" which is (or is equivalent) to the XEID-prefix of 0 bits:
>>>>>> 
>>>>>>  the "referral XEID-prefix" is also initialized to the null value
>>>>>>  since no referral has yet been received.
>>>>> I think we don’t need to say how its initialized IMO. We should change text here.
>>>>> 
>>>>>> * In regard to the special fields in XEID, viz., DBID, IID, and AFI,
>>>>>> those need to be described in a way that doesn't leave loose ends, by
>>>>>> either describing how they are expected to be used or referring to a
>>>>>> document that does so.  In this document, a lot of that information is
>>>>>> bundled into the definitions of "Extended EID (XEID)" and
>>>>>> "XEID-prefix" in section 3.  It would be best if this information
>>>>>> appeared in its own paragraphs.
>>>>> Agree. We should make this change.
>>>>> 
>>>>>> It appears to me that it is expected that DBID will always be zero
>>>>>> (see definition "XEID-prefix"), but the machinery is defined so that
>>>>>> other values can be used.
>>>>> Experience has showed us that running parallel mapping databases will be useful. They really don’t need to be numbered or identified because there will be distinct roots and xTRs can connect to one or multiple of them.
>>>>> 
>>>>> And right now, we do not have an encoding for a DBID that can be sent in a Map-Register or Map-Request. So I am agreeing with you.
>>>>> 
>>>>>> IID is presumably expected to be zero except when VPNs are used.  (see
>>>>>> definition "Extended EID (XEID)")
>>>>>> 
>>>>>> Note that definition "Extended EID (XEID)" says "optionally extended
>>>>>> with a non-zero Instance ID".  Read literally, that means that zero
>>>>>> IIDs aren't included in the XEID, which would be insanity.  The text
>>>>>> needs to clarify that IID is always present in the XEID, but is
>>>>>> normally zero.
>>>>> Well no, not insane, if we required IID for every register and request, then the XEID would have the same set of tuples for all lookups. Supplying an IID=0 is not wrong or bad semantically and just cost 32-bits in message space.
>>>>> 
>>>>>> AFI is taken from http://www.iana.org/numbers.html, but you have to go
>>>>>> through the link to draft-ietf-lisp-lcaf to discover that; it should
>>>>>> be stated in this draft.
>>>>> True. Authors use the reference I put in the latest LCAF draft. That was an IESG comment. So we should get it right.
>>>>> 
>>>>>> * For any given delegated prefix, there can be more than one "peer"
>>>>>> DDT nodes that contain duplicated information about the prefix.  But
>>>>>> the term "peer" isn't defined in the lexicon, and there is no explicit
>>>>>> statement that the peers (for a prefix) must contain the same
>>>>>> information.
>>>>> Should be fixed in the text. Thanks.
>>>>> 
>>>>>> * It appears that "Map Server" has been defined elsewhere (RFC 6833),
>>>>>> and that Map Servers can automatically be DDT nodes.  Or is it that
>>>>>> some Map Servers are also equipped with DDT node functionality?  If
>>>>>> this draft places further requirements on Map Server DDT nodes, then
>>>>>> this draft should be noted as updating RFC 6833.
>>>>> Well RFC6833 defines the "bottom-half” of the map-server. That is the interface for Map-Registration. A Map-Server is also a DDT-node when there are map-server-peer configuration so a set of map-servers that are authoritative and have registeration state for the same prefix can include themselves as referrals in Map-Referral messages.
>>>>> 
>>>>>> * There seems to be two meanings of "DDT node".  One is a broad sense,
>>>>>> and is any server that responds to Map-Request.  The other is a narrow
>>>>>> sense, and means any DDT node in the broad sense that is not a Map
>>>>>> Server, and thus is allowed to contain prefix delegations.  These
>>>>>> terms need to be separated, and the uses of "DDT node" in the draft
>>>>>> need to be revised to the correct term.
>>>>> The name “Map-Server” in context to LISP-DDT means that it is a DDT-node at the bottom of the tree with no DDT-node children. It is a DDT-node but one with more functionality, Map-Server functionality according to RFC6833.
>>>>> 
>>>>>> However, the preceding paragraph assumes that a DDT node is not
>>>>>> allowed to contain both prefix delegations and ETR registrations.
>>>>> Correct.
>>>>> 
>>>>>> That seems to be the case because in many places, those classes of
>>>>>> nodes are required to behave differently (e.g., return different error
>>>>>> codes for nonexistent prefixes) and be treated differently by other
>>>>>> DDT nodes (e.g., referrals to them are given with different action
>>>>>> codes).  But there are a few places where the text suggests that a DDT
>>>>>> node could contain both prefix delegations and ETR registrations.
>>>>> All correct. You interpreted the idea exactly.
>>>>> 
>>>>>> * Is it really true that two Map Servers that are authoritative for
>>>>>> the same XEID prefix can contain different sets of ETR registrations?
>>>>> Typically no. The set of ETRs at a LISP site will register all the ETRs RLOCs for the same EID-prefix. Therefore, each map-server, that all ETRs for that site register to, will have the same EID-prefix-to-RLOC-set mapping.
>>>>> 
>>>>>> That is, the DDT client (the Map Resolver) may be required to query
>>>>>> the entire set of peer Map Servers to find the right ETR registration?
>>>>> No, it doens’t have to do that. And it SHOULDN’T that. I can query each referral from a Map-Referral serially or in parallel, only for reachability and robustness reasons.
>>>>> 
>>>>>> Perhaps the answer is defined in the RFC describing Map Servers, but
>>>>>> it affects one's understanding of this draft enough that it should be
>>>>>> stated in the overview.
>>>>> It is a bit. But leaves out specifics to LISP-DDT because Map-Servers can use any “mapping database transport” system.
>>>>> 
>>>>>> * The role of hints is not clear.  Clearly, a DDT node can be
>>>>>> configured with hints regarding some XEID-prefix, but what are the
>>>>>> limitations on what RLOCs must be provided in a hint?  This seems
>>>>> We should have new text to make this more clear.
>>>>> 
>>>>>> especially important because it seems in practice that the
>>>>>> authoritative nodes for a prefix might be reconfigured without anyone
>>>>>> realizing that the hints in nodes farther down the tree need to be
>>>>>> updated.  In particular, when should the DDT client follow a hint?
>>>>>> Hints seem to provide the possibility of circular references.  Given
>>>>>> that this is an Experimental draft, perhaps the best use of hints is
>>>>>> an "open issue and consideration", and by listing it in section 11,
>>>>>> these questions need not be answered now.
>>>>> All good points. Agree.
>>>>> 
>>>>>> 1.  Introduction
>>>>>> 
>>>>>>  LISP offers a general-purpose mechanism for mapping between EIDs and
>>>>>>  RLOCs.  In organizing a database of EID to RLOC mappings, this
>>>>>>  specification extends the definition of the EID numbering space by
>>>>>>  logically prepending and appending several fields for purposes of
>>>>>>  defining the database index key: Database-ID (DBID, 16 bits),
>>>>>>  Instance identifier (IID, 32-bits), Address Family Identifier (16
>>>>>>  bits), and EID-prefix (variable, according to AFI value).  The
>>>>>>  resulting concatenation of these fields is termed an "Extended EID
>>>>>>  prefix" or XEID-prefix.
>>>>>> 
>>>>>> This paragraph is undecided whether it is defining XEID or
>>>>>> XEID-prefix.  Better, I think is to define XEID first and then define
>>>>>> XEID-prefix based on that:
>>>>>> 
>>>>>>  this
>>>>>>  specification extends the definition of the EID numbering space by
>>>>>>  logically concatenating several fields for purposes of
>>>>>>  defining the database index key: Database-ID (DBID, 16 bits),
>>>>>>  Instance identifier (IID, 32-bits), Address Family Identifier (16
>>>>>>  bits), and EID (variable length, according to AFI value).  The
>>>>>>  resulting concatenation of these fields is termed an "Extended EID"
>>>>>>  or XEID.  Prefixes within the XEID space are thus "Extended EID
>>>>>>  prefixes" or XEID-prefixes.
>>>>>> 
>>>>>> —
>>>>> Agree.
>>>>> 
>>>>>>  It
>>>>>>  also provides delegation information to Map Resolvers, which use the
>>>>>>  information to locate EID-to-RLOC mappings.
>>>>>> 
>>>>>> There needs to be clarification regarding the relationship between
>>>>>> "Map Resolver" and "DDT client".  As far as I can tell, in all places
>>>>>> in this document, "DDT client" is the correct term, though it is
>>>>>> expected that most (but not all) DDT clients will be Map Resolvers.
>>>>>> So this text should be something like
>>>>>> 
>>>>>>  It
>>>>>>  also provides delegation information to DDT clients (which are
>>>>>>  usually Map Resolvers, but may be ITRs), which use the
>>>>>>  information to locate EID-to-RLOC mappings.
>>>>>> 
>>>>>> and approximately all uses of "Map Resolver" should be changed to "DDT
>>>>>> client".
>>>>>> 
>>>>>>  LISP-DDT defines a new device type, the DDT node, that is configured
>>>>>>  as authoritative for one or more XEID-prefixes.
>>>>>> 
>>>>>> Here would be a good place to lay out clearly the relationship between
>>>>>> DDT node and Map Server:  whether nodes that do delegation are
>>>>>> disjoint from Map Server nodes, etc.
>>>>> Agree.
>>>>> 
>>>>>> 3.  Definition of Terms
>>>>>> 
>>>>>>  Extended EID (XEID):  a LISP EID, optionally extended with a non-
>>>>>>     zero Instance ID (IID) if the EID is intended for use in a context
>>>>>>     where it may not be a unique value, such as on a Virtual Private
>>>>>>     Network where [RFC1918] address space is used.  See "Using
>>>>>>     Virtualization and Segmentation with LISP" in [RFC6830] for more
>>>>>>     discussion of Instance IDs.
>>>>>> 
>>>>>>  XEID-prefix:  a LISP EID-prefix with 16-bit LISP-DDT DBID (provided
>>>>>>     to allow the definition of multiple databases; currently always
>>>>>>     zero in this version of DDT, with other values reserved for future
>>>>>>     use), 32-bit IID and 16-bit AFI prepended.  Encoding of the
>>>>>>     prefix, its AFI and the instance ID (IID) are specified by
>>>>>>     [I-D.ietf-lisp-lcaf].  An XEID-prefix is used as a key index into
>>>>>>     the database.
>>>>>> 
>>>>>> These can be simplified by moving the details of the XEID format and
>>>>>> the values of the fields into separate paragraphs (as discussed
>>>>>> above).
>>>>>> 
>>>>>>  DDT node:  a network infrastructure component responsible for
>>>>>>     specific XEID-prefix and for delegation of more-specific sub-
>>>>>>     prefixes to other DDT nodes.
>>>>>> 
>>>>>> A DDT node can be authoritative for more than one prefix (see section
>>>>>> 4.2 and section 10, paragraph 2), so "specific XEID-prefix" should be
>>>>>> "specific XEID-prefix(es)".
>>>>>> 
>>>>>>  DDT Map Resolver:  a network infrastructure element that accepts a
>>>>>>     Map-Request, adds the XEID to its pending request list, then
>>>>>>     queries one or more DDT nodes for the requested EID, following
>>>>>>     returned referrals until it receives one with action code MS-ACK
>>>>>>     (or an error indication).  MS-ACK indicates that the Map-Request
>>>>>>     has been sent to a Map Server that will forward it to an ETR that,
>>>>>>     in turn, will provide a Map-Reply to the original sender.  A DDT
>>>>>>     Map Resolver maintains both a cache of Map-Referral message
>>>>>>     results containing RLOCs for DDT nodes responsible for XEID-
>>>>>>     prefixes of interest (termed the "referral cache") and a pending
>>>>>>     request list of XEIDs that are being resolved through iterative
>>>>>>     querying of DDT nodes.
>>>>>> 
>>>>>> This isn't really a definition of what how Map Resolver fits into the
>>>>>> overall scheme, but an outline of Map Resolver processing.  The
>>>>>> description of processing should be moved somewhere else.  Also, any
>>>>>> DDT client that is not a Map Resolver must do the same processing, so
>>>>>> "DDT client" and "DDT Map Resolver" should be merged.
>>>>> I think we should have both.
>>>>> 
>>>>>>  DDT Map-Request:  an Encapsulated Map-Request sent by a DDT client to
>>>>>>     a DDT node.  The "DDT-originated" flag is set in the encapsulation
>>>>>>     header ...
>>>>>> 
>>>>>> Given the importance of Map-Request messages, it might be worth
>>>>>> mentioning that they are defined in RFC 6830.
>>>>> Agree.
>>>>> 
>>>>>> What is the need for the DDT-originated flag?  It seems from the
>>>>>> definition "Encapsulated Map-Request" that EMRs from ITRs to Map
>>>>>> Resolvers never have the flag set, EMRs from Map Resolvers to DDT
>>>>>> nodes (including Map Servers) always have the flag set, and EMRs from
>>>>>> Map Servers to ETRs never have the flag set.  But if that is so, no
>>>>>> type of device can receive EMRs that both have the flag set and not.
>>>>> The flag is to tell the difference between a Map-Request that is originated by a LISP-site (ITR or PITR) and one that is sent by a Map-Resolver. One generates a Map-Reply and the other generates a Map-Referral.
>>>>> 
>>>>>> Hmmm, the exception is if an ITR acts as a DDT client sends a
>>>>>> Map-Request directly to DDT nodes.  But in that case, the DDT nodes
>>>>>> would process the Map-Request in exactly the same way as a Map
>>>>>> Resolver, so there is no need for a "D" flag.
>>>>> That is that the typical case though. Look at it as a Map-Request, with DDT-flag set, as a solitication for a Map-Referral.
>>>>> 
>>>>>> Also, the definition of the flag in section 5 is awkward:
>>>>>> 
>>>>>>  D: The "DDT-originated" flag.  It is set by a DDT client to indicate
>>>>>>     that the receiver SHOULD return Map-Referral messages as
>>>>>>     appropriate.  Use of the flag is further described in
>>>>>>     Section 7.3.1.  This bit is allocated from LISP message header
>>>>>>     bits marked as Reserved in [RFC6830].
>>>>>> 
>>>>>> If the flag *means* "DDT-originated", then the message must have come
>>>>>> from a DDT client, and the receiver MUST return Map-Referral messages
>>>>>> -- that's what this draft is specifying!
>>>>> Correct.
>>>>> 
>>>>>> I get the feeling that the D flat is (or was) intended to work like
>>>>>> the DNS "recursion" flag, it tells whether the client is willing to
>>>>>> accept and follow Map-Referral messages, or whether the client wants
>>>>>> to put that work of following referrals on the server.  But as the
>>>>> It can work that way. Do you think calling the bit “Request-for-Map-Referral” would be better?
>>>>> 
>>>>>> lexicon makes clear, *any* DDT client must be willing to follow
>>>>>> Map-Referral messages, and DDT nodes are *never* required to follow
>>>>>> referrals on behalf of the DDT client.
>>>>> Or we could call the bit “DDT-client-flag”. And still keep the reference to the bit called “D”.
>>>>> 
>>>>>>  Map-Referral:  a LISP message sent by a DDT node in response to a DDT
>>>>>>     Map-Request for an XEID that matches a configured XEID-prefix
>>>>>>     delegation.  A non-negative Map-Referral includes a "referral", a
>>>>>>     set of RLOCs for DDT nodes that have more information about the
>>>>>>     sub-prefix;
>>>>>> 
>>>>>> The phrase "more information" is used in various places, but it is not
>>>>>> really informative.  As far as I can tell, all uses of "DDT nodes that
>>>>> We should say “more specific information”. Where “more-specific” is relative to the xEID-prefix.
>>>>> 
>>>>>> have more information" mean "DDT nodes to which that XEID has been
>>>>>> delegated".  Unless perhaps hints are also considered to point to "DDT
>>>>>> nodes that have more information", in which case the term "more
>>>>>> information" needs to be defined specifically, as it doesn't always
>>>>>> mean a delegation relationship.
>>>>>> 
>>>>>>  Negative Map-Referral:  a Map-Referral sent in response to a DDT Map-
>>>>>>     Request that matches an authoritative XEID-prefix but for which
>>>>>>     there is no delegation configured (or no ETR registration if sent
>>>>>>     by a DDT Map-Server).
>>>>>> 
>>>>>> I'd describe a negative Map-Referral as an answer from an
>>>>>> authoritative DDT node that there is no mapping for the requested
>>>>>> XEID.  That happens because the request is sent to an authoritative
>>>>>> DDT node "but for which there is no delegation configured (or no ETR
>>>>>> registration if sent by a DDT Map-Server)", but the core semantics is
>>>>>> an authoritative denial of a mapping.
>>>>> True. We should have new text to make this more clear.
>>>>> 
>>>>>>  Pending Request List:  the set of outstanding requests for which a
>>>>>>     DDT Map Resolver has received encapsulated Map-Requests from a DDT
>>>>>>     client for an XEID.
>>>>>> 
>>>>>> Is it correct that a DDT Map Resolver can receive Map-Requests from
>>>>>> DDT clients?  I thought a Map Resolver could only receive them from
>>>>> No, not architecturally. It receives only Map-Requests with the DDT-bit set to 0. I say no architecturelly because if the map-resolver is also a map-server, then it could receive DDT Map-Requests. But it is acting as a map-server.
>>>>> 
>>>>> DDT-nodes could also be map-resolvers. Which mean they are part of the delegarion hierarchy but also are configured with DDT-roots to send requests. It all comes down to how a network adminstrator would want to co-locate such functions.
>>>>> 
>>>>> With the popularity of VMs and containers, the same piece of bare-metal could be both a map-resolver and DDT-node, but from a LISP architecture point of view, they are separate nodes (with separate IP addresses).
>>>>> 
>>>>>> ITRs, and a DDT client could only send them to DDT nodes.  If a Map
>>>>>> Resolver can receive requests from other Map Resolvers, there are
>>>>>> complexities of behavior that don't seem to be described in this
>>>>>> draft.
>>>>> DDT-Map-Requests to not get sent to Map-Resolvers and we should make that crystal clear.
>>>>> 
>>>>>> In any case, does this need an entry in the lexicon?  It seems that a
>>>>>> pending request list is an implementation detail and should be
>>>>>> described in the algorithm description sections.
>>>>>> 
>>>>>>  It is important to note that LISP-DDT does not store actual EID-to-
>>>>>>  RLOC mappings; it is, rather, a distributed index that can be used to
>>>>>>  find the devices (Map Servers and their registered EIDs) that can be
>>>>>>  queried with LISP to obtain those mappings.
>>>>>> 
>>>>>> This text defines that Map Servers are not part of DDT, but the
>>>>>> lexicon refers to DDT Map Servers.  And actually, its the ETRs that
>>>>>> store the EID-to-RLOC mappings, not the Map Servers (except when the
>>>>>> Map Server is proxying for the ETR).
>>>>> Map-Servers configured as a DDT-node is definitely part of DDT because they must send MS-ACK based Map-Referrals. Because if this does not happen, then Map-Resolvers will retransmit and think they have not got to the bottom of the referral tree.
>>>>> 
>>>>>> 6.1.  Action codes
>>>>>> 
>>>>>>  MS-ACK (2):  indicates that a replying DDT Map Server received a DDT
>>>>>> 
>>>>>> s/a replying/the replying/
>>>>> Agree.
>>>>> 
>>>>>>  NOT-AUTHORITATIVE (5):  indicates that the replying DDT node received
>>>>>>     a Map-Request for an XEID-request for which it is not
>>>>>>     authoritative.  This can occur if a cached referral has become
>>>>>>     invalid due to a change in the database hierarchy.
>>>>>> 
>>>>>> There's a treacherous case of how hints are returned by a DDT node.
>>>>>> Reading the above definition, it's clear that a hint should be
>>>>>> returned with a NON-AUTHORITATIVE action code, because the node isn't
>>>>>> authoritative for the XEID.  Then again, section 6.1 suggests that
>>>>>> hints are returned as NODE-REFERRAL or MS-REFERRAL.  If so, things get
>>>>>> messy -- How is the DDT client to know that the referral set is a hint
>>>>>> rather than an authoritative delegation?  And that distinction is
>>>>>> necessary because the client can't fully trust hints.
>>>>> To be honest, I am questioning the value of “hint” as a reference. Hmm. Let’s see what the authors think about this.
>>>>> 
>>>>>> 6.3.  Incomplete flag
>>>>>> 
>>>>>>  o  If it is setting action code MS-ACK or MS-NOT-REGISTERED but does
>>>>>>     not have configuration for other "peer" DDT nodes that are also
>>>>>>     authoritative for the matched XEID-prefix.
>>>>>> 
>>>>>> Is this situation equivalent to the referral set being a hint rather
>>>>>> than a delegation?  Or rather, a hint which the DDT node doesn't
>>>>>> believe is the complete peer set for the prefix?  (Is there any way
>>>>>> for a DDT node to know that it has the complete peer set?)  In any
>>>>>> case, it seems to me that this might be usefully changed to "hint
>>>>>> flag".
>>>>>> 
>>>>>> 6.4.  Map-Referral Message Format
>>>>>> 
>>>>>> Is it intended that the "record" and "ref" sections can be repeated?
>>>>>> That is a different usage of bracketing than in the figure in section
>>>>>> 5, and if so, should be described in the text.
>>>>> Agree.
>>>>> 
>>>>>> I note that this section lists all the action codes, as does section
>>>>>> 6.1.  It seems like these should be consolidated into section 6.1.
>>>>>> 
>>>>>> The handling of the "Incomplete" column of the table cannot be
>>>>>> correct.  There is no way for a node to send hints and mark them
>>>>>> Incomplete, and the description at the top of page 12 is incompatible
>>>>>> with the contents of the table.
>>>>> We don’t want to add an additional set of comabinations for hints and non-hints. Authors, we should discuss this.
>>>>> 
>>>>>>  Loc/LCAF-AFI: If this is a Loc AFI, keys SHOULD NOT be included in
>>>>>>  the record.  If this is a LCAF AFI, the contents of the LCAF depend
>>>>>>  on the Type field of the LCAF.  Security material are stored in LCAF
>>>>>>  Type 11.  DDT nodes and Map Servers can use this LCAF Type to include
>>>>>>  public keys associated with their Child DDT nodes for a XEID-prefix
>>>>>>  referral record.  LCAF types and formats are defined in
>>>>>>  [I-D.ietf-lisp-lcaf].
>>>>>> 
>>>>>> This paragraph doesn't make sense in this context.  The terms "Loc",
>>>>>> "keys", "LCAF", "Security material" are all undefined in this context.
>>>>>> 
>>>>>>  Note, though,
>>>>>>  that the set of RLOCs correspond to the DDT node to be queried as a
>>>>>>  result of the referral not the RLOCs for an actual EID-to-RLOC
>>>>>>  mapping.
>>>>>> 
>>>>>> I take it that the "Ref" sections is counted by the "Referral Count"
>>>>>> field, and that the "Loc/LCAF-AFI" and "Locator" fields contain the
>>>>>> RLOCs of the set of DDT nodes that are the referral set.  It might
>>>>>> help the reader to rephrase this sentence in those terms.
>>>>> All this is trying to say (and with too many words), is that the referral-set is stored in a Map-Referral as RLOC-records. That is all.
>>>>> 
>>>>>> 6.4.1.  SIG section
>>>>>> 
>>>>>>  Sig Length: The length of the Signature field.
>>>>>> 
>>>>>> Is this measured in bytes?
>>>>>> 
>>>>>>  Signature: Contains the cryptographic signature that covers the
>>>>>>  entire record.  The Record TTL and the sig fields are set to zero for
>>>>>>  the purpose of computing the Signature.
>>>>> Needs to be fixed in the text.
>>>>> 
>>>>>> It's not clear to me why the Record TTL should be set to zero for
>>>>>> computing the signature, given that you'd want to protect the TTL from
>>>>>> modification.  Also, what is the relationship between Record TTL and
>>>>>> Original Record TTL?  As far as I can tell, no DDT element can receive
>>>>>> a Map-Referral Record from another element and pass it on to a third
>>>>>> element, so there need never be TTL skew between when a record was
>>>>>> signed and when it was sent.
>>>>> The signature covers the complete Map-Referral message. If that is not clear, we will make it clear.
>>>>> 
>>>>>> It seems awkward to compute the signature by first laying out the Sig
>>>>>> section and filling it with zeros when the same benefit could be
>>>>>> obtained by omitting the Sig section from the part of the record whose
>>>>>> signature is calculated.
>>>>> It allows the implementation to be more efficient. You build the message once with the correct length include the signature records, run the hash over it. And then fill in the zero bit fields. That way you can then include the referral addresses that are part of the LCAF.
>>>>> 
>>>>>> Is it a problem that Original Record TTL, Signature Expiration, and
>>>>>> Signature Inception aren't protected by the signature?
>>>>> The entire Map-Referral should be covered by the signature.
>>>>> 
>>>>>> 7.1.1.  Match of a delegated prefix (or sub-prefix)
>>>>>> 
>>>>>>  If the delegation is known to be a DDT Map Server,
>>>>>> 
>>>>>> This seems to assume that either all delegatees are Map Servers or
>>>>>> none are.  All of the processing algorithms seem to presuppose that a
>>>>>> set of peers either are all Map Servers or all are not, but there
>>>>>> doesn't seem to be an explicit requirement of that.
>>>>> See my explanations above.
>>>>> 
>>>>>> 7.1.2.  Missing delegation from an authoritative prefix
>>>>>> 
>>>>>>  If the requested XEID did not match a configured delegation but does
>>>>>>  match an authoritative XEID-prefix, then the DDT node MUST return a
>>>>>>  negative Map-Referral that uses the least-specific XEID-prefix that
>>>>>>  does not match any XEID-prefix delegated by the DDT node.
>>>>>> 
>>>>>> It would be a bit clearer if "the least-specific XEID-prefix" was
>>>>>> changed to "the least-specific prefix of the XEID".
>>>>>> 
>>>>>>  If the requested XEID did not match either a configured delegation or
>>>>>>  an authoritative XEID-prefix, then negative Map-Referral with action
>>>>>>  code NOT-AUTHORITATIVE MUST be returned.
>>>>>> 
>>>>>> I understand what you mean, but this isn't phrased quite right in
>>>>>> regard to hints, because the DDT node may have a hint for an
>>>>>> XEID-prefix that is neither a configured delegation nor within one of
>>>>>> its authoritative XEID-prefixes, but hints are returned with
>>>>>> NODE-REFERRAL.
>>>>> Agree.
>>>>> 
>>>>>> 7.3.  DDT Map Resolver
>>>>>> 7.3.1.  Queuing and sending DDT Map-Requests
>>>>>> 
>>>>>> I think there is an issue around the cache.  Usually (IMHO) when
>>>>>> discussing "resolvers", the "cache" is entirely transient information
>>>>>> that the resolver has acquired from other devices, it doesn't contain
>>>>>> configured information.  But in some places, the draft reads as if the
>>>>> True, in the DDT case as well.
>>>>> 
>>>>>> configured information is permanently present in the cache.  If that
>>>>>> is so, it would help the reader (i.e., this reader!) if when the cache
>>>>>> is introduced that it was stated that the configured delegations (and
>>>>>> hints) are permanently resident in the cache.
>>>>> But that isn’t precisely true. Delegations ARE configuration items, in DDT-nodes, all of roots, ddt-nodes, and map-servers. And the cache is dynamically created entries from Map-Referrals from those node’s configuration information.
>>>>> 
>>>>>> That is, this should be promoted from section 7.3.1 to 7.3 where the
>>>>>> structure (rather than the detailed behavior) of a Map Resolver is
>>>>>> discussed:
>>>>>> 
>>>>>>  The referral cache is initially populated with one or more
>>>>>>  statically-configured entries;
>>>>>> 
>>>>>> Similarly this is a structural statement about the cache:
>>>>>> 
>>>>>>  A DDT Map Resolver is not absolutely required to cache referrals,
>>>>>>  but it doing so decreases latency and reduces lookup delays.
>>>>>> 
>>>>>> --
>>>>>> 
>>>>>>  Note that in normal use on the public Internet, the statically-
>>>>>>  configured initial referral cache for a DDT Map Resolver should
>>>>>>  include a "default" entry with RLOCs for one or more DDT nodes that
>>>>>>  can reach the DDT root node.
>>>>>> 
>>>>>> This suggests that it will be common that a Map Resolver won't be
>>>>>> configured with the RLOCs of the root nodes (which is different from
>>>>> No, they would be.
>>>>> 
>>>>>> the common DNS usage), but rather configured with the RLOCs of nodes
>>>>>> that contain a hint for the null prefix and the root nodes.  (Also,
>>>>>> "can reach" should be changed to "containing hints for".)  If this is
>>>>>> so, then the operation of hints is a central part of the DDT protocol
>>>>>> and (IMO) it would greatly help if the role and processing of hints
>>>>>> was outlined in some location.  In particular, it suggests that all
>>>>>> nodes that are expected to be the initial node for an extensible
>>>>>> population of Map Resolvers SHOULD be configured with a hint for the
>>>>>> root nodes.
>>>>> We have to simplify this wording. It is more complex than it needs to be.
>>>>> 
>>>>>> There is also a possible conflict with section 10 -- the Map Resolver
>>>>>> isn't expected to be configured with the RLOCs of the root servers,
>>>>>> but it is expected to be configured with the public keys of the root
>>>>>> servers.  Indeed, given the language in section 10, the keys can
>>>>> No, both. Because map-resolvers need to know where to send DDT-Map-Requests and when they get signed Map-Referrals, then need a public key to verify the signature. And the reason is beacuse there is no parent of the root that can give the map-resolver the public-key like the rest of the hierarchy can do.
>>>>> 
>>>>>> differ between the various root DDT nodes, which means that in order
>>>>>> to configure the Map Resolver with the public keys of the root
>>>>>> servers, it must be configured with their RLOCs.
>>>>> Yes, yes, yes.
>>>>> 
>>>>>> 7.3.2.  Receiving and following referrals
>>>>>> 
>>>>>>  If the maximum number of retransmissions has occurred and all RLOCs
>>>>>>  have been tried, then the pending request list entry is dequeued.
>>>>>> 
>>>>>> This isn't phrased quite right, because it requires a further
>>>>>> retransmission if "the maximum number of retransmissions has occurred"
>>>>>> but not "all RLOCs have been tried" -- and that would mean sending
>>>>>> more retransmissions than the "maximum number".
>>>>>> 
>>>>>> I believe that the intention is that the Map Resolver must attempt to
>>>>>> contact all relevant RLOCs, but that it must also send at least
>>>>>> "number of retransmissions", meaning that if there are fewer RLOCs
>>>>>> than that number, some RLOCs will be attempted more than once.  If
>>>>>> that is so, then "maximum number" should be "minimum number”.
>>>>> Really good point.
>>>>> 
>>>>>> OTOH, if "maximum number" is intended, then the text should be "If the
>>>>>> maximum number of retransmissions has occurred or all RLOCs have been
>>>>>> tried”.
>>>>> Right.
>>>>> 
>>>>>> Also, this paragraph should specify what response the Map Resolver
>>>>>> should send if processing is terminated due to response time-out.  As
>>>>>> written, the text doesn't require the Map Resolver to send *any*
>>>>>> response, which seems like a bad design.
>>>>> Agree. The Map-Resolver does send a response. If its not documented, we missed it and will add.
>>>>> 
>>>>>>  MS-REFERRAL:  The DDT Map Resolver follows an MS-REFERRAL in the same
>>>>>>     manner
>>>>>> 
>>>>>> It might be better to say "processes" than "follows”.
>>>>> Agree.
>>>>> 
>>>>>>  MS-ACK:  This is returned by a DDT Map Server to indicate that it has
>>>>>>     one or more registered ETRs that can answer a Map-Request for the
>>>>>>     XEID and the request has been forwarded to one of them
>>>>>> 
>>>>>> It's not clear to me how the Map Server or ETR knows the address of
>>>>>> the DDT client to which to send the Map-Reply.  It seems that the
>>>>>> address must be in the Map-Request message, but reading that section
>>>>>> of RFC 6830 doesn't make it clear to me how that is done.
>>>>>> 
>>>>>> The processing regarding MS-ACK is not clear to me.  It would help if
>>>>>> there was an overview discussion of the four-way dance between the DDT
>>>>>> client, the Map Resolver, the Map Server, and the ETR.  (Some times
>>>>>> the Map Server also does the ETR's job.)  Since one step of it is for
>>>>>> the ETR to send Map-Replay to the DDT client, this processing doesn't
>>>>>> break down into separate client/Map Resolver, Map Resolver/Map Server,
>>>>>> and Map Server/ETR components, there's a specific overall structure.
>>>>> You are absolutely right. There needs to be a complete example of the “day in the life of a Map-Request” when the Map-Resolver has nothing cached and the ITR and ETR are not DDT-clients. That is the typical use-case that has been and will continue to be deployed.
>>>>> 
>>>>>> In particular, what happens when a Map Resolver sends a Map-Request to
>>>>>> a Map Server without LISP-SEC information?  It appears that processing
>>>>>> goes through two cycles, with a second cycle when the Map Resolver
>>>>>> re-sends the Map-Request to the Map Server with LISP-SEC information.
>>>>>> The Map Server seems to return MS-ACK messages to the Map Resolver in
>>>>>> both cycles, and there is no special marking in the first MS-ACK
>>>>>> message to indicate that resending must be done (the Map Resolver can
>>>>>> determine that itself).  But presumably, the Map Server forwards the
>>>>>> Map-Request to the ETR in both cycles, and the ETR sends Map-Replys to
>>>>>> the client in both cycles.  Presumably the first Map-Reply is useless
>>>>>> to the client (otherwise there wouldn't need to be two cycles), but
>>>>>> it's not clear how the client deals with two replies.
>>>>> LISP-SEC information is in the Map-Request from the ITR, transported in the DDT-Map-Request so an ETR can get the LISP-SEC information in the Map-Request to then return LISP-SEC in the *Map-Reply*.
>>>>> 
>>>>> The Map-Server only sends Map-Replies when it is configured to proxy-reply and the ETR is not in the loop here. And it would fill in the same LISP-SEC information the ETR would because the registration information is the same as the database entry info the ETR has stored.
>>>>> 
>>>>>>  MS-NOT-REGISTERED:  ...
>>>>>>     The DDT Map Resolver MUST return a negative
>>>>>>     Map-Reply to the original Map-Request sender; this Map-Reply
>>>>>>     contains the non-registered XEID-prefix whose TTL value SHOULD be
>>>>>>     set to one minute.
>>>>>> 
>>>>>> I think "non-registered XEID-prefix" is meant to mean "least-specific
>>>>>> prefix of the XEID for which no registrations exist”.
>>>>> It means the DDT-Map-Request went all the way to the map-server, it has a a configure LISP site entry and the ETRs have not registered (yet).
>>>>> 
>>>>>>  NOT-AUTHORITATIVE:  ...
>>>>>>     The pending request is silently discarded, i.e. all state
>>>>>>     for the request that caused this answer is removed and no answer
>>>>>>     is returned to the original requester.
>>>>>> 
>>>>>> It seems like a poor design to return no response.  Is there not some
>>>>> A response is ALWAYs returned in LISP-DDT. The only time it can’t is when a Map-Request cannot get to where its going or the Map-Referral cannot get back to the DDT-client source. And that is the only case we call a “timeout”.
>>>>> 
>>>>>> sort of "server failure" response that can be returned to the DDT
>>>>>> client?
>>>>>> 
>>>>>> 8.  Pseudo Code and Decision Tree diagrams
>>>>>> 
>>>>>> Care needs to be taken here as to whether the pseudo-code and decision
>>>>>> trees are normative or not.  Generally, algorithms enunciated in RFCs
>>>>>> are marked as non-normative, as the implementation is usually allowed
>>>>>> to deviate from the stated algorithm as long as it satisfies the
>>>>>> constraints written in the text.
>>>>> Agree. We should have new text to make this more clear.
>>>>> 
>>>>>> 9.  Example topology and request/referral following
>>>>>> 
>>>>>>  The same principle
>>>>>>  of hierarchical delegation and pinpointing referrals is equally
>>>>>>  applicable to any AF whose address hierarchy can be expressed as a
>>>>>>  bitstring with associated length.
>>>>>> 
>>>>>> This sentence seems to be redundant because we've been assuming all
>>>>>> along that in any address family used by DDT the address hierarchy is
>>>>>> expressed as bistrings with lengths.
>>>>>> 
>>>>>> Are lines in the diagram intended to cross?  If so, they could be
>>>>>> clarified as:
>>>>> Yes, because each parent points to 2 children.
>>>>> 
>>>>>>     +---------------------+  +---------------------+
>>>>>>     |  root1: 192.0.2.1   |  |  root2: 192.0.2.2   |
>>>>>>     | authoritative: ::/0 |  | authoritative: ::/0 |
>>>>>>     +---------------------+  +---------------------+
>>>>>>                |         \   /        |
>>>>>>                |          \ /         |
>>>>>>                |           X          |
>>>>>>                |          / \         |
>>>>>>                |         /   \        |
>>>>>>                |        |     |       |
>>>>>>                V        V     V       V
>>>>>> +-------------------------+  +--------------------------+
>>>>>> |  DDT node1: 192.0.2.11  |  |  DDT node2: 192.0.2.12   |
>>>>>> |     authoritative:      |  |      authoritative:      |
>>>>>> |      2001:db8::/32      |  |       2001:db8::/32      |
>>>>>> +-------------------------+  +--------------------------+
>>>>>>                |         \   /        |
>>>>>>                |          \ /         |
>>>>>>                |           X          |
>>>>>>                |          / \         |
>>>>>>                |         /   \        |
>>>>>>                |        |     |       |
>>>>>>                V        V     V       V
>>>>>> +--------------------------+  +---------------------------+
>>>>>> | Map-Server1: 192.0.2.101 |  |  DDT node3: 192.0.2.201   |
>>>>>> |      authoritative:      |  |      authoritative:       |
>>>>>> |    2001:db8:0100::/40    |  |    2001:db8:0500::/40     |
>>>>>> | site1: 2001:db8:0103::/48|  +---------------------------+
>>>>>> | site2: 2001:db8:0104::/48|     |                    |
>>>>>> +--------------------------+     |                    |
>>>>>>                                 |                    |
>>>>>>                                 |                    |
>>>>>>                                 V                    V
>>>>>>          +---------------------------+   +---------------------------+
>>>>>>          | Map-Server2: 192.0.2.211  |   | Map-Server3: 192.0.2.221  |
>>>>>>          |      authoritative:       |   |      authoritative:       |
>>>>>>          |    2001:db8:0500::/48     |   |    2001:db8:0501::/48     |
>>>>>>          |site3: 2001:db8:0500:1::/64|   |site5: 2001:db8:0501:8::/64|
>>>>>>          |site4: 2001:db8:0500:2::/64|   |site6: 2001:db8:0501:9::/64|
>>>>>>          +---------------------------+   +---------------------------+
>>>>>> 
>>>>>> 
>>>>>> 10.  Securing the database and message exchanges
>>>>>> 
>>>>>>  Each DDT node is configured with one or more public/private key
>>>>>>  pair(s) that are used to digitally sign referral records for XEID-
>>>>>>  prefix(es) that the DDT node is authoritative for.  In other words,
>>>>>>  each public/private key pair is associated with the combination of a
>>>>>>  DDT node and the XEID-prefix that it is authoritative for.
>>>>>> 
>>>>>> s/the XEID-prefix/an XEID-prefix/
>>>>> Agree.
>>>>> 
>>>>>> But the first sentence doesn't say the same thing as the second
>>>>>> sentence.  Better would be
>>>>>> 
>>>>>>  Each DDT node is configured with one or more public/private key
>>>>>>  pairs for each XEID-prefix that it is authoritative for, and those
>>>>>>  keys are used to sign referral records for XEID-prefixes within the
>>>>>>  authoritative XEID-prefix.
>>>>> Agree.
>>>>> 
>>>>>> Also, there should be some text as to whether a node is required to
>>>>>> sign a referral record with *all* of its keys.  And in general, there
>>>>>> should be some discussion of the significance and use of multiple keys
>>>>>> for a single DDT node/authoritative prefix.
>>>>> Really good point. I definitely agree.
>>>>> 
>>>>>>  Every DDT
>>>>>>  node is also configured with the public keys of its children DDT
>>>>>>  nodes.  By including public keys of target child DDT nodes in the
>>>>>>  Map-Referral records, and signing each record with the DDT node's
>>>>>>  private key, a DDT node can securely delegate sub-prefixes of its
>>>>>>  authoritative XEID-prefixes to its children DDT nodes.
>>>>>> 
>>>>>> Does a DDT node have the public keys of the DDT nodes that its hints
>>>>>> point to?  If not, hints can't be trusted and followed in the same way as
>>>>>> "downward" Map-Referrals, which breaks the trust sequence if the DDT
>>>>>> client is not configured with the keys of the RLOCs in the hint.
>>>>> It should yes.
>>>>> 
>>>>>> Also, how does the DDT node return public keys to the Map Resolver?  I
>>>>>> don't see any field for it in the Map-Referral message.
>>>>> An RLOC record contains LCAF type 11 with the RLOC/address of the referral and key material.
>>>>> 
>>>>>> 11.  Open Issues and Considerations
>>>>>> 
>>>>>>  o  Management of the DDT Map Resolver referral cache, in particular,
>>>>>>     detecting and removing outdated entries.
>>>>>> 
>>>>>> I assume that this means "the definition and use of TTL values",
>>>>>> because the use of TTL values does not seem to be completely described
>>>>>> in this document.  Perhaps this item could be rephrased to mention TTL
>>>>>> explicitly.
>>>>> Agree.
>>>>> 
>>>>>> 13.  Security Considerations
>>>>>> 
>>>>>>  For this reason, when
>>>>>>  LISP-SEC is deployed in conjunction with a LISP-DDT mapping database
>>>>>>  and the path between Map-Resolver and Map-Server needs to be
>>>>>>  protected, DDT security should be enabled as well.
>>>>>> 
>>>>>> This sentence is obscure, because "DDT security" is not defined
>>>>>> anywhere, and there seems to be no optional security mechanism
>>>>>> described in the draft.
>>>>> We have referred to LISP-DDT-SEC to mean the public/private key signing of Map-Referral messages. That is what the reference to DDT security could mean. But this section could be confidentiality support as well.
>>>>> 
>>>>>> 14.2.  Informative References
>>>>>> 
>>>>>>  [I-D.ietf-lisp-lcaf]
>>>>>>             Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
>>>>>>             Address Format (LCAF)", draft-ietf-lisp-lcaf-13 (work in
>>>>>>             progress), May 2016.
>>>>>> 
>>>>>> The reference to ietf-lisp-lcaf in the definition "XEID-prefix" in
>>>>>> section 3 seems to be normative (unless the text in this draft is
>>>>>> adjusted to consider XEIDs as undifferentiated bit strings).
>>>>> Should be normative since we are about to publish the LCAF RFC.
>>>>> 
>>>>>>  [LISP-TREE]
>>>>>>             Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D.,
>>>>>>             and O. Bonaventure, "LISP-TREE: a DNS hierarchy to support
>>>>>>             the lisp mapping system", Selected Areas in
>>>>>>             Communications, IEEE Journal , 2010,
>>>>>>             <http://ieeexplore.ieee.org/xpls/
>>>>>>             abs_all.jsp?arnumber=5586446>.
>>>>>> 
>>>>>> This reference is not referenced.
>>>>>> 
>>>>>>  [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
>>>>>>             Standards (PKCS) #1: RSA Cryptography Specifications
>>>>>>             Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
>>>>>>             2003, <http://www.rfc-editor.org/info/rfc3447>.
>>>>>> 
>>>>>> The reference to RFC 3447 in section 6.4.1 seems to be normative, as
>>>>>> the specifics of RSA-SHA1 signatures come from this RFC.
>>>>> Agree.
>>>>> 
>>>>>> Dale
>>>>> Thanks again for the really detailed comments.
>>>>> 
>>>>> Dino
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> lisp mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/lisp
>> 
>