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

[Dhruv Dhody <[e-mail]>]

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]>
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]>
> *Sent:* Wednesday, September 28, 2022 13:06
> *To:* Marina Fizgeer <[e-mail]>
> *Cc:* Orly Bachar <[e-mail]>; [e-mail];
> [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]>
> 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
>
> [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.
>
>
> 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]
> https://www.ietf.org/mailman/listinfo/pce
>