Subject: [Idr] Adrian Farrel's Abstain on draft-ietf-idr-as-migration-03: (with COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 19 Feb 2015 06:25:42 -0800

Adrian Farrel has entered the following ballot position for
draft-ietf-idr-as-migration-03: Abstain

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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I cannot support the publication of this document in its current form.
My issues could possibly be resolved, but I do not think that minor
edits would be enough, and I suspect that after the work to produce 
the document and considering WG and IETF consensus, there will be 
enthusiasm to start again. resolving my concerns would, I think,
require the document to return to the working group.

Since I do not feel strongly enough that this document MUST NOT be
published in this form, I will not use my Discuss to insist on 
changes.

The notes below are provided to help you understand my reasoning and,
if you are minded to agree with me, to help you think about how to 
update the document.

(Some of the nits come from a "training review" done by Alvaro.)

The documentseems to address four topics:
- Requirements for and circumstances of AS migration
- Behavior needed from a BGP system when migrating AS numbers
- Mechanisms that a BGP implementation can use to provide the
  behavior
- Description of the mechanisms and configuration options contained in
  specific implementations

As Alvaro wrote:

> o The Introduction is very tentative about the purpose: it wants to
> document de facto standards for future implementations and so
> that new features (BGPSec) take them into consideration..but it is
> not expecting all implementation to follow exactly (at least not the
> existing ones).  My question is: should this be Informational instead
> of Standard?

I would say that the first two bullets are classic descriptive 
requirements text. They are good to publish as Informational.

The third bullet is somewhat suspect. Maybe it is an advisory appendix,
but the list of ways to provide the function is unbounded and there is
no requirement for interoperability. I am not sure that publshing this
information is a great benefit. Maybe it is not harmful although it 
might tend to reduce innovation and give vendors and operators
expectations about mechanisms that should be used within
implementations.

I find the final bullet very suspect. It goes beyond an implementation
report and enters into the world of sales. While the document makes no
explicit analysis of the pros and cons of the different implementations,
described, there is a lot between the lines. Furthermore, by not
documenting the mechanisms in other implementations, the document gives
the false impression that the three implementations described are the
benchmark for AS migration. It might be possible to move this material 
to an appendix or a separate implementation document, but as the authors
note, much or all of the information can be found on the websites of the
companies concerned, and I think that is where it should stay.

[Please note that twice, while typing this, I wrote "AD migration". That
may be a better solution to all of our problems!]

Here are the minor comments and nits...

o "ISPs bill customers based on the 95th percentile of the greater
  of the traffic sent or received, over the course of a 1-month
  period, on the customer's access circuit."  
  
  This information is not needed and may change at any time after the
  publication of this document. You have made the point about
  utilization: you can drop this text.

o The use case figres, Fig 1 and 2, show customers C and D. When
  explaining the features, CE-A and CE-B are used instead.  
  
  It would make it easier to follow if the same names were used.

o Potential loops!  Using "local-as no-prepend replace-as" results in 
  eliminating an ASN from the AS_PATH (in the example, the Old_ADN
  64510 is eliminated). If other routers in ISP B have not been migrated
  yet (very real possibility) then they may accept Updates that already
  went through their ASN (64510) resulting in potential loops.
  
  To be fair, the text suggests that ISP B has been migrated to the
  New_ASN before applying the "local-as no-prepend replace-as" config,
  but I think that it would be important to describe the potential 
  risk of using this feature - either as an Operational Consideration
  or in the Security section.

o The text uses "MY ASN" to indicate the ASN number in the BGP
  Open Message.  However, (1) there is no reference to rfc4271 so that
  the reader understand what they're talking about, and (2) the field in
  the Open message is called "My Autonomous System" (not MY ASN).
  This shows up in 3.3 and 4.2.

o Also in 3.3 (and 4.2), the Error Message "BAD PEER AS" is mentioned..
  Again, no reference and wrong name.  The name used in rfc4271 is
 "Bad Peer AS".  

o Other rfc4271 related nits..  The draft talks about "updates", but the
  official name is "UPDATE".  Yes, maybe OCD, but I think it is 
  important to be clear about what is being specified.  
  
  In some cases the use is mixed: "..it MUST process the update as
  normal, but it MUST append the configured ASN in the AS_PATH attribute
  before advertising the UPDATE".

