Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP)
draft-ietf-pce-lsp-control-request-11

[Ballot comment]
** I support Ben Kaduk’s DISCUSS point on the need to clarify the authorization policy of a PCE asking for control, and have the same question as Alvaro Retana posed about how the PCC determines when to honor a PCE’s request to take control an LSP.  More discussion of this policy mechanism is needed.

** As this draft is defining a bit from the previously reserved allocation of the flag field and redefining the semantics of 0 in the PLSP-ID of the SRP object per Section 7.2 of RFC8281, is there a reason that this draft does not formally update RFC8281.

[Ballot discuss]
This may just be a philosophical discussion, but if RFC 8231 marks the
PLSP-ID value of 0 as "reserved" and we are making use of the extension
point, do we need to have an Updates: relationship with 8231?  This
seems particularly poigniant given that we have to explicitly override
the RFC 8231 error handling, with some text in the second paragraph of
Section 4.

What kind of feature negotiation is available to check support prior to
using this flag?  After all, if the peer does not implement this
document it will not implement the override of 8231 error handling and
will respond with errors when the D flag is set (or the PLSP-ID of 0
used).  If we have to just "try it and fall back to not using it if we
get errors", that has some associated security considerations as well.

What can we say about authorization policy on the PCC?  Alvaro touched
on this in his Comment, but I think it's important enough to be
Discuss-level.  Since this policy is the key factor to the security
posture of this extension, not only does it seem like there MUST be the
ability to configure the policy, but it also seems like we should be
able to give some guidance on typical use cases (where the authors
believe the security properties to be reasonable).  Other use cases
might require an additional level of analysis by those proposing to
deploy the solution.

[Ballot comment]
Section 1

              It includes mechanisms to effect LSP state
  synchronization between Path Computation Clients (PCCs) and PCEs,
  delegation of control of LSPs to PCE, and PCE control of timing and
  sequence of path computations within and across PCEP sessions.  [...]

nit: assuming this is grouped as "it includes mechanisms to: (1) effect
LSP state synchronization [...], (2) delegation of control [...], and
(3) PCE control of timing and sequence [...]", the verb tenses need to
be changed so that they match up.

  For Redundant Stateful PCEs (section 5.7.4. of [RFC8231]), during a
  PCE failure, one of the redundant PCE could request to take control
  over an LSP.  The redundant PCEs may use a local policy or a

Just to check: this request is only possible with the mechanism defined
in this document, and is not possible with just the previous
technologies?  I might suggest to s/could/might want to/ to make it more
clear that this is motivating the rest of the document.

  In case of virtualized PCEs (vPCE) running as virtual network
  function (VNF), as the computation load in the network increases, a

nit: singular/plural mismatch "PCEs"/VNF

  can be used in conjunction to [RFC8231].  Ultimately, it is the PCC
  that decides which PCE to delegate the orphaned LSP.

nit: either "to which to delegate the orphaned LSP" or "to delegate the
orphaned LSP to".

Section 3

  A new flag, the "LSP-Control Request Flag" (C), is introduced in the
  SRP object.  On a PCUpd message, a PCE sets the C Flag to 1 to
  indicate that it wishes to gain control of LSPs.  The LSPs are
  identified by the LSP object.  A PLSP-ID of value other than 0 and
  0xFFFFF is used to identify the LSP for which the PCE requests
  control.  The PLSP-ID value of 0 indicates that the PCE is requesting
  control of all LSPs originating from the PCC that it wishes to
  delegate.  [...]

nit: I suggest s/identified by the LSP object/identified by the PLSP-ID
in the LSP object following the SRP object/.

  delegate.  The C Flag has no meaning in other PCEP messages that
  carry SRP object and the flag MUST be set to 0 on transmission and
  MUST be ignored on receipt.

nit: I suggest s/object/objects/ and s/and the/and for which the/

Section 4

  If a PCE wishes to gain control over an LSP, it sends a PCUpd message
  with C Flag set to 1 in SRP object.  The LSP for which the PCE
  requests control is identified by the PLSP-ID.  The PLSP-ID of 0

