Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP
draft-ietf-idr-deprecate-as-sets-06

[Ballot comment]
Thank you for addressing my Discuss and Comment. I have cleared my Discuss on the basis of the RFC Editor note, but please be aware that 2119 language is not appropriate in the Abstract, and that "RECOMMENDS" is not an RFC 2119 term.

[Ballot comment]
1. I support comments made by the other ADs about improper use (or lack of use) of 2119 keywords.

2. In the Introduction section, the second paragraph contains a statement that route aggregation “can cause operational issues that include reachability problems and traffic engineering issues”.  From an editorial perspective, this statement might be easier to read if broken into two or three sentences.  In any case, it would be valuable for this statement to be expanded and/or include a reference to background information.

3. The third paragraph in the Introduction contains a statement that aggregation benefits are “outweighed” by complexity and confusion.  The judgment made by this statement feels correct, but likewise an explanation and/or reference would be useful.  Additionally, while the [analysis] reference to “Measurement Data...” provides useful details on the number of routes with AS_SET / AS_CONFED_SET attributes, some analysis of the impact on table size would be useful.  Specifically, what is the compression ratio achieved by extant AS_SET routes and thusly how might those routes multiply if replaced by more-specific routes?  I doubt that it will have a material impact on default-free routing, but it’s worth discussing if any data is available.

[Ballot discuss]
The DISCUSS and COMMENT is partly based on the OPS-DIR review performed by Benson Schliesser.

1. The claim in the Abstract is confusing. The draft proposes deprecation of usage of AS_SET and AS_CONFED_SET, which seems like a desirable goal.  However, the Abstract claims “[t]his is done to simplify the design and implementation of the BGP protocol” but the document offers no specific updates to the BGP protocol.  If updates to the BGP protocol are to be done elsewhere, a reference and/or pointer would be welcome.  If no specific protocol updates are envisioned at this time, and the document is merely suggesting that operators should cease using these attributes, then this should be made explicit, and maybe a section that recommends further work on the protocol should be added.

2. Being the most significant element of this draft, section 3 needs to include more specific details.  Operators that already announce routes with AS_SET or AS_CONFED_SET are advised to re-announce those prefixes without the deprecated attributes, perhaps undoing aggregation and announcing more-specific routes.  But it should be made clear under what circumstances the original prefix may continue to be advertised (re-announced), and that in other cases the more-specific routes are advertised instead (not in addition), etc.  This draft doesn’t need to provide a primer on Internet routing with BGP, of course, but it should at least give more details and/or pointers on how to implement the recommendation.

3. Further, the draft should explicitly discuss recommendations to operators that receive routes with AS_SET or AS_CONFED_SET.  The simplest case is to recommend that these operators continue with status quo.  However, the draft mentions “new technologies” that “may not support” these routes, and that “operators may begin filtering routes that contain AS_SETs or AS_CONFED_SETs”.  If operators should behave differently as a result of this deprecation, then the recommended behavior should be described.  Likewise, if existing technologies and/or implementations should be updated as a result of this deprecation, those updates should be described.  The draft doesn’t appear to provide or recommend any specific updates to BGP; that should be explicitly stated.

[Ballot comment]
I support Adrian's Discuss, and pete's comments.
Either this is an update to the existing standards, and thus should be standards-track itself,
OR it is a usage recommendation.
Either way, the document, especially, the RFC2119 language, should be modified to reflect the purpose.

[Ballot comment]
I would like to see proper use of RFC 2119 language in Section 3

  strongly advised == RECOMMENDED
  should withdraw == SHOULD withdraw
  operators may begin filtering == MAY

---

