[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                              X. Xu
Internet-Draft                                                   M. Chen
Intended status: Standards Track                                  Huawei
Expires: July 25, 2014                                  January 21, 2014


              Advertising Global Labels or SIDs Using OSPF
                 draft-xu-ospf-global-label-sid-adv-00

Abstract

   Segment Routing (SR) is a new MPLS paradigm in which each SR-capable
   router is required to advertise global MPLS labels or Segment IDs
   (SID) for its attached prefixes by using link-state IGPs, e.g., OSPF.
   One major challenge associated with such global MPLS label or SID
   advertisement mechanism is how to avoid a given global MPLS label or
   SID from being allocated by different routers to different prefixes.
   Although such global label or SID allocation collision problem can be
   addressed through manual allocation , it is error-prone and
   nonautomatic therefore may not be suitable in large-scale SR network
   environments.  This document proposes an alternative approach for
   allocating and advertising global MPLS labels or SIDs via OSPF so as
   to eliminate the potential risk of label allocation collision.

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

   This Internet-Draft will expire on July 25, 2014.

Copyright Notice

   Copyright (c) 2014 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



Xu & Chen                 Expires July 25, 2014                 [Page 1]


Internet-Draft                                              January 2014


   (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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Advertising Label Bindings for Prefixes . . . . . . . . . . .   3
   4.  Advertising SID Bindings for Prefixes . . . . . . . . . . . .   4
   5.  Requesting Label Bindings for Prefixes  . . . . . . . . . . .   5
   6.  Requesting SID Bindings for Prefixes  . . . . . . . . . . . .   5
   7.  Advertising Mapping Server Capability . . . . . . . . . . . .   5
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   6
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     11.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Segment Routing (SR) [I-D.filsfils-rtgwg-segment-routing] is a new
   MPLS paradigm in which each SR-capable router is required to
   advertise global MPLS labels or Segment IDs (SID) for its attached
   prefixes by using link-state IGPs, e.g.,
   OSPF[I-D.psenak-ospf-segment-routing-extensions] . One major
   challenge associated with such global MPLS label or SID advertisement
   mechanism is how to avoid a given global MPLS label or SID from being
   allocated by different routers to different prefixes.  Although such
   global label or SID allocation collision problem can be addressed
   through manual allocation, it is error-prone and nonautomatic
   therefore may not be suitable in large-scale SR network environments.

   This document proposes an alternative approach for allocating and
   advertising global MPLS labels or SIDs via OSPF so as to eliminate
   the potential risk of label allocation collision.  The basic idea of
   this approach is to allow a particular IGP router to allocate global
   MPLS labels or SIDs for those prefixes attached to each SR-capable
   router and meanwhile advertise the corresponding label or SID
   bindings in the IGP domain scope.  That particular IGP rouer is
   therefore refered to as a mapping server.  As for how the mapping



Xu & Chen                 Expires July 25, 2014                 [Page 2]


Internet-Draft                                              January 2014


   server know which prefixes need to be allocated with global labels or
   SIDs, it can be achieved either by configuration on the mapping
   server or by advertisement from SR-capable routers.  In the multi-
   area scenario where route summarization between areas is enabled, the
   IP longest-match algorithm SHOULD be used by SR-capable routers when
   processing label or SID bindings advertised by the mapping server,
   just as the mechanism defined in [RFC5283].

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

2.  Terminology

   This memo makes use of the terms defined in
   [I-D.filsfils-rtgwg-segment-routing] and [RFC4970].

3.  Advertising Label Bindings for Prefixes

   A new Opaque LSA [RFC5250] of type 11 (with domain-wide flooding
   scope), referred to as Prefix Opaque LSA, is defined.  The opaque
   type of this Prefix Opaque LSA is TBD.  A mapping server could use
   one or more Prefix Opaque LSAs to advertise label bindings for those
   prefixes which need to be allocated with global labels.  One or more
   Prefix TLV (type code=TBD) as shown below could be contained in a
   Prefix Opaque LSA.

     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=TBD            |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    MT-ID      |  Prefix-Len   |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    IPv4 Prefix (0-4 octets)                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    //                      Sub-TLVs (Variable)                     //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type: TBD.

      Length: Variable.

      MT-ID: Multi-Topology ID as defined in [RFC4915].

      Prefix-Len: the length of the prefix in bits (i.e., 0-32).



Xu & Chen                 Expires July 25, 2014                 [Page 3]


Internet-Draft                                              January 2014


      IPv4 Prefix: the prefix is encoded in the minimal number of octets
      (i.e., 0-4) for the given number of significant bits.

   A Label Binding Sub-TLV (type code=TBD) as shown below is associated
   with a prefix which is contained in the Prefix TLV.

      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=TBD            |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |P|      Reserved       |          MPLS Label (20 bit)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type: TBD.

      Length: 4.

      P-Flag: if set, the penultimate hop router MUST perform PHP action
      on the allocated MPLS label.  For a given prefix, the P-Flag in
      the Label Binding Sub-TLV MUST be set to the same value as that of
      the P-Flag in the Label Request Sub-TLV if a label request message
      (see section 5 of this document) for that prefix is received by
      the mapping server.

      MPLS Label: a global label which is allocated to the prefix which
      is contained in the Prefix TLV.

4.  Advertising SID Bindings for Prefixes

   A mapping server could use one or more Prefix Opaque LSAs as defined
   in Section 3 to advertise SID bindings for those prefixes which need
   to be allocated with global SIDs.  One or more Prefix TLV as defined
   in Section 3 could be contained in a Prefix Opaque LSA.

   A SID Binding Sub-TLV (type code=TBD) as shown below is associated
   with a prefix which is contained in the Prefix TLV.

      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=TBD            |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              SID                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type: TBD.




Xu & Chen                 Expires July 25, 2014                 [Page 4]


Internet-Draft                                              January 2014


      Length: 4.

      SID: a SID for the prefix which is carried in the TLV containing
      this sub-TLV.

5.  Requesting Label Bindings for Prefixes

   SR-capable OSPF routers could use one or more Prefix Opaque LSAs as
   defined in section 3 of this document to advertise those among their
   attached prefixes which need to be allocated with global labels.  A
   new Sub-TLV of the Prefix TLV, referred to as Label Request Sub-TLV
   (type code=TBD) as shown below is associated with a prefix which is
   contained in a Prefix TLV.

      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=TBD            |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |P|                         Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type: TBD.

      Length: 4.

      P-Flag: if set, the penultimate hop router MUST perform PHP action
      on the required label.

6.  Requesting SID Bindings for Prefixes

   SR-capable OSPF routers could use one or more Prefix Opaque LSAs as
   defined in section 3 of this document to advertise those among their
   attached prefixes which need to be allocated with global SIDs.  A new
   Sub-TLV of the Prefix TLV, referred to as SID Request Sub-TLV (type
   code=TBD and Length=0) is associated with a prefix which is contained
   in a Prefix TLV.

7.  Advertising Mapping Server Capability

   For redundancy purpose, more than one router could be configured as
   candidates for mapping servers.  Each candidate for mapping servers
   SHOULD advertise its capability of being a mapping servers by using
   OSPF Router Capability TLV.  The one with the highest priority SHOULD
   be elected as the primary mapping server which is eligible to
   allocate and advertise global labels or SIDs for prefixes on behalf
   of SR-capable routers.  The comparison of OSPF router ID breaks the
   tie between two or more candidates with the same highest priority.



Xu & Chen                 Expires July 25, 2014                 [Page 5]


Internet-Draft                                              January 2014


   Meanwhile, the one with the second highest priority SHOULD be elected
   as a backup mapping server.  This backup mapping server SHOULD
   advertise the same label bindings as those advertised by the primary
   mapping server.  In this way, the unnecessary changes to the data
   plane (i.e., MPLS forwarding table) of SR-capable routers can be
   avoided in the event of mapping server failover.

   Each candidate mapping server SHOULD advertise its capability of
   being mapping servers by using an OSPF Router Informational
   Capabilities TLV [RFC4970] contained in an Opaque LSA of type 11
   (with domain-wide flooding scope).  One of the unreserved OSPF Router
   Informational Capabilities Bits is reserved for this purpose.
   Furthermore, a sub-TLV (type code=TBD) as shown below is used to
   convey the priority value for mapping server election.

     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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Priority    |
     +-+-+-+-+-+-+-+-+

      Type: TBD.

      Length: 1

      Priority: the priority for mapping server election.

8.  Acknowledgements

   The authors would like to thank .

9.  IANA Considerations

   TBD.

10.  Security Considerations

   This document does not introduce any new security considerations.

11.  References

11.1.  Normative References







Xu & Chen                 Expires July 25, 2014                 [Page 6]


Internet-Draft                                              January 2014


   [I-D.psenak-ospf-segment-routing-extensions]
              Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
              Shakir, R., and W. Henderickx, "OSPF Extensions for
              Segment Routing", draft-psenak-ospf-segment-routing-
              extensions-03 (work in progress), October 2013.

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

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC
              4915, June 2007.

   [RFC4970]  Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
              Shaffer, "Extensions to OSPF for Advertising Optional
              Router Capabilities", RFC 4970, July 2007.

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

   [RFC5283]  Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
              for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
              July 2008.

11.2.  Informative References

   [I-D.filsfils-rtgwg-segment-routing]
              Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
              Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
              Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
              "Segment Routing Architecture", draft-filsfils-rtgwg-
              segment-routing-01 (work in progress), October 2013.

Authors' Addresses

   Xiaohu Xu
   Huawei

   Email: xuxiaohu@huawei.com


   Mach Chen
   Huawei

   Email: mach.chen@huawei.com




Xu & Chen                 Expires July 25, 2014                 [Page 7]


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