Subject: Re: [rrg] RG futures

From: [email-masked]
Date: Thu, 06 May 2010 05:02:39 -0400

How aboutan honest discussion that deals with the real causes of the scalability problem!
Thescalability (size) issue only unveils how miserably bad the (most important)IETF routing paradigms are. Particularly:
1) DistanceVector
A glimpseto intra-domain routing shows that there is an alternative. Brian’s statement“forget Dijkstra” is terribly wrong. Correct is: “simple Dijkstra is notenough”.
After 6years discussion Geof Huston had to remind people that the RIB size is moreworrying than the FIB size. Millions of routes are being collected due togrowth and tighter meshing. Though not a single one needs to be collectedprovided though not a single one is really needed. DV eats up the storagememory and eats up the performance due to the amount of the update churn. Theimprovements achieved by LISP be acknowledged. But there are millions of useful(detouring) routes in addition which DV does not detect and will never be ableto detect. In addition, hereby TE is hampered in many ways. DV prevents havinga rearview mirror, i.e. it doesn’t provide the “upstream routes”. This preventsintelligent solutions for dealing with congestions and for balancing traffic ingeneral (avoiding congestions in the first place, time-of-day routing,…). Youcan only get solutions like re-ECN where the source is informed (!) who iseventually far away from the point of congestion and who has no knowledge aboutthe network and its current overall traffic situation at all. This is TE likeDiffServ: based on not-knowing what is going on outside.
A lastpoint:The ISP business model. Yes, with DV an ISP may deliberately preventbeing used as transit by not forwarding its reachabilities to some non-payingneighbor-ISP. I.e. this comes for free. But question for the experts: And whatif that neighbor disbelieves him and sends him packets nevertheless? Imho,TARAwould be able to handle this business relation issue by means of additions theknowledgeable experts are invited to contribute.
 
2) Prefixbuilding
Prefixbuilding is best in case you have no better solution.Pure TARA doesn’t need anysingle prefix nor any single AS number. However, for reasons of incrementaldeployment it would still need them with respect to those reachabilities thatare attached to non-TARA- routers. 
If some oneinsists on building prefixes that fits for routing he/she has to acknowledgethat E.164 is the best of all. Yes, it has good and bad implications: politicalones (= good and bad),
administrationalones (ITU-T versus IETF; = neutral), Istanbul-effect (= bad)
 
So far, theprefix building concept is the one and only reason for preventing fast next hopdetermination (applies to Dijkstra-based intra-domain AND DV-based inter-domainr.) i.e. for preventing Moore’s law applicability. It prevents any smarter FIB.
 
3)Multicast addresses
More thanten years ago I sent an email to Scott Bradner comparing the multicastaddresses with the compartments in trains: both are relicts due to the past,there, because the first train would draw a few coaches, here because LANshave/need multicast addresses. Approx. a billion of addresses could be madeavailable for unicast (as to relax the Ipv4 address depletion problem) by meansof 1 Multicast-Protocol Type combined with the sender’s unicast address as toreplace the multicast address. In case the counter argument were “thisundermines all the deployed multicast solutions” then I would add “good so”(see next).
 
4)Multicast forwarding
I heavilyquestion ALL existing multicast solutions. I am also wondering why multicastdoesn’t play any role at all in the RRG-discussion. My proposed solution wouldbe “cascade tree forwarding”, enabling state-less multicast to approx. 99,9 %of the involved routers.
 
It is thecombination of all these holy cows which blocks the view to a brighter routingtechnology, where there is no discrepancy between intra- and inter-domainrouting, nor between CES and  CEE, and where better technological tools wouldbe given to the hands of the next generation of students.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Aaron Falk <[email-masked]>
An: IRTF Routing RG <[email-masked]>
Verschickt: Mo., 26. Apr. 2010, 15:21
Thema: Re: [rrg] RG futures

Work in the IRTF is initiated, in general, by the folks who want to do
it.  Thus it is a more bottoms-up organization than the quotes below
would imply (c.f RFC2014, section 2.2) and the RG leadership plays a key
role.  My role is to guide and provide oversight.  So, I think Eliot is
asking an excellent question: what does this group want to do next? 
It's *your* group (or at least, those of you who want to continue to
collaborate).  Are there no other research areas in routing that folks
want to work on? 

--aaron

