Skip to main content

Experience with the BGP-4 Protocol
draft-ietf-idr-bgp4-experience-protocol-05

Discuss


Yes

(Bill Fenner)

No Objection

(Allison Mankin)
(David Kessens)
(Jon Peterson)
(Margaret Cullen)
(Sam Hartman)
(Thomas Narten)

Note: This ballot was opened for revision 05 and is now closed.

Steven Bellovin Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2004-07-22) Unknown
draft-ietf-idr-bgp4
        9.1.2.1: what is the "longest route"?  The longest prefix?  The longest AS path?

draft-ietf-idr-bgp-vuln
        section 1: Address-spoofing should be listed as a possible form of damage.  Also discuss how this enables active attacks on traffic, by routing it through a modifier station.

draft-ietf-idr-bgp-analysis
        The document speaks of versions 1, 2, and 3 of BGP-4

draft-ietf-idr-bgp4-experience-protocol
        The document speaks of 134,000 prefixes; draft-ietf-idr-bgp-analysis speaks of 120K.  Which is it?

        Section 7.1.1: s/potatoe/potato/ (unless the authors subscribe to the Dan Quayle school of spelling)

        Some of the subsections of Section 17 appear as if they should be sections.
Alex Zinin Former IESG member
(was No Record, Yes) Yes
Yes (2004-07-15) Unknown
Some comments that should be addressed when the documents are revised.

draft-ietf-idr-bgp4-experience-protocol:

From my previous review:

>  I'm generally quite happy with this document. The only comment I had was about
>  the way the 2119 requirements language is used. In some places (simple search
>  for "MUST" would reveal), the document reads as defining protocol procedures,
>  which should be in the protocol spec. If the intention is to quote the spec,
>  the wording should be changed accordingly.

>  Refs to SBGP and SoBGP should be filled in.


There are still one place where the above problem exists:

> 7.1.2.  Sending MEDs to BGP Peers

>    [BGP4] allows MEDs received from any EBGP peers by a BGP speaker to
>    be passed to its IBGP peers.  Although advertising MEDs to IBGP peers
>    is not a required behavior, it is a common default.  MEDs received
>    from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP
>    peers.

The document also needs new boilerplates per 3667/3668.


draft-ietf-idr-bgp-implementation-01.txt:

> 1. Introduction
>     
>     This revision of the BGP-4 standard [BGP4] updates the BGP standard 
>     [RFC1771] to be in alignment with the deployments of the BGP-4 
>     protocols.   BGP-4 as deployed in the Internet encompasses both this 
>     base specification and additional specifications such as TCP MD5 
>     [RFC2385], BGP Route Reflectors [RFC 2796], BGP Confederations   
>     [RFC3065], and BGP Route Refresh [RFC 2918].   

Don't "This revision of the BGP-4 standard" and "this base specification"
give the reader an impression that this document is the revision and the
base specification?

> 2.3 BGP Implementation Identification

The origins of the implementations are still not specified.


draft-ietf-idr-bgp-analysis-05.txt:
> 2.1.  Key Features
...
>    One of the most important path attributes is the Autonomous System
>    Path, or AS_PATH. Autonomous System's (AS) reachability information
                       ^^^^^^^^^^^^^^^^^^^^^^^^

Is this really what you meant here? The original text said "AS reachability
info...", I commented if is should have been "As", i.e. whether it should read
"as ... info travereses... it is augmented..."

>    traverses the Internet, this information is augmented by the list of
>    autonomous systems that have been traversed thus far, forming the
>    AS_PATH.
...

> 6.1.  Link bandwidth and CPU utilization
...
>
>            BW = O((N + A) * P)
>
>    The following table illustrates the typical amount of bandwidth

The table is missing in the text.

> 6.1.1.  CPU utilization
...
>    During the periods of network instability, BGP routers within the
>    network are generating routing updates that are exchanged using the
>    BGP UPDATE messages.  The greatest overhead per UPDATE message occurs
>    when each UPDATE message contains only a single network. It should
>    pointed out that in practice routing changes exhibit strong locality

"it should BE pointed out"

When you revise the draft, please include the new boilerplates required
by 3667/3668.

draft-ietf-idr-bgp4-24.txt:

needs new boilerplates
Bill Fenner Former IESG member
Yes
Yes () Unknown

                            
Allison Mankin Former IESG member
No Objection
No Objection () Unknown

                            
Bert Wijnen Former IESG member
(was Discuss) No Objection
No Objection (2004-12-02) Unknown
-------
draft-ietf-idr-bgp-implementation-01.txt
-------
Section 1 speaks about:
    Section 1.3 provides the quick survey results on inter-operability.
    Section 1.4 provides an inter-operability of the 4 implementations.
but there are no such section 1.3 and 1.4

Actually, the whole numbering of sections needs to be checked I think.

---------- 

Additional Comment from Pekka on 26 Nov 2004:

