IDR Working Group                                                Z. Wang
Internet-Draft                                                     Q. Wu
Intended status: Standards Track                                  Huawei
Expires: April 20, May 24, 2020                                        J. Tantsura
                                                            Apstra, Inc.
                                                        October 18,
                                                           K. Talaulikar
                                                           Cisco Systems
                                                       November 21, 2019

       Distribution of MPLS-TE Extended admin Group Using BGP
                   draft-ietf-idr-eag-distribution-09 BGP-LS
                   draft-ietf-idr-eag-distribution-10

Abstract

   As MPLS-TE network grows, administrative Groups

   Administrative groups (commonly referred to as "colors" or "link
   colors") are link attributes that are advertised by link state
   protocols like IS-IS (Intermediate System to Intermediate System) and
   OSPF (Open Shortest Path First) and used for traffic engineering.
   These administrative groups have initially been defined as a
   fixed-length fixed-
   length 32-bit Bitmask is quite constraining.  "Extended
   Administrative Group" IGP TE extensions sub-TLV is introduced bitmask.  As networks grew and more use-cases were
   introduced, the 32-bit length was found to
   provide for additional be constraining and hence
   extended administrative groups (link colors) beyond were introduced in the
   current limit of 32. link state
   protocols.  The 32-bit administrative groups are already advertised
   as link attributes in BGP-LS.  This document describes introduces extensions to BGP
   protocol, that can be used to distribute
   BGP-LS (Border Gateway Protocol Link-State) for advertisement of the
   extended administrative
   groups in MPLS-TE. groups.

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 https://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 April 20, May 24, 2020.

Copyright Notice

   Copyright (c) 2019 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
   (https://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
   2.
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  Carrying   3
   2.  Advertising Extended Administrative Groups in BGP  . . . BGP-LS  . . . .   3
     3.1.  AG and EAG coexistence  . . . . . . . .
   3.  IANA Considerations . . . . . . . . .   3
     3.2.  Desire for unadvertised EAG bits . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   4
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   4
   8.
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   MPLS-TE advertises 32 administrative

   Administrative groups (commonly referred to as "colors" or "link
   colors") are link attributes that are advertised by link state
   protocols like IS-IS [RFC5305], OSPFv2 [RFC3630] and OSPFv3 [RFC5329]
   for traffic engineering use-cases.  The BGP-LS advertisement is
   encoded using the Administrative Group sub-TLV of
   the Link (color) TLV 1088 as defined in OSPFv2 (RFC3630), OSPFv3 (RFC5329) and ISIS
   (RFC5305).

   As MPLS-TE network grows,
   [RFC7752].

   These administrative Groups advertised groups are defined as a fixed-length 32-bit Bitmask is quite constraining.  "Extended
   Administrative Group" IGP TE extensions sub-TLV defined in [RFC7308]
   is introduced
   bitmask.  As networks grew and more use-cases were introduced, the
   32-bit length was found to provide for additional be constraining and hence extended
   administrative groups (link
   colors) beyond (EAG) were introduced in the current limit of 32.

   TThis IS-IS and OSPFv2
   link state routing protocols [RFC7308].

   This document defines a new TLV specifies extensions to be carried within BGP-LS
   attribute (defined in [I.D-ietf- idr-ls-distribution]) to distribute for advertisement of the
   extended administrative groups in MPLS-TE.

2. groups.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Carrying

2.  Advertising Extended Administrative Groups in BGP BGP-LS

   This document proposes one new BGP link attribute TLVs defines extensions that can be
   announced as attribute in the enable BGP-LS attribute (defined speakers to
   signal the EAG of links in [I.D-ietf-
   idr-ls-distribution]) a network to distribute extended administrative groups. a BGP-LS consumer of network
   topology such as a centralized controller.  The extensions in centralized
   controller can leverage this document build on the ones provided information in BGP-LS
   [RFC7752] traffic engineering
   computations and BGP-4 [RFC4271]. other use-cases.  When a BGP-LS attribute defined in [RFC7752] has nested TLVs which allow speaker is
   originating the
   BGP-LS attribute to be readily extended.  Link attribute TLVs defined
   in section 3.2.2 topology learnt via link-state routing protocols like
   OSPF or IS-IS, the EAG information of [I-D.ietf-idr-ls-distribution]are TLVs that may
   be encoded in the BGP-LS attribute with a link NLRI.  Each 'Link
   Attribute' links is a Type/Length/ Value (TLV) triplet formatted sourced from the
   underlying extensions as defined in Section 3.1 of [I-D.ietf-idr-ls-distribution].

   This document proposes one new TLV as a link attribute:

         Type            Value

         TBD1        Extended Administrative Group (EAG) [RFC7308].  The BGP-LS speaker
   may also advertise the EAG TLV is used in addition to information for the Administrative Groups when local links of a node wants to advertise more than 32 colors for a link.  The EAG TLV
   is optional.  The format and semantics of
   when not running any link-state IGP protocol e.g. when running BGP as
   the 'value' fields in only routing protocol.

   EAG
   TLVs correspond to the format and semantics of value fields in IGP
   extension sub-TLVs, defined a link is encoded in [RFC7308].

   +------------+---------------------+--------------+-----------------+
   | a new Link Attribute TLV Code  |     Description     |     IS-IS    |   Defined in:   |
   |    Point   |                     |  TLV/Sub-TLV [RFC7752] using
   the following format:

      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            |    TBD1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Extended      |     22/14    |    [RFC7308]    |
   |            |Admininstrative Group|              |                 |
   +------------+---------------------+--------------+-----------------+

                     Table Administrative Groups (variable)                 //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 1: 'EAG' Link Attribute TLV

3.1.  AG and EAG coexistence

   Similar to section 2.3.1 of [RFC7308],if a BGP speaker advertises
   both AG and EAG then AG and EAG should be dealt with in the same way
   as AG and EAG carried in the Extended Administrative Group (EAG) sub- Groups TLV [RFC7308] for both OSPF [RFC3630] and ISIS [RFC5305].

3.2.  Desire for unadvertised EAG bits

   Unlike AGs, EAGs are advertised as any non-zero-length-bit Bitmask. Format

   Where:

   o  Type: 1173

   o  Length: variable (MUST be multiple of 4); represents the EAG total
      length may be longer for some links than for others.  Similar
   to section 2.3.2 of [RFC7308], if a BGP peer wants to only use links
   where the specific bits value field in octets.

   o  Value : one or more sets of an EAG is set to 1 but 32-bit bitmasks that indicate the
      administrative groups (colors) that are enable on the link when
      those specific bits
   of this are set.

   The EAG TLV is not advertised, then the implementation SHOULD process
   these desire an optional TLV.  The existing AG TLV 108 and unadvertised the EAG bits
   TLV introduced in accordance this document MAY be advertised together.  The
   semantics of the EAG and the backward compatibility aspects of EAG
   with rule
   defined respect to the AG are handled as described in the Backward
   Compatibility section 2.3.2 of [RFC7308].

4.  Security Considerations

   This document does not introduce security issues beyond those
   discussed in [RFC7752] and [RFC4271].

5.

3.  IANA Considerations

   This document requests assigning code-points code-point from the registry "BGP-
   LS "BGP-LS
   Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
   TLVs" based on table below.  Early allocation for the new Link Attribute TLVs defined these code-points
   have been done by IANA.

    +------------+-------------------------------+-------------------+
    | Code Point |   Description                 | IS-IS TLV/Sub-TLV |
    +------------+-------------------------------+-------------------+
    |   1173     | Extended Administrative Group |      22/14        |
    +------------+-------------------------------+-------------------+

4.  Security Considerations

   The extensions in the table above:

6.  Contributors

   Ketan Talaulikar
   Cisco Systems Inc.
   Email: ketant@cisco.com

7. this document advertise same administrative group
   information specified via [RFC7752] but as a larger/extended value
   and hence does not introduce security issues beyond those discussed
   in [RFC7752].

5.  Acknowledgments

   The authors gratefully acknowledge the review made by Eric Osborne.

8. Osborne and Les
   Ginsberg.

6.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997. 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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

   [RFC4271]  Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)",
              RFC 4271, January 2006. 2003,
              <https://www.rfc-editor.org/info/rfc3630>.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008.
              2008, <https://www.rfc-editor.org/info/rfc5305>.

   [RFC5329]  Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
              "Traffic Engineering Extensions to OSPF Version 3",
              RFC 5329, DOI 10.17487/RFC5329, September 2008,
              <https://www.rfc-editor.org/info/rfc5329>.

   [RFC7308]  Osborne, E., "Extended Administrative Groups in MPLS-TE",
              ID RFC7308, MPLS
              Traffic Engineering (MPLS-TE)", RFC 7308,
              DOI 10.17487/RFC7308, July 2014. 2014,
              <https://www.rfc-editor.org/info/rfc7308>.

   [RFC7752]  Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
              S. Ray, "North-Bound Distribution of Link-State and
              TE
              Traffic Engineering (TE) Information using Using BGP", RFC 7752,
              DOI 10.17487/RFC7752, March 2016. 2016,
              <https://www.rfc-editor.org/info/rfc7752>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Zitao Wang
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: wangzitao@huawei.com

   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: bill.wu@huawei.com

   Jeff Tantsura
   Apstra, Inc.

   Email: jefftant.ietf@gmail.com
   Ketan Talaulikar
   Cisco Systems

   Email: ketant@cisco.com