Hi Adrian, The resolutions below are fine by me. Let's see how the discussion progresses on that filter/route switch and we'll be able to move forward.
Thanks, Julien On 05/01/2020 19:51, Adrian Farrel wrote: > 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 > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
