Subject: [v6ops] FW: Submitted for your approval: IRON

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 17 Dec 2010 15:36:13 -0800

Fwd'd here from the intarea list. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Tuesday, December 14, 2010 10:39 AM
To: [email-masked]
Subject: [Int-area] Submitted for your approval: IRON

Submitted for your approval, the Internet Routing Overlay
Network (IRON) is a comprehensive new routing and addressing
system for the Internet. The IRON architecture builds on the
mechanisms of VET and SEAL, and expands upon the architectural
principles established in RANGER. Relevant documents include:

http://tools.ietf.org/html/draft-templin-iron
http://tools.ietf.org/html/draft-templin-intarea-seal
http://tools.ietf.org/html/draft-templin-intarea-vet
http://www.rfc-editor.org/rfc/rfc5720.txt

The IRON system uniquely combines a hybrid routing/mapping system
that benefits from the both the shortest-path routing afforded by
pure dynamic routing systems and the routing scaling suppression
afforded by pure mapping systems. IRON therefore targets the elusive
"sweet spot" that pure routing and pure mapping systems alone cannot
satisfy.

The IRON system requires a deployment of new routers/servers
throughout the Internet and/or provider networks to maintain
well-balanced virtual overlay networks. These routers/servers can
be deployed incrementally without disruption to existing Internet
infrastructure and appropriately managed to provide acceptable
service levels to customers.

End-to-end traffic that traverses an IRON virtual overlay network
may experience delay variance between the initial packets and
subsequent packets of a flow. This is due to the IRON system
allowing longer path stretch for initial packets followed by timely
route optimizations to utilize better next hop routers/servers for
subsequent packets. Such delay variance is no different than for
routing fluctuations that can occur within ordinary Internet routing.

IRON virtual overlay networks also interact favorably with existing
and emerging services within the native Internet. In particular,
customers serviced by IRON virtual overlay networks will receive
the same service enjoyed by customers serviced by non-IRON service
providers. Internet services already deployed within the native
Internet also need not make any changes to accommodate IRON virtual
overlay network customers.

The IRON system operates between routers within provider networks
and end user networks. Within these networks, the underlying paths
traversed by the virtual overlay networks may comprise links that
accommodate varying MTUs. While the IRON system imposes an additional
per-packet overhead that may cause the size of packets to become
slightly larger than the underlying path can accommodate, IRON routers
have a method for naturally detecting and tuning out all instances of
path MTU underruns. In some cases, these MTU underruns may need to be
reported back to the original hosts; however, the system will also
allow for MTUs much larger than those typically available in current
Internet paths to be discovered and utilized as more links with larger
MTUs are deployed.

Finally, and perhaps most importantly, the IRON system provides an
in-built mobility management and multihoming capability that allows
end user devices and networks to move about freely while both
imparting minimal oscillations in the routing system and maintaining
generally shortest-path routes. This mobility management is afforded
through the very nature of the IRON customer/provider relationship,
and therefore requires no adjunct mechanisms. The mobility management
and multihoming capabilities are further supported by forward-path
reachability detection that provides "hints of forward progress" in
the same spirit as for IPv6 ND.

What does all of this mean to the intarea? It means that there is
now a unified solution proposal at hand that naturally accomodates
the growth profiles and mobility/multihoming challenges that the
Internet now faces. Moreover, it provides a comprehensive transition
to IPv6 with full incremental deployment capability and with little
or no disruption to the existing Internet. And finally, IRON is a
complete solution rather than a piecemeal combination of adjunct
mechanisms.

IRON is therefore hereby submitted for your approval.

Fred Templin
[email-masked]
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Fred Baker <[email-masked]>
Date: Sat, 18 Dec 2010 23:33:56 -0800

On Dec 17, 2010, at 3:36 PM, Templin, Fred L wrote:

> Submitted for your approval

I think the IRTF Routing Research Group is looking at this, right? I think that's a very appropriate forum.

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 19 Dec 2010 08:46:43 -0800

> I think the IRTF Routing Research Group is looking at this, right? I think that's a very appropriate forum.

OPS produces problems that lead to proposals like this, it's beyond our
remit to solve them.
 _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>