Subject: [Teas] Status update on <draft-ietf-teas-pce-central-control>

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Mar 2017 12:01:48 -0000

Hi,

As requested, here is the status of this I-D.

- Not on the agenda in Chicago

- New revision posted in December
   - Fixed nits after re-review by several authors

- The authors have repeatedly pointed out to the chairs that the
   document is complete and ready to move forward.
   - At this stage, the chairs are blocking progress

- Related work...
   - Use cases document has been adopted in TEAS
      draft-ietf-teas-pcecc-use-cases

Adrian

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 Mar 2017 15:19:14 -0400

WG,

    This is the 2nd (or 3rd) time the authors are stating that the
document is ready to LC  since it was adopted ~6months ago - without
there being any substantive discussion on the document within the WG and
only a minor update in December.  It's a little hard for us (chairs) to
know if silence is due to complete agreement with the document or simply
apathy.  From the message below, the authors clearly think it's the
former.  If you are *not* an author of this document and are willing to
share your opinion on this document, please do so -- preferably on the
list, but unicast to the chairs is also acceptable.  We will also ask
for feedback on the draft during the status portion of the meeting.

Thank you,

Lou (and Pavan)

On 3/22/2017 8:01 AM, Adrian Farrel wrote:
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Fri, 24 Mar 2017 10:31:59 +0000

We have already discussed "lively" the speculative statements in certain sections of this document.

To me, examples such as section 3.1.4 (and others) ...

   It may be the case that additional technology-
   specific parameters are needed to configure the NEs and these
   parameters will need to be carried in the PCEP messages

... continue to somehow contradict the expectation in Section 4 that extensions will be generic:

   The only work expected to be needed is small extensions
   to carry additional or specific information elements for the
   individual use cases.  Where possible, consistent with the general
   principles of how protocols are extended, any additions to the
   protocol should be made in a generic way such that they are open to
   use in a range of applications.

Having said this, maybe one could add some thoughts on increased PCEP protocol complexity (e.g., would it possible that the small PCEP extensions would require transaction and rollback support?), impact on running PCEP code, as well as implications on interoperability testing between implementations? This might partly be speculation, but manageability impact doesn't seem entirely unrealistic for some of the use cases considered in the document.

Thanks

Michael

> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Mittwoch, 22. März 2017 20:19
> To: [email-masked]; [email-masked]
> Subject: Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>
> 
> WG,
> 
>     This is the 2nd (or 3rd) time the authors are stating that the document is
> ready to LC  since it was adopted ~6months ago - without there being any
> substantive discussion on the document within the WG and only a minor
> update in December.  It's a little hard for us (chairs) to know if silence is due
> to complete agreement with the document or simply apathy.  From the
> message below, the authors clearly think it's the former.  If you are *not* an
> author of this document and are willing to share your opinion on this
> document, please do so -- preferably on the list, but unicast to the chairs is
> also acceptable.  We will also ask for feedback on the draft during the status
> portion of the meeting.
> 
> Thank you,
> 
> Lou (and Pavan)
> 
>

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 24 Mar 2017 13:33:34 +0000

Thanks Michael,

I have similar concerns. If there is a need for proprietary PCEP extensions to accommodate vendor specific semantics, how we will not end up with the same issues that have made GMPLS RSVP-TE/OSPF-TE, realistically speaking, uninteroperable? In other words, would you agree that applied to circuit switched technologies, PCEP has exact same probability for interoperability success as GMPLS? Note that for IP/MPLS networks there is no (or at least much less) potential PCEP interop problems, but IP/MPLS control plane has proved to be interoperable as well.

Igor     

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Scharf, Michael (Nokia - DE/Stuttgart)
Sent: Friday, March 24, 2017 6:32 AM
To: Lou Berger; [email-masked]; [email-masked]
Subject: Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>

Thanks

Michael

---

From: Lou Berger <[email-masked]>
Date: Fri, 24 Mar 2017 09:43:54 -0400

Thank you both for the additional input - would either of you care to
propose some specific text changes to address your comments/concerns?

Thanks,

Lou

---

