Subject: [Pce] FW: New Version Notification for draft-chen-pce-sr-policy-ifit-02.txt

From: Giuseppe Fioccola <[email-masked]>
Date: Fri, 10 Jul 2020 14:51:24 +0000

Dear All,
We have recently updated draft-chen-pce-sr-policy-ifit. It aims to define the Extensions to PCEP to enable automatically IOAM and Alternate Marking when the SR policy is applied. In particular we have clarified better the PCEP usage in this scenario.

Feedbacks and suggestions are always welcome.

Best Regards,

Giuseppe

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, July 10, 2020 2:28 PM
To: Giuseppe Fioccola <[email-masked]>; Hang Yuan <[email-masked]>; Huanan Chen <[email-masked]>; wangyali <[email-masked]>; Liweidong (Poly) <[email-masked]>; Tianran Zhou <[email-masked]>
Subject: New Version Notification for draft-chen-pce-sr-policy-ifit-02.txt

A new version of I-D, draft-chen-pce-sr-policy-ifit-02.txt
has been successfully submitted by Giuseppe Fioccola and posted to the IETF repository.

Name:		draft-chen-pce-sr-policy-ifit
Revision:	02
Title:		PCEP SR Policy Extensions to Enable IFIT
Document date:	2020-07-10
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-chen-pce-sr-policy-ifit-02.txt
Status:         https://datatracker.ietf.org/doc/draft-chen-pce-sr-policy-ifit/
Htmlized:       https://tools.ietf.org/html/draft-chen-pce-sr-policy-ifit-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-chen-pce-sr-policy-ifit
Diff:           https://www.ietf.org/rfcdiff?url2=draft-chen-pce-sr-policy-ifit-02

Abstract:
   Segment Routing (SR) policy is a set of candidate SR paths consisting
   of one or more segment lists and necessary path attributes.  It
   enables instantiation of an ordered list of segments with a specific
   intent for traffic steering.  In-situ Flow Information Telemetry
   (IFIT) refers to network OAM applications that apply dataplane on-
   path telemetry techniques.  This document defines extensions to PCEP
   to distribute SR policies carrying IFIT information.  So that IFIT
   behavior can be enabled automatically when the SR policy is applied.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Dhruv Dhody <[email-masked]>
Date: Sun, 26 Jul 2020 17:23:08 +0530

Hi Giuseppe,

Thanks for letting the WG know about your I-D.

<wg-contributor>
I have some suggestions to improve this I-D -

(0) Can these TLVs be carried inside the LSPA object, and allow the
IFIT to be used for all paths (including SR, SRv6, RSVP-TE, PCECC,
etc). I understand that your key case is with SR-Policy but it is
better to put the TLVs in a generic object rather than in an SR
specific one. I am guessing you might be influenced by BGP SR Policy
(where it makes sense to limit it to SR-Policy as BGP is used only for
SR-Policy) but in the case of PCEP, making it generic is a better idea
IMHO.

(1) Add capability exchange between PCEP speakers by adding a flag in
SR-PCE-CAPABILITY Sub-TLV. PCE WG has a long history of explicit
capability exchange in open before using new features.

(2) You need to re-write section 5.1, it does not come across as an
example - it describes some new procedure to handle SR Policy that is
not aligned with the rest of PCE documents. I suggest adding an
example figure with a PCInitiate message from PCE to PCC carrying the
SR Policy/Candidate Path/IFIT attributes to explain the flow with an
example.

(3) The document is light on motivation, you say "So that IFIT
behavior can be enabled automatically when the SR policy is applied".
I wish you can expand on this a little more.  Something on lines of -

   When a PCE is used to initiate paths using PCEP, it is important
   that the head end of the path also understands the IFIT behavior
   that is intended for the path. When PCEP is in use for path initiation
   it makes sense for that same protocol to be used to also carry the
   IFIT attributes that describe the IOAM header/procedure that needs
   to be applied to the data that flow those paths.

(4) Only one of these TLVs can be enabled right? This needs to be
described. Also, add text to describe disabling of IFIT or making
changes. Some tightening of the procedure is needed here.

(5) PCE would need to maintain the uniqueness of Flow ID, FlowMonID
etc. This can be highlighted with a reference to other I-Ds that
describe the procedure.

(6) It would be good to also point to the registries created by other
documents that we would be re-using.

I hope you find this useful. I would encourage the WG to provide their
thoughts as well.
</wg-contributor>

Thanks!
Dhruv

On Fri, Jul 10, 2020 at 8:21 PM Giuseppe Fioccola
<[email-masked]> wrote:
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 27 Jul 2020 14:49:08 +0000

Hi Dhruv,
Thanks a lot for the review and for the suggestions.
Please find my answers inline tagged as [GF].

Regards,

Giuseppe

-----Original Message-----
From: Dhruv Dhody [mailto:[email-masked]] 
Sent: Sunday, July 26, 2020 1:53 PM
To: Giuseppe Fioccola <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Pce] FW: New Version Notification for draft-chen-pce-sr-policy-ifit-02.txt

Hi Giuseppe,

<wg-contributor>

(0) Can these TLVs be carried inside the LSPA object, and allow the IFIT to be used for all paths (including SR, SRv6, RSVP-TE, PCECC, etc). I understand that your key case is with SR-Policy but it is better to put the TLVs in a generic object rather than in an SR specific one. I am guessing you might be influenced by BGP SR Policy (where it makes sense to limit it to SR-Policy as BGP is used only for
SR-Policy) but in the case of PCEP, making it generic is a better idea IMHO.