On 4/25/10 11:04 AM, Ran Atkinson wrote:
>> Eliot Lear originally wrote:
>>     
>>> What do people want to do next with this group?
>>>       
>> Scott Brim responded:
>> Declare victory, put it to sleep, and let Aaron decide what to do with it.
>>     
> RFC-2014 which is normative, indicates that the RG charter is a matter
> for the IRTF Chair, IRSG, and IAB.
>   

> RFC-4440, starting bottom of Page 2, specifically says:
>    The IRTF Chair is appointed by the Internet Architecture Board (IAB), 
>    and charters IRTF research groups (RGs) in consultation with the 
>    Internet Research Steering Group (IRSG) and with approval of the IAB.
>
> That says decisions about a future charter for this RG are in the hands 
> of the IRSG, IRTF Chair, and IAB, rather than being within the scope 
> of the RG itself.
>
> That seems entirely consistent with what Scott said.
>
> Ran

_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: <[email-masked]>
Date: Thu, 6 May 2010 10:18:19 +0100

I would simply turn off non-link-local multicast (on most routers it's not even on...) and return class D and class E addresses to the allocatable pool.

If this leads to a bonus upgrade of router equipment across the Internet - well, that's one way to ensure other protocols (e.g. IPv6) are available for use.

Lloyd Wood
http://sat-net.com/L.Wood
__________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: 06 May 2010 10:02
To: [email-masked]; [email-masked]
Subject: Re: [rrg] RG futures

[..]
3) Multicast addresses
More than ten years ago I sent an email to Scott Bradner comparing the multicast addresses with the compartments in trains: both are relicts due to the past, there, because the first train would draw a few coaches, here because LANs have/need multicast addresses. Approx. a billion of addresses could be made available for unicast (as to relax the Ipv4 address depletion problem) by means of 1 Multicast-Protocol Type combined with the sender’s unicast address as to replace the multicast address. In case the counter argument were “this undermines all the deployed multicast solutions” then I would add “good so” (see next).

4) Multicast forwarding
I heavily question ALL existing multicast solutions. I am also wondering why multicast doesn’t play any role at all in the RRG-discussion. My proposed solution would be “cascade tree forwarding”, enabling state-less multicast to approx. 99,9 % of the involved routers.

It is the combination of all these holy cows which blocks the view to a brighter routing technology, where there is no discrepancy between intra- and inter-domain routing, nor between CES and  CEE, and where better technological tools would be given to the hands of the next generation of students.

Heiner

---

From: Toni Stoev <[email-masked]>
Date: Fri, 7 May 2010 01:41:58 +0300

On Thursday 06 May 2010 12:02:39 [email-masked] sent:
> 
> How about an honest discussion that deals with the real causes of the scalability problem!
> The scalability (size) issue only unveils how miserably bad the (most important) IETF routing paradigms are. Particularly:
...
> Heiner

Intra-domain routing is as simple as node location naming follows topology.

Inter-domain routing has issues with intra-domain context – route identification prefixes based on intra-domain identity/location naming, so called addresses.
Inter-domain routing has issues with route destination/endpoint ambiguity – what an inter-domain route leads to, node(s) or autonomous system?

Regards to all.

---

From: [email-masked]
Date: Fri, 07 May 2010 04:12:48 -0400

Sure. Agreed. I know, we can only express our personal opinions and see what might happen.
Heiner

-----Ursprüngliche Mitteilung----- 
Von: [email-masked]
An: [email-masked]; [email-masked]; [email-masked]
Verschickt: Do., 6. Mai. 2010, 11:18
Thema: RE: [rrg] RG futures

I would simply turn off non-link-local multicast (on most routers it's not even 
on...) and return class D and class E addresses to the allocatable pool.

If this leads to a bonus upgrade of router equipment across the Internet - well, 
that's one way to ensure other protocols (e.g. IPv6) are available for use.

Lloyd Wood
http://sat-net.com/L.Wood
__________
From: [email-masked] [[email-masked]] On Behalf Of 
[email-masked] [[email-masked]]
Sent: 06 May 2010 10:02
To: [email-masked]; [email-masked]
Subject: Re: [rrg] RG futures

[..]
3) Multicast addresses
More than ten years ago I sent an email to Scott Bradner comparing the multicast 
addresses with the compartments in trains: both are relicts due to the past, 
there, because the first train would draw a few coaches, here because LANs 
have/need multicast addresses. Approx. a billion of addresses could be made 
available for unicast (as to relax the Ipv4 address depletion problem) by means 
of 1 Multicast-Protocol Type combined with the sender’s unicast address as to 
replace the multicast address. In case the counter argument were “this 
undermines all the deployed multicast solutions” then I would add “good so” (see 
next).

