PCEP between Nokia 7750 SR and Fluorine


Andrii Elperin
 

Hello,

Right now I'm testing interoperability between PCEP implementation in Nokia 7750 SR routers and ODL.

Software versions:
7750 SR: TimOS 16.0.R6
ODL: Fluorine SR2

Java:
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

7750 SR configured as PCC, ODL is configured as PCE.

Looks like I'm observing quite serious issues from the very beginning.

1. PCRpt messages processing. When 7750 reporting some new LSP (PCC initiated, PCC controlled) ODL can process PCRpt messages and add corresponding LSPs to LSP-DB, but in any case it will throw a bunch of PCErr messages in return. All PCerr are the same - "LSP Object missing". And of course this object is actually present (ODL can't parse it correctly ?). I made capture of traffic exchange between PCC and PCEP (starting from PCEP session establishment) to illustrate this issue. Logs from PCE side are present as well. There are two files attached - 190321_pcrpt.pcap, 190321_pcrpt_odl.log

2. PCReq messages from 7750 can't be parsed at all by ODL. All I can get is "Failed to decode protocol message" in ODL logs. Again I made capture of traffic exchange between PCC and PCE and collected logs from ODL side. There are two files attached - 190321_pcreq.pcap, 190321_pcreq_odl.log

Maybe somebody can look in my pcaps/logs and give me some advices ? I'm already in touch with TimOS developers but any comments from ODL community are appreciated. Maybe some bugfixes are needed in ODL as well ?

--
/me from somewhere


Ajay Lele
 

Hi Andrey

Problem appears to be happening because message from device has some objects which are not expected there

On Fri, Mar 22, 2019 at 2:45 AM Andrey Elperin <mizzy@...> wrote:

  Hello,

  Right now I'm testing interoperability between PCEP implementation in
Nokia 7750 SR routers and ODL.

  Software versions:
  7750 SR: TimOS 16.0.R6
  ODL: Fluorine SR2

  Java:
  openjdk version "1.8.0_181"
  OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
  OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

  7750 SR configured as PCC, ODL is configured as PCE.

  Looks like I'm observing quite serious issues from the very beginning.

  1. PCRpt messages processing. When 7750 reporting some new LSP (PCC
initiated, PCC controlled) ODL can process PCRpt messages and add
corresponding LSPs to LSP-DB, but in any case it will throw a bunch of
PCErr messages in return. All PCerr are the same - "LSP Object missing".
And of course this object is actually present (ODL can't parse it
correctly ?). I made capture of traffic exchange between PCC and PCEP
(starting from PCEP session establishment) to illustrate this issue.
Logs from PCE side are present as well. There are two files attached -
190321_pcrpt.pcap, 190321_pcrpt_odl.log

Expected format for PCRpt is here: https://tools.ietf.org/html/rfc8231#page-25. Message in attached pcap has LSPA/BANDWIDTH/METRIC objects after RRO object which is not expected
 

  2. PCReq messages from 7750 can't be parsed at all by ODL. All I can
get is "Failed to decode protocol message" in ODL logs. Again I made
capture of traffic exchange between PCC and PCE and collected logs from
ODL side. There are two files attached - 190321_pcreq.pcap,
190321_pcreq_odl.log

Expected format for PCReq is here: https://tools.ietf.org/html/rfc5440#page-19. Message in attached pcap has LSP object after END-POINTS object which is not expected there 

Regards
Ajay


  Maybe somebody can look in my pcaps/logs and give me some advices ? I'm
already in touch with TimOS developers but any comments from ODL
community are appreciated. Maybe some bugfixes are needed in ODL as well
?

--
/me from somewhere_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users


Andrii Elperin
 

Hi Ajay,

Thank you very much for an answer. 

I’m a bit surprised about expected PCReq format. According to the docs, ODL PCEP plugin supports draft-ietf-pce-pce-initiated-lsp
and there is the following statement here:


   The definition of the PCReq message from [RFC5440] is extended to
   optionally include the LSP object after the END-POINTS object.

Is it not implemented in parser ?

In the meanwhile I did some additional searches in bgpcep-dev archives and found this topic:

with the following statement:

>> The protocol implementation, pcep-impl, does fully support RFC5440. 
>> The default ODL application, pcep-topology-provider, supports only 
>> 
active stateful PCE mode of operation and does not include support 
>> for PCC-initiated path computation.

Is it still true for the latest PCEP plugin version ? If yes - I can assume that ODL won’t be able to respond to PCReq’s anyway.

--
/me from somewhere

1 квіт. 2019 р. о 22:53 Ajay Lele <ajayslele@...> написав(ла):

Hi Andrey

Problem appears to be happening because message from device has some objects which are not expected there

On Fri, Mar 22, 2019 at 2:45 AM Andrey Elperin <mizzy@...> wrote:

  Hello,

  Right now I'm testing interoperability between PCEP implementation in 
Nokia 7750 SR routers and ODL.

  Software versions:
  7750 SR: TimOS 16.0.R6
  ODL: Fluorine SR2

  Java:
  openjdk version "1.8.0_181"
  OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
  OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

  7750 SR configured as PCC, ODL is configured as PCE.

  Looks like I'm observing quite serious issues from the very beginning.

  1. PCRpt messages processing. When 7750 reporting some new LSP (PCC 
initiated, PCC controlled) ODL can process PCRpt messages and add 
corresponding LSPs to LSP-DB, but in any case it will throw a bunch of 
PCErr messages in return. All PCerr are the same - "LSP Object missing". 
And of course this object is actually present (ODL can't parse it 
correctly ?). I made capture of traffic exchange between PCC and PCEP 
(starting from PCEP session establishment) to illustrate this issue. 
Logs from PCE side are present as well. There are two files attached - 
190321_pcrpt.pcap, 190321_pcrpt_odl.log

Expected format for PCRpt is here: https://tools.ietf.org/html/rfc8231#page-25. Message in attached pcap has LSPA/BANDWIDTH/METRIC objects after RRO object which is not expected
 

  2. PCReq messages from 7750 can't be parsed at all by ODL. All I can 
get is "Failed to decode protocol message" in ODL logs. Again I made 
capture of traffic exchange between PCC and PCE and collected logs from 
ODL side. There are two files attached - 190321_pcreq.pcap, 
190321_pcreq_odl.log

Expected format for PCReq is here: https://tools.ietf.org/html/rfc5440#page-19. Message in attached pcap has LSP object after END-POINTS object which is not expected there 

Regards
Ajay


  Maybe somebody can look in my pcaps/logs and give me some advices ? I'm 
already in touch with TimOS developers but any comments from ODL 
community are appreciated. Maybe some bugfixes are needed in ODL as well 
?

-- 
/me from somewhere_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users


Olivier Dugeon
 

Hello Andrey,

Your PCReq message is correctly formatted as per RFC8231. However, LSP Object has been introduced in RFC8231 and added to the PCReq grammar while ODL support only PCReq from RFC5440 which define only LSPA Object. Thus, you got an error from ODL while your message is correct.

In addition, if PCReq messages are parsed by ODL there are not properly handle. What you get is only a message in the log telling that a PCReq message has been received but flag as "unsupported message". And you do not receive any answer which is not conform to RFC5440. At least you must get a PCRep message with a NO-PATH Object or a PCErr message.

BTW, we develop a full implementation of RFC5440 & RFC5441 for ODL. PCReq messages are handle and if you use BGP-LS our code is able to compute path. We are currently under code review process before submitting our patch. We have already open a JIRA ticket for that: https://jira.opendaylight.org/browse/BGPCEP-858 . From what you experienced with your test, I understand that we must also update the PCReq message parser in order to support LSP Object as per RFC8231 in complement to RFC5440 Objects.

Regards

Olivier


Le 03/04/2019 à 01:18, Andrey Elperin a écrit :
Hi Ajay,

Thank you very much for an answer. 

I’m a bit surprised about expected PCReq format. According to the docs, ODL PCEP plugin supports draft-ietf-pce-pce-initiated-lsp
and there is the following statement here:


   The definition of the PCReq message from [RFC5440] is extended to
   optionally include the LSP object after the END-POINTS object.

Is it not implemented in parser ?

In the meanwhile I did some additional searches in bgpcep-dev archives and found this topic:

with the following statement:

>> The protocol implementation, pcep-impl, does fully support RFC5440. 
>> The default ODL application, pcep-topology-provider, supports only 
>> 
active stateful PCE mode of operation and does not include support 
>> for PCC-initiated path computation.

Is it still true for the latest PCEP plugin version ? If yes - I can assume that ODL won’t be able to respond to PCReq’s anyway.

--
/me from somewhere

1 квіт. 2019 р. о 22:53 Ajay Lele <ajayslele@...> написав(ла):

Hi Andrey

Problem appears to be happening because message from device has some objects which are not expected there

On Fri, Mar 22, 2019 at 2:45 AM Andrey Elperin <mizzy@...> wrote:

  Hello,

  Right now I'm testing interoperability between PCEP implementation in 
Nokia 7750 SR routers and ODL.

  Software versions:
  7750 SR: TimOS 16.0.R6
  ODL: Fluorine SR2

  Java:
  openjdk version "1.8.0_181"
  OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
  OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

  7750 SR configured as PCC, ODL is configured as PCE.

  Looks like I'm observing quite serious issues from the very beginning.

  1. PCRpt messages processing. When 7750 reporting some new LSP (PCC 
initiated, PCC controlled) ODL can process PCRpt messages and add 
corresponding LSPs to LSP-DB, but in any case it will throw a bunch of 
PCErr messages in return. All PCerr are the same - "LSP Object missing". 
And of course this object is actually present (ODL can't parse it 
correctly ?). I made capture of traffic exchange between PCC and PCEP 
(starting from PCEP session establishment) to illustrate this issue. 
Logs from PCE side are present as well. There are two files attached - 
190321_pcrpt.pcap, 190321_pcrpt_odl.log

Expected format for PCRpt is here: https://tools.ietf.org/html/rfc8231#page-25. Message in attached pcap has LSPA/BANDWIDTH/METRIC objects after RRO object which is not expected
 

  2. PCReq messages from 7750 can't be parsed at all by ODL. All I can 
get is "Failed to decode protocol message" in ODL logs. Again I made 
capture of traffic exchange between PCC and PCE and collected logs from 
ODL side. There are two files attached - 190321_pcreq.pcap, 
190321_pcreq_odl.log

Expected format for PCReq is here: https://tools.ietf.org/html/rfc5440#page-19. Message in attached pcap has LSP object after END-POINTS object which is not expected there 

Regards
Ajay


  Maybe somebody can look in my pcaps/logs and give me some advices ? I'm 
already in touch with TimOS developers but any comments from ODL 
community are appreciated. Maybe some bugfixes are needed in ODL as well 
?

-- 
/me from somewhere_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users



_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users

_________________________________________________________________________________________________________________________

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.


Olivier Dugeon
 

Hi Andrey,

And for the second problem with the PCRpt message, LSPA/BANDWIDTH/METRICS could be associated with the ERO Object only. Not with RRO.

I already made some tests with Juniper and Cisco router where these objects are announced with ERO and correctly parse & handle by ODL.

Regards

Olivier


Le 03/04/2019 à 13:07, Olivier Dugeon a écrit :

Hello Andrey,

Your PCReq message is correctly formatted as per RFC8231. However, LSP Object has been introduced in RFC8231 and added to the PCReq grammar while ODL support only PCReq from RFC5440 which define only LSPA Object. Thus, you got an error from ODL while your message is correct.

In addition, if PCReq messages are parsed by ODL there are not properly handle. What you get is only a message in the log telling that a PCReq message has been received but flag as "unsupported message". And you do not receive any answer which is not conform to RFC5440. At least you must get a PCRep message with a NO-PATH Object or a PCErr message.

BTW, we develop a full implementation of RFC5440 & RFC5441 for ODL. PCReq messages are handle and if you use BGP-LS our code is able to compute path. We are currently under code review process before submitting our patch. We have already open a JIRA ticket for that: https://jira.opendaylight.org/browse/BGPCEP-858 . From what you experienced with your test, I understand that we must also update the PCReq message parser in order to support LSP Object as per RFC8231 in complement to RFC5440 Objects.

Regards

Olivier


Le 03/04/2019 à 01:18, Andrey Elperin a écrit :
Hi Ajay,

Thank you very much for an answer. 

I’m a bit surprised about expected PCReq format. According to the docs, ODL PCEP plugin supports draft-ietf-pce-pce-initiated-lsp
and there is the following statement here:


   The definition of the PCReq message from [RFC5440] is extended to
   optionally include the LSP object after the END-POINTS object.

Is it not implemented in parser ?

In the meanwhile I did some additional searches in bgpcep-dev archives and found this topic:

with the following statement:

>> The protocol implementation, pcep-impl, does fully support RFC5440. 
>> The default ODL application, pcep-topology-provider, supports only 
>> 
active stateful PCE mode of operation and does not include support 
>> for PCC-initiated path computation.

Is it still true for the latest PCEP plugin version ? If yes - I can assume that ODL won’t be able to respond to PCReq’s anyway.

--
/me from somewhere

1 квіт. 2019 р. о 22:53 Ajay Lele <ajayslele@...> написав(ла):

Hi Andrey

Problem appears to be happening because message from device has some objects which are not expected there

On Fri, Mar 22, 2019 at 2:45 AM Andrey Elperin <mizzy@...> wrote:

  Hello,

  Right now I'm testing interoperability between PCEP implementation in 
Nokia 7750 SR routers and ODL.

  Software versions:
  7750 SR: TimOS 16.0.R6
  ODL: Fluorine SR2

  Java:
  openjdk version "1.8.0_181"
  OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
  OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

  7750 SR configured as PCC, ODL is configured as PCE.

  Looks like I'm observing quite serious issues from the very beginning.

  1. PCRpt messages processing. When 7750 reporting some new LSP (PCC 
initiated, PCC controlled) ODL can process PCRpt messages and add 
corresponding LSPs to LSP-DB, but in any case it will throw a bunch of 
PCErr messages in return. All PCerr are the same - "LSP Object missing". 
And of course this object is actually present (ODL can't parse it 
correctly ?). I made capture of traffic exchange between PCC and PCEP 
(starting from PCEP session establishment) to illustrate this issue. 
Logs from PCE side are present as well. There are two files attached - 
190321_pcrpt.pcap, 190321_pcrpt_odl.log

Expected format for PCRpt is here: https://tools.ietf.org/html/rfc8231#page-25. Message in attached pcap has LSPA/BANDWIDTH/METRIC objects after RRO object which is not expected
 

  2. PCReq messages from 7750 can't be parsed at all by ODL. All I can 
get is "Failed to decode protocol message" in ODL logs. Again I made 
capture of traffic exchange between PCC and PCE and collected logs from 
ODL side. There are two files attached - 190321_pcreq.pcap, 
190321_pcreq_odl.log

Expected format for PCReq is here: https://tools.ietf.org/html/rfc5440#page-19. Message in attached pcap has LSP object after END-POINTS object which is not expected there 

Regards
Ajay


  Maybe somebody can look in my pcaps/logs and give me some advices ? I'm 
already in touch with TimOS developers but any comments from ODL 
community are appreciated. Maybe some bugfixes are needed in ODL as well 
?

-- 
/me from somewhere_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users



_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users


_________________________________________________________________________________________________________________________

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.


Andrii Elperin
 

Hi Olivier,


It's a very good news that you already have a working full implementation of RFC5440. If I can somehow help you with testing of this code in our environment (we have a plenty of Nokia and Huawei routers) - I'll be glad to help.


_Passive_ stateful PCE (RSVP-TE) using BGP-LS - it's the first setup I'm trying to test. Looks like that absence of path computation in current ODL release is the main showstopper for this test.


olivier.dugeon@... писал 03.04.2019 14:07:

Hello Andrey,

Your PCReq message is correctly formatted as per RFC8231. However, LSP Object has been introduced in RFC8231 and added to the PCReq grammar while ODL support only PCReq from RFC5440 which define only LSPA Object. Thus, you got an error from ODL while your message is correct.

In addition, if PCReq messages are parsed by ODL there are not properly handle. What you get is only a message in the log telling that a PCReq message has been received but flag as "unsupported message". And you do not receive any answer which is not conform to RFC5440. At least you must get a PCRep message with a NO-PATH Object or a PCErr message.

BTW, we develop a full implementation of RFC5440 & RFC5441 for ODL. PCReq messages are handle and if you use BGP-LS our code is able to compute path. We are currently under code review process before submitting our patch. We have already open a JIRA ticket for that: https://jira.opendaylight.org/browse/BGPCEP-858 . From what you experienced with your test, I understand that we must also update the PCReq message parser in order to support LSP Object as per RFC8231 in complement to RFC5440 Objects.

Regards

Olivier


Le 03/04/2019 à 01:18, Andrey Elperin a écrit :
Hi Ajay,
 
Thank you very much for an answer. 
 
I'm a bit surprised about expected PCReq format. According to the docs, ODL PCEP plugin supports draft-ietf-pce-pce-initiated-lsp
and there is the following statement here:
 
 
   The definition of the PCReq message from [RFC5440] is extended to
   optionally include the LSP object after the END-POINTS object.
 
Is it not implemented in parser ?

In the meanwhile I did some additional searches in bgpcep-dev archives and found this topic:

with the following statement:

>> The protocol implementation, pcep-impl, does fully support RFC5440. 
>> The default ODL application, pcep-topology-provider, supports only 
>> 
active stateful PCE mode of operation and does not include support 
>> for PCC-initiated path computation.

Is it still true for the latest PCEP plugin version ? If yes - I can assume that ODL won't be able to respond to PCReq's anyway.

--
/me from somewhere

1 квіт. 2019 р. о 22:53 Ajay Lele <ajayslele@...> написав(ла):

Hi Andrey
 
Problem appears to be happening because message from device has some objects which are not expected there

On Fri, Mar 22, 2019 at 2:45 AM Andrey Elperin <mizzy@...> wrote:

  Hello,

  Right now I'm testing interoperability between PCEP implementation in 
Nokia 7750 SR routers and ODL.

  Software versions:
  7750 SR: TimOS 16.0.R6
  ODL: Fluorine SR2

  Java:
  openjdk version "1.8.0_181"
  OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
  OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

  7750 SR configured as PCC, ODL is configured as PCE.

  Looks like I'm observing quite serious issues from the very beginning.

  1. PCRpt messages processing. When 7750 reporting some new LSP (PCC 
initiated, PCC controlled) ODL can process PCRpt messages and add 
corresponding LSPs to LSP-DB, but in any case it will throw a bunch of 
PCErr messages in return. All PCerr are the same - "LSP Object missing". 
And of course this object is actually present (ODL can't parse it 
correctly ?). I made capture of traffic exchange between PCC and PCEP 
(starting from PCEP session establishment) to illustrate this issue. 
Logs from PCE side are present as well. There are two files attached - 
190321_pcrpt.pcap, 190321_pcrpt_odl.log
 
Expected format for PCRpt is here: https://tools.ietf.org/html/rfc8231#page-25. Message in attached pcap has LSPA/BANDWIDTH/METRIC objects after RRO object which is not expected
 

  2. PCReq messages from 7750 can't be parsed at all by ODL. All I can 
get is "Failed to decode protocol message" in ODL logs. Again I made 
capture of traffic exchange between PCC and PCE and collected logs from 
ODL side. There are two files attached - 190321_pcreq.pcap, 
190321_pcreq_odl.log
 
Expected format for PCReq is here: https://tools.ietf.org/html/rfc5440#page-19. Message in attached pcap has LSP object after END-POINTS object which is not expected there 
 
Regards
Ajay
 

  Maybe somebody can look in my pcaps/logs and give me some advices ? I'm 
already in touch with TimOS developers but any comments from ODL 
community are appreciated. Maybe some bugfixes are needed in ODL as well 
?

-- 
/me from somewhere_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users


_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users

_________________________________________________________________________________________________________________________

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.


--
/me from somewhere


Andrii Elperin
 

Hi Olivier,


Yes, I already figured out root cause of this problem. By default SR OS PCEP implementation is configured with "report-path-constraints" knob, which means:

---------------------------------------------

This command enables the inclusion of LSP path constraints in the PCE report messages sent from the PCC to a PCE.

In order for the PCE to know about the original constraints for an LSP that is delegated but for which there is no prior state in its LSP database; for example, if no PCReq message was sent for the same PLSP-ID, the following proprietary behavior is observed:

  1. the PCC appends a duplicate of each of the LSPA, metric, and bandwidth objects in the PCRpt message. The only difference between two objects of the same type is that the P-flag is set in the common header of the duplicate object to indicate that it is a mandatory object for processing by the PCE.
  2. the value of the metric or bandwidth in the duplicate object contains the original constraint value, while the first object contains the operational value. This is applicable to hop metrics in the metric and bandwidth objects only. The 7705 SAR PCC does not support configuring a boundary on the path computation IGP or TE metrics.
  3. the path computation on the PCE must use the first set of objects when updating a path if the PCRpt message contained a single set. If the PCRpt message contained a duplicate set, PCE path computation must use the constraints in the duplicate set.

---------------------------------------------


When this proprietary behaviour is disabled - ODL can pasre PCRtp messages from SR OS without any errors.


olivier.dugeon@... писал 03.04.2019 14:31:

Hi Andrey,

And for the second problem with the PCRpt message, LSPA/BANDWIDTH/METRICS could be associated with the ERO Object only. Not with RRO.

I already made some tests with Juniper and Cisco router where these objects are announced with ERO and correctly parse & handle by ODL.

Regards

Olivier


Le 03/04/2019 à 13:07, Olivier Dugeon a écrit :

Hello Andrey,

Your PCReq message is correctly formatted as per RFC8231. However, LSP Object has been introduced in RFC8231 and added to the PCReq grammar while ODL support only PCReq from RFC5440 which define only LSPA Object. Thus, you got an error from ODL while your message is correct.

In addition, if PCReq messages are parsed by ODL there are not properly handle. What you get is only a message in the log telling that a PCReq message has been received but flag as "unsupported message". And you do not receive any answer which is not conform to RFC5440. At least you must get a PCRep message with a NO-PATH Object or a PCErr message.

BTW, we develop a full implementation of RFC5440 & RFC5441 for ODL. PCReq messages are handle and if you use BGP-LS our code is able to compute path. We are currently under code review process before submitting our patch. We have already open a JIRA ticket for that: https://jira.opendaylight.org/browse/BGPCEP-858 . From what you experienced with your test, I understand that we must also update the PCReq message parser in order to support LSP Object as per RFC8231 in complement to RFC5440 Objects.

Regards

Olivier


Le 03/04/2019 à 01:18, Andrey Elperin a écrit :
Hi Ajay,
 
Thank you very much for an answer. 
 
I'm a bit surprised about expected PCReq format. According to the docs, ODL PCEP plugin supports draft-ietf-pce-pce-initiated-lsp
and there is the following statement here:
 
 
   The definition of the PCReq message from [RFC5440] is extended to
   optionally include the LSP object after the END-POINTS object.
 
Is it not implemented in parser ?

In the meanwhile I did some additional searches in bgpcep-dev archives and found this topic:

with the following statement:

>> The protocol implementation, pcep-impl, does fully support RFC5440. 
>> The default ODL application, pcep-topology-provider, supports only 
>> 
active stateful PCE mode of operation and does not include support 
>> for PCC-initiated path computation.

Is it still true for the latest PCEP plugin version ? If yes - I can assume that ODL won't be able to respond to PCReq's anyway.

--
/me from somewhere

1 квіт. 2019 р. о 22:53 Ajay Lele <ajayslele@...> написав(ла):

Hi Andrey
 
Problem appears to be happening because message from device has some objects which are not expected there

On Fri, Mar 22, 2019 at 2:45 AM Andrey Elperin <mizzy@...> wrote:

  Hello,

  Right now I'm testing interoperability between PCEP implementation in 
Nokia 7750 SR routers and ODL.

  Software versions:
  7750 SR: TimOS 16.0.R6
  ODL: Fluorine SR2

  Java:
  openjdk version "1.8.0_181"
  OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
  OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

  7750 SR configured as PCC, ODL is configured as PCE.

  Looks like I'm observing quite serious issues from the very beginning.

  1. PCRpt messages processing. When 7750 reporting some new LSP (PCC 
initiated, PCC controlled) ODL can process PCRpt messages and add 
corresponding LSPs to LSP-DB, but in any case it will throw a bunch of 
PCErr messages in return. All PCerr are the same - "LSP Object missing". 
And of course this object is actually present (ODL can't parse it 
correctly ?). I made capture of traffic exchange between PCC and PCEP 
(starting from PCEP session establishment) to illustrate this issue. 
Logs from PCE side are present as well. There are two files attached - 
190321_pcrpt.pcap, 190321_pcrpt_odl.log
 
Expected format for PCRpt is here: https://tools.ietf.org/html/rfc8231#page-25. Message in attached pcap has LSPA/BANDWIDTH/METRIC objects after RRO object which is not expected
 

  2. PCReq messages from 7750 can't be parsed at all by ODL. All I can 
get is "Failed to decode protocol message" in ODL logs. Again I made 
capture of traffic exchange between PCC and PCE and collected logs from 
ODL side. There are two files attached - 190321_pcreq.pcap, 
190321_pcreq_odl.log
 
Expected format for PCReq is here: https://tools.ietf.org/html/rfc5440#page-19. Message in attached pcap has LSP object after END-POINTS object which is not expected there 
 
Regards
Ajay
 

  Maybe somebody can look in my pcaps/logs and give me some advices ? I'm 
already in touch with TimOS developers but any comments from ODL 
community are appreciated. Maybe some bugfixes are needed in ODL as well 
?

-- 
/me from somewhere_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users


_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users

_________________________________________________________________________________________________________________________

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.


--
/me from somewhere