Subject: [rrg] Inter-/intra-domain operation distinction

From: Toni Stoev <[email-masked]>
Date: Wed, 26 May 2010 10:42:16 +0300

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-masked]> 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-masked]> 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-masked]> 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-masked]>
> >>>>>
> >>>>> Reply-To: <[email-masked]>
> >>>>> Date:
> >>>>
> >>>> Mon, 24 May 2010 18:30:02 -0700 (PDT)
> >>>>>
> >>>>> To: <[email-masked]>
> >>>>>
> >>>> 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-masked]
> >>>>>
> >>>> 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-masked]
> >>>>
> >>>> http://www.irtf.org/mailman/listinfo/rrg
> >>>
> >>> _____________________________________
> >>>>
> >>>> __________
> >>>
> >>> rrg mailing
> >>>>
> >>>> list
> >>>
> >>> [email-masked]
> >>> http://www.irtf.org/mailman/listinfo/rrg
> >>>
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> rrg mailing list
> >> [email-masked]
> >> http://www.irtf.org/mailman/listinfo/rrg
> >>
> >
> >
> >
> > --
> > DY
> >
> 
> 
>