My first thought here is that OTP simply gives network designers a new, useful tool in their toolbox. There's not a lot to condemn this approach, but let's consider a few things.
Like any overlay, LISP introduces packet overhead (i.e., you're taking a packet and sticking a wrapper around it, making the packet bigger than it was). Therefore, the packet maximum transmission unit (MTU) size must be considered. However, as the interfaces carrying the encapsulated traffic are SP-facing, this might not be a huge concern. Ask your provider to support oversized packets, and off you go--well, at least in theory it's that easy. In reality, it could be a bit of a challenge to accomplish this with your service provider.
Alternatively, a designer might need to implement path MTU discovery or rewrite TCP maximum segment size (MSS) to avoid fragmentation issues at the customer router sitting at the edge of the SP cloud.
Another concern that popped in my head is that the EIGRP OTP route reflector appears to be a single point of failure, but documentation is scant on OTP thus far so I don't know for sure. As the RR is such a key component of the OTP design as well as a critical component for scaling the solution, my gut feeling is that there's probably a mechanism for RR redundancy. I just didn't happen to see any evidence of such a thing in the material I reviewed.
An additional drawback could be that EIGRP OTP doesn't support multicast traffic at this point. That's not going to be a roadblock to OTP adoption for many organizations, but since large multicast trees (including ones that traverse a SP cloud in some way) are increasingly common, this could cause OTP to fail the requirements of some networks in the short term. Multicast support is road mapped for OTP.
Another point to consider: To scale to very high throughput requirements, encapsulation and decapsulation operations should be performed in hardware. Customers evaluating EIGRP OTP will need to consider whether the combination of hardware and software they want to run OTP on will support the data rates they require. It's not yet clear to me which of Cisco's myriad platforms will eventually support OTP, and of those platforms, which of them could support LISP encapsulation in hardware.
That's not to say that OTP is a non-starter if the encapsulation operation is punted to the device CPU on a given platform. If there's enough CPU in the device to handle the required throughput without impacting the device negatively, then that's a valid solution.
Cisco is shipping OTP now on IOS XE on the ASR 1K platform. In November, Cisco expects to ship OTP on classic IOS in the Catalyst 3K, 4K and 6K products. I have no information on shipping OTP for the ISR router platform, but my best guess is that it will be a Cisco priority, as many customers position the ISR platform as a WAN edge router. Speculating again, I suspect adding this feature to NX-OS is a somewhat lower priority for Cisco, as Nexus hardware is less likely to be positioned at the WAN edge. However, there are use cases I can conceive of for OTP on Nexus, and interestingly, there's at least one Nexus 7000 series line card that can handle LISP in hardware.
What do you think of OTP? Is it something your organization could use? Share your thoughts in the comments section below.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
Maintaining existing network infrastructures often incurs huge technical debt before newer technologies are adopted over time.
Amid ongoing regional uncertainties, telecom infrastructure in the Middle East has expand to include terrestrial low-latency network infrastructure, which offers resilience and agility in navigating political complexities without relying solely on undersea networks.
