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

Reply via email to