Re: [lisp] Alia Atlas' Abstain on draft-ietf-lisp-impact-04: (with COMMENT)

[Luigi Iannone <[e-mail]>]

Hi Alia,

thanks for your comments, see inline for our replies.

ciao

Luigi


> On 21 Oct 2015, at 22:41, Alia Atlas <[e-mail]> wrote:
> 

[snip]
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> The opening of this draft 
> "The Locator/Identifier Separation Protocol (LISP) relies on three
>   principles to improve the scalability properties of Internet routing:
>   address role separation, encapsulation, and mapping.  The main goal
>   of LISP is to make the routing infrastructure more scalable by
>   reducing the number of prefixes announced in the Default Free Zone
>   (DFZ)."
> is targeted at solving the Internet scalability issue for Internet
> routing.
> While the document goes into some details about rather large unknowns
> and issues observed, it does not have any indications or caveats up
> front that this is still experimental work - certainly as far as solving
> this
> Internet-scale problem.
> 
> At a minimum, I think there need to be clear caveats on the experimental
> nature, on the aspects still to be understood, and on the complexity and
> concerns around the operational and security aspects.
> 
> While LISP is a really neat idea and it's good to see how far work and
> research on it has progressed, this document reads much more like
> marketing than something discussing the engineering and operational
> trade-offs.
> 

We did our best to change the tone of the document, 
trying to be as neutral as possible and just state observed facts.
If something still slipped in please point us to the right spot and we’ll fix it.

> 1) There is no discussion of what the "mapping system" is and I think
> that some of the discussion is assuming the use of BGP, but it's a bit
> hard
> to tell.  At a minimum, it'd be good to clarify whether an
> Internet-scale
> deployment must use the same mapping system and what the trade-offs
> there are.

Fair enough. This is actually an open issue that has been just tackled by M. Boucaidair in his recent drafts.

I would propose to saccutally modify in Sec. 5.2 the Business/Operational-related paragraph.

That paragraph now ends with:

	“….    how will the EIDs be
         allocated to allow aggregation and hence scalability of the
         mapping system?  Who will operate the mapping system
         infrastructure and for what benefits?”

We can append the questions:

	“What is several operators run different mapping systems?
	How will they interoperate or share mapping information?”



> 
> 2) In Sec 4.1, "When there are several RLOCs, the ITR selects the one
> with
>   the highest priority and sends the encapsulated packet to this RLOC.
>   If several such RLOCs exist, then the traffic is balanced
>   proportionally to their weight among the RLOCs with the lowest
>   priority value."
> 
> It is unclear whether the "highest priority" means the lowest priority
> value.
> Please clarify because it incorrectly sounds like the highest priority
> RLOC
> is picked - unless there are multiple in which case load-balancing among
> the
> lowest priority value RLOCs is done.

Excellent catch, thanks. The sentence is indeed misleading. 
The second sentence should be:
	
	“If several RLOCs with the highest priority exist, then the traffic 
	is balanced proportionally to their weight among such RLOCs."

> 
> 3) Sec 5.1 "Proxies cause what is referred to as path stretch and make
>   troubleshooting harder."  This doesn't actually describe what path
> stretch
> is in any way.  I can guess from the name, but that's not sufficient.

Sentence can be modified as follows, so to provide a definition of path stretch:

	"Proxies cause what is referred to as path stretch (i.e., a lengthening 
	of the path compared to the topological shortest-path) and make 
	 troubleshooting harder."


> 
> 4) In Sec 5.2: "Deployment in the beta network has shown that LISP+ALT
>         ([RFC6836], [CCR13]) was not easy to maintain and control,
>         which explains the migration to LISP-DDT [I-D.ietf-lisp-ddt]"
> Can you give a reference or indicate what the benefits of DDT are as
> compared to ALT in this context?

That is the content of [CCR13], but I agree that with the current 
formulation is not clear that the reader can find such information in it.
The text can be modified as follows:

	"Deployment in the beta network has shown that LISP+ALT
        ([RFC6836]) was not easy to maintain and control ([CCR13]),
        which explains the migration to LISP-DDT [I-D.ietf-lisp-ddt],
	based on a massively distributed and hierarchical approach 
	([CCR13]).”

	
> 
>