draft-ietf-grow-rift-00.txt   draft-ietf-grow-rift-01.txt 
INTERNET-DRAFT D. Meyer (Editor) INTERNET-DRAFT D. Meyer (Editor)
draft-ietf-grow-rift-01.txt
Category Informational Category Informational
Expires: July 2004 January 2004 Expires: August 2004 February 2004
Operational Concerns and Considerations for Routing Protocol Operational Concerns and Considerations for Routing Protocol
Design -- Risk, Interference, and Fit (RIFT) Design -- Risk, Interference, and Fit (RIFT)
<draft-ietf-grow-rift-00.txt> <draft-ietf-grow-rift-01.txt>
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 3, line 17 skipping to change at page 3, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Scope of this Work . . . . . . . . . . . . . . . . . . . . . . 5 2. Scope of this Work . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement. . . . . . . . . . . . . . . . . . . . . . . 6 3. Problem Statement. . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Risk, Interference, and Application Fit (RIFT) . . . . . . 6 3.1. Risk, Interference, and Application Fit (RIFT) . . . . . . 6
3.1.1. Risk: Software Engineering . . . . . . . . . . . . . . . 7 3.1.1. Risk: Software Engineering . . . . . . . . . . . . . . . 7
3.1.2. Interference: Protocol Specification/Dynamic Behavior . 7 3.1.2. Interference: Protocol Specification/Dynamic Behavior . 7
3.1.3. Application Fit: Distribution Topology . . . . . . . . . 7 3.1.3. Application Fit: Distribution Topology . . . . . . . . . 7
4. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Reachability Information. . . . . . . . . . . . . . . . . . 8 4.1. Reachability Information. . . . . . . . . . . . . . . . . . 8
4.2. Layer 3 Routing Information . . . . . . . . . . . . . . . . 8 4.2. Layer 3 Routing Information . . . . . . . . . . . . . . . . 8
4.2.1. Standard Routing Information . . . . . . . . . . . . . . 9
4.3. Auxiliary (non-routing) Information . . . . . . . . . . . . 9 4.3. Auxiliary (non-routing) Information . . . . . . . . . . . . 9
4.4. Address Family Identifier (AFI) . . . . . . . . . . . . . . 9 4.4. Address Family Identifier (AFI) . . . . . . . . . . . . . . 9
4.5. Subsequent Address Family Identifier (SAFI) . . . . . . . . 9 4.5. Subsequent Address Family Identifier (SAFI) . . . . . . . . 10
4.6. Network Layer Reachability. . . . . . . . . . . . . . . . . 9 4.6. Network Layer Reachability. . . . . . . . . . . . . . . . . 10
4.7. Application . . . . . . . . . . . . . . . . . . . . . . . . 10 4.7. Application . . . . . . . . . . . . . . . . . . . . . . . . 10
4.8. Routing Protocol. . . . . . . . . . . . . . . . . . . . . . 10 4.8. Routing Protocol. . . . . . . . . . . . . . . . . . . . . . 10
4.9. Fate Sharing. . . . . . . . . . . . . . . . . . . . . . . . 10 4.9. Fate Sharing. . . . . . . . . . . . . . . . . . . . . . . . 11
5. Architectural Models . . . . . . . . . . . . . . . . . . . . . 11 5. Architectural Models . . . . . . . . . . . . . . . . . . . . . 11
5.1. General Purpose Transport Infrastructure (GPT) Model. . . . 11 5.1. General Purpose Transport Infrastructure (GPT) Model. . . . 12
5.2. Special Purpose Transport Infrastructure (SPT) Model. . . . 12 5.2. Special Purpose Transport Infrastructure (SPT) Model. . . . 12
6. Analyzing Risk and Interference. . . . . . . . . . . . . . . . 12 6. Analyzing Risk and Interference. . . . . . . . . . . . . . . . 13
6.1. Risk: Code Impact, and Resource Sharing . . . . . . . . . . 13 6.1. Risk: Code Impact, and Resource Sharing . . . . . . . . . . 13
6.1.1. Code Impact. . . . . . . . . . . . . . . . . . . . . . . 13 6.1.1. Code Impact. . . . . . . . . . . . . . . . . . . . . . . 13
6.1.2. Resource Sharing . . . . . . . . . . . . . . . . . . . . 13 6.1.2. Resource Sharing . . . . . . . . . . . . . . . . . . . . 14
6.1.2.1. Resource Sharing and Operating System Level Issues . 14 6.1.2.1. Resource Sharing and Operating System Level Issues . 14
6.2. Interference. . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Interference. . . . . . . . . . . . . . . . . . . . . . . . 15
7. GTP and SPT Models: Risk and Interference. . . . . . . . . . . 15 7. GTP and SPT Models: Risk and Interference. . . . . . . . . . . 15
7.1. Risk. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Risk. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1.1. Code Impact. . . . . . . . . . . . . . . . . . . . . . . 15 7.1.1. Code Impact. . . . . . . . . . . . . . . . . . . . . . . 16
7.1.2. Resource Sharing . . . . . . . . . . . . . . . . . . . . 16 7.1.2. Resource Sharing . . . . . . . . . . . . . . . . . . . . 17
7.1.3. Multisession BGP . . . . . . . . . . . . . . . . . . . . 17 7.1.3. Multisession BGP . . . . . . . . . . . . . . . . . . . . 17
7.2. Interference. . . . . . . . . . . . . . . . . . . . . . . . 18 7.2. Interference. . . . . . . . . . . . . . . . . . . . . . . . 19
7.2.1. Multisession BGP . . . . . . . . . . . . . . . . . . . . 19 7.2.1. Multisession BGP . . . . . . . . . . . . . . . . . . . . 19
8. Application Fit. . . . . . . . . . . . . . . . . . . . . . . . 19 8. Application Fit. . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. RFC 2547 Style VPNs . . . . . . . . . . . . . . . . . . . . 19 8.1. RFC 2547 Style VPNs . . . . . . . . . . . . . . . . . . . . 20
8.2. VPWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1.1. RFC 2547 and Label Distribution. . . . . . . . . . . . . 21
8.3. VPLS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.2. VPWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Operational Implications . . . . . . . . . . . . . . . . . . . 22 8.2.1. Assertion #1 . . . . . . . . . . . . . . . . . . . . . . 22
10. Other Models. . . . . . . . . . . . . . . . . . . . . . . . . 22 8.2.2. Counter-Assertion #1 . . . . . . . . . . . . . . . . . . 22
11. Conclusions and Recommendations . . . . . . . . . . . . . . . 22 8.2.3. Assertion #2 . . . . . . . . . . . . . . . . . . . . . . 23
12. Intellectual Property . . . . . . . . . . . . . . . . . . . . 22 8.2.4. Counter-Assertion #2 . . . . . . . . . . . . . . . . . . 23
13. Design Team . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.2.4.1. Assertion #2a . . . . . . . . . . . . . . . . . . . . 23
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 8.2.4.2. Counter-Assertion #2a . . . . . . . . . . . . . . . . 23
15. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8.2.5. Assertion #3 . . . . . . . . . . . . . . . . . . . . . . 24
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8.2.6. Counter-Assertion #3 . . . . . . . . . . . . . . . . . . 25
17. References. . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.3. VPWS and Per-Wire Attributes. . . . . . . . . . . . . . . . 27
17.1. Normative References . . . . . . . . . . . . . . . . . . . 25 8.3.1. Assertion #4 . . . . . . . . . . . . . . . . . . . . . . 27
17.2. Informative References . . . . . . . . . . . . . . . . . . 27 8.3.2. Counter-Assertion #4:. . . . . . . . . . . . . . . . . . 27
18. Editor's Address. . . . . . . . . . . . . . . . . . . . . . . 29 8.3.3. Assertion #5 . . . . . . . . . . . . . . . . . . . . . . 27
19. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 29 8.3.4. Counter-Assertion #5 . . . . . . . . . . . . . . . . . . 27
8.3.5. Assertion #6 . . . . . . . . . . . . . . . . . . . . . . 28
8.3.6. Counter-Assertion #6 . . . . . . . . . . . . . . . . . . 28
8.3.7. Assertion #7:. . . . . . . . . . . . . . . . . . . . . . 28
8.3.8. Counter-Assertion #7:. . . . . . . . . . . . . . . . . . 29
8.4. VPLS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.4.1. Assertion #8 . . . . . . . . . . . . . . . . . . . . . . 29
8.4.2. Counter-Assertion #8 . . . . . . . . . . . . . . . . . . 29
8.4.3. Assertion #9 . . . . . . . . . . . . . . . . . . . . . . 30
8.4.4. Counter-Assertion #9 . . . . . . . . . . . . . . . . . . 30
9. Operational Implications . . . . . . . . . . . . . . . . . . . 30
9.1. OAM Functionality . . . . . . . . . . . . . . . . . . . . . 30
9.1.1. Assertion #10: . . . . . . . . . . . . . . . . . . . . . 30
9.1.2. Counter-Assertion #10: . . . . . . . . . . . . . . . . . 31
9.2. Full-Mesh Issues. . . . . . . . . . . . . . . . . . . . . . 31
10. Conclusions and Recommendations . . . . . . . . . . . . . . . 31
11. Intellectual Property . . . . . . . . . . . . . . . . . . . . 31
12. Design Team . . . . . . . . . . . . . . . . . . . . . . . . . 31
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
14. Security Considerations . . . . . . . . . . . . . . . . . . . 33
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
16. References. . . . . . . . . . . . . . . . . . . . . . . . . . 34
16.1. Normative References . . . . . . . . . . . . . . . . . . . 34
16.2. Informative References . . . . . . . . . . . . . . . . . . 37
17. Editor's Address. . . . . . . . . . . . . . . . . . . . . . . 38
18. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
The stability of the global Internet routing system has been the The stability of the global Internet routing system has been the
subject of much research (see e.g., [RVBIB]) and discussion on subject of much research (see e.g., [RVBIB]) and discussion on
various IETF mailing lists [IETFOL]. Much of the research into the various IETF mailing lists [IETFOL]. Much of the research into the
routing system has centered around the analysis of the dynamics and routing system has centered around the analysis of the dynamics and
stability of the Border Gateway Protocol Version 4 [BGP] (hereafter stability of the Border Gateway Protocol Version 4 [BGP] (hereafter
referred to as BGP). referred to as BGP).
skipping to change at page 9, line 5 skipping to change at page 9, line 5
Finally, if one defines routing information as "information used to Finally, if one defines routing information as "information used to
forward packets", combined with the above definition of reachability forward packets", combined with the above definition of reachability
information, then we can consider information such as described in information, then we can consider information such as described in
[FLOW] (for example) to be routing information (since it is [FLOW] (for example) to be routing information (since it is
attempting to add a level of granularity to how an 'aggregate' is attempting to add a level of granularity to how an 'aggregate' is
defined). That is, [FLOW] intends to complement to the existing defined). That is, [FLOW] intends to complement to the existing
routing information, and the flow information is dependent on IP4 routing information, and the flow information is dependent on IP4
unicast reachability advertised by the same neighbor. unicast reachability advertised by the same neighbor.
4.2.1. Standard Routing Information
In the most general terms, then, a routing protocol distributes data
to accomplish the following three functionalities:
(i). To govern the routing decision process (e.g., the
standard BGP decision process)
(ii). To constrain the flow of information (for example, with
BGP communities)
(iii). To tell the recipient how to get packets to the next hop
We will refer to information that falls into this class as "standard
routing information".
4.3. Auxiliary (non-routing) Information 4.3. Auxiliary (non-routing) Information
Auxiliary Information is any information that is exchanged by routers Auxiliary Information is any information that is exchanged by routers
which is neither Layer 3 routing information, nor reachability which is neither Layer 3 routing information, nor reachability
information. IS-IS hostname TLVs are an example of Axillary information. IS-IS hostname TLVs are an example of auxiliary
information [RFC1142]. information [RFC1142].
4.4. Address Family Identifier (AFI) 4.4. Address Family Identifier (AFI)
An Address Family contains addresses that share common structure and An Address Family contains addresses that share common structure and
semantics. An Address Family Identifier (AFI) uniquely identifies semantics. An Address Family Identifier (AFI) uniquely identifies
each address family. Several routing protocol messages contain a each address family. Several routing protocol messages contain a
field that represents the AFI. The AFI identifies the address type field that represents the AFI. The AFI identifies the address type
used by another data item contained in that message. The Routing used by another data item contained in that message. The Routing
Information Protocol (RIP) [RFC2453], Distance Vector Multicast Information Protocol (RIP) [RFC2453], Distance Vector Multicast
skipping to change at page 18, line 27 skipping to change at page 18, line 44
When formulated in this way, one can see that one objective of When formulated in this way, one can see that one objective of
multisession BGP is to find a value, call it g, such that multisession BGP is to find a value, call it g, such that
f(GPT, g) ~ f(SPT,k), for small values of k (i.e., k close to 1) f(GPT, g) ~ f(SPT,k), for small values of k (i.e., k close to 1)
where where
A(n) ~ B(k) ==> A(n) = B(k) + h(n), h(n) >= 0 A(n) ~ B(k) ==> A(n) = B(k) + h(n), h(n) >= 0
That is, A(n) is approaches B(k) That is, A(n) is approximately equal to B(k)
In this case, g is the size of the multisession AFI/SAFI grouping, In this case, g is the size of the multisession AFI/SAFI grouping,
and for small values of g, multisession BGP can have a risk profile and for small values of g, multisession BGP can have a risk profile
that looks very much like the SPT risk profile. In particular, for g that looks very much like the SPT risk profile. In particular, for g
= 1, both models would have similar risk profiles. Of course, there = 1, both models would have similar risk profiles. Of course, there
are many other components of risk that that are not considered by are many other components of risk that that are not considered by
this analysis, such as collateral issues resulting from the existence this analysis, such as collateral issues resulting from the existence
of faulty shared code, operating system process and memory structure, of faulty shared code, operating system process and memory structure,
etc. etc.
skipping to change at page 19, line 18 skipping to change at page 19, line 29
GPT model by eliminating one potential source of interference, GPT model by eliminating one potential source of interference,
namely, the potential interference due to presence of multiple namely, the potential interference due to presence of multiple
AFI/SAFIs in a single BGP session. Following the analysis presented AFI/SAFIs in a single BGP session. Following the analysis presented
in section 7.1.3, we can see that for small groupings (described as in section 7.1.3, we can see that for small groupings (described as
small values of g in section 7.1.3), the interference profiles of small values of g in section 7.1.3), the interference profiles of
both models converge. both models converge.
8. Application Fit 8. Application Fit
In the following sub-sections, application fit is examined from the In the following sub-sections, application fit is examined from the
perspective of analyzing the data distribution needs of three perspective of analyzing the signaling and data distribution needs of
representative classes of application, namely: three representative applications, namely:
RFC 2547 Style VPNs RFC 2547 Style VPNs
VPWS VPWS
VPLS VPLS
8.1. RFC 2547 Style VPNs However, before investigating how the BGP data distribution mechanism
(and its extensions) fit the requirements of these applications, it
is useful to briefly review the gross characteristics of the BGP data
distribution infrastructure. In particular, we examine which
distribution topologies can be naturally built using internal BGP (or
iBGP).
First, it is useful to review the distribution mechanisms available iBGP has been described loosely as a broadcast mechanism since an
in BGP, in particular, in i-BGP. i-BGP has been described loosely as iBGP speaker sends information to all its peers. This is typically
a broadcast mechanism since an i-BGP speaker sends information to all achieved by means of one or more route reflectors (or RRs); a more
its peers. This is typically achieved by means of one or more route direct but less scalable means is for each iBGP speaker to have a BGP
reflectors; a more direct but less scalable means is for each i-BGP session with each iBGP peer. It may, however, be more accurate to
speaker to have a BGP session with each i-BGP peer. characterize iBGP as a constrained broadcast mechanism. This is
because the use of communities in conjunction with import and export
policies allows an iBGP speaker to effectively limit its
communication to a subset of the full set of iBGP peers; the
efficiency of constrained broadcast can be improved by techniques
such as described in [ORF] and [RTCONST].
However, it is more accurate to characterize i-BGP as a constrained 8.1. RFC 2547 Style VPNs
broadcast mechanism. This is because the use of communities in
conjunction with import and export policies allows an i-BGP speaker
to effectively limit its communication to a subset of the full set of
i-BGP peers; the efficiency of constrained broadcast can be improved
by techniques such as described in [ORF] and [RTCONST].
There are five classes of information that need to be distributed for There are five classes of information that need to be distributed for
RFC 2547 style VPNs: RFC 2547 style VPNs:
(a). Membership (auto-discovery) (a). Membership (auto-discovery)
(b). Prefixes (b). Prefixes
(c). Labels (c). Labels
(d). BGP nexthop, and (d). BGP nexthop, and
(e). Path selection attributes (e). Path selection attributes
The first of these, membership or auto-discovery, must be sent to all The first of these, membership or auto-discovery, must be sent to all
peers, as a BGP speaker does not know a priori which of its peers are peers, as a BGP speaker does not know a priori which of its peers are
members of a given VPN. Membership of a given VPN is recognized by members of a given VPN. Membership of a given VPN is recognized by
the use of certain extended communities called Route Targets. BGP is the use of extended communities called Route Targets. BGP is well-
clearly eminently well-suited for this mode of distribution. suited for this mode of distribution.
The next three of these constitute the reachability information. The next three of these constitute the reachability information.
They say what part of a given VPN (b) is reachable, and how it is to They say what part of a given VPN (b) is reachable, and how it is to
be reached (c and d). The final piece of information is used for be reached (c and d). The final piece of information is used for
selection if there are multiple paths to a given prefix of a VPN, as selection if there are multiple paths to a given prefix of a VPN, as
in the case of multi-homing. All of these pieces of information need in the case of multi-homing. All of these pieces of information need
only be distributed to members of the VPN, i.e., they require a only be distributed to members of the VPN, i.e., they require a
constrained broadcast mechanism. BGP is reasonably well-suited for constrained broadcast mechanism. BGP is reasonably well-suited for
this mode of distribution using import and export NLRI filtering. this mode of distribution using import and export NLRI filtering.
The addition of the mechanism in [RTCONST] makes BGP even better The addition of the mechanism in [RTCONST] makes BGP even better
suited to this. suited to this.
The encoding of this information as defined in [RFC2547BIS] puts all The encoding of this information as defined in [RFC2547BIS] puts all
of this information in a single NLRI. This seems to imply that a of this information in a single NLRI. This seems to imply that a
broadcast mechanism has to be used for the distribution of RFC 2547 broadcast mechanism has to be used for the distribution of RFC 2547
VPN information. However, the combination of [RTCONST] and [RFC2918] VPN information. However, the combination of [RTCONST] and [RFC2918]
allow BGP to distribute this information correctly yet efficiently. allow BGP to distribute this information correctly yet efficiently.
Finally, it is useful to observe that standard BGP path selection In summary, there seems to be little argument that the RFC 2547
mechanisms (local pref, MED, AS path length, etc.) can be applied to application is a routing application. This is because the information
the information in (e). that gets sent via BGP in RFC 2547 is generally considered to be
"routing information". That is, the protocol distributes address
prefixes, along with their next hops (and of course, some additional
attributes). Finally (and perhaps most importantly), there seems to
be little argument that the information distributed by the RFC 2547
application is standard routing information.
The conclusion is that BGP is quite well-suited to this application, 8.1.1. RFC 2547 and Label Distribution
and, with the addition of mechanisms such as [RTCONST] and [RFC2918],
the fit is even closer. One issue that is frequently raised with respect to whether or not
the RFC 2547 VPN application is a routing application surrounds the
fact that, in the 2547 application, BGP distributes MPLS labels along
with the routes. The contention then, is that the RFC 2547
application represents more than just a routing application. However,
in this case the MPLS label is just a shorthand way of representing
one or more address prefixes. That is, the assertion is that in this
case, the label represents "standard routing information".
8.2. VPWS 8.2. VPWS
A VPN based on a Virtual Private Wire Service [VPWS] connects a The question of whether VPWS is a "good fit" for the BGP transport
number of sites by virtual wires (or pseudo-wires). The information infrastructure is the source of much discussion (and controversy). In
needed to create such a VPN comprises: this section, we will review both positions and their supporting
arguments as a series of assertions and counter-assertions (we will
use this format throughout the rest of this section).
(a). Membership (auto-discovery) The key debate with respect to VPWS centers around what set of
(b). VPN site identification services are being defined, and how they are to be signaled. One way
(c). Labels to analyze the VPWS application, then is in terms of two of its more
(d). BGP nexthop contentious functionalities, namely:
(e). Path selection attributes, and
(f). Per-wire information
The analysis of the first five items is exactly as for RFC 2547 VPNs, (a). Auto-discovery
with the slight change that the definition of a 'part of a VPN' is no
longer an IP prefix, but is a VPN site identifier, which can be
viewed as the VPWS prefix. The distribution requirements and the fit
with BGP distribution mechanisms is identical to RFC 2547.
The one major change is the potential for 'per-wire' attributes, such Auto-discovery refers to discovery of the set of nodes
as bandwidth for a given site-to-site connection. This information that belong in a common L2VPN, and
should be distributed on a point-to-point basis. BGP mechanisms are
not efficient for point-to-point distribution. However, it is an
open question whether such 'per-wire' attributes really need to be
exchanged, as evidenced by the fact that LDP signaling for pseudo-
wires [MARTINI] has not defined any such attributes. If per-wire
information is indeed not necessary, BGP distribution mechanisms are
as well-suited for VPWS VPNs as for RFC 2547 VPNs.
Note that existing BGP path selection mechanisms can be used as is (b). Signaling
for VPWS, and can prove useful for multi-homed sites.
8.3. VPLS Signaling refers to the setup and maintenance of the
point-to-point pseudo-wires that carry the traffic of
the L2VPN.
A VPLS connects a number of sites by an emulated LAN segment. The The next sections examine the various assertions and counter-
information needed to create a VPLS consists of: assertions around auto-discovery and signaling for VPLS.
(a). Membership (auto-discovery) 8.2.1. Assertion #1
(b). VPLS site identification
(c). Labels
(d). BGP nexthop, and
(e). Path selection attributes
The notion of 'VPLS site identification' is analogous to a VPN site Assertion #1 states VPWS is not a routing application. Those
identifier for VPWS. The analysis of the distribution needs of these supporting this assertion argue that in the case of VPWS, we are not
five items is exactly as for RFC 2547 VPNs, and the conclusion is distributing address prefixes, and (importantly) unlike the case of
that BGP is reasonably well-suited for this application, and with the RFC 2547 style VPNs, the BGP decision process is not used (or at
addition of [RTCONST] and [REFRESH], the fit is even better. least it is not used in the same way). Further, proponents argue that
what we are distributing is state information that corresponds to
point-to-point entities, i.e., pseudo-wires, and thus argues that
that the VPWS application is completely different.
Note that existing BGP path selection mechanisms can be used as is 8.2.2. Counter-Assertion #1
for VPLS, and can prove useful for multi-homed sites.
Counter-Assertion #1 states that VPWS is a routing application. More
specifically, this position is outlined in [VPLS] (section 3.4),
namely:
"It is often desired to multi-home a VPLS site, i.e., to connect
it to multiple PEs, perhaps even in different ASes. In such a
case, the PEs connected to the same site can either be
configured with the same VE ID or with different VE IDs. In the
latter case, it is mandatory to run STP on the CE device, and
possibly on the PEs, to construct a loop-free VPLS topology.
In the case where the PEs connected to the same site are
assigned the same VE ID, a loop-free topology is constructed by
routing mechanisms, in particular, by BGP path selection. When a
BGP speaker receives two equivalent NLRIs (see below for the
definition), it applies standard path selection criteria such as
Local Preference and AS Path Length to determine which NLRI to
choose; it MUST pick only one.
If the chosen NLRI is subsequently withdrawn, the BGP speaker
applies path selection to the remaining equivalent VPLS NLRIs to
pick another; if none remain, the forwarding information
associated with that NLRI is removed."
8.2.3. Assertion #2
Assertion #2 states that auto-discovery for VPWS requires some form
of constrained broadcast. There doesn't seem to be much controversy
that auto-discovery does require some sort of constrained broadcast
mechanism (which we don't want to be limited to a single AS), and we
may want to be able to optimize it by using a RP (rendezvous point)
like mechanism. BGP route reflectors (RR) provide a convenient and
ubiquitously deployed candidate RP. In this case (RR as RP), the fit
is good since auto-discovery, like routing, requires an n-party
protocol where each party has no a priori knowledge of the existence
or identity of the other n-1 parties.
8.2.4. Counter-Assertion #2
There is no real counter-position to Assertion #2, as it simply
states that VPWS auto-discovery requires some form of constrained
broadcast (about which there is some controversy; see Assertion #2a
below).
8.2.4.1. Assertion #2a
Assertion #2a states that auto-discovery is not needed for VPWS.
Further, the Assertion #2a states that there is not a validated need
for VPWS auto-discovery, since auto-discovery is useful only when
creating full mesh layer 2 topologies, which are undesirable due to
their (well-understood) poor scaling properties; hence auto-discovery
for VPWS is not useful.
8.2.4.2. Counter-Assertion #2a
<what is the counter-assertion here? auto-discovery is useful for
partial mesh? cite?>
In summary, with the exception of Assertion #2a, the major
controversy surrounding VPWS is in signaling piece of the
application. The "VPWS is not a routing application" camp argues that
the VPWS signaling requirements do not fit the BGP distribution
infrastructure, while the "VPWS is a routing application" camp
believes that BGP is a good fit. The next sections examine these
assertions.
8.2.5. Assertion #3
Assertion #3 states that VPWS applications are not a good fit for
BGP. This argument is based on the assertion that BGP is poorly
suited to the VPWS signaling requirements because pseudo-wires are
inherently point-to-point (see, for example [L2VPNSIG]). Further, the
assertion is that VPWS signaling is qualitatively different than in
routing or auto-discovery, in which each piece of information must be
distributed to the n participants. The conclusion here is that BGP's
distribution mechanisms are a poor match for VPWS signaling. Another
way to think about this is that BGP generally works from a single
database, and then applies some filtering on a per-connection basis;
this only makes sense if most of the information is going to go to a
lot of places.
For example, suppose that a RR is used for VPWS signaling, and there
is the need to set up n pseudo-wires. In this case, instead of
sending n setup messages, one sends one large "meta-setup" message
with all the info that would have been in the n setup messages. That
is, let
n = number of pseudo-wires
l = the size of the per-wire label information
k = the size of the per-wire information
In this case, the meta-setup message will be of size O((l + k) * n).
After receiving the setup message, the RR then must send the n
messages that could have been sent by the endpoint (note that this is
almost true; the endpoint would have to send n messages of size (l +
k), but the RR will have to send n copies of the larger setup
message).
8.2.6. Counter-Assertion #3
Counter-Assertion #3 states that the VPWS application is a good fit
for BGP (see, for example [L2VPNT]). In particular, this camp
suggests that a RR really only needs to distribute the label-range
[LABELRANGE], so the setup message isn't really n times as large, but
rather is analyzed as follows:
Let n = number of pseudo-wires
m = the size of the label-range data
k = the size of the per-wire information
Then the messages will be of size O(m + (k * n)), and most
importantly for the label-range argument:
O(m + (k * n)) < O((l + k) * n)
That is, the label-range concept reduces the size of the
messages that need to be sent to and by the RR.
However, some will argue that the label-range concept is efficient if
and only if:
(a). A large enough label range is preallocated to accommodate
all the systems you might ever want to add to the
VPLS/VPWS (assuming that service interruption is not
acceptable), and
(b). There is no per-wire information other than labels that
needs to distributed
In these cases, the label range approach can reduce the size of the
setup messages as analyzed above. However, the counter argument is
that any such reduction will become a second-order effect as soon as
some other piece of per-wire status or configuration (e.g., MTU)
information must be distributed. In addition, the idea of pre-
allocating a large enough label range to accommodate future
expansion, while saving bits in the setup messages, has other costs
which may be large. In particular:
(a). Until the future expansion takes place (if it ever does),
one may be wasting quite a lot of labels (noting that
that each label you distribute requires you to allocate a
piece of high-speed memory in your forwarding engine;
putting some of it aside for possible later use seems
very costly. Each one you put aside is, e.g., one less
RFC2547 route you can support).
However, if you don't preallocate enough contiguous label
space for future expansion, then if the expansion occurs
you must start adding additional labels or label ranges,
and your setup messages start getting longer anyway (in
theory, you could just carve a new set of label ranges,
instead of adding new ones; counter-position: if you did
that, you'd have to bring down your whole VPWS (and
possibly VPLS) every time you add a new endpoint).
(b). Fragmentation of the label space, which can result from
this preallocation, has real impact on label switching
implementations (as the MPLS architecture explicitly
leaves it to the implementation to develop its own label
assignment strategies). So if, for example, a hardware
designer thinks s/he can improve performance by using,
say, prime numbered labels first, s/he should have the
ability to design her/his system in this way. If an
application is going to come along and demand that labels
be assigned in contiguous groups, implementations which
are perfectly conformant to the architecture may not be
able to support that application.
(c). For diagnosis of network problems, the label-range
approach may have the additional issue that the operator
may not know (a priori) which label(s) were assigned to
which endpoint(s).
(d). Finally, one may argue that label-range allocation is
sub-optimal for non-full mesh topologies, since all peers
of the VPN must hear about the a label-range withdraw, and
(in a non-full mesh topology), not all peers need to know
about it.
In any event, one may argue that the scaling benefits of using a RR
in routing is that the RR pre-digests all the received info; it runs
the (BGP) decision process, and only forwards the results of the
decision process, rather than forwarding all the raw data. In the
case of VPWS (and possibly VPLS), the argument is that this advantage
is absent (i.e., we don't run BGP path selection), and as a result,
the RR doesn't help with scaling in the same way it does with
routing. Of course, the counter position is that some form of BGP
path selection is used; see discussion above). Finally, one may argue
that using the RR will introduce some latency into the label withdraw
procedure.
8.3. VPWS and Per-Wire Attributes
While several per-wire attributes have been defined (see [L2TPV3],
for example), the need for per-wire attributes for VPWS remains
controversial. The following sections examine those controversies.
8.3.1. Assertion #4
Assertion #4 is that VPWS requires various per-wire parameters. These
may include (but are not limited to) MTU, whether to use sequencing
capabilities, bandwidth capabilities, and QoS. In addition, during
the lifetime of a pseudo-wire, there are per-wire status indications
that may need to be passed to the other endpoint.
8.3.2. Counter-Assertion #4:
Counter-Assertion #4 states that it has not been demonstrated that
VPWS needs per-wire attributes as few (per-wire attributes) have as
yet been defined (see, e.g., [MARTINI]).
8.3.3. Assertion #5
Assertion #5 states that passing per-wire attributes through an RR
will likely be inefficient. The argument here is that in the event
that per-wire attributes are required, passing these (per-wire)
attributes through a RR will be sub-optimal as the RR will forward
the status to all the VPWS members, not just to the one endpoint that
is interested in it. For attributes like sequence numbers, it may
even more difficult as one has to make sure the sequence numbers
resynchronize properly when the pseudo-wire flaps. This seems
somewhat difficult to achieve through a BGP RR.
8.3.4. Counter-Assertion #5
The counter assertion here is that, since few (or no) per-wire
attributes have been defined (counter-assertion #4), the fact that it
is inefficient to use a RR for distribution is irrelevant.
8.3.5. Assertion #6
Assertion #6 states that, while still an open issue, pseudo-wire
congestion control may require regular point-to-point control message
exchanges, something which BGP would seem ill-equipped to handle.
8.3.6. Counter-Assertion #6
In this case, the counter assertion is that since few (or no) per-
wire attributes have been defined (see counter-assertion #4), and
further, since congestion control for pseudo-wires is still an open
issue, arguing fit is premature.
8.3.7. Assertion #7:
Assertion #7 states that the primary motivation for VPWS is to
deliver existing service models (i.e., Frame Relay and ATM) over a
packet infrastructure (this is as opposed to some new service). In
this case, common deployments involve partial mesh topologies (more
specifically multiple hub and spoke connections, with some hub to hub
connectivity that makes sense for the enterprise traffic profile). In
addition, some of the connections in such deployments require per-
wire characteristics (e.g., guaranteed throughput for voice, etc).
In other words, the argument here is that a VPWS service designed to
support so-called legacy services (Frame Relay and ATM) will require
point-to-point signaling due to existing topologies and the need for
per-wire attributes. Further, for new VPWS services that require
full-mesh auto-provisioning, the "Colored Pools PW Provisioning
Model" [L2VPN] suggests a method to support such provisioning while
retaining the point-to-point signaling required to support per-wire
attributes.
8.3.8. Counter-Assertion #7:
<what is the counter-assertion here?>
8.4. VPLS
A VPLS service connects a number of sites by an emulated LAN segment.
In the next sections, we examine whether VPLS maybe be considered to
be a routing application, and hence whether BGP is a good fit for its
distribution requirements.
8.4.1. Assertion #8
Assertion #8 states that VPLS is a routing application, since the
notion of "VPLS site identification" is analogous to a VPN site
identifier for VPWS (which this camp also views as a routing
application). As a result, the analysis of the distribution needs of
these five items is exactly as for RFC 2547 VPNs, and the conclusion
is that BGP is reasonably well-suited for this application, and with
the addition of [RTCONST] and [REFRESH], the fit is even better.
Finally, note that existing BGP path selection mechanisms can be used
as is for VPLS, and can prove useful for multi-homed sites.
8.4.2. Counter-Assertion #8
Counter-Assertion #8 states that VPLS is not a routing application.
In particular, the contention here is that while the VPLS NLRI are
used to identify that a particular PE belongs to a particular VPLS
instance (as described in Assertion #8),the path which data traffic
follows will depend on the route to that PE, and that route is
determined by the ordinary IP routing. As a result, it is not
relevant which neighbor a VPLS NLRI was received from, and hence is
not routing.
8.4.3. Assertion #9
Assertion #9 is that constrained or true broadcast is not valuable
for VPLS, since the same label can not be used by all peers. In
particular, the same label can not be used by all peers since MAC
address learning is performed in the data plane.
8.4.4. Counter-Assertion #9
<what is the counter-assertion here? label ranges?>
9. Operational Implications 9. Operational Implications
10. Other Models In this section we examine the operational implications of the
various choices in the design spaces described in this document.
11. Conclusions and Recommendations 9.1. OAM Functionality
12. Intellectual Property A service provider (SP) may want to know exactly where a particular
pseudo-wire leaves its domain, and in addition may want to keep
various counts and bits of status at that point. Further, the SP may
want to be able to do data path testing to that point. That is, a SP
may want point-to-point pseudo-wire state to be maintained at its
border routers.
9.1.1. Assertion #10:
Assertion #10 states that it may be difficult for service providers
to maintain point-to-point pseudo-wire state at their border routers
with the proposed BGP signaling mechanisms. This is because those
mechanisms provide no way to ensure that a pseudo-wire data path will
leave the network at a node which has state information for that
pseudo-wire.
9.1.2. Counter-Assertion #10:
<counter assertion?>
9.2. Full-Mesh Issues
10. Conclusions and Recommendations
11. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11 [RFC2028]. standards-related documentation can be found in BCP-11 [RFC2028].
Copies of claims of rights made available for publication and any Copies of claims of rights made available for publication and any
skipping to change at page 22, line 33 skipping to change at page 31, line 35
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementors or users of this such proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat. specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
13. Design Team 12. Design Team
The design team that produced this document consisted of Daniel The design team that produced this document consisted of Daniel
Awduche (awduche@awduche.com), Ron Bonica (Ronald.P.Bonica@mci.com), Awduche (awduche@awduche.com), Ron Bonica (Ronald.P.Bonica@mci.com),
Hank Kilmer (hank@rem.com), Kireeti Kompella (kireeti@juniper.net), Hank Kilmer (hank@rem.com), Kireeti Kompella (kireeti@juniper.net),
Chris Lewis (chrlewis@cisco.com), Danny McPherson (danny@tcb.net), Chris Lewis (chrlewis@cisco.com), Danny McPherson (danny@tcb.net),
David Meyer (dmm@1-4-5.net) and Peter Whiting David Meyer (dmm@1-4-5.net) and Peter Whiting
(pwhiting@vericenter.com). (pwhiting@vericenter.com).
14. Acknowledgments 13. Acknowledgments
David Ball, Peter Gutierrez, Susan Harris, Pedro Marques, Eric Rosen, David Ball, Peter Gutierrez, Susan Harris, Pedro Marques, Eric Rosen,
Pekka Savola, and Mark Townsley have all made many insightful Pekka Savola, and Mark Townsley have all made many insightful
comments on earlier versions of this document. comments on earlier versions of this document.
15. Security Considerations 14. Security Considerations
This document specifies neither a protocol nor an operational This document specifies neither a protocol nor an operational
practice, and as such, it creates no new security considerations. practice, and as such, it creates no new security considerations.
16. IANA Considerations 15. IANA Considerations
This document creates a no new requirements on IANA namespaces This document creates a no new requirements on IANA namespaces
[RFC2434]. [RFC2434].
17. References 16. References
17.1. Normative References 16.1. Normative References
[AFI] http://www.iana.org/assignments/address-family-numbers [AFI] http://www.iana.org/assignments/address-family-numbers
[BGP] Rekhter, Y, T.Li, and S. Hares, "A Border Gateway [BGP] Rekhter, Y, T.Li, and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-23.txt. Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-23.txt.
Work in progress. Work in progress.
[BGPVPN] Ould-Brahim, H., E. Rosen, and Y. Rekhter, "Using [BGPVPN] Ould-Brahim, H., E. Rosen, and Y. Rekhter, "Using
BGP as an Auto-Discovery Mechanism for BGP as an Auto-Discovery Mechanism for
Provider-provisioned VPNs", Provider-provisioned VPNs",
skipping to change at page 25, line 35 skipping to change at page 34, line 35
[EXTCOMM] Sangali, S., D. Tappan, and Y. Rekhter, "BGP [EXTCOMM] Sangali, S., D. Tappan, and Y. Rekhter, "BGP
Extended Communities Attribute", Extended Communities Attribute",
draft-ietf-idr-bgp-ext-communities-06.txt. Work draft-ietf-idr-bgp-ext-communities-06.txt. Work
in progress. in progress.
[FLOW] Marques, P, et. al., "Dissemination of flow [FLOW] Marques, P, et. al., "Dissemination of flow
specification rules", specification rules",
draft-marques-idr-flow-spec-00.txt. Work in draft-marques-idr-flow-spec-00.txt. Work in
progress. progress.
[LABELRANGE] What is the cite here?
[L2VPN] Andersson, L. and E. Rosen, "L2VPN Framework",
draft-ietf-l2vpn-l2-framework-03.txt. Work in
Progress.
[L2VPNSIG] Rosen, E. and V. Rodoaca, "Provisioning Models
and Endpoint Identifiers in L2VPN Signaling",
draft-ietf-l2vpn-signaling-00.txt. Work in
Progress.
[L2VPNT] Kompella, K. (Editor), "Layer 2 VPNs Over
Tunnels", draft-kompella-l2vpn-l2vpn-00.txt.
Work in Progress.
[L2TPv3] Lau, J., M. Townsley and I. Goyret (Editors), [L2TPv3] Lau, J., M. Townsley and I. Goyret (Editors),
"Layer Two Tunneling Protocol (Version "Layer Two Tunneling Protocol (Version
3)", draft-ietf-l2tpext-l2tp-base-11.txt. Work in 3)", draft-ietf-l2tpext-l2tp-base-11.txt. Work in
progress. Progress.
[MARTINI] Martini, L., E.Rosen, and T. Smith, "Pseudowire [MARTINI] Martini, L., E.Rosen, and T. Smith, "Pseudowire
Setup and Maintenance using LDP", Setup and Maintenance using LDP",
draft-ietf-pwe3-control-protocol-05.txt. Work in draft-ietf-pwe3-control-protocol-05.txt. Work in
progress. progress.
[MULLER1999] Muller, R. et. al., "Control System Reliability [MULLER1999] Muller, R. et. al., "Control System Reliability
Requires Careful Software Installation Requires Careful Software Installation
Procedures", International Conference on Procedures", International Conference on
Accelerator and Largeand Large Experimental Accelerator and Largeand Large Experimental
skipping to change at page 27, line 24 skipping to change at page 36, line 42
[RFC3036] Anderson, L., et. al., "LDP Specification", RFC [RFC3036] Anderson, L., et. al., "LDP Specification", RFC
3036, January 2001. 3036, January 2001.
[RFC3439] Bush, R. and D. Meyer, "Some Internet [RFC3439] Bush, R. and D. Meyer, "Some Internet
Architectural Guidelines and Philosophy", RFC Architectural Guidelines and Philosophy", RFC
3439, December, 2002. 3439, December, 2002.
[SAFI] http://www.iana.org/assignments/safi-namespace [SAFI] http://www.iana.org/assignments/safi-namespace
[VLPS] Kompella, K., et. al. "Virtual Private LAN [VPLS] Kompella, K., et. al. "Virtual Private LAN
Service", draft-ietf-l2vpn-vpls-bgp-02.txt. Service", draft-ietf-l2vpn-vpls-bgp-01.txt.
Work in progress. Work in progress.
[VPWS] Kompella, K. et.al. "Layer 2 VPNs Over Tunnels", [VPWS] Kompella, K. et.al. "Layer 2 VPNs Over Tunnels",
draft-kompella-ppvpn-l2vpn-04.txt. Work in draft-kompella-ppvpn-l2vpn-04.txt. Work in
progress. progress.
17.2. Informative References 16.2. Informative References
[IETFOL] https://www1.ietf.org/mailman/listinfo/routing-discussion [IETFOL] https://www1.ietf.org/mailman/listinfo/routing-discussion
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119, March, Indicate Requirement Levels", RFC 2119, March,
1997. 1997.
[RFC2026] Bradner, S., "The Internet Standards Process -- [RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", RFC 2026/BCP 9, October, 1996. Revision 3", RFC 2026/BCP 9, October, 1996.
skipping to change at page 29, line 5 skipping to change at page 38, line 5
[RFC2434] Narten, T., and H. Alvestrand, "Guidelines for [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs", Writing an IANA Considerations Section in RFCs",
RFC 2434/BCP 26, October 1998. RFC 2434/BCP 26, October 1998.
[RVBIB] http://www.routeviews.org/papers [RVBIB] http://www.routeviews.org/papers
[WILLINGER2002] Willinger, W., and J. Doyle, "Robustness and the [WILLINGER2002] Willinger, W., and J. Doyle, "Robustness and the
Internet: Design and evolution", 2002. Internet: Design and evolution", 2002.
18. Editor's Address 17. Editor's Address
David Meyer David Meyer
Email: dmm@1-4-5.net Email: dmm@1-4-5.net
19. Full Copyright Statement 18. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
skipping to change at line 1033 skipping to change at line 1431
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Meyer, et. al.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/