o In 3.3 (last paragraph) the authors talk about the CLI implementation.

   While the exact command syntax is an implementation detail beyond the
   scope of this document, the following consideration may be helpful
   for implementers

  Suggest to stay out of this completely. It is nested "may" and that 
  really calls its value into question.

o Because the external features (Section 3) assumes that the AS being
  migrated is already using the New_ASN before using local-as, I would
  like to see the internal features (Section 4) be discussed first in 
  the text to keep a logical flow.

o 4.1: s/typically to PE devices/typically connected to PE devices

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 19 Feb 2015 09:48:12 -0500

Alvaro and Adrian: 

It's nice to have you chime in on this draft.  As IDR chair, may I ask we remove the draft from the IESG agenda today.  I'll need some unpacking of your reasoning. 

Are you looking for a major rewrite of this draft or to scrap this effort?  

If you are looking to scrap the effort, I need additional details on why.  It has been discussed by SIDR, Grow and IDR to be valuable for the BGP deployments. This draft provides reasoning for the SIDR work on AS migration.  Your reasoning is that the "mechanism that BGP implementation can use to provide the behavior" below .. seems to suggest it should not be documented.  New BGP implementations are arising in DC, Mobile backend networks, and Carriers that utilize these features so interoperable features are necessary. 

If you are looking for a complete rewrite, I'm happy to work with you, Alvaro, Alia and the authors to find a new acceptable form of the draft(s). 

My understanding is that you want to split to:

Informational Draft: 
- Requirements for and circumstances of AS migration, 
- Behavior needed from a BGP system when migrating AS numbers, 

Mechanism (RFC) 
- Mechanisms that a BGP implementation can use to provide the
  Behavior [mechanism in RFC] 
- Description of the mechanisms and configuration options contained in
  specific implementations [mechanism draft appendix, non-normative]  

If this is your desire, I will be happy to take this back to the authors and the WG to create this draft. 

Sue  

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Thursday, February 19, 2015 9:26 AM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Adrian Farrel's Abstain on draft-ietf-idr-as-migration-03: (with COMMENT)

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

I cannot support the publication of this document in its current form.
My issues could possibly be resolved, but I do not think that minor edits would be enough, and I suspect that after the work to produce the document and considering WG and IETF consensus, there will be enthusiasm to start again. resolving my concerns would, I think, require the document to return to the working group.

Since I do not feel strongly enough that this document MUST NOT be published in this form, I will not use my Discuss to insist on changes.

The notes below are provided to help you understand my reasoning and, if you are minded to agree with me, to help you think about how to update the document.

As Alvaro wrote:

