Reservation of Last Autonomous System (AS) Numbers
draft-ietf-idr-last-as-reservation-07

[Ballot comment]
Minor suggested revision:
OLD: "Operators SHOULD filter Last ASNs within the AS_PATH and AS4_PATH attributes."
NEW: "Operators SHOULD filter routes with Last ASNs in the AS_PATH and AS4_PATH attributes."

Does that accurately capture your intent?  As I read the original sentence, it sounds like you would remove those ASNs from the path, which seems bad.

[Ballot comment]
Maybe this is just me not understanding, and it may not matter if the whole point is to ask IANA to do these reservations, but in this text: 3.  Reasons for Last ASNs Reservation

  A subset of the BGP communities of ASN 65535, the last ASN of the 16
  bit range, are reserved for use by Well-known communities as
  described in [RFC1997] and [IANA.WK].  Although this is not currently
  true of ASN 4294967295, if there is a future need for another Special
  Use ASN that is not designed to be globally routable, or the
  associated BGP communities of such an ASN, ASN 4294967295 could be a
  valid candidate for such purpose.  This document does not prescribe
  any such Special Use to this ASN at the time of publication.

I'm not seeing anything that looks like a clearly stated reason for the reservations.

If everyone else thinks that's a reason, please carry on :D

[Ballot comment]
As noted by Gunter V. in his OPS Directorate review, and answered by Jeff Haas

> 5. Implementation Consideration
>
> <>Start<>
> However, implementations MAY generate a local warning message indicating improper use of a reserved ASN.
> <>end<>
>
> I think that for operational simplicity this should be a stronger recommendation SHOULD, because if they are used, then the intended network architecture will breack somewhere…

For internal routing, this is generally true.  For stuff you’re getting off the Internet, you may not care and will simply discard that reachability.  Making this too chatty may not be a good idea.


Benoit: Maybe the solution is to make the distinction between internal routing (SHOULD) and external (MAY).

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-idr-last-as-reservation-04.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, in the 16-bit Autonomous System Numbers subregistry of the Autonomous System (AS) Numbers registry located at:

http://www.iana.org/assignments/as-numbers/

the reference for 65535 will be set to [ RFC-to-be ]. IANA understands that the instructions in the current draft of the document for the value 65535 is duplicated.

Second, in the 32-bit Autonomous System Numbers subregistry of the Autonomous System (AS) Numbers registry located at:

http://www.iana.org/assignments/as-numbers/

the reference for 4294967295 will be set to [ RFC-to-be ].

Third, IANA notes that these values will be documented in a new IANA Special Purpose AS Numbers registry to be created by [ I-D.housley-number-registries ]. No actions associated with that new registry are required upon approval of the current document.

IANA understands that these are the only actions that need to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Reservation of Last Autonomous System (AS) Numbers) to Informational RFC


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'Reservation of Last Autonomous System (AS) Numbers'
  as 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 2014-04-03. 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 reserves two Autonomous System numbers (ASNs) at the
  end of the 16 bit and 32 bit ranges, described in this document as
  "Last ASNs" and provides guidance to implementers and operators on
  their use.




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

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-idr-last-as-reservation/ballot/


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

As part of my standard processing for progressing routing drafts, I do a review of drafts before requesting IETF Last Call or progressing the draft. 

This is a well-written clear draft.  I have just two comments on it.

First, let's keep it as Informational and see how that goes.

Second, could the IANA considerations section please add this document as the reference for 0xFFFFFFFF and 0xFFFF ?

Once the authors have posted the updated version, we can move on to IETF Last Call.

RFC 4858 based (form shortened)

Version: 2
Date: 3/14/2014
Note: Update of shepherd's report expected
Shepherd: Susan Hares
AD: Alia Atlas:

(1) type of RFC:  Proposed standard or BCP
Note the WG was fine with BCP, Proposed Standard or BCP.  It is specifying AS Reservation.

If BCP, it should Updates RFC1930.  If informational, it should refer to


(2) 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 reserves two Autonomous System numbers (ASNs) at the
  end of the 16 bit and 32 bit ranges, described in this document as
  "Last ASNs" and provides guidance to implementers and operators on
  their use.

Working Group Summary

WG's only discussion was on whether this was BCP or Proposed standard.
The result was "What-ever works" as it has both suggestions to
implementors and operators.

Document Quality

Implementations at Microsoft, Cisco and Juniper adapted this range.
No implementation report exists.


(3) Review of document:
This document has no nits and good English in the text.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No.  List discussions include operations people (Such as Randy Bush)

(5) Reviews needed:

1) AD review - should this be BCP or Proposed Standard
2) IANA review

stated:
"We have one more action to add to the IANA Considerations section: the recently-approved document RFC-housley-number-registries-04 has just created a new registry called "Special-Purpose AS Numbers," where this document is a reference for value 4294967295. This document should instruct us to update that reference and, if appropriate, tell us to add it as a reference for any other relevant registrations in that registry."

Version -03: has the changes to respond to this IANA review.  Please note AD will need to decide BCP or Information. WG is Ok with either one.

3) OPS-DIR - is this

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

IDR/Grow share the concerns with AS allocations. We are taking a pragmatic view regarding who process these drafts by doing cross reviews, talking between Chairs,
and just getting the work done.

(7) IPR Disclosures:  IPR query out to Authors for final version. This shepherds report will be updated once this has been received.

(8) Has an IPR disclosure been filed that references this document?
No.

(9) How solid is the WG consensus behind this document? 

Consensus appears to reflect interested parties. However, this draft simply fixes
something missed in a widely discuss private-as draft so it is most likely people are
not commenting on the administrative information. 
(Note: The administrative or operation impact implies a BCP).

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  Everyone wants the draft. The only question is BCP or Proposed standard.

(11)Nits - no nits, no edits needed

(12) Reviews:  Early reviews for IANA, OPS-DIR, Routing AD, and Routing Directorate requested.

(13)/(14)/(150  Normative/Informative:  Seem to be in the correct place, but in the
IANA review we will check their viewpoint. No downward normative references (RFC3967)


(16) Will publication of this document change the status of any
existing RFCs?  No status change for RFCs, and Abstract is does not contain RFC references.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. 

The IANA section is being asked to early review. No changes need to be made
for this draft at IANA, but it links to a Last AS allocaiton.

(18) No new IANA registries

(19) No XML, BNF, RBNF or other thigns to review