Re: [Pce] [EXTERNAL] Re: PCEP support for S-BFD configuration for PCE initiated LSPs

[Marina Fizgeer <[e-mail]>]

Thank you, Dhruv.
Fully agree that it shall be for any PST. But LSPA is not so useful for SR-TE (as in my example below).
New association object was our first suggestion, as you remember ☺.
Let’s change our direction again and back to the initial proposals with new AG

Best regards,
Marina

From: Dhruv Dhody <[e-mail]>
Sent: Wednesday, September 28, 2022 13:26
To: Marina Fizgeer <[e-mail]>
Cc: Dhruv Dhody <[e-mail]>; Orly Bachar <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Pce] [EXTERNAL] Re: PCEP support for S-BFD configuration for PCE initiated LSPs

Hi Marina,

I disagree with your perception of the LSPA object :)
PCEP was originally defined only for RSVP-TE and so was the LSPA object! Moreover we need to make this document generic to work with any path setup type (PST) and not just SR-MPLS!

If not LSPA, I would ask you to think about a new association type for the association object then :)

Thanks!
Dhruv (no-hats)

On Wed, Sep 28, 2022 at 3:46 PM Marina Fizgeer <[e-mail]<mailto:[e-mail]>> wrote:
Thank you, Dhruv.
It’s really implementation points and for sure shall be changed to an internet draft text.
The only issue we  thought is that LSPA is optional object, partially defined for RSVP-TE and not so used for SR-TE (for example, fields of priority and preemption).
May be, better to define the new object with optional TLVs for S-BFD. As alternate, we can use LSP object, but it seems to us less suitable.
What do you think?
In our implementation PCEP for SR-TE (before S-BFD) we don’t use LSPA object.

Best regards,
Marina

From: Dhruv Dhody <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, September 28, 2022 13:06
To: Marina Fizgeer <[e-mail]<mailto:[e-mail]>>
Cc: Orly Bachar <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [EXTERNAL] Re: PCEP support for S-BFD configuration for PCE initiated LSPs

Hi Marina,

Apologies for the late reply! I suggest you convert this to I-D soon which would be easier to review and track.

I am assuming that the below text is written from the implementation point of view and not from the standards point of view. It would be appropriate going forward to move the discussion to an internet draft and discuss it from standards POV. Do take care of the reframing of the text as appropriate for IETF documents (and not implementation documents) :)

On Wed, Sep 14, 2022 at 3:42 PM Marina Fizgeer <[e-mail]<mailto:[e-mail]>> wrote:
Hi, Dhruv and all.
We prepared our suggestion for option 2 (as discussed). Please, review it. Thank you
Motivation

S-BFD protocol is used for detecting failures in SR-TE tunnels.

There are several protocol parameters that need to be configured and exchanged between PCEP speakers.

As the parameters are associated to SR-TE tunnel, they should be exchanged via PCEP.

However, currently there is no standard way to exchange S-BFD parameters via PCEP, so it is decided to define proprietary extensions, and discuss these with IETF WG.


Better to make this generic so that it is applicable to SRv6, PCECC etc. We can keep the SR-MPLS as the key usecase but let's not tie the PCEP extension too closely to SR-MPLS only!


Support new TLVs

PCEP speakers shall implement new TLVs to report the S-BFD Initiator attributes configured per SR-TE tunnel shall be defined according to the table below.

To implement the new feature, PCEP speakers shall use unassigned IANA types.

IANA Unassigned Association types: Unassigned 7-65535

IANA Unassigned Error types: unassigned 33-255

IANA Unassigned TLV types: unassigned 64-65503

Remove this for the internet-draft.

Attribute

Range

Default

Type

Data Type

Description/Limitations

S-BFD enable

True/False

False

R/W

Boolean

Specify if S-BFD is enable on this tunnel. Means enable on all LSPs

Remote Discriminator

1 - 4294967295

IP address of the Destination of the tunnel

R/W

Uint32

Specify the remote discriminator of the session

Minimal TX interval

As for regular BCM based MH-BFD

<20|50|100|1000|10000>

100

R/W

Uint32

Specify the Minimal Transmit Interval (mSec)

Multiplier

2-255

3

R/W

Uint8

Specify the Multiplier value.

Better to refer to BFD documents for these values and descriptions in the internet-draft!



Support "S-BFD Capability" TLV

Why "S-BFD" and not just BFD? While https://datatracker.ietf.org/doc/draft-ietf-spring-bfd/<https://clicktime.symantec.com/15sLvREooVfNXi7dxR2cR?h=Z0uzM-Ig3C0Kd3kPOLy2im-Z1fkpyICLrRyEvuVSdqA=&u=https://datatracker.ietf.org/doc/draft-ietf-spring-bfd/> uses BFD!



