Subject: [Idr] Pete Resnick's Discuss on draft-ietf-idr-as-migration-03: (with DISCUSS and COMMENT)

From: "Pete Resnick" <[email-masked]>
Date: Wed, 18 Feb 2015 20:36:34 -0800

Pete Resnick has entered the following ballot position for
draft-ietf-idr-as-migration-03: 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 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/

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

A procedural DISCUSS, which I expect will be cleared on the call,
whatever the outcome:

RFC 2026 says this in section 5 regarding what a BCP is for:

   Historically Internet standards have generally been concerned with
   the technical specifications for hardware and software required for
   computer communication across interconnected networks.  However,
   since the Internet itself is composed of networks operated by a great
   variety of organizations, with diverse goals and rules, good user
   service requires that the operators and administrators of the
   Internet follow some common guidelines for policies and operations.
   While these guidelines are generally different in scope and style
   from protocol standards, their establishment needs a similar process
   for consensus building.

That sounds like exactly what this document is doing. Sounds like it
should be a BCP. Is there a reason it shouldn't be?

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

I tend to agree with Alissa's distaste for the style of the second
paragraph in section 1. This is a technical document, so I don't see the
need to get into the details of how the technology impacts business. I'm
sure the people driving the decision to use this document will be fully
aware of the business consequences, so no need to really go into them
here. Here's a suggestion by way of toning it down:

NEW
   The migration features discussed here are useful to ISPs and
   organizations of all sizes, but they are critical for ISPs'
   operations when it is necessary to seamlessly migrate both internal
   and external BGP speakers from one ASN to a second ASN, such as
   during a merger, acquisition or divestiture involving two
   organizations.  The overall goal in doing so is to simplify
   operations through consistent configurations across all BGP speakers
   in the combined network.  In addition, ISPs find it critical to
   maintain utilization of their network resources by their customers. 
   Because the BGP Path Selection algorithm selects routes with the
   shortest AS_PATH attribute, an increase in AS_PATH length during or
   after ASN migration toward downstream transit customers or
   settlement-free peers would result in significant changes to traffic
   patterns and decreased utilization by those customers.

---

From: "George, Wes" <[email-masked]>
Date: Thu, 19 Feb 2015 14:23:49 -0500

WG] as I said when asking the question of the WG, I don't have any
particular religion about what the document status is, because it has
little impact on the document's potential usefulness to its intended
audiences, which I think is the real goal of publishing it in the first
place. This document falls into a bit of a grey area due to the lack of
strict requirement for interop, but I don't agree that it conforms exactly
to the BCP definition you list above. Perhaps the draft is too flexible in
that regard, but I thought that would be a useful thing for implementers
since IETF's usual philosophy is to not be overly prescriptive except
where it is necessary to ensure proper interoperability. PS seemed the
right choice because it is still governing the behavior (albeit optional
and only locally-significant) for what we'd consider a BGP-compliant
implementation. I will note that the companion draft in SIDR is much more
clearly a PS because it normatively alters the protocol behavior, and thus
if idr-as-migration is changed to a lesser status, we have a problem of a
down ref normative reference. Not the biggest problem ever, but worth
considering when discussing potential status changes. I do think that the
normative reference in SIDR-as-migration must remain normative, because
that document is predicated on the idea that it is updating SIDR BGPSec to
allow for a now standardized part of the BGP protocol. It makes less sense
to standardize something in BGPSec to allow for an implementation that is
only a de facto standard. Whether informational or BCP status would raise
that concern is a matter of interpretation that I leave to those on the
IESG that see the document's status as an issue.

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 14:23:49 -0500

Thanks

Wes