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

Versions: 00 01 02 03 04 05 06 07 08

SPRING Working Group                                      Madhukar Anand
Internet-Draft                                            Sanjoy Bardhan
Intended Status: Informational                       Ramesh Subrahmaniam
                                                    Infinera Corporation
Expires: September 21, 2016                               March 20, 2016


             Packet-Optical Integration in Segment Routing
                      draft-anand-spring-poi-sr-00


Abstract

   This document illustrates a way to integrate a new class of nodes and
   links in segment routing to represent networks in an opaque way for
   further extensibility of the link-state protocols that help with
   segment routing.  An instance of the opaque definition would be
   optical networks that are typically transport centric.  In the IP
   centric network, this will help in defining a common control protocol
   for packet optical integration that will include optical paths as
   opaque 'segments' or sub-paths as an augmentation to the defined
   extensions of segment routing. This opaque option defines a general
   mechanism to allow for future extensibility of segment routing.


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 to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html



Anand et al.,          Expires September 21, 2016               [Page 1]


Internet-Draft        draft-anand-spring-poi-sr-00        March 20, 2016


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2016 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.  Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . .  3
   3. Use case - Packet Optical Integration . . . . . . . . . . . . .  3
   4.  Mechanism overview . . . . . . . . . . . . . . . . . . . . . .  5
   5.  IS-IS extensions for supporting the opaque adjacency segment .  6
   6.  OSPF extensions for supporting the opaque adjacency segment  .  8
   7.  OSPFv3 extensions for supporting the opaque adjacency
       segment  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  BGP-LS extensions for supporting the opaque adjacency
       segment  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1 Link Attribute TLVs  . . . . . . . . . . . . . . . . . . . . 11
     8.2 Opaque Adjacency SID TLV . . . . . . . . . . . . . . . . . . 12
   9.  PCEP-LS extensions for supporting the opaque adjacency
       segment  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   10. Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   11.  Security Considerations . . . . . . . . . . . . . . . . . . . 14
   12  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   13  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     13.1  Normative References . . . . . . . . . . . . . . . . . . . 14
     13.2  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15









Anand et al.,          Expires September 21, 2016               [Page 2]


Internet-Draft        draft-anand-spring-poi-sr-00        March 20, 2016


1  Introduction

   Packet and optical transport networks have evolved independently with
   different control plane mechanisms that have to be provisioned and
   maintained separately. Consequently, coordinating packet and optical
   networks for delivering services such as end-to-end traffic
   engineering or failure response has proved challenging. To address
   this challenge, a unified control and management paradigm that
   provides an incremental path to complete packet-optical integration
   while leveraging existing signaling and routing protocols in either
   domains is needed. This document introduces such a paradigm based on
   Segment Routing (SR) [I-D.ietf-spring-segment-routing].

   This document introduces a new type of segment, Opaque Adjacency
   Segment. Opaque Adjacency Segment can be used to model abstracted
   paths through the optical transport domain and integrate it with the
   packet network for delivering end-to-end services. In addition, this
   also introduces a notion of a Packet optical gateway (POG). These are
   nodes in the network that map packet services to the optical domain
   that originate and terminate these opaque adjacency segments. Given
   an opaque adjacency, a POG will expand it to a path in the optical
   transport network.



2.  Reference Taxonomy

   POG - Packet optical gateway Device

   SR Edge Router - The Edge Router which is the first SR capable device

   CE - Customer Edge Device that is outside of the SR domain

   PCE - Path Computation Engine

   Controller - A network controller



3. Use case - Packet Optical Integration

   Many operators build and operate their networks that are both multi-
   layer and multi-domain. Services are built around these layers and
   domains to provide end-to-end services.  Due to the nature of the
   different domains, such as packet and optical,  the management and
   service creation has always been problematic and time consuming. With
   segment routing, enabling a head-end node to select a path and embed
   the information in the packet is a powerful construct that would be



Anand et al.,          Expires September 21, 2016               [Page 3]


