Alvaro Retana has entered the following ballot position for draft-ietf-pce-pcep-flowspec-10: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- §8.7: "it is possible that Flow Specifications will be distributed by BGP as well as by PCEP as described in this document...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." I understand the need to allow one protocol to take precedence over the other. The concern I have is that in BGP's distribution model FlowSpecs are forwarded to other BGP speakers...which may not also be PCCs. If PCEP takes precedence, and the actions are different, then there might be nodes that take the BGP-defined action when not intended to...potentially resulting in unexpected forwarding or rate-limiting of the traffic. Clearly, this issue is related to the different distribution models for the information. If the operator took care of using BGP to distribute FlowSpecs to only the PCCs, then this issue wouldn't exist. I would like to see some text that provides guidance when using both distribution mechanisms. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [major comments] (1) What is the number/type of Flow Filter TLVs that can be included in the PCEP FLOWSPEC option? Is it up to one of each, or just one or the other? These text snippets seem to not be aligned: §3.2.2: "The PCEP FLOWSPEC object carries zero or one Flow Filter TLV or one L2 Flow Filter TLV or both Flow Filter TLV as well as L2 Flow Filter TLV, which describes a traffic flow." §6: "Only one Flow Filter TLV or L2 Flow Filter TLV can be present and represents the complete definition of a Flow Specification for traffic to be placed on the tunnel....The set of Flow Specification TLVs in a single instance of a Flow Filter TLV and L2 Flow Filter TLV are combined to indicate the specific Flow Specification. Note that the PCEP FLOWSPEC object can include just one Flow Filter TLV, just one L2 Flow Filter TLV, or one of each TLV." §7.1: "when both Flow Filter TLV and L2 Flow Filter TLV are present, they are combined to produce a more detailed specification of a flow" That first sentence from §6 indicates one or the other, but the other text talks about the possibility of both. If they are combined, how is that done? (2) Entity Identifier §5: The Speaker Entity Identifier TLV can be optionally included in the OPEN [rfc8232]...and it is required in the FLOWSPEC object. Should there be a relationship between the two? If the TLV is included in both objects, then I would expect the identifier to match. What should the receiver do if they don't match? Related... Should a receiver check that the same identifier is included in all FLOWSPEC objects? What if they're not? (3) §5: "All subsequent PCEP messages can identify the FlowSpec using the FS-ID." [This point is related to Ben's DISCUSS.] The description of the use of the Speaker Entity Identifier TLV says that it is "used in conjunction with FS-ID to uniquely identify the FlowSpec information." I take this to mean that the FS-ID *and* the identifier in the TVL are used in the identification. Is that correct? The text in §5 also talks about using only the FS-ID: "the Flow Specification identified with a FS-ID does not exist". And §8.3 emphasizes it again: "FS-ID field of the PCEP FLOWSPEC object is used to identify a specific Flow Specification". If only the FS-ID is needed, what is the Speaker Entity Identifier used for? (4) §8.4: "it is possible to to define these within a single PCEP FLOWSPEC object: for example, two Destination IPv4 Prefix TLVs could be included to indicate that packets matching either prefix are acceptable." Two Destination Prefix TLVs would be equivalent to two Type 1 components in a BGP FS, but that is not allowed by rfc5575bis. This document follows the same rules as in rfc5575bis -- is this an exception that I missed? It may just be a bad example... (5) §8.5: If the R bit is set and Flow Specification TLVs are present, an implementation MAY ignore them. If the implementation checks the Flow Specification TLVs against those recorded for the FS-ID of the Flow Specification being removed and finds a mismatch, the Flow Specification MUST still be removed and the implementation SHOULD record a local exception or log. Which "Flow Specification MUST still be removed"? The one previously advertised using the FS-ID, or the one specified in the TLVs, or both? [minor comments] (6) §1: "For convenience we term the description of a traffic flow using Flow Specification Components as a "Flow Specification" and it must be understood that this is not the same as the same term used in [I-D.ietf-idr-rfc5575bis] since no action is explicitly included in the encoding." rfc5575bis uses pretty much the same definition (from §3): A Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. A given IP packet is said to match the defined Flow Specification if it matches all the specified criteria. The actions are encoded separately. Note that the definition in §2 of FlowSpec, apparently from rfc5574bis, is not included there. (7) §5: "L bit...If the bit is set, only Flow Specifications that describe IPv4 or IPv6 destinations are meaningful in the Flow Filter TLV." If there is no meaningful information then what? I'm assuming that the object is just ignored... It might be nice to be explicit about that. Just a minor point. (8) §7: In the Multicast Flow Specification TLV, what does "(*, *)" match? Any source and any destination? What is source/group wildcarding? (9) §7.1: s/All L2 Flow Specification TLVs...(for example, in [I-D.ietf-idr-rfc5575bis] and [I-D.ietf-idr-flow-spec-v6])/All L2 Flow Specification TLVs...(for example, in [I-D.ietf-idr-flowspec-l2vpn]) [nits] s/flow specification/Flow Specification/g s/defines following new types -/defines the following new types: s/will be place/will be placed s/to to/to _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
