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

["Joel M. Halpern" <[e-mail]>]

That proposed text works for me.
Yours,
Joel

On 2/12/15 3:28 AM, Luigi Iannone wrote:
> Hi,
>
> Aren’t we going into to much details for the intro document?
>
> What if we change the sentence in the following way:
>
> OLD (suggested by David)
>
> "in the specific case of a VM/mobile node the EID-prefix should be /32
> or /128 (IPv4 or IPv6 respectively)”
>
> NEW
>
> "In the mobility case the EID-prefix can be as small as a full /32 or
> /128 (IPv4 or IPv6 respectively) depending on the mobility use-case
> (e.g., subnet mobility vs single VM/Mobile node mobility)"
>
>
> Opinions?
>
>
>> On 12 Feb 2015, at 02:59, Jmh.direct <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>> Temeber that an EID prefix represents a site.  A tenant network in a
>> data center is a viable site.  So the prefix as registered for that.
>>  Mobiluty of VMs with the tenant network can be handled internally.
>>
>> Ypu could instead advertise each VM EID.  Tge fact that both cased
>> work makes doing an introductory description a bit tricky.
>>
>> Yours,
>> Joel
>>
>>
>> Sent from my Samsung smartphone on AT&T
>>
>>
>>
>> -------- Original message --------
>> Subject: RE: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11
>> From: "Black, David" <[e-mail] <mailto:[e-mail]>>
>> To: "Jmh.direct" <[e-mail]
>> <mailto:[e-mail]>>,"[e-mail]
>> <mailto:[e-mail]>" <[e-mail]
>> <mailto:[e-mail]>>
>> CC: "[e-mail] <mailto:[e-mail]>"
>> <[e-mail]
>> <mailto:[e-mail]>>,"[e-mail]
>> <mailto:[e-mail]>" <[e-mail]
>> <mailto:[e-mail]>>,"[e-mail]
>> <mailto:[e-mail]>" <[e-mail]
>> <mailto:[e-mail]>>,"[e-mail]
>> <mailto:[e-mail]>" <[e-mail]
>> <mailto:[e-mail]>>,"[e-mail] <mailto:[e-mail]>"
>> <[e-mail] <mailto:[e-mail]>>,"[e-mail]
>> <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>,"Black,
>> David" <[e-mail] <mailto:[e-mail]>>
>>
>>
>> > In the VM case, am entire service network may be moved to the data
>> center, and so the EID block for that set can be moved.
>>
>> For a single VM, that would apply if the VM is using an entire EID
>> block - most individual VMs aren’t/don’t.  Individual /32 and /128
>> addresses are common for individual VMs, so that’s what’s needed in
>> general for individual VM movement.
>>
>> I’d expect the EID block move case to apply for movement of a group of
>> VMs that are using such a block (e.g., as a subnet), but VM live
>> migrations cannot be synchronized in general (cold migrations of
>> powered-off VMs can be, obviously), so even in this case where the
>> entire EID block moves, if live VM migrations are involved, there are
>> intermediate stages where the EID block is split between LISP sites
>> ... and hence /32 and /128 prefixes are still what’s wanted.
>>
>> Thanks,
>> --David
>>
>> *From:*Jmh.direct [mailto:[e-mail]]
>> *Sent:* Wednesday, February 11, 2015 7:19 PM
>> *To:* Black, David; [e-mail] <mailto:[e-mail]>
>> *Cc:* [e-mail] <mailto:[e-mail]>;
>> [e-mail] <mailto:[e-mail]>;
>> [e-mail] <mailto:[e-mail]>;
>> [e-mail] <mailto:[e-mail]>; [e-mail]
>> <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>> *Subject:* RE: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11
>> *Importance:* Low
>>
>> I thinl we may want to separate VM mobility from mobile devices.  Om
>> the VM case, am entire setvice network may be moved to the data
>> center, and so the EID block for that set can be moved.  In the case
>> of individually mobile debices or some vatiations on data center
>> mobility, there is a need to mske sure the full EID is advertised in
>> the mapping system.
>>
>> Yours,
>>
>> Joel
>>
>>
>>
>> Sent from my Samsung smartphone on AT&T
>>
>>
>>
>>
>> -------- Original message --------
>> Subject: RE: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11
>> From: "Black, David" <[e-mail] <mailto:[e-mail]>>
>> To: "[e-mail] <mailto:[e-mail]>"
>> <[e-mail] <mailto:[e-mail]>>
>> CC: Dino Farinacci <[e-mail]
>> <mailto:[e-mail]>>,"Joel M. Halpern" <[e-mail]
>> <mailto:[e-mail]>>,Damien Saucez <[e-mail]
>> <mailto:[e-mail]>>,"[e-mail]
>> <mailto:[e-mail]>" <[e-mail]
>> <mailto:[e-mail]>>,"[e-mail] <mailto:[e-mail]>"
>> <[e-mail] <mailto:[e-mail]>>,"[e-mail]
>> <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>,"Black,
>> David" <[e-mail] <mailto:[e-mail]>>
>>
>> Hi Albert,
>>
>> As noted below, on the EID prefix for mobility issue, a simple
>> statement in Section 5 to the effect that “in the specific case of a
>> VM/mobile node the EID-prefix should be /32 or /128 (IPv4 or IPv6
>> respectively)” will suffice.  Details on what to do when that advice
>> is ignored can be left to other documents.
>>
>> Thanks,
>> --David
>>
>> *From:*Albert Cabellos [mailto:[e-mail]]
>> *Sent:* Wednesday, February 11, 2015 6:33 PM
>> *To:* Black, David
>> *Cc:* Dino Farinacci; Joel M. Halpern; Damien Saucez; [e-mail]
>> <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>;
>> [e-mail] <mailto:[e-mail]>
>> *Subject:* Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11
>>
>> 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]
>> <mailto:[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] <mailto:[e-mail]>]
>> > Sent: Wednesday, February 11, 2015 2:19 PM
>> > To: Joel M. Halpern
>> > Cc: Black, David; Albert Cabellos; Damien Saucez;[e-mail] <mailto:[e-mail]>;
>> >[e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[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
>>
>