4) Multicast forwarding
I heavily question ALL existing multicast solutions. I am also wondering why 
multicast doesn’t play any role at all in the RRG-discussion. My proposed 
solution would be “cascade tree forwarding”, enabling state-less multicast to 
approx. 99,9 % of the involved routers.

It is the combination of all these holy cows which blocks the view to a brighter 
routing technology, where there is no discrepancy between intra- and 
inter-domain routing, nor between CES and  CEE, and where better technological 
tools would be given to the hands of the next generation of students.

Heiner

---

From: [email-masked]
Date: Fri, 07 May 2010 15:40:28 -0400

Toni,
I am sorry, but I don't understand what you mean.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Toni Stoev <[email-masked]>
An: IRTF RRG <[email-masked]>
Verschickt: Fr., 7. Mai. 2010, 0:41
Thema: Re: [rrg] RG futures

On Thursday 06 May 2010 12:02:39 [email-masked] sent:
> The scalability (size) issue only unveils how miserably bad the (most 
important) IETF routing paradigms are. Particularly:
...

Inter-domain routing has issues with intra-domain context – route identification 
prefixes based on intra-domain identity/location naming, so called addresses.
Inter-domain routing has issues with route destination/endpoint ambiguity – what 
an inter-domain route leads to, node(s) or autonomous system?

Regards to all.

---

From: Toni Stoev <[email-masked]>
Date: Sat, 8 May 2010 00:13:21 +0300

> I am sorry, but I don't understand what you mean.

Heiner,

Currently inter-domain routing is based on IP address prefixes, which are intra-domain context, and on AS number paths.
The simple and scalable model is the inter-domain routes to be only AS paths.

Toni

> An: IRTF RRG <[email-masked]>http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing

---

From: Dae Young KIM <[email-masked]>
Date: Sat, 8 May 2010 09:26:14 +0900

This sounds similar to an idea I raised some months ago; inter-domain
routing based on AS numbers.

Some people were criticizing that AS's are not of equal scales (from a
tiny one to a global scale) and that it is not a useful/practical
granularity.

Studying the IRON, the enterprise also can be as small as SOHO and as
big as the entire global Internet. Not much different.

Then why not try an inter-domain routing (solely) based on AS numbers?

Nonsense?

Regards,
DY

---

From: Dae Young KIM <[email-masked]>
Date: Sat, 8 May 2010 09:41:52 +0900

Like...

  o Packets would be appended by an AS number of the destination at
exiting its own AS.

  o DFZ routers sees only AS numbers in determining the next hop router.

  o The destination IP address would be examined only after the packet
has entered the destination AS.

Regards,
DY

---

From: Dae Young KIM <[email-masked]>
Date: Sat, 8 May 2010 10:20:56 +0900

In fact, I find this is essentially the same idea as depicted in
RFC1955<http://tools.ietf.org/html/rfc1955> by Bob Hinden back in
1996... except that he proposed AD-headers while I thought of AD(==AS)
appendix in the option field of IP packets.

He also comments

  - that the scheme can be extended to local (non-globally unique)
addresses, (no worrying anymore about address depletion) and

  - that even IS-IS can be used (not necessarily BGP or OSFP) to the
additional benefit that IS-IS routes on actual endpoints, (not PoA or
interfaces).

Curious to know why this was rejected in IPNG?

Regards,
DY

---

From: [email-masked]
Date: Sat, 08 May 2010 02:31:04 -0400

Now I understand. But sorry, this is even worse than I could ever have imagined.

I think, the RRG would do best by consideringg    A L L    of my "accusations" against the routing paradigms.

Try to answer this: 
Why is it good not to know half of the possible routes?
What value is provided by the orthogonality between intra-and inter-domain routing ?
Why is almost stateless multicast a VERY POOR concept (meaning, for 99,9% of the involved routers, 
not only no state but even no recognition at all that the passing unicast flow has anything to do with p2mp) ?
Why is TE better off by not knowing the routes the traffic comes in ?

Just a few ones.
Heiner

-----Ursprüngliche Mitteilung----- 
Von: Toni Stoev <[email-masked]>
An: IRTF RRG <[email-masked]>
Verschickt: Fr., 7. Mai. 2010, 23:13
Thema: Re: [rrg] RG futures

