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

[Dino Farinacci <[e-mail]>]

> Dino - thanks for the response.
> 
> On the major issues, it looks like both [A] and [B] involve only the text
> in this draft and nothing beyond, which is good news.  I have a simple text
> suggestion for [A], but it looks like [B] is going to require some careful
> editing, as one of the primary causes is that the draft is sloppy in using
> the same symbol "G" to represent both EID and RLOC multicast groups.

Okay for [A] but not true for [B]. In RFC6831, a multicast address G is not in the mapping database because signaling is performed from ETR to ITR. What's in the mapping database is the EID S from the (S,G) the source sends from and to.

> On the minor issues, I have text suggestions for three of the four, and
> I'd like to temporarily defer further discussion the IPv6 UDP zero
> checksum "tarpit" in favor of resolving everything else first.

Sounds good David.

> On the nits/editorial comments, all the suggestions in your email are fine
> with me.  FWIW, I regard that portion of a review as almost entirely
> subject to the draft authors' discretion (and editorial taste).
> 
>>>> [A] EID mobility vs. EID prefixes
>> 
>> ... 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:
> 
> A statement that the mobility use cases need to employ /32 and /128 prefixes,
> and not anything coarser should suffice.  That should be added to Section 5.

Well I think it is not true. Because EID-prefixes are moved but is outside of the VM-mobility use-case.

> 
>>>> [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.
> 
> My concern is that as I read the draft, it leaves me with the strong impression
> that the same multicast addresses (G) are being used in both the overlay
> (as EIDs) and the underlay (as RLOCs).  From your response, I conclude that this

Understand. We state in RFC6831 that it can map one-to-one or many-to-one. We'll make that more clear in the introduction document.

> is not the case (and I have no argument with that).  Rather, Section 6 needs to
> bluntly state that multicast addresses are mapped between EID and RLOC space at
> both ITRs and ETRs, so that the following inference is obvious from the text
> (it's currently not obvious):

Right, agree.

> 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.
> 
> As part of this, I strongly recommend moving away from use of "G" to refer to
> multicast groups in both the overlay and underlay.  Careful use of G-EID
> and G-RLOC would significantly improve clarity.

Well we have not used G-EID in any documentation. And since we want to encourage the use of SSM in the underlay and how we signal in the overlay, we simply call the "eid" the 2-tuple (S,G).

> ---
> If the above are done for [A] and [B] in Sections 5 and 6, then the text for the
> use cases in Section 7 should not need further attention.
> ---
> 
>>>> -- 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.
> 
> Looking at the text, it seems that "LISP site" and "domain" are the same
> concept for this draft.  That would be useful to state, IMHO but I'll leave
> the decision on whether to do so to you and the draft authors.
> 
> On rereading, my concerns seem to be triggered mostly by this sentence in
> Section 3.2:
> 
>   The edge consists of LISP sites (e.g., an
>   Autonomous System) that use EID addresses.
> 
> I think a small change to the last sentence in that paragraph would resolve
> my concern without distracting from the narrative:
> 
> OLD
>   EIDs do not
>   contain inter-domain topological information and because of this,
>   EIDs are usually routable at the edge (within LISP sites) or in the
>   non-LISP Internet.
> NEW
>   EIDs do not
>   contain inter-domain topological information and because of this,
>   EIDs are usually routable at the edge (within LISP sites) or in the
>   non-LISP Internet; see Section 3.5 for discussion of LISP site
>   internetworking with non-LISP sites and domains in the Internet.

Ack.

> 
>>>> Despite multiple  mentions of incremental deployment, I did not
>>>> see a discussion of how that might be accomplished.
>> 
>> There are PxTRs and NATs. And references to the LISP interworking RFC.
> 
> Ok, can we just say so in Section 3.5?  Adding the following sentence
> to the end of the section would suffice:
> 
>   PITRs, PETRs and LISP-NAT support incremental deployment of LISP
>   by providing significant flexibility in location of the boundaries
>   between the LISP and non-LISP portions of the network, and making
>   it reasonable to change those boundaries over time.

Yes.

> - 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.
> 
> Please state that a 5-tuple hash is used.  ECMP/LAG is among the important

Well there can be other ways to hash and that is detail not needed at this level IMO. We suggest a 5-tuple hash in RFC6830.

> reasons why, but that doesn't need to be stated if you prefer not to.  An
> example of something that needs to be excluded is that using a random
> number generator to set the source port would be wrong - I could suggest
> citing draft-ietf-dart-dscp-rtp for related discussion (and lots more
> details), but I don't think that's necessary.

How about stating the source-port should not change for a flow or it causes an underlay router to resequence packets over lags?

> -- IPv6 zero UDP checksum
> 
>> 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.
> 
> Understood - there's more than one set of scars on this one :-(.  Let's come back
> to this topic after we've resolved everything else, and please keep in mind
> that I tagged this as a minor issue, not a major one (e.g., the above changes
> for [A] and [B] are far more important, IMHO).

Ack. Thanks again.

Dino

> 
> Thanks,
> --David
> 
>> -----Original Message-----
>> From: Dino Farinacci [mailto:[e-mail]]
>> Sent: Wednesday, February 11, 2015 2:19 PM
>> To: Joel M. Halpern
>> Cc: Black, David; Albert Cabellos; Damien Saucez; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11
>> 
>>> 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
>