From: Dieter Beller <[email-masked]>
Date: Fri, 24 Mar 2017 14:54:58 +0100

Hi Igor, all,

stating that GMPLS is "uninteroperable" is not correct! GMPLS
interoperability
across vendor domains has been demonstrated

multiple times with different participating vendors.

Thanks,

Dieter

On 24.03.2017 14:33, Igor Bryskin
wrote:

Thanks Michael,

Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Scharf, Michael (Nokia - DE/Stuttgart)
Sent: Friday, March 24, 2017 6:32 AM
To: Lou Berger; [email-masked]; [email-masked]
Subject: Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>

Thanks

Michael

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Mittwoch, 22. März 2017 20:19
To: [email-masked]; [email-masked]
Subject: Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>

WG,

Thank you,

Lou (and Pavan)

Hi,

- Related work...

Adrian

htt

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 24 Mar 2017 14:12:31 +0000

Dieter,

Note that I said "realistically speaking".
To be meaningful your email should contain examples of deployed multi-vendor (3 or more vendor) solutions interoping via GMPLS, as well GMPLS interoperability test events (rather than demos) starting from the most recent one.

Cheers,
Igor

From: Teas [mailto:[email-masked]] On Behalf Of Dieter Beller
Sent: Friday, March 24, 2017 9:55 AM
To: Igor Bryskin; Scharf, Michael (Nokia - DE/Stuttgart); Lou Berger; [email-masked]; [email-masked]
Subject: Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>

Hi Igor, all,

stating that GMPLS is "uninteroperable" is not correct! GMPLS interoperability across vendor domains has been demonstrated
multiple times with different participating vendors.

Thanks,
Dieter
On 24.03.2017 14:33, Igor Bryskin wrote:

Thanks Michael,

Igor

-----Original Message-----

To: Lou Berger; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Thanks

Michael

-----Original Message-----

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

WG,

portion of the meeting.

Thank you,

Lou (and Pavan)

Hi,

- Related work...

Adrian

Teas mailing list

[email-masked]<mailto:[email-masked]>

Teas mailing list

[email-masked]<mailto:[email-masked]>

Teas mailing list

[email-masked]<mailto:[email-masked]>

Teas mailing list

[email-masked]<mailto:[email-masked]>

htt

---

From: "Doolan, Paul (Coriant - US/Irving)" <[email-masked]>
Date: Fri, 24 Mar 2017 16:38:28 +0000

Hi Dieter,

you might want to start by Googling "huawei gmpls interoperability". Just a thought.

cheers,

pd

________________________________
From: Teas <[email-masked]> on behalf of Igor Bryskin <[email-masked]>
Sent: Friday, March 24, 2017 10:12 AM
To: Dieter Beller; Scharf, Michael (Nokia - DE/Stuttgart); Lou Berger; [email-masked]; [email-masked]
Subject: Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>

Dieter,

Note that I said “realistically speaking”.

Cheers,

Igor

Hi Igor, all,

Thanks,
Dieter

Thanks Michael,

Igor

-----Original Message-----

Thanks

Michael

-----Original Message-----

WG,

portion of the meeting.

Thank you,

Lou (and Pavan)

Hi,

- Related work...

Adrian

Teas mailing list

Teas mailing list

Teas mailing list

Teas mailing list

htt

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 24 Mar 2017 18:35:44 -0000

Hello Igor and Michael,

Thanks for the input.

To address the points in order...

Michael notes two pieces of text.
The first says that it *may* be the case that technology-specific extensions are
needed.
The second says two things:
- that only small extensions are expected 
- that any extensions should be made in a generic way if possible

I certainly don't see any contradiction in this text, but I would welcome having
it explained to me so it can be fixed.
I note that the final bullet is very consistent with the purpose of the TEAS
working group where protocol extensions to RSVP-TE are made in a generic way
where possible even if the motivation is for technology-specific use cases.

Michael then goes on to ask about several points
- Increased PCEP protocol complexity if transaction or rollback support
   would be needed.
   What can I say? This is an architecture not a requirements document,
   but I wonder why this question comes up now and not for the general
   question of PCE-initiated LSPs.
