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

From: "Alia Atlas" <[email-masked]>
Date: Wed, 21 Oct 2015 13:41:39 -0700

Alia Atlas has entered the following ballot position for
draft-ietf-lisp-impact-04: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/

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

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.

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.

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.

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?

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 22 Oct 2015 11:58:22 +0200

Hi Alia,

thanks for your comments, see inline for our replies.

ciao

Luigi

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

[snip]

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.

> deployment must use the same mapping system and what the trade-offs

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

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

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

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

---

From: Alia Atlas <[email-masked]>
Date: Thu, 22 Oct 2015 10:16:16 -0400

Hi Luigi,

Those fixes look good.

For the tone of the draft, I think the primary thing that I was looking for
was some context and indication in the introduction around the experiments
and experimental nature.

Given that the WG is willing to admit in the rechartering that trying to
solve
the general Internet routing scaling problem is not a continuing target for
LISP, I'd be interested in some text describing a combination of
"When invented, LISP was targeted at solving the Internet routing scaling
problem.  There have now been years of implementations and experiments
examining the impact and open questions of using LISP to improve
inter-domain routing scalability.  This document describes, at a high level,
the impacts and open questions still seen.  This information is particularly
useful for considering future approaches and to support further
experimentation
to clarify some large open questions (e.g. around the operations)."

Beyond that, there was one section which was a "without lisp, ..." versus
a "with lisp"  that struck me as incorrect and assuming that the only
solution
to the problem was lisp.  Changing it to "currently" or "as commonly
implemented"
would help.

Thanks for considering my comments.

Regards,
Alia

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 22 Oct 2015 16:19:52 +0200

Hi Alia,

> On 22 Oct 2015, at 16:16, Alia Atlas <[email-masked]> wrote:
> 
> Hi Luigi,
> 
> Those fixes look good.
> 
> Given that the WG is willing to admit in the rechartering that trying to solve
> useful for considering future approaches and to support further experimentation

This look great to me. This can be added to the document. 

thanks

> a "with lisp"  that struck me as incorrect and assuming that the only solution
> to the problem was lisp.  Changing it to "currently" or "as commonly implemented"
> would help.
> 

I see. I’ll check that as well and change the tone as you suggested.

Thanks

ciao

Luigi

> On Thu, Oct 22, 2015 at 5:58 AM, Luigi Iannone <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Alia,
> 
> > On 21 Oct 2015, at 22:41, Alia Atlas <[email-masked] <mailto:[email-masked]>> wrote:
> >
> 
> [snip]

---

From: Alia Atlas <[email-masked]>
Date: Thu, 22 Oct 2015 10:21:59 -0400

Thank you.  That would make me much happier with seeing this
be published.

Regards,
Alia