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

[Igor Bryskin <[e-mail]>]

Hi Adrian,

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

[Skipped]

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?
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)

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

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 :=)

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
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);
  
- for technologies where interoperable hardware is possible
IB>> See below

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 :-)

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  

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.

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






> -----Original Message-----
> From: Igor Bryskin [mailto:[e-mail]]
> Sent: 24 March 2017 13:34
> To: Scharf, Michael (Nokia - DE/Stuttgart); Lou Berger; [e-mail];
> [e-mail]
> 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
> 
> -----Original Message-----
> From: Teas [mailto:[e-mail]] On Behalf Of Scharf, Michael (Nokia
-
> DE/Stuttgart)
> Sent: Friday, March 24, 2017 6:32 AM
> To: Lou Berger; [e-mail]; [e-mail]
> Subject: Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>
> 
> 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.