Internet-Draft        draft-anand-spring-poi-sr-00        March 20, 2016


   used in the Packet Optical Gateways (POG). The path is usually
   constructed for each domain that may be manually derived or through a
   stateful PCE which is run specifically in that domain.

   P1---------O1---------P2---------O2---------P3---------O3---------P4

         Figure 1:  Representation of a packet-optical path

   In Figure 1 above, the nodes represent a packet optical network.  P1,
   P2, P3 and P4 are packet optical devices that are connected via
   optical paths O1, O2 and O3. Nodes P1 and P4 are edge devices that
   have customer facing devices (denoted as Border POGs) and P2 and P3
   are core nodes (denoted as Transit POGs) in the network. A packet
   service is established by specifying a path between P1 and P4. Note
   that in defining this path, we will need to specify both the nodes
   and the links that make up this service.  POGs advertise themselves
   along with their adjacencies and the domains they belong to. To
   leverage segment routing to define the above service, the ingress
   node P1 would append all outgoing packets in a SR header consisting
   of the SIDs that constitute the path. In the packet domain this would
   mean P1 would send its packets towards P4 using the segment list {P2,
   P4}. The operator would need to use a different mechanism in the
   optical domain to set up the optical paths denoted by O1, O2 and O3.
   Each POG would announce the active optical path as  an opaque
   adjacency - for example, in the case of P1, the optical path O1 would
   represent an optical path that includes the optical nodes Om and On
   as shown on Figure 2. This path is not known to the packet SR domain
   and is only relevant to the optical domain D between P1 and P2.   A
   PCE that is run in Domain D would be responsible for calculating path
   O1.

             |-----Om--------On-----|

       P1----|         (D)          |------P2

             |-----Ox---------Oy----|

   Figure 2: POG with multiple optical paths through an optical domain

   Similarly, the transit POGs P2 and P3 in Figure 1 would announce
   opaque adjacencies O2 and O3.  The border POG would include the
   optical paths O1, O2 and O3 to the segment list for P1 to P4. The
   expanded segment list would read as {O1, P2, O2, P3, O3, P4}.

   There are potentially two locations for Borders POGs - one that has
   last-mile access nodes and the other being Data Center Interconnect
   nodes.  The POGs that are in the core of the network which connect
   with long haul optical networks are usually Transit POGs.



Anand et al.,          Expires September 21, 2016               [Page 4]


Internet-Draft        draft-anand-spring-poi-sr-00        March 20, 2016


                       +------------------------+
                       |                        |
   +--------------+----'    PCE or Controller   |----+---------------+
   |              |    |                        |    |               |
   |              |    +------------------------+    |               |
   |              |                                  |               |
   |              |            .-----.               |               |
   |              |           (       )              |               |
+-------+     +-------+   .--(         )--.     +-------+      +-------+
|  SR   |     |Packet |  (                 )    |Packet |      |  SR   |
| Edge  |     |Optical|-( Optical Transport )_  |Optical|      | Edge  |
|Router | ... |Gateway| (       Domain      )   |Gateway| ...  |Router |
+---+.--+     +-------+  (                 )    +-------+      +---+.--+
    |                      '--(         )--'                       |
  ,--+.                        (       )                         ,-+-.
 ( CE  )                        '-----'                         ( CE  )
  `---'                                                          `---'





        Figure 3. Reference Topology for Opaque Adjacency Segment






4.  Mechanism overview

      The current proposal assumes that the SR domains run standard IGP
   protocols to discover the topology and distribute labels without any
   modification. There are also no modifications to the control plane
   mechanisms in the Optical transport domains. The mechanism for
   supporting the opaque adjacency segment is as follows.

      1. Firstly, the Packet Optical Gateway (POG) devices announce
   themselves in the SR domain. This is indicated by advertising a new
   SR node capability flag. The exact extensions to support this
   capability are described in the subsequent sections of this
   document.

      2. Then, the POG devices announce paths to other POGs through the
   optical transport domain as an opaque adjacency segment (opaque
   adjacency SID) in the SR domain.  The paths are announced with an
   appropriate transit domain type, optical transport domain ID, and a
   label to be used to bind to the opaque adjacency segment. The



Anand et al.,          Expires September 21, 2016               [Page 5]


