Subject: [rrg] Next topic?

From: Tony Li <[email-masked]>
Date: Sun, 8 May 2011 10:18:26 -0700

Hi all,

It's time to start the conversation about where the RRG is headed.  Towards that end, I'd like to open the floor for the discussion of topics.  Any _research_ topic within the broad area of routing and addressing is appropriate.  

I propose the following process: we hold this discussion this month, trying to identify relevant topics.  Each topic should have a succinct statement of its goals.  At the end of the month, we poll to determine the interest level in the various topics.  Those that seem to have critical mass are recommended to the IRTF Chair for consideration.

The default answer, if no topic has critical mass, is for the RG to go on hiatus.

Any questions or comments on the process?

Any proposals of research topics?

The floor is open...

Tony

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 10 May 2011 11:10:25 +0200

Hi,

What about doing some work in multi-path routing in the inter-domain?
i.e. enabling a router to use multiple paths with potential different 
characteristics to forward packets across domains.
Would people find this topic interesting?

regards, marcelo

El 08/05/11 19:18, Tony Li escribió:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: [email-masked]
Date: Tue, 10 May 2011 06:01:17 -0400

Obviously no one, because this was a main goal of ignored TARA: multipath forwarding based on a network graph which is composed of 
inter- AND intra-network links and which  not only comprises  ECMPs but also  detouring paths  via equidistant or even more remote routers.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: marcelo bagnulo braun <[email-masked]>
An: [email-masked]
Verschickt: Di., 10. Mai. 2011, 11:10
Thema: Re: [rrg] Next topic?

Hi, 
 
What about doing some work in multi-path routing in the inter-domain? 
i.e. enabling a router to use multiple paths with potential different characteristics to forward packets across domains. 
Would people find this topic interesting? 
 
regards, marcelo

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 10 May 2011 15:03:28 +0300

Hello Marcelo,

In fact I happen to be working on the topic you are suggesting. I am interested and willing to contribute. Should we have an initial state of the art description?

- Hannu 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext marcelo bagnulo braun
Sent: Tuesday, May 10, 2011 12:10 PM
To: [email-masked]
Subject: Re: [rrg] Next topic?

Hi,

regards, marcelo

---

From: Christopher Pluntke <[email-masked]>
Date: Tue, 10 May 2011 14:02:10 +0100

Hi,

I think there are many interesting problems to be explored in the
context of inter-domain multipath routing. Having mainly done work on
intra-domain multipath routing so far, I would be very interested in
looking at this as well.

Christopher

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 10 May 2011 15:05:03 +0300

Based on my reading of TARA it was all about geographical addressing.

-          Hannu 

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Tuesday, May 10, 2011 1:01 PM
To: [email-masked]; [email-masked]
Subject: Re: [rrg] Next topic?

Heiner

-----Ursprüngliche Mitteilung----- 
Von: marcelo bagnulo braun <[email-masked]>
An: [email-masked]
Verschickt: Di., 10. Mai. 2011, 11:10
Thema: Re: [rrg] Next topic?

Hi, 

regards, marcelo

---

From: Sampo Syreeni <[email-masked]>
Date: Wed, 11 May 2011 01:36:07 +0300 (EEST)

On 2011-05-10, marcelo bagnulo braun wrote:

> characteristics to forward packets across domains. Would people find 
> this topic interesting?

I'd guess they would, since the idea is so old and also underexploited. 
But does it bring in real extra value? I.e. does anybody know whether 
multipath routing could significantly increase the total utilization of 
the routing fabric, either now or under some theoretically founded 
future situation?

If nobody knows, a preliminary study could be IRTF material.
-- 
Sampo Syreeni, aka decoy - [email-masked], http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

---

From: [email-masked]
Date: Wed, 11 May 2011 01:15:21 -0400

Hannu, 
please admit that Columbus routing is part of multipath forwarding and I will admit that I deliberately obstained from submitting a 01-version of the TARA-draft that contained in detail how to do Columbus routing based on TARA.

I don't know the secret why DV is such sacrosanct but I know for sure that enhancements for routing via more and more remote nodes would blow up DV.

Offlist I received comments about what to do with so many alternative paths, when provided. Indeed, they need to be utilized for the overall benefit
(traffic balancing, congestion avoidance, congestion handling). This however would need a rearview mirror i.e. knowledge about upstream paths from where the traffic comes from. Again: not possible based on DV.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Flinck, Hannu (NSN - FI/Espoo) <[email-masked]>
An: [email-masked]; [email-masked]; [email-masked]
Verschickt: Di., 10. Mai. 2011, 14:05
Thema: RE: [rrg] Next topic?

