Subject: Re: [lisp] I-D Action: draft-ietf-lisp-deployment-01.txt

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 11 Aug 2011 11:19:42 +0300

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. 

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). 

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?

Best regards
Hannu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Loránd Jakab
Sent: Monday, July 11, 2011 1:36 PM
To: [email-masked]
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-masked] 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-masked]
> https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: Lori Jakab <[email-masked]>
Date: Mon, 29 Aug 2011 00:13:02 +0200

Hi Hannu,

> 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?

> 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) bet…

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.

> 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)