> Responding to just the Discuss portion due to time constraints before the > telechat...
Understood Top posting: This really feels like a problem for 5575bis. I'm beginning to think we overstepped by even mentioning it in this document. I wanted to draw out the risks and confusions (almost to say "don't do that") without trampling on existing practice or messing with BGP. This is (clearly?) not the document to tell people how to manage their BGP FlowSpecs, yet we wanted to inherit as much as possible from BGP, yet we don't want people to damage themselves, yet the scissors are sharp and they enjoy running. You paragraph of suggestions of pointers of how/when to do AND and OR is a reasonable starting point. But surely it is something that belongs in 5575bis? Cheers, Adrian On Wed, Aug 26, 2020 at 09:51:52PM +0100, Adrian Farrel wrote: > Hi Ben, > > Thanks for the review. > A lot of very helpful comments and discussions. > All answers in line. > I have a working copy with the edits (hint to co-authors: *I* have the working copy :-) > > Best, > Adrian > > > DISCUSS: > > > > As with the others, I also found this document to be quite easy to > > read and well-structured; thank you! > > Kind of you to say so. > > > This is a Discuss because I want to have a discussion, not because I'm > > confident in the correctness of my position. But it seems like the > > ambiguity about when multiple flow specifications in single FLOWSPEC > > object are treated as logical AND to narrow a single flow specification > > versus treated as separate flow specifications per Section 8.4 could > > lead to confusion, and it would be simpler and have less risk to stick > > to the "one flow specification per FLOWSPEC object" model as discussed > > in the rest of the document. If the ability to define multiple flows > > within a single FLOWSPEC object is retained, I think we need more > > specific procedures for identifying when that is the case, quite > > possibly with a specific enumeration of cases. > > The specification of a flow can be complex. For example, > Destination address = 64.6.64.0/24 > Destination port number = 53 > Packet length > 1600 bytes > > These elements are each encoded in a separate Flow Specification TLV. Combined (using AND), they describe the Flow Specification. > > All of the elements of a Flow Specification (all of the Flow Specification TLVs) are included in a single Flow Filter TLV thus providing a grouping. Thus a Flow Filter TLV describes the Flow Specification. > > A Flowspec Object can contain zero or one Flow Filter TLV. Thus the object (when it contains a Flow Filter TLV) describes the Flow Specification. > > A PCEP message can contain multiple Flowspec Objects thus applying the function of the message to multiple Flow Specifications. > > So far, so good. Yup. > A little confusingly, we might want to describe a Flow Specification as: > Destination address = 64.6.64.0/24 or 64.6.65/24 > Destination port number = 53 > Packet length > 1600 bytes > > This could be done by defining two separate specifications. But there is a tendency to want to provide one Flow Filter TLV with four Flow Specification TLVs indicating > Destination address = 64.6.64.0/24 > Destination address = 64.6.65/24 > Destination port number = 53 > Packet length > 1600 bytes I understand that this is the sort of thing that is done, and that it is an attrative convenience... > The parser is expected to know when to apply AND and when to apply OR to construct the Flow Specification. I can't say I think this is hygienic, but it is 'common' practice in the BGP world, and it is basically functional. So we allow it as well (after all, it is probably the same code processing and installing the Flow Specifications). I'm mostly just worried about the latent risk of leaving it up to the parser to just "know", since my parser may disagree with your parser. It may well be that this is a topic that should be handled in common for PCEP and BGP (I don't have the BGP details at hand right now) and thus punted to IDR, but I would feel a lot more comfortable if there was some specific list of things that get OR treatment when appearing multiple times. (Or is the rule that if a single sub-TLV appears multiple times it's always OR, and the AND is for sub-TLV types? That's actually a pretty easy rule to enforce...) Src/dst IP address and port seem like prety obvious ORs, but is there anything else? What about the case of a packet length range, only packets between 500 and 1500 bytes on this path, with smaller ones and bigger ones getting their own paths? > However, 8.4 points out the risks and confusions associated, and indicates how those issues are resolved. Indeed, the discussion of risks/confusions is key, and as promised I will not insist on changes. I am hopeful, though, that we can give more clear procedures and close off as much of the risk as possible. -Ben > > I also mention in the per-section comments several places where (IIUC) > > there seems to be a need to match the Speaker Entity Identifier TLV as > > well as the FS-ID value. It might even be an exhaustive list, but > > please do a pass to check. > > Handled in line in the Comments with cross-check to the whole document. Thanks, Ben _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
