Subject: Re: [rrg] Rebooting the RRG

From: Wassim Haddad <[email-masked]>
Date: Mon, 2 Dec 2013 10:09:53 -0800

Hi,

I am interested in many topics in the list below and would like to contribute

Regards,

Wassim H.

On Nov 27, 2013, at 12:59 AM, Tony Li <[email-masked]> wrote:

> 
> 
> Dear volunteers,
> 
> Thanks for offering to help out and contribute to the workshop program. 
> 
> I'm very pleased to report that Dmitri Krioukov has tentatively agreed to present.
> 
> Let's keep adding to the list.
> 
> So far, the topics that folks have mentioned look like:
> 
> 	- The intersection of naming and routing
> 	- Problems with centralizing control planes
> 	- Network programmability
> 	- Routing in ICN (information-centric networking)
> 	- Multi-layer routing
> 	- SDN routing, including multi-domain SDN
> 	- (Ab)use of BGP
> 	- Mesh routing
> 	- DTN routing
> 	- Privacy
> 	- Compact routing
> 	- Routing for more generalized addressing
> 	- Software defined Internet exchange
> 
> And some obvious sources of papers to pursue:
> 	- ANRP
> 	- Routing from SIGCOMM
> 
> For those of you have volunteered to help out, could you please:
> 
> 	- Add other topics to the lists above
> 	- Add other specific authors that we should invite
> 	- Reach out and invite speakers
> 
> We rely on your help to make this into a successful workshop.
> 
> Thanks,
> Tony
> 
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

---

From: Tony Li <[email-masked]>
Date: Mon, 2 Dec 2013 10:17:08 -0800

> I am interested in many topics in the list below and would like to contribute

Again, we are looking for folks to suggest papers that are relevant to these topics, propose speakers who could be contacted and then for folks to actually reach out and contact speakers.

This is an open program committee.  It's up to us to make this successful.

Tony

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 3 Dec 2013 20:27:38 +0200

Scott,

we are going to have an increased amount of dual stack endpoints in
the future, right? Thus more and more endpoints will need to deal with
both protocols. What if we could use both namespaces concurrently by
tweaking them slightly? In your local network you could use either
IPv4 or ULA IPv6, what ever you prefer - it is your business and your
budget.  But once you traverse the DFZ you would need to have a global
IPv6 as your primary forwarding namespace. Once the packet hits the
remote network you change the forwarding namespace to IPv4 - because
the endpoints that are exposed to the Internet will be dual stacked
anyway for a very long time.

Outcome is that the DFZ would be IPv6 based only (the RIB a lot more
smaller), in the long term, and the organizations attached to the
Internet can use IPv4/ULA IPv6 for their internal traffic. Everyone
should be happy, right?

Sorry for revisiting our previous work and going for solutions, but I
had to get this of my chest. Replace the ALOC namespace in RFC6306
with an IPv6 namespace, and take the ILNP identifier part into that
namespace for host and service identifiers - a multipath transport
protocol will provide the session identifiers. Where could that go - I
don't know, it is a foggy picture at the moment and I'm on my learning
curve with IPv6. Any interest in such a topic?

Patrick