> document de facto standards for future implementations and so that new 
> features (BGPSec) take them into consideration..but it is not 
> expecting all implementation to follow exactly (at least not the 

I would say that the first two bullets are classic descriptive requirements text. They are good to publish as Informational.

The third bullet is somewhat suspect. Maybe it is an advisory appendix, but the list of ways to provide the function is unbounded and there is no requirement for interoperability. I am not sure that publshing this information is a great benefit. Maybe it is not harmful although it might tend to reduce innovation and give vendors and operators expectations about mechanisms that should be used within implementations.

I find the final bullet very suspect. It goes beyond an implementation report and enters into the world of sales. While the document makes no explicit analysis of the pros and cons of the different implementations, described, there is a lot between the lines. Furthermore, by not documenting the mechanisms in other implementations, the document gives the false impression that the three implementations described are the benchmark for AS migration. It might be possible to move this material to an appendix or a separate implementation document, but as the authors note, much or all of the information can be found on the websites of the companies concerned, and I think that is where it should stay.

[Please note that twice, while typing this, I wrote "AD migration". That may be a better solution to all of our problems!]

  

  

o Also in 3.3 (and 4.2), the Error Message "BAD PEER AS" is mentioned..
  Again, no reference and wrong name.  The name used in rfc4271 is  "Bad Peer AS".

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 19 Feb 2015 09:48:12 -0500

Alvaro and Adrian: 

Informational Draft: 

Mechanism (RFC) 

Sue

---

From: Alia Atlas <[email-masked]>
Date: Thu, 19 Feb 2015 09:54:04 -0500

Hi Sue,

On Thu, Feb 19, 2015 at 9:48 AM, Susan Hares <[email-masked]> wrote:

> Alvaro and Adrian:
>
> It's nice to have you chime in on this draft.  As IDR chair, may I ask we
> remove the draft from the IESG agenda today.  I'll need some unpacking of
> your reasoning.
>

I have removed it from today's telechat.

> Are you looking for a major rewrite of this draft or to scrap this effort?

I would like to see a major rewrite - though not as strongly as Alvaro and
Adrian feel.

> If you are looking to scrap the effort, I need additional details on why.
> It has been discussed by SIDR, Grow and IDR to be valuable for the BGP
> deployments. This draft provides reasoning for the SIDR work on AS
> migration.  Your reasoning is that the "mechanism that BGP implementation
> can use to provide the behavior" below .. seems to suggest it should not be
> documented.  New BGP implementations are arising in DC, Mobile backend
> networks, and Carriers that utilize these features so interoperable
> features are necessary.
>
> If you are looking for a complete rewrite, I'm happy to work with you,
> Alvaro, Alia and the authors to find a new acceptable form of the draft(s).
>

I'm far from convinced that it needs to be two drafts.  I would like to see
it more clearly divided into
clear requirements, specific required behavior, and leaving out the vendor
specifics (in an appendix
if truly necessary).

Regards,
Alia

If this is your desire, I will be happy to take this back to the authors
> and the WG to create this draft.
>
> Sue
>
> My issues could possibly be resolved, but I do not think that minor edits
> would be enough, and I suspect that after the work to produce the document
> and considering WG and IETF consensus, there will be enthusiasm to start
> again. resolving my concerns would, I think, require the document to return
> to the working group.
>
> published in this form, I will not use my Discuss to insist on changes.
>
> The notes below are provided to help you understand my reasoning and, if
> you are minded to agree with me, to help you think about how to update the
> document.
>
> but the list of ways to provide the function is unbounded and there is no
> requirement for interoperability. I am not sure that publshing this
> information is a great benefit. Maybe it is not harmful although it might
> tend to reduce innovation and give vendors and operators expectations about
> mechanisms that should be used within implementations.
>
> documenting the mechanisms in other implementations, the document gives the
> false impression that the three implementations described are the benchmark
> for AS migration. It might be possible to move this material to an appendix
> or a separate implementation document, but as the authors note, much or all
> of the information can be found on the websites of the companies concerned,
> and I think that is where it should stay.
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 19 Feb 2015 09:54:04 -0500

Hi Sue,

Regards,
Alia

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 19 Feb 2015 15:05:52 +0000

On 2/19/15, 9:54 AM, "Alia Atlas" <[email-masked]<mailto:[email-masked]>> wrote:

Sue:

Hi!

I'm far from convinced that it needs to be two drafts.  I would like to see it more clearly divided into
clear requirements, specific required behavior, and leaving out the vendor specifics (in an appendix
if truly necessary).

I agree with that.  In the comments that I sent Wes (on the list) I wrote:

===
What I think would have been nice is to describe the migration scenario and functionality independent of the existing feature names first..and then say “BTW, the cisco features that do this are xxx..for Juniper yyy, etc.”.   Talking about specific features creates expectations that further implementations will do the exact same thing (specially when config snippets are included): as in the functionality documented at the cisco site (for example).
===

Sorry I wasn’t paying enough attention before and this came so late in the process.

Alvaro.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 19 Feb 2015 15:05:52 +0000

Sue:

Hi!

===

Alvaro.

---

From: "George, Wes" <[email-masked]>
Date: Thu, 19 Feb 2015 19:29:24 -0500

Snipped where possible.
My comments below inline with WG]

On 2/19/15, 9:25 AM, "Adrian Farrel" <[email-masked]> wrote:

>The document seems to address four topics:

WG] See my response to Pete's DISCUSS.

Frankly, this document exists because we got told early on in the life of
the SIDR document that we needed to standardize the behavior (in IDR)
before we could really tell SIDR that they weren't allowed to break it
with BGPSec and propose a solution. That made sense to me, because while
BGPSec is the current concern, there's no guarantee that there won't be
other changes to BGP in the future that might need to take this behavior
into account. So we split the AS migration stuff into its own document,
and the SIDR document focuses exclusively on how to make BGPSec work with
AS Migration. I'm not sure what that really translates to from a document
status (or even a content) perspective between these two parallel drafts.
I'm just going with consensus thus far.