-          Hannu 

Heiner

-----Ursprüngliche Mitteilung----- 
Von: marcelo bagnulo braun <[email-masked]>
An: [email-masked]
Verschickt: Di., 10. Mai. 2011, 11:10
Thema: Re: [rrg] Next topic?

Hi, 

regards, marcelo 

El 08/05/11 19:18, Tony Li escribió: 
> http://www.irtf.org/mailman/listinfo/rrg ;
> 
 
_______________________________________________ 
rrg mailing list 
[email-masked] 
http://www.irtf.org/mailman/listinfo/rrg ;

---

From: Jose Manuel Camacho Camacho <[email-masked]>
Date: Thu, 12 May 2011 00:49:28 +0200

I guess there are some potential advantages in deploying multipath  
inter-domain routing. For instance, currently each border router  
forwards the traffic for a prefix through the same next AS. Balancing  
through two different next ASes it is not possible without re- 
advertising and sending the control plane to reconverge. Using  
multipath the balancing could be done even in a fine granularity (e.g.  
per packet) so that,

	- Different treatment (e.g. regarding QoS) could be provided per  
packet/flow, relaying traffic to a better provider (likely to have a  
higher pricing) and charging more money to the customers.
	- The latter may enable pricing and services competition.
	- Egress traffic engineering could be decoupled from the routing  
advertisement, forwarding to an upstream provider or another should be  
transparent to downstream customer ASes if they all the paths are  
advertised beforehand.
	- Congestion control may be more flexible for ISPs.

Thinking of future architectures, the case of multipath-aware  
transport protocols would let some or full control of the path  
selection to final hosts. It is not likely that ISPs go for this, but  
theoretically failure detection, failure recovery and better  
congestion control should be possible in this scenario, since end- 
hosts can measure end-to-end performance easily.

Jose M. Camacho,   [email-masked], www.uc3m.es
+34916248795

El 11/05/2011, a las 0:36, Sampo Syreeni escribió:

>> What about doing some work in multi-path routing in the inter- 
>> domain? i.e. enabling a router to use multiple paths with potential  
>> different characteristics to forward packets across domains. Would  
>> people find this topic interesting?
>
> I'd guess they would, since the idea is so old and also  
> underexploited. But does it bring in real extra value? I.e. does  
> anybody know whether multipath routing could significantly increase  
> the total utilization of the routing fabric, either now or under  
> some theoretically founded future situation?
>

---

From: Tony Li <[email-masked]>
Date: Wed, 11 May 2011 16:06:03 -0700

> Would people find this topic interesting?

It looks like there are a number of people who are at least somewhat interested in this topic.

To move this topic forward, it would be very good to have a very clear statement of what this would (and would not) involve as research goals, and the specific researchers who are interested in contributing to this effort.  Obviously, much of this topic might involve direct protocol modifications or mechanism proposals.  These would be inappropriate as research goals, as these would be overlapping with the work that the IETF is chartered to perform.  Answering architectural questions would be appropriate, IMHO.

Folks writing topic proposals might do so with an eye on the current RRG charter.  Any eventual topics will necessarily become part of our rechartering effort.

Tony

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 12 May 2011 07:26:32 +0200

Ok, let me try to coordinate with others to produce some first draft of 
this probably during next week, is that ok?

---

From: Tony Li <[email-masked]>
Date: Wed, 11 May 2011 23:52:56 -0700

That should be fine, thanks.  Again, I'd like to move forward with all proposals by the end of the month.

Tony

On May 11, 2011, at 10:26 PM, marcelo bagnulo braun wrote:

> Ok, let me try to coordinate with others to produce some first draft of this probably during next week, is that ok?
> 
> 
>

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 13 May 2011 09:29:14 +0800

Hi Tony and all,

In the past few years, RRG has done a lot of excellent research work to
explore various ideas and approaches (e.g., map&encap, id/locator split and
translation...) to addressing the Internet routing scalability issue. Today
it seems that the cloud Data Center Network (DCN) and Data Center
Interconnection (DCI) scenarios are facing a similar scalability challenge
(i.e., MAC forwarding table scalability issue). The demand for VM mobility
within the whole large L2 data center network or even across geographically
dispersed data centers is one major driving force of extending the L2 domain
scope larger and larger.

