Re: [lisp] Review of RFC6833bis
Dino Farinacci <farinacci@gmail.com> Wed, 29 November 2017 21:36 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 24A6B126CD6 for <lisp@ietfa.amsl.com>; Wed, 29 Nov 2017 13:36:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 YCeSssorrSyn for <lisp@ietfa.amsl.com>; Wed, 29 Nov 2017 13:36:18 -0800 (PST)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 59875124239 for <lisp@ietf.org>; Wed, 29 Nov 2017 13:36:18 -0800 (PST)
Received: by mail-pf0-x22c.google.com with SMTP id a90so2160552pfk.1 for <lisp@ietf.org>; Wed, 29 Nov 2017 13:36:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=81DcdDn4c7wHosFFvt5uxUfy94f8F1JwB6vAIvVUcWo=; b=DYHeiBhTHjKTggm7WDkYfzA/F1Izh3YDB8kWim7gVeuLFtXyJr3M4bZjzuf8upx95T c4uzji0vbMsJ1qkLb9I4YfRNGFRVIoMgV4TyW8GYy8EEYSni/i5cwdnBNlUpiU2veQqG wujS2v9fsKERCejKpJ6mpJqJHf1fAbyUnsqtcE0jxNcRn3zm6HBbD+o9k1lu2Kr1rLro zCFZZwO/2wAFtlD/KMbQjOxlgqUtKzlGhtSQoOK20An0D3CJx3QbFVHMmw36cAjlLURX 455SCmZjlA4TaAsSCI4rEssOYvKhcy45YIz0RGZGBNTe9sduOl0OIrOtClxnfP2LxpHb xGUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=81DcdDn4c7wHosFFvt5uxUfy94f8F1JwB6vAIvVUcWo=; b=Y9scSGJUBZBTAeGoHXVLK+0/abofjeKTKTBomQ/2CJw/Z/pjc2HKdT47PbhzR4C1z3 L4n2WgbBOWbh7kGmiIhoyGBdOgYTP2SpyW5OnyzlMjJavq6J6XJsNRLDXLMG3WvYVSn7 ng2o04lRVo9/AB79kUeKAKuBZsq1ivcZTwhQ/+iTvR9mm40iU4rjnjLgGLzQdIgG8+Ba tzp3Eu6Y/csZ8/K4dSSQk2qUMzpNQzmzYkeg+9C4u98LFOExilvB2m4TJ4sJntCaFqNO 1GDIyNkW0XkbfZ++0jRBVttLRd2UFgOKA2Jp/XypUJriEukDwalwV+Hxil3gwcl+na6O jhZg==
X-Gm-Message-State: AJaThX670W3bY1NLXPqlbnIiVPRKF3ma376sI7+4/QoIX7+QsIwm1Mhn ZGHXy5hRGJlFJc+gtDIyh8s=
X-Google-Smtp-Source: AGs4zMaSLY3Jioun1w2rYxVhVyETi9nrAd+qI5yoZzlaV2+L1X4Wu9yAoyHFmKJnvNCyblFvv1ke8Q==
X-Received: by 10.101.78.2 with SMTP id r2mr285083pgt.320.1511991377315; Wed, 29 Nov 2017 13:36:17 -0800 (PST)
Received: from dino-macbook.lan (c-67-180-23-75.hsd1.ca.comcast.net. [67.180.23.75]) by smtp.gmail.com with ESMTPSA id d6sm4791032pfc.29.2017.11.29.13.36.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 13:36:16 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <53F582DF-33D8-41BF-94F4-CCE65D6C7908@cisco.com>
Date: Wed, 29 Nov 2017 13:36:15 -0800
Cc: "lisp@ietf.org list" <lisp@ietf.org>, Alberto Rodriguez-Natal <rodrigueznatal@gmail.com>, Dino Farinacci <farinacci@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <36D472D5-8E64-4CB7-A98F-60C850724974@gmail.com>
References: <CA+YHcKG3rjZTWExk_yA4iU9A_5DBAGEQmy36+qnYmc7bbzJ+dQ@mail.gmail.com> <2CE690EE-D955-4E50-B17D-6BF31A8622AF@gmail.com> <CA+YHcKH8tmw_06GRXKDRCEXcwipWRCQ3Fmm02wd4tB_-PUX8rQ@mail.gmail.com> <53F582DF-33D8-41BF-94F4-CCE65D6C7908@cisco.com>
To: Victor Moreno <vimoreno@cisco.com>
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/tDHLhx6gTGv-HySbeS-yPKpPtQA>
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 21:36:22 -0000
> On Nov 29, 2017, at 11:09 AM, Victor Moreno (vimoreno) <vimoreno@cisco.com> wrote: > > In addition to the comments provided by Alberto and Dino, I have some comments on the text in section 5 of the RFC. > > 1. The text in section 5 currently prescribes that in response to a map-request for a non-registered or non-existent EID, an ITR should expect an NMR from the Map-Server (or Resolver) with action code “Natively-Forward” (this is stated in section 5.1 and re-stated in 5.3 and 5.4). Prescribing that this is to always be an NMR with a Native-Forward action is limiting. I can go along with this Victor. I would like to hear what the working group says about this. See technical details below. I have also asked myself the question many times if we need or should distinguish between not-registered or not-assigned. We did this in DDT with Map-Referrals but not in negative Map-Replies. The problem with “not-assigned” is that a big EID-prefix block may be configured in a map-server with “accept-more-specifics” semantics. Which means you don’t know if the more specifics are assigned or not. So what would always be returned is a “not-registered” action. So I think we could introduce this, I think in practice it could never be used. And as you say a negative prefix that is built for a hole that needs to point to a PETR, is that a EID-prefix or not? So it would be hard to distinguish between not-assigned here versus not-registered unless the EID-record had a flag that said what is being registered. > After trying to address a few use cases, it would be very useful if the specification allowed: > > a. As an alternative to responding with an NMR, an implementation may respond to a Map-Request for a non-registered or non-existent EID with a “positive" map-reply inclusive of an RLOC-set that can be configured in the Mapping-System. The immediate use case this would address is that of not having to configure a PETR statically at every ITR, but have the map-replies include the PETR's RLOC information. This Map-Reply should have short TTLs and include covering/hole EID prefixes just as specified for the current NMRs, hence this differs from a map-reply for registered 0/0 EIDs. Why configure a map-server with something it may not have control over. An mapping system provider may not be associaed with data-plane provider, so it unilaterally (or even if agreed upon) should register *to itself*. There is no reason why the data-plane provider register any length EID-prefix with any RLOC-set it determines. Then a LISP site just encapsulates. The architecture already supports this. > b. The use of all action codes possible with the ACT bits (as defined in section 4.4) when Map-Replying with an NMR to a Map-Request for a non-registered or non-existent EID. As I read the text in section 5, it isn’t clear that other action codes are allowed, the text is focused solely on Natively-Forward, there are strong requirements to leverage the Drop action and particularly Drop/Policy-Denied. As well as Auth-Failure. I can make this more clear in the section describing the ACT bits. > 2. There are multiple references to LISP-ALT in the text. Do we want to keep those references moving forward? Or can these be removed? The implementations I work with do not use ALT, but maybe there are others that do? Since LISP-ALT and LISP-DDT are the only RFC’ed mapping database transport systems, we should include both IMO. What do you think? We have done this for other areas as well. > 3. Section 5.3. Paragraph 2 is describing the behavior for the MS when there is a match on an EID “hole”. Section 5.3. suggests a 15 minute TTL, meanwhile section 5.1. suggests a 1 minute TTL for the same EID. I think it should be 1 minute in both cases. Will fix. > I can contribute with text suggestions once we discuss the above on the list. Thanks for that. If you want to take a crack at (b) above that would be great. Dino > > -v > > >> On Nov 29, 2017, at 10:04 AM, Alberto Rodriguez-Natal <rodrigueznatal@gmail.com> wrote: >> >> Thanks for the responses Dino. I'll get back to you later this week. >> >> Alberto >> >> On Tue, Nov 28, 2017 at 5:12 PM, Dino Farinacci <farinacci@gmail.com> wrote: >>>> 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 mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >
- [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