Folks: OK. In the past several days, I have:
read Tony's ipv6ipaddressusage-04 draft read Michel's gapi-00 draft reviewed the site-local use discussion in the IPv6 WG read the Multi6 charter read the Multi6 requirements draft re-read RFC 2373 and RFC 2374 re-read the addr-arch-v3 draft re-read the ipv6-prefix-delegation-requirement-00 draft re-read the ipv6-ipaddressassign-06 draft read Iljitch van Beijnum's multi6-isp-int-aggr-00 draft read Michel's Multi Homing Aliasing Protocol draft I went back and ploughed through my archive of ngtrans mail. At one point I thought I had got myself into a configuration which features a permanently recirculating digestive system. 8-/ There is much high-quality work in the documents and discussions cited above. Each of the drafts proposes a solution to a specific problem or elememt of a problem, or, in some cases, proposes tools to handle some of the effects of the percieved problem; the proposals have substantial technical merit, and all deserve full and careful consideration. After working through the reading listed above, a disturbing notion began niggling around in the back of my brain (what little there is of it). More below. On Fri, 14 Feb 2003, Michel Py wrote: > > Tony Hain wrote: > > We are at an impass. > > Indeed. > > No wonder we're at an impasse: we have a blind-men-and-the-elephant problem here! Each of the discussions and drafts cited above defines a problem, and, in most cases, proposes a solution for that problem or a tool to help constrain the problem space. As I read the documents and discussion logs, all the problems described converge on a common underlying root issue. In effect, each group or author has siezed upon one aspect of the root issue (one the trunk; another an ear, the third a leg; ...) and then described a possible solution for that aspect of the issue. I suggest that we might be able to make more progress if we directly address the underlying issue. This is not to sugggest that the problems severally described in the citations above will automagically disappear once the root issue is resolved; however, I think that most (probably all) of the discrete problems will then become much easier to solve. The common, underlying issue, as I see it, is: The use of PA space in end-user networks has the effect of imposing upon those networks functional burdens and restrictions in multiple areas which the managers of commercial end-user networks may be unwilling to tolerate. In consequence, we may need to reconsider our current address allocation practice, which relies principally on the PA model, in light of current user expectations, current state of the routing protocols and standards, and anticipated developments in routing and switching code. Given the present state of our technologies, any discussion of a change in address allocation models will inevitably entail extensive consideration of scalability and routing-table-size issues, along with aggregation and related matters. > > this puts the ADs in a bind, because they would have a hard > > time justifing that the IPv6 wg should be tasked with defining > > an operational plan that an Operations Area wg is already > > tasked to do. > > Yep. Some will remember that in an attempt to shake things up, a year or > two ago I tried to bypass multi6 and sent my text to ngtrans. The result > was the addition of text in the ngtrans charter that specifically > labeled multihoming solutions as non-goals that would not be looked at > by the WG. We're deadlocked. > I think we may be able to break the deadlock and, for lagniappe, get the ADs out of their bind (provided they really are so constrained) by proposing to deal directly with the root issue rather than continuing to nibble away at the leaves. As I read the charters and tasks lists, there are mutiple tasks extant which treat some aspect of the PA functional restrictions and burdens on end-user networks, but no task which coordinates activities across the multiple working groups on the issues arising from PA in end-user networks. Additionally, there is no task open which deals directly with the user-community concerns over the functional burdens imposed on end-user networks by forced use of PA. > > > It is exactly that business model where PI approaches like > > Michele's or mine work well. > > To set the record straight, Tony's drafts have been one of the major > sources inspiring GAPI in the early stages. One of the interim releases > of MHAP actually used Tony's scheme before GAPI was written. > The drafts cited above present tools and practices which may very well be a part of the solution set for the underlying issue, in adddition to providing specific solutions in particular functional areas. > > > I have a document that describes the situation and need for PI: > > http://www.tndh.net/~tony/ietf/ipv6piaddressusage-04.txt > > I never bothered writing something like this as Tony's text is also > valid for GAPI for the most part. Read it. > > Michel. > > I have read Tony's draft, and it does contain a very good statement of specific needs which are amenable to solution by use of PI. This is very fine work indeed. Now, I intend to make a specific proposal on next steps below, and then pose these questions: 1) Should we ask for something akin to the steps proposed below? 2) Is there another approach which will work at least as well, and, if so, what is it? 3) Are we approaching this matter hind-end-foremost? or 4) I am the functional equivalent of a skunk with his head stuck in a tin can? (Alternately expressed: is this proposal fundamentally wrong-headed, and should we abandon it in favor or more productive discussions?) Here is a starting point for discussion of next steps. We may wish to: 1) Ask the IPv6 WG chairs and the Internet Area ADs to add to the IPv6 task list a work item which directs the WG to coordinate and support extant activities in other WGs which deal with issues surrounding use of PA and PI address spaces in, or at the boundaries of, end-user networks. (Note: this language will need to be clarified. Suggestions welcome.) This is incontestably within the working group charter, as indicated by this charge in the charter statement: - Serve as a review board and body of competence and coordination for IPv6 architectural issues that span multiple IETF working groups. 2) Ask the IPv6 WG chairs and the Internet Area ADs to add to the IPv6 task list a work item which directs the WG to review and, if needed, recommend revisions to the current IPv6 unicast address allocation practice in light of current user expectations, current state of the routing protocols and standards, and anticipated developments in routing and switching code. Here again, this is incontestably within the scope of the WG charter, as indicated by this charge in the charter statement: - Provide technical input to the IAB, IANA and Internet Address Registries with regard to IPv6 address allocation policies and procedures. OK, let the gates down - I'm eager for comments. Regards, AEB -- Alan E. Beard <[EMAIL PROTECTED]> AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
