[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Idr] AD-review comments on draft-ietf-idr-bgp-implementation-00.txt
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:zinin at psg.com]
Sent: Friday, May 21, 2004 9:36 PM
To: Susan Hares
Cc: idr at ietf.org
Subject: Re: [Idr] AD-review comments on
draft-ietf-idr-bgp-implementation-00.txt
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/
Tuesday, May 4, 2004, 10:45:41 AM, Susan Hares wrote:
> 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:zinin at psg.com]
> Sent: Wednesday, April 14, 2004 10:42 PM
> To: idr at ietf.org
> 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
> Idr at ietf.org
> https://www1.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www1.ietf.org/mailman/listinfo/idr