[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

LSR Working Group                                               Yao. Liu
Internet-Draft                                              Zheng. Zhang
Intended status: Standards Track                         ZTE Corporation
Expires: July 25, 2021                                     Yongqing. Zhu
                                                           China Telecom
                                                        January 21, 2021


           IGP Extensions for Segment Routing Service Segment
                draft-lz-lsr-igp-sr-service-segments-04

Abstract

   This document defines extensions to the link-state routing protocols
   (IS-IS and OSPF) in order to carry service segment information via
   IGP.

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 July 25, 2021.

Copyright Notice

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



Liu, et al.               Expires July 25, 2021                 [Page 1]


Internet-Draft           IGP for Service Segment            January 2021


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.2.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  IGP Extensions for Service Segments . . . . . . . . . . . . .   4
     3.1.  IS-IS Extensions  . . . . . . . . . . . . . . . . . . . .   4
     3.2.  OSPFv2 and OSPFv3 Extensions  . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Segments are introduced in the SR architecture [RFC8402].  Segment
   Routing (SR) allows for a flexible definition of end-to-end paths by
   encoding paths as sequences of topological sub-paths, called
   "segments".

   Service Function Chaining (SFC) [RFC7665] provides support for the
   creation of composite services that consist of an ordered set of
   Service Functions (SF) that are to be applied to packets and/or
   frames selected as a result of classification.

   [I-D.ietf-spring-sr-service-programming] describes how a service can
   be associated with a SID and how to achieve service funtion chaining
   in SR-enabled MPLS and IPv6 networks.  It also defines SR-aware and
   SR-unaware services.  For a SR-unaware service ,there has to be a SR
   proxy handling the SR processing on behalf of the service .

   [I-D.dawra-idr-bgp-ls-sr-service-segments] propose extensions to BGP-
   LS for Service Chaining to distribute the service segment information
   to SR Controller.

   The reference network topology is shown in figure 1.












Liu, et al.               Expires July 25, 2021                 [Page 2]


Internet-Draft           IGP for Service Segment            January 2021


                            SR-C


               A----1----2----3----4----5----B
                         |         |
                         |         |
                         S1        S2



                      Figure 1: Network with Services

   Node 1-5 are nodes capital of segment routing.  A and B are two end
   hosts.  S1 is an SR-aware Service.  S2 is an SR-unaware Service and
   node 4 act as an SR proxy.  The path from A to B needs to pass
   through service function S1 and S2.  SR Controller (SR-C) is capable
   of receiving BGP-LS updates to discover topology, and calculating
   constrained paths between 1 and 5.  To provision and maintain service
   function path, the SR-C needs to collect the SID-related service
   information as well.

   If the service segment information can only be transmitted through
   BGP-LS, the BGP protocol needs to be enabled on all the service
   function nodes or SFFs, and BGP neighbors should be established
   between these nodes and the SR-C or the node selected to have a BGP
   session with the controller.

   A common scenario is that IGP is enabled on each node in the network
   to distributed SIDs and SID-related information(e.g reachability,
   behavior, structure,etc) within the domain and a small amout of nodes
   are connected to the controller/PCE via BGP-LS to report SID-related
   information along with the topology.  This document proposes
   extensions for IGP to advertise service segment information along
   with SIDs to support such scenario.

2.  Conventions used in this document

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







Liu, et al.               Expires July 25, 2021                 [Page 3]


Internet-Draft           IGP for Service Segment            January 2021


2.2.  Acronyms

   SFC: Service Function Chain

   SFF: Service Function Forwarder

   SF: Service Function

   SFP: Service Function Path

3.  IGP Extensions for Service Segments

   If an service function node like S1 supports IGP function, it
   advertises the service information to other SR nodes through IGP
   itself.  Otherwise, SFFs like node 2 or node 4 are responsible to
   advertise the service information through IGP.  How can SFFs get the
   service segment information from SFs is outside of scope of this
   document.

3.1.  IS-IS Extensions

   This document introduces new sub-sub-TLVs for SRv6 End SID sub-TLV
   [I-D.ietf-lsr-isis-srv6-extensions] and Prefix Segment Identifier
   (Prefix-SID) Sub-TLV [RFC8667] for SR-MPLS to associate the Service
   SID Value with Service-related Information.

   One of the new TLVs is Service Chaining (SC) TLV, the TLV is defined
   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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type        |    Length     |        Service Info           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Flags       | Traffic Type  |          RESERVED             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





                    Figure 2:Service Chaining (SC) TLV

   where:

   Type: 8 bit field.  TBD



Liu, et al.               Expires July 25, 2021                 [Page 4]


Internet-Draft           IGP for Service Segment            January 2021


   Length: 8 bit field indicating the length of the remainder of the TLV

   The Flags, Traffic Type and RESERVED fields are the same as in the SC
   TLV defined in [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2.

   Flags: 8 bit field.  Bits SHOULD be 0 on transmission and MUST be
   ignored on reception.

   Traffic Type: 8 Bit field.  A bit to identify if Service is IPv4 OR
   IPv6 OR L2 Ethernet Capable.

   Bit 0(LSB): Set to 1 if Service is IPv4 Capable

   Bit 1: Set to 1 if Service is IPv6 Capable

   Bit 2: Set to 1 if Service is Ethernet Capable

   RESERVED: 16bit field.  SHOULD be 0 on transmission and MUST be
   ignored on reception.

   Service Info: 16-bits field.  The right most 12 bits categorize the
   Service Type: (such as "Firewall", "Classifier" etc).

   0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | P FLAG|    Service Type       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 3: Service Info Field

   The first 4 bits are P FLAG which is used to indicate the SR proxy
   type with the following values:

   0000:SR-aware function.

   0001:Static proxy.

   0010:Dynamic proxy.

   0011:Masquerading proxy(for SRv6 only).

   0100:Shared memory proxy.

   Other values are reserved.

   The P FLAG is mainly defined for SR-MPLS.





Liu, et al.               Expires July 25, 2021                 [Page 5]


Internet-Draft           IGP for Service Segment            January 2021


   In SRv6, although the SR proxy type can be represented by the END
   functions[I-D.ietf-spring-sr-service-programming] which can be
   advertised in Endpoint Behavior field of End SID sub-TLV
   [I-D.ietf-lsr-isis-srv6-extensions], there may be situations that the
   proxy with certain type cannot be associated with a network
   programming function(for example, Shared memory proxy),or an user
   want to define a new type of proxy for private use, or the SR proxy
   node does not support network programming, so the P flag is still
   useful.

   In the IS-IS notification message, when both SR proxy END function
   and P FLAG exist, the proxy type represented by P FLAG shall prevail.

   Another Optional Opaque Metadata(OM) TLV is defined in figure 4.  The
   definition and structure are the same as the OM TLV defined in
   [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2.

              +---------------------------------------+
              |         Type (1 octet)                |
              +---------------------------------------+
              |        Length (1 octet)               |
              +---------------------------------------+
              |        Opaque  Type (2 octet)         |
              +---------------------------------------+
              |        Flags (1 octet)                |
              +---------------------------------------+
              |        Value (variable)               |
              +---------------------------------------+

                     Figure 4:Opaque Metadata(OM) TLV

3.2.  OSPFv2 and OSPFv3 Extensions

   This document introduces new sub-sub-TLVs for SRv6 End SID sub-TLV
   [I-D.li-ospf-ospfv3-srv6-extensions] and Prefix-SID Sub-TLV [RFC8665]
   [RFC8665] for SR-MPLS to associate the Service SID Value with
   Service-related Information.

   One of the new TLVs is Service Chaining (SC) TLV,












Liu, et al.               Expires July 25, 2021                 [Page 6]


Internet-Draft           IGP for Service Segment            January 2021


       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Service Info         |     Flags     |  Traffic Type |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          RESERVED             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 5:Service Chaining (SC) TLV

   where:

   Type: 16 bit field.  TBD

   Length: 16 bit field indicating the length of the remainder of the
   TLV

   Flags, Traffic Type and RESERVED are the same as that in SC TLV
   defined in [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2.

   The definition and use principle of the Service Type field is the
   same as that defined in the IS-IS extension above.

   Another Optional Opaque Metadata(OM) TLV is defined in figure 6.  The
   definition and structure are the same as the OM TLV defined in
   [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2.

              +---------------------------------------+
              |         Type (2 octet)                |
              +---------------------------------------+
              |        Length (2 octet)               |
              +---------------------------------------+
              |        Opaque  Type (2 octet)         |
              +---------------------------------------+
              |        Flags (1 octet)                |
              +---------------------------------------+
              |        Value (variable)               |
              +---------------------------------------+

                     Figure 6:Opaque Metadata(OM) TLV

4.  Security Considerations

   Procedures and protocol extensions defined in this document do not
   affect the IS-IS and OSPF security model




Liu, et al.               Expires July 25, 2021                 [Page 7]


Internet-Draft           IGP for Service Segment            January 2021


5.  IANA Considerations

   TBD

6.  References

6.1.  Normative References

   [I-D.dawra-idr-bgp-ls-sr-service-segments]
              Dawra, G., Filsfils, C., Talaulikar, K., Clad, F.,
              daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B.,
              Elmalky, H., Xu, X., Guichard, J., and C. Li, "BGP-LS
              Advertisement of Segment Routing Service Segments", draft-
              dawra-idr-bgp-ls-sr-service-segments-04 (work in
              progress), August 2020.

   [I-D.ietf-lsr-isis-srv6-extensions]
              Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
              Z. Hu, "IS-IS Extension to Support Segment Routing over
              IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-11
              (work in progress), October 2020.

   [I-D.ietf-spring-sr-service-programming]
              Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
              d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
              Henderickx, W., and S. Salsano, "Service Programming with
              Segment Routing", draft-ietf-spring-sr-service-
              programming-03 (work in progress), September 2020.

   [I-D.li-ospf-ospfv3-srv6-extensions]
              Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak,
              "OSPFv3 Extensions for SRv6", draft-li-ospf-
              ospfv3-srv6-extensions-07 (work in progress), November
              2019.

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

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

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



Liu, et al.               Expires July 25, 2021                 [Page 8]


Internet-Draft           IGP for Service Segment            January 2021


   [RFC8665]  Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
              H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
              Extensions for Segment Routing", RFC 8665,
              DOI 10.17487/RFC8665, December 2019,
              <https://www.rfc-editor.org/info/rfc8665>.

   [RFC8666]  Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions
              for Segment Routing", RFC 8666, DOI 10.17487/RFC8666,
              December 2019, <https://www.rfc-editor.org/info/rfc8666>.

   [RFC8667]  Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
              Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
              Extensions for Segment Routing", RFC 8667,
              DOI 10.17487/RFC8667, December 2019,
              <https://www.rfc-editor.org/info/rfc8667>.

6.2.  Informative References

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

Authors' Addresses

   Liu Yao
   ZTE Corporation
   Nanjing
   China

   Email: liu.yao71@zte.com.cn


   Zhang Zheng
   ZTE Corporation
   Nanjing
   China

   Email: zzhang_ietf@hotmail.com


   Zhu Yongqing
   China Telecom
   China

   Email: zhuyq8@chinatelecom.cn





Liu, et al.               Expires July 25, 2021                 [Page 9]


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