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

[Dhruv Dhody <[e-mail]>]

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]>
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/ uses BFD!



> The "S-BFD Capability" TLV is an optional TLV associated with the OPEN
> Object to exchange S-BFD capability of PCEP speakers
>
> [image: 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.
>
> [image: 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.
>
> [image: 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.
>
> [image: 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):
>
>    1. "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
>          2. [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):
>
>    1. "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
>             2. [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):
>
>    1. "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
>             2. [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]> *On Behalf Of *Marina Fizgeer
> *Sent:* Sunday, August 28, 2022 15:42
> *To:* Dhruv Dhody <[e-mail]>
> *Cc:* Orly Bachar <[e-mail]>; [e-mail];
> [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]>
> *Sent:* Sunday, August 28, 2022 15:38
> *To:* Marina Fizgeer <[e-mail]>
> *Cc:* [e-mail]; Lizhenbin <[e-mail]>;
> [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]>
> 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]>
> *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.
>
>
> 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.
>