One document matched: draft-hlmu-l2vpn-bgp-discovery-01.txt
Differences from draft-hlmu-l2vpn-bgp-discovery-00.txt
L2VPN Working Group Paul Unbehagen
Internet Draft Praveen Muley
Expiration Date: February 2005 Vasile Radoaca
Document: draft-hlmu-l2vpn-bgp-discovery-01.txt Nortel Networks
Chitanya Kodeboyina Sue Hares
Juniper Next Hop
Peter Busschbach Wei Luo
Lucent Cisco Sytems
October 2004
BGP-based Auto-Discovery for L2VPNs
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [i].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
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
"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."
"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."
Abstract
This document defines a mechanism of using BGP for the discovery of
L2VPN membership information. The L2VPN membership information can be
used by a L2VPN signaling protocol to set up pseudowires for L2VPNs,
such as VPWS and VPLS.
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 RFC2119.
Table of Contents
1. Introduction...................................................2
2. Auto-Discovery Overview........................................3
2.1 Assumptions................................................3
2.2 Reference Model............................................3
3. BGP Protocol Details...........................................4
3.1 Overview...................................................4
3.2 AFI/SAFI encoding..........................................5
3.3 NLRI Encodings.............................................5
3.4 Capabilities Advertisement for L2VPN Auto-Discovery........6
3.5 Use of RT for Auto-Discovery...............................6
3.6 Use of RT for L2VPN Topology...............................6
4. Inter-AS Auto-Discovery........................................7
4.1 Proxy Mode.................................................8
4.2 Transparent Mode...........................................8
5. Forwarder Removal..............................................9
6. Security Considerations........................................9
7. RD Value Selection............................................10
8. Dynamic Signaling Session Creation............................10
9. References....................................................11
10. Acknowledgments..............................................12
11. AuthorÆs Addresses...........................................12
1. Introduction
L2VPN signaling protocols described in [L2VPN-SIG] specify the
signaling procedures to set up various L2VPN models as defined in
[L2VPN-FRAME]. This document describes an auto-discovery mechanism
for the L2VPN membership information that is needed in order to
initiate the signaling process. For each VPN, the membership
information consists of the set of Forwarders, an identifier for
each Forwarder, the IP address of each Forwarder's PE, and any
other information which is needed in order to initiate the signaling
procedures. This information is encoded and distributed to other PEs
through BGP update messages with support for both Generalized ID (GID)
and Psuedowire ID (PW-id) FECs.
2. Auto-Discovery Overview
[BGP-AUTO] describes the general framework of using BGP for auto-
discovery of both L2VPNs and L3VPNs using BGP. The auto-discovery
mechanism specified in this document is built on this framework, and
the VPN membership information obtained through this mechanism can be
used by L2VPN signaling protocols, such as LDP or L2TP. In order to
participate in the auto-discovery process, the PEs must support
Multi-Protocol BGP [MPBGP] and BGP Capabilities Advertisement [BGP-
DYNCAP].
The BGP-AD process is used to automate the provisioning aspects of a
VPN, in order to automate the signaling process. Hence the use of
BGP is for the announcement and/or deletion of a VPN on a PE. Once a
L2VPN is torn down, then BGP should remove all L2VPN membership
information from all other PEs.
2.1 Assumptions
It is assumed that the PEÆs that participate in the auto-discovery
process have the capability of using BGP peerings supporting MP-BGP
and open capability negotiations. The BGP-AD exchange messages
contain the information that is needed for LDP signaling, called
L2VPN membership information [L2VPN-MI].
As such for GID: AGI, AII, PE-id
And for PW-id: PW-type, PW-id, PE-id
It is also assumed that multiple topologies need to be supported such
as a single AS, multiple AS, multiple SP, and a hierarchical model
with access networks and a BGP core. This document is currently
focusing on the first two cases.
Besides the function of auto-discovery an additional service is
creating multiple L2VPN topologies such as point to point, point to
multipoint, and multipoint to multipoint L2VPNS.
2.2 Reference Model
The following diagram shows an example of an L2VPN that uses BGP
auto-discovery. Each PE can communicate with one another through BGP
sessions that are established either directly between PEs or by the
way of route reflectors. The BGP sessions are used to advertise L2VPN
membership information among the PEs. Once PEs learn such information,
they can establish L2VPN signaling connections and pseudowires
accordingly.
PE-1 PE-2
+-------------+ +--------------+
+--------+ | +---------+ | | +----------+ | +--------+
| VPN-A | | | | | | | | | | VPN-A |
| Site1 |--| |Forwarder| | BGP VPN | |Forwarder | |-| site2 |
+--------+ | | A | |<----------->| | A | | +--------+
| +---------+ | Discovery | +----------+ |
| | | |
+--------+ | +---------+ | | +----------+ | +--------+
| VPN-B | | | | | +---------+ | | | | | VPN-B |
| Site1 |--| |Forwarder| |-|Backbones|-| |Forwarder | |-| site2 |
+--------+ | | B | | +---------+ | | B | | +--------+
| +---------+ | | +----------+ |
| | | |
+--------+ | +---------+ | | +----------+ | +--------+
| VPN-C | | | | | Signaling | | | | | VPN-C |
| Site1 |--| |Forwarder| |<----------->| |Forwarder | |-| site2 |
+--------+ | | C | | Protocol | | C | | +--------+
| +---------+ | | +----------+ |
+-------------+ +--------------+
[L2VPN-SIG] specifies that each Forwarder is represented by a
Forwarder Identifier which is the concatenation of an Attachment
Group Identifier (AGI) and an Attachment Individual Identifier (AII).
To advertise a Forwarder, the AGI and AII are encoded in BGP MP-NLRI
fields and distributed to PEs participating in L2VPN auto-discovery.
All Forwarders belonging to the same L2VPN will have the same AGI.
When a PE receives a Forwarder advertisement through BGP, it uses the
AII encoded in the advertisement as the Target AII (TAII) for the
L2VPN signaling protocol. The Source AII (SAII) of the local
Forwarder is known through local configuration on the PE. When a
Forwarder previously advertised is removed from a PE, the PE needs to
withdraw the AGI and AII of this Forwarder.
3. BGP Protocol Details
3.1 Overview
The BGP auto-discovery specified in this document is similar to the
schemes described [BGPVPN] and [LDPVPN], but further optimized. This
introduction provides the background on these mechanisms.
The L2VPN mechanisms have been designed to support both VPWS and VPLS
(normal and GVPLS). The mechanisms have been optimized to support the
rapid growth of either VPWS or VPLS usage.
The BGP multi-protocol attribute has the following fields [MPBGP]:
[AFI] [SAFI] [length of next hop] [next hop address] [number of
SNPAs] [length of SNPA1] [SNPA1][length of SNPA2] [SNPA2] ...
[length of SNPAn] [SNPAn]
BGP auto-discovery makes use of the coloring of routes in BGP and the
attachment of next hop addresses to a particular sub-network point of
attachment (SNPA) in the multi-protocol attribute.
The coloring of routes passed in the BGP protocol can be done by
associating either a BGP Community (normal [BGPCOMM] or extended
[BGPEXTCOMM]), and or extended information in the multi-protocol
Network Layer Reachability Information (NLRI). In L3VPNs [2547bis],
the coloring is done via a:
- Route Target as an Extended Community attribute, and
- an AFI/SAFI pair that allows the NLRI to be encoded as
12 bytes with 8 byte Route Distinguisher and a 4 byte IP v4
address.
The encoding of the AFI/SAFI alerts the L3VPNs that this AFI/SAFI
pair is used for L3VPNs.
As the use of additional BGP address families has increased, there
have been worries that problems with one address family with affect
other families. New BGP work items have been proposed to reduce the
"fate sharing" between different address families. These proposed
BGP mechanisms include: route-refresh limited to a AFI-SAFI pair
[BGPREFRESH], bundling of AFI/SAFIs over a TCP connection [BGP-
BUNDLE-TCP]. While proposed BGP mechanisms are under consideration of
the IDR group and have some deployment, these items have not been
approved as BGP drafts.
These mechanisms can also reduce the fate-sharing of auto-discovery
mechanisms for different L2VPNS. If explosive growth occurs in
either the VPWS or VPLS deployments, utilizing these AFI/SAFI
isolation mechanisms may allow splitting of the processing of auto-
discovery mechanisms.
3.2 AFI/SAFI encoding
The AFI value of XXXX (assigned by IANA) is used for all L2VPN
applications referred to as the L2VPN Auto Discovery Address Family.
The SAFI value will be set the following bit pattern:
0000 00LW -- where
L is the presence of VPLS
W is the presence of VPWS
Future deployments that expect either VPWS or VPLS but not both in an
L2VPN may set the SAFI value in the AFI/SAFI encoding to 1 for VPWS
or 2 for VPLS.
3.3 NLRI Encodings
The encoding of the NRLI in the MP-BGP attribute is based on the
AFI/SAFI identifiers. For L2VPNs, the SAFI values of 1-3 will have
the following NLRI encoding:
Length of NLRI in bits, NLRI field (variable length)
Where the NLRI field is further defined as:
Length of AGI (in bits), AGI (variable),
Length of AII (in bits), AII (variable)
3.4 Capabilities Advertisement for L2VPN Auto-Discovery
In order for two BGP speakers to exchange L2VPN NLRI, they MUST use
negotiation scheme defined in [MPBGP-RFC 2842] to ensure both of them
capable of processing such NLRI correctly. Two BGP speakers
exchanging L2VPN NLRI service MAY use the dynamic capabilities
negotiation scheme defined utilizing the new capabilities message
[BGP-DYNCAP].
With either negotiation, the peer will specify the Multi-protocol
Extensions (capability 1) including in the capability list the
AFI/SAFI pairs for L2VPNs. As example, a BGP peer could announce in
the capability could specific AFI(XXX)/SAFI(1), AFI(XXX)/SAFI(2),
AFI/SAFI(3).
3.5 Use of RT for Auto-Discovery
In order for a Layer 2 Forwarder to be discovered via the procedures
of this specification, it must be provisioned with a Forwarder
Identifier and with a Route Target (RT) Extended Communities
attribute. This RT is known as the Forwarder's "Export RT". The PE
which contains the forwarder will advertise an NLRI which is
constructed from the AGI and AII. The RT will be transmitted as an
attribute of the NLRI.
3.6 Use of RT for L2VPN Topology
The RTs are utilized in BGP to control NLRI distribution. In addition
to being configured with an Export RT, each Forwarder must be
configured with one or more Import RTs. If a PE receives a
particular NLRI in the L2VPN Auto-Discovery Family, and there is no
RT such that (a) the RT is one of the Extended Communities attributes
of that NLRI, and (b) the RT is one of the Import RTs of one of the
PE's Forwarders, then that NLRI is filtered. The RTs can also be
used as filters at intermediate BGP speakers to constrain the
distribution of the auto-discovery information.
To form a full mesh, each Forwarder is configured with the same RT
value for both the "export RT" and the "import RT". This
distribution policy allows the Forwarders to be visible to all BGP
speakers having the same Route Target (Extended Community value).
After the all BGP peers have the Layer-2 information, they can set up
a full mesh of pseudowires among these Forwarders using the L2VPN
signaling procedures. (Note: Other BGP policy may not utilize Route
Targets and fully distribute the L2VPN information to all BGP
speakers within the full mesh. The key is the full distribution of
Layer-2 endpoints to the BGP speakers setting up the full mesh.)
Sometimes, a hub-and-spoke L2VPN network is desired. This can be
achieved by using two different RTs for distribution processing,
where one stands for "hub" and the other stands for "spoke". On the
hub PE, the "hub" RT is assigned to local Forwarders as the "export
RT", and the hub PE is configured to "import" only the L2VPN NLRIs
that have the "spoke" RT. On the spoke PE, the "spoke" RT is assigned
to the local Forwarders as the "export RT", and the spoke PE is
configured to "import" only the L2VPN NLRIs that have the "hub" RT.
This distribution policy will result in (1) spoke PEs only seeing the
Forwarders configured on the hub PE, and (2) a hub PE seeing all
Forwarders configured on every spoke PE. The L2PVN signaling then
sets up pseudo-wires that form the hub-and-spoke topology.
A more complex topology is partial mesh topology. The partial mesh
topology can be creaated by using sets of "import RTs" and "export
RTs" to control route distributions.
4. Inter-AS Auto-Discovery
L2VPNS can span across multiple AS domains, network regions or
multiple SPs. In [L2VPN-SIG] is described a model where the L2VPN PWs
are decomposed in multiple PWs [called Single Hop PW]. Those SH-PWs,
are stitched together in order to create a logical PW end to end,
called Multi Hop PW.
This model can be used for P2P PW or VPLS services. However, in the
current proposal, it's described only the P2P PW case, and the
Hierarchical VPLS remaining for further work.
When PEs participating in L2VPNs reside in more than one AS, the BGP
auto-discovery procedures need to ensure that VPN membership
information can be communicated across AS boundaries. Depending on
how Forwarders on the PEs are connected in Inter-AS L2VPNs, ABSRs
operate in different modes which follow different procedures for
L2VPN auto-discovery.
PE-1 ----+ +---- PE-3
| |
| |
ASBR-1 ------- ASBR-2
| |
| |
PE-2 ----+ +---- PE-4
|<-- AS1 -->| |<-- AS2 -->|
4.1 Proxy Mode
Some network operators want to enforce certain policies including
those of L2VPNs at the AS boundaries, and they want L2VPN signaling
connections and pseudowires to be confined within an AS. In this mode
of operation, an ASBR acts as a æProxyÆ PE that establishes and
manages signaling connections and pseudowires to the PEs in its own
AS on behalf of the PEs in another AS.
Proxy mode allows a SP to bind the number of control connections. It
also allows SPÆs to confine the control connections to border routers
and use MD5 authentication to secure the control connection.
To connect two Forwarders on PE-1 and PE-3 respectively for instance,
three pseudowires need to be established and spliced together: one
from PE-1 to ASBR-1, one from ASBR-1 to ASBR-2, and one from ASBR-2
to PE-3.
Prior to establishing the pseudowires, PE-1 announces its Forwarder
information through a BGP update message. When receiving the BGP
update, ASBR-1 replaces the next-hop address with its own address so
that the recipient of the update thinks that ASBR-1 is provisioned
with the Forwarder being advertised. In order to keep track of the
originating PE, the BGP Identifier of PE-1 is recorded in the first
SNPA field. ASBR-1 then announces the update to ASBR-2 with:
- next-hop address of ASBR-1, and
- SNPA1 filled with PE-1 BGP Identifier (Router-ID).
When ASBR-2 receives the update from ASBR-1, it performs the same
procedures as ASBR-1, so it announces the update to all PEs in AS2
with:
- next-hop address of ASBR-2, and
- SNPA1 with PE1 BGP Identifier (Router-ID), and
- SNPA2 with ASBR-1 BGP Identifier (Router-ID).
From the perspective of PE-3, the remote Forwarder advertised through
the update message is provisioned on ASBR-2, so PE-3 needs to set up
a pseudowire to ASBR-2 in order to connect to the remote Forwarder.
4.2 Transparent Mode
In this mode, L2VPN signaling connections and pseudowires traverse
the AS boundaries and are directly established between the PEs on
which Forwarders are provisioned. That is, ASBRs treat pseudowires
transparently and do not keep any stateful information of pseudowires.
This deployment would most often be deployed within an enterprise or
carrier where the AS boundaries group information but do not provide
a hard boundary to the L2VPNs.
The ASBRs that deal with the AS confederations that replaced an IBGP
mesh may be a candidate to utilize the transparent mode. It is key
for the deployment and management issues to understand that the ASBRs
that do not support L2VPN auto-discovery and are included in the
transparent mode:
- must pass the information transparently through the router
without modification.
- will not keep any information about the state of the pseudo-
wires.
The ASBR that transparently pass the information can either:
1) support the L2VPN AFI/SAFI but be configured not
to participate in the L2VPN signaling procedures, or
2) be configured to transitive MP-BGP attributes without
processing any MP-BGP attributes.
For example, When receiving BGP updates that contain L2VPN NLRIs from
PEs in AS1, ASBR-1 simply relays them to the neighboring ASBR-2 which
further relays them to PEs in AS2 without modification.
Besides passing the NLRIs, the transparent ASBRs also need to provide
Inter-AS network reachability for the PEs so that they can establish
L2VPN signaling connections and pseudowires to each other.
Entities utilizing the transparent mode must be careful to consider
all BGP issues, L2VPN signaling and policy issues. L3VPN also
utilizes this transparent mode of operation [2547bis].
5. Forwarder Removal
On removal of forwarder on PE will result in withdrawal of the AGI
using MP_UNREACH_NLRI attribute in update message in BGP. The
withdrawn routes encoding in MP_UNREACH_NLRI attribute is based on
the AFI/SAFI identifiers. For L2VPNs, the SAFI values of 1-3 will
have the following NLRI encoding:
Length of withdrawn NLRI in bits, NLRI field (variable length)
Where the NLRI field is further defined as:
Length of AGI (in bits), AGI (variable)
PE MUST withdraw the previous advertisement through BGP irrespective
of signaling session notification of forwarder removal.
6. Security Considerations
For the BGP sessions used for L2VPN auto-discovery, TCP MD5
authentication can be utilized. The L2VPN signaling protocols may
also use its native authentication mechanisms for security. For
example, LDP has TCP MD5 authentication as well, and L2TP has a CHAP-
like authentication scheme.
7. RD Value Selection
L2VPN auto-configurations are being deployed to ease the
configuration burden of L2VPNs over MPLS. In choosing an RD, it is
important to understand the issues between the three existing types
of RD values. For ease of transition between type 0-2 RD values, it
may be useful to restrict the assigned number to 2 bytes.
The following is the definition of the RD bytes from [BGP2547bis]:
[type (2 octets)]
[Value (6 octets)]
type 0: [Administrator (2 octets), Assigned number (4 octets)]
type 1: [Administrator (4 octets), Assigned number (2 octets)]
type 2: [Administrator (4 octets), Assigned number (2 octets)]
A type 0 RD Administrator filed has two octets for an Administrator
value (2 bytes) that is drawn from the public autonomous system (AS)
number space combined with a 4 byte assigned number. Today, the AS
numbers fit within 2 bytes. Within 3-7 years, the AS numbers may
exceed the 2 byte space, and require the 4 byte AS numbers. It would
be wise to only use the 2 bytes of Assigned number for type 0 and
type 2 assigned numbers. Type 1 uses an assigned IP address [4 bytes]
as the administrator identifier. This address in the type 1 RD
administrator field should utilize.
The type 1 RD administrator field an IP address is from the public IP
address space. Private address numbers used for administrator
numbers should not be used in RDs. Use of private address numbers
(such as network 10) may run into collisions with two network
deployments using the same IP address.
8. Dynamic Signaling Session Creation
The purpose of BGP auto-configuration is to reduce the configuration
burden for setup of psuedowires. In deployment of the BGP auto-
discovery just as in the normal BGP, the policy controlling the auto-
configuration uses configuration plus the existence of the
information in BGP as the impetus to establish a signaling session.
Signaling sessions MAY be established before or after the BGP auto-
discovery phase is completed. This can be done in two ways:
1. Each PE can have a signaling session manually created to all the
PEs participating in L2VPN in the network before the BGP auto-
discovery, regardless of whether they have any forwarders in
common or not OR
2. Each PE can set up a session to other PEs dynamically as the BGP
auto-discovery phase progresses if they have at least one
forwarder in common after the auto-discovery phase is complete.
Approach (1) has the benefit of simplicity and pre-determined
behavior in that the L2VPN signaling sessions may not go up and down
depending on dynamic L2VPN memberships.
Approach (2) provides complete automatic creation of signaling
sessions based on the BGP auto-discovery mechanisms and local policy.
The benefit of this approach is that reduces the configuration burden
to a minimum. Once obtain L2VPN membership information through BGP
auto-discovery, a PE may start L2VPN signaling sessions to other PEs.
With either approach, whenever a new Forwarder is added to an L2VPN,
a PE MUST advertise its information to all other PEs through BGP. The
receiving PE may initiate a pseudowire to the advertising PE with the
information learnt through BGP auto-discovery. Whenever an existing
Forwarder is removed from an L2VPN, a PE MUST withdraw the previous
advertisement of this Forwarder through BGP. PEs with pseudowires
connecting to this Forwarder will also receive an update through the
signaling sessions notifying that the Forwarder is removed.
Either approach may be chosen for deployment depending on given
deployment requirements.
9. References
[2547bis] "BGP/MPLS VPN", Rosen, et. al., draft-ietf-l3vpn-
rfc2547bis-01.txt, September 2003.
[BGP-AUTO] "Using BGP as an Auto-Discovery Mechanism for Network-
based VPNs", Ould-Brahim, et. al., draft-ietf-ppvpn-bgpvpn-auto-
03.txt, August 2002.
[BGP-BUNDLE-TCP], "Multisession BGP", John G. Scudder, Chandra
Appanna, November 2003,
draft-scudder-bgp-multisession-01.txt
[BGPCOMM], "BGP Communities Attribute", R. Chandra, P. P. Traina, T.
Li, RFC 1997, August 1996
[MPBGP] " Multiprotocol Extensions for BGP-4", T. Bates, R. Chandra,
D. Katz, Y. Rekhter, draft-ietf-idr-rfc2858bis-06.txt,
November 2004
[BGP-DYNCAP], "Dynamic Capability for BGP-4", Enke Chen, Srihari R.
Sangli, draft-ietf-idr-dynamic-cap-06.txt
[BGPEXTCOMM], "BGP Extended Communities Attribute", Srihari R. Sangli,
Daniel Tappan, Yakov Rekhter, draft-ietf-idr-bgp-ext-
communities-07.txt, August 2003
[BGPREFRESH], "Route Refresh Capability for BGP-4", Chen E., RFC 2918,
September 2000.
[BGPVPN] "Using BGP as an Auto-Discovery Mechanism for Network-based
VPNs", H. Ould-Brahim et. al., draft-ietf-ppvpn-bgpvpn-
auto-03.txt, August 2002
[VPLS-LDP] "Virtual Private LAN Services over MPLS" draft-ietf-l2vpn-
vpls-ldp-05.txt V.Komeplla, Marc Lasserre, February 2005
[VPLS-BGP] "Virtual Private LAN Service", K. Kompella, Y. Rekhter,
draft-ietf-l2vpn-vpls-bgp-02.txt, November 2004
[L2VPN-FRAME] "L2VPN Framework", Anderson, et. al., draft-ietf-l2vpn-
l2-framework-05.txt, December 2004.
[L2VPN-SIG] "Provisioning Models and Endpoint Identifiers in L2VPN
Signaling", Rosen, et. al., draft-ietf-l2vpn-signaling-
02.txt, March 2005.
[LDPVPN] E. Rosen, "LDP-based Signaling for L2VPNs",draft-rosen-
ppvpn-l2-signaling-02.txt, September 2002
[MPBGP-RFC 2842] "Multiprotocol Extensions for BGP-4", Bates, T., Y.
Rekhter, R. Chandra, D. Katz, RFC 2842, June 2000
[SOFT-NOTIFY] "BGPv4 Soft-Notification Message", Gargi Nalawade,
Keyur Patel, John Scudder, David Ward, October 2003.
10. Acknowledgments
We wish to thank Hamid Ould-Brahim, Shobhan Lakkapragada, Florin
Balus (Nortel Networks) for their comments and contributions.
11. AuthorÆs Addresses
Susan Hares
Merit, Inc.
1071 Beal Avenue,
Ann Arbor, MI 48109
Wei Luo
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Email: luo@cisco.com
Paul Unbehagen
Nortel Networks
35 East Davis Dr.
RTP, NC 27709
Phone: 919-905-2956
Email: paulu@nortelnetworks.com
Praveen Muley
Nortel Networks
600 Technology Park
Billerica, MA 01821
Phone: 978-288-3603
Email : pmuley@nortelnetworks.com
Vasile Radoaca
Nortel Networks
600 Technology Park
Billerica, MA 01821
Phone: (781) 856-0590/978-288-6097
Chaitanya Kodeboyina
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: ck@juniper.net
Peter B. Busschbach
Lucent Technologies
67 Whippany Road
Whippany, NJ, 07981
Email: busschbach@lucent.com
| PAFTECH AB 2003-2026 | 2026-04-23 00:26:57 |