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

["Ben Campbell" <[e-mail]>]

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