Subject: [Pce] Shepherd review of draft-ietf-pce-stateful-pce-p2mp-08

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 4 Feb 2019 18:01:17 -0000

Hi,

I have picked up this document as Shepherd and I have done a "final"
review before the document is passed on to the AD with a publication
request.  Jon had started work on this, and I have folded in his
comments.

Pretty much everything we have here is editorial in nature, but there
are quite a lot of comments in this email, so I think it would be
worthwhile to tidy the document in a new revision before we take it to
the AD.

Thanks,
Adrian

=======

Sections 1 and 14.2

s/RFC4857/RFC4875/   (!)

---

Section 1

OLD
   Stateful PCEs are shown to be helpful in many application scenarios,
   in both MPLS and GMPLS networks, as illustrated in [RFC8051].  These
   scenarios apply equally to P2P and P2MP TE LSPs.  [RFC8231] provides
   the fundamental extensions needed for stateful PCE to support general
   functionality for P2P TE LSP.  [RFC8281] provides the an extensions
   needed for stateful PCE-initiated P2P TE LSP.  Complementarily, this
   document focuses on the extensions that are necessary in order for
   the deployment of stateful PCEs to support P2MP TE LSPs.  This
   document describes the setup, maintenance and teardown of PCE-
   initiated P2MP LSPs under the stateful PCE model.
NEW
   Stateful PCEs are shown to be helpful in many application scenarios,
   in both MPLS and GMPLS networks, as illustrated in [RFC8051].  These
   scenarios apply equally to P2P and P2MP TE LSPs.  [RFC8231] provides
   the fundamental extensions to PCEP needed for stateful PCE to support
   general functionality for P2P TE LSP.  [RFC8281] provides extensions
   to PCEP needed for stateful PCE-initiated P2P TE LSP.  This document
   complements that work by focusing on PCEP extensions that are
   necessary in order for the deployment of stateful PCEs to support
   P2MP TE LSPs.  This document describes the setup, maintenance, and
   teardown of PCE-initiated P2MP LSPs under the stateful PCE model.
END

---

3.1

s/etc/etc./

---

3.1

OLD
   Complementarily, this document focuses on the extensions that are
   necessary in order for the deployment of stateful PCEs to support
   P2MP TE LSPs.
NEW
   This document complements the previous work by focusing on
   extensions that are necessary in order for the deployment of stateful
   PCEs to support P2MP TE LSPs.
END

---

3.1

s/via PLSP-ID/via a PCEP-specific LSP identifier (PLSP-ID)/

---

3.1

OLD
   In case of
   stateless PCE, a modification of P2MP tree requires encoding of all
   leaves along with the paths in PCEP message, but using a stateful PCE
   with P2MP capability, the PCEP message can be used to convey only the
   modifications (the other information can be retrieved from the P2MP
   LSP identifier in the LSP database (LSPDB)).
NEW
   When using a
   stateless PCE, a request to modify an existing P2MP tree requires
   that all the leaves are presented in the PCEP messages along with all
   the path information.  But when using a stateful PCE, the PCEP
   messages can use a PLSP-ID to represent all information about the LSP
   that has previously been exchanged in PCEP messages, and it is only
   necessary to encode the modifications (such as new or removed leaf
   nodes).  The PLSP-ID provides an index into the LSP-DB at the PCE,
   and identifies the LSP at the PCC.
END

---

5.1 (and all of the document)

Please check and fix the capitalisation of PCEP messages.  For example,

OLD
   The path computation request (PCReq) and path computation reply
   (PCRep)
NEW
   The Path Computation Request (PCReq) and Path Computation Reply
   (PCRep)

END

---

5.2 (and all of document)

Use consistent names such as "Stateful PCE Capability TLV" versus
"STATEFUL-PCE-CAPABILITY TLV"

Be consistent with "flag" versus "bit"

s/PCEP speakers advertises/PCEP speakers advertise/

s/changes.;/changes;/

s/an P2MP LSP/a P2MP LSP/

---

5.6.1 (and elsewhere)

s/a LSP/an LSP/

---

5.6.3

s/same as P2P/same as for P2P/

