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 <farina...@gmail.com> wrote: > > Okay, thanks for the effort. > > Dino > >> On Nov 4, 2016, at 9:15 AM, Anton Smirnov <asmir...@cisco.com> 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 <asmir...@cisco.com> 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 >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >> > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
