Hi Adrian,

Thanks for the answers. My comments below.

Regards

Olivier

Le 15/10/2018 à 14:37, Adrian Farrel a écrit :
> 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.
[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 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.
>
> 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
[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.
>
> 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.
>
> 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.
 [OD] I appreciate the new version of the draft that add clarification on that, 
in particular the new table in appendix.
>
>> -----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

Reply via email to