IGP Extentions for Segment Routing Service Segment
draft-lz-lsr-igp-sr-service-segments-00

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 18, 2020.

Copyright Notice

Copyright (c) 2020 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. IGP Extensions for Service Segments
• 2.1. IS-IS Extentions
• 2.2. OSPF Extentions
• 3. Security Considerations
• 4. IANA Considerations
• 5. References
• 5.1. Normative References
• 5.2. Informative References
• Authors' Addresses

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.

    
               SR-C         
                 |           
                 |            
            A----1----2----3----4----5----B
                      |         |
                      |         |
                      S1        S2 proxy----S2
					  
					

Figure 1: Network with Services

We reuse the network topology and concepts in [I-D.dawra-idr-bgp-ls-sr-service-segments] . The network is shown in figure 1.

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.

SR Controller (SR-C) is connected to node 1, but may be attached to any node 1-5 in the network.

SR-C is capable of receiving BGP-LS updates to discover topology, and calculating constrained paths between 1 and 5.

If node 1 gets the service segment information, it can use the BGP-LS extensions [I-D.ietf-spring-sr-service-programming] to advertise it to the SR-C, but how can node 1 get it is a question.but node 1 must get the service segment information from other nodes at first.

This document proposes extensions for IGP to broadcastadvertise service segment information so that there is only one SR node needed per Autonomous System to be connected with the SR-C through BGP-LS to advertise the information to it.

This extension works for both SR-MPLS and SRv6.

2. IGP Extensions for Service Segments

After an SFF like node 2 or node 4 get the service segment information, it needs to advertise the information to other SR nodes in the domain through IGP.

How can SFFs like node 2 and node 4 get the service segment information from S1 and S2 proxy will be discussed further.

There may be other alternate mechanisms and are outside of scope of this document.

2.1. IS-IS Extentions

This document intrduces new TLVs for SRv6 End SID sub-TLV [I-D.ietf-lsr-isis-srv6-extensions] and SID/Label sub-TLV [RFC8666] for SR-MPLS to associate the Service SID Value with Service-related Information.

One of the new TLVs is Service Chaining (SC) TLV, the definition and structure is the same as the SC TLV defined in [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2.

          +---------------------------------------+
          |         Type (1 octet)                |
          +---------------------------------------+
          |        Length (1 octet)               |
          +---------------------------------------+
          |        Service Type(ST) (2 octet)     |
          +---------------------------------------+
          |        Flags (1 octet)                |
          +---------------------------------------+
          |        Traffic Type(1 octet)          |
          +---------------------------------------+
          |        RESERVED (2 octet)             |
          +---------------------------------------+

Service Chaining (SC) TLV

Another Optional Opaque Metadata(OM) TLV is defined in figure 3. The definition and structure is 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)               |
           +---------------------------------------+

Opaque Metadata(OM) TLV

2.2. OSPF Extentions

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

One of the new TLVs is Service Chaining (SC) TLV, the definition and structure is the same as the SC TLV defined in [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2.

           +---------------------------------------+
           |         Type (2 octet)                |
           +---------------------------------------+
           |        Length (2 octet)               |
           +---------------------------------------+
           |        Service Type(ST) (2 octet)     |
           +---------------------------------------+
           |        Flags (1 octet)                |
           +---------------------------------------+
           |        Traffic Type(1 octet)          |
           +---------------------------------------+
           |        RESERVED (2 octet)             |
           +---------------------------------------+

Service Chaining (SC) TLV

Another Optional Opaque Metadata(OM) TLV is defined in figure 3. The definition and structure is 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)               |
           +---------------------------------------+

Opaque Metadata(OM) TLV

3. Security Considerations

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

4. IANA Considerations

TBD

5. References

5.1. Normative References

5.2. Informative References

Authors' Addresses