Dear WG, I did a quick review of rfc6833bis-08. Some comments/suggestions
1. Section 5.8. Encapsulated Control Message Format. There is a reference to LH, it is not spelled out anywhere. I assume this means Lisp Header. 2. Section 5.8. On page 27, there is a figure/header format showing the AD Type and Authentication Data Content, which is not referenced anywhere. Looks like it needs to be removed. 3. Section 8.3/8.4. The text is limited to recommending exclusively a Native Forward action code. However the definition of the Map-reply message in section 5.4 allows 8 possible action codes and specifies 6 possible actions. If the WG agrees I can suggest text that would generalize the recommended processing behaviors described in 8.3 to allow the inclusion and use of the specified actions in the case of NMRs. 8.3. Map-Server Processing Once a Map-Server has EID-Prefixes registered by its client ETRs, it can accept and process Map-Requests for them. In response to a Map-Request (received over the ALT if LISP+ALT is in use), the Map-Server first checks to see if the destination EID matches a configured EID-Prefix. If there is no match, the Map- Server returns a Negative Map-Reply with action code "Natively- Forward" and a 15-minute TTL. This MAY occur if a Map Request is received for a configured aggregate EID-Prefix for which no more- specific EID-Prefix exists; it indicates the presence of a non-LISP "hole" in the aggregate EID-Prefix. Next, the Map-Server checks to see if any ETRs have registered the matching EID-Prefix. If none are found, then the Map-Server returns a Negative Map-Reply with action code "Natively-Forward" and a 1-minute TTL. 8.4 … If the Map-Resolver does not have the mapping entry and if it can determine that the EID is not in the mapping database (for example, if LISP+ALT is used, the Map-Resolver will have an ALT forwarding table that covers the full EID space), it immediately returns a negative LISP Map-Reply, with action code "Natively-Forward" and a 15-minute TTL. To minimize the number of negative cache entries needed by an ITR, the Map-Resolver SHOULD return the least-specific prefix that both matches the original query and does not match any EID-Prefix known to exist in the LISP-capable infrastructure. Regards, -v
_______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
