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

[Alia Atlas <[e-mail]>]

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

Regards,
Alia

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

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