Okay, thanks for the effort. Dino
> On Nov 4, 2016, at 9:15 AM, Anton Smirnov <[email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