Internet-Draft        draft-anand-spring-poi-sr-00        March 20, 2016


   appropriate IGP segment routing extensions to carry this information
   is described in the subsequent sections of this document.

      3. The opaque adjacency segment can also optionally be announced
   with a set of attributes that characterizes the path in the optical
   transport domain between the two POG devices. For instance, those
   attributes could define the OTN mapping used (e.g., ODU4,
   ODU3,ODU3e1....ODU1), timeslots (1-8 or 4,6,7 or 1-2,5), or optical
   path protection schemes.

      4. The POG device is also responsible for programming its
   forwarding table to map every opaque adjacency label entry into an
   appropriate forwarding action relevant in the optical domain, such as
   mapping it to a label-switched path.

      5. The opaque adjacency segment is communicated to the PCE or
   Controller using extensions to BGP-LS or PCEP-LS as described in
   subsequent sections of this document.

      6. Finally, the PCE or Controller then uses the opaque adjacency
   segment label to influence the path leaving the SR domain into the
   optical domain, thereby defining the end-to-end path for a given
   service.





5.  IS-IS extensions for supporting the opaque adjacency segment

   A new IS-IS sub-TLV is defined: the Opaque Adjacency Segment
   Identifier sub-TLV (Opaque-Adj-SID sub-TLV).  The Opaque-Adj-SID sub-
   TLV is an optional sub-TLV carrying the opaque adjacency SID with
   flags and fields that may be used, in future extensions of Segment
   Routing, for carrying other types of Opaque Adjacency SIDs.

      Multiple Opaque-Adj-SID sub-TLVs MAY be associated with a pair of
   POG devices to represent multiple paths within the optical domain
   with perhaps different characteristics.












Anand et al.,          Expires September 21, 2016               [Page 6]


Internet-Draft        draft-anand-spring-poi-sr-00        March 20, 2016


   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    |     Flags     |     Weight    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Domain ID            |Opaque Sub Type| Reserved      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Remote POG System ID                  |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Packet-Optical Label                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:
 Type: TBD, suggested value 33

 Length: variable.

 Flags: 1 octet field of following flags:
   V - Value flag.  If set, then the packet-optical label carries
        a value. By default the flag is SET.
   L - Local. Local Flag.  If set, then the value/index carried by
       the Adj-SID has local significance.  By default the flag is SET.

   0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |V|L|
   +-+-+-+-+-+-+-+-+

 Other bits: Reserved.  These MUST be zero when sent and are ignored
            when received.

 Weight:  TBD

 Domain ID: An identifier for the transport domain

 Opaque Sub Type: TBD

 Remote POG System-ID: 6 octets of IS-IS System-ID of length
                      "ID Length" as defined in [ISO10589].

 Packet-Optical Label : according to the V and L flags, it contains
        either:

      *  A 3 octet local label where the 20 rightmost bits are
        used for encoding the label value.  In this case the V and
        L flags MUST be set.




Anand et al.,          Expires September 21, 2016               [Page 7]


Internet-Draft        draft-anand-spring-poi-sr-00        March 20, 2016


      *  A 4 octet index defining the offset in the label space
        advertised by this router. In this case V and L flags MUST
        be unset.


Further, to communicate the Packet-Optical Gateway capability of the
 device, we introduce a new flag O in the SR Node Capabilities sub-TLV:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |I|V|H|O|       |
   +-+-+-+-+-+-+-+-+

I, V, H flags are defined in [I-D.ietf-isis-segment-routing-extensions].
O-Flag: If set, then the router is capable of performing Packet Optical
        Gateway function.


6.  OSPF extensions for supporting the opaque adjacency segment

A new OSPF sub-TLV is defined: the Opaque Adjacency Segment Identifier
sub-TLV (Opaque-Adj-SID sub-TLV).  The Opaque-Adj-SID sub-TLV is an
optional sub-TLV of the Extended Link TLV carrying the opaque adjacency
SID with flags and fields that may be used, in future extensions of
Segment Routing, for carrying other types of Opaque Adjacency SIDs.

Multiple Opaque-Adj-SID sub-TLVs MAY be associated with a pair of
POG devices to represent multiple paths within the optical domain
with perhaps different characteristics.




    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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |    Reserved   |     MT-ID     |    Weight     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Domain ID            |Opaque Sub Type| Reserved      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Remote POG Router-ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Packet-Optical Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Anand et al.,          Expires September 21, 2016               [Page 8]


