On Wednesday 26 May 2010 at 04:30:38 Dae Young KIM sent: > Hence, in a sense, if I'm not wrong; > > - The granularity of Locator in ILNP is a subnet. It is a subnet > Locator. Although you may use local addressing for Locators, as soon > as they leave a site, they have to be changed to > 'globally-significant' Locators. And these global subnet Locators will > be used as keys to look up routing/forwarding tables. > > - With Toni's model, the granularity of Locator in IDR should be a > site, not subnet. So, this is a site Locator. Now that simply Locator > is used to mean subnet Locator in ILNP, you might want to call this > differently. If not site Locator, then site address? As long as the > intention with Toni might be to call a site wherein independent > intra-domain routing or any routing would be applied under an > independent authority, can is safely be also called a domain? If so, > then, it might be domain address, or something like that. > > So, I think what Toni is proposing is to use site Locator in IDR, and > not to expose subnet Locator in IDR.
Putting words in places: Inter-domain routing: unit – routing domain (autonomous system, site); name – routing domain ID (AS number). Intra-domain routing: unit – node (host, router); name – locator (following topology). > Or is it something already being meant by ILNP? > > On Wed, May 26, 2010 at 9:39 AM, Dae Young KIM <[email protected]> wrote: > > Toni may not be obsessive with LS or any other than BGP. The essence > > that we wanted to assert was to use domains (or AS) as granularity in > > BGP routing. Perhaps, we're mixed up with terminologies, but what is > > meant by AS or domain is not anything different from 'site' in ILNP. > > > > An entity within with an intra-domain routing would be applied. Beyond > > with, an IDR like BGP would be applied. And that the Locator used > > inside a site wouldn't be exposed to IDR. Only site ID or site Locator > > (if that should be the right term) be used in finding a path to the > > target site, upon which the local-significant Locator would be used to > > continue intra-domain routing. > > > > With this, it still is a policy routing at IDR. > > > > I understand you find this idea futile and pointless. > > > > > > > > On Wed, May 26, 2010 at 7:23 AM, Joel M. Halpern <[email protected]> > > wrote: > >> Actually, PNNI at least, and we believe Nimrod as well, allowed for local > >> policy in a number of regards. > >> However, the specific policies that follow naturally from BGP (and hence > >> have become our accepted policy language) are harder to do in those > >> systems. > >> > >> I was responding to the theoretical assertion of necessity that Toni was > >> making, which had a particular slant. that theoretical requirement I don't > >> buy, particular as propounded. > >> > >> The practical requirement: stick with BGP > >> is one I consider we are stuck with, no matter how much I would like to do > >> something different. (And I will readily grant that due to the > >> practicalities, I may even be wrong about the desirability of the > >> alternatives, but it doesn't seem to matter.) > >> > >> Yours, > >> Joel > >> > >> Tony Li wrote: > >>> > >>> 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 > >> > > > > > > > > -- > > DY > > > > > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
