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

["Adrian Farrel" <[e-mail]>]

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.




> -----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.