Hi Alia, > On 22 Oct 2015, at 16:16, Alia Atlas <[email protected]> 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 <[email protected] > <mailto:[email protected]>> wrote: > Hi Alia, > > thanks for your comments, see inline for our replies. > > ciao > > Luigi > > > > On 21 Oct 2015, at 22:41, Alia Atlas <[email protected] > > <mailto:[email protected]>> 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]).” > > > > > > > >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