Although the reason for the MAC forwarding table scalability issue in the
DCN/DCI scenarios is not the same as that for the Internet routing
scalability issue, the ideas and approaches suitable for scaling the
Internet routing system could be utilized to deal with the MAC forwarding
table scalability issue. There are already many such attempts in reality,
especially in the academic circle. VL2 , SEATTLE and MOOSE are good examples
of them.

Hence I suggest we spend some time to consider whether we could utilize our
experience which was obtained from the past and ongoing Internet routing
scalability solution research to address the similar scalability issue
existed in the DCN/DCI scenarios, for example, we could attempt or even
develop those familiar ideas or approaches mentioned above to address the
MAC table scalability issue in the DCN/DCI scenarios.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Tony Li
> 发送时间: 2011年5月9日 1:18
> 收件人: [email-masked]
> 主题: [rrg] Next topic?
> 
> 
> Hi all,
> 
> It's time to start the conversation about where the RRG is headed.
Towards
> that end, I'd like to open the floor for the discussion of topics.  Any
_research_
> topic within the broad area of routing and addressing is appropriate.
> 
> I propose the following process: we hold this discussion this month,
trying to
> identify relevant topics.  Each topic should have a succinct statement of
its
> goals.  At the end of the month, we poll to determine the interest level
in the
> various topics.  Those that seem to have critical mass are recommended to
> the IRTF Chair for consideration.
>

---

From: "Michael K. Smith - Adhost" <[email-masked]>
Date: Fri, 13 May 2011 02:03:07 +0000

>MAC table scalability issue in the DCN/DCI scenarios.

As an adjunct to this line, there is the ARMD group in the IETF (not
officially chartered AFAIK) and an associated BOF at NANOG 52 in Denver.

Mike

---

From: Katsushi Kobayashi <[email-masked]>
Date: Fri, 13 May 2011 11:52:58 +0900

Hi,

I would like point out another requirement from HPC. According to
DOE target of Exascale computing, the top HPC system will be
comprise 100K or 1M nodes. And each node will interconnected
with 2TB/s or 250GB/s BW.

http://www.er.doe.gov/ascr/ascac/Meetings/Mar10/AWhite.pdf

I am not sure whether the system will choose regular direct
interconnection network such as 3-D torus, or irregular indirect
network. DCN/DCI requirements clearly meet the later system.
Even in case of direct interconnection, I believe some topology
finding mechanism will be strongly required for optimal
performance and for operation. 

----
Katsushi Kobayashi

---

From: Tony Li <[email-masked]>
Date: Thu, 12 May 2011 22:13:52 -0700

> performance and for operation. 

Interesting.  As you prepare your topic proposal, please highlight the IP routing and addressing aspects of the research here.

Thanks,
Tony

---

From: Patrick Frejborg <[email-masked]>
Date: Fri, 13 May 2011 09:00:24 +0300

Hi Xiaohu,

this is an interesting topic and there has been other research works
as well. I find it more appealing to use L3 in data centers and that
is doable if the identifier/locator split is applied. Instead of
finding a path from endpoint A to endpoint B the the path is
established from endpoint A to service instance B.
You might find these links interesting
http://sns.cs.princeton.edu/projects/scaffold/
http://netseminar.stanford.edu/past_seminars/seminars/freedman-scaffold.pdf

Patrick

---

From: Benno Overeinder <[email-masked]>
Date: Mon, 16 May 2011 12:18:40 +0200

> this probably during next week, is that ok?

We are running some simulation experiments to get insight in the
scalability (number of BGP update messages and maybe later the
convergence time) and path diversity/disjointness of different
multi-path routing proposals.  We are trying to get an answer what the
practical implications are of the deployment of multi-path routing on
current Internet AS-topology (and the past topologies from 2004 onwards).

If these are interesting questions to put in the draft, I am more than
happy to give more details, etc.

Cheers,

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
http://www.nlnetlabs.nl/

---

From: [email-masked]
Date: Thu, 19 May 2011 12:12:55 -0400

Proposals:

1) Discussion about alternate multicast instance identification:

Historically, a multicast instance is identified by some unique (?) multicast address. Meanwhile there is also ssm, where the multicast instance is identified by the sender's unicast address plus some multicast-address  from some ssm-specific range. 

Proposal: Use a new multicast-protocol type plus the sender's unicast address.

Con: Existing (deployed) multicast services have to be changed.
Pro: 1 billion IPv4-addresses would be freed for unicast which is quite a lot while facing the address depletion issue. 

