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

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

+1 - the crucial concept to introduce (IMHO) is that the "prefix" can be a single IP address.

Thanks,
--David


> -----Original Message-----
> From: Joel M. Halpern [mailto:[e-mail]]
> Sent: Thursday, February 12, 2015 9:20 AM
> To: Luigi Iannone
> Cc: Black, David; [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Damien Saucez; [e-mail]
> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11
> 
> 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
> >>
> >