Subject: [Idr] AD-review comments on draft-ietf-idr-bgp-implementation-00.txt

From: Alex Zinin <[email-masked]>
Date: Wed, 14 Apr 2004 19:41:51 -0700

Folks-

Several comments inline below.

> 1.1 General
>     
>     This draft of BGP-4 attempts to bring BGP standard as described in 

Seems like this is out of context.

>     RFC 1771 in alignment with the deployments of the BGP-4 protocols.   
>     The changes with RFC 1771 are listed in the appendix A of[BGP4].   
>     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].  
>             
>     BGP as a widely deployed cornerstone of Internet technology 
>     continues to add additional functionality as the needs within the 
>     Internet require. This survey had 259 detailed questions on the 
>     compliances with the standard.  3 implementers (Cisco, Laurel, 
>     NextHop) sent in implementation reports.  Sections X - Y provides 
>     the compilation of those results. 
>       
>     X implementers who responded below indicating inter-operability with 
>     other implementations.  Of these X implementations, Y also indicated 
>     the length of the survey was as problem. The editor recommends that 
>     other methods, such as enlisting existing testing vendors be 
>     employed to gather more implementation report. 
>      
>     Section Z provides the quick survey results on inter-operability.  
>     
>  
>  
> Hares & Retana          Expires - August 2004                [Page 3] 
> 
> 
> 
> 
>                  draft-ietf-idr-bgp-implementation-00    February 2004 
>  
>  

X, Y, and Z need to be filled out... ;)

> 1.2 Full Survey result summary 
>      
>     Significant Differences 
>       
>     All 259 survey points had two "y" or "y" and "O" except the 
>     following: 

At this point of the document, it is not clear what "y" and "0" are.

Generally, if we don't have at least two implementations for a specific feature,
it can't stay in the spec. The granularity of the BGP implementation report
is finer than on a per-feature basis, but we still need to see if the spec needs
to be fixed accordingly. More specific comments below:

>       MUST - Question 214 
>        
>       Question 214 about aggregation of  routes. section 9.1.4 had a "N" 
>       response from 3 implementers indicating that they install both 
>       routes, and 1 yes. 

when I look at section 2.43.214, I see:

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y 
       Laurel  Y/N/O/Comments: Y 
       NextHop Y/N/O/Comments: Y 

wrong section?

>       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) indicate "y" matching 
>       the specification. 
>        
>         text: Routes that have different MULTI_EXIT_DISC attribute SHALL 
>         NOT be aggregated. 

If this is considered to be important for protocol correctness, then the WG
may consider softening the requirements language and changing it to "SHOULD
NOT"--apparently some implementers found that under certain circumstances
such routes still need to be aggregated.

>       SHOULD - 2 in appendix F (questions 257, 258)
>        
>       Three vendors said no, one vendor said yes to question 257.  All 
>       four vendors indicated no to question 258. (Please note that 
>       Appendix F is an optional text section) 
>         
>        Text: section F.2 - A BGP speaker which needs to withdraw a 
>        destination and send an update about a more specific or less  
>        specific route SHOULD combine them into the same UPDATE message.  
>         
>        Text: Section F.6: The last instance (rightmost occurrence) of 
>        that AS number is kept.

Assuming that the appendices are not a normative part of the spec, the
2119 language should not be used there.

...
> 1.4 Implementations and interoperability
>     
>    Short informal summary of implementers reporting implementations and 
>    inter-operability 
>      
>      [This section will be added later but will have the format below ] 
>
>                     Alcatel Cisco Laurel  NextHop  
>        Alcatel                                 
>        Cisco                                   
>        Laurel                                                   
>        NextHop                                        

the above table needs to be filled out.

> 1.5 BGP Implementation Identification

This section does not specify the origin of code

>    1.5.0 Alcatel 
>     
>    1.5.1 Cisco 
>    Implementation Name/Version: Cisco BGP Implementation, 12.0(27)S 
>    Date: 11/26/2003 
>     
>    1.5.2 Laurel 
>     
>    1.5.3 NextHop Technologies 
>    Implementation Name/Version: Gated NGC 2.0, 2.2 
>    Date: January 2004  
>  
>  
> Hares & Retana          Expires - August 2004                [Page 5] 
> 
> 
> 
> 
>                  draft-ietf-idr-bgp-implementation-00    February 2004 
>  
>  
>     
> 2. BGP4 Implementation Report 
>     
>    For every item listed, the respondents indicated whether their 
>    implementation supports the Functionality/Description or not (Y/N) 
>    according to the RFC2119 [3] language indicated.

"according to the RFC 2119" should probably be removed. The implementation
either decides to support something the 2119 language prescribes in some form or
it doesn't.

> Any respondent 
>    comments are included.  If appropriate, the respondents indicated 
>    with O the fact that the support is neither Y/N (an alternate 
>    behavior, for example). Refer to the appropriate sections in the 
>    latest BGP-4 ID [4] for additional details. 

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr