LISP is a bit unique in that it can enable many applications concurrently. If the effort for each application is spun off to different groups, each thread will evolve independently and with that the cohesion of the protocol may quickly be lost.
IMO it is important that the WG retains ownership/authority over all things LISP. -v > -----Original Message----- > From: lisp-boun...@ietf.org [mailto:lisp-boun...@ietf.org] On Behalf Of > Terry Manderson > Sent: Monday, September 26, 2011 9:17 PM > To: Dino Farinacci (dino) > Cc: lisp@ietf.org > Subject: Re: [lisp] LISP (re-)Charter discussion > > Thanks Dino, > > I encourage all LISP WG members to reflect on the questions below and voice > an opinion. > > To paraphrase what Dino has written, one proposal (and Dino correct me if > I've oversimplified) is that the LISP WG should become a working group that > contains ALL things LISP. So wherever a body of work uses LISP > encapsulation, or LISP mapping it may gravitate to here to maintain LISP > interoperability and (where appropriate) protocol cohesion. > > ..discuss. > > :) > > Cheers > Terry > > > On 23/09/11 3:24 AM, "Dino Farinacci" <d...@cisco.com> wrote: > > > Terry, what I would like to know first and foremost, before adding any > > specific feature or use-cases to the charter is if they *should* belong > in the > > LISP working group charter versus being owne by another working group. > And > > what the working group thinks about this. I will give some examples to > get > > some clarity and to be more specific. > > > > (1) LISP could be used for many data-center use-cases. > > (2) LISP could be used for device mobility. > > (3) LISP could be used as a IPv6 coexistence solution while delivering > route > > table reduction and low opex multihoming. > > (4) LISP could be used as a VPN solution. > > (5) The mapping database could be used for other applications like > keeping > > track of multicast group membership. > > > > So, to enumerate each one: > > > > For (1), does the LISP WG take this on or is there a data-center specific > > protocol solution working group (ARMD is not that working group because > it is > > a requirement definition working group)? > > > > For (2), the MOBOPTs IRTF research group seem to take interest in LISP- > MN. > > Does it do the initial work and have it spin off a mobility working > group, > > which there are many already. To add, there is a cross-product issue too > since > > LISP-Multicast can run in a LISP-MN implementation and there is a > multimob > > working group already established. > > > > For (3), there are zillions of solutions and places where this occurs > over the > > last decade, I would suggest not spinning another working group for this > and > > have the LISP working group be "address-family" agnostic which would also > > include MAC addressing as a address-family as well a GPS coordinates. > > > > For (4), again, coupled with (3), LISP can do L2-over-L3, L3-over-L3, as > well > > as the other 2 combinations, does the VPN use-case stay in the LISP > working > > group or is it fragmented to be taken to each L2VPN and L3VPN working > groups. > > > > For (5), we do not want to error where everything is put into DNS > (because it > > is the only applicaiton level wide-area/multi-organizational distributed > > database). In our case the mapping database. And moreoever, if the use- > case > > functionality is distributed to other working groups, will there be > design > > change requests to the mapping database design coming from too many > source > > points. > > > > As you can see, this can get very complex and confusing and could result > in > > design fragmentation and opportunity for competitive proposals. All which > turn > > out to add more inefficiencies to the protocol design process which > nearly > > always results in undeployable compromises. > > > > Dino > > > > On Sep 21, 2011, at 5:04 PM, Terry Manderson wrote: > > > >> 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 > >> lisp@ietf.org > >> https://www.ietf.org/mailman/listinfo/lisp > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
