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

["Susan Hares" <[e-mail]>]

Ben: 

I would like to resolve this with you today.  Please see the comments below
and suggest text that will aid in resolving your concern.  Please propose
text as I am the shepherd of this document and WG chair.   

Sue 

----------------

Here's the introduction and a blow by blow comment.

1.  Introduction

   This draft discusses some existing commonly-used BGP mechanisms for
   Autonomous System Number (ASN) migration that are not formally part
   of the BGP4 [RFC4271] protocol specification.  These mechanisms are
   local to a given BGP Speaker and do not require negotiation with or
   cooperation of BGP neighbors.  The deployment of these mechanisms do
   not need to interwork with one another to accomplish the desired
   results, so slight variations between existing vendor implementations
   exist, and will not necessarily be harmonized due to this document.
   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.

Sue comment: 
 Ben- the first paragraph states the knobs are local to the BGP speaker. 
However, the knobs will impact the SIDR and other new BGP work. 
We want to not break thinks in the field - so we need to document these
knobs. 
Do you want to change something in this paragraph?  

Paragraph  2: 

   The migration mechanisms discussed here are useful to ISPs and
   organizations of all sizes, but it is important to understand the
   business need for these mechanisms and illustrate why they are so
   critical for ISPs' operations.  During a merger, acquisition or
   divestiture involving two organizations it is necessary to seamlessly
   migrate both internal and external BGP speakers from one ASN to a
   second ASN.  The overall goal in doing so is to simplify operations
   through consistent configurations across all BGP speakers in the
   combined network.  In addition, given that the BGP Path Selection
   algorithm selects routes with the shortest AS_PATH attribute, it is
   critical that the ISP does not increase AS_PATH length during or
   after ASN migration, because an increased AS_PATH length would likely
   result in sudden, undesirable changes in traffic patterns in the
   network.

Sue's comment on paragraph: This is the "so why do we care?"  statement.  
Do you want something here?

Paragraph 3:  

   By default, the BGP protocol requires an operator to configure a
   router to use a single remote ASN for the BGP neighbor, and the ASN
   must match on both ends of the peering in order to successfully
   negotiate and establish a BGP session.  Prior to the existence of
   these migration mechanisms, it would have required an ISP to
   coordinate an ASN change with, in some cases, tens of thousands of
   customers.  In particular, as each router is migrated to the new ASN,
   to avoid an outage due to ASN mismatch, the ISP would have to force
   all customers on that router to change their router configurations to
   use the new ASN immediately after the ASN change.  Thus, it becomes
   critical to allow the ISP to make this process a bit more asymmetric,
   so that it could seamlessly migrate the ASN within its network(s),
   but allow the customers to gradually migrate to the ISP's new ASN at
   their leisure, either by coordinating individual reconfigurations, or
   accepting sessions using either the old or new ASN to allow for truly
   asymmetric migration.

Sue's comment: This is "So why it hurts us if we do not do this". 



-----Original Message-----
From: Ben Campbell [mailto:[e-mail]] 
Sent: Wednesday, September 30, 2015 10:11 AM
To: Susan Hares
Cc: Jeffrey Haas; [e-mail]; [e-mail]; The IESG;
[e-mail]
Subject: Re: [Idr] Ben Campbell's Discuss on draft-ietf-idr-as-migration-06:
(with DISCUSS)

On 30 Sep 2015, at 8:09, Susan Hares wrote:

> Ben and Jeff:
>
> The purpose behind this draft is to document things that we needed to
> document things in the BGP protocol that SIDR's WG work was modify.   
> So the
> phrase Ben suggests is the key reason.
>
> "Additionally, this document makes changes to the standard protocol 
> behavior during a migration".
>
> However, I believe this text is what the following statement says.
>
> The text:
>
> This draft discusses some existing commonly-used BGP mechanisms for 
> Autonomous System Number (ASN) migration that are not formally part of 
> the BGP4 [RFC4271] protocol specification.
>
> Ben - can you let me know why this text is not sufficient?

That still seems to say "this draft discusses some extra-standard things
people do." Does those things? Does it vary standard procedures to allow for
those things? Something else?

Basically, I'm looking for clarity in the introduction about what the draft
standardizes, or what standards it changes.

Thanks!

Ben.