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.
I would agree if the charter could point to a webpage that lists the RRG RFC publications, i.e., in the same way that IETF working group wepages do. But, the only RRG webpages I have found have outdated and incomplete information, and do not cite the RFC publications. So, I would prefer to include the text I proposed, or something close to it, since the work is so closely related to LISP. > 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. I don't think this would become a slippery slope. LISP spun off out of the RRG albeit in a slightly different manner than did IRON, hIPv4 and ILNP. But, as of this time (and for the forseeable future AFAICT) those are the only four solution proposals to emerge out of the RRG. Thanks - Fred [email protected] > 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
