Subject: [RTG-DIR] RtgDir review: draft-idr-rfc4893bis-06.txt

From: Geoff Huston <[email-masked]>
Date: Tue, 12 Jun 2012 14:28:07 +1000

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-idr-rfc4893bis-06.txt
Reviewer: Geoff Huston
Review Date: 12 June 2012
IETF LC End Date: mnot known
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be
resolved before publication.

Comments:

The draft provides a small number of updates to RFC4893, fixing up some
residual grammatical errors, clarifying, or altering some of the
normative text, and providing a new section on error handling.

The document is clear, and easily understood. 

Major Issues:

none found

Minor Issues:

 1. Ambiguity in the specification

   The last sentence of the final paragraph of section 3 states
   
   "This AS number [referring to AS_TRANS] is also placed in the "My
   Autonomous System" field of the OPEN message originated by a NEW BGP
   speaker, if the speaker does not have a (globally unique) 2-octet AS
   number."
   
   is this "if" an instance of "if and only if"? Or not?
   
   i.e. if the local BGP speaker is within AS 10 (say) and it is 4-octet
   capable, then does the preceding text require that the BGP speaker
   MUST use the value "10" as "My Autonomous System" number, or
   MAY use the number 10 (or, alternatively MAY use the number 23456),
   or MUST NOT use the number 10 at all?
   
   While this is not a major issue, some additional clarification appears
   to be appropriate here.
   
 2. MAY, SHALL, or SHOULD?

   Section 4.1 states:

   "A BGP speaker that supports 4-octet Autonomous System numbers SHALL
   advertise this to its peers using the BGP Capability Advertisements."

   (RFC 4893 used SHOULD)
   
   Yet Section 7 (Transition) states:
   
   "To simplify transition, this document assumes that an Autonomous
   System could start using a 4-octet AS number only after all the BGP
   speakers within that Autonomous System have been upgraded to support
   4-octet AS numbers."   
   
   I observe that during an upgrade of routers within an AS it may be
   the case that the network administrator would like to upgrade the
   capability of all BGP speakers within the AS to support 4-octet AS
   numbers and then and only then have the BGP speakers announce this
   support to their peers. i.e. having the capability to operate in NEW
   mode need not necessarily imply a mandatory (SHALL) announcement to
   the peers of a BGP speaker. Or was this the intended effect of this
   change from SHOULD to SHALL in the document?

 3. missing use of normative language

   The last sentence of section 4.2.1 states
   
   "However, this document does not assume that an Autonomous System with
   NEW speakers has to have a globally unique 2-octet AS number --
   AS_TRANS could be used instead (even if a multiple Autonomous System
   would use it)."
   
   The "could be used instead" implies to this reviewer that there are
   other solutions, yet the document is only proposing a single
   approach. So it is my understanding from the remainder of the text of
   this document that the intent here is that:

   "AS_TRANS MUST be used when the NEW speaker does not have a 2-octet 
   AS number (even if a multiple Autonomous System would use it)."

 4. Error Handling

   Section 4 provides a specification for error handling of update in
   BGP. It would be helpful to note here that this section provides an
   UPDATE to RFC 4271 with respect to the error conditions noted here
   and their handling.

Nits:

  none found

thanks,

   Geoff Huston