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

Jeffrey Haas <jhaas@pfrc.org> Tue, 21 April 2015 20:26 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 338ED1A8A43 for <idr@ietfa.amsl.com>; Tue, 21 Apr 2015 13:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.578
X-Spam-Level:
X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 K-0JcLzW74L7 for <idr@ietfa.amsl.com>; Tue, 21 Apr 2015 13:26:48 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 645821A8A17 for <idr@ietf.org>; Tue, 21 Apr 2015 13:26:48 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 096F8C19B; Tue, 21 Apr 2015 16:26:48 -0400 (EDT)
Date: Tue, 21 Apr 2015 16:26:47 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Juan Alcaide <jalcaide@cisco.com>
Message-ID: <20150421202647.GB1600@pfrc>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.GSO.2.00.1504201548460.29478@clubhouse-1.cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/3HGWSRQCLq567yGjdqoZRqcrA3o>
Cc: "'idr@ietf.org'" <idr@ietf.org>, "'jgralak@juniper.net'" <jgralak@juniper.net>, "UTTARO, JAMES" <ju1738@att.com>, 'Susan Hares' <shares@ndzh.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, 21 Apr 2015 20:26:49 -0000

On Mon, Apr 20, 2015 at 04:21:38PM -0400, Juan Alcaide wrote:
> - As we discussed, for ebgp incomming updates for local-as it makes
> more sense to prepend AS on incomming updates. I think we shoudl
> describe this option as the default one and any other one as a
> variation.

I would say that the "Juniper" behavior has quite a bit of history.  Wes and
company have done a good job being agnostic about these long-standing
behaviors and simply documenting them rather than kicking off a particular
religious war on what should be done.

It wouldn't surprise me though that the publication of this document as an
RFC leads to various vendors implementing versions of the knobs they
previously didn't support.

> - Cisco plans to implement the internal BGP alias as ibgp local-as
> dual-as. So perhaps we can choose an agnostic name and explain both
> Juniper and Cisco names.

I think it's beyond the scope of any IETF document beyond yang and MIB
modules to prescribe the name of a vendor's configuration knob. :-)

(The astute reader will note that we'll have to settle on a name in the yang
module.  See prior comments at the mic during IDR about IETF
vendor-registered augmentation modules.)

> - About "the speaker SHOULD send BGP OPEN using the globally
> configured ASN first". I think we should emphasize how the FSM gets
> modified. It may be implicit, but it may save us from some
> interoperabilities problems. My ideas:

You are welcome to provide text for such a thing but I would suggest it's
not worth the review time of IDR.  The introduction of the internal toggle
would effectively instantiate a sub-state machine within the overall state
machine and be quite the mess.  I have long since lost my notes on the FSM
during RFC 4271 standardization work, but had noted that it had some issues.

Feel free to audit the FSM to see if you can find those issues again and see
how this would interact with the errata. :-)

--Jeff