Internet-Draft        draft-anand-spring-poi-sr-00        March 20, 2016


   where:

 Type: TBD, suggested value 3

 Length: variable.

 Flags: 1 octet field of following flags:
   V - Value flag.  If set, then the optical label carries a value.
       By default the flag is SET.
   L - Local. Local Flag.  If set, then the value/index carried by
       the Adj-SID has local significance.  By default the flag is SET.

   0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |V|L|
   +-+-+-+-+-+-+-+-+

 Other bits: Reserved.  These MUST be zero when sent and are ignored
            when received.

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

 Weight:  TBD

 Domain ID: An identifier for the transport domain

 Opaque Sub Type: TBD

 Remote POG Router-ID: 4 octets of OSPF Router-ID

 Packet-Optical Label : according to the V and L flags, it contains
        either:

      *  A 3 octet local label where the 20 rightmost bits are
        used for encoding the label value.  In this case the V and
        L flags MUST be set.

      *  A 4 octet index defining the offset in the label space
        advertised by this router. In this case V and L flags MUST
        be unset.

Further, to communicate the Packet-Optical Gateway capability of the
device, we introduce an new optical informational capability bit in the
Router Information capabilities TLV (as defined in [RFC4970]).

 Bit-24 - Optical - If set, then the router is capable of performing
        Packet Optical Gateway function.




Anand et al.,          Expires September 21, 2016               [Page 9]


Internet-Draft        draft-anand-spring-poi-sr-00        March 20, 2016


7.  OSPFv3 extensions for supporting the opaque adjacency segment

   The Opaque-Adj-SID Sub-TLV is an optional Sub-TLV of the
Router-Link TLV as defined in [I-D.ietf-ospf-ospfv3-lsa-extend].
It MAY appear multiple times in Router-Link TLV.

Multiple Opaque-Adj-SID sub-TLVs MAY be associated with a pair of
POG devices to represent multiple paths within the optical domain
with perhaps different characteristics.

The Opaque-Adj-SID Sub-TLV has 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           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Flags         |     Weight    |             Reserved          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Domain ID            |Opaque Sub Type| Reserved      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Remote POG Router-ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Packet-Optical Label                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

 Type: TBD, suggested value 6

 Length: variable.

 Flags: 1 octet field of following flags:
   V - Value flag.  If set, then the optical label carries a value.
       By default the flag is SET.
   L - Local. Local Flag.  If set, then the value/index carried by
       the Adj-SID has local significance.  By default the flag is SET.

   0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |V|L|
   +-+-+-+-+-+-+-+-+

 Other bits: Reserved.  These MUST be zero when sent and are ignored
            when received.

 Weight:  TBD



Anand et al.,          Expires September 21, 2016              [Page 10]


Internet-Draft        draft-anand-spring-poi-sr-00        March 20, 2016


 Domain ID: An identifier for the transport domain

 Opaque Sub Type: TBD

 Remote POG Router-ID: 4 octets of OSPFv3 Router-ID

 Packet-Optical Label : according to the V and L flags, it contains
        either:

      *  A 3 octet local label where the 20 rightmost bits are
        used for encoding the label value.  In this case the V and
        L flags MUST be set.

      *  A 4 octet index defining the offset in the label space
        advertised by this router. In this case V and L flags MUST
        be unset.


Further, to communicate the Packet-Optical Gateway capability of the
device, we introduce an new optical informational capability bit in the
Router Information capabilities TLV (as defined in [RFC4970]).

 Bit-24 - Optical - If set, then the router is capable of performing
        Packet Optical Gateway function.


8.  BGP-LS extensions for supporting the opaque adjacency segment

8.1 Link Attribute TLVs
  The following new Link Attribute TLVs are defined:

   +-----------+----------------------------+----------+---------------+
   |  TLV Code | Description                |   Length |       Section |
   |   Point   |                            |          |               |
   +-----------+----------------------------+----------+---------------+
   |    1101   | Opaque Adjacency Segment   | variable |               |
   |           | Identifier (Opq-Adj-SID)TLV|          |               |
   +-----------+----------------------------+----------+---------------+

                       Table 1: BGP-LS Link Attribute TLVs

  These TLVs can ONLY be added to the Link Attribute associated with
the link whose local node originates the corresponding SR TLV.

  The Opaque adjacency segment TLV allows a node to advertise an opaque
adjacency within a single IGP domain.





Anand et al.,          Expires September 21, 2016              [Page 11]


Internet-Draft        draft-anand-spring-poi-sr-00        March 20, 2016


