Network Working Group                                        M. Bocci
Internet Draft                                               A. Zinin
                                                          M. Aissaoui
                                                      D. Papadimitriou
                                                            A. Dolganow
                                                              Alcatel

                                                          Yuji Kamite
                                                    NTT Communications

Expires: June 2007                                    December 7, 2006



           OSPF Extensions for Dynamic Multi-segment Pseudo Wires
                 draft-dolganow-pwe3-ospf-ms-pw-ext-00.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.

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

   This document may only be posted in an Internet-Draft.

   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 June 7, 2007.

Abstract



Dolganow et. al.        Expires June 7, 2007                  [Page 1]


Internet-Draft   OSPF Extensions for Dynamic MS-PWs      December 2006


   Multi-segment pseudo wires 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 adjacencies. MS-PWs can be used to scale PW based networks
   over both a single AS, or between multiple ASs. However, there is a
   particular need to be able to automatically route MS-PWs through
   access and metro PSNs. These networks typically comprise a single AS.

   This draft proposes extensions to OSPF to enable the automatic
   advertisement of summarized PW FECs, thus enabling the automatic
   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...............................................34
      1.1. Terminology...........................................45
      1.2. Architecture..........................................45
   2. Applicability..............................................57
   3. OSPF Extensions............................................67
      3.1. Attachment Circuit Addressing..........................67
      3.2. S-PE Addressing........................................68
      3.3. OSPFv2 LSAs...........................................68
         3.3.1. Pseudo Wire Switching LSA.........................68
      3.4. OSPFv3 LSAs...........................................89
         3.4.1. Pseudo Wire Switching LSA.........................89
      3.5. LSA Information Field.................................810
         3.5.1. AII TLV.........................................911
         3.5.2. PW Adjacency TLV.................................911
   4. Procedures for Advertising PW Signaling Adjacencies........1011
   5. LSA Processing Procedures.................................1012
      5.1. P Routers...........................................1112
      5.2. PE Routers..........................................1112
   Deployment Considerations....................................1113
      6.1. Impact on Existing P-Routers.........................1113
      6.2. Congestion in the Underlying PSN Routing.............1213
   7. Security Considerations...................................1214
   8. IANA Considerations......................................1214


Dolganow et. al.        Expires June 7, 2007                  [Page 2]


Internet-Draft   OSPF Extensions for Dynamic MS-PWs      December 2006


   9. Acknowledgments..........................................1214
   10. References..............................................1315
      10.1. Normative References................................1315
      10.2. Informative References..............................1315
   Author's Addresses..........................................1416
   Intellectual Property Statement..............................1516
   Disclaimer of Validity......................................1516
   Copyright Statement.........................................1517
   Acknowledgment..............................................1517

1. Introduction

   Multi-segment pseudo wires 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, or between 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. However, although MP-BGP may be used within
   a single AS, 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.

   A second important case is where MS-PWs are deployed in service
   provider access and metro networks. Pseudo wires in these networks
   typically span only a single IGP domain or AS. Furthermore, the nodes
   contain a minimal routing implementation to cut operational
   complexity. MP-BGP is not typically deployed on MTUs and full MP-BGP
   functionality may not be required. However, there is also a
   particular need to be able to automatically route MS-PWs through
   these topologies.

   These two cases demonstrate the need for a MS-PW routing protocol
   for:

      -  MP-BGP incapable domains.

      -  Domains where only an incremental increase in routing
        functionality is required over the simple statically placed MS-
        PWs.



Dolganow et. al.        Expires June 7, 2007                  [Page 3]


