Early Review of draft-ietf-idr-last-as-reservation-03
review-ietf-idr-last-as-reservation-03-opsdir-early-van-de-velde-2014-04-14-00

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
Other 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)
Review State Completed
Reviewer Gunter Van de Velde
Review review-ietf-idr-last-as-reservation-03-opsdir-early-van-de-velde-2014-04-14
Posted at http://www.ietf.org/mail-archive/web/ops-dir/current/msg00263.html
Reviewed rev. 03 (document currently at 07)
Review result Has Nits
Draft last updated 2014-04-14
Review completed: 2014-04-14

Review
review-ietf-idr-last-as-reservation-03-opsdir-early-van-de-velde-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./

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

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

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

Brgds,
G/