Re: [Idr] New Version Notification for draft-ga-idr-as-migration-00.txt

Shane Amante <shane@castlepoint.net> Fri, 28 September 2012 02:27 UTC

Return-Path: <shane@castlepoint.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15DA21F8530 for <idr@ietfa.amsl.com>; Thu, 27 Sep 2012 19:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRX+wIl5mWGX for <idr@ietfa.amsl.com>; Thu, 27 Sep 2012 19:27:13 -0700 (PDT)
Received: from mail.tcb.net (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id F3C4621F84CE for <idr@ietf.org>; Thu, 27 Sep 2012 19:27:12 -0700 (PDT)
Received: from mbpw.castlepoint.net (216-160-173-224.hlrn.qwest.net [216.160.173.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id 86E48F5; Thu, 27 Sep 2012 20:27:09 -0600 (MDT)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\))
From: Shane Amante <shane@castlepoint.net>
In-Reply-To: <18209_1348748389_50644465_18209_14333_1_EEE55384044474429A926C625D0FCC81041C96CC71@PUEXCB2F.nanterre.francetelecom.fr>
Date: Thu, 27 Sep 2012 20:27:13 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <A6A2F829-6028-483D-A0C4-3DA596AD5DF6@castlepoint.net>
References: <20120924130811.20935.26346.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD59235F961AA5@PRVPEXVS15.corp.twcable.com> <18209_1348748389_50644465_18209_14333_1_EEE55384044474429A926C625D0FCC81041C96CC71@PUEXCB2F.nanterre.francetelecom.fr>
To: stephane.litkowski@orange.com
X-Mailer: Apple Mail (2.1498)
Cc: "idr@ietf.org" <idr@ietf.org>, "George, Wes" <wesley.george@twcable.com>
Subject: Re: [Idr] New Version Notification for draft-ga-idr-as-migration-00.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 28 Sep 2012 02:27:13 -0000

Hi Stephane,

On Sep 27, 2012, at 6:19 AM, stephane.litkowski@orange.com wrote:
> Hi Wes, and Shane,
> 
> Good idea to describe such migration situations and required features, as you mention, not all implementations have these features.
> I pretty agree on what is described but I think more diagrams would be helpful to clarify.

Could you clarify what more diagrams might help with?  We tried to simplify the diagram to depict the effects on the AS_PATH attribute as it traverse ASN's with these features enabled.  Hopefully, we struck the right balance there, although suggestions are welcome on how we could improve them.


> The main point is that today you are only taking into account (but it's just a first shot of draft :) ) the AS merge case, but AS renumbering case is also very interresting (we done it :) ) as it may require the "allow-as in" or "as-loop" feature and the scenario is a bit difference as you have to manage inter AS gateways (old and new AS).
> It would be helpful to have the draft as PS in order to have such features as MUST or SHOULD within BGP implementations.

That's a good point.  Due to the short time we had to write & publish this draft, we only could document what's in the current draft.  I do plan to add some other ASN migration features in a next rev of this draft, but had not considered those two.  Thanks for the suggestion; we'll see what we can do.  


> PS : Being able to change AS number in router configuration without deleting all BGP config would be helpful also :)

Fortunately, some vendors got this right.  

-shane


> Best Regards,
> 
> Stephane
> 
> 
> -----Message d'origine-----
> De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la part de George, Wes
> Envoyé : lundi 24 septembre 2012 15:11
> À : idr@ietf.org
> Cc : shane@castlepoint.net
> Objet : [Idr] FW: New Version Notification for draft-ga-idr-as-migration-00.txt
> 
> New draft for your review. This is related to a discussion we've been having in SIDR, but since this procedure is not specific to SIDR, we thought it best to document the procedure and features used during an ASN migration here, and then SIDR will need to simply determine the best way to support this.
> 
> This is currently an informational ID, but could potentially be a PS as well.
> 
> Thanks,
> 
> Wes George and Shane Amante
> 
> 
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Monday, September 24, 2012 9:08 AM
> To: George, Wes
> Cc: shane@level3.net
> Subject: New Version Notification for draft-ga-idr-as-migration-00.txt
> 
> 
> A new version of I-D, draft-ga-idr-as-migration-00.txt has been successfully submitted by Wesley George and posted to the IETF repository.
> 
> Filename:        draft-ga-idr-as-migration
> Revision:        00
> Title:           Autonomous System (AS) Migration Features and Their Effects on the BGP AS_PATH Attribute
> Creation date:   2012-09-24
> WG ID:           Individual Submission
> Number of pages: 10
> URL:             http://www.ietf.org/internet-drafts/draft-ga-idr-as-migration-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-ga-idr-as-migration
> Htmlized:        http://tools.ietf.org/html/draft-ga-idr-as-migration-00
> 
> 
> Abstract:
>   This draft discusses common methods of managing an ASN migration
>   using some BGP features that while commonly-used are not formally
>   part of the BGP4 protocol specification and may be vendor-specific in
>   exact implementation.  It is necessary to document these de facto
>   standards to ensure that they are properly supported in BGPSec.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
>