Subject: [rrg] London

From: Tony Li <[email-masked]>
Date: Thu, 9 Jan 2014 01:12:11 -0800

Hi all,

We are still looking for excellent papers for our workshop in London.  We really need your help in collecting these.  If you know of interesting research, could you please contact the authors and ask if they would be willing to present in London?  It's coming very soon…

Thanks,
Tony

---

From: Heiner Hummel <[email-masked]>
Date: Sat, 11 Jan 2014 21:24:38 +0100

Tony,
Given that the IESG doesn't care about IPv4 anymore, what kind of papers are you looking for? IPv6 papers ? IPv7 papers, based on WHAT ?

For anyone it would be easier to outline a routing architecture while 16 octets are available instead of 4. But IPv6 is grounded from the start. Not even the fact that  IPv4 runs out of addresses will help to unleash IPv6.
Combined with NAT,  IPv4 won't effectively have a deletion problem. Not for the next thousand years.
Technologically NAT is a sin  fall, it hampers internet services  enormously. But this is true with IPv6 as well. So what!

Backward compatibility and incremental deployability should be the two MUSTs for any architecture, no matter who proposes it. IPv6 isn't backward compatible due to the dual stack issue - right? or is there any way around?
What is expected from any new architecture? To be backward compatible with IPv4 ( I would think so), to be backward compatible with IPv6 (I wouldn't think so)? So what is expected?

And of course what do you expect to be solved, respectively to be enabled at least ?
----
Another Proposal:  This group should come up with ideas about what a networking layer should do/support/enable WITHOUT being restricted by any existing technical solution.
Two examples: 1): Prefix building per se is not a service. It is only a subdue instrument to cope with problems of a minor design.
2): State-less multicast would enable an enormous progress ( Imagine TV-broadcast to billions of spectators). But this is disabled due to the crazy belief that there is only one way  a FIB can be designed (namely as the existing FIB looks like)
and because a Multicast-FIB cannot reasonable be cast like the existing Unicast-FIB there cannot/must not be state-less multicast. Period.

Heiner

Am 09.01.2014 um 10:12 schrieb Tony Li <[email-masked]>:

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

---

From: "Eggert, Lars" <[email-masked]>
Date: Sun, 12 Jan 2014 07:39:45 +0000

Hi,

On 2014-1-11, at 21:24, Heiner Hummel <[email-masked]> wrote:
> Given that the IESG doesn't care about IPv4 anymore

so even if that were true, what the IESG cares for should have little impact on what an IRTF research group is looking into.

I thought Tony's email was spot-on. If the RRG wants to remain chartered, it needs to become active again and identify some topics that it wants to investigate. Looking at what's been published by academics in the recent past seems a useful exercise in order to find some of those topics.

And the group needs a core set of participants that are willing to put in the energy to make some successful meetings happen, by re-energizing the broader routing community and by inviting folks that have interesting things to present to show up to do so.

Lars

---

From: Lixia Zhang <[email-masked]>
Date: Sun, 12 Jan 2014 10:12:38 -0800

I may not necessarily agree with the technical specifics of Heiner's msg, but I do think the msg made a good point: to provide useful input into RRG London agenda, we need to first have a clear goal(s) for that meeting.
Just volunteering a talk for whatever latest results multiple individuals have achieved may or may not help RRG to move forward.

So what do we as a group want to achieve?
Reactivating RRG would be the results of identifying that goal (the group would march towards that clearly articulated goal).

Or maybe the goal of London meeting could be to identify/clarify the goal?

(in that case, Heiner's msg did make one position statement as an input, for the group to consider)

Lixia
PS: I must admit that I have NOT had time to go thru the 40 or so RRG msgs since Vancouver IETF, ignore my comments if the goal had been clarified earlier (other than "reactivating RRG").

---

From: Tony Li <[email-masked]>
Date: Sun, 12 Jan 2014 21:01:36 -0800

Lixia,

The whole point of London is a broad survey of routing topics with exactly the goal of trying to clarify the topic(s) that the RRG is interested in.

In some circles, this is known as the 'shotgun approach'.  ;-)