nit: as above, I suggest s/identified by the PLSP-ID/identified by the
PLSP-ID in the associated LSP object/

  timer.  A PCE ignores the C Flag on the PCRpt message.  Note that, if

nit: I think this is now redundant with the text added in respone to
the genart review ("The C Flag has no meaning in other PCEP messages
that carry SRP object and the flag MUST be set to 0 on transmission and
MUST be ignored on receipt").

  It should be noted that a legacy implementation of PCC, that does not
  support this extension would trigger the error condition as specified
  in [RFC8231] (a PCErr with Error-type=19 (Invalid Operation) and
  error-value 1 (Attempted LSP Update Request for a non-delegated LSP))
I don't understand this sentence -- what does "as the D Flag would be
unset" mean?  Does it just mean that the PCC treats it as unset because
it has no code to handle the D flag at all?

Section 6

Please cite RFC 7525 as BCP 195.

[Ballot comment]
Hi,

thank you for this document.
This document indicates:
"...MUST NOT trigger the error condition for unknown PLSP-ID in an LSP update request as per [RFC8231] ...".
"...MUST NOT trigger the error handling as specified in [RFC8231] ...".

Yet, it also says:
The procedures for granting and relinquishing control of the LSPs are specified in accordance with the specification [RFC8231].

So
1/ it seems to me that the latter sentence, considering the first two, is not strictly correct.
2/ the rationale is well described, so I'm fine with not respecting the original rules of 8231, but then I wonder if this document shouldn't update 8231.

[Ballot comment]
Hi,

thank you for this document.
This document indicates:
- "...MUST NOT trigger the error condition for unknown PLSP-ID in an LSP update request as per [RFC8231] ..."
- "...MUST NOT trigger the error handling as specified in [RFC8231] ..."

Yet, it also says:
The procedures for granting and relinquishing control of the LSPs are specified in accordance with the specification [RFC8231].

So
1/ it seems to me that the latter sentence, considering the first two, is not strictly correct.
2/ the rationale is well described, so I'm fine with not respecting the original rules of 8231, but then I wonder if this document shouldn't update 8231.

[Ballot comment]
Hi,

thank you for this document.
This document indicates:
MUST NOT trigger the error condition for unknown PLSP-ID in an LSP update request as per [RFC8231]
MUST NOT trigger the error handling as specified in [RFC8231]

Yet, it also says:
The procedures for granting and relinquishing control of the LSPs are specified in accordance with the specification [RFC8231].

So
1/ it seems to me that the latter sentence, considering the first two, is not strictly correct.
2/ the rationale is well described, so I'm fine with not respecting the original rules of 8231, but then I wonder if this document shouldn't update 8231.

[Ballot comment]
I have a substantive comment and then some nits/editorial notes.

(1) It seems to me that any PCE can request control of an LSP.  Even if the sessions are authenticated and encrypted, how does the PCC determine if it's ok for the requesting PCE to ask for control?  §8.1 says that an "implementation SHOULD allow the operator to configure the policy based on which it honors the request to control the LSPs".  If the implementation doesn't allow the configuration of policy, then it is possible for a rogue PCE to ask for control of an LSP, and for the PCC to grant it.  Why is the ability to configure this policy not REQUIRED?  I believe this case should be explicitly called out as a vulnerability.

(2) Abstract: s/A Path Computation Client (PCC) has set up LSPs/A Path Computation Client (PCC) that has set up LSPs

(3) §1: s/which PCE to delegate the orphaned LSP/which PCE to delegate the orphaned LSP to

(4) §1: s/a simple extension, by using this a PCE can/a simple extension, by using it a PCE can

(5) In §3 the new C Flag is called the "LSP-Control Request Flag", but §7.1 only uses "LSP-Control".  Please be consistent; the more descriptive name is probably better.

[Ballot comment]
I have only some editorial comments.  There’s no need to respond, but please consider these comments, as I think they’ll help make the document clearer.  Particularly note the first comment for Section 3.

— Abstract —

  This document describes an extension to the Path Computation Element
  communication Protocol (PCEP) to enable a PCE to make such requests.

It’s a small thing, but no requests have been mentioned that could match “such requests”.  But “control” has been discussed, so  I think you need to say it this way:

NEW
  This document describes an extension to the Path Computation Element
  communication Protocol (PCEP) to enable a PCE to make requests for
  such control.
END

— Section 1 —

  In case of virtualized PCEs (vPCE) running as virtual network
  function (VNF), as the computation load in the network increases

“Running as virtual network function” sounds like it’s missing something.  Maybe “running in VNF mode,” or some such?

  The PCEs could use proprietary algorithm to decide which LSPs
  to be assigned to the new vPCE.

Either “a proprietary algorithm” or “proprietary algorithms”.

  Thus having a mechanism for the PCE
  to request control of some LSPs is needed.

You need a comma after “Thus”.

  This specification provides a simple extension, by using this a PCE
  can request control

Comma splice.  The easiest fix is to change the “,” to a “:”.  Or else split it into two sentences at the comma.

— Section 3 —
This section refers to the new flag as the “LSP-Control Request Flag”.  The IANA Considerations section (7.1) just calls it “LSP-Control”.  Probably Section 7.1 should call it “LSP-Control Request”, and this section should refer to “TBD” so that th RFC Editor will insert the bit number that IANA assigns.

  The Stateful PCE Request Parameters (SRP) object is defined in
  Section 7.2 of [RFC8231], it includes a Flags field.

Comma splice.  Change “it” to “and” to fix it.

  The C Flag has no meaning in other PCEP messages that
  carry SRP object

Either “an SRP object” or “SRP objects”.

— Section 4 —

  The D Flag and C
  Flag are mutually exclusive in PCUpd message.  The PCE SHOULD NOT
  send control request for LSP which is already delegated to the PCE,
  i.e. if the D Flag is set in the PCUpd message, then C Flag SHOULD
  NOT be set.

I’m confused: “mutually exclusive” means that they can’t both be set.  So why SHOULD NOT and not MUST NOT?  (You’re also missing a few articles here: ”a PCUpd message”, “a control request”, “an LSP”, and “the C Flag”.

  It should be noted that a legacy implementation of PCC, that does not
  support this extension would trigger the error condition as specified
  in [RFC8231] (a PCErr with Error-type=19 (Invalid Operation) and
  error-value 1 (Attempted LSP Update Request for a non-delegated LSP))
  as the D Flag would be unset in this update request.

Please move the comma that’s after “PCC” and place it instead before “as the D Flag”.

  It also specifies how a
  PCE MAY obtain control over an orphaned LSP that was PCE-initiated.

This should be “may”, not a BCP 14 key word.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-pce-lsp-control-request-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the SRP Object Flag Field registry located on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

a single, new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Description: LSP-Control
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-08-28):

From: The IESG
To: IETF-Announce
CC: db3546@att.com, Hariharan Ananthakrishnan , hari@netflix.com, pce@ietf.org, pce-chairs@ietf.org, draft-ietf-pce-lsp-control-request@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Ability for a Stateful Path Computation Element (PCE) to request and obtain control of a Label Switched Path (LSP)) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'Ability for a Stateful Path Computation
Element (PCE) to request and
  obtain control of a Label Switched Path (LSP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-08-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  A Stateful Path Computation Element (PCE) retains information about
  the placement of Multiprotocol Label Switching (MPLS) Traffic
  Engineering Label Switched Paths (TE LSPs).  When a PCE has stateful
  control over LSPs it may send indications to LSP head-ends to modify
  the attributes (especially the paths) of the LSPs.  A Path
  Computation Client (PCC) has set up LSPs under local configuration
  may delegate control of those LSPs to a stateful PCE.

  There are use-cases in which a stateful PCE may wish to obtain
  control of locally configured LSPs of which it is aware but that have
  not been delegated to the PCE.

  This document describes an extension to the Path Computation Element
  communication Protocol (PCEP) to enable a PCE to make such requests.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-control-request/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-control-request/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?
-> Proposed Standard

Why is this the proper type of RFC?
-> It is a technical specification of a protocol extension.

Is this type of RFC indicated in the title page header?
-> Yes

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
  A Stateful Path Computation Element (PCE) retains information about
  the placement of Multiprotocol Label Switching (MPLS) Traffic
  Engineering Label Switched Paths (TE LSPs).  When a PCE has stateful
  control over LSPs it may send indications to LSP head-ends to modify
  the attributes (especially the paths) of the LSPs.  A Path
  Computation Client (PCC) has set up LSPs under local configuration
  may delegate control of those LSPs to a stateful PCE.

  There are use-cases in which a Stateful PCE may wish to obtain
  control of locally configured LSPs of which it is aware but that have
  not been delegated to the PCE.

  This document describes an extension to the Path Computation Element
  communication Protocol (PCEP) to enable a PCE to make such requests.
 

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
-> N/A

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
-> One implementation is confirmed and at least one more have been placed on product roadmaps.

Personnel

Who is the Document Shepherd?
-> Hariharan Ananthakrishnan
 
Who is the Responsible Area Director?
-> Deborah Brungard

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
-> The document has been reviewed, updated and is ready to progress.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
-> No (We trust the RFC Editor to catch the few remaining nits.)

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
-> N/A

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
-> N/A

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
-> Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
-> No

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
-> It reflects WG consensus, extending a generic mechanism defined by the WG and involving several companies on the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
-> N/A

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
-> N/A

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
-> N/A

(13) Have all references within this document been identified as
either normative or informative?
-> Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
-> No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
-> No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
-> No


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).
-> The IANA section is consistent with the document's body. A new code point in an existing sub-registry has been requested.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
-> N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
-> N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?
-> Proposed Standard