Heiner,

Currently inter-domain routing is based on IP address prefixes, which are 
intra-domain context, and on AS number paths.
The simple and scalable model is the inter-domain routes to be only AS paths.

Toni

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 08 May 2010 12:06:55 +0200

Hi DY,

Just for the record Enke Chen and myself have came up with this idea as 
well about ... 4 years ago :)

There are number of written documents we have on this. You can easily 
google for it to see where is has been proposed before (even in this WG):

http://www.ietf.org/mail-archive/web/idr/current/msg03174.html

The main part of our proposal was that all transit ASes do not need to 
be upgraded as IP header would contain plane old IPv4 address 
constructed from AS number. Also all destination ASBRs would 
automatically recognize this address and decapsulate.

But our primary focus was not too address "melting Internet" ... our 
focus was to provide a means and ability to provide fast connectivity 
restoration aka PIC but in the inter-as scope (so far it works well 
intra-as).

The mapping plane for it comes for free ... each BGP update carries the 
origin AS today .. now we can even RPKI validate it - to eliminate 
manual mistakes. Soon we will also extend current origin validation to 
make it even more secure.

Clearly the deployment price to pay would be to carry AS host routes oh 
well ... perhaps additional 30K routes more in the Internet if everyone 
suddenly would participate.

But where and what is the benefit ...... The benefit would be only 
feasible if for a given network all of it's customers and transits start 
sending AS IP address encapsulated packets. Otherwise you still need to 
keep all addresses in control plane as well as put all addresses in the 
FIB.

But now that we have ILNP on the table I am just thinking loud here ... 
if DNS record could return us not the locator or set of locators, but 
EID's numerical representation of an AS number hosts which support it 
could easily encap it this way while in the inner header still contain 
today's IP address of the given server.

So here is more of the question to ILNP authors if they have considered 
such option ....

Many thx,
R.

> On Sat, May 8, 2010 at 9:26 AM, Dae Young KIM<[email-masked]>  wrote:
>> On Sat, May 8, 2010 at 6:13 AM, Toni Stoev<[email-masked]>  wrote:
>>>> Von: Toni Stoev<[email-masked]>
>>>> An: IRTF RRG<[email-masked]>http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 08 May 2010 12:11:54 +0200

s/EID's numerical representation/EID's + numerical representation/

Sorry missed the "+"

R.

---

From: Dae Young KIM <[email-masked]>
Date: Sat, 8 May 2010 19:28:36 +0900

Hi, Robert,

Thank you for the info.

Now I'd observe that everyone has different variations in the details
of operation, although the basic idea of having IDR work on AS
numbers.

We might suggest everyone comes with his/her own draft based on this
basic idea and compare the pros/cons of each proposals. The starting
point might well be Bob Hinden's RFC1955 if people would agree.
Different proposals would be weighed against routing scalability,
mobility, multi-homing, easiness of deployment, etc. Maybe, Robin's
criteria list might come into play again.

Concern.

Now that the group (chairs) have already chosen ILNP as the ultimate
solution, I'm not sure if there's any value/use of exploring other
lines of approaches. Perhaps, 'out of scope' or 'out of context'?

Regards,
DY

On Sat, May 8, 2010 at 7:06 PM, Robert Raszuk <[email-masked]> wrote:
> Hi DY,
>
> Just for the record Enke Chen and myself have came up with this idea as well
> about ... 4 years ago :)
>
> There are number of written documents we have on this. You can easily google
> for it to see where is has been proposed before (even in this WG):
>
> The main part of our proposal was that all transit ASes do not need to be
> upgraded as IP header would contain plane old IPv4 address constructed from
> AS number. Also all destination ASBRs would automatically recognize this
> address and decapsulate.
>
> But our primary focus was not too address "melting Internet" ... our focus
> was to provide a means and ability to provide fast connectivity restoration
> aka PIC but in the inter-as scope (so far it works well intra-as).
>
> origin AS today .. now we can even RPKI validate it - to eliminate manual
> mistakes. Soon we will also extend current origin validation to make it even
> more secure.
>
> Clearly the deployment price to pay would be to carry AS host routes oh well
> ... perhaps additional 30K routes more in the Internet if everyone suddenly
> would participate.
>
> But where and what is the benefit ...... The benefit would be only feasible
> if for a given network all of it's customers and transits start sending AS
> IP address encapsulated packets. Otherwise you still need to keep all
> addresses in control plane as well as put all addresses in the FIB.
>
> But now that we have ILNP on the table I am just thinking loud here ... if
> DNS record could return us not the locator or set of locators, but EID's
> numerical representation of an AS number hosts which support it could easily
> encap it this way while in the inner header still contain today's IP address
> of the given server.
>
> So here is more of the question to ILNP authors if they have considered such
> option ....
>
> Many thx,
> R.
>
>
>> Like...
>>
>>>> Currently inter-domain routing is based on IP address prefixes, which
>>>> are intra-domain context, and on AS number paths.
>>>>> An: IRTF
>>>>> RRG<[email-masked]>http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
>>>>>> How about an honest discussion that deals with the real causes of the
>>>>>
>>>>> scalability problem!
>>>>>>

