The problem is the policy requirements of inter-domain routing. While LS can be scaled hierarchically, supporting policy routing in a LS requires policy disclosures that are simply unrealistic in the commercial Internet. See IDPR.
Been there, done that, Tony On 5/25/10 7:27 AM, "Joel M. Halpern" <[email protected]> wrote: > I do not believe that separating intra- and inter- domain routing is > necessary from a theoretical perspective. (From a practical perspective, I > do not believe it is possible to erase the distinction in the current > world.) As a demonstration of why I consider this unnecessary, I point to > either PNNI or Nimrod. In both cases, the same protocol can be used for > intra-, inter-, and in fact iteratively as one wishes, with effective scale. > Whether those protocols themselves provide ID/Locator separation, or whether > they would need to be coupled to such a separation, is left as an exercise > for someone else. It doesn't matter for this question. Even IS-IS was > demonstrated to be able to scale iteratively to multiple levels of > hierarchy. Heck, if we could change to a PIP-like system, the very question > would become moot. Yours, Joel Toni Stoev wrote: > Tony, > > 17.3. > Rationale, sentence 3 has an extra "is". > > A location/identity separation > that we are about to recommend is a good thing. > > Many combinations of > problems may come out of a wrong design. The right design has to service the > valuable practices. > In my opinion the missing basic right approaches for the > graph-resembling packet-switched data communication network are: > > A > topological location name, the locator, must target node, not interface. > > Intra-domain and inter-domain routing must be distinct. Intra-domain routing > must be based on locators that follow topology. Inter-domain routing must be > based on routing domain IDs (AS numbers) and not on IP address prefixes. > > [Location/identity split] There must be a node identification system that maps > a given universal identifier to a tuple of {routing domain ID + locator}. The > solution is numerical bi-directionally aware DNS-like system. The DNS system > shall then map names to identifiers. > > Good faith, > Toni > > On Tuesday > 25 May 2010 at 11:03:29 Tony Li sent: >> FYI... >> >> I hope to do another > editorial pass, so comments and additions are still >> welcome. >> >> > Regards, >> Tony >> >> >> ------ Forwarded Message >> From: > <[email protected]> >> Reply-To: <[email protected]> >> Date: > Mon, 24 May 2010 18:30:02 -0700 (PDT) >> To: <[email protected]> >> > Subject: I-D Action:draft-irtf-rrg-recommendation-08.txt >> >> A New > Internet-Draft is available from the on-line Internet-Drafts >> > directories. >> >> Title : Recommendation for a Routing > Architecture >> Author(s) : T. Li >> Filename : > draft-irtf-rrg-recommendation-08.txt >> Pages : 70 >> Date > : 2010-05-24 >> >> It is commonly recognized that the Internet routing and > addressing >> architecture is facing challenges in scalability, multi-homing, > and >> inter-domain traffic engineering. This document surveys many of the >> > proposals that were brought forward for discussion in this activity, >> as > well as some of the subsequent analysis. >> >> A URL for this Internet-Draft > is: >> > http://www.ietf.org/internet-drafts/draft-irtf-rrg-recommendation-08.txt >> >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable > a MIME compliant mail reader >> implementation to automatically retrieve the > ASCII version of the >> Internet-Draft. >> > _______________________________________________ >> I-D-Announce mailing > list >> [email protected] >> > https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft > directories: http://www.ietf.org/shadow.html >> or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> ------ End of Forwarded > Message >> >> > _______________________________________________ > rrg mailing > list > [email protected] > > http://www.irtf.org/mailman/listinfo/rrg _____________________________________ > __________ rrg mailing > list [email protected] http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