>expectations about mechanisms that should be used within

WG] As noted elsewhere, this is a locally specific implementation, so
interop isn't required. Consistency of behavior is useful, but I'm not
convinced that we're going to be able to force that by being more generic
and more prescriptive, nor am I convinced that there is much innovation to
be had here such that we'd stifle it.
IETF has a decision point here: do we document the desired behavior as if
no implementations currently exist and then reserve any acknowledgment of
the existing implementations for an implementation report or appendix, or
do we acknowledge that we're documenting existing behaviors as something
like the union of the features provided across the different
vendor-specific implementations? There is precedent for documenting one
vendor's implementation of something when they want to make it available
to other implementers, but I'm not aware of any precedent for this when
it's multiple vendors such as this document, especially when none of the
vendors in question are authors.
IMO, the problem with the first choice is that we now find ourselves in
the situation where we are essentially telling vendors that their existing
implementations are not compliant with our ex post facto standard, and I'm
not sure that has any real benefit. As people are fond of saying, IETF
isn't the protocol police, but when customers ask vendors for support of a
certain feature, if there's an RFC that documents it, they often refer to
it in shorthand as "support for RFCnnnn" with the expectation that it will
be fully supported without having to explain every possible part of the
desired feature or behavior.
This draft took a more pragmatic view, "...Rough consensus and running
code." and all that...

>companies concerned, and I think that is where it should stay.

WG] IDR requires implementation/interop reports. Given that this is a bit
of a "cart before horse" situation, where we are documenting existing
implementations, I think some mention of the vendor-specific
implementations is necessary. The info can be found on the websites, but
given that at least one of those links had gone 404 in the time since the
initial draft was written and had to be updated, I do not hold much hope
that the URIs will actually be useful references as this document ages.
Whether that means we need more info in the document instead is open for
discussion.
As to "you used C and J in your examples but not A or H or..." - There are
representatives from all of those vendors present at IETF and AFAIK
participating in IDR, and they are more than welcome to contribute text to
address the concern around unequal discussion of each vendor-specific
implementation within the draft. No slight or endorsement was intended.
That said, I am not convinced that a complete documentation of every
vendor's flavor of this is useful or appropriate, and your comments seem
to agree.
The authors chose examples based on what we were familiar with. Already we
struggled with the issue of terminology, because I got reviews from folks
at both C and J who got cross if I used the other's term or didn't
document the behavior exactly as they implemented it, but it didn't make
sense to invent completely new terms just to avoid using one of the
pre-existing terms. Additionally, because this behavior was initially
vendor-specific, there is a non-trivial amount of overlap between
implementations. Basically, an operator looked at a feature provided by
one vendor and told another either "do it like that" or "do it mostly like
that, but give me this additional optimization". We tried to split the
difference with the normative text. So I guess the question is whether or
not this document stands alone/is useful with just the normative text and
much less in the way of examples to tie it to the existing
implementations. Randy's comments seem to say yes (though he was
commenting more specifically on the business drivers). I will go with
consensus on the matter.

>Here are the minor comments and nits...

WG] These will be addressed.

Thanks,

Wes

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: "George, Wes" <[email-masked]>
Date: Thu, 19 Feb 2015 19:29:24 -0500

Snipped where possible.

Thanks,

Wes

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 20 Feb 2015 15:34:22 +0000

On 2/19/15, 7:29 PM, "George, Wes" <[email-masked]> wrote:

Wes:

Hi!

Hard to snip stuff out..

..

>>. . .

The problem I have with the current text is that it basically reads: ³we
want the behavior to be like cisco¹s local-as² (as an example).  While
(not wearing any hats) I love cisco¹s implementation of local-as, I¹m left
with the sense that others are better off just reading the on-line
documentation..which may of course change at any point.

If you really want the behavior of (todays) cisco¹s local-as, then
document its current behavior, and ack the existing implementations in an
appendix.  This is similar to the ³first choice² you mentioned above in
that the description of the behavior is separate from the commercial
implementation, even if they do the same thing.

