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

["Black, David" <[e-mail]>]

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
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------