Re: OPS-Dir review of draft-ietf-lisp-introduction-11

"Joel M. Halpern" <> Tue, 10 February 2015 23:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B1CE91A8757; Tue, 10 Feb 2015 15:46:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pnv5HAN9MAz9; Tue, 10 Feb 2015 15:45:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92D081A8756; Tue, 10 Feb 2015 15:45:58 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DF1324072B; Tue, 10 Feb 2015 15:45:58 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at
Received: from Joels-MacBook-Pro.local ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 53F742403A3; Tue, 10 Feb 2015 15:45:56 -0800 (PST)
Message-ID: <>
Date: Tue, 10 Feb 2015 18:45:49 -0500
From: "Joel M. Halpern" <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "Black, David" <>, "" <>, "" <>, "" <>
Subject: Re: OPS-Dir review of draft-ietf-lisp-introduction-11
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>, "" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Feb 2015 23:46:01 -0000

I will leave most of these for the authors to comment on.

With regard to your question about incremental deployment, that is the 
domain of the LISP Deployment document, and was deliberately only 
lightly covered here.  I am not sure what we can do to address your 
comment without duplicating the entirety of that document.

With regard to UDP Zero, this was approved by the IESG and published as 
an RFC.  It is part of the way the protocol is defined.  If there are 
specific changes you would like to see in the explanatory text, I am 
sure we could include them.  If you are looking for a change in the 
behavior, this document can not make changes to the LISP behavior.


