RE: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 - UDP source port

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

[A] and [B] are handled in other messages.  On UDP source port selection:

> > 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?

This is for ECMP in addition to LAG - if you go this route, please do cite the dart draft (informative reference) for its supporting discussion about transport protocol (mis)behavior in the face of within-flow resequencing.  It would also be helpful to say that a 5-tuple hash is one way to achieve this (and see RFC 6830 for details).

Thanks,
--David

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