Re: [rrg] Pumping IRON

[Wesley Eddy <[e-mail]>]

Templin, Fred L wrote:
> 
> As such, I am now initiating a two week open review period
> within the research group for technical and editorial review.
> I will also solicit comments from a selected set of expert
> reviewers to ensure a thorough review. The document version
> offered for review is here:
> 
> http://www.ietf.org/id/draft-templin-iron-05.txt
> 
> To the research group, please post comments to the list as
> replies to this subject thread by COB on Wednesday, June 23rd.
> 


Hi Fred, I've looked over the document (and associated ones including 
RANGER, RANGERS, VET, and SEAL); here are some comments I have.

Summary:

The document is generally well-written, and can be understood by someone 
within the context of the other referenced documents (though certainly 
not without them).

The technical description is basically an overview of the concept and
how it could function, rather than a prescriptive protocol spec.  I
think as such it's definitely appropriate to publish through the RG as
Informational, though I'd suggest that it have a more clear listing of
some of the open research issues that exist which would be explored in
taking the concept into a large-scale deployed state.  It would be nice
to see a bulleted list of such things near the end of the document.

The only technical thing I might have an issue with is the reliance on 
the MVP, and the need to come up with hard numbers to show that this is 
a feasible architectural assumption to work at Internet scale without 
operational issues.  I think those studies would be fine as follow-on 
work and the absence of such should not block publication as an RFC from 
the RG.

I'm also a little skeptical of the applicability to mobile networks, but 
the claims made here are definitely no more specious than in other 
proposals, so I'm not overly concerned by them ;).

I would be interested in talking about how IRON compares to an 
architecture where instead of IR(VP)s you have NEMO Home Agents and
instead of IR(EP)s you have NEMO Mobile Routers (which don't necessarily
have to be mobile, just speak the protocol).  Assuming you port in the
use of SEAL for tunnels, there might be a lot of equivalence.  Since the
EPs and VPs would be routable prefixes in this case, I don't think there
would be a need for the MVP either, which seems highly desirable to 
dispose of.

Some comments on particular sections are:

(1) page 5 - in definitions of different types of IRON routers, the term
"VP company" is used several times.

(2) page 5 - in defining different types of IRs, some example diagrams 
might really help.  It's a royal pain to incorporate, so I think this is 
at the authors' discretion, but a couple simple pictures would add a lot 
here, I think.  The scenario in section 6.4 is fantastic for 
illustrating things, but comes too late in the document for readers that 
might get lost up front.


(3) page 6 says:
"""
    The IRON additionally requires a global mapping database to allow IRs
    to map EPs/VPs to RLOCs assigned to the interfaces of other IRs.
"""
This part looks scary at first, and gets a little scarier even when it's
compared to the way that IANA maintains the list of IPv4 and IPv6
delegations, and replication across multiple servers is discussed.  I 
think it's probably not as bad of an idea as it seems like at first, but 
I'm really not sure yet.

(4) In section 6.1, and the discussion of beaconing between IR(EP) and 
the IR(VP)s, I wondered how many IR(VP)s we would expect to see in 
operations, where the heuristic of "at least 2-4" was derived from, and 
how frequently it would be advisable to send the beacons at?  Those seem 
like useful details to be understood, though maybe they would be flushed 
out in later studies and through experience to some extent.

(5) The discussion of mobility management in 6.5.1 may be a bit 
premature. Whether this is usable or not for mobile systems will depend 
on other aspects of performance like how long the registration of the 
new maping from the EP to RLOC takes with the VP company.  All we have 
to analyze this is that the registration uses "an authenticated short 
transaction protocol", but that might involve handshakes with several 
numbers of steps, and the messages in some steps may be relatively 
large.  The specifics here will matter a lot as to whether IRON is 
viable for mobile networks.

(6) The security considerations are a handwave toward RANGER.  I think
this is not the whole story.  For instance, there are security 
considerations on the means used for customers to update (and establish) 
bindings with their VP companies.  I think the draft implies that the 
exact means could vary depending on the VP company, which is fine, but 
there should be some guidelines or analysis of what kind of bad things 
could happen, and how they might be mitigated or dealt with operationally.


--
Wes Eddy
MTI Systems