Tony

---

From: Patrick Frejborg <[email-masked]>
Date: Mon, 13 Jan 2014 21:13:00 +0200

Tony,

here is a shotshell for your shotgun to consider, and also for the
group to consider as a research topic.

Currently there is no papers or presentations available, it is an
early idea based on a combination of several research works - if it is
doable it could produce some new research papers from this group.

The basic idea is:

1) Take ILNPv6 as a baseline.

2) Add a new routing header extension to ILNPv6, it will contain some
locator fields. It must be compatible with RFC2460, some tweaks are
needed but it has to obey the spirit and format of RFC2460.

3) From RFC6306, take the concept of realms and for the "segments
left" field in the new routing header field, take the conpets of exit
routing, DFZ routing and approach routing - apply those on ILNPv6 with
the new routing header extension. However, "segments left" field has
to be applied in such way that it do obey RFC5095 in DFZ routing path
of a packet's journey (this is the tweak).

4) The DFZ must remain backwards compatible.

5) With steps 1-3 in place we can introduce a new type of identifier,
a service identifier with a "late binding", see
http://www.cs.princeton.edu/research/techreps/TR-885-10

6) Multipath transport protocols, such as MPTCP and SCTP will add a
new option of multi-homing and mobility to ILNPv6 ("new option" is the
wrong semantics here, but anyway) - ILNPv6 with the host identifier is
great for business-to-business sessions (e.g. LAN-to-LAN VPN tunnels)
but I think that a multipath transport protocol with a service
identifier solution is better suited for the cloud and mobility era of
the Internet.

So here is the shotshell in a nutshell ;-)
It is up to the group if we can think this might be doable and willing
to spend some time researching on this specific topic.

Patrick

---

From: [email-masked]
Date: Fri, 17 Jan 2014 03:05:53 -0500 (EST)

Lixia,

It was at the London 2002 IETF meeting when the request was raised to develop a new routing architecture. Concurrently it was added " there is no reason to rush, we will have a 10 years time frame for doing it". Well, meanwhile 12 years have passed and all we 've got is LISP which boast to enable 52x10^27 EIDs per person but doesn't enhance the IPv4 address space not by one single address. A concept which  employs (bottle neck) servers which are vulnerable wrt. DoSA and perhaps even due to normal overload of queries and which impose a threat to their not-owning clients which dependent on them.  

