Re: [lisp] Some basic questions ...

Marc Binderberger <marc@sniff.de> Fri, 21 February 2014 00:42 UTC

Return-Path: <marc@sniff.de>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714161A0389 for <lisp@ietfa.amsl.com>; Thu, 20 Feb 2014 16:42:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham
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 dU--g1DbPwL8 for <lisp@ietfa.amsl.com>; Thu, 20 Feb 2014 16:42:01 -0800 (PST)
Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C44171A037C for <lisp@ietf.org>; Thu, 20 Feb 2014 16:41:52 -0800 (PST)
Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 4C85D2AA0F; Fri, 21 Feb 2014 00:41:47 +0000 (GMT)
Date: Thu, 20 Feb 2014 16:41:47 -0800
From: Marc Binderberger <marc@sniff.de>
To: Dino Farinacci <farinacci@gmail.com>
Message-ID: <20140220164147147597.5306c32c@sniff.de>
In-Reply-To: <85246DF3-B45A-474A-BB5F-B0C9D3EE88DA@gmail.com>
References: <20140217013051556658.9cfb700c@sniff.de> <85246DF3-B45A-474A-BB5F-B0C9D3EE88DA@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: GyazMail version 1.5.15
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/y57NzWAqRWXKtNpvcdpn9K8kEv0
Cc: LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] Some basic questions ...
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Fri, 21 Feb 2014 00:42:04 -0000

Hello Dino,

there was another question I forgot regarding the notifications: so 
when the map-notification is not used as an ACK for map-register but is 
actually informing the ETRs about events then how is the delivery 
guaranteed? The underlying IP/UDP transport may drop.

For map-register we periodically send again, so packet loss of 
map-registers is not a big problem. What is your idea for map-notifies? 
Some of the notifications may be singular events. Other of course could 
be periodic (e.g. merge notification triggered by the map-registers?).

Would I need an ACK for the map-notification (and some fast-timer 
re-send, e.g. every 1sec until ACKed) ?  That would take state/timer, 
although only until's it's ACKnowledged.


Thanks & Regards,
Marc



On Mon, 17 Feb 2014 10:13:16 -0800, Dino Farinacci wrote:
>> Hello LISP experts,
>> 
>> have two questions, mainly to understand the context a bit better.
> 
> No prob Marc. Thanks for the email. I'll attempt to answer them but 
> others can chime in as well.
> 
>> Q1: map-notify message.
>> 
>> maybe it's the name but I always expected this message is for the Map 
>> Server to inform ETRs. Kind of a "push" method. But reading RFCs 6830 
> 
> That is exactly what it is. It is used as a event notification from 
> the Map-Server to the ETRs that register for a particular EID-prefix. 
> So when a locator-set changes, the old locators can be notified. The 
> main reason to call it a "Map-Notify" was for this purpose. And you 
> can now understand why by looking at the data-center use-case 
> documents that have been published by Yves and Victor.
> 
>> and 6833 again it seems that the Map-Notify is simply an ACK for a 
>> received and processed Map-Register message. Take the Map-Register 
>> message, set the type to Map-Notify and send back.
> 
> So when a registerer requests Map-Notifies, it will get them for 
> various reasons. The first is the case I said above and the other 
> case is to acknowledge a Map-Register.
> 
>> Now, the use as ACK is not a contradiction to the broader use as a push 
>> message. So my question to the LISP experts and inventors is: is 
>> Map-Notify restricted to be just an ACK? (having an extra type for it 
>> seems generous)
> 
> It is not restricted to just an ack. There is also another use case. 
> Here it is:
> 
> (1) You have two xTRs, each sitting behind different NAT devices.
> (2) The xTRs get private addresses assigned to their interfaces. So 
> they are using them as "local RLOCs". But no one will be able to 
> encapsulate to them so they need to find out their global RLOC 
> addresses.
> (3) Each of the two xTRs are at the same LISP site and can receive 
> encapsulated packets for the same EID-prefix.
> (4) When they each discover their global RLOCs (by mechanisms 
> descrbied in draft-ermagen-lisp-nat-traversal), they each register 
> their own global RLOC. They register with the "merge-request" bit set 
> so the Map-Server will add both xTR global RLOCs to the locator-set.
> (5) So now, if an xTR gets a Map-Request, it will want to send a 
> Map-Reply with the merged-locator set. Well how will it do that when 
> it only knows its own?
> (6) A Map-Notify is used here by the Map-Server to tell each xTR 
> about the other's global RLOC.
>