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

From: "Ben Campbell" <[email-masked]>
Date: Wed, 16 Sep 2015 10:57:09 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-idr-as-migration-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hopefully this is easy to resolve:

I am confused at the purpose of this draft. The introduction says "This
draft discusses some existing commonly-used BGP mechanisms" and "The
deployment of these mechanisms do not need to interwork with one another
to accomplish the desired results" These words suggest an informational
RFC, or maybe a BCP.

On the other hand, the draft is labeled as standards track, and updates
4271 (I assume due to Brian's previous comments). Sections 3.3 and 4.2
make heavy use of 2119 keywords in a way that sounds like it is defining
a standard (although I question whether these keywords in general impact
interoperability per se.)

So, I think there is a misalignment. If the intent is indeed to define a
standard, then I suggest the abstract and first paragraph of introduction
be rewritten to align with that. If not, then it shouldn't be standards
track nor update 4271.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 17 Sep 2015 03:38:54 +0000

On 9/16/15, 1:57 PM, "iesg on behalf of Ben Campbell"
<[email-masked] on behalf of [email-masked]> wrote:

Ben:

Hi!

>be rewritten to align with that. If not, then it shouldn't be standards

Yes, we¹ll clean up the Introduction.

Thanks!

Alvaro.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 16 Sep 2015 22:48:53 -0500

> Yes, we¹ll clean up the Introduction.

Good enough. I will clear.

Thanks!

Ben.

---

From: "George, Wes" <[email-masked]>
Date: Fri, 18 Sep 2015 10:16:42 -0400

Though I do not want to see this document delayed any more, I would
actually prefer not to change the introduction unless WG consensus
changes. This was DISCUSSed (and discussed) during evaluation of -03, and
this was my response to Pete at the time:

"This one is a little bit of a grey area. It doesn't strictly require
interoperability, because its functionality is local to a given BGP
speaker. It doesn't make changes to the BGP Protocol per se but it does
describe the current behavior of something implemented in multiple
vendor-specific methods so that desired behavior is documented for future
implementers. While it is optional, it does modify BGP's behavior from the
strict interpretation of the relevant RFCs, and that could technically be
considered a protocol change. Since it was a question as to which status
(PS vs info) was appropriate, we solicited WG consensus, and PS was the
recommendation.
Some of the language used is to reflect the intent to codify existing
behavior so that as future changes to BGP are contemplated (most notably,
BGPSec), this is considered part of the protocol so that it doesn't get
"broken"."

The abstract and intro attempt to acknowledge this fact. I'm open to
suggestions on wording changes to make it clearer, but I do think that the
text that is there is useful and should not be removed altogether.

Thanks,

Wes

>Yes, we¹ll clean up the Introduction.

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------

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.

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 18 Sep 2015 10:13:18 -0500

> text that is there is useful and should not be removed altogether.

I don't necessarily object to a PS that, for example, doesn't impact 
interoperability. It's just that the first paragraph as written feels 
like an explanation of why something _wouldn't_ be a PS. So even adding 
few sentences explaining why the working group wants this to be 
standards track in spite of that would be helpful, even if you otherwise 
keep the existing text.

Part of my concern is that lots of readers ignore headings and 
boilerplate. So if the body text seems to lead down a path that is 
different from what is said in the headings and boilerplate, at least 
some readers will misunderstand.

Thanks!

Ben.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 18 Sep 2015 12:02:37 -0400

Ben: 

Is next step is for us to propose some text?  

Sue 
-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: Friday, September 18, 2015 11:13 AM
To: George, Wes
Cc: [email-masked]; [email-masked]; The IESG;
[email-masked]; [email-masked]
Subject: Re: [Idr] Ben Campbell's Discuss on draft-ietf-idr-as-migration-06:
(with DISCUSS)

On 18 Sep 2015, at 9:16, George, Wes wrote:

> changes. This was DISCUSSed (and discussed) during evaluation of -03, 
> and this was my response to Pete at the time:
>
> speaker. It doesn't make changes to the BGP Protocol per se but it 
> does describe the current behavior of something implemented in 
> multiple vendor-specific methods so that desired behavior is 
> documented for future implementers. While it is optional, it does 
> modify BGP's behavior from the strict interpretation of the relevant 
> RFCs, and that could technically be considered a protocol change. 
> Since it was a question as to which status (PS vs info) was 
> appropriate, we solicited WG consensus, and PS was the recommendation.
> behavior so that as future changes to BGP are contemplated (most 
> notably, BGPSec), this is considered part of the protocol so that it 
> doesn't get "broken"."
>
> suggestions on wording changes to make it clearer, but I do think that 
> the text that is there is useful and should not be removed altogether.

I don't necessarily object to a PS that, for example, doesn't impact
interoperability. It's just that the first paragraph as written feels like
an explanation of why something _wouldn't_ be a PS. So even adding few
sentences explaining why the working group wants this to be standards track
in spite of that would be helpful, even if you otherwise keep the existing
text.

Part of my concern is that lots of readers ignore headings and boilerplate.
So if the body text seems to lead down a path that is different from what is
said in the headings and boilerplate, at least some readers will
misunderstand.

Thanks!

Ben.

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 21 Sep 2015 10:44:40 -0500

> Is next step is for us to propose some text?

I'm sure it is. Unfortunately, I am stuck in all-day meetings all this 
week. I will try to propose some text when I get a few free cycles--but 
if other people have text ideas please do not wait for me.

Ben.

> like
> boilerplate.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 22 Sep 2015 18:17:57 +0000

On 9/18/15, 11:13 AM, "Ben Campbell" <[email-masked]> wrote:

Ben:

Hi!

>standards track in spite of that would be helpful, even if you otherwise

As Wes explained, a big (if not all) the motivation for the WG to make
this document a PS lies in other work that interworks closely with the
AS_PATH attribute, which is what is changed in the mechanisms specified
here.  Specifically, BGPSec is the major one.

After reading the Introduction again, I find this piece of text that (to
me) seems to address what you want:

   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.

The only thing that this text doesn¹t explicitly mention is BGPSec.  There
is a companion document that specifically addresses the sidr side:
https://tools.ietf.org/html/draft-ietf-sidr-as-migration

We could add an Informative reference to BGPSec ‹ but with the -sidr-
draft I think we¹re covered.

Thanks!

Alvaro.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 28 Sep 2015 14:38:15 -0500

>  of these very widely used ASN migration mechanisms.

At this point, I think this is strictly an editorial gripe--but that 
text was part of what made me wonder about the intent. Language like 
"Document these de facto standards" led me down the "document things 
people are doing" vs "creating an IETF standard".

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 28 Sep 2015 15:40:33 -0400

Ben: 

In IDR and SIDR, sometimes we are catching up and standardizing what people are doing in the real-world so that when we advance the standard (SIDR is advancing the standard in this case), the whole set of code is interoperable. 

Sue 

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Monday, September 28, 2015 3:38 PM
To: Alvaro Retana
Cc: George, Wes; [email-masked]; [email-masked]; The IESG; [email-masked]; [email-masked]
Subject: Re: Ben Campbell's Discuss on draft-ietf-idr-as-migration-06: (with DISCUSS)

On 22 Sep 2015, at 13:17, Alvaro Retana (aretana) wrote:

>> like an explanation of why something _wouldn't_ be a PS. So even 
>> adding few sentences explaining why the working group wants this to 
>> be standards track in spite of that would be helpful, even if you 
>> otherwise keep the existing text.
>
> AS_PATH attribute, which is what is changed in the mechanisms 
> specified here.  Specifically, BGPSec is the major one.
>

At this point, I think this is strictly an editorial gripe--but that text was part of what made me wonder about the intent. Language like "Document these de facto standards" led me down the "document things people are doing" vs "creating an IETF standard".

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 28 Sep 2015 14:42:59 -0500

On 28 Sep 2015, at 14:40, Susan Hares wrote:

> Ben:
>
> In IDR and SIDR, sometimes we are catching up and standardizing what 
> people are doing in the real-world so that when we advance the 
> standard (SIDR is advancing the standard in this case), the whole set 
> of code is interoperable.

I have no objection to that.

Perhaps something like "This draft standardizes existing de-facto 
standards..." or "This draft standardizes existing behaviors..." ?

> Cc: George, Wes; [email-masked]; 
> [email-masked]; The IESG; [email-masked]; [email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 29 Sep 2015 16:55:51 -0400

Ben,

On Mon, Sep 28, 2015 at 02:42:59PM -0500, Ben Campbell wrote:
> >In IDR and SIDR, sometimes we are catching up and standardizing
> >what people are doing in the real-world so that when we advance
> >the standard (SIDR is advancing the standard in this case), the
> >whole set of code is interoperable.
> 

The draft documents existing behaviors. :-)

Part of why the document doesn't specifically intend to recommend a specific
way of doing things is that once you get outside of the AS applying these
mechanisms, you don't know that the mechanisms have been used.  The
mechanisms try to be a good black-box as far as the Internet routing system
as a whole is concerned.  

Where the details are important are inside the AS.  Which mechanism makes
the most sense for a provider has a lot of contributing factors, including
which vendor is common and what types of changes are necessary to not only
accommodate the migration, but also preserve desired routing properties as
well.

I suspect a small book could be written on migrations and strategies.  Such
a small book isn't really appropriate for IETF standards.

-- Jeff

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 29 Sep 2015 16:27:46 -0500

> accommodate the migration, but also preserve desired routing 

So I'm confused again. That sounds like an argument for an informational 
RFC, or maybe even a BCP.

I would understand saying something to the effect of "This document 
standardizes a set of common practices, so that implementers will be 
discouraged from implementing new methods that might break 
interoperability/routing properties". But if people don't want to use 
words like "standardize", then it still seems like the introduction is 
inconsistent with the intended status.

> a small book isn't really appropriate for IETF standards.

Would it be appropriate for an informational RFC or BCP?

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 29 Sep 2015 18:13:47 -0400

On Tue, Sep 29, 2015 at 04:27:46PM -0500, Ben Campbell wrote:
> So I'm confused again. That sounds like an argument for an
> informational RFC, or maybe even a BCP.

IMO, the status is *fine* and is really the best mapping we're going to get.
There is one part practice, one part deployment wisdom and - the thing being
truly documented - the behavior changes done in the protocol within the AS
undergoing migration.

The alternative is to ask for a status of "this is weird and doesn't really
fit".

> Would it be appropriate for an informational RFC or BCP?

I think it'd make a fine book. I think it'd make a poor RFC.
Not to mention the thought of taking the resulting material and running it
through the IETF review and editorial process would be maddening.

-- Jeff

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 29 Sep 2015 17:18:55 -0500

> The alternative is to ask for a status of "this is weird and doesn't 

So I think maybe the problem is that part of the draft defines standards 
and part doesn't. Short of splitting them (which I don't think makes 
sense this late in the process, one way of fixing the issue would be to 
change or add text to paragraph 1 in the introduction to say something 
to the effect of "Additionally, this document makes changes to the 
standard protocol behavior during a migration".

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Sep 2015 09:09:17 -0400

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? 

Sue 

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, September 29, 2015 6:19 PM
To: Jeffrey Haas
Cc: Susan Hares; [email-masked]; [email-masked]; The IESG;
[email-masked]
Subject: Re: [Idr] Ben Campbell's Discuss on draft-ietf-idr-as-migration-06:
(with DISCUSS)

On 29 Sep 2015, at 17:13, Jeffrey Haas wrote:

> There is one part practice, one part deployment wisdom and - the thing 
> being truly documented - the behavior changes done in the protocol 
> within the AS undergoing migration.
>
> The alternative is to ask for a status of "this is weird and doesn't 
> really fit".

So I think maybe the problem is that part of the draft defines standards and
part doesn't. Short of splitting them (which I don't think makes sense this
late in the process, one way of fixing the issue would be to change or add
text to paragraph 1 in the introduction to say something to the effect of
"Additionally, this document makes changes to the standard protocol behavior
during a migration".

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 30 Sep 2015 09:11:21 -0500

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

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 30 Sep 2015 14:12:07 +0000

+1

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

Thanks!

Ben.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Sep 2015 10:22:06 -0400

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:[email-masked]] 
Sent: Wednesday, September 30, 2015 10:11 AM
To: Susan Hares
Cc: Jeffrey Haas; [email-masked]; [email-masked]; The IESG;

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

