Hello,

I'd like to announce that an update to the IRON architecture
draft is now available, along with updates to the functional
specifications for its constituent mechanisms VET and SEAL:

http://tools.ietf.org/html/draft-templin-iron-02
http://tools.ietf.org/html/draft-templin-intarea-vet
http://tools.ietf.org/html/draft-templin-intarea-seal

IRON now has what I believe to be a compelling new solution
that supports:

- portable PI
- mobility
- multihoming
- route optimization
- traffic engineering
- multi-protocol operation
- tunnel MTU determination
- other neat stuff

IRON now suggests that a new business model supporting PI
addressing will emerge. In the new model, companies that
hold highly-aggregated Virtual Prefixes (VPs) will lease
portions of their VPs to End User Networks (EUNs) which
can then use them as ISP-independent PI prefixes.

Each EUN registers a PI-prefix-to-ISP mapping with its
parent VP company's network. The VP company's network
then serves as a virtual "home network", and the EUN
appears as a mobile network that is always away from
home. The EUN can change its mapping to use a different
ISP at any time such that mobility and multihoming are
naturally supported.

This new approach specifically focuses on small EUNs that
are either mobile or connect through multiple ISPs (this
is the same class of EUNs that have led to the routing
scaling concerns that brought on the RRG interest in the
first place.) Larger and more fixed networks (e.g., large
enterprise networks, service provider networks, etc.) will
instead announce their prefixes into the IPv4 and/or IPv6
DFZs the same as they have always done.

Please take a moment to take a look at the materials and
post any comments or questions. I would also like to
request that the chairs now consider IRON as a candidate
for publication as an IRTF-stream RFC.

Thanks - Fred
[email protected]
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg

Reply via email to