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

[Albert Cabellos <[e-mail]>]

Hi David

Thanks for your comments, I am parsing them and I´ll suggest new text
aiming to address them ASAP.

I would also like to better understand [A] before doing this.

With LISP an EID-preifx can have an arbitrary length and can move (i.e.,
change its RLOC bindings), in the specific case of a VM/mobile node the
EID-prefix should be /32 or /128 (IPv4 or IPv6 respectively). What doesn't
work is the mobility of a node (assigned with a /32 or /128) *within* a
coarser EID-prefix, in this case you need to split the prefix into more
specifics and register them independently in the Mapping System,
effectively creating new EID-prefixes.

Please let me know if this clarifies your comment, in this case I will
suggest new text for Section 5.

Albert



On Thu, Feb 12, 2015 at 12:07 AM, Black, David <[e-mail]> wrote:

> 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.
>
> 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.
>
> 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.
>
> > >> [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
> 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):
>
> > 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.
>
> ---
> 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.
>
> > >> 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.
>
> > >> - 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
> 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.
>
> -- 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).
>
> 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
>
>