Re: [lisp] LISP (re-)Charter discussion
Hi Marshal, Previous charter discussions suggested that it wasn't necessary to include an outside webpage for 'further' reading, I tend to agree as outside pages (thus not tools based) tend to date really quickly if not actively maintained. That said, if there is a page that does cover _all_ [1] that auxiliary material in one place I'd be happy to look, review, and reconsider by reopening the WG discussion. [1] implementations, research papers, experimental work, additional works etc. Terry On 3/12/11 2:38 AM, "Marshall Eubanks" wrote: > Is there (or could there be) a link outside web page that could > contain auxiliary material, such as research papers, > that may be produced as the work progresses ? > > Regards > Marshall > > On Thu, Dec 1, 2011 at 8:26 PM, Terry Manderson > wrote: >> After a receiving the suggestions from Yakov and John, emailing some ADs, >> the draft charter is as follows: >> >> Please review, and highlight any areas missed. I'd like to close this off by >> next Friday (9th Dec), and pass to our AD. >> >> 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 other >> contexts. The IRTF RRG examined several proposals, some of which were >> published as IRTF-track Experimental RFCs. >> >> The LISP WG is chartered to work on the LISP base protocol and any items >> which directly impact LISP including any base protocol changes required to >> enable VPN and mobile topologies (precise operational definitions of >> these topologies should be left for IETF WGs focused on these technologies). >> 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 LISP >> and the various LISP 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. >> >> >>
Re: [lisp] LISP (re-)Charter discussion
Obviously the discussion has been on-going. I have posted a latest draft. I think that draft sets a fair balance between LISP, and esuring LISP is interoperable when/if other technologies are added to it, and the other ietf work groups that have expertise in such areas. Something that I am interested in getting the WG's opinion on is the school of thought that since the IAB routing workshop (RFC 4984) the growth of the routing system has been near predicable and linear in trend. I'm not siding with any particular viewpoint yet, except to highlight that at some stage the IAB could revise its stance if it finds itself in agreement with that observation. This may have impact on the LISP charter. Cheers Terry On 4/12/11 1:46 AM, "Albert Cabellos" wrote: > In my humble opinion we should discuss what is the charter of this WG, if > someone in another WG uses/extends LISP for VPN or mobility is his/her choice. > This should not prevent that this WG could also work on such applications, if > there are enough volunteers. > Further, and as Terry points out, LISP is experimental and hence, any L2/L3 > VPN extensions will (most likely) end up being also experimental. > Given that I support the initial wording: > ³The LISP WG is chartered to work on the LISP base protocol and any item which > directly impact LISP including any base protocol changes required to enable > VPN and mobile topologies (precise operational definitions of these topologies > should be left for IETF WGs focused on these technologies).² > Albert > > On 02/12/2011, at 16:54, Yakov Rekhter wrote: > >> Terry, >> >>> After a receiving the suggestions from Yakov and John, emailing some ADs, >>> the draft charter is as follows: >>> >>> Please review, and highlight any areas missed. I'd like to close this off by >>> next Friday (9th Dec), and pass to our AD. >>> >>> 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 other >>> contexts. The IRTF RRG examined several proposals, some of which were >>> published as IRTF-track Experimental RFCs. >>> >>> The LISP WG is chartered to work on the LISP base protocol and any items >>> which directly impact LISP including any base protocol changes required to >>> enable VPN and mobile topologies (precise operational definitions of >>> these topologies should be left for IETF WGs focused on these technologies). >> >> With respect to chartering LISP WG to work on the LISP "base protocol >> changes required to enable VPN", if these changes have to do with >> enabling L2 VPNs, then such work should be done in L2VPN WG. If >> these changes have to do with enabling L3 VPN, then such work should >> be done in L3VPN WG. In both of these cases the outcome of this work >> could be reviewed by the LISP WG. >>
Re: [lisp] LISP (re-)Charter discussion
Yakov, On 6/12/11 5:30 AM, "Yakov Rekhter" wrote: > How about: > >The LISP WG is chartered to work on the LISP base protocol and any >items which directly impact LISP protocol structures and are related >to using LISP for improving Internet routing scalability. > >In addition, if work done by some other IETF WG requires changes >in the LISP base protocol or any items which directly impact LISP >protocol structures, then the LISP WG is chartered to work on such >changes. > > The second paragraph is to reflect the point you made above, namely: > Fine with me. The current draft now stands as: 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 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 other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG is chartered to work on the LISP base protocol and any items which directly impact LISP protocol structures and are related to using LISP for improving Internet routing scalability. In addition, if work done by some other IETF WG requires changes in the LISP base protocol or any items which directly impact LISP protocol structures, then the LISP WG is chartered to work on such changes. 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 LISP and the various LISP 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. Goals and Milestones Jun 2012Forward draft-ietf-lisp-mib to the IESG Jun 2012Forward draft-ietf-lisp-sec to the IESG Jun 2012Forward to the IESG an operational document which should include cache management and ETR synchronization techniques (draft-ietf-lisp-deployment). Dec 2013Publish an example cache management specification. Dec 2013Forward to the IESG an evaluation of the security threat to cache maintenance (draft-ietf-lisp-threats) Dec 2013Forward to the IESG a document addressing the areas which require further experimentation. Jun 2014Evaluate the applicability and coverage for LISP from a reuse of SIDR technology. Jun 2014Summarize results of specifying, implementing, and testing LISP and forward to IESG and/or IRTF. Jun 2014Analyze and document the implications of LISP deployments in Internet topologies and forward to IESG for publication. Dec 2014Re-charter or close ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
Terry, > Yakov, > > On 3/12/11 1:54 AM, "Yakov Rekhter" wrote: > > >> > >> The LISP WG is chartered to work on the LISP base protocol and any items > >> which directly impact LISP including any base protocol changes required to > >> enable VPN and mobile topologies (precise operational definitions of > >> these topologies should be left for IETF WGs focused on these technologies ). > > > > With respect to chartering LISP WG to work on the LISP "base protocol > > changes required to enable VPN", if these changes have to do with > > enabling L2 VPNs, then such work should be done in L2VPN WG. If > > these changes have to do with enabling L3 VPN, then such work should > > be done in L3VPN WG. In both of these cases the outcome of this work > > could be reviewed by the LISP WG. > > > > I understand your point, however that doesn't seem to align with current > IETF practice. I am perfectly comfortable to see the definition of > operational aspects and any other work done which doesn't change the base > spec handled by other work groups that specialize in such areas (VPN or > mobility). This is what I discussed with the ADs. If a change is required in > the LISP fields, packet structure, mapping system or other substrate defined > here to enable those WGs to take up such work items - then those changes > should occur here. Ok. > This modus operandi is the same as having IDR fix the AS0 definition, or > allow BGP to carry larger payloads, for BGPSEC instead of having SIDR do it > - and potentially getting it wrong. > > > The same should apply to work on enaling "mobile topoligies". > > > > With this in mind I propose to replace the above sentence with the > > following: > > > > The LISP WG is chartered to work on the LISP base protocol and any items > > which directly impact LISP and are related to using LISP for improving > > Internet routing scalability. > > > > How about: > > The LISP WG is chartered to work on the LISP base protocol and any items > which directly impact LISP protocol structures or are related to using LISP > for improving Internet routing scalability. > How about: The LISP WG is chartered to work on the LISP base protocol and any items which directly impact LISP protocol structures and are related to using LISP for improving Internet routing scalability. In addition, if work done by some other IETF WG requires changes in the LISP base protocol or any items which directly impact LISP protocol structures, then the LISP WG is chartered to work on such changes. The second paragraph is to reflect the point you made above, namely: I am perfectly comfortable to see the definition of operational aspects and any other work done which doesn't change the base spec handled by other work groups that specialize in such areas (VPN or mobility). This is what I discussed with the ADs. If a change is required in the LISP fields, packet structure, mapping system or other substrate defined here to enable those WGs to take up such work items - then those changes should occur here. Yakov. ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
Yakov, On 3/12/11 1:54 AM, "Yakov Rekhter" wrote: >> >> The LISP WG is chartered to work on the LISP base protocol and any items >> which directly impact LISP including any base protocol changes required to >> enable VPN and mobile topologies (precise operational definitions of >> these topologies should be left for IETF WGs focused on these technologies). > > With respect to chartering LISP WG to work on the LISP "base protocol > changes required to enable VPN", if these changes have to do with > enabling L2 VPNs, then such work should be done in L2VPN WG. If > these changes have to do with enabling L3 VPN, then such work should > be done in L3VPN WG. In both of these cases the outcome of this work > could be reviewed by the LISP WG. > I understand your point, however that doesn't seem to align with current IETF practice. I am perfectly comfortable to see the definition of operational aspects and any other work done which doesn't change the base spec handled by other work groups that specialize in such areas (VPN or mobility). This is what I discussed with the ADs. If a change is required in the LISP fields, packet structure, mapping system or other substrate defined here to enable those WGs to take up such work items - then those changes should occur here. This modus operandi is the same as having IDR fix the AS0 definition, or allow BGP to carry larger payloads, for BGPSEC instead of having SIDR do it - and potentially getting it wrong. > The same should apply to work on enaling "mobile topoligies". > > With this in mind I propose to replace the above sentence with the > following: > > The LISP WG is chartered to work on the LISP base protocol and any items > which directly impact LISP and are related to using LISP for improving > Internet routing scalability. > How about: The LISP WG is chartered to work on the LISP base protocol and any items which directly impact LISP protocol structures or are related to using LISP for improving Internet routing scalability. Cheers Terry ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
In my humble opinion we should discuss what is the charter of this WG, if someone in another WG uses/extends LISP for VPN or mobility is his/ her choice. This should not prevent that this WG could also work on such applications, if there are enough volunteers. Further, and as Terry points out, LISP is experimental and hence, any L2/L3 VPN extensions will (most likely) end up being also experimental. Given that I support the initial wording: “The LISP WG is chartered to work on the LISP base protocol and any item which directly impact LISP including any base protocol changes required to enable VPN and mobile topologies (precise operational definitions of these topologies should be left for IETF WGs focused on these technologies).” Albert On 02/12/2011, at 16:54, Yakov Rekhter wrote: Terry, After a receiving the suggestions from Yakov and John, emailing some ADs, the draft charter is as follows: Please review, and highlight any areas missed. I'd like to close this off by next Friday (9th Dec), and pass to our AD. 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 other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG is chartered to work on the LISP base protocol and any items which directly impact LISP including any base protocol changes required to enable VPN and mobile topologies (precise operational definitions of these topologies should be left for IETF WGs focused on these technologies). With respect to chartering LISP WG to work on the LISP "base protocol changes required to enable VPN", if these changes have to do with enabling L2 VPNs, then such work should be done in L2VPN WG. If these changes have to do with enabling L3 VPN, then such work should be done in L3VPN WG. In both of these cases the outcome of this work could be reviewed by the LISP WG. The same should apply to work on enaling "mobile topoligies". With this in mind I propose to replace the above sentence with the following: The LISP WG is chartered to work on the LISP base protocol and any items which directly impact LISP and are related to using LISP for improving Internet routing scalability. Yakov. 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 LISP and the various LISP 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 E
Re: [lisp] LISP (re-)Charter discussion
Is there (or could there be) a link outside web page that could contain auxiliary material, such as research papers, that may be produced as the work progresses ? Regards Marshall On Thu, Dec 1, 2011 at 8:26 PM, Terry Manderson wrote: > After a receiving the suggestions from Yakov and John, emailing some ADs, > the draft charter is as follows: > > Please review, and highlight any areas missed. I'd like to close this off by > next Friday (9th Dec), and pass to our AD. > > 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 other > contexts. The IRTF RRG examined several proposals, some of which were > published as IRTF-track Experimental RFCs. > > The LISP WG is chartered to work on the LISP base protocol and any items > which directly impact LISP including any base protocol changes required to > enable VPN and mobile topologies (precise operational definitions of > these topologies should be left for IETF WGs focused on these technologies). > 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 LISP > and the various LISP 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. > > > Goals and Milestones > > > Jun 2012 Forward draft-ietf-lisp-mib to the IESG > > Jun 2012 Forward draft-ietf-lisp-sec to the IESG > Jun 2012 Forward to the IESG an operational document which should > include cache management and ETR synchronization > techniques (draft-ietf-lisp-deployment). > Dec 2013 Publish an example cache management specification. > Dec 2013 Forward to the IESG an evaluation of the security threat to > cache maintenance (draft-ietf-lisp-threats) > Dec 2013 Forward to the IESG a document addressing the areas which > require further experimentation. > Jun 2014 E
Re: [lisp] LISP (re-)Charter discussion
Terry, > After a receiving the suggestions from Yakov and John, emailing some ADs, > the draft charter is as follows: > > Please review, and highlight any areas missed. I'd like to close this off by > next Friday (9th Dec), and pass to our AD. > > 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 other > contexts. The IRTF RRG examined several proposals, some of which were > published as IRTF-track Experimental RFCs. > > The LISP WG is chartered to work on the LISP base protocol and any items > which directly impact LISP including any base protocol changes required to > enable VPN and mobile topologies (precise operational definitions of > these topologies should be left for IETF WGs focused on these technologies). With respect to chartering LISP WG to work on the LISP "base protocol changes required to enable VPN", if these changes have to do with enabling L2 VPNs, then such work should be done in L2VPN WG. If these changes have to do with enabling L3 VPN, then such work should be done in L3VPN WG. In both of these cases the outcome of this work could be reviewed by the LISP WG. The same should apply to work on enaling "mobile topoligies". With this in mind I propose to replace the above sentence with the following: The LISP WG is chartered to work on the LISP base protocol and any items which directly impact LISP and are related to using LISP for improving Internet routing scalability. Yakov. > 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 LISP > and the various LISP 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. > > > Goals and Milestones > > > Jun 2012Forward draft-ietf-lisp-mib to the IESG > > Jun 2012Forward draft-ietf-lisp-sec to the IESG > Jun 2012Forward to t
Re: [lisp] LISP (re-)Charter discussion
Inherited hangover from the last charter... It can go I think. The awareness of what LISP is, and is not, is substantially different now than before - so I am happy to trim this section out. Cheers Terry On 2/12/11 4:28 PM, "Dino Farinacci" wrote: >> 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. > > This entire paragraph is so misleading and it is not documented in any LISP > specification that an identifier is composed of two parts. > > Also, in the LISP architecture, an EID or RLOC can be other than an IPv4 or > IPv6 address. > > And an EID does not need to change when a host moves from one site to another. > > So, more to the point, why is this definition in the charter? > > Dino > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
> 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. This entire paragraph is so misleading and it is not documented in any LISP specification that an identifier is composed of two parts. Also, in the LISP architecture, an EID or RLOC can be other than an IPv4 or IPv6 address. And an EID does not need to change when a host moves from one site to another. So, more to the point, why is this definition in the charter? Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
After a receiving the suggestions from Yakov and John, emailing some ADs, the draft charter is as follows: Please review, and highlight any areas missed. I'd like to close this off by next Friday (9th Dec), and pass to our AD. 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 other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG is chartered to work on the LISP base protocol and any items which directly impact LISP including any base protocol changes required to enable VPN and mobile topologies (precise operational definitions of these topologies should be left for IETF WGs focused on these technologies). 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 LISP and the various LISP 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. Goals and Milestones Jun 2012Forward draft-ietf-lisp-mib to the IESG Jun 2012Forward draft-ietf-lisp-sec to the IESG Jun 2012Forward to the IESG an operational document which should include cache management and ETR synchronization techniques (draft-ietf-lisp-deployment). Dec 2013Publish an example cache management specification. Dec 2013Forward to the IESG an evaluation of the security threat to cache maintenance (draft-ietf-lisp-threats) Dec 2013Forward to the IESG a document addressing the areas which require further experimentation. Jun 2014Evaluate the applicability and coverage for LISP from a reuse of SIDR technology. Jun 2014Summarize results of specifying, implementing, and testing LISP and forward to IESG and/or IRTF. Jun 2014Analyze and document the implications of LISP deployments in Internet topologies and forward to IESG for publication. Dec 2014Re-charter or close __
Re: [lisp] LISP (re-)Charter discussion
Thanks John, I'll include that milestone. Cheers Terry On 5/11/11 6:24 AM, "John Scudder" wrote: > Terry, > > The end of the charter says: > > On Oct 19, 2011, at 7:23 PM, Terry Manderson wrote: > >> 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. > > ... > >> 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. > > > These seem to suggest two or more additional milestones, along the general > lines of > > - Summarize results of specifying, implementing, and testing LISP and forward > to IESG and/or IRTF. > > and > > - Analyze and document the implications of LISP on etc etc and explain blah > blah. Forward to IESG for publication. > > (This partly echoes Yakov's earlier comment.) > > Regards, > > --John ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
On Nov 1, 2011, at 4:42 AM, Luigi Iannone wrote: > Hi, > > On Nov 1, 2011, at 00:57 , Jari Arkko wrote: > >> Yakov, >> >>> Furthermore, as John Scudder asked in his e-mail on 9/28, "the base >>> spec calls out a number of areas that require more experimentation. >>> A simple grep will find these. These experiments and what has been >>> learned from them should be documented. The same applies if other >>> specs have similar caveats (I just haven't looked for them)." >>> The charter needs to explicitly include in the Goals and Milestones >>> the document(s) that cover this. >>> >> >> I would love to see documents in the charter that describe experiences from >> simulation/implementation/measurement/real-world use, and shed light on >> these issues. >> > > There are a bunch of research papers out there that are interesting for the > WG. Would it make sense to create kind of an informational document with > pointers to the papers and a summary of the main results? > > Or you are suggesting a different document for each open issue? (I can't speak for Jari of course, but...) I'm not fussed about how many documents are produced. What I do think is desirable is to close the open issues in some way. This could be in an omnibus document that cites other papers as you describe, or separately. The main thing would be to allow the reader to relate a given "needs experimentation" placeholder to the experimental results and conclusion. I think this can be phrased broadly enough in the list of milestones that it doesn't tie the hands of the chairs in deciding what documents to produce. I also expect that as issues are resolved, it would make sense to update the base spec wherever there's now a "needs experimentation" placeholder. In fact, that could be an explicit goal and milestone of its own. --John ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
Terry, The end of the charter says: On Oct 19, 2011, at 7:23 PM, Terry Manderson wrote: > 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. ... > 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. These seem to suggest two or more additional milestones, along the general lines of - Summarize results of specifying, implementing, and testing LISP and forward to IESG and/or IRTF. and - Analyze and document the implications of LISP on etc etc and explain blah blah. Forward to IESG for publication. (This partly echoes Yakov's earlier comment.) Regards, --John ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
Hi, On Nov 1, 2011, at 00:57 , Jari Arkko wrote: > Yakov, > >> Furthermore, as John Scudder asked in his e-mail on 9/28, "the base >> spec calls out a number of areas that require more experimentation. >> A simple grep will find these. These experiments and what has been >> learned from them should be documented. The same applies if other >> specs have similar caveats (I just haven't looked for them)." >> The charter needs to explicitly include in the Goals and Milestones >> the document(s) that cover this. >> > > I would love to see documents in the charter that describe experiences from > simulation/implementation/measurement/real-world use, and shed light on these > issues. > There are a bunch of research papers out there that are interesting for the WG. Would it make sense to create kind of an informational document with pointers to the papers and a summary of the main results? Or you are suggesting a different document for each open issue? Luigi > Jari > > > > ___ > 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
Re: [lisp] LISP (re-)Charter discussion
Yakov, On 1/11/11 6:31 AM, "Yakov Rekhter" wrote: > Terry, > > If LISP VPN modality is an L2VPN, then such work should be pursued > in L2VPN WG. > > If LISP VPN modality is an L3VPN, then such work should be pursued > in L3VPN WG. > > Thus both of of the above LISP VPN modalities should be outside the > scope of the LISP WG. > Just to keep you (and the list) in the loop, I have escalated this question to the routing and internet area ADs. When I have a sense of their opinions I will respond further. Cheers Terry ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
Yakov, > > The charter needs to explicitly include in the Goals and Milestones the > document(s) that cover the analysis. > > Furthermore, as John Scudder asked in his e-mail on 9/28, "the base > spec calls out a number of areas that require more experimentation. > A simple grep will find these. These experiments and what has been > learned from them should be documented. The same applies if other > specs have similar caveats (I just haven't looked for them)." > The charter needs to explicitly include in the Goals and Milestones > the document(s) that cover this. > I missed that - thanks for bringing it up again.. I'll send an update in a few days. Terry ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
Yakov, Furthermore, as John Scudder asked in his e-mail on 9/28, "the base spec calls out a number of areas that require more experimentation. A simple grep will find these. These experiments and what has been learned from them should be documented. The same applies if other specs have similar caveats (I just haven't looked for them)." The charter needs to explicitly include in the Goals and Milestones the document(s) that cover this. I would love to see documents in the charter that describe experiences from simulation/implementation/measurement/real-world use, and shed light on these issues. Jari ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
Terry, > WG hat on. > > This follow-up is initiated due to a recent observation gleaned from a > presentation request for the Taipei meeting. > > While this draft charter does not preclude taking on work items specifically > related to LISP VPN or LISP mobility, I think it's useful to tease out the > questions and put them to the WG for discussion. > > Should LISP mobility be specifically included in the work plan? > > Should LISP VPN modalities be specifically included in the work plan? If LISP VPN modality is an L2VPN, then such work should be pursued in L2VPN WG. If LISP VPN modality is an L3VPN, then such work should be pursued in L3VPN WG. Thus both of of the above LISP VPN modalities should be outside the scope of the LISP WG. Yakov. > > Cheers > Terry > > On 20/10/11 9:23 AM, "Terry Manderson" wrote: > > > Hi All, > > > > Joel and I bounced the following charter around and have also passed it in > > front of AD's eyes. > > > > You obviously have time to chew on this for a while before Taipei. > > > > 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 other > > contexts. The IRTF RRG examined several proposals, some of which were > > published as IRTF-track Experimental RFCs. > > > > 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 LISP and the various LISP 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. > > > > > > Goals and Milestones > > > > Jun 2012Forward draft-ietf-lisp-mib to the IESG. > > Jun 2012Forward draft-ietf-lisp-sec to the IESG. > > Jun 2012
Re: [lisp] LISP (re-)Charter discussion
Terry, > Hi All, > > Joel and I bounced the following charter around and have also passed it in > front of AD's eyes. couple of comment in-line... > You obviously have time to chew on this for a while before Taipei. > > 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 other > contexts. The IRTF RRG examined several proposals, some of which were > published as IRTF-track Experimental RFCs. > > 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 LISP and the various LISP 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. The charter needs to explicitly include in the Goals and Milestones the document(s) that cover the analysis. Furthermore, as John Scudder asked in his e-mail on 9/28, "the base spec calls out a number of areas that require more experimentation. A simple grep will find these. These experiments and what has been learned from them should be documented. The same applies if other specs have similar caveats (I just haven't looked for them)." The charter needs to explicitly include in the Goals and Milestones the document(s) that cover this. Yakov. > Goals and Milestones > > Jun 2012Forward draft-ietf-lisp-mib to the IESG. > Jun 2012Forward draft-ietf-lisp-sec to the IESG. > Jun 2012Forward draft-ietf-lisp-deployment to the IESG. > Jun 2012Forward a security proposal document (draft-ietf-lisp-threats) > to the IESG. > > Dec 2013Forward to the IESG an operational set of documents which should > include cache management and ETR synchronization > techniques inclusive of a cache management specification. > > Jun 2014Forward to the
Re: [lisp] LISP (re-)Charter discussion
Hi Albert, On 29/10/11 3:04 AM, "Albert Cabellos" wrote: >> >> Should LISP mobility be specifically included in the work plan? >> > > I would like to point out that we have a small but growing community of > people interested into LISPmob, we open-sourced the code 1.5 months ago. > To be clear (as in crystal) does this mean you think that mobility should be included? or are you simply making the observation that there is a community of people 'out there' who are yet to be vocal on this ML. Cheers Terry ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
Hi, On 27/10/2011 7:10, Terry Manderson wrote: WG hat on. This follow-up is initiated due to a recent observation gleaned from a presentation request for the Taipei meeting. While this draft charter does not preclude taking on work items specifically related to LISP VPN or LISP mobility, I think it's useful to tease out the questions and put them to the WG for discussion. Should LISP mobility be specifically included in the work plan? I would like to point out that we have a small but growing community of people interested into LISPmob, we open-sourced the code 1.5 months ago. Albert Should LISP VPN modalities be specifically included in the work plan? Cheers Terry On 20/10/11 9:23 AM, "Terry Manderson" wrote: Hi All, Joel and I bounced the following charter around and have also passed it in front of AD's eyes. You obviously have time to chew on this for a while before Taipei. 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 other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. 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 LISP and the various LISP 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. Goals and Milestones Jun 2012Forward draft-ietf-lisp-mib to the IESG. Jun 2012Forward draft-ietf-lisp-sec to the IESG. Jun 2012Forward draft-ietf-lisp-deployment to the IESG. Jun 2012Forward a security proposal document (draft-ietf-lisp-threats) to the IESG. Dec 2013Forward to the IESG an operational set of documents which should include cache management and ETR synchronization techniques inclusive of a cache management specification. Jun 2014Forward to the IESG an
Re: [lisp] LISP (re-)Charter discussion
WG hat on. This follow-up is initiated due to a recent observation gleaned from a presentation request for the Taipei meeting. While this draft charter does not preclude taking on work items specifically related to LISP VPN or LISP mobility, I think it's useful to tease out the questions and put them to the WG for discussion. Should LISP mobility be specifically included in the work plan? Should LISP VPN modalities be specifically included in the work plan? Cheers Terry On 20/10/11 9:23 AM, "Terry Manderson" wrote: > Hi All, > > Joel and I bounced the following charter around and have also passed it in > front of AD's eyes. > > You obviously have time to chew on this for a while before Taipei. > > 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 other > contexts. The IRTF RRG examined several proposals, some of which were > published as IRTF-track Experimental RFCs. > > 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 LISP and the various LISP 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. > > > Goals and Milestones > > Jun 2012Forward draft-ietf-lisp-mib to the IESG. > Jun 2012Forward draft-ietf-lisp-sec to the IESG. > Jun 2012Forward draft-ietf-lisp-deployment to the IESG. > Jun 2012Forward a security proposal document (draft-ietf-lisp-threats) > to the IESG. > > Dec 2013Forward to the IESG an operational set of documents which should > include cache management and ETR synchronization > techniques inclusive of a cache management specification. > > Jun 2014Forward to the IESG an evaluation of the security threat to >
Re: [lisp] LISP (re-)Charter discussion
Hi All, Joel and I bounced the following charter around and have also passed it in front of AD's eyes. You obviously have time to chew on this for a while before Taipei. 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 other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. 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 LISP and the various LISP 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. Goals and Milestones Jun 2012Forward draft-ietf-lisp-mib to the IESG. Jun 2012Forward draft-ietf-lisp-sec to the IESG. Jun 2012Forward draft-ietf-lisp-deployment to the IESG. Jun 2012Forward a security proposal document (draft-ietf-lisp-threats) to the IESG. Dec 2013Forward to the IESG an operational set of documents which should include cache management and ETR synchronization techniques inclusive of a cache management specification. Jun 2014Forward to the IESG an evaluation of the security threat to cache management and ETR synchronization. Jun 2014Evaluate the applicability and coverage for LISP from a reuse of SIDR technology. Dec 2014Re-charter or close Cheers Terry ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
If we can't agree what is going into a charter, how we are going to agree where work is going to happen with even a bigger audience to decide. The focus is all wrong. The focus should be on the work and not the process. Dino On Sep 30, 2011, at 9:17 AM, Scott Brim wrote: > On Fri, Sep 30, 2011 at 11:32, Templin, Fred L > wrote: >> 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. > > IMHO a WG charter is not the place to have a listing of other > drafts/RFCs that are not in scope, even if they are related somehow. > If other pages are outdated, that's where the problem should be fixed. > > Scott > ___ > 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
Re: [lisp] LISP (re-)Charter discussion
On Fri, Sep 30, 2011 at 11:32, Templin, Fred L wrote: > 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. IMHO a WG charter is not the place to have a listing of other drafts/RFCs that are not in scope, even if they are related somehow. If other pages are outdated, that's where the problem should be fixed. Scott ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
Hi Terry, > -Original Message- > From: Terry Manderson [mailto:terry.mander...@icann.org] > Sent: Thursday, September 29, 2011 5:18 PM > To: Templin, Fred L; Joel M. Halpern > Cc: lisp@ietf.org > 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 fred.l.temp...@boeing.com > Cheers > Terry > > > On 29/09/11 10:16 PM, "Templin, Fred L" > wrote: > > > Hi Joel, > > > >> -Original Message- > >> From: Joel M. Halpern [mailto:j...@joelhalpern.com] > >> Sent: Wednesday, September 28, 2011 8:11 PM > >> To: Templin, Fred L > >> Cc: Terry Manderson; lisp@ietf.org > >> 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 > > fred.l.temp...@boeing.com > > > >> 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 > >>> fred.l.temp...@boeing.com > >>> > >>>> -Original Message- > >>>> From: lisp-boun...@ietf.org [mailto:lisp-boun...@ietf.org] On > >>>> Behalf Of Terry Manderson > >>>> Sent: Wednesday, September 21, 2011 5:05 PM > >>>> To: lisp@ietf.org > >>
Re: [lisp] LISP (re-)Charter discussion
Hi Terry, > -Original Message- > From: Terry Manderson [mailto:terry.mander...@icann.org] > Sent: Thursday, September 29, 2011 5:18 PM > To: Templin, Fred L; Joel M. Halpern > Cc: lisp@ietf.org > 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" > wrote: > > > Hi Joel, > > > >> -Original Message- > >> From: Joel M. Halpern [mailto:j...@joelhalpern.com] > >> Sent: Wednesday, September 28, 2011 8:11 PM > >> To: Templin, Fred L > >> Cc: Terry Manderson; lisp@ietf.org > >> 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 > > fred.l.temp...@boeing.com > > > >> 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 > >>> fred.l.temp...@boeing.com > >>> > >>>> -Original Message- > >>>> From: lisp-boun...@ietf.org [mailto:lisp-boun...@ietf.org] On > >>>> Behalf Of Terry Manderson > >>>> Sent: Wednesday, September 21, 2011 5:05 PM > >>>> To: lisp@ietf.org > >>>> 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
Re: [lisp] LISP (re-)Charter discussion
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)" 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" 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 >>> chan
Re: [lisp] LISP (re-)Charter discussion
Taking the workgroup 'hat' off for a moment (I was going to say 'underpants', but that is just a _bad_ mental image :) I think what Eliot says here holds true. In respect to LISP there is a level of expertise here. However adopting a view that we be exclusive to a core is a little premature. Perhaps in time a LISP-EXT might pop up, perhaps not. Your observation about preferring ALTO is actually a perfect example of preference. You might prefer to go to ALTO, others may choose LISP. The bottom line for me is not seeing a meaningless turf war commence over standards work. The ultimate win is that the work gets done. Not specifically which WG it ends up in, as I'm sure that there will be sufficient review (both volunteered and requested) by many parties from various WGs and areas. Cheers Terry On 29/09/11 10:31 PM, "Eliot Lear" wrote: >Robert, I think the question hangs on (1) where will the expertise be? Are > they in ALTO or LISP or both? What expertise is needed? The IETF has > addressed this problem in both dimensions that have been discussed. For > example, the DHCP and DNSEXT groups are long standing precisely because the > expertise necessary to extend those protocols can really only be found in > those groups. It DOES require a flexible management view from within a > working group. If orthodoxy sets in (and we've seen that before) clever > engineers find ways to route around the damage. I am not here speaking of > LISP, mind you. > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
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" wrote: > Hi Joel, > >> -Original Message- >> From: Joel M. Halpern [mailto:j...@joelhalpern.com] >> Sent: Wednesday, September 28, 2011 8:11 PM >> To: Templin, Fred L >> Cc: Terry Manderson; lisp@ietf.org >> 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 > fred.l.temp...@boeing.com > >> 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 >>> fred.l.temp...@boeing.com >>> >>>> -Original Message- >>>> From: lisp-boun...@ietf.org [mailto:lisp-boun...@ietf.org] On >>>> Behalf Of Terry Manderson >>>> Sent: Wednesday, September 21, 2011 5:05 PM >>>> To: lisp@ietf.org >>>> 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 >>>> nee
Re: [lisp] LISP (re-)Charter discussion
Hi John, On 29/09/11 5:21 AM, "John Scudder" wrote: > Terry, > > It seems inappropriate to me that LISP be the sole WG that works on all things > related to LISP. I thought my words captured an openness stance, perhaps not. There is simply no way for LISP WG to mandate that all things LISP be here. And such a thing would not be healthy long term, and starts down the "not invented here" path. What I would like to see captured is that the LISP WG is there for people who wish to do work on LISP in the LISP WG in various applications. If a standards developer so chooses to push a work item that uses LISP in another WG, then that is their choice, and the choice of the target WG. Similarly, what I don't want to say is that "I'm sorry - LISP encapsulation of Carrier Pigeon doesn't belong here, see the Carrier Pigeon WG." For precisely the same reasons you mention. > It's standard IETF procedure for one WG to build on another > WG's protocol. There are many examples of this. Of course review by the LISP > WG of any relevant specs (both prior to and during last call) may be > appropriate. This is also SOP. > It will be a normal exercise to maintain awareness and communication with the other WGs when there is such a spec. Cheers Terry ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
Robert, I think the question hangs on (1) where will the expertise be? Are they in ALTO or LISP or both? What expertise is needed? The IETF has addressed this problem in both dimensions that have been discussed. For example, the DHCP and DNSEXT groups are long standing precisely because the expertise necessary to extend those protocols can really only be found in those groups. It DOES require a flexible management view from within a working group. If orthodoxy sets in (and we've seen that before) clever engineers find ways to route around the damage. I am *not* here speaking of LISP, mind you. ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
Hi Joel, > -Original Message- > From: Joel M. Halpern [mailto:j...@joelhalpern.com] > Sent: Wednesday, September 28, 2011 8:11 PM > To: Templin, Fred L > Cc: Terry Manderson; lisp@ietf.org > 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 fred.l.temp...@boeing.com > 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 > > fred.l.temp...@boeing.com > > > >> -Original Message- > >> From: lisp-boun...@ietf.org [mailto:lisp-boun...@ietf.org] On > >> Behalf Of Terry Manderson > >> Sent: Wednesday, September 21, 2011 5:05 PM > >> To: lisp@ietf.org > >> 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 > con
Re: [lisp] LISP (re-)Charter discussion
John, On 9/28/11 9:21 PM, John Scudder wrote: > Terry, > > I think your list of bullet points is almost right. I would something that > Joel proposed in Quebec City: > > * Publish an example cache management specification. > > As a reminder, the purpose of this is to provide something that is amenable > to analysis to make it possible to meaningfully "evaluate the security threat > to cache maintenance" as you say in your last bullet. I generally like to see things in charters that have (at least in the background) names attached to them. Are you volunteering? Eliot ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
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. 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 fred.l.temp...@boeing.com -Original Message- From: lisp-boun...@ietf.org [mailto:lisp-boun...@ietf.org] On Behalf Of Terry Manderson Sent: Wednesday, September 21, 2011 5:05 PM To: lisp@ietf.org 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
Re: [lisp] LISP (re-)Charter discussion
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 fred.l.temp...@boeing.com > -Original Message- > From: lisp-boun...@ietf.org [mailto:lisp-boun...@ietf.org] On > Behalf Of Terry Manderson > Sent: Wednesday, September 21, 2011 5:05 PM > To: lisp@ietf.org > 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
Re: [lisp] LISP (re-)Charter discussion
All, I agree here with John .. the way how I read what is being proposed here I would call also impractical. It seems to me that LISP WG just like any other WG should be involved in the core LISP work and not in any potential new application which will choose to use LISP. As example if I would like to propose an overlay which uses LISP to interconnect set of ALTO servers I would rather work on it in ALTO WG not in LISP. LISP WG could be just involved as far as being aware about such work. That practice has worked very well in the past for large number of other IETF solutions. L3VPNs or L2VPNs while heavily using BGP are not standardized in IDR. They are standardized in their respective WGs. MPLS TE has been topic of MPLS WG and not ISIS, OSPF or RSVP WGs which extensions are critical part of it. Best, R. Terry, It seems inappropriate to me that LISP be the sole WG that works on all things related to LISP. It's standard IETF procedure for one WG to build on another WG's protocol. There are many examples of this. Of course review by the LISP WG of any relevant specs (both prior to and during last call) may be appropriate. This is also SOP. --John On Sep 27, 2011, at 12:17 AM, Terry Manderson wrote: 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 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
Terry, It seems inappropriate to me that LISP be the sole WG that works on all things related to LISP. It's standard IETF procedure for one WG to build on another WG's protocol. There are many examples of this. Of course review by the LISP WG of any relevant specs (both prior to and during last call) may be appropriate. This is also SOP. --John On Sep 27, 2011, at 12:17 AM, Terry Manderson wrote: > 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" 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 yo
Re: [lisp] LISP (re-)Charter discussion
Terry, I think your list of bullet points is almost right. I would something that Joel proposed in Quebec City: * Publish an example cache management specification. As a reminder, the purpose of this is to provide something that is amenable to analysis to make it possible to meaningfully "evaluate the security threat to cache maintenance" as you say in your last bullet. The relevant excerpt from the IETF-81 minutes (http://www.ietf.org/proceedings/81/minutes/lisp.txt) is the "b" part below (Terry's final bullet point covers the "a" part): - Joel Halpern => Let me paraphrase because what I heard sound very reasonable. a) In the threats doc, we should put a little more attention on this. b) We should put as WG item a new document that addresses what is the right answer to this problem is. Alia Atlas => What the minimum answer to the problem is. Joel Halpern => OK. - Second, the base spec calls out a number of areas that require more experimentation. A simple grep will find these. These experiments and what has been learned from them should be documented. The same applies if other specs have similar caveats (I just haven't looked for them). --John On Sep 21, 2011, at 8: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 involv
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. 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" 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 >>> conce
Re: [lisp] LISP (re-)Charter discussion
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" 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/
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" 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
Re: [lisp] LISP (re-)Charter discussion
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 identifi
Re: [lisp] LISP (re-)Charter discussion
Hi Terry On Thu, Sep 22, 2011 at 3:04 AM, Terry Manderson wrote: > 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? > Are there any interest to look further into to future and discuss what is needed to have a long term solution of LISP, as discussed in RFC 1955? This scheme could be extended to not require globally unique IP address. Effectively the combination of AD-Address and IP-Address is the globally unique address. To use this scheme without globally unique IP-Addresses and without changing in the hosts would require a NAT mechanism in the border routers. I think it would be preferable to change the hosts to have them do the DNS query and add the AD- header. This could be the basis for the long term solution. Another interesting aspect of this scheme is that if we were to relax the current architecture where one IP-Address is always in only one AD, to allow an IP-Address to be in more than one AD, it would provide a solution to the issue of allowing a IP entity to get service from more than one service provider. Patrick ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP (re-)Charter discussion
Hi Terry, El 9/22/2011 2:04 AM, Terry Manderson escribió: [...] 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? I think it would be interesting to include mobility in the charter as well. The LISP-MN draft is mature and there are some implementations already of that spec. -Lori 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? ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[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 g
