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

From: <[email-masked]>
Date: Mon, 1 Oct 2012 10:55:52 +0200

Hi Shane,

Regarding diagrams, I was thinking of putting a figure in paragraph §2 to display how Ases are connected (it's clearly explained in text, but when reading, I needed to reread to remember who is what (and finally I drawn a figure by myself :).

For feature effect on ASPATH, it's clear with current diagrams and text.

Regards,

Stephane

-----Message d'origine-----
De : Shane Amante [mailto:[email-masked]] 
Envoyé : vendredi 28 septembre 2012 04:27
À : LITKOWSKI Stephane DTF/DERX
Cc : George, Wes; [email-masked]
Objet : Re: [Idr] New Version Notification for draft-ga-idr-as-migration-00.txt

Hi Stephane,

On Sep 27, 2012, at 6:19 AM, [email-masked] 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 : [email-masked] [mailto:[email-masked]] De la part de 
> George, Wes Envoyé : lundi 24 septembre 2012 15:11 À : [email-masked] Cc 
> : [email-masked] 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: [email-masked] [mailto:[email-masked]]
> Sent: Monday, September 24, 2012 9:08 AM
> To: George, Wes
> Cc: [email-masked]
> 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
> [email-masked]
> 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.
> 
> 

_________________________________________________________________________________________________________________________

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.