[sidr] AD review and progressing draft-ietf-sidr-as-migration-02

Alia Atlas <akatlas@gmail.com> Fri, 30 January 2015 20:51 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196F71A874A for <sidr@ietfa.amsl.com>; Fri, 30 Jan 2015 12:51:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 ooHw93e-Q58Z for <sidr@ietfa.amsl.com>; Fri, 30 Jan 2015 12:50:58 -0800 (PST)
Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BBC21A872C for <sidr@ietf.org>; Fri, 30 Jan 2015 12:50:42 -0800 (PST)
Received: by mail-yh0-f43.google.com with SMTP id 29so11944726yhl.2 for <sidr@ietf.org>; Fri, 30 Jan 2015 12:50:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=beO1RTVhjpeQ+TA9Mx9Ll4SAFXJzZjyiclxphS+I2Sw=; b=VGr0qojvGjN3DjTJaKpXHZ5ZL37clxgKijgZGMjnwULTcrHGj6FqiKnUlq7xBT7NlX MRn5nrwUvNLSD7MvO0rPX32abxUsj6nc8ujzM3r6ooDjr4GL+4714iX6WgXTfsTMJDKk Wb8swmq7U827byiVgE/TKlAPtfQdemA83DOdYYfU28/zkhkEm6y7p95IxeBD4qUkJa4Z Jy4sCHCEYKZIEoDYSd7vB72d/DCw2ykhjHs5+JkukYTi+607y/7IN9CyIz+WjngdsQFw cm33Phr3Z5cW0YpKwveh+XgO5OuDjMmHJ1N7B2Rislx0jlmf9wEYHtXnNFzQxSw2Kd+h +8lQ==
MIME-Version: 1.0
X-Received: by 10.170.117.16 with SMTP id j16mr4476390ykb.15.1422651041490; Fri, 30 Jan 2015 12:50:41 -0800 (PST)
Received: by 10.170.133.80 with HTTP; Fri, 30 Jan 2015 12:50:41 -0800 (PST)
Date: Fri, 30 Jan 2015 15:50:41 -0500
Message-ID: <CAG4d1reTZ8xcR8EO61Ap_VHsEdfgh19tk46o0ns+QFRAD=mPDQ@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: draft-ietf-sidr-as-migration@tools.ietf.org, sidr@ietf.org
Content-Type: multipart/alternative; boundary="001a1137b2a4f7ae1c050de4c1ac"
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/Oy5BztablMEYDDY9FM5xuBATbiQ>
Subject: [sidr] AD review and progressing draft-ietf-sidr-as-migration-02
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jan 2015 20:51:03 -0000

As usual, I have done an AD review of draft-ietf-sidr-as-migration-02 before
progressing the draft.

a) Language around draft-ietf-idr-as-migration is more tentative than is
appropriate
when that draft and this are going to be RFCs.  Please clean that up.

b) In Sec 3.1, it says

"If the route now shows up as originating
   from AS64500, any downstream peers' validation check will fail unless
   a ROA is *also* available for AS64500 as the origin ASN, meaning that
   there will be overlapping ROAs until all routers originating prefixes
   from AS64510 are migrated to AS64500."

I think the second AS64500 should be AS64510.

c) Sec 4:  I think the first paragraph about not standardizing the
draft-ietf-idr-as-migration
can be removed now.

d)  In Sec 5.3, please replace or augment "current BGPSec specification"
with the reference.  After all, this draft will be part of BGPSec too.


e) In draft-ietf-idr-as-migration, the case of handling AS migration
in iBGP sessions is also covered.  I assume that because it is iBGP
sessions, there is no work to be done for BGPsec.  Could you please
add a quick obvious statement to that effect?


Otherwise, this looks like a fine draft.  Please do update the draft
during IETF Last Call.  I'll progress it to IETF Last Call and put it
on the Feb 19 telechat.


Thanks for the good work,

Alia