---

5.6.3.1

s/P2MP TE LSP/P2MP TE LSPs/

---

Section 6 needs a reference to RFC 5511 to explain the notation.

---

6.1

The following bit of RBNF echoes something we did in the base stateful
draft and which has caused confusion / errata to be raised because it
looks so wrong (actual and intended all mixed up).  Do we absolutely
need to do this just to have something that looks like the base draft
(which looks weird)?  If so, please give an explicit explanation in
the text, otherwise we will just get the errata raised again.

   <state-report> ::= [<SRP>]
                       <LSP>
                       <end-point-intended-path-pair-list>
                       [<actual-attribute-list>
                       <end-point-actual-path-pair-list>]
                       <intended-attribute-list>

---

6.1 (and same question for 6.2)

In the following bit of RBNF, what is the use of having more than 1
[intended | actual] path?

   <intended-path> ::= (<ERO>|<SERO>)
              [<intended-path>]

   <actual-path> ::= (<RRO>|<SRRO>)
              [<actual-path>]

---

6.1

In this paragraph:

   When reporting the status of a P2MP TE LSP, the destinations are
   grouped in END-POINTS object based on the operational status (O field
   in S2LS object) and leaf type (in END-POINTS).  This way the leaves
   that share the same operational status are grouped together.  For
   reporting the status of delegated P2MP TE LSP leaf-type = 3 is used,
   where as for non-delegated P2MP TE LSP, leaf-type = 4 is used.

I think the first sentence should use normative language: "the
destinations MUST be grouped..."

You probably mean "This way, leaves of the same type that share the same
operational status are grouped together."

- s/where as/whereas/

---

6.2

   The PCC SHOULD use the make-before-break or sub-group-based
   procedures described in [RFC4875] based on a local policy decision.

That's fine, but if you have "SHOULD" you need to describe the
variant behavior as well.

---

6.6

Not mandatory, but how about adding another example showing a PCInitiate?

---

6.6.1

s/LSP Update Request/An LSP Update Request/

OLD
   request updation of path taken by
   some of the leaves in a P2MP tree.
NEW
   requests an update of the path taken to
   some of the leaves in a P2MP tree.
END

---

6.6.2

s/LSP State Report message/The LSP State Report message/

In the second example, which prunes some leaves, why does the PCC need
to supply the EROs of the pruned leaves?

Reading the fourth example, I wondered if it would be possible in
principle to delegate some leaves in a tree and not others?  Or is it
only possible to delegate the whole tree?

---

6.7

This subsection seems misplaced after the Examples. Maybe move it up within
Section 6?

But maybe also rename it because it seems actually to be about error
handling.

---

7.

s/The PCEP TLV defined/The new PCEP TLVs defined/

---

7.1

s/LSP Object is defined/The LSP Object is defined/
s/PLSP-ID to uniquely/the PLSP-ID to uniquely/
s/for P2MP tunnel, PLSP-ID/for a P2MP tunnel, the PLSP-ID/

-

The text for the N bit uses a mix of descriptive and 2119 language. I
don't think you need the MUST. So...
OLD
   N (P2MP bit):  If the bit is set to 1, it specifies the message is
      for P2MP TE LSP which MUST be set in PCRpt, PCUpd, or PCInitiate
      message for a P2MP TE LSP.
NEW
   N (P2MP bit):  If the N bit is set to 1, it indicates that the
      message is for a P2MP TE LSP.  It can be used on a PCRpt, PCUpd,
      or PCInitiate message.
END

-

Shouldn't the description of the N bit should also mention PCReq and
PCRep?

-

OLD
   If P2MP bit is set, the following P2MP-LSP-IDENTIFIER TLV MUST be
   present in LSP object.
NEW
   If the N bit is set, the P2MP-LSP-IDENTIFIER TLV defined in Section
   7.2 MUST be present in LSP object.
END

---

7.1

   F (Fragmentation bit):  If the bit is set to 1, it specifies the
      message is fragmented.

A forward reference to Section 8 would be useful.

---

7.2

   The P2MP LSP Identifier TLV MUST be included in the LSP object in
   PCRpt message for RSVP-TE signaled P2MP TE LSPs.