- The impact on running PCEP code
   Again, this is an architecture not a requirements or solutions document,
   but in order for this function to be supported I would assume that
   either the protocol extensions have to be backward compatible or that
   PCE and all interacting PCCs have to be upgraded.
- Implications on interoperability testing between implementations
   As in the previous bullet, this will surely depend on the way that the
   protocol extensions are made. I might expect that such extensions
   were covered in capability negotiations and made in such a way that
   unsupported function is discarded or rejected. 

An architecture does not typically try to constrain solutions, but I wouldn't
think it harmful to include a note on "Guidance for Solution Developers" that
could touch *lightly* on these points at least by pointing them out, but not
necessarily directing how they are handled.

Michael ends by asking about manageability impact. I find that difficult to
answer. This is a management architecture. It is all about management. So the
impact is that the management of the network would change. 

I confess that Section 6 seemed light when I wrote it. But what to add? What
would you like to see covered in addition?

Igor then enters the conversation by talking about proprietary PCEP extensions
to accommodate vendor specific semantics. I guess that makes me respond with two
questions:
1. How/why is this different from previous PCE-PCC interactions where PCCs could
be head ends in different vendor systems?
2. How/why is this different from GMPLS systems?

To the first question I would note RFC 7470 and
draft-dhody-pce-stateful-pce-vendor.

Now, for the second question, Igor goes on to claim that "meaningful" GMPLS
interop is questionable, and this may be true in certain optical environments
where the hardware itself struggles for meaningful interoperability. But that
fact has not detracted from the value of standardising GMPLS:
- as a base for proprietary extensions so that engineers, developers, and
   operators have a common understanding
- for technologies where interoperable hardware is possible

But maybe an even more important question is: How is this different from *any*
configuration system? Should we not standardise Netconf because the devices
configured will have different parameters? Should we abandon YANG because the
network devices will need different information? Perhaps we should all use
proprietary CLIs - that will be popular with the operators :-)

Surely the point here is to develop the technology and apply it where it can be
applied. If, as Igor clearly believes, this is only in a CO-PS environment, then
that will be fine. If there are some CO-CS environments where it works, that
will be a bonus. And if it acts as a common template for proprietary work from
different vendors, I don't see that that would be a bad thing.

- - - - -

Bottom line:
I can see two potential changes:
1. Guidance for Solution Developers
2. Management Considerations

Clearly, the authors need help with both of these.

See you in Chicago.
Adrian

--
Support an author and your imagination.
Tales from the Wood - Eighteen new fairy tales.
More Tales from the Wood - Eighteen MORE new fairy tales.
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.

> From: Igor Bryskin [mailto:[email-masked]]
> Sent: 24 March 2017 13:34
> To: Scharf, Michael (Nokia - DE/Stuttgart); Lou Berger; [email-masked];
> [email-masked]
> Subject: RE: [Teas] Status update on <draft-ietf-teas-pce-central-control>
> 
> Thanks Michael,
> 	
> I have similar concerns. If there is a need for proprietary PCEP extensions to
> accommodate vendor specific semantics, how we will not end up with the same
> issues that have made GMPLS RSVP-TE/OSPF-TE, realistically speaking,
> uninteroperable? In other words, would you agree that applied to circuit
> switched technologies, PCEP has exact same probability for interoperability
> success as GMPLS? Note that for IP/MPLS networks there is no (or at least much
> less) potential PCEP interop problems, but IP/MPLS control plane has proved to
> be interoperable as well.
> 
> Igor
> 
> From: Teas [mailto:[email-masked]] On Behalf Of Scharf, Michael (Nokia
-
> DE/Stuttgart)
> We have already discussed "lively" the speculative statements in certain
sections
> of this document.
> ... continue to somehow contradict the expectation in Section 4 that
extensions
> will be generic:
> Having said this, maybe one could add some thoughts on increased PCEP protocol
> complexity (e.g., would it possible that the small PCEP extensions would
require
> transaction and rollback support?), impact on running PCEP code, as well as
> implications on interoperability testing between implementations? This might
> partly be speculation, but manageability impact doesn't seem entirely
unrealistic
> for some of the use cases considered in the document.

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 24 Mar 2017 19:50:55 +0000

