[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03

Open Shortest Path First IGP                             H. Gredler, Ed.
Internet-Draft                                    Juniper Networks, Inc.
Intended status: Standards Track                               S. Amante
Expires: October 12, 2013                   Level 3 Communications, Inc.
                                                               T. Scholl
                                                                  Amazon
                                                                L. Jalil
                                                                 Verizon
                                                          April 12, 2013

                    Advertising MPLS labels in OSPF
               draft-gredler-ospf-label-advertisement-00

Abstract

   Historically MPLS label distribution was driven by protocols like
   LDP, RSVP and LBGP. All of those protocols are session oriented.  In
   order to obtain label binding for a given destination FEC from a
   given router one needs first to establish an LDP/RSVP/LBGP session
   with that router.

   Advertising MPLS labels in IGPs advertisement [I-D.gredler-rtgwg-igp-
   label-advertisement] describes several use cases where utilizing the
   flooding machinery of link-state protocols for MPLS label
   distribution allows to obtain the binding without requiring to
   establish an LDP/RSVP/LBGP session with that router.

   This document describes the protocol extension to distribute MPLS
   labels by the OSPFv2 and OSPFv3 protocol.

Requirements Language

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

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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



Gredler, Amante, Scholl Expires October 12, 2013                [Page 1]


Internet-Draft      Advertising MPLS labels in OSPF           April 2013

   This Internet-Draft will expire on October 12, 2013.

Copyright Notice

   Copyright (c) 2013 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
   2.  Motivation, Rationale and Applicability  . . . . . . . . . . .  3
     2.1.  Issue: Bi-directionality semantics . . . . . . . . . . . .  3
     2.2.  Issue: IP path semantics . . . . . . . . . . . . . . . . .  4
     2.3.  Issue: Lack of 'path' notion . . . . . . . . . . . . . . .  4
     2.4.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  OSPF MPLS LSA Format . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Common LSA Type  . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  OSPFv2 LSA ID  . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  OSPFv2 LSA Format Overview . . . . . . . . . . . . . . . .  5
     3.4.  OSPFv3 LSA ID  . . . . . . . . . . . . . . . . . . . . . .  6
     3.5.  OSPFv3 LSA Format Overview . . . . . . . . . . . . . . . .  6
     3.6.  TLV Header . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  LSA payload details  . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Prefix ERO TLVs  . . . . . . . . . . . . . . . . . . . . .  7
       4.1.1.  IPv4 Prefix ERO TLV  . . . . . . . . . . . . . . . . .  8
       4.1.2.  IPv6 Prefix ERO TLV  . . . . . . . . . . . . . . . . .  8
     4.2.  Flags TLV  . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Advertising Label Examples . . . . . . . . . . . . . . . . . .  9
     5.1.  Sample Topology  . . . . . . . . . . . . . . . . . . . . .  9
       5.1.1.  Transport IP addresses and router-IDs  . . . . . . . . 10
       5.1.2.  Link IP addresses  . . . . . . . . . . . . . . . . . . 10
     5.2.  One-hop LSP to an adjacent Router  . . . . . . . . . . . . 11
     5.3.  One-hop LSP to an adjacent Router using a specific link  . 11
     5.4.  One-hop LSP to an adjacent external Router . . . . . . . . 11
     5.5.  Advertisement of an RSVP LSP . . . . . . . . . . . . . . . 11
     5.6.  Advertisement of an LDP LSP  . . . . . . . . . . . . . . . 11
     5.7.  Interarea advertisement of diverse paths . . . . . . . . . 12
   6.  Inter Area Protocol Procedures . . . . . . . . . . . . . . . . 13
     6.1.  Applicability  . . . . . . . . . . . . . . . . . . . . . . 13
     6.2.  Data plane operations  . . . . . . . . . . . . . . . . . . 13
     6.3.  Control plane operations . . . . . . . . . . . . . . . . . 13
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Gredler, Amante, Scholl Expires October 12, 2013                [Page 2]


Internet-Draft      Advertising MPLS labels in OSPF           April 2013

     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 14
     10.2.  Informative References  . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

1.  Introduction

   MPLS label allocations are predominantly distributed by using the LDP
   [RFC5036], RSVP [RFC5151] or labeled BGP [RFC3107] protocol.  All of
   those protocols have in common that they are session oriented, which
   means that in order to obtain label binding for a given destination
   FEC from a given router one needs first to establish a direct control
   plane (LDP/RSVP/LBGP) session with that router.

   There are a couple of use cases [I-D.gredler-rtgwg-igp-label-
   advertisement] where the consumer of a MPLS label binding may not be
   adjacent to the router that performs the binding.  Bringing up an
   explicit session using the existing label distribution protocols
   between the non-adjacent router that bind the label and the router
   that acts as a consumer of this binding is the existing remedy for
   this dilemma.

   This document describes a OSPFv2 and OSPFv3 protocol extension which
   allows routers to advertise MPLS label bindings within and beyond an
   IGP domain, and controlling inter-area distribution.

2.  Motivation, Rationale and Applicability

   Distributing MPLS labels in an IGP (IS-IS) has been described in
   Segment Routing [I-D.previdi-filsfils-isis-segment-routing].  The
   authors propose to re-use existing traffic-engineering extensions for
   carrying the label information.  While retrofitting existing protocol
   machinery for new purposes is generally a good thing, Segment Routing
   [I-D.previdi-filsfils-isis-segment-routing] falls short of addressing
   some use-cases defined in [I-D.gredler-rtgwg-igp-label-
   advertisement].

   The dominant issue around re-using traffic-engineering extensions is
   that both have existing protocol semantics, which might not be
   applicable to advertising MPLS label switched paths in a generic
   fashion.  These are specifically:

   o  Bi-directionality semantics

   o  IP path semantics

   o  Lack of 'path' notion

2.1.  Issue: Bi-directionality semantics









Gredler, Amante, Scholl Expires October 12, 2013                [Page 3]


Internet-Draft      Advertising MPLS labels in OSPF           April 2013


   'Bi-directionality semantics', affects the complexity around
   advertisement of unidirectional LSPs.  Label advertisement of per-
   link labels or 'Adj-SIDs' [I-D.previdi-filsfils-isis-segment-routing]
   is done by attaching label information to adjacency advertisment
   TLVs.  Usually implementations need to have an adjacency in 'Up'
   state prior to advertising this adjacency as TE-Link in its Link
   State advertisment.  In order to advertise a per-link LSP an
   implementation first needs to have an adjacency, which only
   transitions to 'Up' state after passing the 3-way check.  This
   implies bi-directionality.  If an implementation wants to advertise
   per-link MPLS LSPs to e.g.  outside the IGP domain then it would need
   to fake-up an adjacency.  Changing existing IGP Adjacency code to
   support such cases defeats the purpose of re-using existing
   functionality as there is not much common functionality to be shared.

2.2.  Issue: IP path semantics

   LSPs pointing to a Node are advertised as 'Node-SIDs' [I-D.previdi-
   filsfils-isis-segment-routing] using IP Prefix containers.  That
   means that in order to advertise a MPLS LSP, one is inheriting the
   semantics of advertising an IP path.  Consider router A has got
   existing LSPs to its entire one-hop neighborhood and is re-
   advertising those LSPs using IP reachability semantics.  Now we have
   two exact matching IP advertisements.  One from the owning router
   (router B) which advertises its stable transport loopback address and
   another one from router A re-advertising a LSP path to router B.
   Existing routing software may get confused now as the 'stable
   transport' address shows up from multiple places in the network and
   more worse the IP forwarding path for control-plane protocols may get
   mingled with the MPLS data plane.

2.3.  Issue: Lack of 'path' notion

   Both exisiting traffic-engineering extension containers have limited
   semantics describing MPLS label-switched paths in the sense of a
   'path'.  Both encoding formats allow to express a pointer to some
   specific router, but not to describe a MPLS label switched path
   containing all of its path segments.  [I-D.previdi-filsfils-isis-
   segment-routing] allows to define 'Forwarding Adjacencies' as per
   [RFC4206].  The way to describe a path of a given forwarding
   adjacency is to enlist a list of "Segment IDs".  That implies that
   nodes which do not yet participate in 'Segment routing' or are
   outside of a 'Segment routing' domain can not be expressed using
   those path semantics.

   A protocol for advertising MPLS label switched paths, should be
   generic enough to express paths sourced by existing MPLS LSPs, such
   that ingress routers can flexibly combine them according to
   application needs.

2.4.  Motivation



Gredler, Amante, Scholl Expires October 12, 2013                [Page 4]


Internet-Draft      Advertising MPLS labels in OSPF           April 2013


   IGP advertisement of MPLS label switched paths requires a new set of
   protocol semantics (undirectional paradigm, path paradigm), which
   hardly can be expressed using the existing OSPF and OSPF-TE protocol
   semantics.  This document describes protocol extensions which allows
   generic advertisement of MPLS label switched paths in OSPF.

3.  OSPF MPLS LSA Format

3.1.  Common LSA Type

   One new LSA is defined, the MPLS Label LSA. This LSA advertises MPLS
   labels along with their path information.  The LSA contains more
   specific information encoded in TLVs.  Those TLV extensions are
   shared between the OSPFv2 and OPSFv3 protocols.

3.2.  OSPFv2 LSA ID

   The LSA ID of an Opaque LSA is defined as having eight bits of type
   data and 24 bits of type-specific data.  The MPLS Label LSA uses type
   149. The remaining 24 bits are 4 zero bits followed by the MPLS Label
   value 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      149      |0|0|0|0|              MPLS Label               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The 'MPLS Label' field holds the 20 Bit MPLS label.  Therefore a
   maximum of 2^20 MPLS Label LSAs may be sourced by a single system.

3.3.  OSPFv2 LSA Format Overview

   This extension makes use of the Opaque LSAs [RFC5250].

   Three types of Opaque LSAs exist, each of which has a different
   flooding scope.  This proposal uses only Type 10 LSAs, which have an
   area flooding scope.

   The MPLS Label LSA for OSPFv2 starts with the standard OSPFv2 LSA
   header:













Gredler, Amante, Scholl Expires October 12, 2013                [Page 5]


Internet-Draft      Advertising MPLS labels in OSPF           April 2013


   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   |       10      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      149      |0|0|0|0|            MPLS Label                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                            TLVs                             -+
   |                             ...                               |

3.4.  OSPFv3 LSA ID

   The OSPFv3 LSA ID of an MPLS Label LSA is defined as having twelve
   bits of zero followed by the 20-Bit label MPLS Label value 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0|0|0|0|0|0|0|              MPLS Label               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The 'MPLS Label' field holds the 20 Bit MPLS label.  Therefore a
   maximum of 2^20 MPLS Label LSAs may be sourced by a single system.

3.5.  OSPFv3 LSA Format Overview

   The MPLS Label LSA for OSPFv3 starts with the standard OSPFv3 LSA
   header:

   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|0|1|          149            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0|0|0|0|0|0|0|               MPLS Label              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Advertising Router                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       LS sequence number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                            TLVs                             -+


Gredler, Amante, Scholl Expires October 12, 2013                [Page 6]


Internet-Draft      Advertising MPLS labels in OSPF           April 2013

   |                             ...                               |

   The OSPFv3 'U' Bit will always be set such that routers which do not
   understand the new MPLS Label LSA will store and forward it further.

   In analogy to the OSPFv2 opaque LSA 10 the flooding scope will be set
   to 'Area scoping'.

3.6.  TLV Header

   The LSA payload consists of one or more nested Type/Length/Value
   (TLV) triplets for extensibility.  The format of each TLV is:

   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 Length field defines the length of the value portion in octets
   (thus a TLV with no value portion would have a length of zero).  The
   TLV is padded to four-octet alignment; padding is not included in the
   length field (so a three octet value would have a length of three,
   but the total size of the TLV would be eight octets). Nested TLVs are
   also 32-bit aligned.  Unrecognized types are ignored.

   This memo defines Types 1, 2 and 3. See the IANA Considerations
   section for allocation of new Types.

4.  LSA payload details

   The MPLS Label LSA may be originated by any Traffic Engineering
   [RFC3630] capable router in an OSPF domain.  A router may advertise
   MPLS labels along with so called 'ERO' path segments describing the
   label switched path.  This gets encoded in subsequent TLVs.  Since
   ERO style path notation allows to express pointers to link and node
   IP addresses.  Now any label switched path, sourced by any protocol,
   can be described.

   An LSA contains one or more TLVs, describing properties of the
   advertised MPLS label.

   The following TLV extensions may be shared in both OSPV2 and OSPFv3.
   Passing an IP address of the other address family (IPv4 in OPSFv3 or
   IPv6 in OSPFv2) is possible as the information carried are related
   describing the hops along a path.  The receiver of this information
   is a protocol agnostic path computation module.

4.1.  Prefix ERO TLVs

Gredler, Amante, Scholl Expires October 12, 2013                [Page 7]


Internet-Draft      Advertising MPLS labels in OSPF           April 2013


   All 'Prefix ERO' information represents an ordered set which
   describes the segments of a label-switched path.  The last Prefix ERO
   TLV describes the segment closest to the egress point of the LSP.
   Contrary the first Prefix ERO TLV describes the first segment of a
   label switched path.  If a router extends or stitches a label
   switched path it MUST prepend the new segments path information to
   the Prefix ERO list.

4.1.1.  IPv4 Prefix ERO TLV

   The IPv4 ERO TLV (Type 1) describes a path segment using IPv4 Prefix
   style of encoding.  Its appearance and semantics have been borrowed
   from Section 4.3.3.2 [RFC3209].

   the 'IPv4 Address' is treated as a prefix based on the prefix length
   value below.  Bits beyond the prefix are ignored on receipt and
   SHOULD be set to zero on transmission.

   The 'Prefix Length' field contains the length of the prefix in bits.

   The 'L' bit in the TLV is a one-bit attribute.  If the L bit is set,
   then the value of the attribute is 'loose.'  Otherwise, the value of
   the attribute is 'strict.'

   The 'Reserved' bits are for future use.  They should be zero on
   transmission and ignored on receipt.

   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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     IPv4 Address (4 octets)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Length |L|                   Reserved                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.2.  IPv6 Prefix ERO TLV

   The IPv6 ERO TLV (Type 2) describes a path segment using IPv6 Prefix
   style of encoding.  Its appearance and semantics have been borrowed
   from Section 4.3.3.2 [RFC3209].

   the 'IPv6 Address' is treated as a prefix based on the prefix length
   value below.  Bits beyond the prefix are ignored on receipt and
   SHOULD be set to zero on transmission.

   The 'Prefix Length' field contains the length of the prefix in bits.

   The 'L' bit in the TLV is a one-bit attribute.  If the L bit is set,
   then the value of the attribute is 'loose.'  Otherwise, the value of
   the attribute is 'strict.'


Gredler, Amante, Scholl Expires October 12, 2013                [Page 8]


Internet-Draft      Advertising MPLS labels in OSPF           April 2013


   The 'Reserved' bits are for future use.  They should be zero on
   transmission and ignored on receipt.

   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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 Address (16 octets)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 Address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 Address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 Address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Length |L|                   Reserved                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2.  Flags TLV

   The Flags TLV (Type 3) describes Flags for further MPLS LSA
   treatment.

   Up/Down 'U' Bit: A router may flood MPLS label information across
   area boundaries.  In order to prevent flooding loops, a router will
   Set the Up/Down (U-Bit) when propagating MPLS labels from Area 0 to a
   non-zero Area.

   The 'Reserved' bits are for future use.  They should be zero on
   transmission and ignored on receipt.

   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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|                         Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.  Advertising Label Examples

5.1.  Sample Topology

   The following topology (Figure 9) and IP addresses shall be used
   throughout the Label advertisement examples.








Gredler, Amante, Scholl Expires October 12, 2013                [Page 9]


Internet-Draft      Advertising MPLS labels in OSPF           April 2013



                       AS1                         :    AS 2
                                                   :
                        :                          :
            Level 1     :     Level 2              :
                        :                          :
   +-----+           +-----+-IP3--IP4--+-----+     :
   | R1  +-IP1--IP2--+ R2  |           | R3  |     :
   +--+--+           +--+--+-IP5--IP6--+--+--+-IP15-IP16-
      |                 |                 |        :     \
     IP3               IP7               IP13      :   +--+--+
      |                 |                 |        :   |  R7 |
     IP4               IP8               IP14      :   +--+--+
      |                 |                 |        :     /
   +--+--+           +--+--+           +--+--+-IP17-IP18-
   |  R4 +-IP19-IP20-+ R5  |-IP11-IP12-| R6  |     :
   +-----+           +-----+           +-----+     :
                        :                          :
                        :                          :
                        :                          :

5.1.1.  Transport IP addresses and router-IDs

   o  R1: 192.168.1.1

   o  R2: 192.168.1.2

   o  R3: 192.168.1.3

   o  R4: 192.168.1.4

   o  R5: 192.168.1.5

   o  R6: 192.168.1.6

   o  R7: 192.168.1.7

5.1.2.  Link IP addresses

   o  R1 to R2 link: 10.0.0.1, 10.0.0.2

   o  R1 to R4 link: 10.0.0.3, 10.0.0.4

   o  R2 to R3 link #1: 10.0.0.3, 10.0.0.4

   o  R2 to R3 link #2: 10.0.0.5, 10.0.0.6

   o  R2 to R5 link: 10.0.0.7, 10.0.0.8

   o  R3 to R6 link: 10.0.0.13, 10.0.0.14

   o  R3 to R7 link: 10.0.0.15, 10.0.0.16


Gredler, Amante, Scholl Expires October 12, 2013               [Page 10]


Internet-Draft      Advertising MPLS labels in OSPF           April 2013


   o  R4 to R5 link: 10.0.0.19, 10.0.0.20

   o  R5 to R6 link: 10.0.0.11, 10.0.0.12

   o  R6 to R7 link: 10.0.0.17, 10.0.0.18

5.2.  One-hop LSP to an adjacent Router

   If R1 would advertise a label <N> bound to a one-hop LSP from R1 to
   R2 it would encode as follows:

      LSA 149, LSA-ID <N>:

         IPv4 Prefix ERO TLV: 192.168.1.2/32, Strict

5.3.  One-hop LSP to an adjacent Router using a specific link

   If R2 would advertise a label <N>bound to a one-hop LSP from R2 to
   R3, using the link #2 it would encode as follows

      LSA 149, LSA-ID <N>:

         IPv4 Prefix ERO TLV: 10.0.0.6/32, Strict

5.4.  One-hop LSP to an adjacent external Router

   If R3 would advertise a label <N> bound to a one-hop LSP from R3 to
   R7 (which is outside of the IGP domain), it would encode as follows:

      LSA 149, LSA-ID <N>:

         IPv4 Prefix ERO TLV: 192.168.1.7/32, Strict

   As you can see the representation of an MPLS label crossing an
   external link is identical as an internal link Section 5.2.

5.5.  Advertisement of an RSVP LSP

   Consider a RSVP LSP name "R2-to-R6" traversing (R2 to R3 using link
   #1, R6):

   If R2 would advertise a label <N> bound to the RSVP LSP named
   'R2-to-R6', it would encode as follows

      LSA 149, LSA-ID <N>:

         IPv4 Prefix ERO TLV: 10.0.0.4/32, Strict

         IPv4 Prefix ERO TLV: 192.168.1.6/32, Strict

5.6.  Advertisement of an LDP LSP



Gredler, Amante, Scholl Expires October 12, 2013               [Page 11]


Internet-Draft      Advertising MPLS labels in OSPF           April 2013


   Consider R2 that creates a LDP label binding for FEC 172.16.0.0./12
   using label <N>.

   If R2 would re-advertise this binding in IS-IS it would encode as
   follows

      LSA 149, LSA-ID <N>:

         IPv4 Prefix ERO TLV: 172.16.0.0/12, Loose

5.7.  Interarea advertisement of diverse paths

   Consider two R2->R6 paths: {R2, R3, R6} and {R2, R5, R6}

   Consider two R5->R3 paths: {R5, R2, R3} and {R5, R6, R3}

   R2 encodes its two paths to R6 as follows:

      LSA 149, LSA-ID <N1>:

         IPv4 Prefix ERO TLV: 192.168.1.3, Loose

         IPv4 Prefix ERO TLV: 192.168.1.6, Loose

         Flags TLV: Down

      LSA 149, LSA-ID <N2>:

         IPv4 Prefix ERO subTLV: 192.168.1.5, Loose

         IPv4 Prefix ERO subTLV: 192.168.1.6, Loose

         Flags TLV: Down

   R5 encodes its two paths to R3 as follows:

      LSA 149, LSA-ID <N1>:

         IPv4 Prefix ERO subTLV: 192.168.1.2, Loose

         IPv4 Prefix ERO subTLV: 192.168.1.3, Loose

         Flags TLV: Down

      LSA 149, LSA-ID <N2>:

         IPv4 Prefix ERO subTLV: 192.168.1.6, Loose

         IPv4 Prefix ERO subTLV: 192.168.1.3, Loose

         Flags TLV: Down



Gredler, Amante, Scholl Expires October 12, 2013               [Page 12]


Internet-Draft      Advertising MPLS labels in OSPF           April 2013


   A receiving non-backbone router does see now all 4 paths and may
   decide to load-balance across all or a subset of them.

6.  Inter Area Protocol Procedures

6.1.  Applicability

   Propagation of a MPLS LSP across an area boundary is a local policy
   decision.

6.2.  Data plane operations

   If local policy dictates that a given ABR router needs to re-
   advertise a MPLS LSPs from one area to another then it MUST allocate
   a new label and program its label forwarding table to connect the new
   label to the path in the respective other area.  Depending on how to
   reach the re-advertised LSP, this is typically done using a MPLS
   'SWAP' or 'SWAP/PUSH' data plane operation.

6.3.  Control plane operations

   If local policy dictates that a given ABR router needs to re-
   advertise a MPLS LSPs from one area to another then it must prepend
   its "Traffic-Engineering-ID" as a loose hop in the Prefix ERO TLV
   list.  Furthermore it MUST append teh Flags TLV and set the 'Down'
   Bit.

7.  Acknowledgements

   Many thanks to Yakov Rekhter for his useful comments.

8.  IANA Considerations

   This documents request allocation for one common OSPFv2 and OSPFv3
   LSA Type and TLVs contained within.

   +------------+-----------------+----------+----------+------------+
   | LSA        | TLV             | LSA Type | TLV Type | #Occurence |
   +------------+-----------------+----------+----------+------------+
   | MPLS Label |                 | 149      |          |        >=0 |
   |            | IPv4 Prefix ERO |          | 1        |        >=0 |
   |            | IPv6 Prefix ERO |          | 2        |        >=0 |
   |            | Flags           |          | 3        |        0,1 |
   +------------+-----------------+----------+----------+------------+

   The MPLS Label LSA requires a new sub-registry, with a starting TLV
   value of 1, and managed by Expert Review.

9.  Security Considerations





Gredler, Amante, Scholl Expires October 12, 2013               [Page 13]


Internet-Draft      Advertising MPLS labels in OSPF           April 2013


   This document does not introduce any change in terms of OSPF
   security.  It simply proposes to flood MPLS label information via the
   IGP.  All existing procedures to ensure message integrity do apply
   here.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in
              BGP-4", RFC 3107, May 2001.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC3630]  Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630, September
              2003.

   [RFC4206]  Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
              Hierarchy with Generalized Multi-Protocol Label Switching
              (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.

   [RFC5036]  Andersson, L., Minei, I. and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

   [RFC5151]  Farrel, A., Ayyangar, A. and JP. Vasseur, "Inter-Domain
              MPLS and GMPLS Traffic Engineering -- Resource Reservation
              Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
              5151, February 2008.

   [RFC5250]  Berger, L., Bryskin, I., Zinin, A. and R. Coltun, "The
              OSPF Opaque LSA Option", RFC 5250, July 2008.

10.2.  Informative References

   [I-D.gredler-rtgwg-igp-label-advertisement]
              Gredler, H., Amante, S., Scholl, T. and L. Jalil,
              "Advertising MPLS labels in IGPs", Internet-Draft draft-
              gredler-rtgwg-igp-label-advertisement-03, April 2013.

   [I-D.previdi-filsfils-isis-segment-routing]
              Previdi, S., Filsfils, C., Bashandy, A., Horneffer, M.,
              Decraene, B., Litkowski, S., Milojevic, I., Shakir, R.,
              Ytti, S., Henderickx, W. and J. Tantsura, "Segment Routing
              with IS-IS Routing Protocol", Internet-Draft draft-
              previdi-filsfils-isis-segment-routing-02, March 2013.

Authors' Addresses

Gredler, Amante, Scholl Expires October 12, 2013               [Page 14]


Internet-Draft      Advertising MPLS labels in OSPF           April 2013


   Hannes Gredler, editor
   Juniper Networks, Inc.
   1194 N. Mathilda Ave.
   Sunnyvale, CA 94089
   US

   Email: hannes@juniper.net


   Shane Amante
   Level 3 Communications, Inc.
   1025 Eldorado Blvd
   Broomfield, CO 80021
   US

   Email: shane@level3.net


   Tom Scholl
   Amazon
   Seattle, WN
   US

   Email: tscholl@amazon.com


   Luay Jalil
   Verizon
   1201 E Arapaho Rd.
   Richardson, TX 75081
   US

   Email: luay.jalil@verizon.com




















Gredler, Amante, Scholl Expires October 12, 2013               [Page 15]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/