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

[Luigi Iannone <[e-mail]>]

Hi Alia,

> On 22 Oct 2015, at 16:16, Alia Atlas <[e-mail]> wrote:
> 
> 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)."
> 

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

thanks


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

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

Thanks

ciao

Luigi

> Thanks for considering my comments.
> 
> Regards,
> Alia
> 
> On Thu, Oct 22, 2015 at 5:58 AM, Luigi Iannone <[e-mail] <mailto:[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] <mailto:[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]).”
> 
> 
> >
> >
> 
>