Hi Adrian,

Please, see my comments to your responses to my comments:=)

[Skipped]

IB>> as you correctly interpreted my point of view: works for IP/MPLS, not so much for l0/l1 (similarly to standard RSVP-TE working fine for former, but realistically speaking, not for latter)

2. How/why is this different from GMPLS systems?
IB>> exactly (as mentioned above)

IB>> The solution is really interoperable, if there is a commercial proof to that end, not because RFC XYZ exists claiming the solution is possible. Interop demo is not good enough because one yet to see a demo that has failed :=)

IB>> Basically, as kind of a recipe book for cooking (try that, you may add more salt or nuts or brandy if you like, after all it is your cake, only your guests will appreciate it);
  
IB>> See below

IB>> The difference is that when PCEP communicates to a head end to set up e2e LSP which might go through multiple domains, this is a network wide operation. No one said that Netconf should not be standardized for device level configuration. But you want to avoid a situation when a teacher communicates with each student of a multi-lingual class in the student's own native language. This would be not sustainable regardless whether the teacher speaks (e.g. via PCEP) or writes (e.g. via NetConf) to each student, especially considering that at any moment a new student might show up speaking yet another language  

IB>> As a matter of fact I did what Paul suggested.
When I google-searched "gmpls+interoperability+deployments", one of the hits near the top of the search result list was a pointer to an article written by three Stanford University folks: "Why OpenFlow/SDN Can Succeed Where GMPLS Failed". 
I am not a fan of OpenFlow at all, but I somewhat agree with what they say WRT GMPLS and believe the same is true WRT PCEP based architectures:

"...But GMPLS has failed in terms of actual deployment in wide area networks. It has undergone a lengthy standardization process at the ITU, IETF and OIF; all transport equipment vendors have implemented it in their switches; there have been many interoperability demonstrations; and yet after a decade [ IB>> actually 18 years now], there hasn't been even one significant commercial deployment of GMPLS as a UCP [IB: Unified Control Plane]. GMPLS may have found use in a limited way as a tool to help the NMS/EMS provision a circuit after being triggered manually by the management system. But we are not interested in such use of GMPLS. Such use has a) nothing to do with IP networks; and b) nothing to do even with the ASON view of using GMPLS as an interoperable transport control plane. Rather this use of GMPLS is merely a proprietary vendor implementation of a control plane (in ASON parlance - a vendor-island I-NNI)..."

Igor

-
sections
extensions
require
unrealistic

---

From: Gert Grammel <[email-masked]>
Date: Fri, 24 Mar 2017 21:54:03 +0000

Whether GMPLS is "realistically interoperable" is certainly worth to debate. By doing so however we have to keep in mind that GMPLS is a control plane for a non-IP data plane.

When CCAMP set out to work on GMPLS for WDM (WSON) we might have had asked how many of interoperable (non proprietary) DWDM implementations do exist.
How much leverage you can have from an interoperable control plane when the photons have a hard time to find their way between different vendors?

Fortunately the IP data plane is in a better shape as this email will certainly travel through dozens of vendor domains and a handful of carrier domains, each potentially structured in a few operational domains.

In other words, lgor's statement that GMPLS is not field proven (using a different term here) to interoperate looks correct. The question is now what's next:
1) screw the whole thing since the world doesn't need a standard for protocols that do not interoperate.
2) fix whatever is needed to interoperate (and this requires data plane interoperate too)
3) accept the facts and muddle through by pretending interoperability would be feasible and adding vendor specific loopholes to decrease the probability we'll ever get there.

Perhaps a discussion worth to have together with CCAMP.

Gert

Get Outlook for iOS<https://aka.ms/o0ukef>

_____________________________
From: Doolan, Paul (Coriant - US/Irving) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, March 24, 2017 9:38 AM
Subject: Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>
To: <[email-masked]<mailto:[email-masked]>>, Igor Bryskin <[email-masked]<mailto:[email-masked]>>, Dieter Beller <[email-masked]<mailto:[email-masked]>>, Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Lou Berger <[email-masked]<mailto:[email-masked]>>

Hi Dieter,