---

From: Paul Jakma <[email-masked]>
Date: Sat, 8 May 2010 12:20:47 +0100 (BST)

> routing based on AS numbers.

Note that you can organise routing around AS numbers and so reduce 
routing state requirements perhaps without having to change IP 
forwarding. I.e. you can compute paths on an AS-based topology, and 
then compute IP routes based on which ASes terminate which prefixes. 
As the association of IP prefix:AS is a lot more static than the 
topology, you could reduce the amount of information that had to be 
passed around.

There's still a lot of details and problems you'd have to work out 
though.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
"The Computer made me do it."

---

From: Dae Young KIM <[email-masked]>
Date: Sat, 8 May 2010 21:32:41 +0900

Hi, Paul,

On Sat, May 8, 2010 at 8:20 PM, Paul Jakma <[email-masked]> wrote:

> Note that you can organise routing around AS numbers and so reduce routing
> state requirements perhaps without having to change IP forwarding. I.e. you
> can compute paths on an AS-based topology, and then compute IP routes based
> on which ASes terminate which prefixes. As the association of IP prefix:AS
> is a lot more static than the topology, you could reduce the amount of
> information that had to be passed around.

It seems your idea is based on global IP addressing. What I have in
mind is to get rid of global addressing. So, only the pair

   (local) IP address + AS number

would provide global uniqueness. IP addresses would be local to a
specific AS. Same IP addresses can be reused in different AS's. This
way we are free from the problem of address depletion. It doesn't
matter whether you use IPv4 or IPv6 as your local addressing. A good
thing, isn't it?

So, IDR routers look only at AS numbers, not at IP addresses which
bears no meaning in IDR.

In fact, each AS(or AD) in DFZ can be seen as a node (point) in the
IDR topology. So, the AS number can be interpreted as AS address (or
AD address as Bob Hinden called it). Then, this topology is nothing
different from those any intra-domain routing would deal with. Just
another upward recursion of the same-quality routing domain.

Therefore, you can even use OSPF or IS-IS in DFZ. I think this is what
Heiner (or someone else) kept arguing for; why not use LS routing in
DFZ? Remember Bob Hinden also commented on this possibility, too..
already back 15 years ago. How far sighted.

And also, Bod Hinden commented that IS-IS provides an additional
benefit of routing on endpoints, not interfaces or PoA. It is
interesting that he even regarded it as benefit. We had our hero
already since many years ago.

And you know what? ILNP also says its ID points to the node, not to
the interface or PoA. How nice.

Now with bits from here and bits from there, the whole picture I had
in mind seems to be converging to:

   o Addresses name the nodes(or end-points), not the interfaces or PoAs.

   o Node addresses are local to a given domain(or AS or AD...).

   o Domains are also named by domain addresses. Domain addresses bear
context only in the inter-domain topology.

   o Each domain in the inter-domain topology reduces to a point or a
node as called in usual routing topologies. Therefore, any routing
protocol can be used, be it DV or LS.

   o Since domain addresses name the domain (point) itself, not the
links connecting them, you might want to use IS-IS rather than OSPF
since the former deals with endpoint addresses.

In essence, we are reaching at a recursive network like Joe Touch or
Jon Day asserted:

  o Within a domain, local addressing (for nodes) and LS routing (more
specifically IS-IS since nodes are addressed, not the interfaces) are
used.

  o At a higher recursion level formerly known as DFZ, also local
addressing (for domains) and IS-IS are used.

  o Repetition of exactly the same routing infra in two adjacent layers.

  o What if we have to deal with inter-planetary routing? Or when we
