Re: [netlmm] Review of LMA Discovery document

Christian Vogt <christian.vogt@ericsson.com> Mon, 03 May 2010 13:49 UTC

Return-Path: <christian.vogt@ericsson.com>
X-Original-To: netlmm@core3.amsl.com
Delivered-To: netlmm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5C428C1AD for <netlmm@core3.amsl.com>; Mon, 3 May 2010 06:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.296
X-Spam-Level:
X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[AWL=-2.180, BAYES_40=-0.185, DATE_IN_PAST_06_12=1.069]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCTsTrEyeN98 for <netlmm@core3.amsl.com>; Mon, 3 May 2010 06:49:56 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 29F5328C1BC for <netlmm@ietf.org>; Mon, 3 May 2010 06:49:53 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o43DnaiK029743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 May 2010 08:49:36 -0500
Received: from dhcp-147-214-19-108.ki.sw.ericsson.se (147.117.20.212) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.1.375.2; Mon, 3 May 2010 09:49:35 -0400
MIME-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: Christian Vogt <christian.vogt@ericsson.com>
In-Reply-To: <551716.75965.qm@web111402.mail.gq1.yahoo.com>
Date: Mon, 03 May 2010 07:31:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-ID: <18633E40-F539-4E68-BA72-1780A1B63250@ericsson.com>
References: <457704EB-5997-4BD9-A455-0E4912ADBFFC@ericsson.com> <551716.75965.qm@web111402.mail.gq1.yahoo.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
X-Mailer: Apple Mail (2.1078)
Cc: NETLMM Mailing List <netlmm@ietf.org>, jouni korhonen <jounikor@gmail.com>
Subject: Re: [netlmm] Review of LMA Discovery document
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 May 2010 13:49:56 -0000

Behcet:

Right, this document does not describe a DNS-based LMA discovery method.  But it analyzes some potential issues with such a method, and my comments relate to this analysis.  I felt that it be noteworthy that some of the potential issues can be avoided by proper implementation and administration.

Does this make sense?

- Christian



On Apr 30, 2010, at 21:37, Behcet Sarikaya wrote:

> 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 <christian.vogt@ericsson.com>
>> To: NETLMM Mailing List <netlmm@ietf.org>
>> Cc: jouni korhonen <jounikor@gmail.com>
>> 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
> 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
> 
> _______________________________________________
> netlmm 
>> mailing list
>> href="mailto:netlmm@ietf.org">netlmm@ietf.org
>> href="https://www.ietf.org/mailman/listinfo/netlmm" target=_blank 
>>> https://www.ietf.org/mailman/listinfo/netlmm
> 
> 
>