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

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

(resent with correct draft author address added)

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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 12 Jun 2012 11:36:02 +0100

Authors

Please can you respond to each of Geoff's points indicating
whether you accept the change or not (if not please explain
why).

The edits look relatively straight forward, so we can use
editor's notes if you wish, although a quick respin
is cleaner.

Thanks

Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Enke Chen <[email-masked]>
Date: Tue, 12 Jun 2012 16:35:24 -0700

Hi, Geoff:

Thanks for your review.  Please see my replies below.

>    While this is not a major issue, some additional clarification appears

It is "if and only if".

Would it be better if we change "if the speaker ..." to "in the case 
that the speaker..."?

>    change from SHOULD to SHALL in the document?

The change from "SHOULD" to "SHALL" was to address a comment/observation 
that this capability is different from other bgp capabilities in that 
this capability is needed universally and should be enabled with just 
software upgrade.  So it is more about the "default" vs "non-default" 
behavior.

With that said, I am not sure whether we should revert back to 
"SHOULD".  Please advise.

>    AS number (even if a multiple Autonomous System would use it)."

Will revise as suggested.

>    UPDATE to RFC 4271 with respect to the error conditions noted here

Will do.

>    Geoff Huston

Thanks again.

-- Enke

---

From: Geoff Huston <[email-masked]>
Date: Wed, 13 Jun 2012 10:44:39 +1000

On 13/06/2012, at 9:35 AM, Enke Chen wrote:

> Would it be better if we change "if the speaker ..." to "in the case that the speaker..."?

no - because you also need to clarify the other case (namely that the speaker has a 2-octet AS number)

Might I suggest that you consider the following"

"This AS number is also placed in the "My Autonomous System" field of the OPEN message originated by a NEW BGP speaker, if and only if the speaker does not have a 2-octet AS number."

1) this covers all cases with explicit specification of what to do
2) it also encompasses those cases when the local speaker is using a private (non-globally unique) 2-octet AS number

> The change from "SHOULD" to "SHALL" was to address a comment/observation that this capability is different from other bgp capabilities in that this capability is needed universally and should be enabled with just software upgrade.  So it is more about the "default" vs "non-default" behavior.
> 
> With that said, I am not sure whether we should revert back to "SHOULD".  Please advise.

My observation was that it appears to implicitly suggest that the capability should be announced at the time that the router is 4-octet capable, yet the section 7 transition advice appears to contradict this, in so far as it seems to suggest waiting to all routers arre 4-octet capable.

I think you can leave the SHALL in section 4.1 if you add additional text in section 7. 

YOu may wish to consider the following test in Section 7:

"Where an Autonomous System is using a 2-octet AS number, then the BGP speakers within that Autonomous SYSTEM MAY be upgraded to support 4-octet AS numbers on a piecemeal basis. There is no requirement for a coordinated upgrade of this 4-octet AS capability in this case. However, if an Autonomous System wishes to use a 4-octet AS number as its own AS number, then this document assumes that an Autonomous System can use a 4-octet AS number only after all the BGP speakers within that Autonomous System have been upgraded to support 4-octet AS Numbers."

>>   UPDATE to RFC 4271 with respect to the error conditions noted here

many thanks,

   Geoff

---

From: Enke Chen <[email-masked]>
Date: Wed, 20 Jun 2012 17:21:06 -0700

Geoff,

Will make the changes as you suggested.

Thanks.   -- Enke