Internet-Draft   OSPF Extensions for Dynamic MS-PWs      December 2006


   In these cases, it is possible to leverage the mechanisms of the PSN
   IGP to distribute MS-PW routing 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 routing of MS-PWs across an OSPF domain.
   This information is then used by T-PEs and S-PEs to derive the MS-PW
   routing tables. These are used 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





     +----+                                                  +----+
     |TPE1+--------------------------------------------------+TPE2|
     +----+                                                  +----+

     |<---------------------------PW----------------------------->|

     +----+              +---+           +---+               +----+
     |TPE1+--------------+SPE+-----------+SPE+---------------+TPE2|
     +----+              +---+           +---+               +----+

      <---------------------- Single AS -------------------------->


                      Figure 1 MS-PW Routing Model

   Figure 1Figure 1 illustrates the MS-PW routing model. ACs attached to
   TPE2 are associated with the OSPF Router_ID or any locally assigned
   routable address.

   The proposed model assumes the existence of a signaling adjacency
   between T-PE/S-PE, S-PE/S-PE and/or S-PE/T-PE. An example of a
   signaling adjacency is a Targeted LDP session used by MS-PW signaling
   [11]. A pair of routable IP addresses represents this signaling
   adjacency. Each S-PE / T-PE is also assigned its own layer 2 address
   in the form of an AII as described in [11]


Dolganow et. al.        Expires June 7, 2007                  [Page 4]


Internet-Draft   OSPF Extensions for Dynamic MS-PWs      December 2006


   When such an adjacency is to be used for the establishment of
   intermediate PW segments, both ends can advertise the set of AIIs
   reachable across this set of intermediate PW segments. This is done
   using summarized Type 2 AIIs so that a separate advertisement is not
   required to every AC reachable via that adjacency. AIIs may be
   summarized using the aggregation rules for AII Type 2 described in
   [6]. The corresponding advertisement is modeled a set of PE nodes,
   interconnected with signaling adjacencies, and a set of AII's
   associated with each node.

   The resulting topology is a connected graph that identifies each S-PE
   by an AII (which includes its IP address), an optional set of PW
   links between PEs, and each T-PE by one or more AIIs containing an IP
   address for the T-PE and a set of AC identifiers. Based on that
   topology, each PE builds a routing information containing all
   routable AIIs. When creating MS-PW, the PE looks up the AII and
   determines the next hop PE for LDP signalling as described in [11].

   Figure 1Figure 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 1Figure 1. Selection of an S-PE
   from a set of multiple available S-PEs is left for further revisions
   of this draft.

2. Applicability

   The proposed OSPF protocol extensions are intended for domains where
   MP-BGP is not used. 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 does not preclude cases 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. 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 an exterior gateway protocol.






Dolganow et. al.        Expires June 7, 2007                  [Page 5]


Internet-Draft   OSPF Extensions for Dynamic MS-PWs      December 2006


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                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         AC ID                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1 Attachment Circuit Addressing

   Implementations of this procedure MUST interpret the AII as described
   in [11].

3.2. S-PE Addressing

   The T-PE may select a known specific path along a set of S-PEs for a
   specific PW. This requires that each S-PE be uniquely addressable in
   terms of pseudo wires. For this purpose at least one AII address of
   the format similar to AII type 2 composed of the Global ID, and
   Prefix part only MUST be assigned to each S-PE.

   The prefix must be derived from the S-PE address associated to the
   locally assigned routable address.

3.3. 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, and PSN tunnels between peer S-PEs or T-PEs.

3.3.1. Pseudo Wire Switching LSA

   OSPFv2 routers behaving as S-PEs or T-PEs MAY optionally advertise
   the layer 2 addresses reachable through them. This advertisement MUST
   be in an AS-scoped opaque LSA.


Dolganow et. al.        Expires June 7, 2007                  [Page 6]


Internet-Draft   OSPF Extensions for Dynamic MS-PWs      December 2006


   The format of the OSPFv2 opaque LSA 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            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).

   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.5. below.






Dolganow et. al.        Expires June 7, 2007                  [Page 7]


Internet-Draft   OSPF Extensions for Dynamic MS-PWs      December 2006


3.4. OSPFv3 LSAs

3.4.1. Pseudo Wire 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.5. below.



3.5. 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 June 7, 2007                  [Page 8]


Internet-Draft   OSPF Extensions for Dynamic MS-PWs      December 2006


    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.

   This document defines two additional TLVs: :

   Type TBD: AII

   Type TBD: PW Adjacency

3.5.1. AII TLV

   If the LSA information is of type AII, then the value field contains
   one or more AII Type 2 TLVs, as described above.

