Subject: [Pce] Alvaro Retana's Discuss on draft-ietf-pce-pcep-flowspec-10: (with DISCUSS and COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Wed, 26 Aug 2020 13:11:43 -0700

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