> "Additionally, this document makes changes to the standard protocol 
> behavior during a migration".
>
> Autonomous System Number (ASN) migration that are not formally part of 
> the BGP4 [RFC4271] protocol specification.
>

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.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 30 Sep 2015 10:16:05 -0500

> 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 

> Sue

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

> 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

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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Sep 2015 13:03:20 -0400

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:[email-masked]] 
Sent: Wednesday, September 30, 2015 11:16 AM
To: Susan Hares
Cc: Jeffrey Haas; [email-masked]; [email-masked]; The IESG;

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

confusion:

>> the BGP4 [RFC4271] protocol specification.  These mechanisms are local 

>> to a given BGP Speaker and do not require negotiation with or 

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

>> Ben- the first paragraph states the knobs are local to the BGP 

>> speaker.

>> We want to not break thinks in the field - so we need to document 

>> these knobs.

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

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

> >Sue's comment on paragraph: This is the "so why do we care?"  

> >statement.

>That sounds like BCP material

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

>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 

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

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 30 Sep 2015 13:27:38 -0500

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

> (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"?)

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

>>> of
>>> or
>> standards

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Sep 2015 14:44:02 -0400

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:[email-masked]] On Behalf Of Ben Campbell
Sent: Wednesday, September 30, 2015 2:28 PM
To: Susan Hares
Cc: [email-masked]; [email-masked]; The IESG;
[email-masked]

