< draft-anand-spring-poi-sr-00.txt   draft-anand-spring-poi-sr-01.txt >
SPRING Working Group Madhukar Anand SPRING Working Group Madhukar Anand
Internet-Draft Sanjoy Bardhan Internet-Draft Sanjoy Bardhan
Intended Status: Informational Ramesh Subrahmaniam Intended Status: Informational Ramesh Subrahmaniam
Infinera Corporation Infinera Corporation
Expires: September 21, 2016 March 20, 2016
Jeff Tantsura
Individual
Expires: January 7, 2017 July 6, 2016
Packet-Optical Integration in Segment Routing Packet-Optical Integration in Segment Routing
draft-anand-spring-poi-sr-00 draft-anand-spring-poi-sr-01
Abstract Abstract
This document illustrates a way to integrate a new class of nodes and 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 links in segment routing to represent transport networks in an opaque
further extensibility of the link-state protocols that help with way into the segment routing domain. An instance of this class would
segment routing. An instance of the opaque definition would be be optical networks that are typically transport centric. In the IP
optical networks that are typically transport centric. In the IP
centric network, this will help in defining a common control protocol centric network, this will help in defining a common control protocol
for packet optical integration that will include optical paths as for packet optical integration that will include optical paths as
opaque 'segments' or sub-paths as an augmentation to the defined 'transport segments' or sub-paths as an augmentation to the defined
extensions of segment routing. This opaque option defines a general extensions of segment routing. The transport segment option also
mechanism to allow for future extensibility of segment routing. defines a general mechanism to allow for future extensibility of
segment routing into non-packet domains.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
skipping to change at page 2, line 28 skipping to change at page 2, line 31
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 3 2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 3
3. Use case - Packet Optical Integration . . . . . . . . . . . . . 3 3. Use case - Packet Optical Integration . . . . . . . . . . . . . 3
4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 5 4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 5
5. IS-IS extensions for supporting the opaque adjacency segment . 6 5. PCEP-LS extensions for supporting the transport segment . . . 6
6. OSPF extensions for supporting the opaque adjacency segment . 8 6. OSPF extensions for supporting the transport segment . . . . . 7
7. OSPFv3 extensions for supporting the opaque adjacency 7. OSPFv3 extensions for supporting the transport segment . . . . 9
segment . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. IS-IS extensions for supporting the transport segment . . . . 10
8. BGP-LS extensions for supporting the opaque adjacency 9. BGP-LS extensions for supporting the transport segment . . . . 12
segment . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
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 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1 Normative References . . . . . . . . . . . . . . . . . . . 14 12.2 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.2 Informative References . . . . . . . . . . . . . . . . . . 15 12.3 OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 12.4 IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.5 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1 Normative References . . . . . . . . . . . . . . . . . . . 16
13.2 Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1 Introduction 1 Introduction
Packet and optical transport networks have evolved independently with Packet and optical transport networks have evolved independently with
different control plane mechanisms that have to be provisioned and different control plane mechanisms that have to be provisioned and
maintained separately. Consequently, coordinating packet and optical maintained separately. Consequently, coordinating packet and optical
networks for delivering services such as end-to-end traffic networks for delivering services such as end-to-end traffic
engineering or failure response has proved challenging. To address engineering or failure response has proved challenging. To address
this challenge, a unified control and management paradigm that this challenge, a unified control and management paradigm that
provides an incremental path to complete packet-optical integration provides an incremental path to complete packet-optical integration
while leveraging existing signaling and routing protocols in either while leveraging existing signaling and routing protocols in either
domains is needed. This document introduces such a paradigm based on domains is needed. This document introduces such a paradigm based on
Segment Routing (SR) [I-D.ietf-spring-segment-routing]. Segment Routing (SR) [I-D.ietf-spring-segment-routing].
This document introduces a new type of segment, Opaque Adjacency This document introduces a new type of segment, Transport segment.
Segment. Opaque Adjacency Segment can be used to model abstracted Transport segment can be used to model abstracted paths through the
paths through the optical transport domain and integrate it with the optical transport domain and integrate it with the packet network for
packet network for delivering end-to-end services. In addition, this delivering end-to-end services. In addition, this also introduces a
also introduces a notion of a Packet optical gateway (POG). These are notion of a Packet optical gateway (POG). These are nodes in the
nodes in the network that map packet services to the optical domain network that map packet services to the optical domain that originate
that originate and terminate these opaque adjacency segments. Given and terminate these transport segments. Given a transport segment, a
an opaque adjacency, a POG will expand it to a path in the optical POG will expand it to a path in the optical transport network.
transport network.
2. Reference Taxonomy 2. Reference Taxonomy
POG - Packet optical gateway Device POG - Packet optical gateway Device
SR Edge Router - The Edge Router which is the first SR capable device SR Edge Router - The Edge Router which is the ingress device
CE - Customer Edge Device that is outside of the SR domain CE - Customer Edge Device that is outside of the SR domain
PCE - Path Computation Engine PCE - Path Computation Engine
Controller - A network controller Controller - A network controller
3. Use case - Packet Optical Integration 3. Use case - Packet Optical Integration
Many operators build and operate their networks that are both multi- Many operators build and operate their networks that are both multi-
skipping to change at page 4, line 27 skipping to change at page 4, line 26
service is established by specifying a path between P1 and P4. Note 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 that in defining this path, we will need to specify both the nodes
and the links that make up this service. POGs advertise themselves and the links that make up this service. POGs advertise themselves
along with their adjacencies and the domains they belong to. To along with their adjacencies and the domains they belong to. To
leverage segment routing to define the above service, the ingress leverage segment routing to define the above service, the ingress
node P1 would append all outgoing packets in a SR header consisting 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 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, 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 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. 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 Each POG would announce the active optical path as a transport
adjacency - for example, in the case of P1, the optical path O1 would segment - for example, in the case of P1, the optical path O1 would
represent an optical path that includes the optical nodes Om and On 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 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 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 PCE that is run in Domain D would be responsible for calculating path
O1. O1.
|-----Om--------On-----| |-----Om--------On-----|
P1----| (D) |------P2 P1----| (D) |------P2
|-----Ox---------Oy----| |-----Ox---------Oy----|
Figure 2: POG with multiple optical paths through an optical domain Figure 2: POG with multiple optical paths through an optical domain
Similarly, the transit POGs P2 and P3 in Figure 1 would announce Similarly, the transit POGs P2 and P3 in Figure 1 would announce
opaque adjacencies O2 and O3. The border POG would include the transport segments O2 and O3. The border POG would include the
optical paths O1, O2 and O3 to the segment list for P1 to P4. 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}. expanded segment list would read as {O1, P2, O2, P3, O3, P4}.
There are potentially two locations for Borders POGs - one that has There are potentially two locations for Borders POGs - one that has
last-mile access nodes and the other being Data Center Interconnect last-mile access nodes and the other being Data Center Interconnect
nodes. The POGs that are in the core of the network which connect nodes. The POGs that are in the core of the network which connect
with long haul optical networks are usually Transit POGs. with long haul optical networks are usually Transit POGs.
+------------------------+ +------------------------+
| | | |
skipping to change at page 5, line 23 skipping to change at page 5, line 23
+-------+ +-------+ .--( )--. +-------+ +-------+ +-------+ +-------+ .--( )--. +-------+ +-------+
| SR | |Packet | ( ) |Packet | | SR | | SR | |Packet | ( ) |Packet | | SR |
| Edge | |Optical|-( Optical Transport )_ |Optical| | Edge | | Edge | |Optical|-( Optical Transport )_ |Optical| | Edge |
|Router | ... |Gateway| ( Domain ) |Gateway| ... |Router | |Router | ... |Gateway| ( Domain ) |Gateway| ... |Router |
+---+.--+ +-------+ ( ) +-------+ +---+.--+ +---+.--+ +-------+ ( ) +-------+ +---+.--+
| '--( )--' | | '--( )--' |
,--+. ( ) ,-+-. ,--+. ( ) ,-+-.
( CE ) '-----' ( CE ) ( CE ) '-----' ( CE )
`---' `---' `---' `---'
Figure 3. Reference Topology for Opaque Adjacency Segment Figure 3. Reference Topology for Transport Segment
4. Mechanism overview 4. Mechanism overview
The current proposal assumes that the SR domains run standard IGP The current proposal assumes that the SR domains run standard IGP
protocols to discover the topology and distribute labels without any protocols to discover the topology and distribute labels without any
modification. There are also no modifications to the control plane modification. There are also no modifications to the control plane
mechanisms in the Optical transport domains. The mechanism for mechanisms in the Optical transport domains. The mechanism for
supporting the opaque adjacency segment is as follows. supporting the transport segment is as follows.
1. Firstly, the Packet Optical Gateway (POG) devices announce 1. Firstly, the Packet Optical Gateway (POG) devices announce
themselves in the SR domain. This is indicated by advertising a new themselves in the SR domain. This is indicated by advertising a new
SR node capability flag. The exact extensions to support this SR node capability flag. The exact extensions to support this
capability are described in the subsequent sections of this capability are described in the subsequent sections of this
document. document.
2. Then, the POG devices announce paths to other POGs through the 2. Then, the POG devices announce paths to other POGs through the
optical transport domain as an opaque adjacency segment (opaque optical transport domain as a transport segment (transport segment
adjacency SID) in the SR domain. The paths are announced with an binding SID) in the SR domain. The paths are announced with an
appropriate transit domain type, optical transport domain ID, and a appropriate optical transport domain ID, and a label (Packet-Optical
label to be used to bind to the opaque adjacency segment. The Label) to be used to bind to the transport segment. The appropriate
appropriate IGP segment routing extensions to carry this information IGP segment routing extensions to carry this information is described
is described in the subsequent sections of this document. in the subsequent sections of this document.
3. The opaque adjacency segment can also optionally be announced 3. The transport segment can also optionally be announced with a
with a set of attributes that characterizes the path in the optical set of attributes that characterizes the path in the optical
transport domain between the two POG devices. For instance, those transport domain between the two POG devices. For instance, those
attributes could define the OTN mapping used (e.g., ODU4, 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 ODU3,ODU3e1....ODU1), timeslots (1-8 or 4,6,7 or 1-2,5), or optical
path protection schemes. path protection schemes.
4. The POG device is also responsible for programming its 4. The POG device is also responsible for programming its
forwarding table to map every opaque adjacency label entry into an forwarding table to map every transport segment label entry into an
appropriate forwarding action relevant in the optical domain, such as appropriate forwarding action relevant in the optical domain, such as
mapping it to a label-switched path. mapping it to a label-switched path.
5. The opaque adjacency segment is communicated to the PCE or 5. The transport segment is communicated to the PCE or Controller
Controller using extensions to BGP-LS or PCEP-LS as described in using extensions to BGP-LS or PCEP-LS as described in subsequent
subsequent sections of this document. sections of this document.
6. Finally, the PCE or Controller then uses the opaque adjacency 6. Finally, the PCE or Controller then uses the transport segment
segment label to influence the path leaving the SR domain into the label to influence the path leaving the SR domain into the optical
optical domain, thereby defining the end-to-end path for a given domain, thereby defining the end-to-end path for a given service.
service.
5. IS-IS extensions for supporting the opaque adjacency segment 5. PCEP-LS extensions for supporting the transport segment
A new IS-IS sub-TLV is defined: the Opaque Adjacency Segment To communicate the Packet-Optical Gateway capability of the device,
Identifier sub-TLV (Opaque-Adj-SID sub-TLV). The Opaque-Adj-SID sub- we introduce a new PCEP capabilities TLV is defined as
TLV is an optional sub-TLV carrying the opaque adjacency SID with follows(extensions to [I-D.draft-sivabalan-pce-segment-routing]):
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 Value Meaning Reference
POG devices to represent multiple paths within the optical domain -------- ------------------------------------ -----------------
with perhaps different characteristics. 27 TRANSPORT-SR-PCE-CAPABILITY This document
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 A new type of TLV to accommodate a transport segment is defined
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ by extending Binding SIDs [I-D.draft-sivabalan-pce-binding-label-sid-01]
| Type | Length | Flags | Weight | 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
| Domain ID |Opaque Sub Type| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |
| Remote POG System ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding Type (BT) | Domain ID |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding Value |
| Packet-Optical Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Transport Segment Sub TLVs (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where: -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD, suggested value 33 where:
Type: TBD, suggested value 32
Length: variable.
Binding Type: 0 or 1 as defined in
[I-D.draft-sivabalan-pce-binding-label-sid-01]
Domain ID: An identifier for the transport domain
Binding Value: is the transport segment label
Transport Segment Sub TLVs: TBD
IANA will be requested to allocate a new TLV type (recommended value
is 32) for TRANSPORT-SEGMENT-BINDING-TLV as specified in this document:
1 Transport Segment Label (This document)
6. OSPF extensions for supporting the transport segment
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.
Further, a new OSPF sub-TLV (similar to the ERO SubTLV) of SID/Label
Binding Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the
transport segment label 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain ID | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet-Optical Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Transport Segment Sub TLVs (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type : TBD, Suggested Value 9
Length: variable. Length: variable.
Domain ID: An identifier for the transport domain
Flags: 1 octet field of following flags: Flags: 1 octet field of following flags:
V - Value flag. If set, then the packet-optical label carries V - Value flag. If set, then the optical label carries a value.
a value. By default the flag is SET. By default the flag is SET.
L - Local. Local Flag. If set, then the value/index carried by L - Local. Local Flag. If set, then the value/index carried by
the Adj-SID has local significance. By default the flag is SET. the Adj-SID has local significance. By default the flag is SET.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|V|L| |V|L|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Other bits: Reserved. These MUST be zero when sent and are ignored Packet-Optical Label : according to the V and L flags, it contains
when received. either:
Weight: TBD * 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.
Transport Segment Sub TLVs: TBD
Multiple TRANSPORT-SEGMENT-BINDING-SUBTLV MAY be associated with a pair
of POG devices to represent multiple paths within the optical domain
7. OSPFv3 extensions for supporting the transport segment
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.
Further, a new OSPFv3 sub-TLV similar to the ERO SubTLV) of SID/Label
Binding Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the
transport segment label 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain ID | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet-Optical Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Transport Segment Sub TLVs (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type : TBD,Suggested Value 12
Length: variable.
Domain ID: An identifier for the transport domain Domain ID: An identifier for the transport domain
Opaque Sub Type: TBD 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.
Remote POG System-ID: 6 octets of IS-IS System-ID of length 0 1 2 3 4 5 6 7
"ID Length" as defined in [ISO10589]. +-+-+-+-+-+-+-+-+
|V|L|
+-+-+-+-+-+-+-+-+
Packet-Optical Label : according to the V and L flags, it contains Packet-Optical Label : according to the V and L flags, it contains
either: either:
* A 3 octet local label where the 20 rightmost bits are * A 3 octet local label where the 20 rightmost bits are
used for encoding the label value. In this case the V and used for encoding the label value. In this case the V and
L flags MUST be set. L flags MUST be set.
* A 4 octet index defining the offset in the label space * A 4 octet index defining the offset in the label space
advertised by this router. In this case V and L flags MUST advertised by this router. In this case V and L flags MUST
be unset. be unset.
Further, to communicate the Packet-Optical Gateway capability of the Transport Segment Sub TLVs: TBD
device, we introduce a new flag O in the SR Node Capabilities sub-TLV:
Multiple TRANSPORT-SEGMENT-BINDING-SUBTLV MAY be associated with a pair
of POG devices to represent multiple paths within the optical domain
8. IS-IS extensions for supporting the transport segment
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 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|I|V|H|O| | |I|V|H|O| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
I, V, H flags are defined in [I-D.ietf-isis-segment-routing-extensions]. 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 O-Flag: If set, then the router is capable of performing Packet
Optical Gateway function.
A new OSPF sub-TLV is defined: the Opaque Adjacency Segment Identifier Further, a new IS-IS sub-TLV (similar to the ERO SubTLV) of SID/Label
sub-TLV (Opaque-Adj-SID sub-TLV). The Opaque-Adj-SID sub-TLV is an Binding Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the
optional sub-TLV of the Extended Link TLV carrying the opaque adjacency transport segment label is defined as follows.
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 First, we define the O flag in the SID/Label Binding TLV
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
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 +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|M|S|D|A|O| |
| Type | Length | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F, M, S, D, and A flags: are defined in [I-D.ietf-isis-segment-routing
| Flags | Reserved | MT-ID | Weight | -extensions]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ O-Flag: If set, then the F flag, Range, Prefix Length FEC Prefix, must
| Domain ID |Opaque Sub Type| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote POG Router-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet-Optical Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type: TBD, suggested value 3 be ignored in the SID/Label Binding TLV
Secondly, we define the SubTLV of the SID/Label Binding Sub-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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain ID | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet-Optical Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Transport Segment Sub TLVs (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type : TBD, Suggested Value 151
Length: variable. Length: variable.
Domain ID: An identifier for the transport domain
Flags: 1 octet field of following flags: Flags: 1 octet field of following flags:
V - Value flag. If set, then the optical label carries a value. V - Value flag. If set, then the optical label carries a value.
By default the flag is SET. By default the flag is SET.
L - Local. Local Flag. If set, then the value/index carried by L - Local. Local Flag. If set, then the value/index carried by
the Adj-SID has local significance. By default the flag is SET. the Adj-SID has local significance. By default the flag is SET.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|V|L| |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 Packet-Optical Label : according to the V and L flags, it contains
either: either:
* A 3 octet local label where the 20 rightmost bits are * A 3 octet local label where the 20 rightmost bits are
used for encoding the label value. In this case the V and used for encoding the label value. In this case the V and
L flags MUST be set. L flags MUST be set.
* A 4 octet index defining the offset in the label space * A 4 octet index defining the offset in the label space
advertised by this router. In this case V and L flags MUST advertised by this router. In this case V and L flags MUST
be unset. be unset.
Further, to communicate the Packet-Optical Gateway capability of the Transport Segment Sub TLVs: TBD
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 Multiple TRANSPORT-SEGMENT-BINDING-SUBTLV MAY be associated with a pair
Packet Optical Gateway function. of POG devices to represent multiple paths within the optical domain
with perhaps different characteristics.
7. OSPFv3 extensions for supporting the opaque adjacency segment 9. BGP-LS extensions for supporting the transport segment
The Opaque-Adj-SID Sub-TLV is an optional Sub-TLV of the 9.1 Node Attribuites TLV
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 To communicate the Packet-Optical Gateway capability of the
POG devices to represent multiple paths within the optical domain device, we introduce an new optical informational capability
with perhaps different characteristics. the following new Node Attribute TLV is defined:
The Opaque-Adj-SID Sub-TLV has the following format: +-----------+----------------------------+----------+---------------+
| TLV Code | Description | Length | Section |
| Point | | | |
+-----------+----------------------------+----------+---------------+
| 1172 | SR-Optical-Node-Capability | variable | |
| | TLV | | |
+-----------+----------------------------+----------+---------------+
Table 1: Node Attribute TLVs
These TLVs can ONLY be added to the Node Attribute associated with
the node NLRI that originates the corresponding SR TLV.
9.2 SR-Optical-Node-Capability TLV
The SR Capabilities sub-TLV has following format:
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Weight | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain ID |Opaque Sub Type| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote POG Router-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet-Optical Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Type: TBD, suggested value 6 Type : TBD, Suggested Value 1157
Length: variable.
Flags: The Flags field currently has only one bit defined. If the bit
is set it has the capability of an Packet Optical Gateway.
9.3 Prefix Attribute TLVs
The following Prefix Attribute Binding SID Sub-TLVs have been added:
+------------+-------------------------+----------+-----------------+
| TLV Code | Description | Length | Section |
| Point | | | |
+------------+-------------------------+----------+-----------------+
| 1173 | TRANSPORT-SEGMENT-SID | 12 | |
| | | | |
+------------+-------------------------+----------+-----------------+
Table 4: Prefix Attribute - Binding SID Sub-TLVs
The Transport segment TLV allows a node to advertise an transport
segment within a single IGP domain. The transport segment SID TLV
TRANSPORT-SEGMENT-TLV has the following format:
9.3.1 Transport Segment SID Sub-TLV
Further, a new sub-TLV (similar to the IPV4 ERO SubTLV) of
Binding SID Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the
transport segment label is defined as follows.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain ID | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet-Optical Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Transport Segment Sub TLVs (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type : TBD
Length: variable. Length: variable.
Domain ID: An identifier for the transport domain
Flags: 1 octet field of following flags: Flags: 1 octet field of following flags:
V - Value flag. If set, then the optical label carries a value. V - Value flag. If set, then the optical label carries a value.
By default the flag is SET. By default the flag is SET.
L - Local. Local Flag. If set, then the value/index carried by L - Local. Local Flag. If set, then the value/index carried by
the Adj-SID has local significance. By default the flag is SET. the Adj-SID has local significance. By default the flag is SET.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|V|L| |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 Router-ID: 4 octets of OSPFv3 Router-ID
Packet-Optical Label : according to the V and L flags, it contains Packet-Optical Label : according to the V and L flags, it contains
either: either:
* A 3 octet local label where the 20 rightmost bits are * A 3 octet local label where the 20 rightmost bits are
used for encoding the label value. In this case the V and used for encoding the label value. In this case the V and
L flags MUST be set. L flags MUST be set.
* A 4 octet index defining the offset in the label space * A 4 octet index defining the offset in the label space
advertised by this router. In this case V and L flags MUST advertised by this router. In this case V and L flags MUST
be unset. be unset.
Further, to communicate the Packet-Optical Gateway capability of the Transport Segment Sub TLVs: TBD
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 Multiple TRANSPORT-SEGMENT-TLV MAY be associated with a pair
Packet Optical Gateway function. of POG devices to represent multiple paths within the optical domain
8. BGP-LS extensions for supporting the opaque adjacency segment 10. Summary
8.1 Link Attribute TLVs The motivation for introducing a new type of segment - transport
The following new Link Attribute TLVs are defined: segment - is to integrate transport networks with the segment routing
domain and expose characteristics of the transport domain into the
packet domain. An end-to-end path across packet and transport domains
can then be specified by attaching appropriate SIDs to the packet.
An instance of transport segments has been defined here for optical
networks, where paths between packet-optical gateway devices has been
abstracted using binding SIDs. Extensions to various protocols to
announce the transport segment have been proposed in this document.
+-----------+----------------------------+----------+---------------+ 11. Security Considerations
| TLV Code | Description | Length | Section |
| Point | | | |
+-----------+----------------------------+----------+---------------+
| 1101 | Opaque Adjacency Segment | variable | |
| | Identifier (Opq-Adj-SID)TLV| | |
+-----------+----------------------------+----------+---------------+
Table 1: BGP-LS Link Attribute TLVs This document does not introduce any new security considerations.
These TLVs can ONLY be added to the Link Attribute associated with 12 IANA Considerations
the link whose local node originates the corresponding SR TLV.
The Opaque adjacency segment TLV allows a node to advertise an opaque This documents request allocation for the following TLVs and subTLVs.
adjacency within a single IGP domain.
8.2 Opaque Adjacency SID TLV 12.1 PCEP
The Opaque Adjacency SID (Opq-Adj-SID) TLV has the following format: Packet-Optical Gateway capability of the device
0 1 2 3 Value Meaning Reference
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 -------- ------------------------------------ -----------------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 27 TRANSPORT-SR-PCE-CAPABILITY This document
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Weight | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain ID |Opaque Sub Type| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote POG System ID/Router-ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet-Optical Label |
+---------------------------------------------------------------+
Where: A new type of TLV to accommodate a transport segment is defined
by extending Binding SIDs [I-D.draft-sivabalan-pce-binding-label-sid-01]
Type: TBD, suggested value 1101. Value Description Reference
Length: Variable. 32 TRANSPORT-SR-PCEP-TLV This document
Flags: 1 octet field of following flags as defined in the previous This document requests that a registry is created to manage the value
sections for IS-IS and OSPF. of the Binding Type field in the TRANSPORT-SR-PCEP TLV.
Weight: TBD. Value Description Reference
Domain ID: An identifier for the optical transport domain 1 Transport Segment Label This document
Opaque Sub Type : TBD 12.2 OSPF
Transport-Segment SubTLV of OSPF Extended Prefix LSA
Remote POG Router-ID/System-ID: 4 octets of OSPF Router-ID or 6 Octets Value Description Reference
of IS-IS System ID.
Packet-Optical Label: 4 octet field carrying the label as defined 9 TRANSPORT-SR-OSPF-SUBTLV This document
in the previous sections for IS-IS and OSPF.
9. PCEP-LS extensions for supporting the opaque adjacency segment 12.3 OSPFv3
Transport-Segment SubTLV of OSPFv3 Extend-LSA Sub-TLV registry
Changes similar to BGP-LS are needed for supporting the opaque Value Description Reference
adjacency segment in PCEP-LS. Details TBD.
10. Summary 12 TRANSPORT-SR-OSPFv3-SUBTLV This document
The motivation for introducing an opaque adjacency segment that is 12.4 IS-IS
separate from an IGP adjacency segment is to distinguish between a Transport-Segment SubTLV of Segment Identifier / Label Binding TLV
real IGP adjacency (which is typically a symmetric relationship Value Description Reference
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.
11. Security Considerations 151 TRANSPORT-SR-ISIS-SUBTLV This document
This document does not introduce any new security considerations. 12.5 BGP-LS
Node Attributes TLV:
12 IANA Considerations Value Description Reference
TBD. 1172 TRANSPORT-SR-BGPLS-CAPABILITY This document
Prefix Attribute Binding SID SubTLV:
Value Description Reference
1173 TRANSPORT-SR-BGPLS-TLV This document
13 References 13 References
13.1 Normative References 13.1 Normative References
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and r. rjs@rob.sh, "Segment Routing Architecture", draft- and r. rjs@rob.sh, "Segment Routing Architecture", draft-
ietf-spring-segment-routing-04 (work in progress), July ietf-spring-segment-routing-04 (work in progress), July
2015. 2015.
skipping to change at page 15, line 4 skipping to change at page 17, line 12
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
Extensions for Segment Routing", draft-ietf-ospf-ospfv3- Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
segment-routing-extensions-03 (work in progress), June segment-routing-extensions-03 (work in progress), June
2015. 2015.
[I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-13 Information using BGP", draft-ietf-idr-ls-distribution-13
(work in progress), October 2015. (work in progress), October 2015.
[RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July
2007, <http://www.rfc-editor.org/info/rfc4970>. 2007, <http://www.rfc-editor.org/info/rfc4970>.
[I-D.sivabalan-pce-binding-label-sid]
Sivabalan, S., Filsfils, C., Previdi, S., Tantsura, J.,
Hardwick, J., and M. Nanduri, "Carrying Binding Label/
Segment-ID in PCE-based Networks.", draft-sivabalan-pce-
binding-label-sid-01 (work in progress), March 2016.
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,
"PCEP Extensions for Segment Routing", draft-ietf-pce-
segment-routing-07 (work in progress), March 2016.
13.2 Informative References 13.2 Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses Authors' Addresses
Madhukar Anand Madhukar Anand
skipping to change at page 15, line 26 skipping to change at page 18, line 4
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses Authors' Addresses
Madhukar Anand Madhukar Anand
Infinera Corporation Infinera Corporation
169 W Java Dr, Sunnyvale, CA 94089 169 W Java Dr, Sunnyvale, CA 94089
Email: manand@infinera.com Email: manand@infinera.com
Sanjoy Bardhan Sanjoy Bardhan
Infinera Corporation Infinera Corporation
169 W Java Dr, Sunnyvale, CA 94089 169 W Java Dr, Sunnyvale, CA 94089
Email: sbardhan@infinera.com Email: sbardhan@infinera.com
Ramesh Subrahmaniam Ramesh Subrahmaniam
Infinera Corporation Infinera Corporation
169 W Java Dr, Sunnyvale, CA 94089 169 W Java Dr, Sunnyvale, CA 94089
Email: RSubrahmaniam@@infinera.com Email: RSubrahmaniam@@infinera.com
Jeff Tantsura
Email: jefftant.ietf@gmail.com
 End of changes. 81 change blocks. 
235 lines changed or deleted 364 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/