Re: [Idr] Ben Campbell's Discuss on draft-ietf-idr-as-migration-06: (with DISCUSS)

"Ben Campbell" <ben@nostrum.com> Mon, 28 September 2015 19:38 UTC

Return-Path: <ben@nostrum.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 1FB181B2C19 for <idr@ietfa.amsl.com>; Mon, 28 Sep 2015 12:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
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 Lpr_PgNGVhm8 for <idr@ietfa.amsl.com>; Mon, 28 Sep 2015 12:38:29 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1985D1B2C16 for <idr@ietf.org>; Mon, 28 Sep 2015 12:38:29 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8SJcFxr013752 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Sep 2015 14:38:25 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: Ben Campbell <ben@nostrum.com>
To: Alvaro Retana <aretana@cisco.com>
Date: Mon, 28 Sep 2015 14:38:15 -0500
Message-ID: <02D24C30-23D4-4147-B07D-332676E953AE@nostrum.com>
In-Reply-To: <D2270D59.D2D74%aretana@cisco.com>
References: <20150916175709.15284.39811.idtracker@ietfa.amsl.com> <D21FADDE.D11E6%aretana@cisco.com> <D22192F2.69F88%wesley.george@twcable.com> <8C52202E-2B65-41C5-9E95-DDBD0EC263B7@nostrum.com> <D2270D59.D2D74%aretana@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.2r5107)
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/c1FjrX4sos7fgQCi4kdqiw1shzM>
Cc: idr@ietf.org, idr-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-idr-as-migration@ietf.org, shares@ndzh.com
Subject: Re: [Idr] Ben Campbell's Discuss on draft-ietf-idr-as-migration-06: (with DISCUSS)
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 28 Sep 2015 19:38:30 -0000

On 22 Sep 2015, at 13:17, Alvaro Retana (aretana) wrote:

> On 9/18/15, 11:13 AM, "Ben Campbell" <ben@nostrum.com> wrote:
>
> Ben:
>
> Hi!
>
>> I don't necessarily object to a PS that, for example, doesn't impact
>> interoperability. It's just that the first paragraph as written feels
>> like an explanation of why something _wouldn't_ be a PS. So even 
>> adding
>> few sentences explaining why the working group wants this to be
>> standards track in spite of that would be helpful, even if you 
>> otherwise
>> keep the existing text.
>
> As Wes explained, a big (if not all) the motivation for the WG to make
> this document a PS lies in other work that interworks closely with the
> AS_PATH attribute, which is what is changed in the mechanisms 
> specified
> here.  Specifically, BGPSec is the major one.
>
> After reading the Introduction again, I find this piece of text that 
> (to
> me) seems to address what you want:
>
>  However, it is necessary to document these de facto standards to
>  ensure that new implementations can be successful, and any future
>  protocol enhancements to BGP that propose to read, copy, manipulate
>  or compare the AS_PATH attribute can do so without inhibiting the use
>  of these very widely used ASN migration mechanisms.

At this point, I think this is strictly an editorial gripe--but that 
text was part of what made me wonder about the intent. Language like 
"Document these de facto standards" led me down the "document things 
people are doing" vs "creating an IETF standard".

>
>
> The only thing that this text doesn¹t explicitly mention is BGPSec.  
> There
> is a companion document that specifically addresses the sidr side:
> https://tools.ietf.org/html/draft-ietf-sidr-as-migration
>
> We could add an Informative reference to BGPSec ‹ but with the 
> -sidr-
> draft I think we¹re covered.
>
> Thanks!
>
> Alvaro.