But 7.1 says it MUST be present if the N bit is set.  Isn't RSVP-TE a
subset of all cases where the path may be P2MP?

-

   If the TLV is
   missing, the PCE will generate an error with error-type 6 (mandatory
   object missing) and error-value 14 (early allocated by IANA) (P2MP-
   LSP-IDENTIFIER TLV missing) and close the PCEP session.

Presumably, this is actually...

   If the N bit is set on a PCRpt but the P2MP-LSP-IDENTIFIER TLV is
   absent, the PCE MUST respond with a PCErr message carrying 
   error-type 6 (mandatory object missing) and error-value 14 (early
   allocated by IANA) (P2MP-LSP-IDENTIFIER TLV missing) and close the
   PCEP session.

-

   The P2MP LSP Identifier TLV MAY be included in the LSP object in
   PCUpd message for RSVP-TE signaled P2MP TE LSPs.

A double issue as not only is there the question about limiting to 
RSVP-TE, but this "MAY" contradicts the "MUST" in 7.1.

-

   There are two P2MP LSP Identifier TLVs, one for IPv4 and one for
   IPv6.

Presumably only one can be present?

-

s/the following figure:/Figure 6./

...and then...

s/the following figure:/Figure 7./

---

7.3

You need to define how the other Flags should be set? Can they be
allocated by a future draft? Do you need a registry for them? Or
should you mark the field as "Reserved". (But see also 11.7)

Can the O field in the LSP object be down and the O field in the S2LS
object be up?  What would that mean?

"Future documents MAY define optional TLVs..." - RFC 2119 language is
not appropriate here.  s/MAY/might/.

---

8.

"The total PCEP message length, including the common header, is 16
bytes" - can't be right.  Not sure what you intended here.  

This seems to have been copied from RFC 8306. But I don't know what was
meant there, either.

Maybe (2^16)-1  ?

---

8.1, 8.2, and 8.3

2nd paragraph does not scan - a reword is needed.
Possibly...
OLD
   To indicate P2MP message fragmentation errors associated with a P2MP
   Report, a Error-Type (18) for "P2MP Fragmentation Error" and a new
   error-value 2 (early allocated by IANA) is used if a PCE has not
   received the last piece of the fragmented message, it should send an
   error message to the PCC to signal that it has received an incomplete
   message (i.e., "Fragmented Report failure").
NEW
   The Error-Type value 18 ("P2MP Fragmentation Error") is used to 
   report any error associated with the fragmentation of a P2MP PCEP
   message.  A new error-value 2 (early allocated by IANA) indicates
   "Fragmented report failure" and is used if a PCE does not receive the
   any part of the fragmented message.
END (and similar for 8.2 and 8.3)

---

9.

It's normal to put the names of the error-values in double quotes.

---

9. 

You have that error-value 11 is followed by closing the session.  What 
about error-values 12 and 13?

---

10.

s/PCEP protocol/PCEP/

---

10.2

"The PCEP YANG model SHOULD be extended" Probably no need for RFC 2119
language. Maybe "could".

---

11.7

s/object.New/object.  New/

Tell IANA how many bits are in the registry and what to do for bits 0...28.

---

12.

   The stateful operations on P2MP TE LSP are more CPU-intensive and
   also utilize more bandwidth on wire.

More intensive than what?

---

12.

I find this a bit vague:

   In the event of an unauthorized
   stateful P2MP operations, or a denial of service attack, the
   subsequent PCEP operations may be disruptive to the network.

How about this instead:
   If a rogue PCC were able to request unauthorize stateful PCE
   operations then it may be able to mount a DoS attack against
   a PCE, which would disrupt the network and deny service to
   other PCCs.

---

12.

The second paragraph in this section is unclear in the requirements
that it is placing on implementations.  What security behaviour is 
it specifying?

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 6 Feb 2019 11:19:34 +0000

Hi Adrian, 

Thanks for the clear suggested text to improve the document, much appreciated. 

All editorial comments are accepted and updated in the working copy. Please let me know if there is any issue. 