IPv6 was certainly not meant by that request in London because it existed already at that time. And RFC 4984 §3 even warns that it would multifold the number of prefixes. And integrating AS-numbers seems not good wrt prefix building either. Also: 16 octets are provided and yet a E164 mobile user phone number is still needed outside of these 16 octets:-(.

In the past I have  asked many times to discuss the existing paradigms, and to question them ! Research is questioning the obvious! The too obvious! Like: Why are there two different routing concepts wrt intra versus inter-domain routing? I really would like to know why is Dijkstra bad for inter-domain ? Why isn't Distance Vector used in intra-domain routing?
Why is there no Multicast-FIB ? Is it because it can't hardly be like the existing Unicast-FIB on the one hand side while on the other side a FIB must not be any different than the existing one?
Lixia, why would you not necessarily agree with my technical specific of having a Multicast-FIB ?
And also: What is the value of depending on prefix building in unicast forwarding? After all, it doesn't work wrt Multicast nor to Anycast (nor see above with AS#s)

Another very fundamental point is what we expect a network layer to be/to look like/to handle/ to solve:

It is not only me, it is the entire ITU-T which thinks that the network layer deals with the WHERE. With E164 routing and addressing are or at least have been identical: the next-hop trunk was selected electro-mechanically due to the next dialed digit. A routing protocol wasn't even needed. 

It is worth to have a look to the past. I am convinced, If there were not MPOA (but Cisco's Peer model instead) MPLS wouldn't have been developed. Without MPLS, being a strong push of IntServ, there wouldn't have been the counter movement DiffServ whose mantra is "do what Traffic Engineering wanted to contribute to SVCs/LSPs without knowing the network nor its current traffic load external to the waiting queue of incoming packets at any router And - imho - this mantra prevents any reasonable handling of genuine network layer objectives: like handling traffic congestions (avoiding them if possible in the first place dissolving them where needed). A network layer technology which has no idea, how to direct flows such that some would bypass the congested area to the left while some others to the right is not future prone. It is stupid and unknowledgeable!!!

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Lixia Zhang <[email-masked]>
An: Heiner Hummel <[email-masked]>
Cc: Tony Li <[email-masked]>; rrg <[email-masked]>
Verschickt: So, 12 Jan 2014 7:12 pm
Betreff: Re: [rrg] London

I may not necessarily agree with the technical specifics of Heiner's msg, but I 
do think the msg made a good point: to provide useful input into RRG London 
agenda, we need to first have a clear goal(s) for that meeting.
Just volunteering a talk for whatever latest results multiple individuals have 
achieved may or may not help RRG to move forward.

So what do we as a group want to achieve?
Reactivating RRG would be the results of identifying that goal (the group would 
march towards that clearly articulated goal).

(in that case, Heiner's msg did make one position statement as an input, for the 
group to consider)

Lixia
PS: I must admit that I have NOT had time to go thru the 40 or so RRG msgs since 
Vancouver IETF, ignore my comments if the goal had been clarified earlier (other 
than "reactivating RRG").

On Jan 11, 2014, at 12:24 PM, Heiner Hummel <[email-masked]> wrote:

> Tony,
> Given that the IESG doesn't care about IPv4 anymore, what kind of papers are 
you looking for? IPv6 papers ? IPv7 papers, based on WHAT ?
> 
> For anyone it would be easier to outline a routing architecture while 16 
octets are available instead of 4. But IPv6 is grounded from the start. Not even 
the fact that  IPv4 runs out of addresses will help to unleash IPv6.
> Technologically NAT is a sin  fall, it hampers internet services  enormously. 
But this is true with IPv6 as well. So what!
> 
> Backward compatibility and incremental deployability should be the two MUSTs 
for any architecture, no matter who proposes it. IPv6 isn't backward compatible 
due to the dual stack issue - right? or is there any way around?
> What is expected from any new architecture? To be backward compatible with 
IPv4 ( I would think so), to be backward compatible with IPv6 (I wouldn't think 
so)? So what is expected?
> Another Proposal:  This group should come up with ideas about what a 
networking layer should do/support/enable WITHOUT being restricted by any 
existing technical solution.
> Two examples: 1): Prefix building per se is not a service. It is only a subdue 
instrument to cope with problems of a minor design.
> 2): State-less multicast would enable an enormous progress ( Imagine 
TV-broadcast to billions of spectators). But this is disabled due to the crazy 
belief that there is only one way  a FIB can be designed (namely as the existing 
FIB looks like)
> and because a Multicast-FIB cannot reasonable be cast like the existing 
Unicast-FIB there cannot/must not be state-less multicast. Period.
>> We are still looking for excellent papers for our workshop in London.  We 
really need your help in collecting these.  If you know of interesting research, 
could you please contact the authors and ask if they would be willing to present 
in London?  It's coming very soon…

---

From: Lixia Zhang <[email-masked]>
Date: Fri, 17 Jan 2014 22:04:02 -0800

> It is worth to have a look to the past. I am convinced, If there were not MPOA (but Cisco's Peer model instead) MPLS wouldn't have been developed. Without MPLS, being a strong push of IntServ, ther…

Hi Heiner,

although your msg seems addressed to me, I believe you meant to bring up the questions to the RRG, right?  

Lixia