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

"Susan Hares" <shares@ndzh.com> Tue, 05 May 2015 22:38 UTC

Return-Path: <shares@ndzh.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 ED66D1AD01E for <idr@ietfa.amsl.com>; Tue, 5 May 2015 15:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.055
X-Spam-Level:
X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no
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 zU3rAwWv2oXN for <idr@ietfa.amsl.com>; Tue, 5 May 2015 15:38:06 -0700 (PDT)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 23B781ACDC6 for <idr@ietf.org>; Tue, 5 May 2015 15:38:06 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.55.43.247;
From: Susan Hares <shares@ndzh.com>
To: 'Juan Alcaide' <jalcaide@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> <alpine.GSO.2.00.1504230812570.5542@clubhouse-1.cisco.com>
In-Reply-To: <alpine.GSO.2.00.1504230812570.5542@clubhouse-1.cisco.com>
Date: Tue, 05 May 2015 18:37:54 -0400
Message-ID: <004101d08784$2150ca40$63f25ec0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQF4r1Z2HL4YFm8OUbIc3fl4NvJEkQMc7jnKAeHZrpYCMURyMwGvlBIDA1ULulwCf+QsTwNzHXxiAdKlupsCCDW+ewFzkepwAn9aergCce6R0p06bkDA
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/wq36abM2FpbWBmxVG_e8qVRN3YY>
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: Tue, 05 May 2015 22:38:09 -0000

Juan:

Thank you for this feedback.  I will pass this along to Alvaro and discuss
it with Wes. 

Sue 

-----Original Message-----
From: Juan Alcaide [mailto:jalcaide@cisco.com] 
Sent: Thursday, April 23, 2015 8:17 AM
To: Susan Hares
Cc: 'George, Wes'; 'Jeffrey Haas'; idr@ietf.org; jgralak@juniper.net;
'UTTARO, JAMES'
Subject: RE: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt


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.
>