+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:jmh@xxxxxxxxxxxxxxx] > Sent: Thursday, February 12, 2015 9:20 AM > To: Luigi Iannone > Cc: Black, David; acabello@xxxxxxxxxx; ops-dir@xxxxxxxx; lisp@xxxxxxxx; > farinacci@xxxxxxxxx; Damien Saucez; ietf@xxxxxxxx > 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 <jmh.direct@xxxxxxxxxxxxxxx > >> <mailto:jmh.direct@xxxxxxxxxxxxxxx>> 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" <david.black@xxxxxxx <mailto:david.black@xxxxxxx>> > >> To: "Jmh.direct" <jmh.direct@xxxxxxxxxxxxxxx > >> <mailto:jmh.direct@xxxxxxxxxxxxxxx>>,"acabello@xxxxxxxxxx > >> <mailto:acabello@xxxxxxxxxx>" <acabello@xxxxxxxxxx > >> <mailto:acabello@xxxxxxxxxx>> > >> CC: "farinacci@xxxxxxxxx <mailto:farinacci@xxxxxxxxx>" > >> <farinacci@xxxxxxxxx > >> <mailto:farinacci@xxxxxxxxx>>,"jmh@xxxxxxxxxxxxxxx > >> <mailto:jmh@xxxxxxxxxxxxxxx>" <jmh@xxxxxxxxxxxxxxx > >> <mailto:jmh@xxxxxxxxxxxxxxx>>,"damien.saucez@xxxxxxxx > >> <mailto:damien.saucez@xxxxxxxx>" <damien.saucez@xxxxxxxx > >> <mailto:damien.saucez@xxxxxxxx>>,"ops-dir@xxxxxxxx > >> <mailto:ops-dir@xxxxxxxx>" <ops-dir@xxxxxxxx > >> <mailto:ops-dir@xxxxxxxx>>,"ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>" > >> <ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>>,"lisp@xxxxxxxx > >> <mailto:lisp@xxxxxxxx>" <lisp@xxxxxxxx <mailto:lisp@xxxxxxxx>>,"Black, > >> David" <david.black@xxxxxxx <mailto:david.black@xxxxxxx>> > >> > >> > >> > 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:jmh.direct@xxxxxxxxxxxxxxx] > >> *Sent:* Wednesday, February 11, 2015 7:19 PM > >> *To:* Black, David; acabello@xxxxxxxxxx <mailto:acabello@xxxxxxxxxx> > >> *Cc:* farinacci@xxxxxxxxx <mailto:farinacci@xxxxxxxxx>; > >> jmh@xxxxxxxxxxxxxxx <mailto:jmh@xxxxxxxxxxxxxxx>; > >> damien.saucez@xxxxxxxx <mailto:damien.saucez@xxxxxxxx>; > >> ops-dir@xxxxxxxx <mailto:ops-dir@xxxxxxxx>; ietf@xxxxxxxx > >> <mailto:ietf@xxxxxxxx>; lisp@xxxxxxxx <mailto:lisp@xxxxxxxx> > >> *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" <david.black@xxxxxxx <mailto:david.black@xxxxxxx>> > >> To: "acabello@xxxxxxxxxx <mailto:acabello@xxxxxxxxxx>" > >> <acabello@xxxxxxxxxx <mailto:acabello@xxxxxxxxxx>> > >> CC: Dino Farinacci <farinacci@xxxxxxxxx > >> <mailto:farinacci@xxxxxxxxx>>,"Joel M. Halpern" <jmh@xxxxxxxxxxxxxxx > >> <mailto:jmh@xxxxxxxxxxxxxxx>>,Damien Saucez <damien.saucez@xxxxxxxx > >> <mailto:damien.saucez@xxxxxxxx>>,"ops-dir@xxxxxxxx > >> <mailto:ops-dir@xxxxxxxx>" <ops-dir@xxxxxxxx > >> <mailto:ops-dir@xxxxxxxx>>,"ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>" > >> <ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>>,"lisp@xxxxxxxx > >> <mailto:lisp@xxxxxxxx>" <lisp@xxxxxxxx <mailto:lisp@xxxxxxxx>>,"Black, > >> David" <david.black@xxxxxxx <mailto:david.black@xxxxxxx>> > >> > >> 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:albert.cabellos@xxxxxxxxx] > >> *Sent:* Wednesday, February 11, 2015 6:33 PM > >> *To:* Black, David > >> *Cc:* Dino Farinacci; Joel M. Halpern; Damien Saucez; ops-dir@xxxxxxxx > >> <mailto:ops-dir@xxxxxxxx>; ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>; > >> lisp@xxxxxxxx <mailto:lisp@xxxxxxxx> > >> *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 <david.black@xxxxxxx > >> <mailto:david.black@xxxxxxx>> 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:farinacci@xxxxxxxxx > <mailto:farinacci@xxxxxxxxx>] > >> > Sent: Wednesday, February 11, 2015 2:19 PM > >> > To: Joel M. Halpern > >> > Cc: Black, David; Albert Cabellos; Damien Saucez;ops-dir@xxxxxxxx > <mailto:ops-dir@xxxxxxxx>; > >> >ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>; lisp@xxxxxxxx <mailto:lisp@xxxxxxxx> > >> > 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 > >> > >