Hi Hannu, On 08/11/11 10:19, Flinck, Hannu (NSN - FI/Espoo) wrote: > Hello Lorand and the other authors, > > I have following comments to the draft: > > section 2.4 > > You introduce RLOC to RLOC bindings for recursive LISP use case. On the other > hand in draft-ietf-lisp-eid-block and EID block of /16 IPv6 prefix is > introduced with a target of " By defining an IPv6 EID Block is possible to > configure the router so > to natively forward all packets that have not a destination address > in the block, without performing any lookup whatsoever. " > > Clearly this benefit is lost in the recursive LISP use case.
Well, yes and no. Since the RLOC-to-RLOC mapping databases are mostly shared by two ISPs, they are expected to be in the order of several hundred prefixes even after being deaggregated. In that case NERD would be a good fit for the mapping system, and all prefixes can be pushed to the FIB of recursive routers. That way external lookups can be avoided. And if the prefixes are in the FIB, the lookup for each packet takes the same as for non-encapped packets. It is true that the draft mentions NERD only in passing, as potential solution to one of the disadvantages. If we make it the recommended mapping system for this scenario, would that address your concern? When this section was written, the lisp-eid-block draft was not "revived" yet, this is why it's missing from the discussion. Do you think it would be worth mentioning here, with the above explanation? > > Also you introduce "a private database" for RLOC mappings to be used instead > of the global LISP mapping system. Further you recommend that the use of > recursion only between two ISPs. > > > To me this appears quite a heavy arrangement especially when taking account > the main disadvantages you enumerate in the draft. Why can't you just tunnel > (using your favorite tunneling protocol) between the two ISPs? Without any > mapping system. What does the mapping system bring in to the scenario? > Especially when the number of recursion ITRs and ETRs between the two ISPs > are not that many (order of tens I believe). This scenario is not so much offered as a "_most_ ISPs doing inter-ISP TE should do this", but rather as "_many_ ISPs doing inter-ISP TE could gain something from this". With that in mind, manually configuring tunnels from all the tens of recursive routers of ISP A to those of ISP B, and keeping the configuration up to date can also mean a heavy arrangement on the long run. Creating the shared database may have a higher initial cost, but having a single database distribute "dynamic tunnel" configuration to all routers can lower OpEx on the long run. However, the most interesting application of this scenario in my opinion lies in the finer-grained TE knobs offered by LISP: priorities and especially weights. I can imagine an ISP deploying a smart TE engine that can react in real time to changes in traffic volumes on the circuits they have to other peers, and modifying the weights of certain prefixes according to some algorithm to reach the ISP's TE goals. Note also that the disadvantages are mentioned for completeness sake, and all of them have suggestions for (relatively easy) solutions. > > An editorial nit in section 5.4 Migration Summary: > > Acronym PITR-RD has not been opened up anywhere in the draft. Wouldn't it be > simpler (at least more reader friendly) to talk about EID route servers > instead of PITR-RDs? For the 3 columns of the table we used the abbreviated forms of the titles of sections 5.1, 5.2 and 5.3, one for each scenario. Indeed, 5.3 doesn't contain the abbreviation in parentheses, will add that. Many thanks for the feedback! Best regards, -Lori (returning online) > > > > Best regards > Hannu > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of ext > Loránd Jakab > Sent: Monday, July 11, 2011 1:36 PM > To: [email protected] > Subject: Re: [lisp] I-D Action: draft-ietf-lisp-deployment-01.txt > > Folks, > > We moved the PITR scenarios to a new section discussing > coexistence/migration/transition, and evolved the Tier 1 scenario into a > much better PITR route distribution architecture, that will be presented > in Quebec. > > Regards, > Lorand Jakab (on behalf of the draft authors) > > On 07/11/11 12:26, [email protected] wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Locator/ID Separation Protocol >> Working Group of the IETF. >> >> Title : LISP Network Element Deployment Considerations >> Author(s) : Lorand Jakab >> Albert Cabellos-Aparicio >> Florin Coras >> Jordi Domingo-Pascual >> Darrel Lewis >> Filename : draft-ietf-lisp-deployment-01.txt >> Pages : 22 >> Date : 2011-07-11 >> >> This document discusses the different scenarios for the deployment of >> the new network elements introduced by the Locator/Identifier >> Separation Protocol (LISP). >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-lisp-deployment-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-deployment-01.txt >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