3.5.2. PW Adjacency TLV

   The PW Adjacency TLV is used to describe the presence of a PW
   signaling adjacency between two S-PEs or T-PEs. The PW Adjacency TLV
   contains the following sub TLVs:

   o Advertising PE Layer 2 Address:
      This is the AII Type 2 address of the local PE

   o Remote PE Layer 2 Address:
      This is the AII Type 2 address of the remote PE at the far end of
      the PW signaling session

   Extensions to the PW Adjacency TLV to support the advertisement of
   traffic engineering information and other metrics are for further
   study.



Dolganow et. al.        Expires June 7, 2007                  [Page 9]


Internet-Draft   OSPF Extensions for Dynamic MS-PWs      December 2006


4. Procedures for Advertising PW Signaling Adjacencies

   The signaling adjacencies that exist between S-PEs and T-PEs must be
   advertised. However, the PWE3 topology over which PWs can be signaled
   is a superset of the MS-PW topology, and it is assumed that the PWE3
   topology coincides with the topology of PWE3 control protocol (i.e.
   PW signaling) adjacencies. That is, not all PEs can be S-PEs, and not
   all S-PEs can be assumed to be capable of dynamic PW routing. In
   order to use a given signaling session to a peer S-PE/T-PE to signal
   dynamically placed MS-PWs, S-PEs/T-PEs need to know which of the PW
   adjacency TLVs received represent switching capable PEs along a path
   to reach advertised AIIs.

   The following procedure is used to establish this association.

   T-PEs/S-PEs that are switching capable announce this using the PW
   adjacency TLV in the PW switching LSA. The PW adjacency TLV contains
   all of the configured adjacencies currently operationally up. A T-
   PE/S-PE must associate the originator of that LSA with the endpoint
   of one of its own signaling sessions (either directly or through
   another PW adjacency TLV in case of multi-hop switching) In a single
   hop case, this may be achieved automatically by matching router IP
   addresses in the LSA with signaling endpoints, or by configuration.



5. LSA Processing Procedures

   Nodes capable of pseudowire switching on either side of a signaling
   session exchange PW switching LSAs with the AII and PW adjacency TLV.
   Note that the PW adjacency TLV will only contain those adjacencies
   that are currently configured and operationally up (i.e. targeted LDP
   session is operationally UP ). These PW switching LSAs are processed
   and flooded as described in Section 5.2. The signaling adjacency is
   maintained using a signaling protocol specific mechanism e.g. LDP
   hellos. Changes in the state of the adjacency should be advertised
   using the updated PW adjacency TLV within the PW switching LSA. A
   router should use a mechanism to reduce the number of advertisements
   in case of bouncing signalling adjacency. Such a mechanism is out of
   scope for this specification.

   The application database includes thus a set of signaling sessions
   (PW signaling adjacencies) that may be used for signaling dynamically
   placed MS-PWs. AII TLV associates end-point information to the PW
   adjacency (that are providing access to these end-points). AII TLVs
   are flooded in the PW switching opaque LSA.



Dolganow et. al.        Expires June 7, 2007                 [Page 10]


Internet-Draft   OSPF Extensions for Dynamic MS-PWs      December 2006




5.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.

5.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 link
   state database. The link state database, which represents a connected
   graph of S-PEs and T-PEs (as described above) 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].

   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.



6. 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.

6.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


Dolganow et. al.        Expires June 7, 2007                 [Page 11]


Internet-Draft   OSPF Extensions for Dynamic MS-PWs      December 2006


   aggregation of AIIs. Section 6.2.  below describes other methods for
   limiting the impact of any additional flooding.



6.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].



7. Security Considerations

   This section will be added in a future version.

8. 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

9. Acknowledgments

   The authors gratefully acknowledge the contributions of Vach
   Kompella, Devendra Raut and Yuichi Ikejiri.




Dolganow et. al.        Expires June 7, 2007                 [Page 12]


Internet-Draft   OSPF Extensions for Dynamic MS-PWs      December 2006


10. References

10.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

10.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 June 7, 2007                 [Page 13]


Internet-Draft   OSPF Extensions for Dynamic MS-PWs      December 2006


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






Dolganow et. al.        Expires June 7, 2007                 [Page 14]


Internet-Draft   OSPF Extensions for Dynamic MS-PWs      December 2006


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 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 Internet Society (2006).

   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.

Acknowledgment






Dolganow et. al.        Expires June 7, 2007                 [Page 15]