Subject: [rrg] FW: I-D Action:draft-irtf-rrg-recommendation-08.txt

From: Tony Li <[email-masked]>
Date: Tue, 25 May 2010 01:03:29 -0700

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

---

From: Toni Stoev <[email-masked]>
Date: Tue, 25 May 2010 17:09:08 +0300

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 25 May 2010 10:27:18 -0400

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

---

From: Tony Li <[email-masked]>
Date: Tue, 25 May 2010 15:00:11 -0700

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

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 
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:
> 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
>> I hope to do another
> editorial pass, so comments and additions are still
>> welcome.
>>
>>
> Regards,
>> Tony
>>
>>
>> ------ Forwarded Message
>> From:
>> A New
> Internet-Draft is available from the on-line Internet-Drafts
>>
> directories.
>>
>>  Date
> : 2010-05-24
>> I-D-Announce mailing
> list
>> 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
_____________________________________
> __________
rrg mailing
> list
[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 25 May 2010 18:23:33 -0400

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

---

From: Tony Li <[email-masked]>
Date: Tue, 25 May 2010 17:16:31 -0700

Hi Toni,

Thanks for the comments.

> 17.3.  Rationale, sentence 3 has an extra "is".

Thanks, fixed.

Tony

---

From: Dae Young KIM <[email-masked]>
Date: Wed, 26 May 2010 09:39:59 +0900

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.
> making, which had a particular slant.  that theoretical requirement I don't
> buy, particular as propounded.
>
> 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
>> necessary from a theoretical perspective.  (From a practical perspective,
>> I
>>>
>>>> From:
>>> <[email-masked]>
>>>>
>>>> Date:
>>> Mon, 24 May 2010 18:30:02 -0700 (PDT)
>>>>
>>>>  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
>>>>
>>>> as
>>> well as some of the subsequent analysis.
>>>>
>>>> A URL for this Internet-Draft
>>>
>>> is:
>>>> Below is the data which will enable
>>>
>>> a MIME compliant mail reader
>>>>
>>>> implementation to automatically retrieve the
>>>
>>> ASCII version of the
>>>>
>>>> Internet-Draft.
>>>>
>>>> ------ End of Forwarded
>>> Message

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Wed, 26 May 2010 10:30:38 +0900

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?

-- 
DY