IETF Logo Mail Archive

Re: [lisp] [pim] WGLC draft-ietf-pim-join-attributes-for-lisp-03

"Jesus Arango (jearango)" <jearango@cisco.com> Wed, 08 June 2016 06:47 UTC

Return-Path: <jearango@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 A731912D7F4; Tue, 7 Jun 2016 23:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
X-Spam-Status: No, score=-15.947 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 mZFdO3pYaI0N; Tue, 7 Jun 2016 23:47:26 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D79A12D18E; Tue, 7 Jun 2016 23:47:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2375; q=dns/txt; s=iport; t=1465368446; x=1466578046; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZbQRF8zJYcl0eo2adNx2o+AAk+eEqRmhOnUREZZYPRA=; b=g7cTTYq3Ky+pmyIOsmzKeFdPiSNwut7wgK3t7f8TxcdcLDfSkhsvrFzM IJSyzFxl/cEI5YINHcPfaZ8jnschwsyyckr+bFaGCNMAoVa9F4BDhJPXw AA812RKDoxqoit2WSdk9LdZLWcvt3QLKBhod13Z+rsqlE0304exp+Zzxx I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D1AQDpvldX/4YNJK1dgz6BUwavB4lwgg+BeYYTAoE+OBQBAQEBAQEBZSeERQEBAQMBOj8FBwQCAQgRBAEBHwkHIREUCQgCBA4FCIgNAw8IuSUNhAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEchieETYJDgWeFcAWYGzQBjCuBc48mh3WHawEeNoIHHIFLbokQfwEBAQ
X-IronPort-AV: E=Sophos;i="5.26,437,1459814400"; d="scan'208";a="283106783"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jun 2016 06:47:25 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u586lPrX022639 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Jun 2016 06:47:25 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 8 Jun 2016 01:47:24 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1104.009; Wed, 8 Jun 2016 01:47:24 -0500
From: "Jesus Arango (jearango)" <jearango@cisco.com>
To: Dino Farinacci <farinacci@gmail.com>
Thread-Topic: [lisp] [pim] WGLC draft-ietf-pim-join-attributes-for-lisp-03
Thread-Index: AQHRvS/rP5y/rkLukEibTEvdyF5U2p/W6s5wgABzBgCAB8nhcA==
Date: Wed, 08 Jun 2016 06:47:24 +0000
Message-ID: <0f78a5f449594ad5ba5e2c7c8deee2d6@XCH-ALN-008.cisco.com>
References: <ead4d10adfe946f3afaae63b784d301e@XCH-ALN-008.cisco.com> <0FAB6A25-739D-462D-BE0B-7768BCD04753@gmail.com> <e82c19c4ebef4c32adb6752047eb6232@XCH-ALN-008.cisco.com> <76C8DE6E-7E98-45BA-96FC-E25ABFF4EFDE@gmail.com>
In-Reply-To: <76C8DE6E-7E98-45BA-96FC-E25ABFF4EFDE@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.67.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/46ZEbVBd058C2V2u8J3C5wSjVTQ>
Cc: "lisp@ietf.org" <lisp@ietf.org>, "pim@ietf.org" <pim@ietf.org>, "Stig Venaas (svenaas)" <stig@cisco.com>
Subject: Re: [lisp] [pim] WGLC draft-ietf-pim-join-attributes-for-lisp-03
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.17
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 Jun 2016 06:47:27 -0000

FYI,

I am collaborating with Dino on his comments. We agreed to do some changes and are actively working on them. I will share the changes and publish a new draft version once we reach an agreement on the exact wording to use.

Thanks
Jesus


-----Original Message-----
From: Dino Farinacci [mailto:farinacci@gmail.com] 
Sent: Thursday, June 2, 2016 7:47 PM
To: Jesus Arango (jearango) <jearango@cisco.com>
Cc: pim@ietf.org; lisp@ietf.org; Stig Venaas (svenaas) <stig@cisco.com>
Subject: Re: [lisp] [pim] WGLC draft-ietf-pim-join-attributes-for-lisp-03

> I don't think map-notifies are relevant in the context of this draft. Keep in mind that this draft is written for "pim-signaled" head-end replication. In your "signal-free" draft, map-notifies are the correct message because you are tracking changes in the set of receiver RLOCS and that translates into changes in the merged RLOC set. In this draft, we are tracking changes in source EID location and the proper message for that is an SMR.

I was thinking of using Map-Notifies in this application not in the signal-free one. 

What you do is have the root-xTR register as  a receiver-xTR so when a move occurs the new root-xTR changes which causes the map-server to trigger a Map-Notify to each RLOC in the RLIC-set  because there was an RLOC-set change. 

> The receivers do have map-caches. They

In this data forwarding direction, this is an ETR. ETRs have database-entries which are registered. Used for decapsulation. 

Mao-caches are used for encapsulation. There is no encapsulation in these receiver-ETRs when data flows from a multicast source to the receivers the receiver-ETR supports. 

> have a map-cache entry mapping the source EID to the RLOC of the source XTR.

That is a map-cache entry in the root-ITR not in the ETRs. 

> This is the map-cache entry that we want the SMR to refresh. The creation of this

That is why this is backwards. 

> map-cache was not triggered by traffic. It was triggered by an RPF lookup by PIM in the receiver XTR.

Understand. But it should be called another data structure. Like an RPF data structure, like a RIB is used in normal native routing. 

In any event, if you don't clear up this text, it will be hard for anyone to understand this. 

Dino

v2.23.0 | Report a Bug | By Email