cheers,

pd

________________________________
From: Teas <[email-masked]<mailto:[email-masked]>> on behalf of Igor Bryskin <[email-masked]<mailto:[email-masked]>>
Sent: Friday, March 24, 2017 10:12 AM
To: Dieter Beller; Scharf, Michael (Nokia - DE/Stuttgart); Lou Berger; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>

Dieter,

Cheers,

Igor

From: Teas [mailto:[email-masked]]On Behalf Of Dieter Beller
Sent: Friday, March 24, 2017 9:55 AM
To: Igor Bryskin; Scharf, Michael (Nokia - DE/Stuttgart); Lou Berger; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>

Hi Igor, all,

Thanks,
Dieter

Thanks Michael,

Igor

-----Original Message-----

Thanks

Michael

-----Original Message-----

WG,

portion of the meeting.

Thank you,

Lou (and Pavan)

Hi,

- Related work...

Adrian

Teas mailing list

Teas mailing list

Teas mailing list

Teas mailing list

htt

---

From: Igor Bryskin <[email-masked]>
Date: Sat, 25 Mar 2017 15:09:42 +0000

One option is to accept that GMPLS and PCEP are, generally speaking, not interoperable, allow fot unconstrained intradomain innovations via vendor specific extensions and solve the interoperability problem by some other means, for example, via standartized explici model based NBIs. This is pretty much what ACTN suggests to do.

Igor

From:Gert Grammel
To:[email-masked],Dieter Beller,Scharf, Michael (Nokia - DE/Stuttgart),Doolan, Paul (Coriant - US/Irving),Igor Bryskin,Lou Berger,[email-masked],
Date:2017-03-24 17:54:23
Subject:Re: [Teas] Status update on

Gert

Hi Dieter,

cheers,

pd

Dieter,

Cheers,

Igor

Hi Igor, all,

Thanks,
Dieter

Thanks Michael,

Igor

-----Original Message-----

Thanks

Michael

-----Original Message-----

WG,

portion of the meeting.

Thank you,

Lou (and Pavan)

Hi,

- Related work...

Adrian

Teas mailing list

Teas mailing list

Teas mailing list

Teas mailing list

htt

---

From: Gert Grammel <[email-masked]>
Date: Sat, 25 Mar 2017 16:26:13 +0000

Hi Igor,

I understand you are asking for something like option 3) although the exact wording needs to be settled.

Thanks

Gert

_____________________________
From: Igor Bryskin <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, March 25, 2017 8:10 AM
Subject: Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Igor Bryskin <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Gert Grammel <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>

Igor

From:Gert Grammel
To:[email-masked]<mailto:[email-masked]>,Dieter Beller,Scharf, Michael (Nokia - DE/Stuttgart),Doolan, Paul (Coriant - US/Irving),Igor Bryskin,Lou Berger,[email-masked]<mailto:[email-masked]>,
Date:2017-03-24 17:54:23
Subject:Re: [Teas] Status update on

Gert

Hi Dieter,

cheers,

pd

Dieter,

Cheers,

Igor

Hi Igor, all,

Thanks,
Dieter

Thanks Michael,

Igor

-----Original Message-----

Thanks

Michael

-----Original Message-----

WG,

portion of the meeting.

Thank you,

Lou (and Pavan)

Hi,

- Related work...

Adrian

Teas mailing list

Teas mailing list

Teas mailing list

Teas mailing list

htt

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Sat, 25 Mar 2017 17:10:15 +0000

Hi Adrian,

Thanks a lot for your reply. Regarding my points  ...

> The first says that it *may* be the case that technology-specific extensions
> are needed.

Note that I have just used Section 3.1.4 as *one example*. I have just picked this because for T-SDN, depending on the use case, quite a number of technology-specific parameters could be needed. I think the document does not explain well why *small* changes to PCEP could be sufficient for T-SDN. And it also does not discuss to which extent they could be generic, and what this would mean in reality.

A very similar problem also exists for Section 3.2.3, as this section also mentions complex technology for which it is not necessarily trivial to define generic, technology-independent solutions. Section 3.2.2 is yet another example that can be challenging in reality, e.g., if the exact capabilities of the device could matter.
 