Working Copy - https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-stateful-pce-p2mp-09.txt
Diff - https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-stateful-pce-p2mp-08&url2=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-stateful-pce-p2mp-09.txt

<Snip to a few issues that require some discussion>

> looks so wrong (actual and intended all mixed up).  Do we absolutely need
> to do this just to have something that looks like the base draft (which
> looks weird)?  If so, please give an explicit explanation in the text,
> otherwise we will just get the errata raised again.
> 
[[Dhruv Dhody]] So far we have tried to maintain compatibility between P2P and P2MP versions of the PCEP messages. Additionally we state - 

   Note that the compatibility with the [RFC8231] definition of <state-
   report> is preserved.  At least one instance of <END-POINTS> MUST be
   present in this message for P2MP LSP.

I have also added this now - 

   Note that the ordering of <end-point-intended-path-pair-list>,
   <actual-attribute-list>, <end-point-actual-path-pair-list>, and
   <intended-attribute-list> is done to retain compatibility with state
   reports for the P2P LSPs as per [RFC8231].

>    <actual-path> ::= (<RRO>|<SRRO>)
[[Dhruv Dhody]] The Endpoint Object for P2MP has multiple destinations, and for each destination there would be a corresponding ERO/SERO or RRO/SRRO. That is why it is a list matched to the order of the destinations encoded in the corresponding END-POINTS object. 

<snip>
> That's fine, but if you have "SHOULD" you need to describe the variant
> behavior as well.
> 
[[Dhruv Dhody]] RFC8231 also uses a SHOULD with no mention of any other behavior.  

   Any changes to LSP parameters
   SHOULD be done in a make-before-break fashion.

Any suggestions on how would you prefer this to be handled? 

<snip>
> In the second example, which prunes some leaves, why does the PCC need to
> supply the EROs of the pruned leaves?
> 
[[Dhruv Dhody]] Marked that this could be empty.

> principle to delegate some leaves in a tree and not others?  Or is it only
> possible to delegate the whole tree?
> 
[[Dhruv Dhody]] yes, currently we delegate the whole tree. One could play around with leaf-type in future, if there is a requirement to support those 'per-leaf'. 

<snip> 
> -
> 
> Shouldn't the description of the N bit should also mention PCReq and PCRep?
> 
[[Dhruv Dhody]] I have added this text - 

   The N flag is used in a PCRpt, PCUpd, or PCInitiate message to
   indicate a P2MP TE LSP.  In case of PCReq and PCRep, the N flag in
   the RP (Request Parameters) object ([RFC8231]) is used to indicate
   P2MP path computation.  The N flag in the LSP object MUST also be set
   if the N flag in the RP object is set.  If there is mis-match
   between the N flag in the RP and the LSP object in PCReq or PCRep
   message, the PCEP speaker MUST generate an error with error-type 10
   ("Reception of an invalid object") and error-value TBD1 (to be
   allocated by IANA) ("Mis-match of N flag in RP and LSP object").
<snip>
> subset of all cases where the path may be P2MP?
[[Dhruv Dhody]] I think we can remove any mention of RSVP-TE here. 
> A double issue as not only is there the question about limiting to RSVP-TE,
> but this "MAY" contradicts the "MUST" in 7.1.
> 
[[Dhruv Dhody]] As per RFC 8231, the LSP-IDENTIFIERS TLV is MUST for PCRpt, but optional for PCUpd. 
This borrow the same idea. The text now says - 

   If the N bit is set on a PCRpt but the P2MP-LSP-IDENTIFIER TLV is
   absent, the PCE MUST respond with a PCErr message carrying error-type
   6 ("mandatory object missing") and error-value 14 (early allocated by
   IANA) ("P2MP-LSP-IDENTIFIER TLV missing") and close the PCEP session.

   The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the
   PCUpd message for P2MP TE LSPs.  The special value of all zeros for
   this TLV is used to refer to all paths pertaining to a particular
   PLSP-ID.

> Presumably only one can be present?
[[Dhruv Dhody]] Though RFC8231 does not say anything more, do you suggest I add some text for P2MP?

