< draft-ietf-teas-gmpls-controller-inter-work-00.txt   draft-ietf-teas-gmpls-controller-inter-work-01.txt >
TEAS Working Group Haomian Zheng TEAS Working Group Haomian Zheng
Internet Draft Xianlong Luo Internet Draft Xianlong Luo
Category: Informational Huawei Technologies Category: Informational Huawei Technologies
Yang Zhao Yang Zhao
China Mobile China Mobile
Yunbin Xu Yunbin Xu
CAICT CAICT
Sergio Belotti Sergio Belotti
Dieter Beller Dieter Beller
Nokia Nokia
Expires: December 12, 2019 June 12, 2019 Expires: January 8, 2020 July 8, 2019
Interworking of GMPLS Control and Centralized Controller System Interworking of GMPLS Control and Centralized Controller System
draft-ietf-teas-gmpls-controller-inter-work-00 draft-ietf-teas-gmpls-controller-inter-work-01
Abstract Abstract
Generalized Multi-Protocol Label Switching (GMPLS) control allows Generalized Multi-Protocol Label Switching (GMPLS) control allows
each network element (NE) to perform local resource discovery, each network element (NE) to perform local resource discovery,
routing and signaling in a distributed manner. routing and signaling in a distributed manner.
On the other hand, with the development of software-defined On the other hand, with the development of software-defined
transport networking technology, a set of NEs can be controlled via transport networking technology, a set of NEs can be controlled via
centralized controller hierarchies to address the issue from multi- centralized controller hierarchies to address the issue from multi-
skipping to change at page 2, line 13 skipping to change at page 2, line 13
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference 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/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
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.
This Internet-Draft will expire on August 19, 2019. This Internet-Draft will expire on January 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Conventions used in this document Conventions used in this document
Table of Contents Table of Contents
1. Introduction ................................................ 3 1. Introduction...................................................3
2. Overview .................................................... 4 2. Overview.......................................................4
2.1. Overview of GMPLS Control Plane............................ 4 2.1. Overview of GMPLS Control Plane..............................4
2.2. Overview of Centralized Controller System ................. 4 2.2. Overview of Centralized Controller System....................4
2.3. GMPLS Control Interwork with Centralized Controller System. 4 2.3. GMPLS Control Interwork with Centralized Controller System...4
3. Link Management Protocol .................................... 6 3. Link Management Protocol............Error! Bookmark not defined.
4. Routing Options ............................................. 6 4. Routing Options................................................6
4.1. OSPF-TE ................................................ 6 4.1. OSPF-TE...................................................6
4.2. ISIS-TE ................................................ 6 4.2. ISIS-TE...................................................7
4.3. Netconf/RESTconf ....................................... 7 4.3. Netconf/RESTconf..........................................7
5. Path Computation ............................................ 7 5. Path Computation...............................................7
5.1. Constraint-based Path Computing in GMPLS Control........ 7 5.1. Constraint-based Path Computing in GMPLS Control..........7
5.2. Path Computation Element (PCE) ......................... 7 5.2. Path Computation Element (PCE)............................7
6. Signaling Options ........................................... 8 6. Signaling Options..............................................8
6.1. RSVP-TE ................................................ 8 6.1. RSVP-TE...................................................8
7. Interworking Scenarios....................................... 8 7. Interworking Scenarios.........................................8
7.1. Topology Collection & Synchronization .................. 8 7.1. Topology Collection & Synchronization.....................8
7.2. Multi-domain/layer Service Provisioning ................ 9 7.2. Multi-domain Service Provisioning.........................9
7.3. Recovery ............................................... 9 7.3. Multi-layer Service Provisioning.........................11
7.4. Controller Reliability ................................ 10 7.4. Recovery.................................................11
8. Manageability Considerations................................ 10 7.5. Controller Reliability...................................11
9. Security Considerations .................................... 10 8. Manageability Considerations..................................12
10. IANA Considerations........................................ 10 9. Security Considerations.......................................12
11. References ................................................ 10 10. IANA Considerations..........................................12
11.1. Normative References.................................. 10 11. References...................................................12
11.2. Informative References................................ 12 11.1. Normative References....................................12
12. Authors' Addresses ........................................ 14 11.2. Informative References..................................14
12. Authors' Addresses ...........................................16
1. Introduction 1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends
MPLS to support different classes of interfaces and switching MPLS to support different classes of interfaces and switching
capabilities such as Time-Division Multiplex Capable (TDM), Lambda capabilities such as Time-Division Multiplex Capable (TDM), Lambda
Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network
element (NE) running a GMPLS control plane collects network element (NE) running a GMPLS control plane collects network
information from other NEs and supports service provisioning through information from other NEs and supports service provisioning through
signaling in a distributed manner. More generic description for signaling in a distributed manner. More generic description for
skipping to change at page 4, line 42 skipping to change at page 4, line 42
With the development of SDN technologies, a centralized controller With the development of SDN technologies, a centralized controller
architecture has been introduced to transport networks. One example architecture has been introduced to transport networks. One example
architecture can be found in ACTN [RFC8453]. In such systems, a architecture can be found in ACTN [RFC8453]. In such systems, a
controller is aware of the network topology and is responsible for controller is aware of the network topology and is responsible for
provisioning incoming service requests. provisioning incoming service requests.
Multiple hierarchies of controllers are designed at different levels Multiple hierarchies of controllers are designed at different levels
implementing different functions. This kind of architecture enables implementing different functions. This kind of architecture enables
multi-vendor, multi-domain, and multi-technology control. For multi-vendor, multi-domain, and multi-technology control. For
example, an higher-level controller coordinates several lower-level example, a higher-level controller coordinates several lower-level
controllers controlling different domains, for topology collection controllers controlling different domains, for topology collection
and service provisioning. Vendor-specific features can be abstracted and service provisioning. Vendor-specific features can be abstracted
between controllers, and standard API (e.g., generated from between controllers, and standard API (e.g., generated from
RESTconf/YANG) is used. RESTconf/YANG) is used.
2.3. GMPLS Control Interwork with Centralized Controller System 2.3. GMPLS Control Interwork with Centralized Controller System
Besides the GMPLS and the interactions among the controller Besides the GMPLS and the interactions among the controller
hierarchies, it is also necessary for the controllers to communicate hierarchies, it is also necessary for the controllers to communicate
with the network elements. Within each domain, GMPLS control can be with the network elements. Within each domain, GMPLS control can be
applied to each NE. The bottom-level central controller can act as a applied to each NE. The bottom-level central controller can act as a
NE to collect network information and initiate LSP. Figure 1 shows NE to collect network information and initiate LSP. Figure 1 shows
an example of GMPLS interworking with centralized controllers (ACTN an example of GMPLS interworking with centralized controllers (ACTN
terminologies are used in the figure). terminologies are used in the figure).
+----------+ +--------------------+
| MDSC | | Orchestrator |
+----------+ +--------------------+
^ ^ ^ ^ ^
| | | | |
+---------+ +---------+ +-------------+ | +------------+
| RESTConf / YANG models | | | RESTConf/YANG models |
V V V V V
+---------+ +---------+ +----------+ +----------+ +----------+
| PNC | | PNC | |Controller| |Controller| |Controller|
+---------+ +---------+ +----------+ +----------+ +----------+
^ ^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | | |
Netconf| |PCEP Netconf| |PCEP Netconf| |PCEP Netconf| |PCEP | IF*
/YANG | | /YANG | | /YANG | | /YANG | | |
V V V V V V V V V
.-------------. Inter- .-------------. .------------. Inter- .-----------. Inter- .-----------.
/ \ domain / \ / \ domain / \ domain / \
| LMP | link | LMP | | | link | LMP | link | LMP |
| OSPF-TE ========== OSPF-TE | | |======| OSPF-TE |=======| OSPF-TE |
| RSVP-TE | | RSVP-TE | | | | RSVP-TE | | RSVP-TE |
\ / \ / \ / \ / \ /
`------------` `------------` `-----------` `------------` `----------`
GMPLS domain GMPLS domain non-GMPLS domain 1 GMPLS domain 2 GMPLS domain 3
Figure 1: Example of GMPLS interworks with Controllers Figure 1: Example of GMPLS/non-GMPLS interworks with Controllers
In Figure 1, each domain has the GMPLS control plane enabled at the Figure 1 shows the scenario with two GMPLS domains and one non-GMPLS
physical network level. The PNC can exploit GMPLS capability domain. This system supports the interworking among non-GMPLS
domain, GMPLS domain and the controller hierarchies. For domain 1,
the network element were not enabled with GMPLS so the control can
be purely from the controller, via Netconf/YANG and/or PCEP. For
domain 2 and 3, each domain has the GMPLS control plane enabled at
the physical network level. The PNC can exploit GMPLS capability
implemented in the domain to listen to the IGP routing protocol implemented in the domain to listen to the IGP routing protocol
messages (OSPF LSAs for example) that the GMPLS control plane messages (OSPF LSAs for example) that the GMPLS control plane
instances are disseminating into the network and thus learn the instances are disseminating into the network and thus learn the
network topology. For path computation in the domain with PNC network topology. For path computation in the domain with PNC
implementing a PCE, PCCs (e.g. NEs, other controller/PCE) use PCEP implementing a PCE, PCCs (e.g. NEs, other controller/PCE) use PCEP
to ask the PNC for a path and get replies. The MDSC communicates to ask the PNC for a path and get replies. The MDSC communicates
with PNCs using for example REST/RESTConf based on YANG data models. with PNCs using for example REST/RESTConf based on YANG data models.
As a PNC has learned its domain topology, it can report the topology As a PNC has learned its domain topology, it can report the topology
to the MDSC. When a service arrives, the MDSC computes the path and to the MDSC. When a service arrives, the MDSC computes the path and
coordinates PNCs to establish the corresponding LSP segment. coordinates PNCs to establish the corresponding LSP segment.
skipping to change at page 6, line 14 skipping to change at page 6, line 20
specific network technology. The PNC can retrieve topology specific network technology. The PNC can retrieve topology
information from any NE (the GMPLS control plane instance of each NE information from any NE (the GMPLS control plane instance of each NE
in the domain has the same topological view), construct the topology in the domain has the same topological view), construct the topology
of the domain and export an abstracted view to the MDSC. Based on of the domain and export an abstracted view to the MDSC. Based on
the topology retrieved from multiple PNCs, the MDSC can create the topology retrieved from multiple PNCs, the MDSC can create
topology graph of the multi-domain network, and can use it for path topology graph of the multi-domain network, and can use it for path
computation. To setup a service, the MDSC can exploit e.g.[TE- computation. To setup a service, the MDSC can exploit e.g.[TE-
Tunnel] Yang model together with the technology-specific YANG model Tunnel] Yang model together with the technology-specific YANG model
augmentations. augmentations.
3. Link Management Protocol 3. Discovery Options
In GMPLS control, the link connectivity need to be verified between
each pair of nodes. In this way, link resources, which are
fundamental resources in the network, are discovered by both ends of
the link.
3.1. LMP
Link management protocol (LMP) [RFC4204] runs between a pair of Link management protocol (LMP) [RFC4204] runs between a pair of
nodes and is used to manage TE links. In addition to the setup and nodes and is used to manage TE links. In addition to the setup and
maintenance of control channels, LMP can be used to verify the data maintenance of control channels, LMP can be used to verify the data
link connectivity and correlate the link property. In this way, link link connectivity and correlate the link property.
resources, which are fundamental resources in the network, are
discovered by both ends of the link.
4. Routing Options 4. Routing Options
In GMPLS control, link state information is flooded within the In GMPLS control, link state information is flooded within the
network as defined in [RFC4202]. Each node in the network can build network as defined in [RFC4202]. Each node in the network can build
the network topology according to the flooded link state the network topology according to the flooded link state
information. Routing protocols such as OSPF-TE [RFC4203] and ISIS-TE information. Routing protocols such as OSPF-TE [RFC4203] and ISIS-TE
[RFC5307] have been extended to support different interfaces in [RFC5307] have been extended to support different interfaces in
GMPLS. GMPLS.
skipping to change at page 9, line 9 skipping to change at page 9, line 18
When there are changes in the network topology, the impacted network When there are changes in the network topology, the impacted network
element(s) need to report changes to all the other network elements, element(s) need to report changes to all the other network elements,
together with the controller, to sync up the topology information. together with the controller, to sync up the topology information.
The inter-NE synchronization can be achieved via protocols mentioned The inter-NE synchronization can be achieved via protocols mentioned
in section 3 and 4. The topology synchronization between NEs and in section 3 and 4. The topology synchronization between NEs and
controllers can either be achieved by routing protocols OSPF- controllers can either be achieved by routing protocols OSPF-
TE/PCEP-LS in [PCEP-LS] or Netconf protocol notifications with YANG TE/PCEP-LS in [PCEP-LS] or Netconf protocol notifications with YANG
model. model.
7.2. Multi-domain/layer Service Provisioning 7.2. Multi-domain Service Provisioning
Based on the topology information on controllers and network Based on the topology information on controllers and network
elements, service provisioning can be deployed. Plenty of methods elements, service provisioning can be deployed. Plenty of methods
have been specified for single domain service provisioning, such as have been specified for single domain service provisioning, such as
using PCEP and RSVP-TE. using PCEP and RSVP-TE.
Multi-domain/layer service provisioning would request coordination Multi-domain service provisioning would request coordination among
among the controller hierarchies. Given the service request, the the controller hierarchies. Given the service request, the end-to-
end-to-end delivery procedure may include interactions at any level end delivery procedure may include interactions at any level (i.e.
(i.e. interface) in the hierachy of the controllers (e.g. MPI and interface) in the hierachy of the controllers (e.g. MPI and SBI for
SBI for ACTN). The computation for a cross-domain/layer path is ACTN). The computation for a cross-domain path is usually completed
usually completed by controllers who have a global view of the by controllers who have a global view of the topologies. Then the
topologies. Then the configuration is decomposed into lower layer configuration is decomposed into lower layer controllers, to
controllers, to configure the network elements to set up the path. configure the network elements to set up the path.
A combination of the centralized and distributed protocols may be A combination of the centralized and distributed protocols may be
necessary for the interaction between network elements and necessary for the interaction between network elements and
controller. A typical example would be the PCE Initiation scenario, controller. Several methods can be used to create the inter-domain
in which a PCE message (PCInitiate) is sent from the controller to path:
the first-end node, and then trigger a RSVP procedure along the
path. Similarly, the interaction between the controller and the
ingress node of a domain can be achieved by Netconf protocol with
corresponding YANG models, and then completed by running RSVP among
the network elements.
7.3. Recovery 1) One end-to-end RSVP-TE session:
In this method, an end-to-end RSVP-TE session from the source NE to
the destination NE will be used to create the inter-domain path. A
typical example would be the PCE Initiation scenario, in which a PCE
message (PCInitiate) is sent from the controller to the first-end
node, and then trigger a RSVP procedure along the path. Similarly,
the interaction between the controller and the ingress node of a
domain can be achieved by Netconf protocol with corresponding YANG
models, and then completed by running RSVP among the network
elements.
This method requires the interworking of RSVP-TE protocols between
different domains.
2) Multiple RSVP-TE sessions for multiple path segments:
In this method, each SDN controller is responsible to create the
path segment within its domain.
Note that path segments in the source domain and the destination
domain are "asymmetrical" segments, because the configuration of
client signal mapping into server layer tunnel is needed at only one
end of the segment, while configuration of server layer cross-
connect is needed at the other end of the segment. For example, the
path segment 1 and 3 in Figure 3 are asymmetrical segments, because
one end of the segment requires mapping GE into ODU0, while the
other end of the segment requires setting up ODU0 cross-connect.
+-----------------+ +----------------+ +-----------------+
|Client | | | | Client|
|Signal Domain 1| | Domain 2 | |Domain 3 Signal|
|(GE) | | | | (GE) |
| | ODU0 tunnel| | | | | |
|+-+-+ ^ | | | | +-+-+|
|| | | +--+ |+--+| |+--+ +--+ +--+| |+--+ +--+ | | ||
|| | | | | || || || | | | | || || | | | | | ||
|| ******************************************************** ||
|| | | | | || . || | | | | || . || | | | | ||
|+---+ +--+ +--+| . |+--+ +--+ +--+| . |+--+ +--+ +---+|
+-----------------+ . +----------------+ . +-----------------+
. . . .
.<-Path Segment 1->.<--Path Segment 2-->.<-Path Segment 3->.
. . . .
Figure 3: Example of asymmetrical path segment
The PCEP / GMPLS protocols should support creation of such
asymmetrical segment.
Note also that mechanisms to assign the labels in the inter-domain
links are also needed to be considered. There are two possible
methods:
2.1) Inter-domain labels assigned by NEs:
The concept of Stitching Label that allows stitching local path
segments was introduced in [RFC5150] and [sPCE-ID], in order to form
the inter-domain path crossing several different domains. It also
describes the BRPC and H-PCE PCInitiate procedure, i.e., the ingress
boarder node of each downstream domain assigns the stitching label
for the inter-domain link between the downstream domain and its
upstream neighbor domain, and this stitching label will be passed to
the upstream neighbor domain by PCE protocol, which will be used for
the path segment creation in the upstream neighbor domain.
2.2) Inter-domain labels assigned by SDN controller:
If the resource of inter-domain links are managed by the multi-
domain SDN controller, each single-domain SDN controller can provide
to the multi-domain SDN controller the list of available labels
(e.g. timeslots if OTN is the scenario) using IETF Topology model
and related technology specific extension. Once that multi-domain
SDN controller has computed e2e path RSVP-TE or PCEP can be used in
the different domains to setup related segment tunnel consisting
with label inter-domain information, e.g. for PCEP the label ERO can
be included in the PCInitiate message to indicate the inter-domain
labels, so that each boarder node of each domain can configure the
correct cross-connect within itself.
7.3. Multi-layer Service Provisioning
For further study. Plan to be updated in the next version.
7.4. Recovery
The GMPLS recovery functions are described in [RFC4426]. Two models, The GMPLS recovery functions are described in [RFC4426]. Two models,
span protection and end-to-end protection and restoration, are span protection and end-to-end protection and restoration, are
discussed with different protection schemes and message exchange discussed with different protection schemes and message exchange
requirements. Related RSVP-TE extensions to support end-to-end requirements. Related RSVP-TE extensions to support end-to-end
recovery is described in [RFC4872]. The extensions in [RFC4872] recovery is described in [RFC4872]. The extensions in [RFC4872]
include protection, restoration, preemption, and rerouting include protection, restoration, preemption, and rerouting
mechanisms for an end-to-end LSP. Besides end-to-end recovery, a mechanisms for an end-to-end LSP. Besides end-to-end recovery, a
GMPLS segment recovery mechanism is defined in [RFC4873]. By GMPLS segment recovery mechanism is defined in [RFC4873]. By
introducing secondary record route objects, LSP segment can be introducing secondary record route objects, LSP segment can be
switched to another path like fast reroute [RFC4090]. switched to another path like fast reroute [RFC4090].
For the recovery with controllers, timely interaction between For the recovery with controllers, timely interaction between
controller and network elements are required. Usually the re-routing controller and network elements are required. Usually the re-routing
can be decomposed into path computation and delivery, the controller can be decomposed into path computation and delivery, the controller
can take some advantage in the path computation due to the global can take some advantage in the path computation due to the global
topology view. And the delivery can be achieved by the procedure topology view. And the delivery can be achieved by the procedure
described in section 7.2. described in section 7.2.
7.4. Controller Reliability 7.5. Controller Reliability
Given the important role in the network, the reliability of Given the important role in the network, the reliability of
controller is critical. Once a controller is shut down, the network controller is critical. Once a controller is shut down, the network
should operate as well. It can be either achieved by controller back should operate as well. It can be either achieved by controller back
up or functionality back up. There are several of controller backup up or functionality back up. There are several of controller backup
or federation mechanisms in the literature. It is also more reliable or federation mechanisms in the literature. It is also more reliable
to have some function back up in the network element, to guarantee to have some function back up in the network element, to guarantee
the performance in the network. the performance in the network.
8. Manageability Considerations 8. Manageability Considerations
skipping to change at page 12, line 19 skipping to change at page 14, line 14
[RFC8040] Bierman, A., Bjorklund, M., Watsen, K., "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., Watsen, K., "RESTCONF
Protocol", RFC 8040, January 2017. Protocol", RFC 8040, January 2017.
[RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and [RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and
Control of Traffic Engineered Networks", RFC 8453, August Control of Traffic Engineered Networks", RFC 8453, August
2018. 2018.
11.2. Informative References 11.2. Informative References
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003. 3471, January 2003.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005. May 2005.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005. (GMPLS)", RFC 4202, October 2005.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005. 4204, October 2005.
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D.
Papadimitriou, Ed., "Generalized Multi-Protocol Label Papadimitriou, Ed., "Generalized Multi-Protocol Label
witching (GMPLS) Recovery Functional Specification", RFC witching (GMPLS) Recovery Functional Specification", RFC
4426, March 2006. 4426, March 2006.
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, J.P., Farrel, A.,
"Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering (GMPLS
TE)", RFC 5150, February, 2008.
[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
J. Drake, "Traffic Engineering Extensions to OSPF for J. Drake, "Traffic Engineering Extensions to OSPF for
GMPLS Control of Evolving G.709 Optical Transport GMPLS Control of Evolving G.709 Optical Transport
Networks", RFC 7138, March 2014. Networks", RFC 7138, March 2014.
[RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
and K. Pithewan, "GMPLS Signaling Extensions for Control and K. Pithewan, "GMPLS Signaling Extensions for Control
of Evolving G.709 Optical Transport Networks", RFC 7139, of Evolving G.709 Optical Transport Networks", RFC 7139,
March 2014. March 2014.
skipping to change at page 14, line 5 skipping to change at page 16, line 5
yang-path-computation-04, work in progress. yang-path-computation-04, work in progress.
[PCEP-LS] Dhody, D., Lee, Y., Ceccarelli, D., "PCEP Extensions for [PCEP-LS] Dhody, D., Lee, Y., Ceccarelli, D., "PCEP Extensions for
Distribution of Link-State and TE Information", draft- Distribution of Link-State and TE Information", draft-
dhodylee-pce-pcep-ls, work in progress. dhodylee-pce-pcep-ls, work in progress.
[TE-Tunnel] Saad, T. et al., "A YANG Data Model for Traffic [TE-Tunnel] Saad, T. et al., "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", draft-ietf-teas-yang- Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
te, work in progress. te, work in progress.
[sPCE-ID] Dugeon, O. et al., "PCEP Extension for Stateful Inter-
Domain Tunnels", draft-dugeon-pce-stateful-interdomain,
work in progress.
12. Authors' Addresses 12. Authors' Addresses
Haomian Zheng Haomian Zheng
Huawei Technologies Huawei Technologies
F3 R&D Center, Huawei Industrial Base, F3 R&D Center, Huawei Industrial Base,
Bantian, Longgang District, Bantian, Longgang District,
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Xianlong Luo Xianlong Luo
skipping to change at page 14, line 27 skipping to change at page 16, line 31
Bantian, Longgang District, Bantian, Longgang District,
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Email: luoxianlong@huawei.com Email: luoxianlong@huawei.com
Yunbin Xu Yunbin Xu
CAICT CAICT
Email: xuyunbin@ritt.cn Email: xuyunbin@ritt.cn
Yang Zhao Yang Zhao
China Mobile China Mobile
Email: zhaoyangyjy@chinamobile.com Email: zhaoyangyjy@chinamobile.com
Sergio Belotti Sergio Belotti
Nokia Nokia
Email: sergio.belotti@nokia.com Email: sergio.belotti@nokia.com
Dieter Beller Dieter Beller
Nokia Nokia
Email: Dieter.Beller@nokia.com Email: Dieter.Beller@nokia.com
 End of changes. 21 change blocks. 
95 lines changed or deleted 194 lines changed or added

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