Why is this the proper type of RFC?
-> It is a technical specification of a protocol extension.

Is this type of RFC indicated in the title page header?
-> Yes

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
  A Stateful Path Computation Element (PCE) retains information about
  the placement of Multiprotocol Label Switching (MPLS) Traffic
  Engineering Label Switched Paths (TE LSPs).  When a PCE has stateful
  control over LSPs it may send indications to LSP head-ends to modify
  the attributes (especially the paths) of the LSPs.  A Path
  Computation Client (PCC) has set up LSPs under local configuration
  may delegate control of those LSPs to a stateful PCE.

  There are use-cases in which a Stateful PCE may wish to obtain
  control of locally configured LSPs of which it is aware but that have
  not been delegated to the PCE.

  This document describes an extension to the Path Computation Element
  communication Protocol (PCEP) to enable a PCE to make such requests.
 

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
-> N/A

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
-> One implementation is confirmed and at least one more have been placed on product roadmaps.

Personnel

Who is the Document Shepherd?
-> Hariharan Ananthakrishnan
 
Who is the Responsible Area Director?
-> Deborah Brungard

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
-> The document has been reviewed, updated and is ready to progress.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
-> No (We trust the RFC Editor to catch the few remaining nits.)

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
-> N/A

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
-> N/A

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
-> Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
-> No

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
-> It reflects WG consensus, extending a generic mechanism defined by the WG and involving several companies on the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
-> N/A

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
-> N/A

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
-> N/A

