Internet DRAFT - draft-unbehagen-spb-ip-ipvpn
draft-unbehagen-spb-ip-ipvpn
INTERNET-DRAFT Paul Unbehagen
Intended Status: Informational Roger Lapuh
Expires: September 6, 2012 Avaya
Sue Hares
Peter Ashwood-Smith
Hauwei
March 5, 2012
IP/IPVPN services with IEEE 802.1aq SPB networks
draft-unbehagen-spb-ip-ipvpn-00.txt
Abstract
This document describes a compact method of using a IEEE 802.1aq
Shortest Path Backbone Bridging (SPB) network to natively enable and
carry IP and IPVPN services on native Ethernet links. Further this
documents the extensions to SPB's control protocol, IS-IS, required
to allow it to be a single mechanism for providing all these services
types. On its own SPB provides virtual Ethernet networks; utilizing
IS-IS to create loop free Ethernet topologies that forward Ethernet
traffic using a standard Ethernet header. This document shows how
the same SPB network can also be leveraged to provide IP based
services.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Unbehagen et al Expires September 6, 2012 [Page 1]
INTERNET DRAFT IP/SPB March 5, 2012
Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SPB control of BMAC forwarding . . . . . . . . . . . . . . . . 4
3. IP forwarding with SPB . . . . . . . . . . . . . . . . . . . . 5
3.1. IP Unicast . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IPVPN services with SPB . . . . . . . . . . . . . . . . . . . . 6
4.1. Route Propagation Techniques . . . . . . . . . . . . . . . 6
4.2. Ethernet underlay modes - 802.1aq and/or 802.1Qbp . . . . . 8
4.3. I-TAG Encapsulation . . . . . . . . . . . . . . . . . . . . 9
5. Interworking with MPLS based Networks . . . . . . . . . . . . . 10
6. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 12
9.2 Informative References . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Unbehagen et al Expires September 6, 2012 [Page 2]
INTERNET DRAFT IP/SPB March 5, 2012
1 Introduction
The IEEE has defined a method for L2 virtualization called Shortest
Path Bridging (SPB), which is leveraging IS-IS as a new Ethernet
control plane to control the BMAC layer of the 802.1ah PBB
encapsulation, replacing Ethernet's flooding and learning as the
backbone forwarding protocol. In addition to layer 2 (bridging), the
24 bits of the Service Instance defined in the 802.1ah frame format
can also be leveraged for any network connectivity service including
layer 3 Unicast and Multicast for IPv4 and IPv6. This document
outlines the proposed extensions to ISIS-SPB to enable this
functionality. The benefits of leveraging one protocol (ISIS-SPB) to
provide any type of connectivity service on top of Ethernet are
significant.
SPB, through the use of ISIS to exchange the connectivity service
topology, provides a powerful end-point-only provisioning model.
IP/SPB leverages this and extends this to Layer 3, thus not only L2
VPNs can be formed by attaching Virtual LANs to service IDs (ISIDs),
but also L3 VPNs can be formed by binding Virtual Route Forwarders
(VRFs) to ISIDs at the service attachment points.
Due to the fact that all connectivity services described above are
using the same SPB forwarding plane defined in IEEE802.1aq/.1Qbp,
network availability is defined by the convergence timing of the
single ISIS-SPB control plane.
1.1 Terminology
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 [RFC2119].
[IEEE802.1aq] defines a technology for providing a link state
protocol for the control of a common Ethernet switching layer.
[IEEE802.1ah] Provider Backbone Bridging is a set of architecture
and protocols for transporting of a customer network traffic over a
provider's network
BCB - Backbone Core Bridge
BDA - Backbone Destination Address
BEB - Backbone Edge Bridge
BMAC - Backbone MAC Address
Unbehagen et al Expires September 6, 2012 [Page 3]
INTERNET DRAFT IP/SPB March 5, 2012
BSA - Backbone Source Address
BVID - Backbone VLAN ID
ESP - Ethernet Switched Path
ISID - Service Identifier
ISIS - Intermediate System to Intermediate System Routing
Protocol
ISIS-SPB - ISIS extensions for SPB
MDT - Multicast Distribution Tree
SPF - Shortest Path Forwarding
SPB - Shortest Path Bridging
TLV - Type Length Value
VLAN - Virtual LAN
2. SPB control of BMAC forwarding
SPB uses the terms Backbone Core Bridge (BCB) and Backbone Edge
Bridge (BEB) to describe the functions of network nodes in the
network. These terms describe features that are similar in function
to the PE and P nodes in an MPLS network.
SPB enables a loop free construction of Ethernet switched paths
between every SPB enabled node by reusing some existing components of
IS-IS and by adding a small set of new IS-IS TLVs. SPB nodes use a
standard IS-IS mechanism of operation for neighbor discovery and
database distribution. SPB utilizes an IS-IS based on IS-IS Ethernet
link level peering protocol so it does not depend on link level IP
addressing. Also, due to the fact that the links are forwarding on
the source and destination information in the Ethernet header, there
is no requirement to verify that each node can do IP routing.
Multicast Forwarding entries (BMAC FDB or FIB) on each node are
constructed based on a combination of a nodal unique identifier and a
administratively controlled service identifier providing multicast
trees that can be adjusted to match a desired service granularity.
Each node uses standard IS-IS methods of sharing link state PDU's.
Those PDUs contain the System-ID of each node, the attached neighbors
and information such as EVPN ISIDs for SPB. A unicast SPF process
runs on each switch to construct the unicast connectivity of each
Unbehagen et al Expires September 6, 2012 [Page 4]
INTERNET DRAFT IP/SPB March 5, 2012
switch to every other switch based on these nodal MAC's (BMACs)
derived from the System-ID. Each node that is on the shortest path
between any other given nodes will install corresponding FDB entries
only on their associated ports. This has the added benefit that
Ethernet FDB entries exist only on nodes that are the source, root,
or tandem point for a give SPF ESP between any given set of nodes.
Any node that does not need to participate in the tandem calculations
may use the IS-IS overload bit to exclude tandem paths and behave as
only the root or source for any given service traffic.
3. IP forwarding with SPB
IP unicast and multicast can leverage this base BMAC switching layer
by mapping IP to the Ethernet service points. For unicast forwarding
the standard mechanisms of IS-IS IP route propagation can be used to
associate remote IP networks to the far end nodal Ethernet address.
The encapsulation of IP unicast packets would use the standard method
to include an Ethertype of 0x800 behind the BMAC header.
Packets received Packets in transit Packets forwarded
at ingress BEB in the network by egress BEB
+============+ +=============+ +============+
| IP Header | | IP Header | | IP Header |
+============+ >>>>> +=============+ >>>>> +============+
| C-MAC | | B-MAC | | C-MAC |
+============+ +=============+ +============+
3.1. IP Unicast
The native unicast entries SPB constructs, provide a simple way of
enabling end to end switching of IP packets along a deterministic
Ethernet Switched Path (ESP). Knowledge of the location of IP
subnet's is achieved by utilizing the existing functionality of IS-IS
TLVs for IPv4 and IPv6. The control plane operation becomes one of
simply creating FDB entries that map IP routes to their points of
presence. In other words the FDB entry for an IP route simply gives
the last hop BMAC of the BEB which advertised that route. No shortest
path computations are required since that has already been
accomplished by the SPB layer. For IP subnet awareness the existing
IS-IS TLVs are used to propagate routes. The encapsulation is the
standard IP in Ethernet encapsulation.
To enable this behavior, this document specifies an efficient
learning and forwarding operation where an edge BEB provides a
Unbehagen et al Expires September 6, 2012 [Page 5]
INTERNET DRAFT IP/SPB March 5, 2012
standard IP interface to its attached IP devices. The BEB performs a
route lookup on the destination IP addresses which will resolve to a
remote BMAC to forward towards on the SPB portion of the network, and
then encapsulates the IP packet in a Ethernet header using the
unicast BMAC operation with a standard IPv4 or IPv6 Ethertype. In
essence this is IP over Ethernet where the Ethernet is a BMAC based
Ethernet. One simple way to think of this is that existing ISIS for
IP implementations forward IP packets to the next hop router, while
this mechanism forwards an IP packet directly to the last hop BEB
within the SPB domain thereby eliminating IP forwarding operations on
tandem devices.
4. IPVPN services with SPB
Using the TLV extensions described below it is possible to extend SPB
to not only provide EVPN and the above described IP connectivity, but
also provide virtualized solutions for IP services such as IPVPNs.
The next sections will outline the route propagation techniques for
two different deployment models.
Two common modes of carrying information are: BGP or ISIS [ISIS].
The IS-IS method will be described in this version of the draft. The
control plane encapsulation of VRF routes passed in BGP is similar to
the method used here with ISIS.
4.1. Route Propagation Techniques
The ability to share routes within a network can be provided within
IS-IS. To accomplish this flexibility the use of a new IPVPN TLV and
an optional sub-TLV is proposed.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| MT-ID |U|Resv | VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Resv |S| ISID Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 IPVPN TLV
The TLV MAY appear any number of times (including none) within a Link
State PDU.
The up/down bit used for notification if this TLV has been leaked
down into a L1.
The T bit and R bit are used to signal to the other nodes whether to
construct Multicast trees to and from this announcing node depending
on the combination of bits set to 1. If neither the T nor R bit is
Unbehagen et al Expires September 6, 2012 [Page 6]
INTERNET DRAFT IP/SPB March 5, 2012
set, then the IPVPN service is unicast only. The next 4 bits are
reserved and the S bit is used to signify that the VPN-Route Sub-TLVs
are present.
Sub-TLVs may be set to carry specific routes for each VPN within IS-
IS. This allows for routes from multiple VPNs to be carried under
their respective VPN ISID IDs and allow for overlapping IP subnet's.
IP/SPB VPN ISIDs are comparable to RFC4364 Route distinguishers and
route targets to separate VPN traffic in the control plane. VPN
routes are exchanged through IS-IS and can be distinguished by the
individual ISID they are associated with. In order to form different
types of IP VPNs on BEB's, routes can be exported into ISID's or
imported from ISID's.
This document also defines the following new sub-TLV types that need
to be reflected in the IS-IS sub-TLV registry for the SPB ipvpn TLV:
Sub-Type Description
------- ------------------------------
1 IPv4 Prefix information
2 IPv6 Prefix information
3 Reserved
4 Reserved
The encapsulation is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Sub-TLV model
The sub-TLVs are designed to mimic the top level TLVs for IP
reachability within the VPN. Allowing for a given VRF to support
multiple IP service models within a single VPN-ID.
Sub-TLV 1 is similar as the Extended IPv4 TLV 135 and MAY appear
multiple times in the same TLV with a data structure consisting of:
Unbehagen et al Expires September 6, 2012 [Page 7]
INTERNET DRAFT IP/SPB March 5, 2012
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | Resv |S| Prefix Ln |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 IPv4 sub-TLV
Sub-TLV 2 is similar to the IPv6 TLV 236 and MAY appear multiple
times in the same TLV with a data structure consisting of:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Resv |E|S| Prefix Ln |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 IPv6 sub-TLV
4.2. Ethernet underlay modes - 802.1aq and/or 802.1Qbp
Shortest Path Bridging supports two major modes for L2VPNs via
802.1aq [SPB] and 802.1Qbp [ECMP] the behaviors of which may be
selected on a per ISID basis for carriage of L3VPNs as follows.
The 802.1aq [SPB] L2 underlay on which IPVPN packets flow, supports
deterministic and symmetric multiple equal cost routes with hashing
to the different routes at the head end via normal IP n-tuple or
other micro flow order preserving hash mechanisms. To obtain this
behavior the IPVPN TLV VID field MUST contain a BVID value which has
been associated with one of the 802.1aq ECT-ALGORITHMS by the SPB
underlay in the SPB Base VLAN-Identifiers sub-TLV. This will cause
the ISID information which follows to have 802.1aq semantics - i.e.
(S,G) multicast and symmetric/congruent routing. The normal 802.1aq
ECT-ALGORITHM values 00-80-C2-01 thru 00-80-C2-10 and their
associated VIDs are advertised normally in the IIH and LSPs for
802.1aq and the head end IPVPN behavior is free to hash over any or
all of those VIDs.
Unbehagen et al Expires September 6, 2012 [Page 8]
INTERNET DRAFT IP/SPB March 5, 2012
The 802.1Qbp [ECMP] extensions to [SPB] supports a flow-tag with a
FlowId and TTL resulting in a per hop hashed choice of next hop by L2
forwarding. To obtain this behavior the IPVPN TLV VID field MUST
contain a BVID value which has been associated with one of the
802.1Qbp ECT-ALGORITHMS by the SPB underlay in the SPB Base VLAN-
Identifiers sub-TLV. This will cause the ISID information which
follows to have 802.1Qbp semantics - i.e. (*,G) and/or (S,G)
multicast and non deterministic non symmetric routing. The normal
802.1Qbp ECT-ALGORITHM value 00-80-C2-11 and its associated VIDs are
advertised normally in the IIH and LSPs for 802.1Qbp and the head end
IPVPN behavior is free to hash over all ECMP L2 next hops for this
VID and to insert a flow-tag with appropriate TTL value and FlowId
based on the L3 hash result. The TTL and FlowId will then be used to
enable tandem .1Qbp ECMP behavior without knowledge of or inspection
of the L3VPN headers.
4.3. I-TAG Encapsulation
For the forwarding of IPVPN traffic the use of the standard 802.1ah
I-TAG would require the encapsulation of a nulled out CMAC address,
since the traffic is IP and routed at each BEB there is no need for a
CMAC. Therefore the more optimal encapsulated method used for IPVPN
traffic within the SPB network is to use the ISID portion of the I-
TAG without a CMAC header, called the short I-TAG. This allows the
network to carry forward the benefits of the global label/VPN ID
purpose of the ISID without enforcing unnecessary header overhead.
The encapsulation of IP packets being forwarded for a IPVPN would use
a short I-Tag (ISID with no CMAC) behind the BMAC header. While the
short I-TAG is the recommended mode for carrying IPVPN traffic this
standard permits the inclusion of a zerod out CMAC. In this case the
sender MUST zero out the CMAC on transmission and MUST ignore a non-
zero CMAC on receipt.
Packets received Packets in transit Packets forwarded
at ingress BEB VRF in the network by egress BEB VRF
+=============+
| IP Header |
+============+ +=============+ +============+
| IP Header | | Short I-TAG | | IP Header |
+============+ >>>>> +=============+ >>>>> +============+
| C-MAC | | B-MAC | | C-MAC |
+============+ +=============+ +============+
Figure 7 Short I-TAG encapsulation of IPVPN Packets
Unbehagen et al Expires September 6, 2012 [Page 9]
INTERNET DRAFT IP/SPB March 5, 2012
Where the ISID encapsulation is as follows. Directly between the VLAN
and IP header.
.1ah I-TAG TCI
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P/DE |R1 |R2 | I-SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 Short I-Tag
P/DE 3 Bits Priority, 1 bit Drop Eligible
R1 Res1
R2 Res2
5. Interworking with MPLS based Networks
Any IP/SPB and/or IPVPN SPB network may exist on its own or may be
part of a larger network. For example it may be attached to a
standard IP or IP/MPLS network. This section will define a use case
for using an SPB base network as a method of extending IPVPNs from a
IP/MPLS core network. A similar model exists for the ELAN service
that may span both a SPB and VPLS portions of the network as defined
in [PBBVPLS] The scale and size of the SPB portion of the network and
network devices can then be utilized more efficiently as a single
protocol will drain less resources and thereby allow the IPVPN VRFs
extend closer to the end customer. Another benefit is that packets
that are destined within the SPB network can be forwarded directly in
the SPB portion of the domain without needing to be processed by the
MPLS PE.
Unbehagen et al Expires September 6, 2012 [Page 10]
INTERNET DRAFT IP/SPB March 5, 2012
_,,..--..,,,
,-'` `'-,
.` `'
,' `.
/ ,
| IP MPLS Core |
`
`. `
', _-`
+------/-,, _,-,------+
| ,-,/ | ``'''--'''`` | ,-, |
MPLS-PE1 | |VRF| | | |VRF| |MPLS-PE2
| | | | BC-PEs | | | |
| `|' | | `|' |
+-,--,,-+ +--,--,,+
,' ,'
/ /
| SPB | | SPB |
| Network | | Network |
| | | |
/ /
`. / `. /
+------`-,,+-------+ +-------+'-'+-------+
| ,-, | | ,-, | | ,-, | | ,-, |
| |VRF| | | |VRF| | | |VRF| | | |VRF| |
| | | | | | | | BEBs | | | | | | | |
| `'' | | `'' | | `'' | | `'' |
+-------+ +-------+ +-------+ +-------+
BEB1 BEB2 BEB3 BEB4
Figure 12 MPLS Interworking
A vrf does Service Address Encapsulation on a VPN basis with some
entries of the VRF having MPLS labels and some have IPVPN SPB entries
based on the direction from which the route was learned. The VRF also
gets information from different topologies. Routes learned via BGP
have FIB entries pointing to the appropriate next hop and Label set.
While routes learned from the IPVPN ISID SPB domain have FDB entries
for the appropriate BMAC address and ISID.
Route propagation to and from each domain happens naturally via the
protocol interaction within a given VRF. Routes learned from the SPB
domain are automatically announced into the BGP domain or may have
policies applied and routes learned from other PE's from BGP are
automatically propagated towards the CE's by injecting them into the
SPB domain as a sub-TLV under the VRF's IPVPN ISID TLV.
Unbehagen et al Expires September 6, 2012 [Page 11]
INTERNET DRAFT IP/SPB March 5, 2012
6. OAM
Various techniques exist within the Ethernet standards space for
scalable management of Ethernet based networks. For example OAM
techniques defined in the IEEE 802.ag and the ITU Y.1731 can be used
for the IP based services similarly as they are defined for the EVPNs
7. Security Considerations
The extensions defined in this document do not incur any additional
security considerations. Any IS-IS SPB network may utilize the
security enhancements already defined within the IS-IS working group.
8. IANA Considerations
IP/SPB requires that IANA/ISO allocate a new number from ISIS-TLV
Codepoints for the IPVPN TLV.
IP/SPB also requires that IANA/ISO allocate a new registry for sub
TLV values within the above TLV. The first four values being: 1
IPV4 2 IPV6 3 reserved 4 reserved
9. References
9.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MTISIS] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[IPVPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[802.1AQ] "IEEE P802.1aq/D4.5 Draft Standard for Local and
Metropolitan Area Networks -- Media Access Control (MAC)
Bridges and Virtual Bridged Local Area Networks,
Amendment 8: Shortest Path Bridging", IEEE 802.1aq D4.5,
Feb 6, 2012
[802.1AQ] Ashwood-Smith, P, Fedyk, D., "IS-IS Extensions Supporting
IEEEE 802.1aq Shortest Path Bridging" RFC 6329, XXX, 2012.
9.2 Informative References
Unbehagen et al Expires September 6, 2012 [Page 12]
INTERNET DRAFT IP/SPB March 5, 2012
[IEEE802.1ah] "IEEE Standard for Local and Metropolitan Networks,
Virtual Bridged Local Area Networks, Amendment 7:
Provider Backbone Bridges" IEEE Std 802.1ah - 2008
amendment to IEEE 802.Q - 2005.
[ISIS] ISO/IEC 10589:2002, "Intermediate system to Intermediate
system routing information exchange protocol,"
ISO/IEC10589:2002.
[PBBVPLS] Extensions to VPLS PE model for Provider Backbone Bridging,
IETF, Internet Draft, draft-ietf-l2vpn-pbb-vpls-pe-model-
00.txt, Work in Progress, May 12 2009
10. Acknowledgments
The authors would like to thank Don Fedyk for input into the
contents of this document. And also Dave Allan, Nigel Bragg, Gautam
Khera, Srikanth Keesara and Harish Sankaran for their detailed review
of larger work that is behind this memo.
This document was prepared using nroff.
Authors' Addresses
Paul Unbehagen Jr
Avaya
1300 W. 120th Avenue
Westminster, CO 80234 USA
Email: unbehagen@avaya.com
Roger Lapuh
Avaya
Flughofstrasse 54
8152 Glattbrugg
Switzerland
Email: rlapuh@avaya.com
Peter Ashwood-Smith
Huawei Technologies Canada LTD.
303 Terry Fox drive, Suite 400
Kanata, Ontario , K2K 2J1, Canada
Email: peter.ashwoodsmith@huawei.com
Susan Hares
Huawei
Email: shares@ndzh.com
1-734-604-0332
Unbehagen et al Expires September 6, 2012 [Page 13]
INTERNET DRAFT IP/SPB March 5, 2012
Unbehagen et al Expires September 6, 2012 [Page 14]
