Subject: Re: [Pce] Comments on QoS with flowspec (draft-ietf-pce-flowspec-01.txt)

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Oct 2018 13:37:23 +0100

Hi Olivier,

A couple of the authors have been discussing this and playing with possible approaches.

The first thing to note is that DSCP is one of the flowspec types inherited from BGP, so that function is available for classifying the traffic that is placed on an LSP. Thus it is possible to associate a tunnel to a particular class of service.

We should also note that, while the class of service of an LSP can be specified in the PCReq and PCInitiate messages as you say, it does not follow that there is a simple relationship between the overlay and underlay classes of service. For example, the bronze traffic from a platinum customer may be assigned better treatment than the gold traffic from a bronze customer. Thus it is better to use the flowspecs, and not a simple inheritance bit.

The second point you raise is about rate limiting, or maybe we should call it policing. When an LSP is set up, bandwidth is assigned within the network; you are asking, we think, whether we can add a control for whether the traffic should be limited to that assigned bandwidth or not.

Actually, we think the situation is more complicated:
- Multiple flowspecs may be applied to a single LSP making it confusing how to 
  apply your proposed single bit
- The amount of traffic applied to an LSP may range from some amount of
   undersubscription to some amount of deliberate over-subscription

Furthermore, we think that the subscription rate is probably a quality of the LSP itself rather than specific to the flowspec. We'd like to propose, therefore, that we define a new parameter for the PCEP messages that would be a Policing TLV (possibly in a new object or possibly in an existing object - that needs to be though about) that carries the percentage that the LSP should be loaded (range 0 to 200% ?). 

If you're agreeable to that, we think it would be worth documenting that feature in a new draft.

Thanks,
Adrian

PS. With regard to your other email, yes, we thing that the AFI is needed. This would not have been the case if IDR had kept to a single registry for all flowspec types and had created entries for both v4 and 46, but they have decided have two registries that have overlapping values initially but that may diverge over time.

> -----Original Message-----
> From: Pce [mailto:[email-masked]] On Behalf Of Olivier Dugeon
> Sent: 20 July 2018 16:58
> To: [email-masked]
> Subject: [Pce] Comments on QoS with flowspec (draft-ietf-pce-flowspec-01.txt)
> 
> Dear authors,
> 
> After reading your draft-ietf-pce-flowspec-01.txt, I would know if it is possible to
> also handle some QoS  policy configuration in conjunction with the flowspec.
> 
> In fact, when you configure a TE tunnel with some reserved bandwidth and/or a
> given Class Type and you specify which packets could belong to this tunnel, in
> general, you also associate corresponding policy configuration. In particular, you
> would associated to the tunnel a given Class of Service, thus a given DSCP
> marking/queuing, and if you reserved some bandwidth, you would configure
> some rate limit to be sure that no excess traffic belongs to this tunnel. This give to
> operational entity a complete control over the traffic that belongs to this tunnel.
> 
> So, do you think it is feasible to add two more bits in the Flow Spec Object to
> specify if the PCC must associate a Rate Limiter and/or queuing policy? It is not
> necessary to specify the bandwidth value, nor the Class Type as there have been
> provided previously (during the tunnel computation through PCReq message or
> tunnel setup through PCInitiate message), so only 2 more bits are necessary.
> 
> Regards
> 
> Olivier
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Olivier Dugeon <[email-masked]>
Date: Tue, 16 Oct 2018 19:23:01 +0200

Hi Adrian,

Thanks for the answers. My comments below.

Regards

Olivier

> The first thing to note is that DSCP is one of the flowspec types inherited from BGP, so that function is available for classifying the traffic that is placed on an LSP. Thus it is possible to asso…
[OD] Agree. I also note in the new version published today that my other questions (in a separate mail) have been raised. In particular the possibility to use an MPLS Label or a VlanID. All these flowspec types are inherited from BGP. It is much more clear in the new version of the draft.
> We should also note that, while the class of service of an LSP can be specified in the PCReq and PCInitiate messages as you say, it does not follow that there is a simple relationship between the o…
[OD] Well, the way we operate DiffServ is more on a per Class of Service i.e. allocate a DCSP value per application type rather than on a per customer or per subscription type basis. So, my question is related to flows that are not yet mark with a DSCP value or need to be remark. For that purpose, we need to identify the flows that will belongs to this tunnel and get the DSCP value of the tunnel. For example, if I setup an MPLS-TE tunnel with DSCP value EF to carry voice traffic, I would have the possibility to filter packets that belongs to this tunnel as Voice flow.
>    undersubscription to some amount of deliberate over-subscription
[OD] I agree that just one bits is not sufficient for that purpose, but I would not start the discussion by requesting too much modification i.e. adding a new Policy TLV or Object.
> Furthermore, we think that the subscription rate is probably a quality of the LSP itself rather than specific to the flowspec. We'd like to propose, therefore, that we define a new parameter for th…
[OD] I think the 2 approaches are complementary. In fact it corresponds to what is named ingress-policy and egress-policy. With my proposal, I would address the case of the egress-policy where the router will police and eventually shape/pace the traffic of the LSP according to the amount of bandwidth reserved during the PCReq of PCinitiate phase. This will ensure that the ingress router (i.e. the PCC) will not send more traffic than that has been reserved during the Path Computation performed by the PCE. This will allow an operator to guarantee that the LSP could carry the negotiated bandwidth while not disturbing the other LSPs for which the operator has also some commitments (i.e. respect the negotiated SLA of __all__ LSP of __all__ customers).
Your approach allow to specify the ingress-policy associated to the flowspec. If the egress-policy is quiet simple and could accommodate of only 1 bit indication, the ingress-policy need a new Policy TLV or Object. Of course, we could generalize this new Policy to egress-policy which allow a more flexible management e.g. determine if we perform just a rate-limit, a rate-limit + shaping, the percentage of the bandwidth ... It is also mandatory if the LSP carry more than one CoS i.e. an E-LSP. In this case, we need to specify the percentage of bandwidth of each CoS which required also a new Policy TLV.
> If you're agreeable to that, we think it would be worth documenting that feature in a new draft.
[OD] Fine. Let me know if you need help to write some new sections for this draft.
> PS. With regard to your other email, yes, we thing that the AFI is needed. This would not have been the case if IDR had kept to a single registry for all flowspec types and had created entries for…
 [OD] I appreciate the new version of the draft that add clarification on that, in particular the new table in appendix.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 18 Oct 2018 14:16:53 +0100

