Hi Joel,
> -----Original Message-----
> From: Joel M. Halpern [mailto:[email protected]]
> Sent: Wednesday, September 28, 2011 8:11 PM
> To: Templin, Fred L
> Cc: Terry Manderson; [email protected]
> Subject: Re: [lisp] LISP (re-)Charter discussion
>
> Fred, "Authorized" is I think the wrong word to use to describe the
> publication. Or at least a misleading word. The IRTF
> process is such
> that the RG did not actually approve the publication of any of the
> solutions. The RG Chair sponsored the publication as an
> output of the
> RG. IRTF procedures explicitly recognize and allow for multiple
> minority reports from an RG.
>
> I do agree that we should recognize that a number of ideas have been
> published as RFCs. And we should probably not be too specific about
> what the RG is doing, since that is liable to change.
OK. How does this look for a rewrite:
"A number of approaches have been published in parallel in the
IRTF and IETF. In particular, the IRTF Routing Research Group
(RRG) has published recommendations [RFC6115] and design goals
[RFC6227], and has released three solution proposals for
publication in IRON [RFC6179], hIPv4 [RFC6306] and ILNP [ILNP]."
Thanks - Fred
[email protected]
> Yours,
> Joel
>
> On 9/28/2011 10:20 PM, Templin, Fred L wrote:
> > Hi Terry,
> >
> > Regarding the 5th paragraph of the Draft Charter:
> >
> >> A number of approaches are being looked at in parallel in
> the IRTF and
> >> IETF. At this time, these proposals are at an early stage.
> >
> > This needs to be updated; here is a proposed rewrite:
> >
> > "A number of approaches have been published in parallel in the
> > IRTF and IETF. In particular, the IRTF Routing Research Group
> > (RRG) has published its recommendations [RFC6115] and design
> > goals [RFC6227], and has authorized the publication of three
> > solution proposals in IRON [RFC6179], hIPv4 [RFC6306] and
> > ILNP [ILNP]."
> >
> > Thanks - Fred
> > [email protected]
> >
> >> -----Original Message-----
> >> From: [email protected] [mailto:[email protected]] On
> >> Behalf Of Terry Manderson
> >> Sent: Wednesday, September 21, 2011 5:05 PM
> >> To: [email protected]
> >> Subject: [lisp] LISP (re-)Charter discussion
> >>
> >> Hi Folks,
> >>
> >> In Prague there was no strong consensus on modifying the LISP
> >> Charter from
> >> what it currently is, perhaps only updating the existing
> >> Goals/Milestones.
> >>
> >> So no clear decision could be made. What I would like to do
> >> is push out a
> >> 'idea generating' draft charter that is _almost_ identical to
> >> what we have
> >> today.
> >>
> >> You can find the existing charter here:
> >> https://datatracker.ietf.org/wg/lisp/charter/
> >>
> >> The draft is below.
> >>
> >> So in light of such an approach, Joel and I discussed some
> >> work items that
> >> came from what was said at the mic in Prague and to us
> individually.
> >>
> >> They are:
> >>
> >> * Finish the deployment document
> >> * Get the two security documents done
> >> * Get an operational document at least started, which
> should include
> >> cache management and ETR synchronization techniques.
> >> * Either in the second security document, or in complementary
> >> documents we
> >> need to evaluate the security threat to cache maintenance, and
> >> evaluate the applicability and coverage we get from a reuse of SIDR
> >> technology.
> >>
> >> Is anything not represented here that you believe necessary?
> >> and conversely
> >> is there something here that is out of scope in your eyes?
> >>
> >> Are there work areas not covered by the draft below which you
> >> believe should
> >> be?
> >>
> >> Draft Charter
> >> ------------
> >>
> >> The IAB's October 2006 Routing and Addressing Workshop (RFC 4984)
> >> rekindled interest in scalable routing and addressing
> >> architectures for
> >> the Internet. Among the many issues driving this renewed
> interest are
> >> concerns about the scalability of the routing system and
> the impending
> >> exhaustion of the IPv4 address space. Since the IAB
> workshop, several
> >> proposals have emerged which attempt to address the
> concerns expressed
> >> there and elsewhere. In general, these proposals are based on the
> >> "locator/identifier separation".
> >>
> >> The basic idea behind the separation is that the Internet
> architecture
> >> combines two functions, routing locators, (where you are
> >> attached to the
> >> network) and identifiers (who you are) in one number space: The IP
> >> address. Proponents of the separation architecture postulate that
> >> splitting these functions apart will yield several
> >> advantages, including
> >> improved scalability for the routing system. The separation aims to
> >> decouple locators and identifiers, thus allowing for efficient
> >> aggregation of the routing locator space and providing persistent
> >> identifiers in the identifier space.
> >>
> >> LISP supports the separation of the IPv4 and IPv6 address space
> >> following a network-based map-and-encapsulate scheme (RFC 1955). In
> >> LISP, both identifiers and locators are IP addresses. In LISP,
> >> identifiers are composed of two parts: a "global" portion
> >> that uniquely
> >> identifies a particular site and a "local" portion that
> identifies an
> >> interface within a site. The "local" portion may be subdivided to
> >> identify a particular network within the site. For a given
> identifier,
> >> LISP maps the "global" portion of the identifier into a set
> >> of locators
> >> that can be used by de-capsulation devices to reach the identified
> >> interface; as a consequence a host would typically change
> identifiers
> >> when it moves from one site to another or whenever it
> moves from one
> >> subnet to another within an site. Typically, the same IP
> address will
> >> not be used as an identifier and locator in LISP.
> >>
> >> LISP requires no changes to end-systems or to most
> routers. LISP aims
> >> for an incrementally deployable protocol.
> >>
> >> A number of approaches are being looked at in parallel in
> the IRTF and
> >> IETF. At this time, these proposals are at an early stage.
> >> All proposals
> >> (including LISP) have potentially harmful side-effects to Internet
> >> traffic carried by the involved routers, have parts where
> deployment
> >> incentives may be lacking, and are NOT RECOMMENDED for
> >> deployment beyond
> >> experimental situations at this stage. Many of the proposals have
> >> components (such as the identifier to locator mapping
> system) where it
> >> is not yet known what kind of design alternative is the
> best one among
> >> many.
> >>
> >> However, despite these issues it would be valuable to
> write concrete
> >> protocol specifications and develop implementations that can
> >> be used to
> >> understand the characteristics of these designs. The LISP WG is
> >> chartered to work on the LISP base protocol and any items
> >> which directly
> >> impact LISP. The working group will encourage and
> >> support interoperable LISP implementations as well as defining
> >> requirements for alternate mapping systems. The Working Group
> >> will also
> >> develop security profiles for the ALT and/or other mapping systems.
> >>
> >> It is expected that the results of specifying, implementing,
> >> and testing
> >> LISP will be fed to the general efforts at the IETF and IRTF
> >> (e.g., the
> >> Routing Research Group) that attempts to understand which type of a
> >> solution is optimal. The LISP WG is NOT chartered to
> develop the final
> >> or standard solution for solving the routing scalability
> problem. Its
> >> specifications are Experimental and labeled with accurate
> disclaimers
> >> about their limitations and not fully understood implications for
> >> Internet traffic. In addition, as these issues are understood, the
> >> working group will analyze and document the implications of LISP on
> >> Internet traffic, applications, routers, and security.
> This analysis
> >> will explain what role LISP can play in scalable routing.
> The analysis
> >> should also look at scalability and levels of state required for
> >> encapsulation, decapsulation, liveness, and so on as well as the
> >> manageability and operability of LISP.
> >>
> >>
> >> Cheers
> >> Terry
> >>
> >> _______________________________________________
> >> lisp mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/lisp
> >>
> > _______________________________________________
> > lisp mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/lisp
> >
>
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
