[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:
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@psg.com]
Sent: Wednesday, April 14, 2004 10:42 PM
To: idr@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@ietf.org
https://www1.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr