On 2008-10-22 07:01, Scott Brim wrote:
> On 10/21/08 1:44 PM, Dino Farinacci allegedly wrote:
>>> Map-n-encap would upset Jon, as written GSE depends heavily on DNS, GSE
>>> conversion would take longer to solve routing scaling than we have time
>>> for, and nobody wants to make NAT the centerpiece of the new
>>> architecture.
>> Scott, do you think Jon would be upset with LISP, as the way it is
>> currently defined?
>>
>> Dino
>>
> 
> The question is really about mapping.  I wasn't in the room at that time
> (that I remember) but I think DNS was a lot more fragile than it is now,
> and more fragile than ALT.  Personally I think we're okay as long as we
> can deploy the robustness the system is designed for.  If Jon's problem
> was having IP forwarding depend on something fragile -- like
> the-then-DNS -- then I don't think there's a problem.  If he objected in
> principle to depending on anything other than hop-by-hop routing then I
> guess he would still have a problem ... but then again he never liked
> route filtering either.

There's no doubt Jon felt strongly about this. I'm not sure whether he
or Lixia was the originator of the following words in RFC 1958:

   3.11 Circular dependencies must be avoided.

      For example, routing must not depend on look-ups in the Domain
      Name System (DNS), since the updating of DNS servers depends on
      successful routing.

It might have been Lixia, because the point was explicit in her report
of the plenary discussion at IETF 33:

     "  In addition to the need
for autoconfiguration on tools at low levels, renumbering requires
changes to high-level protocols.  It also puts further reliance on the
DNS system to keep up-to-date address binding.  To avoid circular
dependency, DNS servers themselves will require special treatment,
such as provider-independent addresses, assured connectivity, issues
that are yet to be explored.  "

    Brian


_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg

Reply via email to