draft-ietf-mpls-seamless-mpls-00.txt   draft-ietf-mpls-seamless-mpls-01.txt 
MPLS Working Group N. Leymann, Ed. MPLS Working Group N. Leymann, Ed.
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Intended status: Informational B. Decraene Intended status: Informational B. Decraene
Expires: November 30, 2011 France Telecom Expires: September 13, 2012 France Telecom
C. Filsfils C. Filsfils
Cisco Systems
M. Konstantynowicz M. Konstantynowicz
Juniper Networks Cisco Systems
D. Steinberg D. Steinberg
Steinberg Consulting Steinberg Consulting
May 29, 2011 March 12, 2012
Seamless MPLS Architecture Seamless MPLS Architecture
draft-ietf-mpls-seamless-mpls-00 draft-ietf-mpls-seamless-mpls-01
Abstract Abstract
This documents describes an architecture which can be used to extend This documents describes an architecture which can be used to extend
MPLS networks to integrate access and aggregation networks into a MPLS networks to integrate access and aggregation networks into a
single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is
based on existing and well known protocols. It provides a highly based on existing and well known protocols. It provides a highly
flexible and a scalable architecture and the possibility to integrate flexible and a scalable architecture and the possibility to integrate
100.000 of nodes. The separation of the service and transport plane 100.000 of nodes. The separation of the service and transport plane
is one of the key elements; Seamless MPLS provides end to end service is one of the key elements; Seamless MPLS provides end to end service
skipping to change at page 2, line 4 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 30, 2011.
This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Why Seamless MPLS . . . . . . . . . . . . . . . . . . . . 7 2.1. Why Seamless MPLS . . . . . . . . . . . . . . . . . . . . 6
2.2. Use Case #1 . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Use Case #1 . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Description . . . . . . . . . . . . . . . . . . . . . 8 2.2.1. Description . . . . . . . . . . . . . . . . . . . . . 7
2.2.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 11 2.2.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 10
2.3. Use Case #2 . . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Use Case #2 . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1. Description . . . . . . . . . . . . . . . . . . . . . 11 2.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10
2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 13 2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 12
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 14 3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 13
3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Availability . . . . . . . . . . . . . . . . . . . . . . . 15 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 16 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 16 3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . . 16 4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . . 15
4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . . 17 4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . . 16
4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . . 17 4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . . 16
4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 18 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 17
5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . . 18 5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . . 17
5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 18 5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. General Network Topology . . . . . . . . . . . . . . . 18 5.1.2. General Network Topology . . . . . . . . . . . . . . . 17
5.1.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . 19 5.1.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . 18
5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . . 20 5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . . 19
5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . . 20 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 20 5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19
5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . . 21 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . . 20
5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . . 22 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . . 21
5.1.7. Labled iBGP next-hop handling . . . . . . . . . . . . 23 5.1.7. Labled iBGP next-hop handling . . . . . . . . . . . . 22
5.1.8. Network Availability and Simplicity . . . . . . . . . 24 5.1.8. Network Availability and Simplicity . . . . . . . . . 23
5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 24 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 23
5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . . 25 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . . 24
5.1.8.3. Hierarchical Dataplane and BGP Prefix 5.1.8.3. Hierarchical Dataplane and BGP Prefix
Independent Convergence . . . . . . . . . . . . . 25 Independent Convergence . . . . . . . . . . . . . 24
5.1.8.4. Local Protection using Anycast BGP . . . . . . . . 26 5.1.8.4. Local Protection using Anycast BGP . . . . . . . . 25
5.1.8.5. Assessing loss of connectivity upon any failure . 31 5.1.8.5. Assessing loss of connectivity upon any failure . 30
5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 36 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 35
5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . . 37 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . . 36
5.1.9. Next-Hop Redundancy . . . . . . . . . . . . . . . . . 37 5.1.9. Next-Hop Redundancy . . . . . . . . . . . . . . . . . 36
5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . . 38 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . . 37
5.2.1. Control and Data Plane State for Deployment 5.2.1. Control and Data Plane State for Deployment
Scenario #1 . . . . . . . . . . . . . . . . . . . . . 38 Scenario #1 . . . . . . . . . . . . . . . . . . . . . 37
5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . . 38 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . . 37
5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 39 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 38
5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . . 40 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . . 39
5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 41 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 40
5.2.1.5. Numerical application for use case #1 . . . . . . 42 5.2.1.5. Numerical application for use case #1 . . . . . . 41
5.2.1.6. Numerical application for use case #2 . . . . . . 42 5.2.1.6. Numerical application for use case #2 . . . . . . 41
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
8. Security Considerations . . . . . . . . . . . . . . . . . . . 44 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
8.1. Access Network Security . . . . . . . . . . . . . . . . . 43
8.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 43
8.3. Control Plane Security . . . . . . . . . . . . . . . . . . 44
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Normative References . . . . . . . . . . . . . . . . . . . 44 9.1. Normative References . . . . . . . . . . . . . . . . . . . 44
9.2. Informative References . . . . . . . . . . . . . . . . . . 44 9.2. Informative References . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
MPLS as a mature and well known technology is widely deployed in MPLS as a mature and well known technology is widely deployed in
today's core and aggregation/metro area networks. Many metro area today's core and aggregation/metro area networks. Many metro area
networks are already based on MPLS delivering Ethernet services to networks are already based on MPLS delivering Ethernet services to
residential and business customers. Until now those deployments are residential and business customers. Until now those deployments are
usually done in different domains; e.g. core and metro area networks usually done in different domains; e.g. core and metro area networks
are handled as separate MPLS domains. are handled as separate MPLS domains.
skipping to change at page 43, line 27 skipping to change at page 42, line 27
o TN IP FIB 750 o TN IP FIB 750
o TN MPLS LFIB 150 o TN MPLS LFIB 150
o RR BGP NLRI 40 000 o RR BGP NLRI 40 000
o RR BGP paths 80 000 o RR BGP paths 80 000
6. Acknowledgements 6. Acknowledgements
Many people contributed to this document. The authors wish to thank Many people contributed to this document. The authors would like to
- in alphabetical order: thank Wim Henderickx, Clarence Filsfils, Thomas Beckhaus, Wilfried
Maas, Roger Wenner, Kireeti Kompella, Yakov Rekhter, Mark Tinka and
o Wim Henderickx (Alcatel) Simon DeLord for their suggestions and review.
o Clarence Filsfils (Cisco Networks),
o Thomas Beckhaus, Wilfried Maas, Roger Wenner (Deutsche Telekom),
o Kireeti Kompella, Yakov Rekhter (Juniper Networks),
o Mark Tinka (Global Transit)
o Simon DeLord (Telstra)
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
All drafts are required to have an IANA considerations section (see All drafts are required to have an IANA considerations section (see
the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis]
for a guide). If the draft does not require IANA to do anything, the for a guide). If the draft does not require IANA to do anything, the
section contains an explicit statement that this is the case (as section contains an explicit statement that this is the case (as
above). If there are no requirements for IANA, the section will be above). If there are no requirements for IANA, the section will be
removed during conversion into an RFC by the RFC Editor. removed during conversion into an RFC by the RFC Editor.
8. Security Considerations 8. Security Considerations
In a typical MPLS deployment the use of MPLS is limited to relatively The Seamless MPLS Architecture is subject to similar security threats
small network consisting of core and edge nodes. Those nodes are as any MPLS LDP deployment. It is recommended that baseline security
under full control of the services provider and placed at locations measures are considered as described in the LDP specification RFC5036
where only authorized personal has access (this also includes [RFC5036] including ensuring authenticity and integrity of LDP
physical access to the nodes). With the extensions of MPLS towards messages, as well as protection against spoofing and Denial of
access and aggregation nodes not all nodes will be "locked away" in Service attacks. Some deployments may require increased measures of
secure locations. Small access nodes like DSLAMs will be located in network security if a subset of Access Nodes are placed in locations
street cabinets, potentially offering access to the "interested with lower levels of physical security e.g. street cabinets ( common
researcher". Nevertheless the unauthorized access to such in device practice for VDSL access ). In such cases it is the responsibility
SHOULD NOT impose any security risks to the MPLS infrastructure of the system designer to take into account the physical security
itself. Seamless MPLS must be stable regarding attacks against measures ( environmental design, mechanical or electronic access
access and aggregation nodes running MPLS. control, intrusion detection ), as well as monitoring and auditing
measures (configuration and Operating System changes, reloads, routes
advertisements ). But even with all this in mind, the designer still
should consider network security risks and adequate measures arising
from the lower level of physical security of those locations.
Levels of Security: tbd. 8.1. Access Network Security
Access Network: tbd. A detailed description for Access Network Security in Seamless MPLS
can be found in the LDP Downstream on Demand document
[I-D.ietf-mpls-ldp-dod].
Aggregation Network: tbd. 8.2. Data Plane Security
Core Network: tbd. Data plane security risks applicable to the access MPLS network are
listed below (a non-exhaustive list):
a. packets from a specific access node flow to an altered transport
layer or service layer destination.
b. packets belonging to undefined services flow to and from the
access network.
c. unlabelled packets destined to remote network nodes.
Following mechanisms should be considered to address listed data
plane security risks:
1. addressing (a) - Access and ABR LSRs SHOULD NOT accept labeled
packets over a particular data link, unless from the Access or
ABR LSR perspective this data link is known to attach to a
trusted system based on employed authentication mechanism(s), and
the top label has been distributed to the upstream neighbour by
the receiving Access or ABR LSR.
2. addressing (a) - ABR LSR MAY restrict network reachability for
access devices to a subset of remote network LSR, based on
authentication or other network security technologies employed
towards Access LSRs. Restricted reachability can be enforced on
the ABR LSR using local routing policies, and can be distributed
towards the core MPLS network using routing policies associated
with access MPLS FECs.
3. addressing (b) - labeled service routes (e.g. MPLS/VPN, tLDP)
are not accepted from unreliable routing peers. Detection of
unreliable routing peers is achieved by engaging routing protocol
detection and alarm mechanisms, and is out of scope of this
document.
4. addressing (a) and (b) - no successful attacks have been mounted
on the control plane and has been detected.
5. addressing (c) - ABR LSR MAY restrict IP network reachability to
and from the access LSR.
8.3. Control Plane Security
Similarly to Inter-AS MPLS/VPN deployments RFC4364 [RFC4364], the
data plane security depends on the security of the control plane. To
ensure control plane security access LDP DoD connections MUST only be
made with LDP peers that are considered trusted from the local LSR
perspective, meaning they are reachable over a data link that is
known to attach to a trusted system based on employed authentication
mechanism(s) on the local LSR. The TCP/IP MD5 authentication option
RFC5925 [RFC5925] should be used with LDP as described in LDP
specification RFC5036 [RFC5036]. If TCP/IP MD5 authentication is
considered not secure enough, the designer may consider using a more
elaborate and advanced TCP Authentication Option (TCP-AO RFC5925
[RFC5925]) for LDP session authentication. Access IGP (if used) and
any routing protocols used in access network for signalling service
routes SHOULD also be secured in a similar manner. For increased
level of authentication in the control plane security for a subset of
access locations with lower physical security, designer could also
consider using:
o different crypto keys for use in authentication procedures for
these locations.
o stricter network protection mechanisms including DoS protection,
interface and session flap dampening.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 9.2. Informative References
skipping to change at page 45, line 13 skipping to change at page 45, line 28
Uttaro, J., Leymann, N., and M. Horneffer, "LFA Uttaro, J., Leymann, N., and M. Horneffer, "LFA
applicability in SP networks", applicability in SP networks",
draft-filsfils-rtgwg-lfa-applicability-00 (work in draft-filsfils-rtgwg-lfa-applicability-00 (work in
progress), March 2010. progress), March 2010.
[I-D.ietf-bfd-v4v6-1hop] [I-D.ietf-bfd-v4v6-1hop]
Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single
Hop)", draft-ietf-bfd-v4v6-1hop-11 (work in progress), Hop)", draft-ietf-bfd-v4v6-1hop-11 (work in progress),
January 2010. January 2010.
[I-D.ietf-mpls-ldp-dod]
Beckhaus, T., Decraene, B., Tiruveedhula, K.,
Konstantynowicz, M., and L. Martini, "LDP Downstream-on-
Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-00 (work
in progress), January 2012.
[I-D.kothari-henderickx-l2vpn-vpls-multihoming] [I-D.kothari-henderickx-l2vpn-vpls-multihoming]
Kothari, B., Kompella, K., Henderickx, W., and F. Balus, Kothari, B., Kompella, K., Henderickx, W., and F. Balus,
"BGP based Multi-homing in Virtual Private LAN Service", "BGP based Multi-homing in Virtual Private LAN Service",
draft-kothari-henderickx-l2vpn-vpls-multihoming-01 (work draft-kothari-henderickx-l2vpn-vpls-multihoming-01 (work
in progress), July 2009. in progress), July 2009.
[I-D.narten-iana-considerations-rfc2434bis] [I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-09 (work in draft-narten-iana-considerations-rfc2434bis-09 (work in
skipping to change at page 46, line 34 skipping to change at page 47, line 6
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
for Inter-Area Label Switched Paths (LSPs)", RFC 5283, for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
July 2008. July 2008.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008. Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", RFC 5332, August 2008. Multicast Encapsulations", RFC 5332, August 2008.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
Authors' Addresses Authors' Addresses
Nicolai Leymann (editor) Nicolai Leymann (editor)
Deutsche Telekom AG Deutsche Telekom AG
Winterfeldtstrasse 21 Winterfeldtstrasse 21
Berlin 10781 Berlin 10781
DE DE
Phone: +49 30 8353-92761 Phone: +49 30 8353-92761
Email: n.leymann@telekom.de Email: n.leymann@telekom.de
skipping to change at page 47, line 26 skipping to change at page 48, line 6
Cisco Systems Cisco Systems
Brussels, Brussels,
Belgium Belgium
Phone: Phone:
Fax: Fax:
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
URI: URI:
Maciek Konstantynowicz Maciek Konstantynowicz
Juniper Networks Cisco Systems
Phone: Phone:
Fax: Fax:
Email: maciek@juniper.net Email: maciek@cisco.com
URI: URI:
Dirk Steinberg Dirk Steinberg
Steinberg Consulting Steinberg Consulting
Ringstrasse 2 Ringstrasse 2
Buchholz 53567 Buchholz 53567
DE DE
Email: dws@steinbergnet.net Email: dws@steinbergnet.net
 End of changes. 21 change blocks. 
100 lines changed or deleted 173 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/