IETF Logo Mail Archive

Re: [lisp] draft-ietf-lisp-introduction-04 (Part 1)

Dino Farinacci <farinacci@gmail.com> Mon, 11 August 2014 16:00 UTC

Return-Path: <farinacci@gmail.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 51CA31A069F for <lisp@ietfa.amsl.com>; Mon, 11 Aug 2014 09:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 PHvUINABrWFo for <lisp@ietfa.amsl.com>; Mon, 11 Aug 2014 09:00:27 -0700 (PDT)
Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC281A06A5 for <lisp@ietf.org>; Mon, 11 Aug 2014 09:00:26 -0700 (PDT)
Received: by mail-pd0-f182.google.com with SMTP id fp1so11057987pdb.27 for <lisp@ietf.org>; Mon, 11 Aug 2014 09:00:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9bsvCk20KTN1nwAazKPtdpWkyb11r631bxHMfls51SQ=; b=ZT+u93lsXvjZvrAOta3SdzGR73WeH2sNguARvFrXQifiz4BliUXFGJ4GH2GqwzpcF8 AoOfq6JnzXdYxGzJhTSMFUqYSmkKzR3oYRAklkWGkohUznpIEeD8plX6mB22Bm7R0S34 9eKxrJgubCn/8YcQmc7HPkd+ZXRkHSrFqP+zzOsyn6sizroSWWP5gjsp5YHG2UOKuRsA QtKxRBkvyIAYflKF90Kp5ey5QgHl1oCiUIb6mxM4RM90cmsAerTfPTM1NXcaAFO3Jlgk LnaDYY3bOsaUadahZYrjfXDtrqHmZW6EHKsKDMh4jwZwPUvi3PsOcatg5+s6bVd2VxlZ GweA==
X-Received: by 10.68.139.162 with SMTP id qz2mr2213130pbb.153.1407772826128; Mon, 11 Aug 2014 09:00:26 -0700 (PDT)
Received: from [192.168.1.231] ([207.145.253.66]) by mx.google.com with ESMTPSA id re8sm18075605pdb.61.2014.08.11.09.00.23 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Aug 2014 09:00:24 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <f6c56a2d5cd24a1d8c5d46ad96655ffa@CO1PR05MB442.namprd05.prod.outlook.com>
Date: Mon, 11 Aug 2014 09:00:21 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <48B5B6E2-F0A6-4BCA-927F-05AAC9C2B365@gmail.com>
References: <66bae15549d145a7bcd88223de7ad0ee@CO1PR05MB442.namprd05.prod.outlook.com> <CAGE_QeybcLMzNxMr1CPmtnPATjcEN9V9VWZ-mMo+V+nbmTNVLQ@mail.gmail.com> <f6c56a2d5cd24a1d8c5d46ad96655ffa@CO1PR05MB442.namprd05.prod.outlook.com>
To: Ronald Bonica <rbonica@juniper.net>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/U0OpzMLSh37n3kYyThFG4NKlNzU
Cc: LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 1)
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: Mon, 11 Aug 2014 16:00:29 -0000

> Hi Albert,
> 
> LISP solves one part of the TE problem. That is, it allows the ITR to choose the ETR through which traffic enters the destination LISP site. However, it doesn't determine the path that traffic takes between IETR and ETR. So, it that sense, LISP TE is different from traffic engineering with MPLS.

Read draft-farinacci-lisp-te Ron. A path CAN be chosen. And it is a super-set of functionality that MPLS-TE provides.

> Also, I am not sure that it is *always* a good idea to let the ITR choose the ETR through which traffic enters the destination LISP site. A discussion of when this is and isn't a good idea might be appropriate in the intro document.

The intro document should not be subjective. We should have learned from previous mistakes on this topic.

Dino

> 
>                                                                   Ron
> 
>>> - Section 7.3 needs to be rethought. LISP doesn't provide TE, in the same
>> sense that MPLS does. It's quite different.
>>> 
>> 
>> RFC6830 states that LISP offers TE.
>> 
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

v2.23.0 | Report a Bug | By Email