Hi again Olivier,

> > The first thing to note is that DSCP is one of the flowspec types inherited from
> > BGP, so that function is available for classifying the traffic that is placed on an LSP.
> > Thus it is possible to associate a tunnel to a particular class of service.
>
> [OD] Agree. I also note in the new version published today that my other
> questions (in a separate mail) have been raised. In particular the possibility to use
> an MPLS Label or a VlanID. All these flowspec types are inherited from BGP. It is
> much more clear in the new version of the draft.

Hooray :-)

> > We should also note that, while the class of service of an LSP can be specified in
> > the PCReq and PCInitiate messages as you say, it does not follow that there is a
> > simple relationship between the overlay and underlay classes of service. For
> > example, the bronze traffic from a platinum customer may be assigned better
> > treatment than the gold traffic from a bronze customer. Thus it is better to use
> > the flowspecs, and not a simple inheritance bit.
>
> [OD] Well, the way we operate DiffServ is more on a per Class of Service i.e.
> allocate a DCSP value per application type rather than on a per customer or per
> subscription type basis. So, my question is related to flows that are not yet mark
> with a DSCP value or need to be remark. For that purpose, we need to identify
> the flows that will belongs to this tunnel and get the DSCP value of the tunnel.
> For example, if I setup an MPLS-TE tunnel with DSCP value EF to carry voice
> traffic, I would have the possibility to filter packets that belongs to this tunnel as
> Voice flow.

I think we agree, basically.

Packets on a flow may have a DSCP and other properties. We want to be able to describe those properties and assign the packets to an LSP. Our aim is that we can do all that with our PCEP Flowspec descriptors (and we think we can).

There are four other components of this system:
1. Decide which LSPs to set up
2. Decide what code points to use on an LSP
3. Tell the head end what code point to use
4. Decide which traffic flows to assign to which LSPs
(The fifth step of telling the head end what traffic to put on the LSP is the subject of this draft.)
I think steps 1, 2, and 4 belong with a central controller/PCE.
Step 3 belongs in PCEP, just not in this draft.

> > The second point you raise is about rate limiting, or maybe we should call it
> > policing. When an LSP is set up, bandwidth is assigned within the network; you
> > are asking, we think, whether we can add a control for whether the traffic should
> > be limited to that assigned bandwidth or not.
> >
> [OD] I agree that just one bits is not sufficient for that purpose, but I would not
> start the discussion by requesting too much modification i.e. adding a new Policy
> TLV or Object.
> 
> > Furthermore, we think that the subscription rate is probably a quality of the LSP
> > itself rather than specific to the flowspec. We'd like to propose, therefore, that
> > we define a new parameter for the PCEP messages that would be a Policing TLV
> > (possibly in a new object or possibly in an existing object - that needs to be
> > though about) that carries the percentage that the LSP should be loaded (range 0
> > to 200% ?).
>
> [OD] I think the 2 approaches are complementary. In fact it corresponds to what
> is named ingress-policy and egress-policy. With my proposal, I would address the
> case of the egress-policy where the router will police and eventually shape/pace
> the traffic of the LSP according to the amount of bandwidth reserved during the
> PCReq of PCinitiate phase. This will ensure that the ingress router (i.e. the PCC)
> will not send more traffic than that has been reserved during the Path
> Computation performed by the PCE. This will allow an operator to guarantee that
> the LSP could carry the negotiated bandwidth while not disturbing the other LSPs
> for which the operator has also some commitments (i.e. respect the negotiated
> SLA of __all__ LSP of __all__ customers).
> Your approach allow to specify the ingress-policy associated to the flowspec. If
> the egress-policy is quiet simple and could accommodate of only 1 bit indication,
> the ingress-policy need a new Policy TLV or Object. Of course, we could
> generalize this new Policy to egress-policy which allow a more flexible
> management e.g. determine if we perform just a rate-limit, a rate-limit + shaping,
> the percentage of the bandwidth ... It is also mandatory if the LSP carry more
> than one CoS i.e. an E-LSP. In this case, we need to specify the percentage of
> bandwidth of each CoS which required also a new Policy TLV.

Actually, I was not trying to describe "ingress-policy associated to the flowspec." My intention was to describe the gross ingress-policy associated with the whole LSP.

This seems to be getting more complicated the more we talk about it :-) I'd like us to be able provide this function, but I want us to get it right. I wonder if ...

> [OD] Fine. Let me know if you need help to write some new sections for this

Definitely!

On my list of work.

Best,
Adrian