Subject: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp

From: Tarek Saad <[email-masked]>
Date: Mon, 18 Mar 2019 19:41:59 +0000

Hi authors,

The I-D “draft-ietf-idr-segment-routing-te-policy” defines sub-tlvs for SR Policy attributes that are carried in BGP (see below) for SR policy and its attributes. Ideally, with PCEP can achieve what is supported with BGP signaling and hence can leverage the most of those definitions? Is there a reason not to?

     2.4<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4>.  SR Policy Sub-TLVs  . . . . . . . . . . . . . . . . . . .   9<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-9>

       2.4.1<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.1>.  Preference Sub-TLV  . . . . . . . . . . . . . . . . .   9<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-9>

       2.4.2<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.2>.  Binding SID Sub-TLV . . . . . . . . . . . . . . . . .  10<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-10>

       2.4.3<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.3>.  Segment List Sub-TLV  . . . . . . . . . . . . . . . .  11<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-11>

       2.4.3.1<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.3.1>.  Weight Sub-TLV

       2.4.3.2<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.3.2>.  Segment Sub-TLV

       2.4.4<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.4>.  Explicit NULL Label Policy Sub-TLV  . . . . . . . . .  27<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-27>

       2.4.5<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.5>.  Policy Priority Sub-TLV . . . . . . . . . . . . . . .  28<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-28>

       2.4.6<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.6>.  Policy Name Sub-TLV . . . . . . . . . . . . . . . . .  29<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-29>

Regards,
Tarek

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 20 Mar 2019 20:44:04 +0530

Hi Tarek,

As a individual WG member, I think reusing BGP sub-TLV in PCEP in this
case(*) is problematic, mainly because -

