< draft-anand-spring-poi-sr-02.txt   draft-anand-spring-poi-sr-03.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
Jeff Tantsura Jeff Tantsura
Individual Individual
Expires: June 25, 2017 December 22, 2016
Utpal Mukhopadhyaya
Equinix Inc
Expires: December 28, 2017 June 26, 2017
Packet-Optical Integration in Segment Routing Packet-Optical Integration in Segment Routing
draft-anand-spring-poi-sr-02 draft-anand-spring-poi-sr-03
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 transport networks in an opaque links in segment routing to represent transport networks in an opaque
way into the segment routing domain. An instance of this class would way into the segment routing domain. An instance of this class would
be optical networks that are typically transport centric. In the IP be 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
'transport segments' or sub-paths as an augmentation to the defined 'transport segments' or sub-paths as an augmentation to the defined
skipping to change at page 2, line 4 skipping to change at page 2, line 9
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 3 2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 4
3. Use case - Packet Optical Integration . . . . . . . . . . . . . 3 3. Use case - Packet Optical Integration . . . . . . . . . . . . . 5
4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 8
5. PCEP-LS extensions for supporting the transport segment . . . 6 5. PCEP-LS extensions for supporting the transport segment . . . 8
6. OSPF extensions for supporting the transport segment . . . . . 8 6. OSPF extensions for supporting the transport segment . . . . . 10
7. OSPFv3 extensions for supporting the transport segment . . . . 9 7. OSPFv3 extensions for supporting the transport segment . . . . 11
8. IS-IS extensions for supporting the transport segment . . . . 10 8. IS-IS extensions for supporting the transport segment . . . . 12
9. BGP-LS extensions for supporting the transport segment . . . . 12 9. BGP-LS extensions for supporting the transport segment . . . . 14
10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Note about Transport Segments and Scalability . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12.2 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.3 OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.2 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.4 IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.3 OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.5 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.4 IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.5 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1 Normative References . . . . . . . . . . . . . . . . . . . 16 14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.2 Informative References . . . . . . . . . . . . . . . . . . 18 14.1 Normative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 14.2 Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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
skipping to change at page 3, line 27 skipping to change at page 4, line 27
This document introduces a new type of segment, Transport segment. This document introduces a new type of segment, Transport segment.
Transport segment can be used to model abstracted paths through the Transport segment can be used to model abstracted paths through the
optical transport domain and integrate it with the packet network for optical transport domain and integrate it with the packet network for
delivering end-to-end services. In addition, this also introduces a delivering end-to-end services. In addition, this also introduces a
notion of a Packet optical gateway (POG). These are nodes in the notion of a Packet optical gateway (POG). These are nodes in the
network that map packet services to the optical domain that originate network that map packet services to the optical domain that originate
and terminate these transport segments. Given a transport segment, a and terminate these transport segments. Given a transport segment, a
POG will expand it to a path in the optical transport network. POG will expand it to a path in the optical transport network.
The concept of POG introduced here allows for multiple instantiations
of the concept. In one case, the packet device is distinct from the
optical transport device, and the POG is a logical entity that spans
these two devices. In this case, the POG functionality is achieved
with the help of external coordination between the packet and optical
devices. In another case, the packet and optical components are
integrated into one physical device, and the co-ordination required
for functioning of the POG is performed by this integrated device.
It must be noted that in either case, it is the packet/optical data
plane that is either disaggregated or integrated. Control of the
devices can be logically centralized or distributed in either
scenario. The focus of this document is to define the logical
functions of a POG without going into the exact instantiations of the
concept.
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 ingress 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
skipping to change at page 4, line 7 skipping to change at page 5, line 18
layer and multi-domain. Services are built around these layers and layer and multi-domain. Services are built around these layers and
domains to provide end-to-end services. Due to the nature of the domains to provide end-to-end services. Due to the nature of the
different domains, such as packet and optical, the management and different domains, such as packet and optical, the management and
service creation has always been problematic and time consuming. With service creation has always been problematic and time consuming. With
segment routing, enabling a head-end node to select a path and embed 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 the information in the packet is a powerful construct that would be
used in the Packet Optical Gateways (POG). The path is usually used in the Packet Optical Gateways (POG). The path is usually
constructed for each domain that may be manually derived or through a constructed for each domain that may be manually derived or through a
stateful PCE which is run specifically in that domain. stateful PCE which is run specifically in that domain.
P5 P5
P1 _ .-'-._ ,'P4 P1 _ .-'-._ ,'P4
`._ .-' `-. ,' `._ .-' `-. ,'
`. _.-' `-._ ,' `. _.-' `-._ ,'
`-. .-' `-. ,' `-. .-' `-. ,'
P2`.-'--------------------------`-.- P3 P2`.-'--------------------------`-.- P3
|\ /| |\ /|
| \ / | Packet | \ / | Packet
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
| \ / | | \ / |
| \ / | Transport | \ / | Transport
skipping to change at page 4, line 43 skipping to change at page 6, line 11
network comprising of nodes O1,...,O6. Nodes P2 and P3 are POGs that network comprising of nodes O1,...,O6. Nodes P2 and P3 are POGs that
communicate with other packet devices and also with the devices in the communicate with other packet devices and also with the devices in the
optical transport domain. In defining a link in the packet domain optical transport domain. In defining a link in the packet domain
between P2 and P3, we will need to specify both the nodes and the links between P2 and P3, we will need to specify both the nodes and the links
in the optical transport domain that establish this link. in the optical transport domain that establish this link.
To leverage segment routing to define a service between P1 and P4, the To leverage segment routing to define a service between P1 and P4, the
ingress node P1 would append all outgoing packets in a SR header ingress node P1 would append all outgoing packets in a SR header
consisting of the SIDs that constitute the path. In the packet domain consisting of the SIDs that constitute the path. In the packet domain
this would mean P1 would send its packets towards P4 using a segment this would mean P1 would send its packets towards P4 using a segment
list {P2, P3, P4}. The operator would need to use a different mechanism list {P2, P3, P4} or {P2, P5, P3, P4} as the case may be. The operator
in the optical domain to set up the optical paths comprising the nodes would need to use a different mechanism in the optical domain to set up
O1, O2 and O3. Each POG would announce the active optical path as a the optical paths comprising the nodes O1, O2 and O3. Each POG would
transport segment - for example, in the case of P1, the optical path announce the active optical path as a transport segment - for example,
{O1, O2, O3} would be represented as a label Om. This path is not known the optical path {O1, O2, O3} could be represented as a label Om and the
to the packet SR domain and is only relevant to the optical domain D optical path {O2, O3} could be represented as a transport label On. Both
between P2 and P3. A PCE that is run in Domain D would be responsible Om and On will be advertised by Packet node P1. These paths are not
for calculating path corresponding to label Om. The expanded segment known to the packet SR domain and is only relevant to the optical domain
list would read as {P2, Om, P3, P4}. D between P2 and P3. A PCE that is run in Domain D would be
responsible for calculating paths corresponding to label Om and On. The
expanded segment list would read as {P2, Om, P3, P4} or {P2, On, P3,
P4}. It is to be noted that there are other possible paths between P2
and P3 in the optical domain involving optical nodes O5, O6, and O4.
There is no requirement that every path between P2 and P3 be represented
as transport segments. A discussion on transport segments and
scalability can be found in Section 10.
Use-case examples of transport segments.
1. Consider the scenario where there are multiple fibers between two
packet end points. The network operator may choose to route packet
traffic on the first fiber, and reserve the second fiber only to
maintenance or low priority traffic.
2. As a second use-case, consider the case where the packet end points
are connected by optical transport provided by two different service
providers. The packet operator wants to preferentially route traffic
over one of the providers and use the second provider as a backup.
3. Finally, let the packet end points be connected by optical paths that
lie in different geographies. For instance, one optical transport path
may lie completely in one country while the other optical transport path
transits another country. Weather, tariffs, security considerations and
other factors may determine how the packet operator wants to route
different types of traffic on this network.
All of the above use-cases can be supported by first mapping distinct
optical transport paths to different transport segments and then,
depending on the need, affixing appropriate transport segment identifier
to the specific packet to route it appropriately through the transport
domain.
+------------------------+ +------------------------+
| | | |
+--------------+----' PCE or Controller |----+---------------+ +--------------+----' PCE or Controller |----+---------------+
| | | | | | | | | | | |
| | +------------------------+ | | | | +------------------------+ | |
| | | | | | | |
| | .-----. | | | | .-----. | |
| | ( ) | | | | ( ) | |
+-------+ +-------+ .--( )--. +-------+ +-------+ +-------+ +-------+ .--( )--. +-------+ +-------+
| 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 Transport Segment Figure 3. Reference Topology for Transport Segment Mechanism
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. For example, the optical
supporting the transport segment is as follows. paths may be setup using a domain-specific controller or PCE based on
requirements from the packet domain (such as bandwidth, QoS, latency
and cost). The mechanism for supporting the transport segment in the
packet domain 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 a transport segment (transport segment optical transport domain as a transport segment (transport segment
binding SID) in the SR domain. The paths are announced with an binding SID) in the SR domain. The paths are announced with an
skipping to change at page 15, line 4 skipping to change at page 17, line 7
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.
Transport Segment Sub TLVs: TBD Transport Segment Sub TLVs: TBD
Multiple TRANSPORT-SEGMENT-TLV MAY be associated with a pair Multiple TRANSPORT-SEGMENT-TLV MAY be associated with a pair
of POG devices to represent multiple paths within the optical domain of POG devices to represent multiple paths within the optical domain
10. Summary
10. Note about Transport Segments and Scalability
In most operational scenarios, there would be multiple, distinct paths
between the POGs. There is no requirement that every distinct path in
the optical domain be advertised as a separate transport segment.
Transport segments are designed to be consumed in the packet domain,
and the correspondence between transport segments and exact paths in
the optical domain are determined by their utility to the packet world.
Therefore, the number of transport segments is to be determined by the
individual packet-optical use-case. The number of actual paths in the
optical domain between the POG is expected to be large (counting the
number of active and passive devices in the optical network), it is
likely that multiple actual paths are to be advertised as one transport
segment. Of course, in the degenerate case, it is possible that there
is a one-to-one correspondence between an optical path and a transport
segment. Given this view of network operation, the POG is not expected
to handle a large number of transport segments (and identifiers). This
framework does leave open the possibility of handling a large number
of transport segments in future. For instance, a hierarchical
partitioning of the optical domain along with stacking of multiple
transport segment identifiers could be explored towards reducing
the overall number of transport segment identifiers.
11. Summary
The motivation for introducing a new type of segment - transport The motivation for introducing a new type of segment - transport
segment - is to integrate transport networks with the segment routing segment - is to integrate transport networks with the segment routing
domain and expose characteristics of the transport domain into the domain and expose characteristics of the transport domain into the
packet domain. An end-to-end path across packet and transport domains packet domain. An end-to-end path across packet and transport domains
can then be specified by attaching appropriate SIDs to the packet. can then be specified by attaching appropriate SIDs to the packet.
An instance of transport segments has been defined here for optical An instance of transport segments has been defined here for optical
networks, where paths between packet-optical gateway devices has been networks, where paths between packet-optical gateway devices has been
abstracted using binding SIDs. Extensions to various protocols to abstracted using binding SIDs. Extensions to various protocols to
announce the transport segment have been proposed in this document. announce the transport segment have been proposed in this document.
11. Security Considerations 12. Security Considerations
This document does not introduce any new security considerations. This document does not introduce any new security considerations.
12 IANA Considerations 13 IANA Considerations
This documents request allocation for the following TLVs and subTLVs. This documents request allocation for the following TLVs and subTLVs.
12.1 PCEP 13.1 PCEP
Packet-Optical Gateway capability of the device Packet-Optical Gateway capability of the device
Value Meaning Reference Value Meaning Reference
-------- ------------------------------------ ----------------- -------- ------------------------------------ -----------------
27 TRANSPORT-SR-PCE-CAPABILITY This document 27 TRANSPORT-SR-PCE-CAPABILITY This document
A new type of TLV to accommodate a transport segment is defined 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] by extending Binding SIDs [I-D.draft-sivabalan-pce-binding-label-sid-01]
Value Description Reference Value Description Reference
32 TRANSPORT-SR-PCEP-TLV This document 32 TRANSPORT-SR-PCEP-TLV This document
This document requests that a registry is created to manage the value This document requests that a registry is created to manage the value
of the Binding Type field in the TRANSPORT-SR-PCEP TLV. of the Binding Type field in the TRANSPORT-SR-PCEP TLV.
Value Description Reference Value Description Reference
1 Transport Segment Label This document 1 Transport Segment Label This document
12.2 OSPF 13.2 OSPF
Transport-Segment SubTLV of OSPF Extended Prefix LSA Transport-Segment SubTLV of OSPF Extended Prefix LSA
Value Description Reference Value Description Reference
9 TRANSPORT-SR-OSPF-SUBTLV This document 9 TRANSPORT-SR-OSPF-SUBTLV This document
12.3 OSPFv3 13.3 OSPFv3
Transport-Segment SubTLV of OSPFv3 Extend-LSA Sub-TLV registry Transport-Segment SubTLV of OSPFv3 Extend-LSA Sub-TLV registry
Value Description Reference Value Description Reference
12 TRANSPORT-SR-OSPFv3-SUBTLV This document 12 TRANSPORT-SR-OSPFv3-SUBTLV This document
12.4 IS-IS 13.4 IS-IS
Transport-Segment SubTLV of Segment Identifier / Label Binding TLV Transport-Segment SubTLV of Segment Identifier / Label Binding TLV
Value Description Reference Value Description Reference
151 TRANSPORT-SR-ISIS-SUBTLV This document 151 TRANSPORT-SR-ISIS-SUBTLV This document
12.5 BGP-LS 13.5 BGP-LS
Node Attributes TLV: Node Attributes TLV:
Value Description Reference Value Description Reference
1172 TRANSPORT-SR-BGPLS-CAPABILITY This document 1172 TRANSPORT-SR-BGPLS-CAPABILITY This document
Prefix Attribute Binding SID SubTLV: Prefix Attribute Binding SID SubTLV:
Value Description Reference Value Description Reference
1173 TRANSPORT-SR-BGPLS-TLV This document 1173 TRANSPORT-SR-BGPLS-TLV This document
13 References 14 References
13.1 Normative References 14.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.
[I-D.ietf-isis-segment-routing-extensions] [I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
skipping to change at page 18, line 5 skipping to change at page 20, line 28
Hardwick, J., and M. Nanduri, "Carrying Binding Label/ Hardwick, J., and M. Nanduri, "Carrying Binding Label/
Segment-ID in PCE-based Networks.", draft-sivabalan-pce- Segment-ID in PCE-based Networks.", draft-sivabalan-pce-
binding-label-sid-01 (work in progress), March 2016. binding-label-sid-01 (work in progress), March 2016.
[I-D.ietf-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,
"PCEP Extensions for Segment Routing", draft-ietf-pce- "PCEP Extensions for Segment Routing", draft-ietf-pce-
segment-routing-07 (work in progress), March 2016. segment-routing-07 (work in progress), March 2016.
13.2 Informative References 14.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
Infinera Corporation Infinera Corporation
skipping to change at page 18, line 33 skipping to change at page 21, line 15
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 Jeff Tantsura
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Utpal Mukhopadhyaya
Equinix Inc
1188 E. Arques, Sunnyvale, CA 94085
Email: umukhopadhyaya@equinix.com
 End of changes. 24 change blocks. 
49 lines changed or deleted 130 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/