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