Re: [lisp] Review of RFC6833bis
Dino Farinacci <farinacci@gmail.com> Wed, 29 November 2017 01:12 UTC
Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48765128656 for <lisp@ietfa.amsl.com>; Tue, 28 Nov 2017 17:12:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Level:
X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWcMfHV2Ww0K for <lisp@ietfa.amsl.com>; Tue, 28 Nov 2017 17:12:34 -0800 (PST)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11308120724 for <lisp@ietf.org>; Tue, 28 Nov 2017 17:12:34 -0800 (PST)
Received: by mail-ot0-x232.google.com with SMTP id b54so1646478otd.8 for <lisp@ietf.org>; Tue, 28 Nov 2017 17:12:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=j3JMvnh5ANYaGm1yH5+qc10BEqQf+LrwEWClxNDAovA=; b=j3ZffYFbT192OliMkbKJbhbeO90yWtQeLIudtQAwm5AcHA7OYYhM/YRHjSfiYHxQP4 1SJiEAokjLIN/YEoqCl2fsz35loYQ+XbSOnKsLF+wcji1JTPLjU3YaUMYUfN0H6hoY3u MmudGph9OaU2GP4oWCxy1QGbNNEyj+t5gW0PYziCWMi1cLUhZXfNp/a15Vb7yJl844vX Bie2YE79hLkBujUqRWBkoiJQSn3M9rT7gNNbE6hwY70pwbH/iMXsgdBeGf34Oi3MZefj qnV1nfDyI+mtzTcNuHs1MOaS24+9RY26eD2F87PkQkiom3gHn/Wlaj3q001gcYcLCnyF hslw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=j3JMvnh5ANYaGm1yH5+qc10BEqQf+LrwEWClxNDAovA=; b=f0/vFnFVx+qb8gzotsjaYL7+ZsHOgyFTF9qbwlM8UTrtyzmDMQqBXBElpVisBIUcw9 cjSKWnhvqXwUwzxt1d0RhtFnlLlY58DA6KL89+EkYxqvYNTn50pN45m5Xoy16r350B8c 1XF1amFRV6nLNzc3Ib0MRqF84d/LA/btptVKlxumqYiX56gIuA1JrabOiyLu6qYInzM3 so1L5oyfTOOtYX/AumyeP578uMFtbBaG8WWA5IbQ2qKbZZBt64PwRjcSJi7FByCPUdZI 2Tm2zC3dVwPKMfisc3RUTBPF2Ux4QpUTYHxHiuFBAXDOcjuy2ukRNJ00FouUFjMwek0M jj/w==
X-Gm-Message-State: AJaThX49ulXLGa592Yif7l/gu4pB3WgHUUCBr9JkGLTdmbJ90UzqBoSX lNeD3wfIauPntSzCmtgOlU4WB2Uz
X-Google-Smtp-Source: AGs4zMact325LH+YWzNNqmDR69eLYbGhS4pPoM1S766/YyUtc1a3YCG5Vo5NdryeS2kXm3qxjlhcaw==
X-Received: by 10.157.32.130 with SMTP id x2mr1039762ota.198.1511917953172; Tue, 28 Nov 2017 17:12:33 -0800 (PST)
Received: from dino-macbook.attlocal.net (adsl-108-94-3-201.dsl.pltn13.sbcglobal.net. [108.94.3.201]) by smtp.gmail.com with ESMTPSA id w4sm285421ote.21.2017.11.28.17.12.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 17:12:31 -0800 (PST)
From: Dino Farinacci <farinacci@gmail.com>
Message-Id: <2CE690EE-D955-4E50-B17D-6BF31A8622AF@gmail.com>
Content-Type: multipart/mixed; boundary="Apple-Mail=_DBF0C28B-2AF8-4A3E-9415-93AA2CB96858"
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Date: Tue, 28 Nov 2017 17:12:21 -0800
In-Reply-To: <CA+YHcKG3rjZTWExk_yA4iU9A_5DBAGEQmy36+qnYmc7bbzJ+dQ@mail.gmail.com>
Cc: "lisp@ietf.org list" <lisp@ietf.org>, Dino Farinacci <farinacci@gmail.com>
To: Alberto Rodriguez-Natal <rodrigueznatal@gmail.com>
References: <CA+YHcKG3rjZTWExk_yA4iU9A_5DBAGEQmy36+qnYmc7bbzJ+dQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/O6QBYmr6onudQroy8PQLPfAwvIU>
Subject: Re: [lisp] Review of RFC6833bis
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Nov 2017 01:12:39 -0000
> 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 Thanks again Alberto for your comments. See my responses inline and a -07 diff file. > 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. No, they are “control-plane” encapsulated. I’ll make that more clear. > 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.” I reworded. > 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. Can’t do that because an ITR does not get Map-Notifies as a response to a Map-Register. But I will add that ITRs get Map-Notifies to inform them of RLOC-set changes (for pubsub and signal-free-multicast use-cases). > > 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. They did. But the text you identified above was not changed. Changed now. > 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.” Agree. > 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…" I don’t think we should change this. The lig document indicates that a lig client can send Map-Requests. This document is for support of a data-plane. > 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”. Agree. Changed. > 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.” This is not really true. There are too many cases with respect to NAT-traversal that make things more complicated. I think we need to be specific about each message and not generalize it. Plus, Map-Notify messages are response and unsolicited so they vary on whether the destination or source port is 4342. I have added text to identify each message that follow the Map-Request and Map-Reply port rules. > 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? Yes. Added text. > 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 Good point. Generalized the text a bit. > 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. This is not true. The Map-Request has an IP header but it is encapsulated in an ECM and that IP header destination address is the *Map-Resolvers*. > 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. An AFI=0 Is an RLOC address. > 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. Have that covered. > 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). Removed “globally”. I don’t understand your other “Generally” comment. > 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? Yes, because if the Map-Reply returned a more-specific with the less-specific, then it would be replaced so the less-specific replaces the more-specifics that ARE NOT in the Map-Reply. > 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. I don’t follow. Each EID-record will contain a TTL for the length prefix that is encoded. So the new Map-Reply TTL will be used for any length entry (and in this case the more-specific). > 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. It is discussed in the LCAF draft. Don’t want to repeat it. > 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. Not until we identify and describe the use-case. No point to speculate. But note, if a Map-Notify is returned, the nonce should be non-zero. I’ll fix that. > 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? It can. M bit is set to indicate to avoid DDT procedures. The E bit tells the Map-Server what to do with the Map-Request. > 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? No, this is an ECM, not a data-encapsulated control-message. > 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. Agree. > 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. It does following this. I also made the document RFC2119 compliant where the terms for not capitalized. There were a few places. Thanks again, Dino
- [lisp] Review of RFC6833bis Alberto Rodriguez-Natal
- Re: [lisp] Review of RFC6833bis Dino Farinacci
- Re: [lisp] Review of RFC6833bis Alberto Rodriguez-Natal
- Re: [lisp] Review of RFC6833bis Dino Farinacci
- Re: [lisp] Review of RFC6833bis Alberto Rodriguez-Natal
- Re: [lisp] Review of RFC6833bis Victor Moreno (vimoreno)
- Re: [lisp] Review of RFC6833bis Dino Farinacci
- Re: [lisp] Review of RFC6833bis Alberto Rodriguez-Natal
- Re: [lisp] Review of RFC6833bis Dino Farinacci
- Re: [lisp] Review of RFC6833bis Alberto Rodriguez-Natal