I will leave most of these for the authors to comment on.
See my comments inline. Thanks David for your detailed review and commentary.
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.
That is the risk we may have with many of your comments. We have a lot of
detail in the already 9 published RFCs and this document really is to take all
that detail and summarize as an easily understandable description of a cohesive
design.
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
Definitely agreed. In fact we instigated UDP zero. And I continually talk to
hardware engineers and they all believe we made the right decision. So hats off
to the IETF for being practical.
we could include them. If you are looking for a change in the behavior, this
document can not make changes to the LISP behavior.
Yes, an important point.
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.
Thanks a ton.
-- 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.
No, from the start of the LISP design (circa 2007), an prefix is what moves.
And a specific EID is simply a /32 or /128 prefix. Here is a practical example:
You have a cluster of servers that communicate together for a particular
application. They application cluster is running in a set of VMs. Those VMs are
assigned EIDs from a common power-of-2 EID-prefix. Those VMs are currently
running in a brick-and-mortar data center. Now there is a desire to move the VM
cluster to a cloud provider. What is moved is the EID-prefix of the cluster.
The mapping system is told that the EID-prefix is changing its RLOC-set from
the brick-and-mortar xTRs to the cloud providers xTRs.
- 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.
See above example.
[B] LISP Multicast vs. EID/RLOC separate
- 6. Multicast
This is interesting, multicast addresses (G) look like they're an exception
They are really not. Since multicast addresses *identify* a group of receivers,
it is very much an EID and aheres to the definition of an EID. Multicast
addresses never had topological signficance but the state representing a
distribution tree does tell you were the members are (but the identity of the
members are not know in multicast).
So it makes perfect sense to register multicast addresses to the mapping system
as EIDs and they can map to RLOCs of sites that have joined the group. See
draft-farinacci-signal-free-multicast as just one example. RFC6831 and
draft-farinacci-lisp-mr-signaling are other examples.
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.
I believe the level of detail we have in the introduction document is at the
right level or we'll err on having way too many details crop in.
- 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.?
The mapping system can map an (S-EID-ipv6, group-ipv6) 2-tuple to a RLOC set
that looked like this (ipv4-multicast, ipv4-unicast) mean the ITR that receives
the packet from S-EID-ipv6 would replicate the packet and multicast encapsulate
to ipv4-multicast and unicast encapsualte to ipv4-unicast.
- 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
You can map from EID-G to RLOC-G one to one. But we have seen over the last
decade in a half that with general multicast deployment that many-to-1 is
desirable. Hence, now that we have a way to map with a network-based database,
we can map multiple EID-Gs to a single (or multiple) RLOC-Gs.
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
This is a necessary evil when the underlay is state challenged. But it is a
state/bandwidth tradeoff. We have found with MVPN deployment that the network
admin configures the underly or simply unicasts.
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.
There are just too many combinations to make a high-level description simple to
understand. The current introduction text does a find job providing references
for someone to go off and get the details.
-- 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
This is true when you call the domain a "LISP site". But if the site is
unchanged and one uses PITRs, maybe even close to the site, like in a PE
router, then the PITR is definitely in another AS. But note I said PITR and not
ITR. The reason being is because an ITR is configured with database-mapping
prefixes that is uses to encapsulate packets from such addresses. Versus the
PITR being an ITR with *no database-mappings* providing a much more larger/or
more aggregtable service.
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.
We are overloaded with terms that create topological or organization boundary.
Hence why we created "LISP site" which is also the same as a "LISP VPN site".
Where a "LISP site" that has multiple tennants would be multiple "LISP VPN
sites".
Despite multiple mentions of incremental deployment, I did not
see a discussion of how that might be accomplished. There is some
There are PxTRs and NATs. And references to the LISP interworking RFC.
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.
ECMP/LAG don't influence which source port is selected. It is a 5-tuple hash of
the inner header that selects a source port that influences how an underlay
router would load-split traffic.
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.
My head spins every time I hear about this subject. This subject has been
talked about from 100s of people for a decade. We have CRC on links, we have
apps that use TCP and UDP checksums. Nuf said.
-- 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
We will certainly fixe these. Thanks.
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?
Well beacuse it is as accurate as it can be. If automobiles are going to be
assigned EIDs from a VIN number allocation from a manufacture, the address is
relatively opaque. If a VM in a data-center is going to be assigned an EID from
the set of prefixes already being used and allocated to that data-center, then
there is a good chance that address is in a power-of-2 block that is
summarizable in the IGP.
- 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.
When you want egress path selection to happen further out in the toplogical
from the source location, then you put an ITR-only system there. Where ingress
to the same source (destination in this direction), the ETR can be closer to
the destination.
- 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.
Fair enough.
- 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).
Already noted and will be fixed.
- 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.
Good suggestion and makes sense.
- 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.
Hmm, I'll let Albert and Damien decide if we should state "EID-prefixes"
everywhere instead of just "EID".
- 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.
This is a lot of detail because in RFC6830 we have 3 positions or options on
the subject. And we did provide a reference to RFC6830 for this topic.
- 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.
Agree.
idnits 2.13.01 didn't find any nits.
Thanks,
--David
Thanks again David.
Dino