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

"Vina Ermagan (vermagan)" <vermagan@cisco.com> Wed, 08 November 2017 20:33 UTC

Return-Path: <vermagan@cisco.com>
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 68070129BCF for <lisp@ietfa.amsl.com>; Wed, 8 Nov 2017 12:33:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 3ynsovNasIt2 for <lisp@ietfa.amsl.com>; Wed, 8 Nov 2017 12:33:45 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844C4129BC5 for <lisp@ietf.org>; Wed, 8 Nov 2017 12:33:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3260; q=dns/txt; s=iport; t=1510173225; x=1511382825; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=at2G4FzsiBPxtR9EipvQYoksX4q8Y7AwVyotKMkqGMQ=; b=Nfr6zirzjYe4WtZrcahF4KJk8L9MH16qzelwAAKYVw95P/09AqCZ4cFY KpDQV5VMzCW1mMJiRTMQjOsC5K4x/GFljVRMCmheWfKyLn+jPiU7bPL4K vNwnYbepK0U8i3BOuQxb5yYSf97+qnD3r3faa1Hq4s04PpZ6Dq23ySkhw 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CaAABraQNa/5hdJa1cDgsBAQEBAQEBAQEBAQEHAQEBAQGDNGRuJweOFY8lgXyWTBCCAQoYC4UYAoR8PxgBAQEBAQEBAQFrKIUfAQEBAwEBbAsQAgEIGC4nCyUCBAENBYojEKwnixsBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMwggeBVIFpgh2BDYRdIhaFeAWSLoZciRAClHyTOJV0AhEZAYE4AR84gXF6FUmCZIJcHIEoP3eJRgIFIAeBBYERAQEB
X-IronPort-AV: E=Sophos;i="5.44,365,1505779200"; d="scan'208";a="321783769"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2017 20:33:44 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vA8KXig9025895 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Nov 2017 20:33:44 GMT
Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 8 Nov 2017 14:33:44 -0600
Received: from xch-rcd-019.cisco.com ([173.37.102.29]) by XCH-RCD-019.cisco.com ([173.37.102.29]) with mapi id 15.00.1320.000; Wed, 8 Nov 2017 14:33:44 -0600
From: "Vina Ermagan (vermagan)" <vermagan@cisco.com>
To: Albert López <alopez@ac.upc.edu>, Dino Farinacci <farinacci@gmail.com>
CC: "lisp@ietf.org" <lisp@ietf.org>
Thread-Topic: [lisp] draft-ermagan-lisp-nat-traversal question
Thread-Index: AQHTVH7CnNCB5I/GnkyA06tVaRWOBKMDP+SAgAQ3ZgCAA1/rgA==
Date: Wed, 08 Nov 2017 20:33:44 +0000
Message-ID: <D628A765.D9526%vermagan@cisco.com>
References: <f574957a-e4fd-6984-99ef-185cd2c1bc15@ac.upc.edu> <B5138540-69F2-482B-AAC5-544BB2BD69D8@gmail.com> <2b946dce-7c33-5317-8f3b-9ffd2568381e@ac.upc.edu>
In-Reply-To: <2b946dce-7c33-5317-8f3b-9ffd2568381e@ac.upc.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.9.160926
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.71.191]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <405A9447C00DEF40AC681117C4108532@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/6b5w5Quib51782qWDJdNFXldyv4>
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: Wed, 08 Nov 2017 20:33:47 -0000

Hi Albert,

³Map Register TTL² in the referenced paragraph is indeed the TTL for which
a Map Register stays valid in a Map Server. Suggested time in the RFC for
periodic Map Registers is 1 minute. And MS will expire the registration
after 3 minutes if it does not receive a renewal. So this TTL in RTR
should be set no larger than 3 minutes, and no smaller than 1 minute.
Unfortunately NAPT devices don¹t have a standard TTL for expiring their
address associations; some use 2 minutes as the threshold. So the 3 minute
recommendation for expiring a Map Register seems suitable here.

Hope this clarifies it.

Best,
Vina


On 11/6/17, 1:01 AM, "lisp on behalf of Albert López"
<lisp-bounces@ietf.org on behalf of alopez@ac.upc.edu> wrote:

>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
>
>_______________________________________________
>lisp mailing list
>lisp@ietf.org
>https://www.ietf.org/mailman/listinfo/lisp