<snip>
> allocated by a future draft? Do you need a registry for them? Or should
> you mark the field as "Reserved". (But see also 11.7)
> 
[[Dhruv Dhody]] Updated to - 

   Flags(32-bits):  the following flags are currently defined -

   O(Operational - 3 bits)  the O Field represents the operational
      status of the group of destinations.  The values are as per
      Operational field in LSP object defined in Section 7.3 of
      [RFC8231].

   Unassigned bits are reserved for future uses.  They MUST be set to 0
   on transmission and MUST be ignored on receipt.

> object be up?  What would that mean?
[[Dhruv Dhody]] The state of the P2MP tree would be considered up, if the path to at least one of the leaf is up. So I don't see a case where LSP object says down while S2LS says up.
Added an error case - 

   If there is a
   conflict between the O field in the LSP and the S2LS object (for
   example, O field in LSP corresponds to down whereas the O field in
   S2LS is up), the PCEP speaker MUST generate an error with error-type
   10 ("Reception of an invalid object") and error-value TBD2 (to be
   allocated by IANA) ("Mis-match of O field in S2LS and LSP object").

> 
> "Future documents MAY define optional TLVs..." - RFC 2119 language is not
> appropriate here.  s/MAY/might/.
> 
[[Dhruv Dhody]] Ack

<snip>
> END (and similar for 8.2 and 8.3)
[[Dhruv Dhody]] One change to your suggested text, instead of 'any part', I think we should use 'last part' as done before (as well as in RFC8306). 

I have updated the definition of F bit as well to - 

   F (Fragmentation flag - 1 bit):  If the F flag is unset (0), it
      indicates that the LSP is not fragmented or it is the last piece
      of the fragmented LSP.  If the F flag is set to 1, it indicates
      that the LSP is fragmented and this is not the last piece of the
      fragmented LSP.  The receiver needs to wait for additional
      fragments until it receives an LSP with the same PLSP-ID and with
      the F-bit set to 0.  See Section 8 for further details.
 
This should make it clear that the error would be not receiving the last fragment of report with F bit unset. 

<snip>
> More intensive than what?
[[Dhruv Dhody]] Added - 
   
   The stateful operations on P2MP TE LSPs are more CPU-intensive and
   also utilize more bandwidth on wire (in comparison to P2P TE LSPs).

<snip>
> 
> 12.
> 
> The second paragraph in this section is unclear in the requirements that
> it is placing on implementations.  What security behaviour is it
> specifying?
> 
[[Dhruv Dhody]] Updated to - 

   Securing the PCEP session using Transport Layer
   Security (TLS) [RFC8253], as per the recommendations and best current
   practices in [RFC7525], is RECOMMENDED.

Thanks! 
Dhruv (on behalf of co-authors)

> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 6 Feb 2019 12:25:02 -0000

> All editorial comments are accepted and updated in the working 
> copy. Please let me know if there is any issue. 

All good.

> [[Dhruv Dhody]] So far we have tried to maintain compatibility between P2P
and P2MP
> versions of the PCEP messages. Additionally we state - 
>

Your suggested text is good.

Just looking at the errata for RFC 8231

https://www.rfc-editor.org/errata/eid5492 is still "reported" and shows an
inconsistency between the text "intended-attribute-list is optional" and the
RBNF...
<path>::= <intended-path>
                [<actual-attribute-list><actual-path>]
                <intended-attribute-list>
That looks like a problem to me. But I'm not sure what the correct
resolution is.
I don't see any discussion on the list.
If we can get that resolved, it could help us be clear here.
Depending on the resolution, we might need a change to this draft.

A

>    <actual-path> ::= (<RRO>|<SRRO>)
[[Dhruv Dhody]] The Endpoint Object for P2MP has multiple destinations, and
for each destination there would be a corresponding ERO/SERO or RRO/SRRO.
That is why it is a list matched to the order of the destinations encoded in
the corresponding END-POINTS object. 

<snip>
> That's fine, but if you have "SHOULD" you need to describe the variant
[[Dhruv Dhody]] RFC8231 also uses a SHOULD with no mention of any other
behavior.  

<snip>