(13) Have all references within this document been identified as
either normative or informative?
-> Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
-> No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
-> No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
-> No


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).
-> The IANA section is consistent with the document's body. A new code point in an existing sub-registry has been requested.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
-> N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
-> N/A

Request for posting confirmation emailed to previous authors: Jay Karthik , Jon Parker , Aswatnarayan Raghuram , Siva Sivabalan , Chaitanya Yadlapalli , Al Goddard , pce-chairs@ietf.org, Mahendra Negi

Request for posting confirmation emailed to previous authors: Jay Karthik , Jon Parker , Aswatnarayan Raghuram , Siva Sivabalan , Chaitanya Yadlapalli , Al Goddard , Mahendra Negi

Request for posting confirmation emailed to previous authors: Jay Karthik , Jon Parker , Aswatnarayan Raghuram , Siva Sivabalan , Chaitanya Yadlapalli , Dhruv Dhody , Al Goddard , pce-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Jay Karthik , Jon Parker , Aswatnarayan Raghuram , Siva Sivabalan , Chaitanya Yadlapalli , Dhruv Dhody , Al Goddard

Request for posting confirmation emailed to previous authors: Jay Karthik , Jon Parker , Aswatnarayan Raghuram , Siva Sivabalan , Chaitanya Yadlapalli , Dhruv Dhody , Al Goddard