Hi, Patrick, I'd join a group not finding your proposal anything controversial. You've proposed a hierarchical addressing which I'd find is very appropriate.
Decoupling the exterior routing and interior routing is something Toni and I have raised several times in the list. I'd believe your idea is close to ours in that sense. You carefully used the term 'locator' instead of 'address', since, apparently, employing separate identifiers is one of your option. If you'd rely on a technique like MTCP, you wouldn't need separate identifiers, I'd suppose. A lot of people in this list are very sensitive about use of the term 'address', but, again, to me, your scheme is a hierarchical addressing using 'global area address' and 'local node-interface address'. Anyway, the idea of segregating address space and decoupling interior and exterior routings, I'd believe, is a promising way of leading to a scalable routing paradigm. A very good job. On Thu, Aug 26, 2010 at 7:05 PM, Patrick Frejborg <[email protected]>wrote: > Hi all, > > I'd like to announce that an update to the hIPv4 framework draft is > now available at http://www.ietf.org/id/draft-frejborg-hipv4-08.txt. > > There are two major changes. > > First, an identifier placeholder has been added to the locator header. > With this flag a host identifier scheme, such as HIP, ILNP or NBS, can > be added to the locator header - when desired. The end > user/application have a choice to use a session identifier (can be > found in some transport protocols), a host identifier or no identifier > at all. > > Second, I took a study what could be accomplish in the future and > assumed that the forwarding plane at some stage (a decade or more) is > replaced and the locator swap functionality can be replaced with three > forwarding modes. The outcome is > - the edge locators needs only to be unique at the private network or > in an ISP network, thus no RIR process is needed for the edge locators > - the edge locator can use the whole 32 bit locator space > - only ISP should be able apply for core locators, each core locator > can contain a full 32 bit edge locator space > - a 32 x 32 bit locator space is achieved > > So please have a look on this, perhaps I have missed something > fundamental here and the architecture is broken. > > If the architecture is theoretically functional you could say that > locator freedom is achieved, but not only locator freedom - also > identifier freedom is achieved. > > I think the framework has become enough mature that it can enter the > process described in RFC 5743 - thus asking kindly the chairs to > consider the draft as a candidate for publication. > > If granted, a document shepherd is needed - Aaron pointed out the > author shouldn't take that role - any volunteer? > > I know that this architecture is controversial and may not get > consensus to be published - if You think it is too controversial (or > the architecture is broken, too broken English etc) please speak up as > soon as possible but latest on the 15th of September 12:00 CET so the > reviewers valuable time is not wasted- thanks! > > -- patte > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg > -- DY
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
