IETF Logo Mail Archive

Re: [lisp] draft-ermagan-lisp-nat-traversal question

Albert López <alopez@ac.upc.edu> Mon, 06 November 2017 08:58 UTC

Return-Path: <alopez@ac.upc.edu>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D89913FB56 for <lisp@ietfa.amsl.com>; Mon, 6 Nov 2017 00:58:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vth14JPZcT2S for <lisp@ietfa.amsl.com>; Mon, 6 Nov 2017 00:58:45 -0800 (PST)
Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id D4A1D13FADF for <lisp@ietf.org>; Mon, 6 Nov 2017 00:58:44 -0800 (PST)
Received: from correu-2.ac.upc.es (correu-2.ac.upc.es [147.83.30.92]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id vA68wgtg022269; Mon, 6 Nov 2017 09:58:42 +0100
Received: from [147.83.35.39] (sirius.ac.upc.es [147.83.35.39]) by correu-2.ac.upc.es (Postfix) with ESMTPSA id 70406325; Mon, 6 Nov 2017 09:58:37 +0100 (CET)
To: Dino Farinacci <farinacci@gmail.com>
Cc: lisp@ietf.org
References: <f574957a-e4fd-6984-99ef-185cd2c1bc15@ac.upc.edu> <B5138540-69F2-482B-AAC5-544BB2BD69D8@gmail.com>
From: Albert López <alopez@ac.upc.edu>
Message-ID: <2b946dce-7c33-5317-8f3b-9ffd2568381e@ac.upc.edu>
Date: Mon, 06 Nov 2017 10:01:36 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <B5138540-69F2-482B-AAC5-544BB2BD69D8@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/eeNWq4ozP0ARA_Ofsgw36AwyW8c>
Subject: Re: [lisp] draft-ermagan-lisp-nat-traversal question
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2017 08:58:50 -0000

In that case, I think that It would be better if the validation time / 
expiration time of the locator associated with the ECM-ed Map Register & 
ECM-ed Map Notify is related with the periodic time of sending ECM-ed 
Map Registers.
Usually a hole in the nat box is less than two minutes so we send 
periodic ECM Mag register to maintain this hole opened apart from 
maintaining the status in the Map Server. If we use the TTL of the 
record to maintain an entry in the Map Cacahe of the RTR, it is possible 
we maintain an entry which is no longer valid or send packets to an 
invalid rloc.  What do you think?

Regards

Albert

El 03/11/17 a les 18:38, Dino Farinacci ha escrit:
> The TTL in the Map-Register is the TTL returned in Map-Replies. So it is the expiry time for a map-cache entry. Note it is the “Record TTL” in the EID-record which both appear in Map-Register and Map-Reply messages.
>
> Dino
>
>> On Nov 3, 2017, at 1:35 AM, Albert López <alopez@ac.upc.edu> wrote:
>>
>> Dear all,
>>
>> In section 5.3 of the draft  draft-ermagan-lisp-nat-traversal which describe the RTR processing, it says that when the RTR receive and ECM-ed Map Notify, once it is validated, it changes the state of the associated map-cache entry to verified for the duration of the Map Register TTL.  What does it mean by Map Register TTL?  it means the TTL of the record of the Map Register or it is the same concept of the Map Register TTL of the Map Server which is 3 minutes? If I understand correctly, if we don't receive more Encap Map Register / Map Notify to renew this verified period, the map-cache entry of the RTR expires, at least the locator of the map-cache entry associated with the Encap Map register.
>>
>>    "Once the authenticity of the message is verified,
>>    RTR can confirm that the Map-Register message for the ETR with the
>>    matching xTR-ID was accepted by the Map-Server.  At this point the
>>    RTR can change the state of the associated map-cache entry to
>>    verified for the duration of the Map-Register TTL"
>>
>> Thank you in advance.
>>
>> Albert López
>>
>>
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp

v2.23.0 | Report a Bug | By Email