Network Working Group M. Bocci Internet Draft A. Zinin M. Aissaoui D. Papadimitriou A. Dolganow Alcatel Frederic Jounay Yuji Kamite France Telecom NTT Communications Luca Martini Cisco Systems Expires: May 2008 November 19, 2007 OSPF Extensions for Dynamic Multi-segment Pseudo Wires draft-dolganow-pwe3-ospf-ms-pw-ext-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 19, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Dolganow et. al. Expires May 19, 2008 [Page 1] Internet-Draft OSPF Extensions for Dynamic MS-PWs November 2007 Abstract Multi-segment pseudowires have been defined to enable emulated layer 1 and layer 2 services to be delivered from an IP based packet switched network over a sparse mesh of PSN tunnels and PW control protocol sessions. MS-PWs can be used to scale PW based networks over both a single AS, or between multiple ASs, and there is a particular need to be able to dynamically route MS-PWs through a given AS to reach PEs at or beyond the edge of the AS, where the route of the PW through each AS needs to be automatically determined. This draft proposes extensions to OSPF to enable the automatic advertisement of summarized PW FECs, thus enabling the dynamic routing of MS-PWs across an OSPF domain. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. Introduction................................................3 1.1. Terminology............................................4 1.2. Architecture...........................................4 2. Applicability...............................................5 3. OSPF Extensions.............................................6 3.1. Attachment Circuit Addressing...........................6 3.2. OSPFv2 LSAs............................................6 3.2.1. Pseudowire Switching LSA...........................6 3.3. OSPFv3 LSAs............................................8 3.3.1. Pseudowire Switching LSA...........................8 3.4. LSA Information Field...................................8 3.4.1. Exterior AII TLV...................................9 4. LSA Processing Procedures....................................9 4.1. P Routers..............................................9 4.2. PE Routers............................................10 5. Deployment Considerations...................................10 5.1. Impact on Existing P-Routers...........................10 5.2. Congestion in the Underlying PSN Routing...............11 Dolganow et. al. Expires May 19, 2008 [Page 2] Internet-Draft OSPF Extensions for Dynamic MS-PWs November 2007 6. Security Considerations.....................................11 7. IANA Considerations........................................11 8. Acknowledgments............................................11 9. References.................................................12 9.1. Normative References...................................12 9.2. Informative References.................................12 Author's Addresses............................................13 Intellectual Property Statement................................14 Disclaimer of Validity........................................14 1. Introduction Multi-segment pseudowires have been defined to enable emulated layer 2 services to be delivered from an IP based packet switched network over a sparse mesh of PSN tunnels and PW control protocol adjacencies. MS-PWs can be used to scale PW based networks over both a single AS, and multiple ASs. Requirements for MS-PWs are detailed in [8]. A basic approach to MS-PWs, where the switching points are statically placed, is described in [10]. This is extended in [11] to allow the automatic placement of the MS-PWs. This draft uses FEC 129 with AII type II to summarize the PW end points that are reachable through a given PE, and to provide a layer 2 address for the S-PEs. MP-BGP is used to distribute FECs. The use of MP-BGP is primarily focused on scenarios where each PWE3 domain is a separate AS, and S-PEs are used to switch PWs between adjacent ASs. MP-BGP; therefore, provides the BGP-enabled T-PE or S- PE at the ingress of the AS with reachability information for AIIs at or beyond the border of the AS. This provides sufficient information to dynamically route the PW across the AS when there is a direct PSN tunnel between the ingress and egress S-PE or T-PE. When there is no direct PSN tunnel, a mechanisms must be provided to determine an indirect route for the PW via some intermediate S-PE within an AS domain. A second important case is where MS-PWs are deployed in service provider access and metro networks. Pseudowires in these networks typically span only a single IGP domain or AS. Furthermore, the nodes contain a minimal routing implementation to cut on the operational complexity. In such networks MP-BGP is not typically deployed on MTUs and full MP-BGP functionality may not be required. This prevents methods defined in [11] to be employed; however, the need to be able to dynamically route MS-PWs through these topologies still exists. Dolganow et. al. Expires May 19, 2008 [Page 3] Internet-Draft OSPF Extensions for Dynamic MS-PWs November 2007 To enable automatic placement of MS-PWs in the above described cases, it is possible to leverage the mechanisms of the PSN IGP to distribute MS-PW endpoint reachability information. This draft proposes extensions to OSPF to enable the automatic advertisement of summarized PW layer 2 addresses within a single AS, thus enabling the automatic placement of MS-PWs across an OSPF domain. The advertised information is used by T-PEs and S-PEs to derive the MS-PW next hop route which is used then to signal the next-hop S-PE or T-PE, as described in [11]. 1.1. Terminology The terminology defined in [9] applies. 1.2. Architecture +-----+ +-----+ |T-PE1+--------------------------------------------------+T-PE2| +-----+ +-----+ |<---------------------------PW----------------------------->| +-----+ +-----+ +-----+ +-----+ |T-PE1+-------------+S-PE1+-----------+S-PE2+------------+T-PE2| +-----+ +-----+ +-----+ +-----+ <---------------------- Single AS --------------------------> Figure 1 MS-PW Routing Model for a Single AS Figure 1 illustrates the MS-PW routing model for a single AS. ACs attached to T-PE2 are associated with the OSPF Router_ID or any locally assigned routable address. Each S-PE / T-PE is also assigned its own layer 2 address in the form of an AII as described in [11]. The proposed model requires the existence of PSN tunnels between T- PE/S-PE, S-PE/S-PE and/or S-PE/T-PE. PWs are established on these tunnels using Targeted LDP signaling [11]. Dolganow et. al. Expires May 19, 2008 [Page 4] Internet-Draft OSPF Extensions for Dynamic MS-PWs November 2007 When a PSN tunnel exists and can be used for the establishment of MS- PW or it segment, T-PE advertises the set of exterior AIIs reachable via this tunnel. This is done using summarized Type 2 AIIs so that a separate advertisement is not required for every AC reachable via that tunnel. AIIs may be summarized using the aggregation rules for AII Type 2 described in [6]. When an advertisement is received by an S-PE and the S-PE has a PSN tunnel connectivity to the advertising PE, the advertisement is installed in the S-PE's routing information and the S-PE summarizes AIIs at the far end of the tunnel in its own advertisement for propagation in the AS backbone and further propagation into other areas.. When an advertisement is received by a T-PE and the T-PE has a PSN tunnel connectivity to the advertising PE, the advertisement is installed in the PE's routing information. Alternatively to the above summarization-based population of an advertisement at S-PEs, a static, through configuration, method may be employed at the S-PE to populate AIIs reachable through it. Based on the information advertised, each PE builds a routing information base containing all exterior AIIs reachable through a given next hop S-PE. When creating an MS-PW, the PE looks up the AII and determines the next hop S-PE or T-PE for LDP signalling as described in [11]. Figure 1 depicts the simple model of one-to-one relations of a T-PE to S-PE and S-PE to S-PE, and of a single S-PE to S-PE segment. In the general case, multiple S-PE segments will exist, and the relation between two S-PEs or/and T-PE and S-PEs will be one-to-many or many- to-one. Processing in these cases follows that of the general case illustrated in Figure 1. Selection of an S-PE from a set of multiple available next-hop S-PEs may be achieved by comparing the IGP metrics for the route to the terminating T-PE (TT-PE) via each of these next- hop S-PEs. 2. Applicability The proposed OSPF protocol extensions are intended for domains where MP-BGP is not used and/or where only a partial mesh of PSN tunnels exists. In many cases, this will apply to routing MS-PWs across a single AS, where the source T-PE (ST-PE), the Terminating T-PE (TT- PE) and all of the intermediate S-PEs reside in the same AS. However, the above application may also be used where OSPF is used to route one portion of a MS-PW across a given AS where the ST-PE and the TT-PE reside in different ASs. Here, OSPF is used to advertise the AIIs reachable through S-PEs corresponding to ASBRs. This enables the ingress S-PEs and intermediate S-PEs in an AS to route MS-PWs to the correct egress S-PE in the AS to reach a TT-PE in another AS. Dolganow et. al. Expires May 19, 2008 [Page 5] Internet-Draft OSPF Extensions for Dynamic MS-PWs November 2007 This draft does not define how the egress S-PE learns what AIIs are externally reachable through it, but this could be by configuration, or by learning the exterior reachable addresses from an exterior gateway protocol such as BGP. 3. OSPF Extensions 3.1. Attachment Circuit Addressing As in [11], attachment circuit addressing is derived from AII type 2 [2], as shown in the following figure: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type=02 | Length | Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global ID (contd.) | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (contd.) | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AC ID (contd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Attachment Circuit Addressing Implementations of this procedure MUST interpret the AII as described in [11]. 3.2. OSPFv2 LSAs This extension makes use of the opaque LSA. One new LSA is defined: the PW Switching LSA. This LSA describes the S-PEs/T-PEs, PSN tunnel(s) between peer S-PEs or T-PEs, and AII addresses reachable. 3.2.1. Pseudowire Switching LSA OSPFv2 routers behaving as S-PEs or T-PEs advertise the layer 2 addresses reachable through them. This advertisement MUST be in an AS-scoped or Area-scoped opaque LSA. The format of the OSPFv2 opaque LSA is as follows: Dolganow et. al. Expires May 19, 2008 [Page 6] Internet-Draft OSPF Extensions for Dynamic MS-PWs November 2007 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | Scope | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | LSA Information | + + | ... | Options Field: The options field is described in RFC2370 [3]. The 'O' bit MUST be set to 1. The values of the other bits are TBD. Scope: This is set to the topological flooding scope of the LSA. Normally this is type 11 (AS-wide) or type 10 (Area wide). Opaque type: This field identifies the LSA to be of type PW Switching. Its value is TBD. Opaque ID: This is set to TBD Advertising Router: The OSPF router ID of the originating router. LSA Information: This is formatted as described in Section 3.4. below. Dolganow et. al. Expires May 19, 2008 [Page 7] Internet-Draft OSPF Extensions for Dynamic MS-PWs November 2007 3.3. OSPFv3 LSAs 3.3.1. Pseudowire Switching LSA The OSPFv3 PW switching LSA has a function code of TBD. The S1/S2 bit are set to indicate an AS flooding scope for the LSA. The U bit is set indicating the OSPFv3 PW switching LSA should be flooded even if it is not understood. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |1|S12| 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- LSA Information -+ | ... | LSA Information: This is formatted as described in Section 3.4. below. 3.4. LSA Information Field The LSA information consists of two or more nested Type/Length/Value (TLV) triplets. The format of each TLV is: Dolganow et. al. Expires May 19, 2008 [Page 8] Internet-Draft OSPF Extensions for Dynamic MS-PWs November 2007 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LSA MUST contain a TLV for the IP address of the advertising router. For OSPF v2 routers, this is the Router Address TLV defined in Section 2.4.1 of RFC 3630 [4]. For OSPF v3 routers, this is the Router IPv6 Address TLV specified in Section 3 of draft-ietf-ospf- ospfv3-traffic-07.txt [5]. In each of these, the router address MUST be set to the IP address of the advertising T-PE/S-PE. 3.4.1. Exterior AII TLV The Exterior AII TLV is used to describe addresses attached of attached T-PEs or those routable through S-PEs to T-PEs in another AS. If the LSA information is of type AII, then the value field contains one or more AII Type 2 TLVs, as described above. Exterior AIIs correspond to the AII (or AC) configured on a T-PE, which must contain at least the prefix and global ID to be used in FEC129 for signaling the PW endpoint. The prefix may or may not be directly related to the loopback address of the T-PE. 4. LSA Processing Procedures Nodes capable of pseudowire switching on either side of a PSN tunnel exchange PW switching LSAs with the AII using the PW switching opaque LSA. These PW switching LSAs are processed and flooded as described in Section 4.2. 4.1. P Routers OSPF routers that receive LSAs described in this document and that are not S-PEs or T-PEs MUST flood them according to the rules of OSPFv2 or OSPFv3, as applicable. Dolganow et. al. Expires May 19, 2008 [Page 9] Internet-Draft OSPF Extensions for Dynamic MS-PWs November 2007 4.2. PE Routers S-PEs and T-PEs that are OSPF routers and that receive LSAs described in this document MUST flood them according to the rules of OSPFv2 or OSPFv3, as applicable. These LSAs are also installed in a PW routing database. This routing database MAY be used by S-PEs and T-PEs to calculate a PW routing table. The PW routing table has the structure described in Section 7 of [11], and is used to determine the next signaling hop when a S-PE receives a PW setup message as described in that draft. PW static routes may also be provisioned, as described in [11]. S-PEs that receive LSAs described in this document MAY summarize Exterior AII TLVs received in non-backbone advertisements in that S- PEs own backbone advertisement, and MAY summarize Exterior AII TLVs received in backbone advertisements in that S-PEs non-backbone area advertisements. The algorithm used to calculate the PW routing table from the link state database, and the application of routing constraints, is beyond the scope of this draft. However, all T-PEs and S-PEs within the same PWE3 domain SHOULD use the same algorithm. 5. Deployment Considerations Addition and Removal of ACs, S-PEs and T-PEs The operational and deployment considerations for the addition and removal of S-PEs, T-PEs and ACs will be described in a future version of this draft. 5.1. Impact on Existing P-Routers P-routers supporting Opaque LSA processing procedures must exist along the flooding path in the AS to ensure propagation of the information required for dynamic pseudowire routing. Ideally, multiple "Opaque LSA" flooding paths exist, so a failure of a router along a path does isolate subset of a network. Routers supporting Opaque LSA processing as described in [3], will flood the LSAs as specified in [3]. The impact of this additional flooding load may be constrained through appropriate levels of aggregation of AIIs. Section 5.2. below describes other methods for limiting the impact of any additional flooding. Dolganow et. al. Expires May 19, 2008 [Page 10] Internet-Draft OSPF Extensions for Dynamic MS-PWs November 2007 5.2. Congestion in the Underlying PSN Routing This document describes the use of the underlying interior gateway protocol in an IP network to advertise routing information for the automatic placement of MS-PWs. Congestion may occur in the routing plane of the PSN if a large amount of pseudowire LSAs are flooded. It is therefore important to ensure that this does not degrade the performance of the IGP for the underlying PSN. Implementations may use a number of methods to avoid routing congestion, including: o Separate IGP instances for the underlying PSN and for the MS-PWs. o Prioritization of PSN LSAs over PW Switching LSAs. o Rate limiting PW Switching LSAs so that they do not consume excessive bandwidth or route processor capacity. o OSPF Refresh and Flooding reduction mechanisms as defined in [7]. 6. Security Considerations This section will be added in a future version. 7. IANA Considerations This document requests that the following allocations be made from existing registries: o The OSPFv2 opaque LSA type TBD for the PW switching opaque LSA. o The OSPFv3 LSA type function code TBD for the PW switching LSA 8. Acknowledgments The authors gratefully acknowledge the contributions of Vach Kompella, Devendra Raut and Yuichi Ikejiri. Dolganow et. al. Expires May 19, 2008 [Page 11] Internet-Draft OSPF Extensions for Dynamic MS-PWs November 2007 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Metz, C., et al, "AII Types for Aggregation", Internet Draft, draft-metz-aii-aggregate-01.txt, October 2006. [3] Coltun, R., " The OSPF Opaque LSA Option", RFC 2370, July 1998 [4] Katz D. et al., "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003 [5] Ishiguro K. et al., "Traffic Engineering Extensions to OSPF version 3", Internet Draft, draft-ietf-ospf-ospfv3-traffic- 07.txt, April 2006 [6] Metz C. et al., "Pseudowire Attachment Identifiers for Aggregation and VPN Autodiscovery", Internet Draft, draft-ietf- pwe3-aii-aggregate-01.txt, October 2006 [7] Pillay-Esnault P., "OSPF Refresh and Flooding Reduction in Stable Topologies", RFC 4136, July 2005 9.2. Informative References [8] Bitar, N., Bocci, M., and Martini, L., "Requirements for inter domain Pseudo-Wires", Internet Draft, draft-ietf-pwe3-ms-pw- requirements-02.txt, May 2006 [9] Bocci, M., and Bryant, S.,T., " An Architecture for Multi- Segment Pseudo Wire Emulation Edge-to-Edge", Internet Draft, draft-ietf-pwe3-ms-pw-arch-01.txt, May 2006 [10] Martini et al, "Segmented Pseudo Wire", Internet Draft, draft- ietf-pwe3-segmented-pw-02.txt, March 2006 [11] Martini, L., Bocci, M., Balus, F., et al, " Dynamic Placement of Multi Segment Pseudo Wires", Internet Draft, draft-ietf- pwe3-dynamic-ms-pw-00.txt, December 2005 Dolganow et. al. Expires May 19, 2008 [Page 12] Internet-Draft OSPF Extensions for Dynamic MS-PWs November 2007 Author's Addresses Matthew Bocci Alcatel-Lucent Voyager Place, Shoppenhangers Road Maidenhead Berks, UK Email: matthew.bocci@alcatel-lucent.co.uk Dimitri Papadimitriou Alcatel-Lucent Copernicuslaan 50 2018 ANTWERP BELGIUM Email: dimitri.papadimitriou@alcatel-lucent.be Alex Zinin ALCATEL-Lucent. 701 East Middlefield Road M/S MOUNT-HRPB6 MOUNTAIN VIEW, CA 94043 USA Email: alex.zinin@alcatel-lucent.com Mustapha Aissaoui Alcatel-Lucent 600 March Road OTTAWA, ON K2K 2E6 CANADA Email: mustapha.aissaoui@alcatel-lucent.com Andrew Dolganow Alcatel-Lucent 600 March Road OTTAWA, ON K2K 2E6 CANADA Email: andrew.dolganow@alcatel-lucent.com Yuji Kamite NTT Communcations Email: y.kamite@ntt.com Luca Martini Cisco lmartini@cisco.com Frederic Jounay Dolganow et. al. Expires May 19, 2008 [Page 13] Internet-Draft OSPF Extensions for Dynamic MS-PWs November 2007 France Telecom Frederic.jounay@orange-ftgroup.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). Dolganow et. al. Expires May 19, 2008 [Page 14] Internet-Draft OSPF Extensions for Dynamic MS-PWs November 2007 This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Dolganow et. al. Expires May 19, 2008 [Page 15]