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

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

Ben: 

 

The protocol standards for BGP consist of an overlay of many documents so
understanding the full weight of all these documents is a challenge.  Let me
give the high-order description of the argument. 

 

BGP is being created in three different working groups now:   BGP, BESS, and
SIDR.  We are working to allow people to be simple BGP (in most data
centers), VPN BGP or DC-to-DC BGP, and Secure BGP without requiring people
to do all of these points.  The SIDR (secure BGP) drafts that handle path
attributes in different ways.  We need this draft to standardize the
"de-Facto" BGP as-migrations for base BGP so that we do not break these
features when we do new features in basic BGP, BESS or SIDR.  The compromise
was to standardize the knobs as a protocol standard.  We discussed a long
time in the IDR/SIDR WG whether it would be sufficient to keep the knobs 

 

IHMO and in the WGs opinion, a BCP was insufficient.   Therefore, we were
willing to say  "it is necessary to standardize these de facto standards..."
- but this ran into comments earlier in the process because we noted these
were local BGP speakers functions that were not on the wire.   

 

I am willing to suggest the authors say "standardize" as long as this
agreement does not cause all the "no objections" to change to  with you and
Alvaro that this is acceptable.   I am willing to say it modifies RFC4271
(as Brian Haberman) discussed.  

  

The purpose of my discussion today is to attempt to inform you of the
balancing act we are doing on a protocol that handles intra-DC, inter-DC,
VPNs, DC-to-DC, and distribution of information.   It is a balancing act
that has kept the Internet running. 

 

Is the next step to chat with Alvaro? 

 

Sue 

 

-----Original Message-----
From: Ben Campbell [mailto:[e-mail]] 
Sent: Wednesday, September 30, 2015 11:16 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 9:22, Susan Hares wrote:

 

> 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.

 

Hi Sue,

 

Please note that I cleared the discuss some time ago. You and Alvaro can
certainly declare me in the rough, and I won't hold it against anyone. I
admit to not being a BGP expert, so it's possible this comes from some
misunderstanding on my part about what is and is not part of the standard.

 

I've attempted to compose some text, but the problem is, I really don't
understand what this draft is doing that people think is appropriate for a
PS. I do see that sections 3.3 and 4.2 use a fair bit of 2119 language. But
the introduction seems to pull pretty hard away from the standards track.

 

I'm guessing the pressure to make this a PS comes from the update of RFC
4271. It might help to add a paragraph that explicitly says something like
"Section(s) X update(s) RFC RFC 4271 by changing A, B, and C". I've tried to
tease that out of conversation, but it seems like people don't want to say
that.

 

More comments below that hopefully will illustrate my points of

confusion:

 

> 

> 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?

 

>You don't need a PS to say that common practices constrain future standards
work. That would be appropriate for >an informational or BCP.

>To recap, though, the following phrases in the above paragraph seem to
point away from PS:

 

>"discusses some existing commonly-used BGP mechanisms"

>"The deployment of these mechanisms do not need to interwork"

>"it is necessary to document these de facto standards... " (Unless you want
to change "document" to "standardize")

 

Ben: Let's put "it is necessary to standardize these de facto standards". 

 

>> 

>> 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?

 

>This paragraph is mostly neutral to my confusion, but here's a couple of 

>specifics:

 

>"The overall goal in doing so is to simplify operations through 

>consistent configurations"

> 

>That sounds like BCP material

 

Sue:  Simplify operations  == make it work without the potential of dropping
huge numbers of users. 

 

>"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."

> 

>That's the closest yet for arguing for standards track--but again if 

>this is not an issue of interoperability, it seems more like BCP stuff 

>(e.g. Don't do certain legal-for-the-standard things during migration or 

>bad things might happen"

 

Sue:  The issue of interoperability has two concepts.  Interoperability on
the wire between two peers, and making the whole AS work.  In this case, the
interoperability is "making the whole AS work."   I consider this section to
indicate the 

 

>> 

>> 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".

 

>You don't need a PS to say why something hurts.

>"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."

 

>I understand from the prior text that these migration mechanisms already 

>exist as non-standardized common practices, and that this draft does 

>_not_ attempt to standardize them. Is that a correct understanding? If 

>so, then it still sounds like a BCP to me.

>Thanks!

>Ben.

 

Ben - we need to try to standardize the knobs so we do not break things
between 3 groups standardizing a complex protocol.  We need to standardize
the migration mechanisms because unless we draw the line between migration
and attack in a standard, we cannot protect against the attack.