The "S-BFD Capability" TLV is an optional TLV associated with the OPEN Object to exchange S-BFD capability of PCEP speakers

[cid:image001.png@01D8C825.204A3930]

Type: 65500

Length: 4

B: A PCEP speaker sets this bit to 1 to indicate that it is capable of S-BFD

REQ#1 NPTi shall send the "S-BFD Capability" TLV in the Open message with B flag = 1

Support "LSP-SBFD Enable" TLV

The "LSP-SBFD Enable" proprietary TLV will be sent for the LSPA object.

[cid:image002.png@01D8C825.204A3930]

Type: 65503

Length: 4

B: Enable/Disable S-BFD for this LSP. If B=1 then S-BFD will be enabled. If B=0 then S-BFD will be disabled



PCEP speakers shall implement a new TLV "LSP-SBFD Enable" to report the S-BFD state (Enabled/Disabled) configured per SR-TE tunnel shall be defined according to the table above.

PCEP speakers MUST send "LSP-SBFD Enable" TLV as part of the Optional TLVs of the LSP object.
It should be LSPA?

PCEP speakers shall support receiving "LSP-SBFD Enable" TLV from PCEP peer.

  *   if the B flag is set to 1 then S-BFD shall be applied for specified LSP
  *   If the B flag is set to 0 then S-BFD shall be removed for specified LSP.

If this TLV is received with B=0 and there is no S-BFD applied for the LSP(s), then the PCEP Speaker shall ignore the TLV.

If LSPA object has been received without "LSP-SBFD Enable" TLV, then the PCEP Speaker shall reply with Error Type: 6 “Mandatory Object Missing” with Error value 255 “LSP-SBFD TLV missing”


I am not sure about the error conditions. I think there ought to be a check between the use of LSP-SBFD enable TLV and the capability TLV.

Consider having a single "BFD attribute TLV" that allows multiple sub-TLVs in this case instead of 3 separate TLVs! See RFC 8733 and IFIT draft as reference.
Support "LSP-BFD Parameters" TLV

This new TLV is optional, and shall be sent for the LSPA object only if the S-BFD bit in LSP is 1.

[cid:image003.png@01D8C825.204A3930]

Type: 65502

Length: 6

Min Tx Interval: 4 bytes - Specify the Minimal Transmit Interval (mSec)

Multiplier: 8 bits

PCEP Speaker shall implement "LSP-BFD Parameters" TLV to report the BFD parameters. S-BFD configured attributes per SR-TE tunnel shall be defined according to the table above.

PCEP Speaker shall support receiving "LSP-BFD Parameters" TLV from PCEP peer.

If Min Tx Interval value is not in the specified range as defined in the table above, then the PCEP Speaker shall reply with Error Type = 255 “LSP-BFD Error” and Error-Value = 1 “Min Tx Interval is out of range”

If Multiplier value is not in the specified range as defined in the table above, then the PCEP Speaker shall reply with Error Type = 255 “LSP-BFD Error” and Error-Value = 2 “Multiplier is out of range”

If either the Min Tx Interval or the Multiplier value received in the "LSP-BFD Parameters" TLVs for the LSPA object is not identical, then the PCEP Speaker shall reply with Error Type: 255 “LSP-BFD Error” with Error value 3 “Parameter value(s) must be identical”
Identical to what?



If B=0 and "LSP-BFD Parameters" TLV is received then IGNORE "LSP-BFD Parameters" TLV

Support "LSP-SBFD Discriminator" TLV

The "LSP-SBFD Discriminator" is optional, and shall be sent for the LSPA object only if the S-BFD bit in LSP is 1.

[cid:image004.png@01D8C825.204A3930]

Type: 65501

Length: 4

Remote Discriminator: NPTi will always use Router ID (IPv4 address of Router)

PCEP Speaker shall implement "LSP-SBFD Discriminator" TLV to report the Remote Discriminator of the SR-TE Tunnel.

PCEP Speaker shall support receiving "LSP-SBFD Discriminator" TLV from PCEP peer.

If the Remote Discriminator value received in the "LSP-SBFD Discriminator" TLVs for the LSPs  is not identical, then the PCEP Speaker shall reply with Error Type: 255 “LSP-SBFD Association Error” with Error value 4 “Parameter value(s) must be identical”



association error?
identical to what?



PCC-Initiated Tunnel Flows
PCC-Initiated: PCC created tunnel with S-BFD enable

Upon receiving locally computed request PCC shall send to PCE a PCRpt message containing:
LSPA object containing in the Optional TLVs section the following TLVs (in addition to others):

        *   "LSP-SBFD Enable" TLV with B Flag = 0 if no S-BFD is configured , or B flag = 1 if S-BFD is enabled for the LSP
        *   [Optionally] "LSP-BFD Parameters" TLV and "LSP-SBFD Discriminator" TLV

