Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT)

"Alvaro Retana (aretana)" <aretana@cisco.com> Wed, 17 February 2016 14:31 UTC

Return-Path: <aretana@cisco.com>
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 E91BC1ACC80; Wed, 17 Feb 2016 06:31:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.507
X-Spam-Level:
X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 pFvWfninU-d8; Wed, 17 Feb 2016 06:31:52 -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 23DFD1B2F15; Wed, 17 Feb 2016 06:31:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4468; q=dns/txt; s=iport; t=1455719512; x=1456929112; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=c153Wa8RVYYzn1gMQOD3MIwgZufbLx4fnSweR/8CRQo=; b=B+SFS8X8e49bvLMVpI6huezFXZy9tS0Tid284A2BsXYDdJvIy3C2FeFK onevxb8boj30eACp86VoAzHG4H5WKY/fJgExA2yQ7sYBgdOih2YlL2ZSV MA4JSaAXda7YMWGA51ZiXMZA2cxilQjx0ygCSonFPWeE9afQOr21OiifM k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQCGg8RW/5FdJa1UCoM6gT8Gt36CE?= =?us-ascii?q?wENgWeGDQKBQzgUAQEBAQEBAWQcC4RCAQEEbAoDEAIBCBguIRElAgQOBYgFAxK?= =?us-ascii?q?2Tw2EWwEBAQEBAQEBAQEBAQEBAQEBARiGEoQ7gjqBUYRkAQSNYYURhBEBi2WBc?= =?us-ascii?q?45zhwSHQgEeAQFCggIZFIE0aocoJBl8AQEB?=
X-IronPort-AV: E=Sophos;i="5.22,460,1449532800"; d="scan'208";a="77850356"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2016 14:31:50 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u1HEVpR9030009 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Feb 2016 14:31:51 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 17 Feb 2016 08:31:51 -0600
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Wed, 17 Feb 2016 08:31:51 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "draft-ietf-lisp-eid-block@ietf.org" <draft-ietf-lisp-eid-block@ietf.org>
Thread-Topic: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT)
Thread-Index: AQHRaEHsoX4wm6EbUU2zdG+H0868d58u3uQA//+3JwCAAQKOAP//vsSAgAEMu4D///wWAA==
Date: Wed, 17 Feb 2016 14:31:51 +0000
Message-ID: <D2E9E832.110CF8%aretana@cisco.com>
References: <20160215224046.28084.69566.idtracker@ietfa.amsl.com> <1C8A2608-7564-4190-9CE6-698024EB9564@gigix.net> <D2E86D11.1108DC%aretana@cisco.com> <56C396A6.1080506@joelhalpern.com> <D2E90B2F.110B96%aretana@cisco.com> <CAKFn1SF1Q7OtKQa=pA4JLDe4fCGm+M3TUGHMT+5fRUGeZkQQ_Q@mail.gmail.com>
In-Reply-To: <CAKFn1SF1Q7OtKQa=pA4JLDe4fCGm+M3TUGHMT+5fRUGeZkQQ_Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.212.52]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <981ADE5B6005C049999990B44E4D6B87@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/VTfQoVWbxL6t_DM__QdCZg4GBMY>
Cc: "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>, =?iso-8859-1?Q?Roger_J=F8rgensen?= <rogerj@gmail.com>, "lisp@ietf.org" <lisp@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT)
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: <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, 17 Feb 2016 14:31:59 -0000

On 2/17/16, 4:46 AM, "Roger Jørgensen" <rogerj@gmail.com> wrote:

[Responding to Roger's e-mail..but the answer is not specifically directed
at him.]

>On Tue, Feb 16, 2016 at 11:44 PM, Alvaro Retana (aretana)
><aretana@cisco.com> wrote:
>> On 2/16/16, 4:37 PM, "iesg on behalf of Joel M. Halpern"
>> <iesg-bounces@ietf.org on behalf of jmh@joelhalpern.com> wrote:
>>
>> Hi!
>>
>>>To phrase the experiment judgment differently, either after tree years
>>>there will be sufficient demonstrated value to justify a permanent
>>>allocation, or there won't.  It would take a strange situation to extend
>>>the experimental allocation (although of course we can not foresee every
>>>possible situation.)
>>>
>>>Since I do not expect the IESG to commit to specific criteria (other
>>>than those already documented in RFCs) for granting the permanent
>>>allocation, I don't see much that can be said.
>>>
>>>If you really want, I suppose that we could add a sentence saying that
>>>after the experiment, permanent allocation will be evaluated using the
>>>usual criteria for such requests.
>>
>> The point I'm trying to make is about the evaluation of what you call
>> "sufficient demonstrated value".  As you say, the allocation is
>>justified
>> if value is demonstrated, how is that value demonstrated?
>>
>> At this point in time the allocation is being made temporarily so that
>>an
>> experiment can be run.  What is the success criteria for that
>>experiment?
>
>I understand what you ask for, but I have no idea on how to formulate such
>criteria.
>
>What I am personally quite sure about is that the amount of
>assignment made from this allocation alone will not be a justification for
>granting this a permanent allocation. We could end up with very few
>assigment but the technical gain is significant.

Agreed.

>So, this experiment end in 3years time automatically and before that
>LISP-WG will either 1.) let it expire, 2.) ask for an extension  or
>3.) ask for a permanent allocation.
>
>For option 2 or 3 to happen someone will have to present a draft that
>can justify it technical, or option 1 will happen. Either way we would
>have learned something from it I hope.

I hope we learn too.

Putting the allocation issue aside for a second...

The document itself already lists "the most relevant scenarios" in Section
3. (Rationale and Intent).  For the scenarios listed, what would represent
a successful experiment?  What type of information would we want to
collect to determine if the scenario was in fact relevant (or not)?

For example, taking one of the scenarios (I chose the one with the
shortest description):

   Avoid penalize non-LISP traffic:  In certain circumstances it might
         be desirable to configure a router using LISP features to
         natively forward all packets that have not a destination
         address in the block, hence, no lookup whatsoever is performed
         and packets destined to non-LISP sites are not penalized in any
         manner.


In this case I would assume people would want to look at the impact of the
lookup -- is non-LISP traffic penalized?  How much?  Does having a
separate router processing help?  Is it significant?

Answering questions like that would identify whether, for that scenario,
having the block of addresses made a difference or not.  If, for example,
the penalty was huge and using the block reduced it significantly, then it
helps the case for an extended (maybe even permanent allocation).  OTOH,
if the performance is about the same, then maybe that doesn't justify
anything.  The other potential outcome is that experience was gathered,
but that the results are still inconclusive and more experience is needed,
maybe justifying an extension.

I'm just making all that up -- I'm sure the authors/WG know better than me
why each of those scenarios is relevant.

The important thing about the above is that then the future IESG is not
making a decision in a vacuum about allocation.  And the future lisp WG
can also support their request for extension/permanent allocation with
data from the experiment.

In the end what I would like to see the draft talk about is not the
decision for allocation itself, but about what is going to be done with
it, and (given "the most relevant scenarios") how that experience can
support someone's case in the future.

Thanks!

Alvaro.