Re: [lisp] Confirm/Deny changes on draft 6830bis

Dino Farinacci <> Fri, 26 January 2018 19:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54C13127337 for <>; Fri, 26 Jan 2018 11:20:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 4.402
X-Spam-Level: ****
X-Spam-Status: No, score=4.402 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, GB_SUMOF=5, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id veb7pnrsGIga for <>; Fri, 26 Jan 2018 11:20:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C1BD4124BE8 for <>; Fri, 26 Jan 2018 11:20:31 -0800 (PST)
Received: by with SMTP id c6so883253pfi.8 for <>; Fri, 26 Jan 2018 11:20:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=FWRmycoXYQVpFBi/awOmSG1LN8eiiAqKMymVZz8oKm8=; b=oYmqojxieT9iKqGM1B+vUdibD4R7FMmHgSDSAi8YwCnd5eov27VZc8RjhkHikUusb1 4S7nyQb4KBuUOPO+myC8SwJthBgmENrsS7xutntJm0BdMewvp1lKpAMYuOaznmem2jbv wTGO2kfQfGHUhE5bLpbJeuie1rKNhpzH3yMw9UCKkaHvFiKrg2alMHo/INq5unGimY8B rDCGUO5JqeyiJ59Oq1uBqfxwoITsEFmGEmrVJ/fkUiV2ZNaP3fAwpNH24kB6TXlBIzlH vZLwvfuagEDnzBxH7E0rArY9xLuIlGPGk1oY//5J5NsysRTXsMmDjK7Kha6bQfLC1T8m aJ1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=FWRmycoXYQVpFBi/awOmSG1LN8eiiAqKMymVZz8oKm8=; b=Pgm1SIAwtZg1Fpmsp2TM5KPw6W56zme3wh2KagEEu8ymFP85WrIiG3hoVYriqV/A1z jjl4q18deJVBYi+ADAgL0E9Z1/om5wJ4AMGexyTN3Hxrul1Rg9wD0pNeta+wtNw3rsEU Usns9AAkoVML3z247Crn1PbstROGFGzedZ/Qri+qBbHohRADWpa1EUdAb5sK78MpoQRF Wqyo9Vsyqlg83mZjWFaf8d0DENHix1xI/esaMH+A3ImTd22MZYX41rSiI2B1W3GzDFKX f+Uci0i4rly8J7tPtD/b0+1HtzDjNtTGoRU4CUuJUAi8KURYjniy8OC1rbGgc5V4p4KX pVxg==
X-Gm-Message-State: AKwxytdfMhOZMGap9ACxp52JpT/ndaK6UdqrvgllFWdAjQCuGeSwvxUh xpncWvE/4UmTruqv3YSF1H8=
X-Google-Smtp-Source: AH8x227mOA4oD0LE+btnow398HUyoQbLWVPk6dW6SSCHAY6AUpNi0UIxKBJ8RM+bjthbXoEKRrn9jg==
X-Received: by 2002:a17:902:14d:: with SMTP id 71-v6mr15260158plb.42.1516994429961; Fri, 26 Jan 2018 11:20:29 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id l10sm22347850pfj.6.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jan 2018 11:20:28 -0800 (PST)
From: Dino Farinacci <>
Message-Id: <>
Content-Type: multipart/mixed; boundary="Apple-Mail=_C7FC98C2-EDDC-4BAA-A565-E59514828F56"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Fri, 26 Jan 2018 11:20:27 -0800
In-Reply-To: <>
Cc: Albert Cabellos <>, Luigi Iannone <>, " list" <>,
To: Padma Pillay-Esnault <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [lisp] Confirm/Deny changes on draft 6830bis
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Jan 2018 19:20:49 -0000

Thanks for the detail review Padma. A new update to -09 is enclosed with a diff file. I will wait until next week to post.

I have reflected all of your comments and most of Luigi’s comments. The only issues open are:

(1) Section movement from RFC6830 to RFC6833.

(2) If an OAM document is needed.

