Internet DRAFT - draft-hares-idr-bgp2858-survey
draft-hares-idr-bgp2858-survey
Inter-Domain Working Group
Internet Draft S. Hares (editor)
Document: draft-hares-idr-rfc2858bis-survey-00.txt NextHop
Expires: December 2004 July 2004
MP-BGP implementation Report
Status of this Memo
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
This document may not be modified, and derivative works of it may
not be created, except to publish it as an RFC and to translate it
into languages other than English.
Abstract
This document provides a survey of the BGP implementations
supporting the multi-protocol extensions as specified in
ietf-idr-rfc2858bis-06.txt implementations. After a brief summary,
each response is listed. The editor makes no claim as to the
accuracy of the information provided.
Hares Expires - December 2004
^L
draft-ietf-idr-2858bis Survey Report July 2004
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1].
TABLE of CONTENTS
1. Overview.......................................................2
1.1 General....................................................2
1.2 Full Survey result.........................................3
1.3 Summary of questions.......................................3
1.4 Implementations and interoperability.......................4
1.5 BGP Implementation Identification..........................4
1.6 BGP Survery respondant.....................................5
2. BGP4 Implementation Report.....................................5
2.1 Implementation Survey Results..............................6
3. Survey Form...................................................13
4. Security Considerations.......................................19
Normative References.............................................19
Acknowledgments..................................................19
Author's Addresses...............................................20
Intellectual Property Statement..................................20
Copyright Statement..............................................21
1. Overview
1.1 General
This draft provides a survey of BGP-4 implementations, as defined by
[MP-BGP], that enable BGP to carry routing information for multiple
Network Layer protocols (e.g., IPv6, IPX, etc). These extensions
are often denoted as MP-BGP. The extensions are backward compatible
- a router that supports the extensions can interoperate with a
router that doesn't support the extensions.
The multi-protocol extensions for BGP are a widely deployed
cornerstone of Internet technology. This survey had 15 detailed
questions on the compliances with the standard. Of these 15
questions, 3 of the questions are informational (1, 10, and 15). Of
the remaining 12 questions, one of the questions (2) has 5 parts, of
which 3 are informational. The responses are listed in section 2,
and the full survey is listed in section 3.
5 implementers from Cisco, Juniper, Laurel, NextHop, and Redback
sent in implementation reports.
Hares Expires - December 2004 [Page 2]
^L
draft-ietf-idr-2858bis Survey Report July 2004
1.2 Full Survey result
Significant Differences
Of the 12 standards related questions, all questions had 2 or more
Yes responses. (Note question 2e - has the "O" response indicating
support for the attribute, but no support for SNPA).
Of the informational questions:
Question 1: Can your MPBGP support be configured to be "off"?
Cisco, Juniper, NextHOP and Redback indicated that the MP-BGP
Status could be configured off. Laurel indicated that MP-BGP
could not be configured off.
Questions 10: The actions upon more than one AFI/SAFI in MP-BGP
UPDATE messages is undefined. What action do you take?
Cisco: Takes the last AFI/SAFI in packet
Juniper: Processes AFI/SAFIs in order received
Laurel: Processes Withdraws, MP_REACH_NLRI, MP_UNREACH_NLRI, NLRI
NextHop: Processes Withdraws, MP_UNREACH_NLRI, MP_REACH_NLRI, NLRI
Redback: Processes last instance
Question 15: What SAFIs are supported: (for IPv4, or IPv6)
SAFIs 0-2 3 4 5-63 63-127 128-255
================================
Cisco Y R Y N N 128
Juniper Y N Y N N 128
Laurel Y N N N N 128
NextHop Y R Y N N 128
Redback Y N Y N NA NA
Y - support send/receive
R - only support receive
NA - not answered
1.3 Summary of questions
The following section provides a list of sections where all answers
were not "yes" to RFC 2119 questions (2-9, 11-14). This section is
provided to allow the reader a short cut to the interesting points.
SHOULD:
1) Question 4: Use of NextHop in MP_REACH_NLRI attribute
Hares Expires - December 2004 [Page 3]
^L
draft-ietf-idr-2858bis Survey Report July 2004
Yes: Cisco, Laurel, NextHop, Redback
No: Juniper
2) Question 8: Ignore Update message with no NLRI other than
MP_REACH_NLRI and with NEXT_HOP
Yes: Juniper, Laurel, NextHop, Redback
Optional: Cisco
SHOULD NOT:
1) Question 7: Update message with no NLRI, other than the one
coded in MP_REACH_NLRI attribute SHOULD NOT carry
the NextHop Attribute.
Yes: Juniper, Laurel, NextHop, Redback
Optional: Cisco
Please note, that Cisco has an optional setting that matches all
other implementations for questions 4,7, and 8.
1.4 Implementations and interoperability
Cisco Juniper Laurel NextHop Redback
=======================================
Cisco - Y Y Y Y
Juniper Y - - Y -
Laurel Y Y - Y
NextHop Y Y - - -
Redback Y Y - - -
1.5 BGP Implementation Identification
1.5.1 Cisco
Implementation Name/Version: Cisco BGP Implementation, 12.0(27)S
Date: 11/26/2003
1.5.2 Juniper
Implementation Name/Version: JUNOS 6.4
Date: June 2004
1.5.3 Laurel
Implementation Name/Version: Laurel Networks Release 3.0
Date: May 2004
1.5.4 NextHop Technologies
Hares Expires - December 2004 [Page 4]
^L
draft-ietf-idr-2858bis Survey Report July 2004
Implementation Name/Version: Gated NGC 2.0, 2.2
Date: January 2004
1.5.5 Redback
Implementation Name/Version: SEOS-2.5.7
Date: May 2004
1.6 BGP Survery respondant
1.6.1 Cisco
survey respondent: Russ White
email: ruwhite@cisco.com
time period: 5/09/02 - 6/15/04
1.6.2 Juniper
survey respondent: Pedro Roque Marques
email: roque@juniper.net
time period: 5/03/02 - 6/15/04
1.6.3 Laurel
survey respondent: Manish Vora
email: mvora@laurelnetworks.com
time period: 5/02/02 - 6/15/04
1.6.4 NextHop Technologies
survey respondent: Susan Hares
time period: 5/03/02 - 6/15/04
1.6.5 Redback
survey respondent: Enke Chen
email: enke@redback.com
time period: 5/03/02 - 6/15/04
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] language indicated. 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 [MP-BGP] for additional details.
Hares Expires - December 2004 [Page 5]
^L
draft-ietf-idr-2858bis Survey Report July 2004
2.1 Implementation Survey Results
This survey was first issued in May of 2002. This survey was reissued
in February through May of 2004 to update the original responses to
match the text in draft-ietf-idr-rfc2858bis-06.txt. The form of the
questions has retained the original 2002 form, but some sub-sections
have been added to match the current 2004 suggestions from the
Routing AD and IESG on implementation reports.
Each question indicates the status of the question as informational
or RFC 2119. For descriptions of MAY/SHOULD/MUST see RFC 2119. Each
question may also have questions attached.
-----------------------------------------------------
1) Can your MPBGP support be configured to be "off"?
If your MP-BGP support can be turned off, does
your implementation ignore information passed in
MP_REACH_NLRI and MP_UNREACH_NLRI, and not pass
it to other speakers.
section: 4
text: "This way a BGP speaker that doesn't support
the multiprotocol capabilities will just ignore the
information carried in these attributes, and will
not pass it to other BGP speakers."
status: informational
response: yes/no
survey results:
Cisco: yes
Juniper: yes
Laurel: yes
NextHop: yes
Redback: yes
2) Does your MPBGP support MP_REACH_NLRI and MP_UNREACH_NLRI for:
a) IP Unicast forwarding?
b) IP Multicast forwarding?
[Assumed in the above two questions are the following questions:
2a) MP_REACH_NLRI
section 5: "The MP_REACH_NLRI is an optional
non-transitive attribute with Type code 14."
Hares Expires - December 2004 [Page 6]
^L
draft-ietf-idr-2858bis Survey Report July 2004
2b) MP_UNREACH_NLRI type is 15
section 6: "the MP_UNREACH_NLRI" is an optional
non-transitive attribute with Type code 15."
2c) AFI values used are specified by RFC 1700
section 5: "Presently defined values for the
Address Family Identifier field are specified
in RFC1700 (see the Address Family Numbers."
[Editor's note: RFC 1700 has be replaced by an online IANA
database at www.iana.org.]
2d) SAFI MAY support all, some or none of the SAFIs
section 5: "This document defines the following values
for the Subsequent Address Family Identifier
field carried in the MP_REACH_NLRI and
MP_UNREACH_NLRI attributes:
1 - Network Layer Reachability Information
used for unicast forwarding
2 - Network Layer Reachability Information
used for multicast forwarding.
An implementation MAY support all, some, or
none of the Subsequent Address Family Identifier
values defined in this document."
2e) SNPA padding of odd semi-octets is done in all zeros
section 5: "If the SNPA contains an odd number of semi-octets,
a value in this field will be padded with a
trailing all-zero semi-octet."
status: 2a-2c informational, 2d-2e - RFC 2119
response: yes/no/optional
survey results:
2a 2b 2c 2d 2e Comments
============================================
Cisco y y y y y 2e: no SNPAs sent
Juniper y y y y y 2e: no SNPAs sent
Laurel y y y y y 2e: No SNPAs sent
NextHop y y y y y
Redback y y y y y
2d comments: Cisco: (1) Unicast and (2) Multicast
3) No SNPAs listed in MP_UNREACH_NLRI
section 5: "The value 0 SHALL be used to indicate that no SNPAs
Hares Expires - December 2004 [Page 7]
^L
draft-ietf-idr-2858bis Survey Report July 2004
are listed in this attribute."
status: RFC 2119
response: yes/no/optional
survey results:
Cisco: yes
Juniper: yes comment: No SNPAs are sent
Laurel: yes comment: No SNPAs are sent
NextHop: yes
Redback: yes comment: No SNPAs are sent
4) MPBGP NextHop field
section 5: "The next hop information carried in the MP_REACH_NLRI
path attribute defines the Network Layer address of
the border router that SHOULD be used as the next hop
to the destinations listed in the MP_NLRI attribute in
the UPDATE message."
status: RFC 2119
response: yes/no/optional
survey results:
Cisco: yes
Juniper: no
Laurel: yes
NextHop: yes
Redback: yes
5) MPBGP update with messages that caries no NLRI other than in the
MPBGP attribute
section 5: "An UPDATE message that carries the MP_REACH_NLRI MUST
also carry the ORIGIN and the AS_PATH attributes (both
in EBGP and in IBGP exchanges)."
status: RFC 2119
response: yes/no/optional
survey results:
Cisco: yes
Juniper: yes
Laurel: yes
NextHop: yes
Redback: yes
Hares Expires - December 2004 [Page 8]
^L
draft-ietf-idr-2858bis Survey Report July 2004
6) IBGP Update messages must carry LOCAL_PREF with MP_REACH_NLRI
section 5: "Moreover, in IBGP exchanges such a message MUST also
carry the LOCAL_PREF attribute. "
status: RFC 2119
response: yes/no/optional
survey results:
Cisco: yes
Juniper: yes
Laurel: yes
NextHop: yes
Redback: yes
7) Update with no NLRI other than MP_REACH_NLRI SHOULD NOT carry the
NEXT_HOP attribute
section 5: "An UPDATE message that carries no NLRI, other than the
one encoded in the MP_REACH_NLRI attribute, SHOULD NOT
carry the NEXT_HOP attribute."
status: RFC 2119
response: yes/no/optional
survey results:
Cisco: Optional
Comment: SAFI 1: only NEXT_HOP for IPv4
SAFI 2: NextHop for MP_REACH_NLRI and normal NLRIs,
Other Safis - no NEXT_HOP
Juniper: yes
Laurel: yes
NextHop: yes - Allows option to work around other vendors bug.
Redback: yes - Allows option to work around other vendors bug.
8) Reception of an UPDATE with no NLRI other than MP_REACH_NLRI
and NEXT_HOP attribute
section 5: "If such a message contains the NEXT_HOP attribute,
the BGP speaker that receives the message SHOULD
ignore this attribute."
status: RFC 2119
response (yes/no/optional):
survey results:
Cisco: yes
Juniper: yes
Laurel: yes
NextHop: yes
Redback: yes - Allows option to work around other vendors bug.
Hares Expires - December 2004 [Page 9]
^L
draft-ietf-idr-2858bis Survey Report July 2004
9) Only one instance of AFI/SAFI
Section 5: "An UPDATE message SHOULD NOT include the same address
prefix (of the same <AFI, SAFI>) in more than one of
the following fields: WITHDRAWN ROUTES field, Network
Reachability Information fields, MP_REACH_NLRI field,
and MP_UNREACH_NLRI field."
status: RFC 2119
response (yes/no/optional):
survey results:
Cisco: yes
Juniper: yes
Laurel: yes
NextHop: yes
Redback: yes
10) Processing of more than one instance of AFI/SAFI is undefined:
Section 5: "Processing of such an update in this form is
undefined."
What happens if you receive more than one AFI/SAFI?
status: informational
response: (comments only)
Cisco: Takes the last AFI/SAFI in packet
Juniper: Processes AFI/SAFIs in order received
Laurel: Processes Withdraws, MP_REACH_NLRI, MP_UNREACH_NLRI, NLRI
NextHop: Processes Withdraws, MP_UNREACH_NLRI, MP_REACH, NLRI
Redback: Process last instance
[Editor's note:
The sentence in question 10 follows the text in question 9.
Please refer to the [MP-BGP] specification for the full text.]
11) Does your BGP implementation, upon receiving an update with an
incorrect MP_REACH_NLRI or MP_UNREACH_NLRI:
a) delete all routes from that same SAFI/AFI?
Section 9: "If a BGP speaker receives from a neighbor an
Update message that contains the MP_REACH_NLRI or
MP_UNREACH_NLRI attribute, and the speaker
Hares Expires - December 2004 [Page 10]
^L
draft-ietf-idr-2858bis Survey Report July 2004
determines that the attribute is incorrect, the
speaker MUST delete all the BGP routes received
from that neighbor whose AFI/SAFI is the same as
the one carried in the incorrect MP_REACH_NLRI or
MP_UNREACH_NLRI attribute."
b) Ignore all subsequent routes with that AFI/SAFI? [SHOULD], or
Section 9: "For the duration of the BGP session over which the
Update message was received, the speaker
then SHOULD ignore all the subsequent routes
with that AFI/SAFI received over that session."
c) Terminate the session? [MAY] with "Update Message
Error"/"Optinal Attribute Error".
Section 9: "In addition, the speaker MAY terminate the BGP
session over which the Update message was received."
d) (if terminated)
Section 9: "The session SHOULD be terminated with the
Notification message code/subcode indicating
"Update Message Error"/"Optional Attribute Error".
status: RFC 2119
response: yes/no/optional
survey results:
11a 11b 11c 11d
====================
Cisco y y y y
Juniper y y y y
Laurel y y y y
NextHop y y y y
Redback y y y y
12) Does the BGP use the BGP Capability advertisement to determine
whether the speaker can use MP extensions with a peer?
section 10: "A BGP speaker that uses Multiprotocol Extensions
SHOULD use the Capability Advertisment procedures
[BGP-CAP] to determine whether the speaker could
use Multiprotocol Extensions with a particular
peer."
[BGP-CAP] "Capabilities Advertisement with BGP-4",
R. Chandra, J. Scudder, RFC2842, May 2000
Hares Expires - December 2004 [Page 11]
^L
draft-ietf-idr-2858bis Survey Report July 2004
status: RFC 2119
response: yes/no/optional
survey results:
Cisco: yes
Juniper: yes
Laurel: yes
NextHop: yes
Redback: yes
13) Are the fields: afi, res, safi in the Capability announcement
have Res. (reserved) set to zero by the sender and ignored by the
receiver?
section 10:
"Res. - Reserved (8 bit) field. Should be set to 0 by the
sender and ignored by the receiver."
status: RFC 2119
response: yes/no/optional
survey results:
Cisco: yes
Juniper: yes
Laurel: yes
NextHop: yes
Redback: yes
14) Do you support bi-directional exchange via cross advertisement of
capabilities?
section 10: "To have a bi-directional exchange of routing
information for a particular <AFI, SAFI> between a
pair of BGP speakers, each such speaker MUST advertise
to the other (via the Capability Advertisement
mechanism) the capability to support that particular
<AFI, SAFI> routes."
status: RFC 2119
response: yes/no/optional
survey results:
Cisco: yes
Juniper: yes
Laurel: yes
NextHop: yes
Redback: yes
15) What ranges of SAFI are supported in your implementation:
Hares Expires - December 2004 [Page 12]
^L
draft-ietf-idr-2858bis Survey Report July 2004
a) SAFI 0 - reserved
b) SAFI 1-2 - defined by document
c) SAFI 3 - no longer defined by draft
d) SAFI 4-63 - IANA Assigned, IETF consensus
e) SAFI 64-127 - IANA Assigned,
f) SAFI 128-255 - private use
status: informational only
response: (per a-f comment: yes/no)
survey response:
SAFIs 0-2 3 4 5-63 63-127 128-255
================================
Cisco Y R Y N N 128
Juniper Y N Y N N 128
Laurel Y N N N N 128
NextHop Y R Y N N 128
Redback Y N Y N NA NA
Y - support send/receive
R - only support receive
NA - not answered
16) What other implementations do you inter-operate with?
status: informational
response: comments
survey results:
Cisco: most implementations
Juniper: most implementations
Laurel: Cisco, Juniper, Redback
NextHop: Cisco, Juniper
Redback: Cisco, Juniper
3. Survey Form
(Survery version: 4)
Contributor:
Company:
Software:
Release:
Date:
-----------------------------------------------
Instructions:
Hares Expires - December 2004 [Page 13]
^L
draft-ietf-idr-2858bis Survey Report July 2004
This survey was first issue in 5/2002. I am re-issuing this survey
for any new participants. The form of the questions has retained
it's original 2002 form, but some sub-sections have been added to
match the current 2004 suggestions from the Routing AD and IESG on
implementation reports.
For descriptions of MAY/SHOULD/MUST see RFC 2026.
Questions without MAY/SHOULD/MUST in the section text are
informational only and are not required for a conformant
implementation.
1) Can your MPBGP support be configured to be "off"?
If your MP-BGP support can be turned off, does
your implementation ignore information passed in
MP_REACH_NLRI and MP_UNREACH_NLRI, and not pass
it to other speakers.
section: 4
text: "This way a BGP speaker that doesn't support
the multiprotocol capabilities will just ignore the
information carried in these attributes, and will
not pass it to other BGP speakers."
response: (yes/no/optional)
status: informational
comments:
2) Does your MPBGP support MP_REACH_NLRI and MP_UNREACH_NLRI for:
a) IP Unicast forwarding?
b) IP Multicast forwarding?
[Assumed in the above two questions are the following questions:
2a) MP_REACH_NLRI
section 5: "The MP_REACH_NLRI is an optional
non-transitive attribute with Type code 14."
2b) MP_UNREACH_NLRI type is 15
section 6: "the MP_UNREACH_NLRI" is an optional
non-transitive attribute with Type code 15."
2c) AFI values used are specified by RFC 1700
section 5: "Presently defined values for the
Address Family Identifier field are specified
in RFC1700 (see the Address Family Numbers."
Hares Expires - December 2004 [Page 14]
^L
draft-ietf-idr-2858bis Survey Report July 2004
2d) SAFI MAY support all, some or none of the SAFIs
section 5: "This document defines the following values
for the Subsequent Address Family Identifier
field carried in the MP_REACH_NLRI and
MP_UNREACH_NLRI attributes:
1 - Network Layer Reachability Information
used for unicast forwarding
2 - Network Layer Reachability Information
used for multicast forwarding.
An implementation MAY support all, some, or
none of the Subsequent Address Family Identifier
values defined in this document."
2e) SNPA padding of odd semi-octets is done in all zeros
section 5: "If the SNPA contains an odd number of semi-octets,
a value in this field will be padded with a
trailing all-zero semi-octet."
status: 2a-2c informational, 2d-2e - RFC 2119
response: (yes/no/optional)
comments:
3) No SNPAs listed in MP_UNREACH_NLRI
section 5: "The value 0 SHALL be used to indicate that no SNPAs
are listed in this attribute."
status: RFC 2119
response: (yes/no/optional)
comments:
4) MPBGP NextHop field
section 5: "The next hop information carried in the MP_REACH_NLRI
path attribute defines the Network Layer address of
the border router that SHOULD be used as the next hop
to the destinations listed in the MP_NLRI attribute in
the UPDATE message."
status: RFC 2119
response: (yes/no/optional)
5) MPBGP update with messages that caries no NLRI other than in the
MPBGP attribute
Hares Expires - December 2004 [Page 15]
^L
draft-ietf-idr-2858bis Survey Report July 2004
section 5: "An UPDATE message that carries the MP_REACH_NLRI MUST
also carry the ORIGIN and the AS_PATH attributes (both
in EBGP and in IBGP exchanges)."
status: RFC 2119
response: (yes/no/optional)
comments:
6) IBGP Update messages must carry LOCAL_PREF with MP_REACH_NLRI
section 5: "Moreover, in IBGP exchanges such a message MUST also
carry the LOCAL_PREF attribute."
status: RFC 2119
response: (yes/no/optional)
comments:
7) Update with no NLRI other than MP_REACH_NLRI SHOULD NOT carry the
NEXT_HOP attribute
section 5: "An UPDATE message that carries no NLRI, other than
the one encoded in the MP_REACH_NLRI attribute,
SHOULD NOT carry the NEXT_HOP attribute."
status: RFC 2119
response: (yes/no/optional)
comments:
8) Reception of an UPDATE with no NLRI other than MP_REACH_NLRI
and NEXT_HOP attribute
section 5: "If such a message contains the NEXT_HOP attribute,
the BGP speaker that receives the message SHOULD
ignore this attribute."
status: RFC 2119
response (yes/no/optional):
comments:
9) Only one instance of AFI/SAFI
Section 5: "An UPDATE message SHOULD NOT include the same address
prefix (of the same <AFI, SAFI>) in more than one of
the following fields: WITHDRAWN ROUTES field, Network
Reachability Information fields, MP_REACH_NLRI field,
and MP_UNREACH_NLRI field."
status: RFC 2119
Hares Expires - December 2004 [Page 16]
^L
draft-ietf-idr-2858bis Survey Report July 2004
response (yes/no/optional):
comments:
10) Processing of more than one instance of AFI/SAFI is undefined:
Section 5: "Processing of such an update in this form is
undefined."
What happens if your receive more than one AFI/SAFI?
response: (comments only)
status: informational
11) Does your BGP implementation, upon receiving an update with an
incorrect MP_REACH_NLRI or MP_UNREACH_NLRI
a) delete all routes from that same SAFI/AFI?
section 9: "If a BGP speaker receives from a neighbor an
Update message that contains the MP_REACH_NLRI
or MP_UNREACH_NLRI attribute, and the speaker
determines that the attribute is incorrect, the
speaker MUST delete all the BGP routes received
from that neighbor whose AFI/SAFI is the same as
the one carried in the incorrect MP_REACH_NLRI
or MP_UNREACH_NLRI attribute."
b) Ignore all subsequent routes with that AFI/SAFI? [SHOULD], or
Section 9: "For the duration of the BGP session over which
the Update message was received, the speaker
then SHOULD ignore all the subsequent routes
with that AFI/SAFI received over that session."
c) Terminate the session? [MAY]
with "Update Message Error"/"Optinal Attribute Error".
Section 9: "In addition, the speaker MAY terminate the BGP
session over which the Update message was
received."
d) (if terminated)
Section 9: "The session SHOULD be terminated with the
Notification message code/subcode indicating
"Update Message Error"/"Optional Attribute
Error".
response:(yes/no/optional) (respond to 11a-11d)
status: RFC 2119
Hares Expires - December 2004 [Page 17]
^L
draft-ietf-idr-2858bis Survey Report July 2004
12) Does the BGP use the BGP Capability advertisement to determine
whether the speaker can use MP extensions with a peer?
section 10: "A BGP speaker that uses Multiprotocol Extensions
SHOULD use the Capability Advertisment procedures
[BGP-CAP] to determine whether the speaker could
use Multiprotocol Extensions with a particular
peer."
[BGP-CAP] "Capabilities Advertisement with BGP-4",
R. Chandra, J. Scudder, RFC2842, May 2000
status: RFC 2119
response(yes/no/optional):
comments:
13) Are the fields: afi, res, safi in the Capability announcement
have Res. (reserved) set to zero by the sender and ignored by the
receiver?
section 10:
"Res. - Reserved (8 bit) field. Should be set to 0 by the
sender and ignored by the receiver."
status: RFC 2119
response (yes/no/optional):
comments:
14) Do you support bi-directional exchange via cross advertisement of
capabilities?
section 10: "To have a bi-directional exchange of routing
information for a particular <AFI, SAFI> between a
pair of BGP speakers, each such speaker MUST
advertise to the other (via the Capability
Advertisement mechanism) the capability to support
that particular <AFI, SAFI> routes."
status: RFC 2119
response (yes/no/optional):
comments:
15) What ranges of SAFI are supported in your implementation:
a) SAFI 0 - reserved
Hares Expires - December 2004 [Page 18]
^L
draft-ietf-idr-2858bis Survey Report July 2004
b) SAFI 1-2 - defined by document
c) SAFI 3 - no longer defined by draft
d) SAFI 4-63 - IANA Assigned, IETF consensus
e) SAFI 64-127 - IANA Assigned,
f) SAFI 128-255 - private use
response: (per a-f comment: yes/no)
status: informational only
16) What other implementations do you inter-operate with?
response:
status: informational only
4. Security Considerations
This document does not address any security issues.
Normative References
[MP-BGP] Bates, T., Chandra, R. , Katz, D., Rekhter, Y.,
"Multiprotocol Extensions for BGP-4",
draft-ietf-idr-rfc2858bis-06.txt, May 2004
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, March 1997
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
February 2004
[RFC3668] Bradner, S. "Intellectual Property Rights in IETF
Technology", BCP 79, February 2004
Acknowledgments
My thanks to Russ White(Cisco), Pedro Marques (Juniper), Manish Vora
(Laurel Networks), and Enke Chen (Redback) for responding to lots of
email regarding this survey. My thanks to Matt Richardson and Jeff
Hares Expires - December 2004 [Page 19]
^L
draft-ietf-idr-2858bis Survey Report July 2004
Haas of NextHop for help with the NextHop Survey form. My thanks to
Jeff Haas and Dave Hares on editorial comments.
Author's Addresses
Susan Hares
NextHop Technologies
825 Victors Way, Suite 100
Phone: 734.222.1610
Email: skh@nexthop.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Hares Expires - December 2004 [Page 20]
^L
draft-ietf-idr-2858bis Survey Report July 2004
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hares Expires - December 2004 [Page 21]
^L
