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

["Scharf, Michael (Nokia - DE/Stuttgart)" <[e-mail]>]

Hi Adrian,

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

> Michael notes two pieces of text.
> 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.
 
> The second says two things:
> - that only small extensions are expected
> - 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.
   ...

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

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

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

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?

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

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. 

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

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?

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