Re: [lisp] 6830bis Review
Albert Cabellos <albert.cabellos@gmail.com> Wed, 27 December 2017 01:48 UTC
Return-Path: <albert.cabellos@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 B1677124207 for <lisp@ietfa.amsl.com>; Tue, 26 Dec 2017 17:48:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 UJuk7wS8uP-H for <lisp@ietfa.amsl.com>; Tue, 26 Dec 2017 17:48:32 -0800 (PST)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 8F9AA127076 for <lisp@ietf.org>; Tue, 26 Dec 2017 17:48:32 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id z132so4476078ywd.9 for <lisp@ietf.org>; Tue, 26 Dec 2017 17:48:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0CCs8qCRKe9ddSdVI/cQnMYjmMCyfA+reLWJqCQG4xY=; b=tKGEROaKcB9nrUSwrcs4WidXE9unCGJH/MIsyB11iiZ/WBGRWpwYuYWxwyrUAl7+E8 FKa0Ikb3uN4k+Xl9+jt0QjTT65oQKzwvDwgEauvUTQoazwuM0xlKqhvJ6zEHwhzOmzO4 LcOXD4xGj6UUcGBOqXJQreKdZzSxZV9RLr3zoXU9g9lvZNQ1fVkybwLnhJj5DVQbWHEg /icHxrGF4ZSpzUjKnKBCFI+4pVmlompyTWLoX/BOYYUmPP1FUNcuis3QY4Q4608pLTm7 lOTXck9j2QBm9fYzsC94wClLXr5tspZNkQvL8nZtyC4p4lYcKTVlTyUpGD9GJCHRT+dZ TIMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0CCs8qCRKe9ddSdVI/cQnMYjmMCyfA+reLWJqCQG4xY=; b=UM4zcbZnHYwL5msHB0WaH9C0MIfLvfeU4WVZ61qgLeubwlJaVCr4TyhFKQFVvJTRBq EFTlHISiFCbK9jd+bQnIwR1i6Kn02rNeNTLlJ3npblGeoo1qeblYQxY+t9eYdRuvogvf xf5sJNpVmsnFTPCb7r40dULGHMWYbPYk1CKtEuXC72HPUB9IcZBmWOUT+tHKSSObFAbT yT2d45ycUw5ZEYnoIc1U5tyo6SNaqUC7GKegU1kZDYYL14MMI2SYCIyPtwsJlI3xeWTX Nzdp+KOJ2SZrcjHHve6v2jUA/lx4jMvlfcZr/Y09EdgSjU9S85TGa280uDFSUR++fLQD OAXg==
X-Gm-Message-State: AKGB3mLhGPH/tmpGYw24aN3If1z5QfbfreMVcKA9XguxBMKcFP6WFyzf 2vf+SVPURWkt0/bRqvOEN9CKmRIWyvz2HiC1zdooU35R
X-Google-Smtp-Source: ACJfBosAmIs3SufNFrSUUekJzFAbEIGmhmIFToBz202oPOIVf/SK+Rm6bHRmnEjOdfwSg1Q5DE2UqG4jrIkhsAHJYGk=
X-Received: by 10.129.104.194 with SMTP id d185mr18599276ywc.322.1514339311122; Tue, 26 Dec 2017 17:48:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.183.142 with HTTP; Tue, 26 Dec 2017 17:48:30 -0800 (PST)
In-Reply-To: <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net>
References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net>
From: Albert Cabellos <albert.cabellos@gmail.com>
Date: Wed, 27 Dec 2017 02:48:30 +0100
Message-ID: <CAGE_QexqW=q51kXR9fo_8YDu6VVUHCBz-XrGt5iZ6FOTRxDLiA@mail.gmail.com>
To: Luigi Iannone <ggx@gigix.net>
Cc: "lisp@ietf.org list" <lisp@ietf.org>, lisp-chairs@tools.ietf.org
Content-Type: multipart/alternative; boundary="001a11490486b57fac0561489850"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/9hvRtUswldiX_i6ldpi6Km8-yXY>
Subject: Re: [lisp] 6830bis Review
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, 27 Dec 2017 01:48:36 -0000
Hi Thanks for the review, please find my comments inline. I have removed all the comments for which I **agree**: > > Provider-Assigned (PA) Addresses: PA addresses are an address block > assigned to a site by each service provider to which a site > connects. Typically, each block is a sub-block of a service > provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and > is aggregated into the larger block before being advertised into > the global Internet. Traditionally, IP multihoming has been > implemented by each multihomed site acquiring its own globally > visible prefix. LISP uses only topologically assigned and > aggregatable address blocks for RLOCs, eliminating this > demonstrably non-scalable practice. > > Last sentence to be deleted is a relic of scalability discussion. > > Agreed. I suggest deleting entirely the definitions for both PA and PI, they are not used throughout the document. [snip] > > > Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for > IPv6) value used in the source and destination address fields of > the first (most inner) LISP header of a packet. The host obtains > a destination EID the same way it obtains a destination address > today, for example, through a Domain Name System (DNS) [RFC1034] > lookup or Session Initiation Protocol (SIP) [RFC3261] exchange. > The source EID is obtained via existing mechanisms used to set a > host's "local" IP address. An EID used on the public Internet > must have the same properties as any other IP address used in that > manner; this means, among other things, that it must be globally > unique. An EID is allocated to a host from an EID-Prefix block > associated with the site where the host is located. An EID can be > used by a host to refer to other hosts. Note that EID blocks MAY > be assigned in a hierarchical manner, independent of the network > topology, to facilitate scaling of the mapping database. In > addition, an EID block assigned to a site may have site-local > structure (subnetting) for routing within the site; this structure > is not visible to the global routing system. In theory, the bit > string that represents an EID for one device can represent an RLOC > for a different device. As the architecture is realized, if a > given bit string is both an RLOC and an EID, it must refer to the > same entity in both cases. > > > Is the above sentence really necessary? > Agreed, why not simplify the definitions. They are written from the ‘Internet scalability mindset’, why not say that an EID is an address of the overlay and an RLOC an address of the overlay. This change may require further changes on the document so I am not 100% sure if this is a good idea. [snip] > > Re-encapsulating Tunneling in RTRs: Re-encapsulating Tunneling > > RTR have never been defined. Agree, they are defined in LISP-TE, not sure about the rules here. They are used in section 17. [snip] > > Recursive Tunneling: Recursive Tunneling occurs when a packet has > more than one LISP IP header. Additional layers of tunneling MAY > be employed to implement Traffic Engineering or other re-routing > as needed. When this is done, an additional "outer" LISP header > is added, and the original RLOCs are preserved in the "inner" > header. > > Do not think the following sentence is really necessary. > It is an easy way to explain that tunnels can be nested, may be obvious for us but not for some readers. In any case the term ‘recursive tunneling’ is used several times throughout the document. I don´t have a strong opinion but I´d say leave it as it is. > > o EIDs are typically IP addresses assigned to hosts. > > o Other types of EID are supported by LISP, see [RFC8060] for > further information. > > I would put the last two bullets in the definition of EID. It simplifies the story here. > > I suggest to leave them here, I don´t think that readers start from the ‘Definition of terms’, these are relevant concepts to understand LISP. > > The description of the encap/decap operation lacks of clarity concerning how to deal with > ECN bits and DSCP . > > 1. I think that the text should make explicitly the difference between DSCP and ECN fields. > > 2. How to deal with ECN should be part of the description of the encap/decap not a paragraph apart. > This basically means that half of the last paragraph should be a bullet of the ITR/PITR encapsulation > and the other half in the ETR/PETR operation. Agreed, what about this (please comment): When doing ITR/PITR encapsulation: o The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field. o The outer-header 'Differentiated Services Code Point' (DSCP) field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the inner-header DSCP field ('Traffic Class' field, in the case of IPv6) considering the exception listed below. o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header. When doing ETR/PETR decapsulation: o The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field, when the Time to Live value of the outer header is less than the Time to Live value of the inner header. Failing to perform this check can cause the Time to Live of the inner header to increment across encapsulation/decapsulation cycles. This check is also performed when doing initial encapsulation, when a packet comes to an ITR or PITR destined for a LISP site. o The inner-header 'Differentiated Services Code Point' (DSCP) field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the outer-header DSCP field ('Traffic Class' field, in the case of IPv6) considering the exception listed below. o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC3168]. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints. Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header minus 1. Copying the Time to Live (TTL) serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration. See Section 18.3 for TTL exception handling for traceroute packets. > > Large part of this section is about control plane issues and as such should be put in 6833bis. > > What this section should state is that priority and weight are used to select the RLOC to use. > Only exception is gleaning where we have one single RLOC and we do not know neither priority nor weight. > > All the other operational discussion goes elsewhere, but not in this document. > Agree, I suggest moving it to 6833bis. What to leave in 6830bis is less obvious, maybe something like (not final, just a couple of ideas): The data-plane must follow the state stored in the map-cache to encapsulate and decapsulate packets. The map-cache is populated using a control-plane, such as [6833bis]. ETRs encapsulate packets following the Priorities and Weights stored in the map-cache. Actually we should merge this section with 'Routing Locator Hashing' > We need to cite the threats document because of the security issues of LSB. What about this: Therefore, when a Locator becomes unreachable, the Locator-Status-Bit that corresponds to that Locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID-Prefix. *****There are security risks associated to the use of Locator-Status-Bits, we recommend to follow the guidelines described in [THREATS]****** > > 12. Routing Locator Hashing > > When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to > a requesting ITR, the Locator-Set for the EID-Prefix may contain > different Priority values for each locator address. When more than > one best Priority Locator exists, the ITR can decide how to load- > share traffic against the corresponding Locators. > > The above paragraph should not state where the mapping comes from, from the data plane perspective it comes from the cache. > > Also where is weight??????? What about: When an ITR encapsulates packets it may found that corresponding map-cache entry contains a Locator-Set with different priorities and weights, the following hash algorithm may be used by an ITR to select a Locator for a packet destined to an EID for the EID-to-RLOC mapping: > > 13. Changing the Contents of EID-to-RLOC Mappings > > > This is a control plane issue, as such it has to go in 6833bis, with two exception: > The very first paragraph stetting the problem, and the versioning subsection, because it is a data-plane mechanism. > > All of the rest 6833bis > > Actually I remember a suggestion about putting operations issues like this in an OAM document which would be a good idea. > > So you are suggesting that the LISP control-plane does not define any mechanism to update EID-to-RLOC mappings?
- [lisp] 6830bis Review Luigi Iannone
- Re: [lisp] 6830bis Review (PLEASE COMMENTS) Luigi Iannone
- Re: [lisp] 6830bis Review (PLEASE COMMENTS) Dino Farinacci
- Re: [lisp] 6830bis Review (PLEASE COMMENTS) Luigi Iannone
- Re: [lisp] 6830bis Review Albert Cabellos
- Re: [lisp] 6830bis Review Dino Farinacci
- Re: [lisp] 6830bis Review (PLEASE COMMENTS) Dino Farinacci
- Re: [lisp] 6830bis Review - scalability Joel M. Halpern
- Re: [lisp] 6830bis Review - scalability Dino Farinacci
- Re: [lisp] 6830bis Review Albert Cabellos
- Re: [lisp] 6830bis Review Dino Farinacci
- Re: [lisp] 6830bis Review Joel M. Halpern
- Re: [lisp] 6830bis Review - control relationship Joel M. Halpern
- Re: [lisp] 6830bis Review Dino Farinacci
- Re: [lisp] 6830bis Review Joel M. Halpern
- Re: [lisp] 6830bis Review Dino Farinacci
- Re: [lisp] 6830bis Review Dino Farinacci
- Re: [lisp] 6830bis Review Luigi Iannone
- Re: [lisp] 6830bis Review (PLEASE COMMENTS) Luigi Iannone
- Re: [lisp] 6830bis Review Luigi Iannone
- Re: [lisp] 6830bis Review Dino Farinacci
- Re: [lisp] 6830bis Review (PLEASE COMMENTS) Dino Farinacci
- Re: [lisp] 6830bis Review (PLEASE COMMENTS) Luigi Iannone
- Re: [lisp] 6830bis Review Luigi Iannone
- Re: [lisp] 6830bis Review Damien Saucez
- Re: [lisp] 6830bis Review Dino Farinacci
- Re: [lisp] 6830bis Review Alberto Rodriguez-Natal
- Re: [lisp] 6830bis Review Dino Farinacci
- Re: [lisp] 6830bis Review Joel M. Halpern
- Re: [lisp] 6830bis Review Luigi Iannone
- Re: [lisp] 6830bis Review Dino Farinacci
- Re: [lisp] 6830bis Review Luigi Iannone
- Re: [lisp] 6830bis Review Dino Farinacci
- Re: [lisp] 6830bis Review Joel M. Halpern
- Re: [lisp] 6830bis Review Dino Farinacci
- Re: [lisp] 6830bis Review Joel M. Halpern
- Re: [lisp] 6830bis Review Alberto Rodriguez-Natal
- Re: [lisp] 6830bis Review Dino Farinacci
- Re: [lisp] 6830bis Review Reshad Rahman (rrahman)