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:pce-boun...@ietf.org] On Behalf Of Olivier Dugeon > Sent: 20 July 2018 16:58 > To: pce@ietf.org > 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 > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
