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

[Jeffrey Haas <[e-mail]>]

Adrian,


On Thu, Feb 19, 2015 at 06:25:42AM -0800, Adrian Farrel wrote:
[...]
> 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.

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