Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt

Juan Alcaide <jalcaide@cisco.com> Thu, 23 April 2015 12:17 UTC

Return-Path: <jalcaide@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F041B3059 for <idr@ietfa.amsl.com>; Thu, 23 Apr 2015 05:17:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.801
X-Spam-Level:
X-Spam-Status: No, score=-6.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 LtjkXfcLhU1V for <idr@ietfa.amsl.com>; Thu, 23 Apr 2015 05:17:29 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6526D1B3045 for <idr@ietf.org>; Thu, 23 Apr 2015 05:17:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2072; q=dns/txt; s=iport; t=1429791450; x=1431001050; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=4ric1cCojnDNl/AKOkq5SgrEFCbb8DnMPVxishD+EgQ=; b=j2uqm2PNoqFwuWj/yFqGTSCMis9qiKrLcwwlSDRw3TrR5iTrHTEktnFa Ug4PO07LvIZegdlRYQY2/xO2V2dahRCqo0pgkt+pbjn9kyleG8IWVyEn7 c50rfgnIse/hTe5KTMEaPddll3AwrW3699H6lPqIHd10WQHekSa4TprWE Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AYBQCD4jhV/4oNJK1bgwzPLAKBOUwBAQEBAQGBC4QgAQEBAwFrDgULCw44VwaINgjMZQEBAQEBAQEBAQEBAQEBAQEBAQEZizeFBAeELQWdFIM/jQ2DTiOED4MXAQEB
X-IronPort-AV: E=Sophos;i="5.11,630,1422921600"; d="scan'208";a="411048351"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP; 23 Apr 2015 12:17:29 +0000
Received: from clubhouse-1.cisco.com (clubhouse-1.cisco.com [64.100.21.13]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3NCHRBI025852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2015 12:17:28 GMT
Date: Thu, 23 Apr 2015 08:17:26 -0400 (EDT)
From: Juan Alcaide <jalcaide@cisco.com>
To: Susan Hares <shares@ndzh.com>
In-Reply-To: <002d01d07d55$168b3b60$43a1b220$@ndzh.com>
Message-ID: <alpine.GSO.2.00.1504230812570.5542@clubhouse-1.cisco.com>
References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> <D14BFEEA.4CC52%wesley.george@twcable.com> <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> <D14C3347.A438A%aretana@cisco.com> <alpine.GSO.2.00.1504161723090.17655@clubhouse-1.cisco.com> <001f01d07b3f$13ee12f0$3bca38d0$@ndzh.com> <B17A6910EEDD1F45980687268941550F0CB90981@MISOUT7MSGUSRCD.ITServices.sbc.com> <alpine.GSO.2.00.1504201548460.29478@clubhouse-1.cisco.com> <20150421202647.GB1600@pfrc> <alpine.GSO.2.00.1504220511220.16159@clubhouse-2.cisco.com> <D15D7DB9.4E672%wesley.george@twcable.com> <002d01d07d55$168b3b60$43a1b220$@ndzh.com>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-838832689-1429791447=:5542"
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/ESZKUHpkLls2z2cCeW7aLCRtUGU>
Cc: idr@ietf.org, jgralak@juniper.net, "'UTTARO, JAMES'" <ju1738@att.com>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2015 12:17:31 -0000

Let me be clear. I don't want to revise the FSM.

With the current FSM, internal BGP alias feature will work if we are 
strict in how it's implemented. Otherwise, we may have interoperability 
problems. Basically, it needs to be specified with AS is tried first.

Just want to make sure the draft says this explicetely (in its current 
form it is implied).

-J


> WG, George, Jeff and Juan:
>
> A revision to the state machine in BGP is outside the scope of this draft.  For those who want to participate in a revision of the state machine, please send me your names.   I will put you on a design team to examine the state machine and provide a draft for the WG group.
>
> Sue
>
>
> WG] I think the point here is that even this more basic guidance needs to be bashed against what the FSM currently does vs what the spec says it should do (or worse, where the spec is ambiguous and has likely been handled different ways by different vendors) before we can determine where/if it's actually necessary to provide explicit guidance on the matter. The philosophy of the draft has generally been to not be overly proscriptive and discuss the desired behavior, and then let the implementers figure out how that has to work in the guts of their BGP implementation, such as within their implementation of FSM. If you can point to guidance that we need to provide to prevent the desired behavior from being critically altered if it is incorrectly implemented at the FSM level or it otherwise creates interoperability issues for something that is pretty much only locally significant, I can see about adding it, but you will definitely need to provide text, as I am by no means an expert on
  how this interacts with the FSM.
>