Re: [Pce] Whither Stateless PCE?

[<[e-mail]>]

> whatever the solution we choose, we need new release, so new version of firmware in the routers and new software for the PCE

Yes but some changes can be introduced as easy fix while introducing NO-PATH may not be so trivial from a coding point of view (leading to not being able to be introduced in minor release as a fix).
Moreover as already told, introducing new things is possible as long as we do not break what is working today (between some implementations, even if not all).

Introducing NO-PATH is possible if we still support the “old” approach using empty ERO (so both can be used) => everyone will have to fix.

From: Pce [mailto:[e-mail]] On Behalf Of Olivier Dugeon
Sent: Thursday, September 08, 2016 15:10
To: Robert Varga; Ina Minei
Cc: [e-mail]
Subject: Re: [Pce] Whither Stateless PCE?

Hello Robert,
Le 08/09/2016 11:38, Robert Varga a écrit :

On 09/07/2016 05:57 PM, Ina Minei wrote:

I think if we replace MUST with SHOULD in the text you provided that

would work for the transition. Can implementors comment on the impact?



The change in PCRpt format is incompatible with fielded installations.



OpenDaylight will refuse a PCRpt consisting of (LSP, NO-PATH) and will

raise an Mandatory Object Missing PCErr, leading to failure to perform

initial state synchronization. The requirement has been there since

revision 05 (at least) and has been clarified in revision 16.
Agree. But, as we face to some interoperability issues between various implementation, whatever the solution we choose, we need new release, so new version of firmware in the routers and new software for the PCE. So, I prefer to have a clear fix without any ambiguity instead of patch what wil continue to be subject to misinterpretation.

Regarding OpenDayLight, I think that the modification is not too huge:

Add NO-PATH object in 'path-definition' group in pcep-types.yang (line 1027 - 1031)

    grouping path-definition {
        uses explicit-route-object;
+      uses no-path-object;
        uses lsp-attributes;
    }

Or if you prefer

    grouping path-definition {
+        choice report-path {
+            mandatory true;
+
+        case ero {
            uses explicit-route-object;
+        }
+
+        case no-path {
+           uses no-path-object;
+        }
        uses lsp-attributes;
    }

I also look at the Stateful07TopologySessionListener() class where the PCRpt is handle. At any moment the code check that there is a valid ERO (i.e. method buildPath() line 389 and following). I also made some tests with Juniper router with RSVP-TE tunnel setup and delegated, but without an explicit route set in the config. The Juniper router report the tunnel through a PCRpt message without ERO. Just an RRO. And this is correctly handle by OpenDayLight.

So, for me there is no much issue in OpenDayLight no manage NO-PATH Object.

Regards

Olivier




Bye,

Robert




_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.