Early Review of draft-ietf-idr-last-as-reservation-03

Request Review of draft-ietf-idr-last-as-reservation
Requested rev. no specific revision (document currently at 07)
Type Early Review
Team Ops Directorate (opsdir)
Deadline 2014-04-03
Requested 2014-03-18
Authors Jeffrey Haas, Jon Mitchell
Draft last updated 2014-04-14
Completed reviews Genart Last Call review of -04 by Francis Dupont (diff)
Genart Telechat review of -07 by Francis Dupont
Secdir Last Call review of -04 by David Harrington (diff)
Opsdir Early review of -03 by Gunter Van de Velde (diff)
Assignment Reviewer Gunter Van de Velde
State Completed
Review review-ietf-idr-last-as-reservation-03-opsdir-early-van-de-velde-2014-04-14
Reviewed rev. 03 (document currently at 07)
Review result Has Nits
Review completed: 2014-04-14


Dear All,

This is the requested early review of draft-ietf-idr-last-as-reservation-05

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.

These comments were written primarily for the benefit of the operational
area directors.

This document is: Ready with nits

Review notes:

1. Introduction

This section explains that IANA reserved both last ASN of 16-bit and 32-bit number space. The introduction mentions that these numbers border on private use numbers, however that there is no definition or reservation description.  While description is given later in the document, I do feel that the introduction would be more complete with a 1 line high level overview of its intended usage case.

4. Operational Considerations

s/Operators SHOULD NOT use these Last ASNs as if they are Private Use ASNs or for any other purpose./ Operators SHOULD NOT use these Last ASNs for any other purpose or as Private Use ASNs./

Operators that choose to do filtering of Private Use ASNs within the AS_PATH and AS4_PATH attributes SHOULD also filter these Last ASNs.

Why only mention like this when filtering private ASN's? it should always be filtered, when or when not private ASNs are used... It would be simpler from operational perspective to have a single recommendation for both instances.

5. Implementation Consideration

However, implementations MAY generate a local warning message indicating improper use of a reserved ASN.

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