face with the address depletion problem also with Domain addressing?
Then, build another layer ontop, and repeat the same routing infra.
Out of the solar system....?

  o What if we have to dig into our human body to extend our
networking internally into our organs and even cells?.. body area
network... Then you just repeat the same routing infra in the reverse
direction or in the inward direction. The one point node now becomes a
universe for a population of internal sub-node points.

   o Just like the same nature repeats inwards to micro-cosom and
outwards to ever expanding universe.

Isn't this simple? Isn't this scalable? We don't need to manage global
unique address spaces. We don't need governance. We are now free. Our
systems is fully decentralized, distributed.

>
> There's still a lot of details and problems you'd have to work out though.
>
> regards,
> --

-- 

Regards,
DY

---

From: Paul Jakma <[email-masked]>
Date: Sat, 8 May 2010 13:57:36 +0100 (BST)

On Sat, 8 May 2010, Dae Young KIM wrote:

> mind is to get rid of global addressing.

Yes, I gathered that, but it's unnecessary AFAICT.

> So, IDR routers look only at AS numbers, not at IP addresses which 

Sure, but why? :) What problem are you trying to address? If you're 
trying to force aggregation by AS, then why not use an IPv6 prefix 
that embeds the ASN? Basically, the underlying forwarding technology 
isn't the problem - the problem is finding a good way to apply some 
higher-level structure to it.

IPv6 almost certainly has the room to accomodate any reasonable 
addressing structure that can't fit with IPv4. If you're proposing a 
solution that requires all forwarding infrastructure to be upgraded, 
it'll have to have amazing benefits, and be impossible to layer onto 
IP.

Also you need to consider "Why do we currently have ASes that 
originate multiple disparate prefixes?".

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
Nihilism should commence with oneself.

---

From: Dae Young KIM <[email-masked]>
Date: Sat, 8 May 2010 23:24:28 +0900

On Sat, May 8, 2010 at 9:57 PM, Paul Jakma <[email-masked]> wrote:
>> It seems your idea is based on global IP addressing. What I have in mind
>> is to get rid of global addressing.
>
>> So, IDR routers look only at AS numbers, not at IP addresses which bears
>> no meaning in IDR.
>
> Sure, but why? :) What problem are you trying to address? If you're trying
> to force aggregation by AS, then why not use an IPv6 prefix that embeds the
> ASN? Basically, the underlying forwarding technology isn't the problem - the
> problem is finding a good way to apply some higher-level structure to it.
>
> IPv6 almost certainly has the room to accomodate any reasonable addressing
> structure that can't fit with IPv4. If you're proposing a solution that
> requires all forwarding infrastructure to be upgraded, it'll have to have
> amazing benefits, and be impossible to layer onto IP.
>
> Also you need to consider "Why do we currently have ASes that originate
> multiple disparate prefixes?".

Yes, the correct question.

Well... let me try. Let's take the case of IPv4 which is facing more
imminent/urgent routing scalability problem.

What is the maximum size (in node) of operating domains that are
managed by an intra-domain routing? Would 2*16 be too big? .. and they
don't do prefix aggregation in intra-domain routing, or do they?

It happens that AS number is also 16 bit, although larger AS numbers
began to be issued. Would you still need prefix aggregation if the
prefix (or the AS number) is 16 bit long? If not, you can apply LS
routing also to inter-domains.

In fact, I won't be against virtual prefix, either; IRON, RANGER,
Ivip, etc. Even with virtual prefix,

    o Addressing can be local within domains(or enterprise or site).
Any addressing in fact; IPv4, IPv6, and even CNLP/NSAP. Or any other
addressing if you deal with sensor or smart dust networks. Freedom to
users.

    o DNS query would return

             Destination address (of any type) + Domain virtual prefix

    o Virtual prefix would be imbedded in the option field of packets.
(Or some people might prefer to put it in outer encapsulator).

    o Virtual prefixes will be mapped to prefixes provided by ISP's at
exiting the domains.

    o Since prefixes provided by ISPs will be used in DFZ, prefix
aggregation will take place much more effectively, to combat routing
scalability.

    o Or tunneling can take place in DFZ as in IRON or similar ones.

One burden here is to manage virtual prefixes and mapping to PA
prefixes. Since it seems most people are read for this additional
mapping, it's OK to me, too.

