Hi Julien, Long ago you sent your review. Comments in line.
At the same time, we see that IDR has basically completed work on draft-ietf-idr-rfc5575bis and we think we should update this document to use that as a reference instead of RFC 5575 and RFC 7674. Finally, someone contacted us privately to ask that we add a flag to a PCEP flowspec to indicate that it should not be installed as a data plane filter, but should be installed as a 'normal route' with longest prefix matching. That is a simple change, but nevertheless a change of technical substance. I'll send a separate email to the list to see whether anyone else is interested and determine whether we can craft some text. I'll do a new revision and then start the thread for the additional point noted above. Best wishes for the New Year, Adrian === > I still have one pending question, related to section 8.7. (Priorities > and Overlapping Flow Specifications). I understand this section as > "priorities within PCEP-installed flow specs follow the same ordering > rules as BGP-installed flow specs, i.e. [RFC5575]". Let us now look at a > device supporting both protocols to install flow specs: > - Is there an implicit scope associated to each set of flow specs making > them mutually exclusive? > - If both sets can overlap, can we assume that priority rules do not > care about the protocol used to install the flow specs? > Adding a couple of sentences may be enough to clarify that. You raise a very good point. I am not certain how often this is going to arise, but it seems almost certain that were we to decide it could never arise, it would immediately become a requirement from the field. So we should address it. Now, draft-ietf-idr-rfc5575bis-18.txt talks only about BGP, but section 5.1 gives a description of how flow specifications are ordered for traffic matching regardless of what order they arrive in BGP. I think we should assume that all traffic is open to all flowspecs whether installed by BGP for firewalls or routing, or installed by PCEP for classification onto traffic paths (LSPs or SR paths). I believe that similar work is being looked at for classification of traffic onto service function chains, and I imagine that those flowspecs might also coincide with BGP and PCEP flowspecs. I think that all we need do is: - call out that both protocols might be simultaneously present and distributing flowspecs for installation - make the observation that the rules defined in section 5.1 of draft-ietf-idr-rfc5575bis apply regardless of which protocol distributed the flowspec. That brings me to the text in 8.7: OLD Flow specifications can overlap. For example, two different flow specifications may be identical except for the length of the prefix in the destination address. In these cases the PCC must determine how to prioritize the flow specifications so as to know to which path to assign packets that match both flow specifications. That is, the PCC must assign a precedence to the flow specifications so that it checks each incoming packet for a match in a predictable order. The processing of BGP Flow Specifications is described in [RFC5575]. Section 5.1 of that document explains the order of traffic filtering rules to be executed by an implementation of that specification. PCCs MUST apply the same ordering rules as defined in [RFC5575]. NEW Flow specifications can overlap. For example, two different flow specifications may be identical except for the length of the prefix in the destination address. In these cases the PCC must determine how to prioritize the flow specifications so as to know to which path to assign packets that match both flow specifications. That is, the PCC must assign a precedence to the flow specifications so that it checks each incoming packet for a match in a predictable order. The processing of BGP Flow Specifications is described in [I-D.ietf-idr-rfc5575bis]. Section 5.1 of that document explains the order of traffic filtering rules to be executed by an implementation of that specification. PCCs MUST apply the same ordering rules as defined in [I-D.ietf-idr-rfc5575bis]. Furthermore, it is possible that Flow Specifications will be distributed by BGP as well as by PCEP as described in this document. In such cases implementations supporting both approaches MUST apply the prioritization and ordering rules as set out in [I-D.ietf-idr-rfc5575bis] regardless of which protocol distributed the Flow Specifications, however implementations MAY provide a configuration control to allow one protocol to take precedence over the other as this may be particularly useful if the Flow Specification make identical matches on traffic but have different actions. It is RECOMMENDED that when two Flow Specifications distributed by different protocols overlap, and especially when one acts to replace another, that a message be logged for the operator to understand the behaviour. END > Please find below a few additional nits. > ------ > 1. Introduction > > - The abstract uses "traffic engineered networks", the intro "traffic > engineering networks". I do not have any strong preference, but > consistency would be welcome. (By the way, no hyphen in > "traffic-engineered"?) Yes. "traffic engineering" > - s/to Generalized MPLS (GMPLS) networks/to Generalized MPLS > (GMPLS)-controlled networks/ OK > - s/about the the LSPs/about the LSPs/ oops > - OLD: > The data flows > intended for a tunnel can be described using Flow Specification > Components, and when PCEP is in use for tunnel initiation it makes > sense for that same protocol to be used to distribute the Flow > Specification Components that describe what data is to flow on those > tunnels. > NEW: > The data flows > intended for a tunnel can be described using Flow Specification > Components; when PCEP is in use for tunnel initiation, it makes > sense for that same protocol to be used to distribute the Flow > Specification Components that describe what data is to flow on those > tunnels. Going even further and using a period. > 3.2. Elements of Procedure > > - s/in each case including whether/in each case. This includes whether/ OK > 6. Flow Filter TLV > > OLD: > Only one Flow Filter TLV can be > present and represents the complete definition of a Flow > Specification for traffic to be placed on the tunnel indicated by the > PCEP message in which the PCEP Flow Spec Object is carried. > NEW: > Only one Flow Filter TLV can be > present and represents the complete definition of a Flow > Specification for traffic to be placed on a tunnel; this tunnel is > indicated by the PCEP message in which the PCEP Flow Spec Object > is carried. Again, a period. > 7. Flow Specification TLVs > > [Page 14] > "Two bit flags (S and G) are defined. They have the common meanings for > wildcarding in multicast." > -> At least a reference would be appreciated to teach about what > "common" refers to. I thought I was going to find this in 7761, but it wasn't that easy. Since the text immediately afterwards explains the bits anyway, we can change this to... Two bit flags (S and G) are defined to describe the multicast wildcarding in use. > [Page 15] > "if a Multicast Flow > Specification TLV is received with S bit = 0 and G bit = 1 the > receiver SHOULD respond" > -> Is there a reason why it is not a MUST? Right. I can't think of a "but MAY decide to let off fireworks and drink prosecco," so we'll use MUST. > 13. Manageability Considerations > > - s/view the the Flow Specifications/view the Flow Specifications/ Again? > - s/implementations MUST support indicating/implementations MUST > indicate/ [Guessing it was wrongly fixed in -06.] Yes _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
