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

[Alia Atlas <[e-mail]>]

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

On Thu, Oct 22, 2015 at 5:58 AM, Luigi Iannone <[e-mail]> wrote:

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