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
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