> 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

> BGP is being created in three different working groups now:   BGP, 

> BESS, and

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

> 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

> 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

> From: Ben Campbell [ <mailto:[email-masked]> mailto:[email-masked]]

> Cc: Jeffrey Haas;  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked]; The IESG;

>  <mailto:[email-masked]>

> Subject: Re: [Idr] Ben Campbell's Discuss on 

> draft-ietf-idr-as-migration-06:

> 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

> 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

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

>>> the BGP4 [RFC4271] protocol specification.  These mechanisms are 

>>> local

>>> results, so slight variations between existing vendor 

>>> implementations

>>> compare the AS_PATH attribute can do so without inhibiting the use 

>> To recap, though, the following phrases in the above paragraph seem 

>> to

>> "it is necessary to document these de facto standards... " (Unless 

>> you want

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

> standards".

>>> divestiture involving two organizations it is necessary to 

>>> seamlessly

>>> after ASN migration, because an increased AS_PATH length would 

>>> likely

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

> Sue:  Simplify operations  == make it work without the potential of 

> dropping

>> "it is critical that the ISP does not increase AS_PATH length during 

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

> 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

>>> customers.  In particular, as each router is migrated to the new 

>>> ASN,

>>> all customers on that router to change their router configurations 

>>> to

>>> critical to allow the ISP to make this process a bit more 

>>> asymmetric,

>>> their leisure, either by coordinating individual reconfigurations, 

>>> accepting sessions using either the old or new ASN to allow for 

>>> truly

>> required an ISP to coordinate an ASN change with, in some cases, tens 

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

>> already

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

>> If

> 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

Idr mailing list

 <mailto:[email-masked]> [email-masked]

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