The Interior Routing Overlay Network (IRON)
draft-templin-ironbis-16

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'The Intradomain Routing Overlay Network (IRON)' to Informational RFC (draft-templin-ironbis-12.txt)

The IESG has approved the following document:
- 'The Intradomain Routing Overlay Network (IRON)'
  (draft-templin-ironbis-12.txt) as Informational RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Ralph Droms.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-templin-ironbis/

Ballot Text

Technical Summary

   Since large-scale Internetworks such as the public Internet must
   continue to support escalating growth due to increasing demand, it
   is clear that Autonomous Systems (ASes) must avoid injecting
   excessive de-aggregated prefixes into the interdomain routing
   system and instead mitigate de-aggregation internally.  This
   document proposes an Intradomain Routing Overlay Network (IRON)
   architecture that supports sustainable growth within interior
   routing domains while requiring no changes to end systems and no
   changes to the exterior routing system.  In addition to routing
   scaling, IRON further addresses other important issues including
   mobility management, mobile networks, multihoming, traffic
   engineering, NAT traversal and security.  While business
   considerations are an important determining factor for widespread
   adoption, they are out of scope for this document.


Working Group Summary

   This revises RFC 6179 which was published on the IRTF stream by the
   RRG.  Since then, IRON (which it describes) has also been discussed
   somewhat in the DMM/MEXT WG and I believe in the INTAREA.  It
   differs in architecture and underlying technology too much from
   Mobile IP in order to gain any traction with the DMM/MEXT
   participants, as that WG's charter has always been Mobile IP
   centric.  It is similar in some goals to work also being done in
   the LISP WG, however it also differs substantially from the LISP
   technology.  Since LISP is being done as Experimental, and it's
   well recognized that there are alternative approaches like ILNP
   (and IRON), this does not seem to pose a problem.  I do not believe
   there have every been very specific critical points raised against
   IRON.


Document Quality

   As this is an Informational document, and not a protocol spec, it
   isn't something that will be directly implemented.  Some parts of
   the IRON architecture, at least, have been implemented (e.g. SEAL
   in Linux), though I'm not aware that the full IRON architectural
   concepts have been deployed and operated with for any amount of
   time.


Personnel

Wesley Eddy is the document shepherd and Ralph Droms is the
responsible area director.


RFC Editor Note

  (Insert RFC Editor Note here or remove section)

IRTF Note

  (Insert IRTF Note here or remove section)

IESG Note

  (Insert IESG Note here or remove section)

IANA Note

  (Insert IANA Note here or remove section)

RFC Editor Note