Hi all,
Wanted to send this before the meeting on Friday. I just completed a
review of 6833bis, you can find my comments below. Like last time,
extracts from the draft are copied and followed by my comments.
Thanks,
Alberto
Map-Resolver: A network infrastructure component that accepts LISP
Encapsulated Map-Requests,
• [AR] We could remove "Encapsulated" and just use "Map-Requests".
A Map-Resolver may accept non-encapsulated Map-Requests as well.
Map-Register message: A LISP message sent by an ETR to a Map-Server
to register its associated EID-Prefixes. In addition to the set of
EID-Prefixes to register, the message includes one or more RLOCs to be
used by the Map-Server when forwarding Map-Requests (re-formatted as
Encapsulated Map-Requests) received through the database mapping
system.
• [AR] This may give the impression that the RLOCs on the
Map-Register are only to forward Map-Requests, which is not the case
in proxy-reply mode. I would suggest we rephrase this text as follows:
"In addition to the set of EID-Prefixes to register, the message
includes one or more RLOCs to be used to reach the ETR. The Map-Server
uses these RLOCs when it has to forward Map-Requests (potentially
re-formatted as Encapsulated Map-Requests) received through the
database mapping system."
Map-Notify message: A LISP message sent by a Map-Server to an ETR
• [AR] I would replace "ETR" with "xTR" so we cover the PubSub
behavior as well.
For definitions of other terms -- notably Map-Request, Map-Reply,
Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please
consult the LISP specification [I-D.ietf-lisp-rfc6830bis].
• [AR] I think that the definitions for Map-Request and Map-Reply
should be moved here, and probably we should include the definition
for Map-Notify-Ack as well. 6830bis should reference 6833bis for
control-plane messages, not the other way around.
A Map-Register message contains a list of EID-Prefixes plus a set of
RLOCs that can be used to reach the ETR when a Map-Server needs to
forward a Map-Request to it.
• [AR] Since proxy-reply is a common case, I'd not constrain the
meaning of the RLOCs in the Map-Register. I'd remove the last part of
the sentence that says "when a Map-Server needs to forward a
Map-Request to it."
A Map-Resolver receives Encapsulated Map-Requests from its client ITRs
and uses a mapping database system to find the appropriate ETR to
answer those requests.
• [AR] A MR can receive Map-Requests that don't come from ITR
and/or that are not encapsulated. If we don't want to change the text,
at least I'd add at the beginning: "In a common scenario, a
Map-Resolver..."
Note that while it is conceivable that a non-LISP-DDT Map-Resolver
could cache responses to improve performance,
• [AR] The discussion on caching or not at the Map-Resolver goes
beyond DDT. We could rephrase this removing the mention to
"non-LISP-DDT".
The LISP UDP-based messages are the Map-Request and Map-Reply
messages. When a UDP Map-Request is sent, the UDP source port is
chosen by the sender and the destination UDP port number is set to
4342. When a UDP Map-Reply is sent, the source UDP port number is set
to 4342 and the destination UDP port number is copied from the source
port of either the Map-Request or the invoking data packet.
• [AR] I would remove the first sentence and re-phrase this
paragraph as follows: "When a UDP LISP control message is sent and is
not a direct reply to a previous control message, the UDP source port
is chosen by the sender and the destination UDP port number is set to
4342. When a UDP LISP control message is sent as a direct reply to a
previous message, the source UDP port number is set to 4342 and the
destination UDP port number is either set to 4342 or copied from the
source port of the invoking LISP control message. See the following
subsections for details."
The UDP checksum is computed and set to non-zero for Map-Request,
Map-Reply, Map-Register, and Encapsulated Control Message (ECM)
control messages.
• [AR] Shouldn't it be computed for all LISP control messages?
EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16
octets for an IPv6 address family. When a Map-Request is sent by an
ITR because a data packet is received for a destination where there is
no mapping entry, the EID-Prefix is set to the destination IP address
of the data packet, and the 'EID mask-len' is set to 32 or 128 for
IPv4 or IPv6, respectively.
• [AR] We should probably rephrase this to don't limit it to IPv4/6
For the latter two cases, the destination IP address used for the
Map-Request is one of the RLOC addresses from the Locator-Set of the
Map-Cache entry.
• [AR] To refresh map-caches before TTL expiration, the
destination IP of the Map-Request can be the address of the Map-Server
if in proxy-reply. This should be considered here.
If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier
MUST drop the Map-Request.
• [AR] This could probably be a SHOULD since we use AFI = 0 as
ITR-RLOC to unsubscribe in PubSub.
EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16
octets for an IPv6 address family.
• [AR] We should mention the possibility for address families
other than IPv4/6.
The RLOCs in the Map-Reply are globally routable IP addresses of all
ETRs for the LISP site.
• [AR] We should remove "globally" here. Maybe also add a
"Generally" at the beginning since we might have LCAFs with AFI = 0
(LISP-VPN encoding of Home-IID for instance).
For example, a requester with two cached EID-Prefixes that are covered
by a Map-Reply containing one less-specific prefix replaces the entry
with the less-specific EID-Prefix.
• [AR] Not sure if I follow here. Does this mean that a
less-specific received in a Map-Reply will erase from the map-cache
previously cached more-specifics that are covered by the
less-specific?
When more than one EID-Prefix is returned, all SHOULD use the same
Time to Live value so they can all time out at the same time. When a
more-specific EID-Prefix is received later, its Time to Live value in
the Map-Reply record can be stored even when other less-specific
entries exist.
• [AR] We should explain in which cases a more-specific can be
received later.
The Locator-Set MUST be sorted in order of ascending IP address where
an IPv4 locator address is considered numerically 'less than' an IPv6
locator address.
• [AR] LCAF addresses (maybe with AFI=0) should be discussed here as well.
Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register messages.
• [AR] Since there may be future cases that benefit from having a
non-zero nonce on the Map-Register, I would suggest to rephrase this
sentence to add a CAN.
E: This is the to-ETR bit. When set to 1, the Map-Server's intention
is to forward the ECM to an authoritative ETR.
• [AR] Can M and E be set at the same time?
LCM: The format is one of the control message formats described in
this section. At this time, only Map-Request messages are allowed to
be encapsulated.
• [AR] Shall we mention the NAT traversal draft?
A Map-Server's configuration must also include a list of the
EID-Prefixes for which each ETR is authoritative.
• [AR] There may be certain cases where this does not need to be
pre-configured. I suggest we replace the "must" with a "should". Note
that this requirement is already a "should" in section 6.
See [I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server sets
certain flags (such as those indicating whether the message is
authoritative and how returned Locators should be treated) when
sending a Map-Reply on behalf of an ETR.
• [AR] It may be useful to discuss at least some of those details here.
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
