IETF Logo Mail Archive

[IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03

"Frederic Detienne (fdetienn)" <fdetienn@cisco.com> Thu, 23 January 2014 15:32 UTC

Return-Path: <fdetienn@cisco.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7C41A0037 for <ipsec@ietfa.amsl.com>; Thu, 23 Jan 2014 07:32:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.036
X-Spam-Level:
X-Spam-Status: No, score=-15.036 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.535, 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 gHn402nRlsSm for <ipsec@ietfa.amsl.com>; Thu, 23 Jan 2014 07:32:38 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D576B1A0036 for <ipsec@ietf.org>; Thu, 23 Jan 2014 07:32:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1249; q=dns/txt; s=iport; t=1390491158; x=1391700758; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AWcsvf20GcMJ9aSin3QJjiJDyJXZknoTMljnv65zOgY=; b=PzzfmQY4vqluEfNToj1hqEN0+9XKcIi5g67F5whULi3RcvExAMqc0+on W+lx9mKzbo6jOtJT4MApiewyanBECkiW51aGA0MYu4pyZv6GHFrnidbq3 ET7jqJMA2wUMebR6gNznCdF+jgJyWBt9QRwBh8+xkWi949/Zc6B5F8ocM Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAA414VKtJXHB/2dsb2JhbABbgww4VrtzgRAWdIIlAQEBAwF5EAIBTjIlAgQOiAIIDcVjF48AB4MkgRQEmCOBMpBmgy2CKg
X-IronPort-AV: E=Sophos;i="4.95,706,1384300800"; d="scan'208";a="299228545"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 23 Jan 2014 15:32:38 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0NFWba8011181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jan 2014 15:32:37 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.243]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 09:32:37 -0600
From: "Frederic Detienne (fdetienn)" <fdetienn@cisco.com>
To: Praveen Sathyanarayan <praveenys@juniper.net>
Thread-Topic: Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03
Thread-Index: AQHPGFBYhUfNVOEedUmNXuQwCZtSsQ==
Date: Thu, 23 Jan 2014 15:32:20 +0000
Message-ID: <88259CEC-4D10-48EC-8A21-0D2F348EEE3F@cisco.com>
References: <CF02A72F.6A65A%praveenys@juniper.net>
In-Reply-To: <CF02A72F.6A65A%praveenys@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.60.74.189]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <AD6FF8EA73964141900C164E3812378E@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<ipsec@ietf.org> WG" <ipsec@ietf.org>
Subject: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 15:32:41 -0000

> 
>   1.2 What happens when a prefix administratively changes from behind one
> branch to another ? How do servers get notified about that ?
>  
> [PRAVEEN] That’s an interesting point Fred, and thanks for bringing it up. First, please refer the ADVPN_INFO Payload and PROTECTED_DOMAIN sections (3.6 and 3.9, respectively) of http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03. As a general rule, each spoke can download updated PROTECTED_DOMAIN information periodically, which advertises everything behind the hub and all other spokes combined. Of course, this does not change if some subnet has moved from behind spoke A to behind another spoke, B. However, the Lifetime attribute of the ADVPN_INFO payload is key here. We could see this being employed in a straightforward manner to allow for this transition: a) the subnet can "disappear" and be unreachable for one Lifetime, or b) the original spoke can redirect to the new spoke.

It turns out I did read those sections and this is exactly what surprised me. Your answer is even more surprising.

Before going any further, is this resource exclusively exchanged between hub & spoke or also between spokes ?

thanks,

	fred

v2.23.0 | Report a Bug | By Email