Or.. perhaps, I'm drifting around again...

-- 

Regards,
DY

---

From: Dae Young KIM <[email-masked]>
Date: Sat, 8 May 2010 23:34:26 +0900

On Sat, May 8, 2010 at 7:06 PM, Robert Raszuk <[email-masked]> wrote:
> + numerical representation of an AS number, hosts which support it could easily

Yes, I have the feeling that, with only a little bit of tweaking of or
a clever definition of Locators, people are basically going the same
way.

-- 
Regards,
DY

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 08 May 2010 10:54:57 -0400

As far as I can tell, trying to create an IPv6 address that is 
mathematically equivalent to the AS number does us very little good if 
we assume some sort of mapping system (like ILNP.)  It also does us very 
little good if we assume that customers use PA addresses.

First, note that AS numbers are now 32 bits.  So an AS number solution 
presume IPv6.  (That doesn't actually bother me, but it is worth 
mentioning.)

Second, the reason I referred to an Ipv6 address is that I am not going 
to assume global replacement of core routers and global changes in the 
core forwarding paradigm.  (Edge changes, yes, we have discussed many of 
those.)

Given that, then the primary goal we have already been working towards 
is that the IPv6 addresses used in packets in the core be aggregatable 
addresses.  As such, if we got to the point that these were the only 
addresses that were used for packets in the core, we would see 
significant benefit in advertisement / FIB size.

Folks could argue that operators today disaggregate such blocks.  And 
indeed they sometimes do.  They do so for good reasons.  Attempting to 
tell the operators that they MUST use a system that does not permit that 
(such as a pure AS based system without the ability to circulate 
multiple advertisements for the AS, will mean that they will refuse to 
adopt the solution.  For example, while I do not agree that the 
operators must have exclusive control over traffic engineering (which is 
an argument that has been used against shim6, LISP, ILNP, ...), it is 
true that they should have control of the traffic engineering of the 
paths to their own prefixes.

Yes, I would prefer to address such a requirement by different tools 
than disaggregation and path stuffing.  previous efforts to go there 
have foundered on teh lack of an incentive for the core operators to 
make any changes in that space.  (They don't get any benefit until 
almost everyone has shifted, and they incur MAJOR costs.)

And if we had a routing system that gave us TE without disaggregation, 
then PA address blocks would be a small enough multiplier that we 
wouldn't care if each operator advertised a few of them.

Hence, there may be some computational (internal to the router) reasons 
to focus on the AS first, and there are some dynamics reasons to wonder 
about using an AS-centric approach, as long as we have heavily 
disaggregated advertisements, in practice this is not in my view really 
a solution to the problem.

Yours,
Joel

Paul Jakma wrote:
> trying to force aggregation by AS, then why not use an IPv6 prefix that 
> embeds the ASN? Basically, the underlying forwarding technology isn't 
> the problem - the problem is finding a good way to apply some 
> it'll have to have amazing benefits, and be impossible to layer onto IP.
>

---

From: Paul Jakma <[email-masked]>
Date: Sat, 8 May 2010 16:12:55 +0100 (BST)

On Sat, 8 May 2010, Joel M. Halpern wrote:

> mathematically equivalent to the AS number does us very little good 
> if we assume some sort of mapping system (like ILNP.)  It also does 
> us very little good if we assume that customers use PA addresses.

It's worth exploring the non-mapping solution space.

There are a number of scenarios where, even with mapping solutions, 
the core internet locator topology (i.e. by definition not mapped) 
continues to experience the same scale of growth as is currently 
causing us today to consider mapping solutions.

> Second, the reason I referred to an Ipv6 address is that I am not 
> going to assume global replacement of core routers and global 
> changes in the core forwarding paradigm.  (Edge changes, yes, we 
> have discussed many of those.)

Yes, I was trying to hint at this myself. :)

> Folks could argue that operators today disaggregate such blocks.

Indeed. More than that, there is no guarantee today that an AS has 
internal transit. I.e. an AS is not per se continuous.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
Once the toothpaste is out of the tube, it's hard to get it back in.
 		-- H.R. Haldeman

---

From: Scott Brim <[email-masked]>
Date: Sun, 09 May 2010 11:42:58 -0400

> lines of approaches. Perhaps, 'out of scope' or 'out of context'?

The RRG is still a research group.  You can propose anything you want 
and see what flies.

---