On Tue, Nov 19, 2013 at 3:47 PM, Scott Brim <[email-masked]> wrote:
> Heiner, the IETF has said it doesn't want to come up with any more clever
> ways to help organizations continue to squeeze more life out of IPv4
> addresses. It will help with transition away from IPv4. Thus IPv4 address
> depletion isn't a favored topic, and neither is making significant changes
> to Internet routing and/or addressing architecture in response. I suspect
> that ideas for routing multiple namespaces efficiently could be worth
> considering, but I would generalize it beyond just IPv4 and IPv6.  What else
> could you route?
>
> Scott
>
> On Nov 18, 2013 4:54 PM, <[email-masked]> wrote:
>>
>> Certainly - though the times are gone when routing and addressing where
>> identical, i.e. when my means of the next dialled digit the next-hop trunk
>> was selected electro-mechanically.
>> Just compare TARA-now (
>> http://www.igi-global.com/chapter/topology-aggregating-routing-architecture-tara/77501
>> ) and the long expired draft-hummel-tara-00:
>> I once had the same idea like Fuller  to  disseminate a prefix of length
>> zero, so that a TARA-router closest to the ingress could attract traffic,
>> then prepend a TARA-header as to do TARA-forwarding to some TARA-ETR. But it
>> was necessary to sacrifice this nice idea. Instead it is more important to
>> involve the user side and
>> have  FQDN mapped to {IPv4; TARA-locator} by one single action. The gain:
>> tons and tons of available IPv4-addresses.
>>
>> All has to be taken into consideration. Whereas the LISP-supporters say
>> "hey, addressing is not our problem; we just deal with the scalability
>> issue".
>> Well, if you want to help IPv4, both issues must be of concern, and the
>> address depletion is even the more serious issue, isn't it?
>>
>> Heiner
>>
>>
>>
>> -----Ursprüngliche Mitteilung-----
>> Von: Tony Li <[email-masked]>
>> An: heinerhummel <[email-masked]>
>> Cc: lars <[email-masked]>; rrg <[email-masked]>
>> Verschickt: So, 17 Nov 2013 7:12 pm
>> Betreff: Re: [rrg] Rebooting the RRG
>>
>>
>> On Nov 17, 2013, at 8:35 AM, [email-masked] wrote:
>>
>> > When RRG was launched the driving force was the so-called scalability
>> > problem.
>> > Currently the biggest issue is the expiration of available IPv4
>> > addresses.
>> > That however would be a non-issue if the FQDN were mapped to {IPv4 addr
>> > of
>> destination user; locator of ETR} in a single strike based on DNS while
>> taking
>> care that IPv4 addresses of the same locator were mutually unique.
>> > LISP-DDT neither does so now, nor would be able to do so ever. Hence
>> > IPv4's
>> lifetime is up to NAT as long as solutions like LISPv2.0 or my TARA are
>> discarded/ignored. There are much more knowledgable folks around who know
>> the
>> disadvantages of the NAT sinfall better than myself. I can only add one
>> disadvantage: With a network layer based on TCP (NAT) you can never enable
>> Multicast with a roaming sender.
>> >
>> > I think this IPv4-depletion issue is the most urgent problem at all.
>>
>>
>> Is that a routing problem?
>>
>> Tony
>>
>>

---

From: "Stephen D. Strowes" <[email-masked]>
Date: Thu, 05 Dec 2013 15:14:14 -0800

On 29/11/2013 00:16, Tony Li wrote:
> Dimitri Papadimitriou has volunteered to present research on  i) two variants of geometric routing (geodesic path routing and greedy embedding) ii) distributed name-independent compact routing and iii) dynamic compact multicast routing from the work that has been done on the EULER project (https://www-sop.inria.fr/mascotte/EULER/wiki/pmwiki.php/Main/Publications).
>
> Is this of interest to folks?
*raises hand*

S.

---

From: Tony Li <[email-masked]>
Date: Fri, 13 Dec 2013 09:09:20 -0800

Since this is already being discussed in IDR, I would think that is sufficient.

Tony

On Dec 13, 2013, at 1:13 AM, Xuxiaohu <[email-masked]> wrote:

> Hi, 
> 
> Is the performance-based routing an interesting topic? The following draft (http://tools.ietf.org/html/draft-xu-idr-performce-routing-00) describes an performance-based BGP routing paradigm. Somebody may look it as an abuse of BGP:) 
> 
> By the way, the following blog and the linked webinar might be helpful to understand the motivation for performance-based routing mechanism:
> http://blog.level3.com/level-3-network/network-performance-app-performance/
> 
> Best regards,
> Xiaohu
> 
>> -----邮件原件-----
>> 发件人: rrg [mailto:[email-masked]] 代表 Tony Li
>> 发送时间: 2013年11月27日 16:59
>> 收件人: [email-masked]
>> 主题: Re: [rrg] Rebooting the RRG
>> 
>> 
>> 
>> Dear volunteers,
>>