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

From: "Susan Hares" <[email-masked]>
Date: Tue, 4 May 2004 13:45:41 -0400

Alex:

I'm catching up with old mail that I didn't respond to:

	On section 1 - oops, I'll fix that to match the draft
	On section 1.2 - oops, will fix tonight.
	On section 1.4 - I've got to query the implementers. 
	On section 1.5.2 - I'll query Laurel.
	
	RFC 2119 - we need to at least note that that was the context
		     of the messages.  Could you send text that you'd like
			that indicates that message. 

Thanks for all the great comments.

Sue
 
-----Original Message-----
From: Alex Zinin [mailto:[email-masked]]
Sent: Wednesday, April 14, 2004 10:42 PM
To: [email-masked]
Subject: [Idr] AD-review comments on
draft-ietf-idr-bgp-implementation-00.txt

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

[snip] 
      
>     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

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

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 22 May 2004 11:11:24 -0400

Alex:

Thanks for the input. Here's the new text, please
comment:  
 
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.   Appendix A of [BGP4] lists the differences between [RFC1771] and this BGP standard.  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.  4 implementers (Alcatel, Cisco, Laurel, NextHop) sent in implementation reports.  Section 2 provides a compilation of those results.

Section 1.3 provides the quick survey results on inter-operability. Section 1.4 provides an inter-operability of the 4 implementations.
 
Due to the large number of BGP implementations and the small number of responses, the editor took an informal survey to determine if the length of survey was an issue.  The survey questions and the results are listed in section 1.5.  X additional 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.

The editor has compiled the survey results and does guarantee the accuracy of the responses.

Sue

-----Original Message-----
From: Alex Zinin [mailto:[email-masked]]
Sent: Friday, May 21, 2004 9:36 PM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Idr] AD-review comments on

Sue,

 On the 2119 part, something along these lines--

    For every item listed, the respondents indicated whether their
    implementation supports the Functionality/Description or not (Y/N)
    indicated by the RFC2119 [3] language.

 --would seem better to me (the old texts read as "supports... according to the
 RFC 2119", the proposed reads "Functionality/Decription ... indicated by the
 RFC 2119"). A rather minor point, really.

 Thanks.

-- 
Alex
http://www.psg.com/~zinin/

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 22 May 2004 11:11:24 -0400

Alex:

 

Sue

-----Original Message-----
From: Alex Zinin [mailto:[email-masked]]
Sent: Friday, May 21, 2004 9:36 PM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Idr] AD-review comments on

Sue,

 Thanks.