> possible to delegate the whole tree?
[[Dhruv Dhody]] yes, currently we delegate the whole tree. One could play
around with leaf-type in future, if there is a requirement to support those
'per-leaf'. 

<snip> 
PCRep?

> A double issue as not only is there the question about limiting to
RSVP-TE,
> but this "MAY" contradicts the "MUST" in 7.1.
[[Dhruv Dhody]] As per RFC 8231, the LSP-IDENTIFIERS TLV is MUST for PCRpt,
but optional for PCUpd. 
This borrow the same idea. The text now says - 

> Presumably only one can be present?
[[Dhruv Dhody]] Though RFC8231 does not say anything more, do you suggest I
add some text for P2MP?

<snip>

> object be up?  What would that mean?
[[Dhruv Dhody]] The state of the P2MP tree would be considered up, if the
path to at least one of the leaf is up. So I don't see a case where LSP
object says down while S2LS says up.
Added an error case - 

   If there is a

[[Dhruv Dhody]] Ack

<snip>
> END (and similar for 8.2 and 8.3)
[[Dhruv Dhody]] One change to your suggested text, instead of 'any part', I
think we should use 'last part' as done before (as well as in RFC8306). 

 
This should make it clear that the error would be not receiving the last
fragment of report with F bit unset. 

<snip>
[[Dhruv Dhody]] Added - 

<snip>

Thanks!

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 7 Feb 2019 04:25:06 +0000

Hi Adrian, 

> >> 6.1
> >>
> >> The following bit of RBNF echoes something we did in the base
> >> stateful draft and which has caused confusion / errata to be raised
> >> because it looks so wrong (actual and intended all mixed up).  Do we
> >> absolutely need to do this just to have something that looks like the
> >> base draft (which looks weird)?  If so, please give an explicit
> >> explanation in the text, otherwise we will just get the errata raised
> again.
> >>
> inconsistency between the text "intended-attribute-list is optional" and
> the RBNF...
>                 <intended-attribute-list> That looks like a problem to me.
> But I'm not sure what the correct resolution is.
[[Dhruv Dhody]] I responded with a proposal to handle the errata. 
And the corresponding change is made in this I-D as well. 

>    allocated by IANA) ("Mis-match of N flag in RP and LSP object").

[[Dhruv Dhody]] It was pointed out to me that this is applicable for all flags that are common between RP and LSP objects, so better way forward could be to refer to RP object only when both RP and LSP object exist in the PCEP messages. 

Thus I have added - 

   The flags defined in this section (N, F, E flags) are used in PCRpt,
   PCUpd, or PCInitiate message.  In case of PCReq and PCRep message,
   these flags have no meaning and thus MUST be ignored.  The
   corresponding flags in the RP (Request Parameters) object are used as
   described in [RFC8231].

Let me know if this is fine with you? 

Working Copy - https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-stateful-pce-p2mp-10.txt
Diff - https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-stateful-pce-p2mp-09&url2=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-stateful-pce-p2mp-10.txt

Regards,
Dhruv

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 8 Feb 2019 13:17:06 -0000

Looks good to me.

Thanks!

I'll wait to see -09 posted.

A

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: 07 February 2019 04:25
To: [email-masked]; [email-masked]
Cc: [email-masked]; 'Dhruv Dhody' <[email-masked]>
Subject: RE: [Pce] Shepherd review of draft-ietf-pce-stateful-pce-p2mp-08

Hi Adrian, 

>    allocated by IANA) ("Mis-match of N flag in RP and LSP object").

[[Dhruv Dhody]] It was pointed out to me that this is applicable for all
flags that are common between RP and LSP objects, so better way forward
could be to refer to RP object only when both RP and LSP object exist in the
PCEP messages. 

Thus I have added - 

Working Copy -
https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-p
ce-stateful-pce-p2mp-10.txt
Diff -
https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-stateful-pce-p2mp-09&url2
=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-
pce-stateful-pce-p2mp-10.txt

Regards,
Dhruv

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 12 Feb 2019 10:01:08 +0530

Hi Adrian,

I have posted -10 that has this change incorporated.

Thanks!
Dhruv