Gen-ART review of draft-ietf-ospf-dynamic-hostname-03

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

  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.

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]