Adding in Carlos who holds the pen for us, Please see inline starting
with SH:
-----Original Message-----
From: Spencer Dawkins [mailto:spencer(_at_)wonderhamster(_dot_)org]
Sent: Friday, June 12, 2009 3:55 AM
To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson
Cc: ietf(_at_)ietf(_dot_)org; General Area Review Team; Ross Callon; Acee
Lindem;
Abhay Roy (akr)
Subject: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03
I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-ospf-dynamic-hostname-03
Reviewer: Spencer Dawkins
Review Date: 2009-06-11
IETF LC End Date: 2009-06-16
IESG Telechat date: (not known)
Summary: This document is almost ready for publication as a Proposed
Standard. I identified two minor issues listed below.
2. Possible solutions
Another approach is having a centralized location where the name-to-
Router ID mapping can be kept. DNS can be used for the same. A
disadvantage with this centralized solution is that its a single
Spencer (nit): s/its/it's/
point of failure; and although enhanced availability of the central
mapping service can be designed, it may not be able to resolve the
hostname in the event of reachability or network problems. Also, the
response time can be an issue with the centralized solution, which
can be particularly problematic in times of problem resolution. If
Spencer (minor): good point on response times, but I'd also think you'd
point out that looking up attributes on a centralized mapping table is
exactly the wrong thing to do when you're resolving problems with
routing - the centralized resource may not even be reachable.
SH: I think we already have it covered just above in the same paragraph.
(single point of failure)
<snip>
A disadvantage with this centralized solution is that its a
single
point of failure; and although enhanced availability of the central
mapping service can be designed, it may not be able to resolve the
hostname in the event of reachability or network problems.
</snip>
DNS is used as the centralized mapping table, a network operator may
desire a different name mapping than the existing in the DNS, or new
routers may not yet be in DNS.
3. Implementation
The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL. Upon receipt
of the TLV a router may decide to ignore this TLV, or to install the
symbolic name and Router ID in its hostname mapping table.
Spencer (minor): I'm suspecting that if this attribute becomes widely
deployed, network operators would train themselves to read the hostname
and pay very little attention to the numeric router ID, so I'm wondering
if it's worth saying anything (either here or in an Operations and
Management Considerations section <ducks> :-) about the possibility that
two different routers may both insist they are "routerXYZ".
That would be a misconfiguration, and the text as written allows the
router to ignore the second attempt to claim the name "routerXYZ", but
it would be irritating to troubleshoot a problem looking at logs that
conflate two disjoint "routerXYZ" routers. I'm not a router guy, so I
don't know what other responses might be appropriate - I don't think
you'd declare an error for a perfectly good next-hop who's confused
about its hostname, and I don't know if suggesting that this be SNMP
TRAPped would make sense - but you guys would be the right ones to
suggest an appropriate response.
SH: This is a mis-configuration issue. Network Administrators need to be
careful while configuring hostnames on the routers. I think we have text
around this in
<snip>
5. Security Considerations
Since the hostname-to-Router ID mapping relies on information
provided by the routers themselves, a misconfigured or compromised
router can inject false mapping information.
</snip>
However I am open to the idea of elaborating it somewhere else too if
every body else feels its needed.
Regards
Sanjay
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf