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

[Dhruv Dhody <[e-mail]>]

HI Marina,


On Sun, Aug 28, 2022 at 2:32 PM Marina Fizgeer <[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, 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]>
> *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]>
> 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:
> [image:
> 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)
>
> [image:
> 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.
>
> [image:
> 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
>
> [image:
> 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.
>