> Procedural:
> 
> 1)
> 
> The results of the implementation report do not seem to be completely 
> reflected in the document.  For example:
> 
>       b) SHALL NOT - Question 228, regarding section 9.2.2.2
> 
>           Three vendors (Alcatel, Cisco, Laurel), answered "N" to shall
>           not (meaning they did).  One vendor (NextHop) indicated "O"
>           matching the specification.
> 
>         Text:  Routes that have different MULTI_EXIT_DISC attribute
>                SHALL NOT be aggregated.
> 
> ==> one implementation does not fulfill the criteria of two 
> implementations of a feature, which is required prior to advancing to 
> Draft Standard.  Therefore the BGP specification must be changed.
> 
> I have not gone through the implementation report in detail, but it 
> should be carefully reviewed to ensure that features for which there 
> aren't at least two interoperable implementations are removed.
> 
> 
> 2) A normative reference may need to be moved over to Informative:
> 
> Normative References:
>     [RFC2474] Nichols, K., et al.,"Definition of the Differentiated
>     Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474,
>     December 1998
> 
> ==> this is a Proposed Standard, and a Draft Standard cannot 
> reference it normatively.
> 
> Nit:
>   'Working Group Summary' in the announcement needs to be updated.
> 
>
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Harald Alvestrand Former IESG member
(was Discuss) No Objection
No Objection (2004-12-02) Unknown
draft-ietf-idr-bgp-implementation-01 and -02 reviewed by Mary Barnes, Gen-ART
draft-ietf-idr-bgp4-24 and -26 reviewed by Brian Carpenter, Gen-ART
draft-ietf-idr-bgp4-mib-14 reviewed by John Loughney, Gen-ART
draft-ietf-idr-bgp-vuln-00 reviewed by Kent Crispin, Gen-ART
                       -01 reviewed by Elwyn Davies, Gen-ART
draft-ietf-idr-bgp-analysis-05 reviewed by Lucy Lynch, Gen-ART
                           -06 reviewed by Elwyn Davies, Gen-ART
draft-ietf-idr-bgp4-experience-protocol-04 reviewed by Mark Allman, Gen-ART
                                       -05 reviewed by Suzanne Woolf, Gen-ART
draft-ietf-idr-bgp-mibagent-survey-02 reviewed by Michael Patton, Gen-ART
draft-iesg-tcpmd5app-00 reviewed by Spencer Dawkins, Gen-ART

I have added reviews as comments on the individual documents, not on the ballots. There are no show-stopper issues identified, but lots of details worthy of notice (still).
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Margaret Cullen Former IESG member
(was Discuss, No Objection) No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (2004-07-21) Unknown
  draft-idr-bgp-implementation-01:

  The abstract and the introduction state that the the editors make no claim
  as to the accuracy of the information provided.  It would be much better to
  make a positive statement in the introduction, and say nothing in the 
  abstract.  Perhaps something like:  The editors have assembled information
  provided by four implementors: Alcatel, Cisco, Laurel, and NextHop.

  draft-ietf-idr-bgp4-24:

  Please replace the first sentence of the Security Considerations with:  A
  BGP implementation MUST support the authentication mechanism specified in
  RFC 2385 [RFC2385].

  draft-ietf-idr-bgp4-mib-14:

  The security considerations section contains non-ASCII characters.

  draft-ietf-idr-bgp-vuln-00:

  Nice job.

  It would have helped me if the event tags had been explained before I 
  encountered the first one in section 3.1.1.  Perhaps an additional
  paragraph in section 3 would explain them.

  In the whole document: s/IPSEC/IPsec/

  In section 1, 5th paragraph: s/msut/must/

  The lists in section 1 and section 2 have a different format.  In section 1,
  each item in the list ends with a comma (the "and" appears one entry before
  it should), and in section 2, the list members are full sentences.  I would
  like to see the same style for both lists.

  draft-iesg-tcpmd5app-00:
  
  The security Considerations say:
  >
  > The IESG believes that the variance described here will not affect
  > the security of the Internet.
  >
  I think we should insert "adversely" before "affect."

  draft-ietf-idr-bgp4-experience-protocol-04:

  In section 17.6: s/rationelle/rationale/

  Section 17 includes stuff that is not security relevant, including the
  acknowledgements section.  A minor reorganization is appropriate.
Sam Hartman Former IESG member
No Objection
No Objection () Unknown

                            
Scott Hollenbeck Former IESG member
No Objection
No Objection (2004-07-15) Unknown
draft-ietf-idr-bgp-mibagent-survey:
The Security Considerations should be something more detailed than "This document does not address any security issues".  If anything, those words are an admission that something more should be written!  A reading of RFC 3552 would explain why I think this could be better, even if there's not much in this document that has a security impact.

draft-ietf-idr-bgp4-experience-protocol:
draft-ietf-idr-bgp-vuln:
References need to be split normative/informative.
Ted Hardie Former IESG member
No Objection
No Objection (2004-07-20) Unknown
In draft-ietf-idr-bgp4-24.txt, an informative reference to RFC1930 seems likely to be
useful, especially since that reserves specific ASNs as private use.

The abstract in draft-ietf-idr-bgp4-mib-14.txt says:

  This memo is an extension to the SNMP MIB.  It obsoletes RFC 1657 and
   RFC 1269..

That doesn't seem quite right.  1657, which this obsoletes, says:

This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects used for managing the
   Border Gateway Protocol Version 4 or lower [1, 2].

An extension to the SMI, maybe, instead of the snmp mib?

In draft-idr-bgp-implementationt:

The abstract states the the editors make no claim as to the accuracy 
of the information provided.  This is repeated in section 1. Not blocking 
but this seems strange in an implementation report.  

In draft-ietf-idr-bgp4-experience-protocol-04.txt , I assume the RFC Editor 
will talk to them about "hot potatoe" spellings in US terms.  This sentence:

Seemingly more intuitive references that fall outside the vegetable
   kingdom refer to cold potatoe routing as "best exit routing", and hot
   potatoe routing as "closest exit routing", though vegetable.

also looked like it might have gotten interrupted in mid-edit.

I note the this document says that folks use IPSEC to protect BGP
in some circumstances, where the TCPmd5 variance says that
IPSec and TLS  are rarely if ever used.  Not blocking, just thought it worth
noting that these don't quite agree.  Hopefully this means folks are looking
at how to augment TCPmd5.
Thomas Narten Former IESG member
(was Discuss, No Objection) No Objection
No Objection () Unknown