On 2/10/15 6:25 PM, Black, David wrote:
> I have reviewed this document as part of the Operational directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written with the intent of improving the operational
> aspects of the IETF drafts. Comments that are not addressed in last call
> may be included in AD reviews during the IESG review.  Document editors
> and WG chairs should treat these comments just like any other last call
> comments.
> Document: draft-ietf-lisp-introduction-11
> Reviewer: David Black
> Review Date: Feb 10, 2015
> IETF LC End Date: Feb 4, 2015 (on -10)
> Summary: This draft is on the right track, but has open issues
>   		described in the review.
> First of all, I apologize for this review showing up after the end of
> IETF Last Call on this draft.  I plead being one of the victims of this
> year's flu vaccine being poorly matched to the prevalent flu viruses.
> The draft is generally well written and provides a nice introduction to
> LISP - good job.  Most of the usual OPS-Dir questions in Appendix A of
> RFC 5706 do not apply, as they are better addressed by the additional
> material in the RFCs that specify the actual LISP protocol specifications.
> Nonetheless, there are a few that apply, as noted in the issues below.
> I found a couple of major issues that I hope arise from the
> summarization of LISP in this draft, as opposed to being problems in
> the actual LISP protocols.  I also found a few minor issues, the most
> important of which is the need for additional security considerations
> discussion on misdelivery, with particular attention to VPNs.
> -- Major issues --
> [A] EID mobility vs. EID prefixes
> - 5. Mobility
> I understand how this works when mapping is per-EID, but how does this work
> when the EID of the system that moves is part of an EID prefix, as discussed
> in Section 3.4.1?  Even if the answer is a long version of "Don't do that!"
> it should be explained.
> - 7.4.  LISP for Virtual Machine Mobility in Data Centers
> I don't understand how this works when EID prefixes are used, as each VM
> has its own EID or EIDs, hence the entire prefix range does not move when
> the VM moves.
> For OPS-Dir, this EID prefix issue [A] falls under A.1.1 in Appendix A
> of RFC 5706:  Has deployment been discussed? and specifically under:
>         *  Is the proposed specification deployable?  If not, how could
>            it be improved?
> as EID prefixes appear to be undeployable for Mobility and VM Mobility usage.
> [B] LISP Multicast vs. EID/RLOC separate
> - 6. Multicast
> This is interesting, multicast addresses (G) look like they're an exception
> to the EID/RLOC separation as the same destination IP multicast address
> is used for both purposes.  This could use some more discussion, as it's
> unexpected based on the contents of the draft up to this point.
> - 7.2.  LISP for IPv6 Co-existence
>     LISP encapsulations allows to transport packets using EIDs from a
>     given address family (e.g., IPv6) with packets from other address
>     families (e.g., IPv4).
> How does that work for multicast traffic, where the destination address
> (G) has to be the same in both the inner and outer headers?  Are ETRs
> and ITRs expected to map IPv6 multicast addresses to IPv4 and v.v.?
> - 7.3.  LISP for Virtual Private Networks
> This also has multicast problems, as there is only one instance of each
> multicast address (G) in the underlay network.  I think I can figure out how
> to make multicast work for this use case, but it's not immediately obvious,
> and the result when the same underlay multicast address is used by more
> than one VPN could well deliver some traffic to ETRs that have to discard
> it because the Instance ID is wrong (and that excessive delivery is a
> security consideration, see minor issue on Section 8 below).  I think an
> explanation is in order.
> For OPS-Dir, this multicast issue [B] falls under A.1.4 in Appendix A of
> RFC 5706: Have the Requirements on other protocols and functional
>         components been discussed?
> -- Minor Issues --
> There seems to be an implicit assumption that the end host and its
> ITR (xTR) are in the same domain or Autonomous System.  For incremental
> deployment, I don't think that's always the case, but I think that only
> has editorial impact on this document, as I don't think any of the
> fundamental LISP mechanisms are affected.  The authors should look for
> use of "domain" and "Autonomous System" and ensure that the text is
> generalized to the case where the end host and ITR are more widely
> separated.
> Despite multiple  mentions of incremental deployment, I did not
> see a discussion of how that might be accomplished.  There is some
> useful content in Section 3.5, but that's at best an incomplete
> explanation.  This is an OPS-Dir review concern - it falls under
> A.1.3 in Appendix A of RFC 5706: Has the migration path been discussed?
> - 3.3.1.  LISP Encapsulation
>     the source port is selected by
>     the ITR and ignored on reception.
> Please mention multipathing (e.g., ECMP and LAG) as possible influences
> on how source ports are selected, as this imposes some limits on what an
> ITR can reasonably do.
> For OPS-Dir, this multipathing concern falls under A.1.4 in Appendix A of
> RFC 5706: Have the Requirements on other protocols and functional
>         components been discussed?
>     This decision was made because the
>     typical transport protocols used by the applications already include
>     a checksum, by neglecting the additional UDP encapsulation checksum
>     xTRs can forward packets more efficiently.
> Groan!  I have an exquisite set of scars on UDP zero checksums for IPv6
> from working on the MPLS in UDP draft, so I may be overly sensitive to
> this concern.  The downside of this efficiency is that there is no
> checksum coverage of the IPv6 header when zero UDP checksums are used.
> That should at least be mentioned here, with a summary of why that's ok
> - the detailed justification for why that's ok can be left to other
> documents.
> For OPS-Dir, this UDP zero checksum for IPv6 concern also falls under
> A.1.4 in Appendix A of RFC 5706:
>     Have the Requirements on other protocols and functional
>         components been discussed?
> - 8 Security Considerations
> This should discuss possibility of misdelivery of LISP-encapsulated
> packets to the wrong ETR and the resulting security consequences.  This
> is particularly relevant to the VPN use case in Section 7.3.  This
> discussion should also note that omitting the UDP checksum for IPv6
> increases the opportunity for misdelivery.
> For OPS-Dir, this security concern falls under A.1.5 in Appendix A of
> RFC 5706: Has the impact on network operation been discussed?
> This is because dealing with any such misdelivery will have an operational
> impact.
> -- Nits/Editorial Comments --
> - Top of p.4:
>     The initial motivation in the LISP effort is to be find in the
> "find" -> "found"
> - Section 3.1, first bullet item
>        Devices are assigned with relatively opaque identity
>        meaningful addresses that are independent of their topological
>        location.
> I don't understand "relatively opaque identity meaningful" and
> suggest rewriting the sentence.  In particular - opaque to what?
> meaningful to what in what manner?
> - Section 3.2, second paragraph
> Judging from the figure, xTRs are the common case, with single-
> function ITRs and ETRs being rare.  It might be good to say that
> and discuss when ITRs and ETRs that are not xTRs are appropriate
> to use.
> - 3rd paragraph on p.7:
>     Finally, the LISP architecture emphasizes a cost effective
>     incremental deployment.
> I'd delete "cost effective" here and look for other occurrences
> of "cost" as candidates for deletion.  This is supposed to be
> a technical document, so discussion of costs is a bit off-target.
> - First item after Figure 2:
>     1.  HostA retrieves the EID_B of HostB, typically querying the DNS
>         and obtaining and A or AAAA record.
> "and A" -> "an A"  (spelling checkers don't catch everything).
> - 3.3.1.  LISP Encapsulation
>     On the other hand, Recursive
>     tunnels are nested tunnels and are implemented by using multiple LISP
>     encapsulations on a packet.
> The above sentence seems out of place in the middle of a paragraph about
> Re-encapsulating tunnels and routers - I suggest moving it down into its
> own paragraph and perhaps adding a sentence about where/how Recursive
> tunnels may be useful.
> - 3.3.2.  LISP Forwarding State
>     In the LISP architecture, ITRs keep just enough information to route
>     traffic flowing through it.
> "it." -> "them."
>     Meaning that, ITRs retrieve from the
>     LISP Mapping System mappings between EID prefixes and RLOCs that are
>     used to encapsulate packets.
> This is the first use of the notion of EID prefixes.  That concept should
> be explained before it is used, although a forward reference to section
> 3.4.1 may suffice.  It might be better to rewrite this paragraph in terms
> of EIDs and leave the notion of EID prefixes to section 3.4.1.
> - 4.4.  MTU Handling
>     Additionally, LISP also recommends inferring reachability of locators
>     by using information provided by the underlay, in particular:
> It'd be useful to add a sentence or two about how LISP and the techniques
> in this section interact with host use of PMTUD and PLPMTUD.
> - Next to last paragraph on p.17:
>     Additionally, LISP also recommends inferring reachability of locators
>     by using information provided by the underlay, in particular:
> This looks like it's a paragraph early and needs to be moved down to
> after the paragraph that follows it.
> idnits 2.13.01 didn't find any nits.
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
>        Mobile: +1 (978) 394-7754
> ----------------------------------------------------