[GF]: We can surely make it generic and define the same TLVs carried inside the LSPA object in order to be applied for all path types, as long as they support the relevant data plane telemetry method. The current version of the draft already mentions the possibility to generalize the proposal but through RFC8697: "Note that the IFIT attributes here described can also be generalized and included as TLVs for other Association Groups". We only considered the case of SR Policy since IOAM and Alternate Marking are becoming mature especially for SR, looking at the relevant adopted work for data plane telemetry (e.g. for SRv6: draft-ietf-6man-ipv6-alt-mark, draft-ietf-ippm-ioam-ipv6-options). Anyway the possibility to generalize the proposal can be discussed. I guess you are also suggesting to replace this I-D with a new I-D that has a general scope (not limited to SR policy, as it is now), correct?

(1) Add capability exchange between PCEP speakers by adding a flag in SR-PCE-CAPABILITY Sub-TLV. PCE WG has a long history of explicit capability exchange in open before using new features.

[GF]: Good suggestion. We will add a new Section in the next revision and describe a new SR-PCE-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV in order to allow explicit capability exchange.

(2) You need to re-write section 5.1, it does not come across as an example - it describes some new procedure to handle SR Policy that is not aligned with the rest of PCE documents. I suggest adding an example figure with a PCInitiate message from PCE to PCC carrying the SR Policy/Candidate Path/IFIT attributes to explain the flow with an example.

[GF]: Agree. Section 5.1 will be revised in the next version and, as you suggested, a figure can help in this case to describe the flow.

(3) The document is light on motivation, you say "So that IFIT behavior can be enabled automatically when the SR policy is applied".
I wish you can expand on this a little more.  Something on lines of -

[GF]: Yes, the motivation part also needs to be extended and thanks for the input on this.

(4) Only one of these TLVs can be enabled right? This needs to be described. Also, add text to describe disabling of IFIT or making changes. Some tightening of the procedure is needed here.

[GF]: We can certainly add a new section about the procedure of enabling/disabling of IFIT and also describe the coexistence of IOAM and Alternate Marking.

(5) PCE would need to maintain the uniqueness of Flow ID, FlowMonID etc. This can be highlighted with a reference to other I-Ds that describe the procedure.

[GF]: Yes, I will specify better the procedure in the next version. 

(6) It would be good to also point to the registries created by other documents that we would be re-using.

[GF]: Ok.

I hope you find this useful. I would encourage the WG to provide their thoughts as well.
</wg-contributor>

Thanks!
Dhruv

On Fri, Jul 10, 2020 at 8:21 PM Giuseppe Fioccola <[email-masked]> wrote:
> To: Giuseppe Fioccola <[email-masked]>; Hang Yuan 
> <[email-masked]>; Huanan Chen <[email-masked]>; 
> wangyali <[email-masked]>; Liweidong (Poly) 
> <[email-masked]>; Tianran Zhou <[email-masked]>

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 27 Jul 2020 22:46:00 +0530

Hi Giuseppe,

Snipping to...

> [GF]: We can surely make it generic and define the same TLVs carried inside the LSPA object in order to be applied for all path types, as long as they support the relevant data plane telemetry method. The current version of the draft already mentions the possibility to generalize the proposal but through RFC8697: "Note that the IFIT attributes here described can also be generalized and included as TLVs for other Association Groups".

[Dhruv]: Encoding these TLVs in an ASSOCIATION object of any type
would not be the best encoding option in my opinion. The association
types already defined are Protection, Diversity, Policy, and the next
set coming up are Bi-direction (multiple types), VN association, SR
policy etc. It would be out of place to put  IFIT attribute TLV in all
these associations.

LSPA object seems to be a better place to encode and would be
applicable to all path-setup-types by default. Check out RFC 8733 on
how to use LSPA to encode new attributes.

> We only considered the case of SR Policy since IOAM and Alternate Marking are becoming mature especially for SR, looking at the relevant adopted work for data plane telemetry (e.g. for SRv6: draft-ietf-6man-ipv6-alt-mark, draft-ietf-ippm-ioam-ipv6-options). Anyway the possibility to generalize the proposal can be discussed. I guess you are also suggesting to replace this I-D with a new I-D that has a general scope (not limited to SR policy, as it is now), correct?

[Dhruv] Let's continue to discuss during the meeting tomorrow.

Thanks!
Dhruv

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 27 Jul 2020 19:29:15 +0000

Hi Dhruv,
Please see inline as [GF]
Regards,

Giuseppe

-----Original Message-----
From: Dhruv Dhody [mailto:[email-masked]] 
Sent: Monday, July 27, 2020 7:16 PM
To: Giuseppe Fioccola <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Pce] FW: New Version Notification for draft-chen-pce-sr-policy-ifit-02.txt

Hi Giuseppe,

Snipping to...

> [GF]: We can surely make it generic and define the same TLVs carried inside the LSPA object in order to be applied for all path types, as long as they support the relevant data plane telemetry meth…

[Dhruv]: Encoding these TLVs in an ASSOCIATION object of any type would not be the best encoding option in my opinion. The association types already defined are Protection, Diversity, Policy, and the next set coming up are Bi-direction (multiple types), VN association, SR policy etc. It would be out of place to put  IFIT attribute TLV in all these associations.

[GF]: I see your point. Since we started to focus on SR, in the context of draft-ietf-pce-segment-routing-policy-cp, it makes sense to add IFIT attribute TLV to the SRPAG. But, looking at the association types already defined, I agree, the IFIT attribute TLVs cannot be generalized in this way.

LSPA object seems to be a better place to encode and would be applicable to all path-setup-types by default. Check out RFC 8733 on how to use LSPA to encode new attributes.

[GF]: Thanks for the reference. I will have a look at RFC8733.

[GF]: Sure.

Thanks!
Dhruv