(1) PCEP already has some other objects and TLVs which were defined much
before the BGP SR Policy work, such as -
- SR-ERO subobject to carry SID (compared to BGP's Segment sub-TLV)
- TE-PATH-BINDING TLV for BSID (compared to BGP's Binding SID sub-TLV)

(2) PCEP has a very specific format for all its TLVs as per
https://tools.ietf.org/html/rfc5440#section-7.1, you would notice that BGP
does not follow that.

(3) SR-POLICY is a top level container, in PCEP-SR for each LSP (or
candidate path) we carry its associated Policy information in the
ASSOCIATION object.

That said, it is important that fields and encoding are aligned between BGP
and PCEP and I would request the authors to make sure that is the case.

Thanks!
Dhruv

(*) We were able to do this successfully in case of Flowspec

On Tue, Mar 19, 2019 at 1:12 AM Tarek Saad <[email-masked]> wrote:

> Hi authors,
>
>
>
> The I-D “draft-ietf-idr-segment-routing-te-policy” defines sub-tlvs for SR
> Policy attributes that are carried in BGP (see below) for SR policy and its
> attributes. Ideally, with PCEP can achieve what is supported with BGP
> signaling and hence can leverage the most of those definitions? Is there a
> reason not to?
>
>
>
>
>
>      2.4 <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2..4>.  SR Policy Sub-TLVs  . . . . . . . . . . . . . . . . . . .   9 <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-9>
>
>        2.4.1 <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.1>.  Preference Sub-TLV  . . . . . . . . . . . . . . . . .   9 <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-9>
>
>        2.4.2 <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.2>.  Binding SID Sub-TLV . . . . . . . . . . .. . . . . . .  10 <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-10>
>
>        2.4.3 <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.3>.  Segment List Sub-TLV  . . . . . . . . . . . . . . . .  11 <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-11>
>
>        2.4.3.1 <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.3.1>.  Weight Sub-TLV
>
>        2.4.3.2 <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.3.2>.  Segment Sub-TLV
>
>        2.4.4 <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.4>.  Explicit NULL Label Policy Sub-TLV  . . . . . . . . .  27 <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-27>
>
>        2.4.5 <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.5>.  Policy Priority Sub-TLV . . . . . . . . .. . . . . . .  28 <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-28>
>
>        2.4.6 <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.6>.  Policy Name Sub-TLV . . . . . . . . . . .. . . . . . .  29 <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-29>
>
>
>
>
>
> Regards,
>
> Tarek
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Wed, 20 Mar 2019 15:42:13 +0000

Hi Tarek,

In addition to what Dhruv has said, I don’t believe draft-ietf-idr-segment-routing-te-policy provides a way to encode “Protocol Origin”, “Originator ASN” and “Originator Address”. These are essential for reporting existing policies from the PCC to the PCE.

Thanks,
Mike.

From: Dhruv Dhody <[email-masked]>
Sent: Wednesday, March 20, 2019 11:14 AM
To: Tarek Saad <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp

Hi Tarek,

As a individual WG member, I think reusing BGP sub-TLV in PCEP in this case(*) is problematic, mainly because -

(1) PCEP already has some other objects and TLVs which were defined much before the BGP SR Policy work, such as -
- SR-ERO subobject to carry SID (compared to BGP's Segment sub-TLV)
- TE-PATH-BINDING TLV for BSID (compared to BGP's Binding SID sub-TLV)

(2) PCEP has a very specific format for all its TLVs as per https://tools.ietf.org/html/rfc5440#section-7.1, you would notice that BGP does not follow that.

(3) SR-POLICY is a top level container, in PCEP-SR for each LSP (or candidate path) we carry its associated Policy information in the ASSOCIATION object.

That said, it is important that fields and encoding are aligned between BGP and PCEP and I would request the authors to make sure that is the case.

Thanks!
Dhruv

On Tue, Mar 19, 2019 at 1:12 AM Tarek Saad <[email-masked]<mailto:[email-masked]>> wrote:
Hi authors,

     2.4<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2..4>.  SR Policy Sub-TLVs  . . . . . . . . . . . . . . . . . . .   9<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-9>

       2.4.2<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.2>.  Binding SID Sub-TLV . . . . . . . . . . .. . . . . . .  10<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-10>

       2.4.5<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.5>.  Policy Priority Sub-TLV . . . . . . . . .. . . . . . .  28<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-28>

       2.4.6<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.6>.  Policy Name Sub-TLV . . . . . . . . . . .. . . . . . .  29<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-29>

Regards,
Tarek
_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

---

From: Tarek Saad <[email-masked]>
Date: Wed, 20 Mar 2019 16:16:24 +0000

Hi Dhruv,

Thanks for the reply. I understand your point; however, my concern is not so much on the PCEP protocol object definition, but more on the attribute(s) alignment for the different protocol cases.
I’ll quote an example you gave for BSID TLV definition in both drafts..

draft-ietf-idr-segment-routing-te-policy defines “S”, and “I” flags but those are missing from draft-sivabalan-pce-binding-label-sid

      *  S-Flag: This flag encodes the "Specified-BSID-only" behavior.
         It is used by SRPM as described in section 6.2.3 in
         [I-D.ietf-spring-segment-routing-policy<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#ref-I-D.ietf-spring-segment-routing-policy>].

      *  I-Flag: This flag encodes the "Drop Upon Invalid" behavior.  It
         is used by SRPM as described in section 8.2 in
         [I-D.ietf-spring-segment-routing-policy<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#ref-I-D.ietf-spring-segment-routing-policy>].

Similarly, draft-sivabalan-pce-binding-label-sid defines BT=0/1 behaviors but those are missing from the other draft..
There may be other cases for SR-ERO too – e.g. missing “SR Algorithm”, etc.

I noticed a trend in LSR WG to define sub-TLVs that can be resused by multiple IGP protocols (e.g. the sub-TLVs defined in draft-ietf-lsr-pce-discovery-security-support).. and I was wondering if this approach could be leveraged here too.

Regards,

Tarek

From: Dhruv Dhody <[email-masked]>
Date: Wednesday, March 20, 2019 at 11:14 AM
To: Tarek Saad <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp

Hi Tarek,

Thanks!
Dhruv

Regards,
Tarek

---

From: Tarek Saad <[email-masked]>
Date: Wed, 20 Mar 2019 16:28:52 +0000

Hi Mike,

>> In addition to what Dhruv has said, I don’t believe draft-ietf-idr-segment-routing-te-policy provides a way to encode “Protocol Origin”, “Originator ASN” and “Originator Address”. These are essent…
[TS]: Agreed. However, as far as I see, draft-ietf-idr-segment-routing-te-policy covers the “controller -> device” signaling only. The attributes you mention are for reporting state from “device -> controller”.

Regards,
Tarek

Thanks,
Mike.

Hi Tarek,

Thanks!
Dhruv

Regards,
Tarek

---

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Wed, 20 Mar 2019 16:35:29 +0000

Hi Tarek,

Yes, because draft-barth-pce-segment-routing-policy-cp covers both "controller -> device" and "device -> controller" signaling, these extra attributes are needed for us. I agree that draft-ietf-idr-segment-routing-te-policy does not need them because they are implicit in BGP.

Thanks,
Mike.

From: Tarek Saad <[email-masked]>
Sent: Wednesday, March 20, 2019 12:29 PM
To: Mike Koldychev (mkoldych) <[email-masked]>; Dhruv Dhody <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp

Hi Mike,

>> Hi Tarek,
>> In addition to what Dhruv has said, I don't believe draft-ietf-idr-segment-routing-te-policy provides a way to encode "Protocol Origin", "Originator ASN" and "Originator Address". These are essential for reporting existing policies from the PCC to the PCE.
[TS]: Agreed. However, as far as I see, draft-ietf-idr-segment-routing-te-policy covers the "controller -> device" signaling only. The attributes you mention are for reporting state from "device -> controller".

Regards,
Tarek

Thanks,
Mike.

From: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 20, 2019 11:14 AM
To: Tarek Saad <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp

Hi Tarek,

Thanks!
Dhruv

The I-D "draft-ietf-idr-segment-routing-te-policy" defines sub-tlvs for SR Policy attributes that are carried in BGP (see below) for SR policy and its attributes. Ideally, with PCEP can achieve what is supported with BGP signaling and hence can leverage the most of those definitions? Is there a reason not to?

Regards,
Tarek

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 21 Mar 2019 14:03:49 +0000

Hi Tarek,

See inline...

From: Pce [mailto:[email-masked]] On Behalf Of Tarek Saad
Sent: 20 March 2019 21:46
To: Dhruv Dhody <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp

Hi Dhruv,

Thanks for the reply. I understand your point; however, my concern is not so much on the PCEP protocol object definition, but more on the attribute(s) alignment for the different protocol cases.
I'll quote an example you gave for BSID TLV definition in both drafts..

draft-ietf-idr-segment-routing-te-policy defines "S", and "I" flags but those are missing from draft-sivabalan-pce-binding-label-sid

[[[Dhruv Dhody]]] Your point is well taken, I would ask the authors of the SR documents to do this exercise. I see some overlap in authors as well who could take the lead.
But due care should be taken in the description within the PCEP and BGP context, because BSID as currently described in PCEP is attached to a candidate path v/s BSID in BGP is described towards the full SR policy.

Similarly, draft-sivabalan-pce-binding-label-sid defines BT=0/1 behaviors but those are missing from the other draft..
[[[Dhruv Dhody]]] You are right. This aligns to the C bit in SR-ERO. A question to BGP draft authors on why this is not in BGP!

There may be other cases for SR-ERO too - e.g. missing "SR Algorithm", etc.
[[[Dhruv Dhody]]] I guess this would be needed when a PCE does not prepare the label stack but provide NAI and flex algo is enabled. Looks like nobody uses this yet and thus was not noticed :). We could define a new NAI type to handle this case.

Thanks for engaging and providing instances where there are mismatch. I would encourage authors to do an alignment check.

Thanks!
Dhruv

Regards,

Tarek

Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Hi Tarek,

Thanks!
Dhruv

     2.4<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2...4>.  SR Policy Sub-TLVs  . . . . . . .. . . . . . . . . . . . .   9<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-9>

       2.4.2<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.2>.  Binding SID Sub-TLV . .. . . . . . . . . .. . . . . . .  10<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-10>

       2.4.6<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.6>.  Policy Name Sub-TLV . .. . . . . . . . . .. . . . . . .  29<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-29>

Regards,
Tarek