Hi Terry, > -----Original Message----- > From: Terry Manderson [mailto:[email protected]] > Sent: Thursday, September 29, 2011 5:18 PM > To: Templin, Fred L; Joel M. Halpern > Cc: [email protected] > Subject: Re: [lisp] LISP (re-)Charter discussion > > Fred, > > I'm not keen on specifically listing _any_ RFCs in the > charter. It just > doesn't add meaning at this stage of the WG lifecycle, in my opinion. > > How about a simpler: > > A number of approaches are being looked at in parallel in other > contexts. The IRTF RRG examined several proposals, some of > which were > published as IRTF-track Experimental RFCs.
> This provides the reader of the charter with knowledge that > there is a body > of work "out there" and points to the RRG as a place to look > first. Beyond > that we would probably fall into the trap of listing almost > every RFC that > has (had) anything to do with scaling, EID/LOC split, > encapsulation .. .. .. > etc. > > Cheers > Terry > > > On 29/09/11 10:16 PM, "Templin, Fred L" > <[email protected]> wrote: > > > Hi Joel, > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:[email protected]] > >> Sent: Wednesday, September 28, 2011 8:11 PM > >> To: Templin, Fred L > >> Cc: Terry Manderson; [email protected] > >> Subject: Re: [lisp] LISP (re-)Charter discussion > >> > >> Fred, "Authorized" is I think the wrong word to use to describe the > >> publication. Or at least a misleading word. The IRTF > >> process is such > >> that the RG did not actually approve the publication of any of the > >> solutions. The RG Chair sponsored the publication as an > >> output of the > >> RG. IRTF procedures explicitly recognize and allow for multiple > >> minority reports from an RG. > >> > >> I do agree that we should recognize that a number of ideas > have been > >> published as RFCs. And we should probably not be too > specific about > >> what the RG is doing, since that is liable to change. > > > > OK. How does this look for a rewrite: > > > > "A number of approaches have been published in parallel in the > > IRTF and IETF. In particular, the IRTF Routing Research Group > > (RRG) has published recommendations [RFC6115] and design goals > > [RFC6227], and has released three solution proposals for > > publication in IRON [RFC6179], hIPv4 [RFC6306] and > ILNP [ILNP]." > > > > Thanks - Fred > > [email protected] > > > >> Yours, > >> Joel > >> > >> On 9/28/2011 10:20 PM, Templin, Fred L wrote: > >>> Hi Terry, > >>> > >>> Regarding the 5th paragraph of the Draft Charter: > >>> > >>>> A number of approaches are being looked at in parallel in > >> the IRTF and > >>>> IETF. At this time, these proposals are at an early stage. > >>> > >>> This needs to be updated; here is a proposed rewrite: > >>> > >>> "A number of approaches have been published in parallel in the > >>> IRTF and IETF. In particular, the IRTF Routing Research Group > >>> (RRG) has published its recommendations [RFC6115] and design > >>> goals [RFC6227], and has authorized the publication of three > >>> solution proposals in IRON [RFC6179], hIPv4 [RFC6306] and > >>> ILNP [ILNP]." > >>> > >>> Thanks - Fred > >>> [email protected] > >>> > >>>> -----Original Message----- > >>>> From: [email protected] [mailto:[email protected]] On > >>>> Behalf Of Terry Manderson > >>>> Sent: Wednesday, September 21, 2011 5:05 PM > >>>> To: [email protected] > >>>> Subject: [lisp] LISP (re-)Charter discussion > >>>> > >>>> Hi Folks, > >>>> > >>>> In Prague there was no strong consensus on modifying the LISP > >>>> Charter from > >>>> what it currently is, perhaps only updating the existing > >>>> Goals/Milestones. > >>>> > >>>> So no clear decision could be made. What I would like to do > >>>> is push out a > >>>> 'idea generating' draft charter that is _almost_ identical to > >>>> what we have > >>>> today. > >>>> > >>>> You can find the existing charter here: > >>>> https://datatracker.ietf.org/wg/lisp/charter/ > >>>> > >>>> The draft is below. > >>>> > >>>> So in light of such an approach, Joel and I discussed some > >>>> work items that > >>>> came from what was said at the mic in Prague and to us > >> individually. > >>>> > >>>> They are: > >>>> > >>>> * Finish the deployment document > >>>> * Get the two security documents done > >>>> * Get an operational document at least started, which > >> should include > >>>> cache management and ETR synchronization techniques. > >>>> * Either in the second security document, or in complementary > >>>> documents we > >>>> need to evaluate the security threat to cache maintenance, and > >>>> evaluate the applicability and coverage we get from a > reuse of SIDR > >>>> technology. > >>>> > >>>> Is anything not represented here that you believe necessary? > >>>> and conversely > >>>> is there something here that is out of scope in your eyes? > >>>> > >>>> Are there work areas not covered by the draft below which you > >>>> believe should > >>>> be? > >>>> > >>>> Draft Charter > >>>> ------------ > >>>> > >>>> The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) > >>>> rekindled interest in scalable routing and addressing > >>>> architectures for > >>>> the Internet. Among the many issues driving this renewed > >> interest are > >>>> concerns about the scalability of the routing system and > >> the impending > >>>> exhaustion of the IPv4 address space. Since the IAB > >> workshop, several > >>>> proposals have emerged which attempt to address the > >> concerns expressed > >>>> there and elsewhere. In general, these proposals are based on the > >>>> "locator/identifier separation". > >>>> > >>>> The basic idea behind the separation is that the Internet > >> architecture > >>>> combines two functions, routing locators, (where you are > >>>> attached to the > >>>> network) and identifiers (who you are) in one number > space: The IP > >>>> address. Proponents of the separation architecture postulate that > >>>> splitting these functions apart will yield several > >>>> advantages, including > >>>> improved scalability for the routing system. The > separation aims to > >>>> decouple locators and identifiers, thus allowing for efficient > >>>> aggregation of the routing locator space and providing persistent > >>>> identifiers in the identifier space. > >>>> > >>>> LISP supports the separation of the IPv4 and IPv6 address space > >>>> following a network-based map-and-encapsulate scheme > (RFC 1955). In > >>>> LISP, both identifiers and locators are IP addresses. In LISP, > >>>> identifiers are composed of two parts: a "global" portion > >>>> that uniquely > >>>> identifies a particular site and a "local" portion that > >> identifies an > >>>> interface within a site. The "local" portion may be subdivided to > >>>> identify a particular network within the site. For a given > >> identifier, > >>>> LISP maps the "global" portion of the identifier into a set > >>>> of locators > >>>> that can be used by de-capsulation devices to reach the > identified > >>>> interface; as a consequence a host would typically change > >> identifiers > >>>> when it moves from one site to another or whenever it > >> moves from one > >>>> subnet to another within an site. Typically, the same IP > >> address will > >>>> not be used as an identifier and locator in LISP. > >>>> > >>>> LISP requires no changes to end-systems or to most > >> routers. LISP aims > >>>> for an incrementally deployable protocol. > >>>> > >>>> A number of approaches are being looked at in parallel in > >> the IRTF and > >>>> IETF. At this time, these proposals are at an early stage. > >>>> All proposals > >>>> (including LISP) have potentially harmful side-effects > to Internet > >>>> traffic carried by the involved routers, have parts where > >> deployment > >>>> incentives may be lacking, and are NOT RECOMMENDED for > >>>> deployment beyond > >>>> experimental situations at this stage. Many of the proposals have > >>>> components (such as the identifier to locator mapping > >> system) where it > >>>> is not yet known what kind of design alternative is the > >> best one among > >>>> many. > >>>> > >>>> However, despite these issues it would be valuable to > >> write concrete > >>>> protocol specifications and develop implementations that can > >>>> be used to > >>>> understand the characteristics of these designs. The LISP WG is > >>>> chartered to work on the LISP base protocol and any items > >>>> which directly > >>>> impact LISP. The working group will encourage and > >>>> support interoperable LISP implementations as well as defining > >>>> requirements for alternate mapping systems. The Working Group > >>>> will also > >>>> develop security profiles for the ALT and/or other > mapping systems. > >>>> > >>>> It is expected that the results of specifying, implementing, > >>>> and testing > >>>> LISP will be fed to the general efforts at the IETF and IRTF > >>>> (e.g., the > >>>> Routing Research Group) that attempts to understand > which type of a > >>>> solution is optimal. The LISP WG is NOT chartered to > >> develop the final > >>>> or standard solution for solving the routing scalability > >> problem. Its > >>>> specifications are Experimental and labeled with accurate > >> disclaimers > >>>> about their limitations and not fully understood implications for > >>>> Internet traffic. In addition, as these issues are > understood, the > >>>> working group will analyze and document the implications > of LISP on > >>>> Internet traffic, applications, routers, and security. > >> This analysis > >>>> will explain what role LISP can play in scalable routing. > >> The analysis > >>>> should also look at scalability and levels of state required for > >>>> encapsulation, decapsulation, liveness, and so on as well as the > >>>> manageability and operability of LISP. > >>>> > >>>> > >>>> Cheers > >>>> Terry > >>>> > >>>> _______________________________________________ > >>>> lisp mailing list > >>>> [email protected] > >>>> https://www.ietf.org/mailman/listinfo/lisp > >>>> > >>> _______________________________________________ > >>> lisp mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/lisp > >>> > >> > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