In the draft you focused on the local-as (and options) functionality in
Section 3 and 'Internal BGP Alias' in Section 4.  I think you were right
in describing the internal and external behaviors separately, which I
think means that the functionality is not really the union of features,
but two independent features.

>commenting more specifically on the business drivers). I will go with

I think examples are ok (in an appendix), specially if the base of the
behavior is an already existing and deployed feature, as it is here.

Personally, I would stay away form trying to show examples for all
possible variations and all possible vendors, and focus on the specific
functionality you¹re addressing.

Thanks!

Alvaro.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 20 Feb 2015 15:34:22 +0000

Wes:

Hi!

Hard to snip stuff out..

..

Thanks!

Alvaro.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 22 Feb 2015 21:24:18 -0000

Sue,

It's good of you and Wes to try to address the concerns expressed in my Abstain. It reflects well on your concern to do the right thing by the IETF.

However, I abstained precisely because I did not think you should try to resolve my concerns. I believe that an attempt to do so will change significantly what the WG wanted to publish, and will cause a huge amount of churn for minimal progress.

So...

> Are you looking for a major rewrite of this draft or to scrap this effort?

Neither. I am looking to get out of the way of publication of the document.
As I recall, addressing Pete's Discuss would have been enough to have had the document approved on Thursday's IESG call.

> My understanding is that you want to split to:
[snip]

No, I don't want to split anything.

It's true that I don't want to have anything to do with this document in its current form. But also true that I don't ask for any changes to be made.

The IESG writes (in its advice to itself [http://www.ietf.org/iesg/voting-procedures.html])

|"Abstain" means "I cannot support sending this document forward." There
|are two obvious reasons an AD might post this ballot position: 
|- I am so strongly opposed to the document that I am unwilling to
|  "discuss". (Note that this should be very unusual.)
|- I oppose this document but understand that others differ and am
|  not going to stand in the way of the others.
|It is normal good practice for an AD to enter a Comment that explains the
|reason for their Abstain position.

I took the second bullet and gave my reasons.

That means that I am not sure that it is fruitful to discuss my reasons with me unless I have suddenly shed light in a corner that you or the authors believe now needs attention. 

Pip-pip,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 22 Feb 2015 21:24:18 -0000

Sue,

So...

[snip]

Pip-pip,
Adrian

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 24 Feb 2015 13:56:42 -0500

Adrian,

On Thu, Feb 19, 2015 at 06:25:42AM -0800, Adrian Farrel wrote:
[...]
> expectations about mechanisms that should be used within

Wes already covered a primary motivation for having this document in the
first place: SIDR needed something written down in order to not have their
bgpsec protocol design negatively impacted by operational reality.

The majority of AS migration mechanisms are ugly twists of protocol behavior
within the service provider that is utilizing them.  However, once an
appropriate administrative boundary is reached, the observed behavior is
largely transparent. Where such administrative boundaries lie will depend on
the migration mechanism in question.

Use of such mechanisms is not without its risk in terms of being what should
ideally appear to be a BGP black box outside of that boundary.  An example
of this is when the "replace-private all" mechanism is used, there will be
apparent loops in the path.  E.g.: "2 64512 3 64513" becomes "2 2 3 2".
Pedantically reading the RFC 4271 AS_PATH modification rules will lead one
to assume that such a loop could never happen and an excessively aggressive
implementation may choose to drop the path as tainted.

That obviously doesn't happen.  Healing partitioned ASes through a second
service provider is a known trick.  as-override for VPN purposes is a known
trick.  In my opinion, such tricks aren't even necessarily well covered in
the SIDR companion document since VPNs are out of scope at the moment.

While I certainly appreciate your point about the lack of normative
interoperability between several of the mechanisms, the fact that the
behavior may be transparent outside of a given domain boundary has made it
less important to operators to have the mechanisms standardized.

What I believe I see in the above comments from you are:
- Requirements may be fine.
- Descriptive behavior may be fine.
- Be more clearly normative about the behavior changes we are discussing for
  each mechanism.  

And that the above should probably consistute a document while the
implementation details may constitute a second document as an implementation
report.

With regard to your "harmful" comment, I believe leaving these long-standing
mechanisms undocument is far more harmful.  Simply writing them down and
discussing the impacts of the various options will likely lead to wider
standardization.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 24 Feb 2015 13:56:42 -0500

Adrian,

-- Jeff