8.2 Opaque Adjacency SID TLV
  The Opaque Adjacency SID (Opq-Adj-SID) TLV has 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           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Flags         |     Weight    |             Reserved          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Domain ID            |Opaque Sub Type| Reserved      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Remote POG System ID/Router-ID                   |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Packet-Optical Label                   |
   +---------------------------------------------------------------+

Where:

 Type: TBD, suggested value 1101.

 Length: Variable.

 Flags: 1 octet field of following flags as defined in the previous
        sections for IS-IS and OSPF.

 Weight: TBD.

 Domain ID: An identifier for the optical transport domain

 Opaque Sub Type : TBD

 Remote POG Router-ID/System-ID: 4 octets of OSPF Router-ID or 6 Octets
                                of IS-IS System ID.

 Packet-Optical Label: 4 octet field carrying the label as defined
        in the previous sections for IS-IS and OSPF.





9.  PCEP-LS extensions for supporting the opaque adjacency segment

Changes similar to BGP-LS are needed for supporting the opaque
adjacency segment in PCEP-LS. Details TBD.



Anand et al.,          Expires September 21, 2016              [Page 12]


Internet-Draft        draft-anand-spring-poi-sr-00        March 20, 2016


10. Summary

The motivation for introducing an opaque adjacency segment that is
separate from an IGP adjacency segment is to distinguish between a
real IGP adjacency (which is typically a symmetric relationship
between the devices that share a route flooding domain), and a
relationship between devices in potentially two different domains such
as packet and optical domains with no real IGP adjacency. Further,
the opaque adjacency segment can carry optional information that is
of significance only in the optical domain, and hence, opaque, to
the IGPs. This is specifically useful if the optical domain is
bridging the same IGP domain, then, the POG can attach both the
adjacency SID and the opaque adjacency SID to influence the
end-to-end path in the packet and optical domains respectively.





































Anand et al.,          Expires September 21, 2016              [Page 13]


Internet-Draft        draft-anand-spring-poi-sr-00        March 20, 2016


11.  Security Considerations

   This document does not introduce any new security considerations.


12  IANA Considerations

TBD.


13  References

13.1  Normative References



[I-D.ietf-spring-segment-routing]
        Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
        and r. rjs@rob.sh, "Segment Routing Architecture", draft-
        ietf-spring-segment-routing-04 (work in progress), July
        2015.

[I-D.ietf-isis-segment-routing-extensions]
        Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
        Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
        Extensions for Segment Routing", draft-ietf-isis-segment-
        routing-extensions-05 (work in progress), June 2015.

[I-D.ietf-ospf-segment-routing-extensions]
        Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
        Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
        Extensions for Segment Routing", draft-ietf-ospf-segment-
        routing-extensions-05 (work in progress), June 2015.


[RFC4915] L. Nguyen, P. Psenak, S. Mirtorabi, P. Pillay-Esnault, and
         A. Roy, "Multi-Topology (MT) Routing in OSPF.", RFC4915,
         <http://tools.ietf.org/html/rfc4915>.

[I-D.ietf-ospf-ospfv3-segment-routing-extensions]
        Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
        Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
        Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
        segment-routing-extensions-03 (work in progress), June
        2015.

[I-D.ietf-idr-ls-distribution]
        Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.



Anand et al.,          Expires September 21, 2016              [Page 14]


Internet-Draft        draft-anand-spring-poi-sr-00        March 20, 2016


        Ray, "North-Bound Distribution of Link-State and TE
        Information using BGP", draft-ietf-idr-ls-distribution-13
        (work in progress), October 2015.

 [RFC4970]  Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
           S. Shaffer, "Extensions to OSPF for Advertising Optional
           Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July
           2007, <http://www.rfc-editor.org/info/rfc4970>.





13.2  Informative References

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


Authors' Addresses


   Madhukar Anand
   Infinera Corporation
   169 W Java Dr, Sunnyvale, CA 94089

   Email: manand@infinera.com



   Sanjoy Bardhan
   Infinera Corporation
   169 W Java Dr, Sunnyvale, CA 94089

   Email: sbardhan@infinera.com



   Ramesh Subrahmaniam
   Infinera Corporation
   169 W Java Dr, Sunnyvale, CA 94089

   Email: RSubrahmaniam@@infinera.com






Anand et al.,          Expires September 21, 2016              [Page 15]


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