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. > > > > 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. 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 ... > > 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. Definitely! On my list of work. Best, Adrian _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
