Hi Victor, I think authority and ownership are stretches of the vocabulary.
I am concerned about protocol cohesion, and I'd like the WG to be the preferred place (i.e "gravitate") for LISP related work. But saying that LISP is the locus of control for all this LISP might be a tad far :) I think we should also keep in mind that LISP is heading for Experimental publication which means any work that uses LISP in the majority at this point in time will probably/possibly also end up as Experimental given downref considerations. Cheers Terry On 27/09/11 3:02 PM, "Victor Moreno (vimoreno)" <vimor...@cisco.com> wrote: > 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
