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

Juan Alcaide <> Wed, 22 April 2015 09:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 171E11B3359 for <>; Wed, 22 Apr 2015 02:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z-RaLv669OxM for <>; Wed, 22 Apr 2015 02:22:36 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C04731A1AB3 for <>; Wed, 22 Apr 2015 02:22:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2300; q=dns/txt; s=iport; t=1429694550; x=1430904150; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=veWHD0YXBRR2A3HtD4pS/tnsRPS363UFqvXbTqktqYs=; b=H+5VCIrmiDOcl7SeCoxzDw5DGrSMnJpfcrXCq51C71WZ0QFLcPUOHQ8e SpdI7l6+668/bcziecban0Ek3HjxEOHpeD+Fd2AZnGxUEoci1Mccq1ec+ fQ/k33W8HJ8Trm7WnoG8TOnzJ7PYK61XsozojEwdGwl/DSXs7vijzFQlj 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.11,623,1422921600"; d="scan'208";a="413761796"
Received: from ([]) by with ESMTP; 22 Apr 2015 09:20:49 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t3M9KkXX005697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2015 09:20:48 GMT
Date: Wed, 22 Apr 2015 05:20:45 -0400
From: Juan Alcaide <>
To: Jeffrey Haas <>
In-Reply-To: <20150421202647.GB1600@pfrc>
Message-ID: <>
References: <> <> <02e401d072e4$4f5a1cc0$ee0e5640$> <> <> <001f01d07b3f$13ee12f0$3bca38d0$> <> <> <20150421202647.GB1600@pfrc>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <>
Cc: "''" <>, "''" <>, "UTTARO, JAMES" <>, 'Susan Hares' <>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Apr 2015 09:22:38 -0000



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

You mean vendors implementing 'prepend on incomming ebgp update'?
Possibly, but we shouldn't describe on a RFC only the suboptimal approach 
('prepend on outbound ibgp update')

> 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.)
So internal-alias, besides Juniper naming, is the 'official' name 
according to the yang module?

In anycase, since the draft describes multiple vendors implementations, it 
may be worth to describe the naming of others.

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

Don't want to do a deep inspection of the FSM ;-)
It's something more basic. Consider

- You can send only one AS in your open each time you try to establish a 
new session
- The As you send does not depend on the AS you receive (no negotiation)
- You can accept received AS to be accepted if it's one of the 2 
configured ones
- You must force AS you send and AS you receive to be the same.

>From the above, it can be deduced that if both speakers have the internal 
alias feature configured, they must send the same AS ast the first time 
they try to establish the session. And session must be formed with this 
AS. Otherwise, AS never match and session cannot be establish.

We could do something more complicated, but this would really be beyond 
the scope of the draft.

> --Jeff