Subject: [netlmm] Review of LMA Discovery document

From: Christian Vogt <[email-masked]>
Date: Thu, 29 Apr 2010 14:53:40 -0700

Folks,

Jouni asked me to review the LMA Discovery document.  I did this, and
found that the document is mature and well written, and should be
progressed further as soon as possible.  I have just one comment on
section 4:

Section 4 gives two classes of reasons not to use the DNS for LMA
discovery.  The first class is related to update propagation latencies
caused by caching.  The second class is related to update latencies
caused by primary-to-secondary server synchronization.  My comment
relates to the first class of reasons:

Can't the issues described be well avoided?  In deployments where the
DNS is to be used for LMA discovery, make sure you have DNS
implementations that accept low TTLs, and set your TTLs low -- that
seems to be it.  I agree that the issues you are describing do need to
be considered, and hence it is very important to document them.  But I
personally don't see them as show-stoppers.

This said, your second class of reasons may be more intractable.

Hope this helps.  Best regards,

- Christian

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 30 Apr 2010 12:37:03 -0700 (PDT)

Hi Christian,

  The way DNS is used in the draft is how an ordinary host makes a DNS query.

  This is no DNS based LMA discovery. I think you (and Julien) had already indicated this in your mails to the list earlier. RFC 5026-like DNS discovery has been described in our draft as we had indicated many times in the list.  In fact DNS based LMA discovery in PMIPv6 is much more secure and efficient that MIPv6 DNS discovery of HAs.

My suggestion is to drop totally Section 4 as this section is artificial without a real DNS discovery solution and instead merge draft-sarikaya-netlmm-lma-dnsdiscovery-01

with this draft.

Regards,

Behcet
----- Original Message ----
> From: Christian Vogt <[email-masked]>
> To: NETLMM Mailing List <[email-masked]>
> Cc: jouni korhonen <[email-masked]>
> Sent: Thu, April 29, 2010 4:53:40 PM
> Subject: [netlmm] Review of LMA Discovery document
> 
> Folks,

Jouni asked me to review the LMA Discovery document.  I did 
> this, and
found that the document is mature and well written, and should 
> be
progressed further as soon as possible.  I have just one comment 
> on
section 4:

Section 4 gives two classes of reasons not to use the 
> DNS for LMA
discovery.  The first class is related to update propagation 
> latencies
caused by caching.  The second class is related to update 
> latencies
caused by primary-to-secondary server synchronization.  My 
> comment

Can't the issues 
> described be well avoided?  In deployments where the
DNS is to be used 
> for LMA discovery, make sure you have DNS
implementations that accept low 
> TTLs, and set your TTLs low -- that
seems to be it.  I agree that the 
> issues you are describing do need to
be considered, and hence it is very 
> important to document them.  But I
personally don't see them as 
> show-stoppers.

This said, your second class of reasons may be more 
> intractable.

- 
> Christian

_______________________________________________
netlmm 
> mailing list
> href="mailto:[email-masked]">[email-masked]
> href="https://www.ietf.org/mailman/listinfo/netlmm" target=_blank 
> >https://www.ietf.org/mailman/listinfo/netlmm

---

From: jouni korhonen <[email-masked]>
Date: Sat, 1 May 2010 02:17:04 +0300

Hi Christian,

Thank you for the review.

> personally don't see them as show-stoppers.

Agree that they are not show-stoppers. Maybe the document could emphasize more clearly that the DNS administrator just has to know what he's doing. Enhancing the first paragraph slightly.

   A number of LMA discovery solutions described in Section 2 and
   Section 3 eventually depend on the DNS.  This section discusses
   impacts of the DNS response caching and issues related to the Dynamic
   DNS [RFC2136] updates. The impacts and related issues can mostly be
   avoided by a proper DNS administration that takes PMIPv6 domain
   deployment aspects into consideration.

> Hope this helps.  Best regards,

- JOuni

> netlmm mailing list
> [email-masked]