> - that any extensions should be made in a generic way if possible

Well, in the IETF we typically build protocols that are extensible and we always try to make the design generic.

> I certainly don't see any contradiction in this text, but I would welcome
> having it explained to me so it can be fixed.

I continue to struggle with the wording "small extension". If I think of what extensions could be possible for some of the use cases mentioned in the document, I could imagine significant additions to the PCEP protocol engine, e.g., new messages, additional states, a huge number of new attributes, etc. 

To me, it would help to better quantify the word "small". It is a bit difficult for me to propose wording given the huge scope of the use cases, but the following would to me at least a little bit better than what the text states right now:
 
   ...
   The only work expected to be needed is small extensions
   to carry additional or specific information elements for the
   individual use cases, which maintain backward compatibility
   and do not impact existing PCEP deployments.
   ...

> working group where protocol extensions to RSVP-TE are made in a generic
> way where possible even if the motivation is for technology-specific use
> cases.
> 
> 

>From my point of view, the document discusses network configuration use cases that could require data models more complex than what is needed for PCE-initiated LSPs.

>    PCE and all interacting PCCs have to be upgraded.

This is good protocol design practice, but since PCCs are already deployed it might be worth-wile to mention that. 

There could also be impact on robustness (new functions added to the PCEP implementation), security (potentially new attach vectors resulting from the new use cases), etc.

Since PCEP is essential for network stability, wouldn't it make sense to discuss this impact of the architecture?

>    unsupported function is discarded or rejected.

My concern is how to maintain interoperability between different implementations, which currently seem to exists for PCEP for MPLS/IP.

I could imagine implications such as...

* Future interoperability tests for PCEP have to cover new use cases and e.g. include testing for the protocol extensions and additional information attributes, which may increase the total effort of testing 

* Existing interoperability tests for PCEP implementations may have to be repeated to confirm that already interoperable implementations are still interoperable after adding new extensions

I mention this since, for our customers, the key motivation for SDN solutions is typically interoperability. And since the document mentions "SDN" in the first sentence of the abstract, I believe such a discussion is in scope of the document. 

> necessarily directing how they are handled.

Indeed, albeit I believe some discussion on the potential challenges of PCEP extensions could also be homed in Section 4 or 6.

> answer. This is a management architecture. It is all about management. So
> the impact is that the management of the network would change.
>

The impact on interoperability of existing PCEP implementations and a discussion how to ensure this interoperability in future might fit in here, no?
 
Michael

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 25 Mar 2017 19:22:48 -0000

Thanks Michael,

I don't agree with all the points you make, but thanks for the advice on
designing network protocols. I guess I am learning all the time.

With regard to...

> Indeed, albeit I believe some discussion on the potential challenges of PCEP
> extensions could also be homed in Section 4 or 6.
> 
> The impact on interoperability of existing PCEP implementations and a
discussion
> how to ensure this interoperability in future might fit in here, no?

Great.
We'll wait for your text.

Thanks,
Adrian

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Sat, 25 Mar 2017 20:24:49 +0000

Hi Adrian

> designing network protocols. I guess I am learning all the time.

Which specific comments do you not agree with?

> > > could touch *lightly* on these points at least by pointing them out,
> > > but not necessarily directing how they are handled.
> >
> > Indeed, albeit I believe some discussion on the potential challenges
> > of PCEP extensions could also be homed in Section 4 or 6.
> >
> > > Michael ends by asking about manageability impact. I find that
> > > difficult to answer. This is a management architecture. It is all
> > > about management. So the impact is that the management of the
> network would change.
> > >
> > > I confess that Section 6 seemed light when I wrote it. But what to
> > > add? What would you like to see covered in addition?
> >

Regarding the interoperability issue specifically, one option would be to add to Section "4.  Protocol Implications" something like ...

  Protocol extensions could have impact on existing PCEP deployments and the interoperability between different implementations. It is anticipated that changes of the PCEP protocol or addition of information elements could require additional testing to ensure interoperability between different PCEP implementations.

Does this make sense? Or do I miss something?

Michael