The discussion should be led by ISP folks. I think, they would know best the costs as well as the benefits.

2) State-less multicast for about 99 % of the involved routers by means of cascade tree multicast
Example: By employing a cascade degree =10 about 90 % of the receivers wouldn't even become aware of being involved in some multicast activity.Assuming 20 hops in average between any two nodes of the cascade tree, only a half percent of the involved routers have be cascade tree multicast knowledgable.

Heiner

---

From: Loránd Jakab <[email-masked]>
Date: Thu, 19 May 2011 18:44:32 +0200

Hi Heiner,

On 05/19/11 18:12, [email-masked] wrote:
> Historically, a multicast instance is identified by some unique (?)
> multicast address. Meanwhile there is also ssm, where the multicast
> instance is identified by the sender's unicast address plus some
> multicast-address  from some ssm-specific range. 
>
> Pro: 1 billion IPv4-addresses would be freed for unicast which is
> quite a lot while facing the address depletion issue. 
>

This proposal came up a few times on the North American Network
Operators' Group (NANOG) mailing list, where the ISP folks hang out. I
think the main concern is that "Class D" (and E, the experimental block)
is hardcoded into most router's software, and forcing everyone to
upgrade is just not feasible. Granted, a lot of IPv4 addresses would be
freed this way, but migrating to IPv6 should be a better long term
strategy. The amount of time/energy needed to coordinate a change like
this would be better spent for IPv6 migration.

-Loránd Jakab

> Example: By employing a cascade degree =10 about 90 % of the receivers
> wouldn't even become aware of being involved in some multicast
> activity.Assuming 20 hops in average between any two nodes of the
> cascade tree, only a half percent of the involved routers have be
> cascade tree multicast knowledgable.
>
>
> Heiner
>
>
>
>
>

---

From: [email-masked]
Date: Thu, 19 May 2011 18:15:03 -0400

Hi Lorand,

Certainly, my proposal is to find out how urgent is the IPv4-address depletion issue. Maybe it is not urgent and NAT will do.
And looking at IPv6: IPv6 provides even more of these funny Multicast addresses :-( 
You may be fancy about IPv6, not me. (I don't know whether I should be happy or sad about the flow label's destiny so far.)

This is RRG, i.e. somehow "research for the better". IMHO there are different actions wrt p2p, p2mp, mp2p, mp2mp and anycast which should be expressed by different protocol types. Yes, some additional information is to be provided:
In case of multicast, the sender's IPv4-address, in case of anycast some ANYCAST-destination address (by using a separate protocol type  the anycast addres range could be 32 bits long - more than enough). Wrt  mp2p I only know MPLS applications - it does not exist in IP. mp2mp isn't reflected nowhere :-(

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Loránd Jakab <[email-masked]>
An: [email-masked]
Cc: [email-masked]
Verschickt: Do., 19. Mai. 2011, 18:44
Thema: Re: [rrg] Next topic?

Hi Heiner,

-Loránd Jakab

---

From: Tony Li <[email-masked]>
Date: Sat, 21 May 2011 09:26:53 +0200

Hi all,

It's now the 21st.  I'd like to call on folks who are seriously proposing topics to produce their statements.  So far, we have one.  

Something that is analogous to the current RRG charter would be most helpful.

As some topics do seem to be gaining traction, it would also be very helpful if each statement could include a list of researchers who would be participating, along with their research affiliations.

Thanks all,
Tony

---

From: Katsushi Kobayashi <[email-masked]>
Date: Mon, 23 May 2011 17:04:11 +0900

Hi,

Sorry for late response and not to fit an RRG charter.

I believe the host number scalability issue in HPC network
are not different from DCN/DCI.  HPC has a roadmap including
some the number of hosts to be connected, while the
requirements of future DCN/DCI is not clear.

If L2 can be resolve the issues alone, it is not an IETF/IRTF issue.
If we need some support for ARP/DHCP presented as SEATTLE,
EtherProxy, IRTF should do.

HPC network also shares with DCN/DCI in the routing on
large number switches. RBridge and other link-state based
L2 routing can help. However, HPC network topology should be
free from "backbone", since HPC network topology and traffic
have highly symmetrical.

I think many people agrees with the host number scalability issue,
since many research challenges are ongoing and industries may support it.
The later routing issue is only my own idea, and I cannot find any
research paper discussing it other than ATM PNNI. 
So, I don't insist that RRG should pick it.

----
Katsushi Kobayashi