no enable TLV in the LSPA should itself indicate no BFD!



PCE-Initiated Flows
PCE created tunnel/LSP with S-BFD enable

Upon receiving request PCE shall send to PCC a PCInit message containing:
LSPA object containing in the Optional TLVs section the following TLVs (in addition to others):

           *   "LSP-SBFD Enable" TLV with B Flag = 0 if no S-BFD is configured , or B flag = 1 if S-BFD is enabled for the LSP
           *   [Optionally] "LSP-BFD Parameters" TLV and "LSP-SBFD Discriminator" TLV

PCE edit tunnel/LSP: enabling or disabling S-BFD

Upon receiving request PCE shall send to PCC a PCUpd message containing:
LSPA object containing in the Optional TLVs section the following TLVs (in addition to others):

           *   "LSP-SBFD Enable" TLV with B Flag = 0 if no S-BFD is configured , or B flag = 1 if S-BFD is enabled for the LSP
           *   [Optionally] "LSP-BFD Parameters" TLV and "LSP-SBFD Discriminator" TLV




Looking forward to seeing the internet-draft!

Thanks!
Dhruv



Best regards,
Marina

From: Pce <[e-mail]<mailto:[e-mail]>> On Behalf Of Marina Fizgeer
Sent: Sunday, August 28, 2022 15:42
To: Dhruv Dhody <[e-mail]<mailto:[e-mail]>>
Cc: Orly Bachar <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Pce] [EXTERNAL] Re: PCEP support for S-BFD configuration for PCE initiated LSPs

Thank you, Dhruv.
We will prepare our suggestion for option 2 – capability and TLVs – and will share with you

Best regards,
Marina

From: Dhruv Dhody <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, August 28, 2022 15:38
To: Marina Fizgeer <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Lizhenbin <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [EXTERNAL] Re: PCEP support for S-BFD configuration for PCE initiated LSPs

HI Marina,


On Sun, Aug 28, 2022 at 2:32 PM Marina Fizgeer <[e-mail]<mailto:[e-mail]>> wrote:
Hi, Dhruv. Thank you for fast response.

This draft is expired in 2016. We also know about draft https://datatracker.ietf.org/doc/html/draft-alvarez-pce-path-profiles-04<https://clicktime.symantec.com/15t5ZrfzxBWcsxXk23rhF?h=w5cHD76LcIxiG2AjEgEfAxBT5I4LN_xWpqIj9y5ELCU=&u=https://datatracker.ietf.org/doc/html/draft-alvarez-pce-path-profiles-04>, that also is expired many years ago.

I wanted to introduce past work and hope you could find collaborators in this space.


We agree with your suggestion to support it via new set of TLVs in LSPA object. The benefits of using of AG approach is that it can be negotiated in open message in AG list (is it supported by both PCEP speakers or not and can be used). For this goal we can add some S-BFD capabilities in open message. Do you agree with this suggestion?

Sure! The capability advertisement (or negotiation) is not unique to association groups. Many PCEP extension defines CAPABILITY TLV that MUST be exchanged in the Open message before you could use the extension. Yes I agree!


Then, these new TLVs can be used in case, that both speakers report “S-BFD” is support.
Our goal is to be interoperable and standard with 3rd party SDN controller/NE.

Then, as summary, we can progress in our work in two directions:

1.      Define and use new AG for S-BFD and future MPLS parameters, need to be define on LSPs

2.      Add new TLVs for S-BFD to LSPA


My presonal preference (no hats) is for 2.

Thanks!
Dhruv


Need your opinion on it. Thank you.

Best regards,
Marina

From: Dhruv Dhody <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, August 24, 2022 18:51
To: Marina Fizgeer <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Orly Bachar <[e-mail]<mailto:[e-mail]>>; Lizhenbin <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: PCEP support for S-BFD configuration for PCE initiated LSPs

Hi Marina / Orly,

There was a draft a while back which did propose passing BFD parameters - https://datatracker.ietf.org/doc/html/draft-li-pce-bfd-00<https://clicktime.symantec.com/15sM1FEjA593kaeUeFZQD?h=bMprcVcPrOF0oOI_v2ZgMAfKe9-4nwbAItrdDUJ6QFg=&u=https://datatracker.ietf.org/doc/html/draft-li-pce-bfd-00>.
Looking at the minutes - https://www.ietf.org/proceedings/95/minutes/minutes-95-pce<https://clicktime.symantec.com/15sM65S1cgpeAXUQBoxYq?h=29uJ8zWzZTBurmU_NQsojBOlSgJ8_7fXB9MHuc2JxS0=&u=https://www.ietf.org/proceedings/95/minutes/minutes-95-pce> it also had some support from the WG.

