draft-ietf-pce-stateful-pce-15.txt   draft-ietf-pce-stateful-pce-16.txt 
PCE Working Group E. Crabbe PCE Working Group E. Crabbe
Internet-Draft Individual Contributor Internet-Draft Oracle
Intended status: Standards Track I. Minei Intended status: Standards Track I. Minei
Expires: January 19, 2017 Google, Inc. Expires: March 5, 2017 Google, Inc.
J. Medved J. Medved
Cisco Systems, Inc. Cisco Systems, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
July 18, 2016 September 1, 2016
PCEP Extensions for Stateful PCE PCEP Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-15 draft-ietf-pce-stateful-pce-16
Abstract Abstract
The Path Computation Element Communication Protocol (PCEP) provides The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests. computations in response to Path Computation Clients (PCCs) requests.
Although PCEP explicitly makes no assumptions regarding the Although PCEP explicitly makes no assumptions regarding the
information available to the PCE, it also makes no provisions for PCE information available to the PCE, it also makes no provisions for PCE
control of timing and sequence of path computations within and across control of timing and sequence of path computations within and across
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 19, 2017. This Internet-Draft will expire on March 5, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 44 skipping to change at page 2, line 44
5.6. State Synchronization . . . . . . . . . . . . . . . . . . 12 5.6. State Synchronization . . . . . . . . . . . . . . . . . . 12
5.7. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 15 5.7. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 15
5.7.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15 5.7.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15
5.7.2. Revoking a Delegation . . . . . . . . . . . . . . . . 16 5.7.2. Revoking a Delegation . . . . . . . . . . . . . . . . 16
5.7.3. Returning a Delegation . . . . . . . . . . . . . . . 18 5.7.3. Returning a Delegation . . . . . . . . . . . . . . . 18
5.7.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 18 5.7.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 18
5.7.5. Redelegation on PCE Failure . . . . . . . . . . . . . 19 5.7.5. Redelegation on PCE Failure . . . . . . . . . . . . . 19
5.8. LSP Operations . . . . . . . . . . . . . . . . . . . . . 19 5.8. LSP Operations . . . . . . . . . . . . . . . . . . . . . 19
5.8.1. Passive Stateful PCE Path Computation 5.8.1. Passive Stateful PCE Path Computation
Request/Response . . . . . . . . . . . . . . . . . . 19 Request/Response . . . . . . . . . . . . . . . . . . 19
5.8.2. Active Stateful PCE LSP Update . . . . . . . . . . . 21 5.8.2. Switching from Passive Stateful to Active Stateful . 21
5.8.3. Active Stateful PCE LSP Update . . . . . . . . . . . 22
5.9. LSP Protection . . . . . . . . . . . . . . . . . . . . . 23 5.9. LSP Protection . . . . . . . . . . . . . . . . . . . . . 23
5.10. PCEP Sessions . . . . . . . . . . . . . . . . . . . . . . 23 5.10. PCEP Sessions . . . . . . . . . . . . . . . . . . . . . . 23
6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 23 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 23 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 24
6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 25 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 26
6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 27 6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 28
6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 28 6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 29
6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 29 6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 30
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 30
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 29 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 29 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 30
7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 29 7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . 31
7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . 30 7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 33
7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 32 7.3.1. LSP-IDENTIFIERS TLVs . . . . . . . . . . . . . . . . 35
7.3.1. LSP-IDENTIFIERS TLVs . . . . . . . . . . . . . . . . 34 7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . 38
7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . 37 7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . 39
7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . 38 7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 39
7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 38 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 8.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 40
8.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 39 8.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 41
8.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 40 8.3. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 41
8.3. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 40 8.4. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 41
8.4. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 40 8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 42
8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 41 8.6. Notification Object . . . . . . . . . . . . . . . . . . . 42
8.6. Notification Object . . . . . . . . . . . . . . . . . . . 41 8.7. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 43
8.7. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 42 8.8. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 43
8.8. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 42 8.9. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . 43
8.9. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . 42 9. Manageability Considerations . . . . . . . . . . . . . . . . 44
9. Manageability Considerations . . . . . . . . . . . . . . . . 43 9.1. Control Function and Policy . . . . . . . . . . . . . . . 44
9.1. Control Function and Policy . . . . . . . . . . . . . . . 43 9.2. Information and Data Models . . . . . . . . . . . . . . . 45
9.2. Information and Data Models . . . . . . . . . . . . . . . 44 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 45
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 44 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 45
9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 44 9.5. Requirements on Other Protocols and Functional Components 46
9.5. Requirements on Other Protocols and Functional Components 45 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 46
9.6. Impact on Network Operation . . . . . . . . . . . . . . . 45 10. Security Considerations . . . . . . . . . . . . . . . . . . . 46
10. Security Considerations . . . . . . . . . . . . . . . . . . . 45 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . 46
10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . 45 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . 47
10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . 46 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . 47
10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . 46 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . 48
10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . 47 11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 48
11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 47 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 13.1. Normative References . . . . . . . . . . . . . . . . . . 49
13.1. Normative References . . . . . . . . . . . . . . . . . . 48 13.2. Informative References . . . . . . . . . . . . . . . . . 50
13.2. Informative References . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element Communication [RFC5440] describes the Path Computation Element Communication
Protocol (PCEP). PCEP defines the communication between a Path Protocol (PCEP). PCEP defines the communication between a Path
Computation Client (PCC) and a Path Computation Element (PCE), or Computation Client (PCC) and a Path Computation Element (PCE), or
between PCEs, enabling computation of Multiprotocol Label Switching between PCEs, enabling computation of Multiprotocol Label Switching
(MPLS) for Traffic Engineering Label Switched Path (TE LSP) (MPLS) for Traffic Engineering Label Switched Path (TE LSP)
characteristics. Extensions for support of Generalized MPLS (GMPLS) characteristics. Extensions for support of Generalized MPLS (GMPLS)
in PCEP are defined in [I-D.ietf-pce-gmpls-pcep-extensions] in PCEP are defined in [I-D.ietf-pce-gmpls-pcep-extensions]
skipping to change at page 12, line 52 skipping to change at page 12, line 52
During State Synchronization, a PCC first takes a snapshot of the During State Synchronization, a PCC first takes a snapshot of the
state of its LSPs state, then sends the snapshot to a PCE in a state of its LSPs state, then sends the snapshot to a PCE in a
sequence of LSP State Reports. Each LSP State Report sent during sequence of LSP State Reports. Each LSP State Report sent during
State Synchronization has the SYNC Flag in the LSP Object set to 1. State Synchronization has the SYNC Flag in the LSP Object set to 1.
The set of LSPs for which state is synchronized with a PCE is The set of LSPs for which state is synchronized with a PCE is
determined by advertised stateful PCEP capabilities and PCC's local determined by advertised stateful PCEP capabilities and PCC's local
configuration (see more details in Section 9.1). configuration (see more details in Section 9.1).
The end of synchronization marker is a PCRpt message with the SYNC The end of synchronization marker is a PCRpt message with the SYNC
Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved
value 0 (see Section 7.3). The LSP Object does not include the value 0 (see Section 7.3). In this case, the LSP Object SHOULD NOT
SYMBOLIC-PATH-NAME TLV in this case, it will include an empty ERO as include the SYMBOLIC-PATH-NAME TLV and SHOULD include the LSP-
its intended path and will not include the optional RRO object in the IDENTIFIERS TLV with the special value of all zeroes. The PCRpt
path. If the PCC has no state to synchronize, it will only send the message MUST include an empty ERO as its intended path and SHOULD NOT
end of synchronization marker. include the optional RRO object for its actual path. If the PCC has
no state to synchronize, it SHOULD only send the end of
synchronization marker.
A PCE SHOULD NOT send PCUpd messages to a PCC before State A PCE SHOULD NOT send PCUpd messages to a PCC before State
Synchronization is complete. A PCC SHOULD NOT send PCReq messages to Synchronization is complete. A PCC SHOULD NOT send PCReq messages to
a PCE before State Synchronization is complete. This is to allow the a PCE before State Synchronization is complete. This is to allow the
PCE to get the best possible view of the network before it starts PCE to get the best possible view of the network before it starts
computing new paths. computing new paths.
Either the PCE or the PCC MAY terminate the session using the PCEP Either the PCE or the PCC MAY terminate the session using the PCEP
session termination procedures during the synchronization phase. If session termination procedures during the synchronization phase. If
the session is terminated, the PCE MUST clean up state it received the session is terminated, the PCE MUST clean up state it received
skipping to change at page 21, line 27 skipping to change at page 21, line 27
A PCC MUST send each LSP State Report to each stateful PCE that is A PCC MUST send each LSP State Report to each stateful PCE that is
connected to the PCC. connected to the PCC.
Note that a single PCRpt message MAY contain multiple LSP State Note that a single PCRpt message MAY contain multiple LSP State
Reports. Reports.
The passive stateful PCE is the model for stateful PCEs is described The passive stateful PCE is the model for stateful PCEs is described
in [RFC4655], Section 6.8. in [RFC4655], Section 6.8.
5.8.2. Active Stateful PCE LSP Update 5.8.2. Switching from Passive Stateful to Active Stateful
This section deals with the scenario of an LSP transitioning from a
passive stateful to an active stateful mode of operation. When the
LSP has no working path, prior to delegating the LSP, the PCC MUST
first use the procedure defined in Section 5.8.1 to request the
initial path from the PCE. This is required because the action of
delegating the LSP to a PCE using a PCRpt message is not an explicit
request to the PCE to compute a path for the LSP. The only explicit
way for a PCC to request a path from PCE is to send a PCReq message.
The PCRpt message MUST NOT be used by the PCC to attempt to request a
path from the PCE.
When the LSP is delegated after its setup, it may be useful for the
PCC to communicate to the PCE the locally configured intended
configuration parameters, so that the PCE may reuse them in its
computations. Such parameters MAY be acquired through an out of band
channel, or MAY be communicated in the PCRpt message delegating the
LSPs, by including them as part of the intented-attribute-list as
explained in Section 6.1. An implementation MAY allow policies on
the PCC to determine the configuration parameters to be sent to the
PCE.
5.8.3. Active Stateful PCE LSP Update
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
1) LSP State |-- PCRpt, Delegate=1 -->| 1) LSP State |-- PCRpt, Delegate=1 -->|
Synchronization | . | Synchronization | . |
| . |2) PCE decides to | . |2) PCE decides to
| . | update the LSP | . | update the LSP
| | | |
skipping to change at page 24, line 5 skipping to change at page 24, line 17
A Path Computation LSP State Report message (also referred to as A Path Computation LSP State Report message (also referred to as
PCRpt message) is a PCEP message sent by a PCC to a PCE to report the PCRpt message) is a PCEP message sent by a PCC to a PCE to report the
current state of an LSP. A PCRpt message can carry more than one LSP current state of an LSP. A PCRpt message can carry more than one LSP
State Reports. A PCC can send an LSP State Report either in response State Reports. A PCC can send an LSP State Report either in response
to an LSP Update Request from a PCE, or asynchronously when the state to an LSP Update Request from a PCE, or asynchronously when the state
of an LSP changes. The Message-Type field of the PCEP common header of an LSP changes. The Message-Type field of the PCEP common header
for the PCRpt message is to be assigned by IANA. for the PCRpt message is to be assigned by IANA.
The format of the PCRpt message is as follows: The format of the PCRpt message is as follows:
<PCRpt Message> ::= <Common Header> <PCRpt Message> ::= <Common Header>
<state-report-list> <state-report-list>
Where: Where:
<state-report-list> ::= <state-report>[<state-report-list>] <state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>] <state-report> ::= [<SRP>]
<LSP> <LSP>
<path> <path>
Where: Where:
<path>::= <intended_path><attribute-list>[<actual_path>] <path>::= <intended_path>
[<actual_attribute_list><actual_path>]
<intended_attribute_list>
Where: <actual_attribute-list>::=[<BANDWIDTH>]
<intended_path> is represented by the ERO object defined in [<metric-list>]
section 7.9 of [RFC5440].
<attribute-list> is defined in [RFC5440] and extended by Where:
PCEP extensions. <intended_path> is represented by the ERO object defined in
<actual_path> is represented by the RRO object defined in section 7.9 of [RFC5440].
section 7.10 of [RFC5440]. <actual_attribute_list> consists of the actual computed and signaled values
of the <BANDWIDTH> and <metric-lists> objects defined in [RFC5440].
<actual_path> is represented by the RRO object defined in
section 7.10 of [RFC5440].
<intended_attribute_list> is the attribute-list defined in
section 6.5 of [RFC5440] and extended by PCEP extensions.
The SRP object (see Section 7.2) is OPTIONAL. If the PCRpt message The SRP object (see Section 7.2) is OPTIONAL. If the PCRpt message
is not in response to a PCupd message, the SRP object MAY be omitted. is not in response to a PCupd message, the SRP object MAY be omitted.
When the PCC does not include the SRP object, the PCE MUST treat this When the PCC does not include the SRP object, the PCE MUST treat this
as an SRP object with an SRP-ID-number equal to the reserved value as an SRP object with an SRP-ID-number equal to the reserved value
0x00000000. The reserved value 0x00000000 indicates that the state 0x00000000. The reserved value 0x00000000 indicates that the state
reported is not as a result of processing a PCUpd message. reported is not as a result of processing a PCUpd message.
If the PCRpt message is in response to a PCUpd message, the SRP If the PCRpt message is in response to a PCUpd message, the SRP
object MUST be included and the value of the SRP-ID-number in the SRP object MUST be included and the value of the SRP-ID-number in the SRP
skipping to change at page 25, line 9 skipping to change at page 25, line 25
The LSP object (see Section 7.3) is REQUIRED, and it MUST be included The LSP object (see Section 7.3) is REQUIRED, and it MUST be included
in each LSP State Report on the PCRpt message. If the LSP object is in each LSP State Report on the PCRpt message. If the LSP object is
missing, the receiving PCE MUST send a PCErr message with Error- missing, the receiving PCE MUST send a PCErr message with Error-
type=6 (Mandatory Object missing) and Error-value to be assigned by type=6 (Mandatory Object missing) and Error-value to be assigned by
IANA (LSP object missing). IANA (LSP object missing).
If the LSP transitioned to non-operational state, the PCC SHOULD If the LSP transitioned to non-operational state, the PCC SHOULD
include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error
Code to report the error to the PCE. Code to report the error to the PCE.
The intended path, represented by the ERO object, is REQUIRED. If
the ERO ojbect is missing, the receiving PCE MUST send a PCErr
message with Error-type=6 (Mandatory Object missing) and Error-value
to be assigned by IANA (ERO object missing). The ERO may be empty if
the PCE does not have a path for a delegated LSP.
The actual path, represented by the RRO object, SHOULD be included in The actual path, represented by the RRO object, SHOULD be included in
PCRpt by the PCC when the path is up or active, but MAY be omitted if PCRpt by the PCC when the path is up or active, but MAY be omitted if
the path is down due to a signaling error or another failure. the path is down due to a signaling error or another failure.
The intended_attribute_list maps to the attribute_list in Section 6.5
of [RFC5440] and is used to convey the requested parameters of the
LSP path. This is needed in order to support the switch from passive
to active stateful PCE as described in Section 5.8.2. When included
as part of the intended_attribute_list, the meaning of the BANDWIDTH
object is the requested bandwidth as intended by the operator. In
this case, the BANDWIDTH Object-Type of 1 SHOULD be used. Similarly,
to indicate a limiting constraint, the METRIC object SHOULD be
included as part of the intended_attribute_list with the B flag set
and with a specific metric value. To indicate the optimization
metric, the METRIC object SHOULD be included as part of the
intended_attribute_list with the B flag unset and the metric value
set to zero. Note that the intended_attribute_list is optional and
thus may be omitted. In this case, the PCE MAY use the values in the
actual_attribute_list as the requested parameters for the path.
The actual_attribute_list consists of the actual computed and
signaled values of the BANDWIDTH and METRIC objects defined in
[RFC5440]. When included as part of the actual_attribute_list,
Object-Type 2 ([RFC5440]) SHOULD be used for the BANDWIDTH object and
the C flag SHOULD be set in the METRIC object ([RFC5440]).
A PCE may choose to implement a limit on the resources a single PCC A PCE may choose to implement a limit on the resources a single PCC
can occupy. If a PCRpt is received that causes the PCE to exceed can occupy. If a PCRpt is received that causes the PCE to exceed
this limit, the PCE MUST notify the PCC using a PCNtf message with this limit, the PCE MUST notify the PCC using a PCNtf message with
Notification Type to be allocated by IANA (Stateful PCE resource Notification Type to be allocated by IANA (Stateful PCE resource
limit exceeded) and Notification Value to be allocated by IANA limit exceeded) and Notification Value to be allocated by IANA
(Entering resource limit exceeded state) and MAY terminate the (Entering resource limit exceeded state) and MAY terminate the
session. session.
6.2. The PCUpd Message 6.2. The PCUpd Message
skipping to change at page 50, line 43 skipping to change at page 51, line 43
2008, <http://www.rfc-editor.org/info/rfc5305>. 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394, "Policy-Enabled Path Computation Framework", RFC 5394,
DOI 10.17487/RFC5394, December 2008, DOI 10.17487/RFC5394, December 2008,
<http://www.rfc-editor.org/info/rfc5394>. <http://www.rfc-editor.org/info/rfc5394>.
Authors' Addresses Authors' Addresses
Edward Crabbe Edward Crabbe
Individual Contributor Oracle
1501 4th Ave, suite 1800
Seattle, WA 98101
US
Email: edward.crabbe@gmail.com Email: edward.crabbe@oracle.com
Ina Minei Ina Minei
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: inaminei@google.com Email: inaminei@google.com
Jan Medved Jan Medved
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 17 change blocks. 
73 lines changed or deleted 136 lines changed or added

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