One document matched: draft-dhody-pce-stateful-pce-lspdb-realtime-sync-00.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc ipr="trust200902" category="std" docName="draft-dhody-pce-stateful-pce-lspdb-realtime-sync-00" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="REALTIME-SYNC">Realtime Synchronization between Redundant Stateful PCEs.</title>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Divyasree Techno Park, Whitefield</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560066</code>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</author>
<date month="June" year="2016" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>The Path Computation Element Communication Protocol (PCEP)
provides mechanisms for Path Computation Elements (PCEs) to
perform path computations in response to Path Computation
Clients (PCCs) requests.</t>
<t><xref target='I-D.ietf-pce-stateful-pce'></xref> specifies a set of extensions
to PCEP to enable stateful control of MPLS-TE and GMPLS Label
Switched Paths (LSPs) via PCEP and maintaining of these LSPs
at the stateful PCE. This document describes the mechanisms
of realtime LSP Database (LSP-DB) synchronization between stateful
PCEs.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t><xref target="RFC5440"/> describes the Path Computation
Element Protocol (PCEP) as the communication between a Path
Computation Client (PCC) and a Path Computation Element (PCE),
or between PCEs, enabling computation of Multiprotocol Label
Switching (MPLS) for Traffic Engineering Label Switched Paths
(TE LSPs).</t>
<t><xref target='I-D.ietf-pce-stateful-pce'></xref> specifies a set of extensions
to PCEP to enable stateful control of LSPs in compliance with
<xref target="RFC4655"/>. It includes mechanisms for LSP state
synchronization between a PCC and a PCE, i.e., all stateful PCEs
synchronize their LSP states from the network.
It further describe the handling of redundant stateful PCEs,
where all PCEs receive the state from the network (PCCs). When
the primary PCE fails, another PCE can take over.</t>
<t>Apart from the synchronization from the network, it is also
useful if there is realtime synchronization mechanism between the
stateful PCEs. As stateful PCE make changes to
its delegated LSPs, these changes (pending LSPs and the sticky
resources) can be synchronized immediately to the other PCEs.
Further PCE may also synchronize any status change of its
delegated LSPs to other PCEs. Note that some synchronization
issues are identified in <xref target="RFC7399"/>.</t>
<t>It should be noted that in some deployments the PCE function is
part of the central controller architecture with multiple instances of
PCE for load balancing and backup which uses proprietary mechanics to
maintain consistent state between these PCE instance. In such deployment
PCEP MAY not used as a database synchronization mechanism. </t>
<t>This document specifies the mechanisms of realtime LSP-DB synchronization
between redundant stateful PCEs via PCEP.</t>
<section title="Requirements Language" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="Terminology" toc="default">
<t>The terminology is as per <xref target="RFC5440"/> and <xref target='I-D.ietf-pce-stateful-pce'></xref>.</t>
<t>
<list style="hanging">
<t hangText="LSP-DB:">A database of LSPs that are active
in the network as maintained by a stateful PCE.</t>
<t hangText="Sticky Resources:">The temporarily assigned
resources that are allocated to a pending LSP and are
provisionally blocked.</t>
</list>
</t>
</section>
<section title="Architectural Considerations" toc="default">
<t>Distributed computation model (<xref target="RFC4655"/>) refers to
a domain or network that may include multiple PCEs where computation of
paths is shared among the PCEs, this is further clarified in
<xref target="RFC7399"/>.</t>
<t>When multiple stateful PCEs are operating in the network, they could
be either - </t>
<t>
<list style="hanging">
<t hangText="Primary or Backup PCE:">A backup PCE exists to perform
functions in the network, only in the event of a failure of the primary
PCE. In this case, all LSPs to be delegated are under primary stateful
PCE control while other PCEs in the domain act as backup.</t>
<t hangText="Load-Balanced 'Backup' PCE:">Load-Balanced PCEs share the
computation load at all times, as well as act backup to each other.
One PCE MAY serve a set of PCCs as the primary computation server,
and only addresses requests from other PCCs in the event of the
failure of some other PCE. Delegated LSPs are thus distributed
among stateful PCEs.</t>
</list>
</t>
<t>In either case it is beneficial for the PCE to synchronize changes
of its delegated LSPs to the other PCEs in realtime. This should include -
<list style="symbols">
<t>Any update made by the PCE to its delegated LSP.</t>
<t>Any status change learned from the network.</t>
</list>
</t>
<t>Note that the state synchronization as per <xref target='I-D.ietf-pce-stateful-pce'></xref> and <xref target='I-D.ietf-pce-stateful-sync-optimizations'></xref>remains unchanged.
This include initial state synchronization as well as LSP state reports. The mechanism described
in this document are in addition to those already present in <xref target='I-D.ietf-pce-stateful-pce'></xref>.</t>
</section>
<section title="Functions to Support LSP-DB Synchronization" toc="default" anchor="SEC_F">
<t><xref target='I-D.ietf-pce-stateful-pce'></xref> specifies new functions to support a
stateful PCE. It also specifies that a function can be initiated either
from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C).</t>
<t>
<list style="symbols">
<t>Capability negotiation (E-C,C-E)</t>
<t>LSP state synchronization (C-E)</t>
<t>LSP update request (E-C)</t>
<t>LSP state report (C-E)</t>
<t>LSP control delegation (C-E,E-C)</t>
<t>Stateful PCE discovery via <xref target="I-D.sivabalan-pce-disco-stateful"/></t>
</list>
</t>
<t>This document extends some of these functions to support
realtime LSP-DB synchronization. These are initiated from a
PCE towards another PCE (E-E). </t>
<t>
<list style="hanging">
<t hangText="Capability negotiation (E-E):">both the PCEs must announce
during PCEP session establishment that they support PCEP Stateful PCE
extensions defined in <xref target='I-D.ietf-pce-stateful-pce'></xref>. It should also
declare whether it has realtime synchronization capability between PCEs.
This is done via Open message.</t>
<t hangText="LSP state report (E-E):"> a PCE sends an LSP state report to a PCE
whenever the state of an delegated LSP changes. This is usually triggered on receiving
the state report from the PCC. This is done via PCRpt
message.</t>
<t hangText="LSP update request (E-E):">When a PCE requests modification
of attributes of a delegated LSP, this information should also be sent
to other PCEs. This is done via PCUpd message. This is needed to
synchronize the pending LSPs and sticky resources.</t>
<t hangText="Stateful PCE discovery:"> PCE can advertise its realtime synchronization
capability between PCEs via IGP.</t>
</list>
</t>
</section>
<section title="Operations" toc="default">
<section title="Relatime LSP-DB Synchronization between redundant Stateful PCEs" toc="default" anchor="SEC_redundant">
<t>PCE (including redundant stateful PCEs) learn LSP state from the PCCs.
Apart from that, for each LSP delegated to a stateful PCE -
<list style="symbols">
<t>When it sends an LSP Update (PCUpd message) to the PCC for the delegated LSP, it also sends an LSP update to other stateful PCEs.</t>
<t>When it receives an LSP report (LSRpt message) from the PCC for the delegated LSP, it also sends an LSP report to other stateful PCEs.</t>
</list></t>
<t>Thus a PCE may learn LSP state from both the PCC as well as the PCE to which LSP is delegated. </t>
<t>In <xref target="FIG_1"/>, PCE1 is the primary stateful PCE
and PCE2 is the backup stateful PCE (all LSPs are delegated to PCE1). PCC1 and PCC2 synchronize the LSP-DB
with PCE1 and PCE2 after session initialization phase. </t>
<t>PCC1 and PCC2 delegates LSP1 and LSP2 to the primary PCE1. Whenever
there is an update in LSP, PCE1 sends a PCUpd message to corresponding
PCC and also to backup PCE2. This is LSP update request as described in
<xref target="SEC_F"/> and uses PCUpd message. This makes sure that the
pending LSP changes and sticky resources are backed up. The PCC sends a
PCRpt message to the primary PCE, indicating the LSP's status, the primary
PCE further synchronizes the state with backup PCEs via PCRpt message.</t>
<figure title="Relatime LSP-DB synchronization between primary and backup stateful PCEs" suppress-title="false" align="left" alt="" width="" height="" anchor="FIG_1">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
+----+ +----+ +----+ +----+
|PCC1| |PCC2| |PCE1| |PCE2|
+-+--+ +-+--+ +-+--+ +-+--+
| | | |
|---- LSP SYNC ---+----------------->| |
| |---- LSP SYNC --->| |
| | | |
| |---- LSP SYNC ----+------------------>|
|---- LSP SYNC ---+------------------+------------------>|
| | | |
|-- PCRpt,lsp1,D -+----------------->| |
|<----------------+----PCUpd,lsp1 ---| |
| | |--- PCUpd,lsp1 --->|
|-- PCRpt,lsp1,up-+----------------->| |
|-- PCRpt,lsp1,up-+------------------+------------------>|
| | |----PCRpt,lsp1,up->|
| | | |
| |-- PCRpt,lsp2,D ->| |
| |<---PCUpd,lsp2 ---| |
| | |--- PCUpd,lsp2---->|
| |-- PCRpt,lsp2,up->| |
| |-- PCRpt,lsp2,up--+------------------>|
| | |----PCRpt,lsp2,up->|
| | | |
</artwork>
</figure>
<t>The backup PCE is used only in case the primary PCE fails. At the
time of failure of primary PCE (PCE1), the backup PCE (PCE2) act as a
primary. </t>
<t>In <xref target="FIG_2"/>, PCE1 and PCE2 are load-balanced
stateful PCEs and share the computation load as well as act as backup
to each other. PCC1 and PCC2 synchronize their LSP-DB with both PCEs
after session initialization phase as per <xref target='I-D.ietf-pce-stateful-pce'></xref>.
</t>
<t>PCC1 delegates LSP1 to PCE1. Whenever there is an update in LSP1,
PCE1 sends the PCUpd message to PCC1 and other stateful PCEs (PCE2).
Similarly, PCC2 delegates LSP2 to PCE2. Whenever there is an update
in LSP2, PCE2 sends the PCUpd message to PCC2 and other stateful PCEs
(PCE1). This is LSP update request as described in <xref target="SEC_F"/>
and it makes sure that the pending LSP changes and sticky resources are
synchronized. The PCC sends an PCRpt message to the all load-balanced
PCEs as per <xref target='I-D.ietf-pce-stateful-pce'></xref>, indicating the LSP's status.
The PCE to which LSP is delegated, also sends report message to other PCEs.</t>
<figure title="Relatime LSP-DB synchronization between load-balanced stateful PCEs" suppress-title="false" align="left" alt="" width="" height="" anchor="FIG_2">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
+----+ +----+ +----+ +----+
|PCC1| |PCC2| |PCE1| |PCE2|
+-+--+ +-+--+ +-+--+ +-+--+
| | | |
|---- LSP SYNC ---+----------------->| |
|---- LSP SYNC ---+------------------+------------------>|
| |---- LSP SYNC --->| |
| |---- LSP SYNC ----+------------------>|
| | | |
|-- PCRpt,lsp1,D -+----------------->| |
| |-- PCRpt,lsp2,D --+------------------>|
| | | |
| | | |
|<----------------+----PCUpd, lsp1---| |
| | |--- PCUpd, lsp1--->|
|-- PCRpt,lsp1,up-+----------------->| |
|-- PCRpt,lsp1,up-+------------------+------------------>|
| | |----PCRpt,lsp1,up->|
| | | |
| | | |
| |<---PCUpd, lsp2---|-------------------|
| | |<--- PCUpd, lsp2 --|
| |-- PCRpt,lsp2,up--+------------------>|
| | |<---PCRpt,lsp1,up--|
| |-- PCRpt,lsp2,up->| |
| | | |
</artwork>
</figure>
<t>At the time of failure of one of the PCEs (say PCE1), the other PCE
(PCE2) may take up the load. </t>
</section>
<section title="Other Considerations" toc="default">
<t>
<list style="symbols">
<t>The computation mechanism and how PCE chooses to handle the sticky
resources during computation is out of scope of this document.</t>
<t>This document does not tackle the issue about TED synchronization
which is described in detail in <xref target="RFC7399"/>.</t>
</list>
</t>
</section>
</section>
<section title="PCEP Messages" toc="default">
<section title="The PCRpt Message" toc="default">
<t>The format of PCRpt message is defined in <xref target='I-D.ietf-pce-stateful-pce'></xref>.
It specifies the PCRpt message is sent from PCC to PCE in reporting the
LSP state. This document extends the usage of PCRpt message between redundant stateful PCEs for realtime LSP synchronization as described in
<xref target="SEC_redundant"/>. A unique PLSP-ID needs to be generated at the PCE and should also carry the PCC generated PLSP-ID along in a REALTIME-SYNC TLV in the LSP object.
</t>
</section>
<section title="The PCUpd Message" toc="default">
<t>The format of PCUpd Message is defined in <xref target='I-D.ietf-pce-stateful-pce'></xref>.
It specifies the PCUpd message is sent from PCE to PCC to request changes
in LSP attributes. This document extends the usage of PCUpd message between
stateful PCEs for realtime LSP synchronization
as described in <xref target="SEC_redundant"/>. Whenever there is a PCUpd message
sent from PCE to PCC, PCE should also send it to other PCEs along with the PCC generated PLSP-ID in a REALTIME-SYNC TLV in the LSP object.
</t>
</section>
</section>
<section title="TLVs" toc="default">
<section title="Stateful PCE Capability TLV" toc="default" anchor="SEC_C">
<t>As per <xref target='I-D.ietf-pce-stateful-pce'></xref>, STATEFUL-PCE-CAPABILITY TLV can be
used in the OPEN object for stateful PCE capability negotiation. A stateful
PCE must announce during PCEP session establishment that they support PCEP
stateful PCE extensions defined in <xref target='I-D.ietf-pce-stateful-pce'></xref>. A new
flag is added - </t>
<t>
<list style="hanging">
<t hangText="R (REALTIME-SYNC-PCE - 1 bit):"> if set to 1 by PCE, the PCE has the
capability for realtime synchronization between PCEs. In case of
PCC, this bit has no meaning
and is simply ignored.</t>
</list>
</t>
</section>
<section title="Speaker Entity Identifier TLV" toc="default">
<t><xref target='I-D.ietf-pce-stateful-sync-optimizations'></xref> describes
'Speaker Entity Identifier TLV' to be included in OPEN object. This
document uses the same TLV in the LSP object for realtime sync
between redundant stateful PCEs.</t>
<t>For a PCE that supports realtime sync (REALTIME-SYNC-PCE R flag in Stateful PCE Capability TLV),
the PCC MUST include 'Speaker Entity Identifier TLV' in the OPEN message. Note a PCC may
have to bring down the current session and include the TLV in the subsequent open message.</t>
<t>Any realtime state synchronization (PCRpt or PCUpd message between PCEs) MUST include
'Speaker Entity Identifier TLV' in LSP object with the PCC's speaker identity.
If the TLV is missing, the PCE will generate an error with error-type 6 (mandatory object missing) and
error-value TBD1 (Speaker Entity Identifier TLV missing) and close the session.</t>
<t>The format of Speaker Entity Identifier is defined in <xref target='I-D.ietf-pce-stateful-sync-optimizations'></xref>.</t>
</section>
<section title="REALTIME-SYNC TLV" toc="default">
<t>PCC uses the PLSP-ID in LSP object to uniquely identify an LSP. For PCE to
PCE realtime sync, another unique PLSP-ID needs to be generated at the PCE
and should also carry the PCC's generated PLSP-ID in the REALTIME-SYNC TLV.
This way redundant PCE can correlate the LSP from the state received from the PCCs.</t>
<t>This TLV MUST be encoded in the PCRpt and PCUpd message between redundant stateful PCEs.
If the TLV is missing, the PCE will generate an error with error-type 6 (mandatory object missing) and
error-value TBD2 (REALTIME-SYNC TLV missing) and close the session.</t>
<t>The format of the REALTIME-SYNC TLV is shown in the following
figure:</t>
<figure title="REALTIME-SYNC TLV format" suppress-title="false" align="left" alt="" width="" height="" anchor="FIG_3">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
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=[TBD3] | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCC's PLSP-ID | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The type of the TLV is to be assigned by IANA and it has a fixed
length of 4 octets. The value contains the following fields:</t>
<t>
<list style="hanging">
<t hangText="PCC's PLSP-ID (20 bits):"> The PCC's original PLSP-ID as
received in the PCRpt message from the PCC. This along with Speaker Entity Identifier
TLV can be used to co-relate information received from the network (PCCs).</t>
</list>
</t>
</section>
<section title="PCE-CAP-FLAGS sub-TLV " toc="default">
<t><xref target="RFC5088"/> and <xref target="RFC5089"/> describe the mechanism
to advertise the PCE Discovery information via OSPF and IS-IS respectively
along with processing rules for the sub-TLVs. <xref target="I-D.sivabalan-pce-disco-stateful"/>
further enhances the optional PCE-CAP-FLAGS sub-TLV used to advertise PCE
stateful capabilities.</t>
<t>Further a new bit is added - </t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Bit Capabilities
TBD4 Realtime Sync between PCEs
]]></artwork>
</figure>
</t>
<t>If this bit is set to 1, the PCE has the
capability for realtime synchronization between PCEs.</t>
</section>
</section>
<section title="Other Considerations" toc="default">
<section title="PCE Initiated LSP" toc="default">
<t><xref target='I-D.ietf-pce-pce-initiated-lsp'/> describes the setup and
teardown of PCE-initiated LSPs under the active stateful PCE model. As the PCE
sends PCInitiate message to PCC to create or delete LSP, the PCE should also
send PCUpd message to other PCEs. For the initiation, the PCUpd message should have PCC's PLSP-ID as zero. The rest of the processing remains unchanged.</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>This document does not introduce any new security concerns besides those in
<xref target='I-D.ietf-pce-stateful-pce'></xref>.</t>
</section>
<section title="Manageability Considerations" toc="default">
<section title="Control of Function and Policy" toc="default">
<t>A PCE may be deployed to act only as a backup (<xref target="SEC_redundant"/>),
an operator SHOULD be able to configure a PCE as backup. </t>
</section>
<section title="Information and Data Models" toc="default">
<t><xref target="RFC7420"/> describes the PCEP MIB, there are no new MIB Objects
for this document.</t>
</section>
<section title="Liveness Detection and Monitoring" toc="default">
<t>Mechanisms defined in this document do not imply any new liveness detection
and monitoring requirements in addition to those already listed in
<xref target="RFC5440"/>.</t>
</section>
<section title="Verify Correct Operations" toc="default">
<t>Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
<xref target="RFC5440"/>.</t>
</section>
<section title="Requirements On Other Protocols" toc="default">
<t>Mechanisms defined in this document do not imply any new requirements
on other protocols.</t>
</section>
<section title="Impact On Network Operations" toc="default">
<t>Mechanisms defined in this document do not have any impact on
network operations in addition to those already listed in
<xref target="RFC5440"/>.</t>
</section>
</section>
<section title="IANA Considerations" toc="default">
<section title="STATEFUL-PCE-CAPABILITY TLV" toc="default">
<t>As discussed in <xref target="SEC_C"/>, a new STATEFUL-PCE-CAPABILITY TLV
Flag Field has been defined. IANA has made the following allocation from the
PCEP "STATEFUL-PCE-CAPABILITY TLV Flag Field" sub-registry:</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Bit Description Reference
TBD REALTIME-SYNC-PCE [This I.D.]
]]></artwork>
</figure>
</t>
</section>
<section title="PCE-CAP-FLAGS sub-TLV" toc="default">
<t>As discussed in <xref target="SEC_C"/>, a new bit is added, IANA is
requested to allocate a new bit in "PCE Capability Flags" registry for
backup stateful PCE capability as follows:</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Bit Description Reference
TBD4 Realtime Sync between PCEs [This I.D.]
]]></artwork>
</figure>
</t>
</section>
<section title="REALTIME-SYNC TLV" toc="default">
<t>This document defines the following new PCEP TLV:</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Value Meaning Reference
TBD3 REALTIME-SYNC TLV This document
]]></artwork>
</figure>
</t>
</section>
<section title="PCEP-Error Object" toc="default">
<t>IANA is requested to make the following allocation in the "PCEP-ERROR
Object Error Types and Values" registry.</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Error-Type Meaning Reference
6 Mandatory Object missing [RFC5440]
Error-Value= TBD2 This document
Speaker Entity Identifier TLV
missing
Error-Value= TBD3 This document
REALTIME-SYNC TLV missing
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Acknowledgments" toc="default">
<t>Thanks to Adrian Farrel and Daniel King for writing <xref target="RFC7399"/>.</t>
<t>We would like to thank Avantika Kumar for her useful comments and suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.I-D.ietf-pce-stateful-pce"?>
<?rfc include="reference.I-D.ietf-pce-stateful-sync-optimizations"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4655.xml" ?>
<?rfc include="reference.RFC.5088.xml" ?>
<?rfc include="reference.RFC.5089.xml" ?>
<?rfc include="reference.RFC.7399.xml" ?>
<?rfc include="reference.RFC.7420.xml" ?>
<?rfc include="reference.I-D.ietf-pce-pce-initiated-lsp"?>
<?rfc include="reference.I-D.sivabalan-pce-disco-stateful"?>
</references>
<section title="Contributor Addresses" toc="default">
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Udayasree Palle
Huawei Technologies
Divyasree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: udayasree.palle@huawei.com
Xian Zhang
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R.China
EMail: zhang.xian@huawei.com
Venugopal Reddy Kondreddy
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: venugopalreddyk@huawei.com
]]></artwork>
</figure>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:43:44 |