I have included the authors in cc, if they and others in the WG would like to revive this work.

Now, coming to use of association object -- the use of association is useful when we there is a clear relationshep between a set of the LSPs.
In this case, I assume the only relationship is that they share the same BFD parameters.
I would suggest thinking through if association is the best technique or a new TLV under LSPA a better technique.
Also checkout IOAM draft https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-ifit/<https://clicktime.symantec.com/15sLvR3ShTTTLdpZ6hAFb?h=JhbgyCctN-E19EbNmLb_lg4J9XhAPkNn0gcabmZpRnY=&u=https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-ifit/> which uses the latter and I would think keeping this consistent would be a good idea.

Thanks!
Dhruv



On Wed, Aug 24, 2022 at 8:03 PM Marina Fizgeer <[e-mail]<mailto:[e-mail]>> wrote:
Hi, Dhruv and all,
My colleagues and I are working on PCEP PCE initiated and PCC initiated LSP with S-BFD configuration (the same may be relevant for BFD as well).
As far as we understand, it is currently not possible to configure S-BFD parameters via PCEP (like other future MPLS parameters).
We propose to add a new association type to allow additional LSP configuration (as example and the first using, S-BFD parameters).
New association type shall be part of negotiation process in session establishment (that both PCEP speakers support this type).
In TLV:
[https://ilptlppjir01.ecitele.com:7443/confluence/download/attachments/144821588/image2021-12-7_10-29-57.png?version=1&modificationDate=1660463565000&api=v2]
Both NPT and NC MUST support ASSOC-Type-List TLV
PCEP Speaker shall use ASSOC-Type-List TLV to report its support in Assoc-Type = MPLS-Additional-Params  (65535)
PCEP Speaker shall send the S-BFD Association Object and the new TLVs only if it has received from its peer (in the ASSOC-Type-List TLV) the MPLS-Additional-Params Association Type in the Open message

Support new proprietary TLVs
PCEP speaker shall implement new TLVs to report the S-BFD Initiator attributes configured per SR-TE LSP (SR policy) according to the table below. This table is part of our implementation as example:

Attribute
Range
Default
Type
Data Type
Description/Limitations
S-BFD enable
True/False
False
R/W
Boolean
Specify if S-BFD is enable on this tunnel. Means enable on all LSPs
Remote Discriminator
1 - 4294967295
IP address of the Destination of the tunnel
R/W
Uint32
Specify the remote discriminator of the session
Minimal TX interval
As for regular BCM based MH-BFD
<20|50|100|1000|10000>
100
R/W
Uint32
Specify the Minimal Transmit Interval (mSec)
Multiplier
2-255
3
R/W
Uint8
Specify the Multiplier value.

Support "S-BFD Enable" TLV
The "S-BFD Enable" TLV will be sent for the S-BFD ASSOCIATION object  only if the user (PCEP speaker) configured S-BFD for the specified LSP (for failure detection purpose)
[https://ilptlppjir01.ecitele.com:7443/confluence/download/attachments/144821588/image2022-8-14_19-42-18.png?version=1&modificationDate=1660495338000&api=v2]
Type: 65503
Length: 4
B: Enable/Disable S-BFD for this association group. If B=1 then S-BFD will be enabled. If B=0 then S-BFD will be disabled


Support "BFD Parameters" TLV
This new TLV is optional, and will be sent for the S-BFD ASSOCIATION object only if the user (PCEP speaker) modified the defaults of the S-BFD parameters for a specified tunnel.
[https://ilptlppjir01.ecitele.com:7443/confluence/download/attachments/144821588/image2022-8-10_11-38-56.png?version=1&modificationDate=1660120736000&api=v2]
Type: 65502
Length: 6
Min Tx Interval: 4 bytes - Specify the Minimal Transmit Interval (mSec)
Multiplier: 8 bits

Support "S-BFD Discriminator" TLV
The "S-BFD Discriminator" proprietary TLV is optional, and will be sent for S-BFD Association Group only if the user (CLI / NC)  wishes to change the Remote Discriminator of the SR Policy
[https://ilptlppjir01.ecitele.com:7443/confluence/download/attachments/144821588/image2022-8-10_11-19-18.png?version=1&modificationDate=1660119559000&api=v2]
Type: 65501
Length: 4
Remote Discriminator: NPTi will always use Router ID (IPv4 address of Router)


Best regards,
Marina and Orly


Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________
Pce mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pce<https://clicktime.symantec.com/15siF93TYQjYYJAUBf17L?h=KAhZOgFIBODATyuzs0HnC1DbYJvZkOAgXTQvn76GTf8=&u=https://www.ietf.org/mailman/listinfo/pce>

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.