> 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.
Right, I was not direct about this point but it can be inferred from below. Thanks for clarifying Terry. Dino > > ..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
