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

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

Ben:

 

I'm glad the argument has enlightened you.  We did debate BCP/PS so this
discussion brought back those discussions. 

 

On the changes:  The document "updates 4271".    The volunteering for saying
it updates RFC4271 - was to put a sentence in about that point.  RFC4271 has
timer knobs that affect the protocol.  These would be migration knobs that
would need to be added to RFC4271bis. 

 

I will chat with Alvaro (email already sent to request this point) regarding
"standardize" change and the "updates 4271". 

 

Sue 

 

-----Original Message-----
From: Idr [mailto:[e-mail]] On Behalf Of Ben Campbell
Sent: Wednesday, September 30, 2015 2:28 PM
To: Susan Hares
Cc: [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 12:03, Susan Hares wrote:

 

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

 

The concern that a BCP is not sufficient implies that a BCP has lower
standing than the standards track. IMO, that is not the case. But I'm more
convinced by the "doing this wrong can cause great harm" argument that you
made below. (Although a BCP can say that too.)

 

In any case, I'm not pushing for a change to BCP this late in the process. I
don't think it would be worth the the cost of rerunning process.

 

> 

> 

> 

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

 

This change would make me happier. I would be even happier if that 

included a couple of sentences in the introduction with a 

very-high-level description _how_ it updates 4271. (Doesn't the current 

version already say "updates 4271"?)

 

> 

> 

> 

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

 

Probably so. In the end it's up to Alvaro and the working group to do 

the Right Thing, even if that means telling me to take a hike. (Again, I 

cleared the discuss a while back. My happiness is not a requirement).

 

> 

> 

> 

> Sue

> 

> 

> 

> -----Original Message-----

> From: Ben Campbell [ <mailto:[e-mail]> mailto:[e-mail]]

> Sent: Wednesday, September 30, 2015 11:16 AM

> To: Susan Hares

> Cc: Jeffrey Haas;  <mailto:[e-mail]> [e-mail];
<mailto:[e-mail]> [e-mail]; The IESG;

>  <mailto:[e-mail]>
[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.

 

_______________________________________________

Idr mailing list

 <mailto:[e-mail]> [e-mail]

 <https://www.ietf.org/mailman/listinfo/idr>
https://www.ietf.org/mailman/listinfo/idr