From: Paul Jakma <[email-masked]>
Date: Sat, 8 May 2010 17:17:52 +0100 (BST)

Hi Kim Dae Young,

On Sat, 8 May 2010, Dae Young KIM wrote:

> managed by an intra-domain routing? Would 2*16 be too big? .. and 
> they don't do prefix aggregation in intra-domain routing, or do 
> they?

I believe intra-domain protocols do tend to have mechanisms to 
sub-divide their routing and do aggregation between those divisions. 
OSPF, IS-IS both have at least.

> if the prefix (or the AS number) is 16 bit long? If not, you can 
> apply LS routing also to inter-domains.

You could, but note that you do not need to change the forwarding 
technology. I.e. you could use link-state to construct a topology of 
ASes. Then, like the 2nd stage calculations of SPF in OSPF, you could 
work out routes for IP prefixes originated by those ASes.

There a number of problems though that'd need to be solved:

- traffic engineering: an AS is not fine-grained enough, so you'd
   need to allow for sub-AS entitities somehow.

- other policy tools that operators use to restrict which paths may
   be used for specific prefixes (easy to do with BGP)

> Or.. perhaps, I'm drifting around again...

Drifting can sometimes take you to interesting places (though, more 
often you just get stuck in the reeds). ;)

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
It is only people of small moral stature who have to stand on their dignity.

---

From: Patrick Frejborg <[email-masked]>
Date: Sun, 9 May 2010 10:59:51 +0300

Joel,

what if the locator to reach an ISP is not coupled to an AS number,
instead the ISP could use a locator to identify an area at the ISP -
the area could consist of several AS or only a part of a specific AS
of the ISP.
If the ISP could have several locators for traffic engineering
purposes, i.e. the locator is decoupled from the AS structure, the ISP
could create service classes with different attributes for its
customer and their incoming traffic.
Is this something ISP would be interested in?

There is a strong opinion on to have an identifier in the new architecture.
One thing I would like to ask about the identifier - could it be
abused and we will get into privacy issues? With HTTP cookies the end
user can always make a choice, accept or deny. But if the identifier
is a crucial part of the architecture my guess is that enterprise
policies will state that the identifier has to be more or less
permanent  for a user when attached to the enterprise network, for
tracking purposes.
What about ISP, could they create a similar policy - probably not -
but that could depend upon in which country the ISP operates in.
Has there been any discussions around identifiers and privacy concerns?

-- patte

On Sat, May 8, 2010 at 5:54 PM, Joel M. Halpern <[email-masked]> wrote:
> mathematically equivalent to the AS number does us very little good if we
> assume some sort of mapping system (like ILNP.)  It also does us very little
> good if we assume that customers use PA addresses.
>
> Second, the reason I referred to an Ipv6 address is that I am not going to
> assume global replacement of core routers and global changes in the core
> forwarding paradigm.  (Edge changes, yes, we have discussed many of those.)
>
> Given that, then the primary goal we have already been working towards is
> that the IPv6 addresses used in packets in the core be aggregatable
> addresses that were used for packets in the core, we would see significant
> benefit in advertisement / FIB size.
>
> Folks could argue that operators today disaggregate such blocks.  And indeed
> they sometimes do.  They do so for good reasons.  Attempting to tell the
> operators that they MUST use a system that does not permit that (such as a
> pure AS based system without the ability to circulate multiple
> advertisements for the AS, will mean that they will refuse to adopt the
> solution.  For example, while I do not agree that the operators must have
> exclusive control over traffic engineering (which is an argument that has
> been used against shim6, LISP, ILNP, ...), it is true that they should have
> control of the traffic engineering of the paths to their own prefixes.
>
> Yes, I would prefer to address such a requirement by different tools than
> disaggregation and path stuffing.  previous efforts to go there have
> foundered on teh lack of an incentive for the core operators to make any
> changes in that space.  (They don't get any benefit until almost everyone
> has shifted, and they incur MAJOR costs.)
>
> And if we had a routing system that gave us TE without disaggregation, then
> PA address blocks would be a small enough multiplier that we wouldn't care
> if each operator advertised a few of them.
>
> Hence, there may be some computational (internal to the router) reasons to
> focus on the AS first, and there are some dynamics reasons to wonder about
> using an AS-centric approach, as long as we have heavily disaggregated
> advertisements, in practice this is not in my view really a solution to the
> problem.
>
> Yours,
> Joel
>
> Paul Jakma wrote:
>>