Section 3

  It is worth noting that new technologies (such as those that take
  advantage of the "X.509 Extensions for IP Addresses and AS
  Identifiers" ([RFC3779]) may not support routes with AS_SETs /

I prefer s/may not/might not/

[Ballot discuss]
This is a relatively small Discuss. I have already discussed it with Stewart and we think we undertand the intention, but I am entering the whole Discuss point so that the authors can respond...

Danny McPherson wrote the following notes in his Routing Directorate
review.

> I'm still unclear about the proposed publication track for this
> document, and the precise objective.  If the aim is to deprecate a
> feature in TWO Standards Track RFCs (4271 & 5065) shouldn't it be
> Standards Track as well and recommend which documents be modified
> in what manner?  The current recommendation is that operators stop
> using a Standards Track feature, and this seems a bit backwards to
> me.

All this seems to predecated on the statement that this document
deprecates AS_SET and AS_CONFED_SET. If that was the case then...

  Certainly, the document must be updating RFC 4271 and RFC 5065.
  So I would expect that in the header and the Abstract, and I would
  expect specific discussion in the body with reference to the sections
  of those RFCs that are being updated.

  As to what track this document should be on...
  I can't get excited, but Danny does seem to be right that Standards
  Track seems more appropriate.

But I think the point is that you are not deprecating anything in the
protocol. You are recommending against the use of AS_SET and
AS_CONFED_SET. If that is the case:

  Change "Deprecate"

  - Document title "Recommendation on non-use of..."

  - Abstract "This document recommends against the use of..."

  - Introduction - delete

      Since this practice is thought to no longer be widely
      used, it is thought to be safe to deprecate the use of AS_SET.

> Regarding the Introduction and "very seldom used" discussed, I've
> seen this discussion evolve and because "very seldom used" != 0 it
> may be worthwhile to ask either the respective operations communities
> and/or upstream network operators, or perhaps the RIRs involved with
> the number resources in question, to contact and expressly notify the
> current operators that use this feature in order to avoid breaking
> operational infrastructure and encouraging them to change their
> routing design to remove AS_SETs - or to make a real solid case for
> why they cannot.

Again, this is a question of whether support is deprecated, or use is
NOT RECOMMENDED. If you mean to deprecate from the protocol, then I
agree with Danny. If you mean to recommenda against use, then no change
is needed.

[Ballot comment]
Paragraph 1 of section 3 has a couple of places that look appropriate for 2119 language: "are strongly advised to not" could easily be "SHOULD NOT" and "should withdraw" could be "SHOULD withdraw". Indeed, the last sentence of section 3 mirrors the language of 2119 where it says "the operator should understand the full implications of the change." So if you really want to use 2119, it seems like these are good places to use it.

However, the one (and only one) place you *do* use 2119 language, it is used incorrectly:

  It is worth noting that new technologies (such as those that take
  advantage of the "X.509 Extensions for IP Addresses and AS
  Identifiers" ([RFC3779]) may not support routes with AS_SETs /
  AS_CONFED_SETs in them, and MAY treat as infeasible routes containing
  them.  Future BGP implementations may also do the same.

This is not defining the optional behavior of treating routes as infeasible. This is saying that it should be noted that new technologies might treat routes as infeasible. I suggest changing "MAY" to "may" or "might".

If you put SHOULDs into paragraph 1, include the 2119 reference. If you don't, remove the 2119 reference entirely. Either way, fix the MAY.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Deprecation of the use of BGP AS_SET, AS_CONFED_SET.) to Informational RFC


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'Deprecation of the use of BGP AS_SET, AS_CONFED_SET.'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-08-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document deprecates the use of the AS_SET and AS_CONFED_SET
  types of the AS_PATH in BGPv4.  This is done to simplify the design
  and implementation of the BGP protocol and to make the semantics of
  the originator of a route more clear.  This will also simplify the
  design, implementation and deployment of ongoing work in the Secure
  Inter-Domain Routing Working Group.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-sets/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-sets/


No IPR declarations have been submitted directly on this I-D.

This is the completed Document Shepherd Write-Up as required by RFC
4858 for the draft draft-ietf-idr-deprecate-as-sets-04. This
template was completed 2011-07-07.

The template version is dated September 17, 2008.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

John Scudder is the Document Shepherd. He has reviewed the
document and believes it is ready.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has received review from key WG members and members from
the SIDR (and other) WGs. The document provides advice to operators to
avoid using a specific feature of the BGP protocol (which almost no-one
is using anyway!) and does not make any changes to the protocol itself.
Why do this? Furute work is planned to deprecate the feature itself.
This document provides notice to operators to stop using the feature, so
that the future work can proceed.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

As noted above the document does not actually deprecate the feature,
but merely advises that its USE be discontinued. I had hoped that
it would be possible to move directly forward and deprecate the
feature; there was not WG consensus to do this however and this seems
a good intermediate step.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

This document recived review before being accepted (on 2010-10-25).
There was an inital WGLC that ended on 2011-04-13. During this WGLC
the comments received were generally in support, but there were not
enough comments received to call concensus, and at least one participant
provided comments that the authors felt should be incorporated.

Following integration of these a second WGLC was held, concluding on
2011-05-17, during which time sufficent supporting comments were recieved.

There were around 150 emails on list regarding this document / topic and a
an additional 100 - 150 emails on other lists / off-list emails.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Meets the checklist and the idnits tool reports no nits.
There are some minor spelling and grammar nits, which can be addressed
with the RFC Editor.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

There are only Informative References.
There is one informative reference that has not been included in the current document
(as the stable refernce was not ready). It is in support of:
"From analysis of past Internet routing data..." and will reference:
http://www.antd.nist.gov/~ksriram/AS_SET_Aggregator_Stats.pdf
This data was discussed onlist and the reference can be added at edit time.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?


The documents asks nothing of the IANA function and clearly states so.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

N/A

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document provides advice to operators. It deprecates the use of the
AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to
simplify the design and implementation of the BGP protocol and to make
the semantics of the originator of a route more clear.

Working Group Summary

This document was adopted as a WG item on Oct 25th, 2010. There was an
initial WGLC that concluded on April 13th, 2010. Comments from the
initial WGLC were integrated and a second WGLC held, which concluded on
May17, 2011.