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 <[email protected]> wrote: > 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]> 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]> 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
