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. 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 > -- DY _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
