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

[Marina Fizgeer <[e-mail]>]

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, that also is expired many years ago.
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? 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

Need your opinion on it. Thank you.

Best regards,
Marina

From: Dhruv Dhody <[e-mail]>
Sent: Wednesday, August 24, 2022 18:51
To: Marina Fizgeer <[e-mail]>
Cc: [e-mail]; Orly Bachar <[e-mail]>; Lizhenbin <[e-mail]>; [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.