Waiting for more working group concensus on this.

> Dear Dino and Albert 
> The doc reads well.
> Please find thereafter some comments on the version- 09 you posted on the list 
> Page 4
> "Client-side:  Client-side is a term used in this document to indicate a connection initiation attempt by an EID."
> PPE 1: Strictly speaking the EID is just an identifier and does not initiate anything. Suggest something like this.
> "Client-side:  Client-side is a term used in this document to indicate a connection initiation attempt by the end system (represented by an EID)”

Fixed. Put in your suggestion.

> Page 6
> 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.
> PPE 2: Shouldn't these two be MUST rather than must? Suggestion below
> 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.


> Page 8
> An EID maps to one or more RLOCs.
> PPE 3: Seems to contradict earlier explanation on negative mapping entry where it is possible that an EID has NO RLOC.

I changed to “zero or more RLOCs.”.

> Page 8 
> When using multiple mapping database systems, care must be taken to not create re-encapsulation loops through misconfiguration.
> PPE 4: Suggest to add "re-encapsulation" in the list in Security Considerations section as this is an exploit possibility.

I have removed the sentence. Because it actually is not true. If you use different mapping systems and circuitious forwarding occurs. The packet travels only until its TTL reaches 0. Using the rules for copy inner to outer and outer to inner during RTR re-encapsulation applies.

> Page 13
> "gleaned" mapping
> PPE 5: Suggest adding “glean mapping” in the definition section.


> Page 17
> "The KK-bits are a 2-bit field used when encapsualted packets are encrypted."
> PPE 6: Nit - Typo "encapsualted" -> “encapsulated"


> Page 20
> "When the lookup succeeds, the locator-set  retrieved from the map-cache is used to send the packet to the EID's topological location."
> PPE 7: Nit - Suggest capitalize L and S of "locator-set" for consistency with rest of document.

Thanks. Done.

> Page 23
> "The server-side sets a Weight of 0..."
> PPE 8: Nit - For consistency in text change to "Weight of zero”.


> Page 23 
> "Control is shared by the server- side determining the list and the client determining load  distribution." 
> PPE 9: Suggest use of "Client-side"
> "Control is shared by the server- side determining the list and the client-side determining load distribution.”


> Page 24
> When a verified Map-Cache entry is stored, data gleaning no longer occurs for subsequent packets that have a source EID that matches
> the EID-Prefix of the verified entry.[PE1]   This "gleaning" mechanism is OPTIONAL.
> PPE 10: In section 16.2 later gleaning is used as a solution.  Changes in the gleaned info could be an interesting way to update the cache fast …however this text make it sound that this is not an option after first packet.

It is an option when the ETR has no mapping to return packets. Once a mapping is cache, there is no point to glean since the mapping system verified the information the same as in the map-cache.

> Page 25
> "Note that trusting ICMP messages may  not be desirable, but neither is ignoring them completely. Implementations are encouraged to follow current best practices in treating these conditions."
> PPE 11: A reference would be useful if possible.

Added draft-ietf-opsec-icmp-filtering.

> Page 25
> "An ITR that participates in the global routing system can determine that an RLOC is down if no BGP Routing Information Base (RIB) route exists that matches the RLOC IP address."
> PPE 12: Isn't this true for any protocol entry not just a BGP entry? We are really trying to determine if there is no route whatever the protocol.

Yes, we can generalize this. I changed text.

> Page 38
> "For a more detailed networkd design deployment recommendation, refer to [RFC7215]."
> PPE 13: Nit typo "netword"-> “network"


> Page 40
> "By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and Re-Encapsulate for a new encapsuluation path to the destination end site."
> PPE 14: Nit Typo "encapsuluation" -> “encapsulation"


> Page 43
> "If the attacker spoofs the source RLOC, it can mount a DoS attack by redirecting traffic to the spoofed victim;s RLOC, potentially overloading it."

> PPE 15: Nit  typo "victim;s" -> “victim’s”