I agree that there are risks associated with allowing configuration of options.
Indeed, control of traffic paths from intelligence outside the network is a danger. However, we allow that and some operators even use it. True, those with fat fingers or buggy software may inadvertently send data down the wrong path, create loops, or black-hole traffic. But if we were to suggest that it should not be possible for control of paths to be applied from outside the network, then we might find ourselves in trouble. Similarly, however, we also consider the application of choice from within the network to be useful. Consider, for example, the loose hop in a traffic engineered path. It is clear that a choice exists, but we don't specify how a node that expands a loose hop works out what path to use: it's a policy choice how the loose hop is expanded. Now, in the specific case, suppose I conceive three different load balancers. They all do load balancing, but they do it differently. Let's assign them different service function types so we can distinguish them. Now let's assume that we really don't want to use one of them in our service function path, but that we are happy to see any instance of a function of either of the other types on the path. See what we can do with our proposal? But I suspect your concern is slightly more complex. I think you may be worried about how additional information to inform a choice might be passed to an SFF. I think that, just as in the traffic routing case, there are many ways to answer the question. But the simplest case is choosing between an allowed set of SFIs using the local policy for balancing SF load. Hope this helps, Adrian > -----Original Message----- > From: sfc [mailto:[email protected]] On Behalf Of Joel M. Halpern > Sent: 13 November 2016 09:49 > To: [email protected]; [email protected] > Cc: [email protected] > Subject: Re: [sfc] [bess] BGP/SFC encoding of things that will not work > > Fair enough. > > In this case, what I was refering to is the combination of two > preorpties of the encoding of paths. > On teh one hand, it is extraordinarily flexible in being able to > represent a broad range of delegated choices (as well as allowing the > controller to advertise very specific things. > At the same time, it has no explanations for which ways of using those > tools will or will not work, are intended to work, or should not be used. > One example is the quesiton i raised on the list is an SFP with two SFF > each of which has two different SF types, A and B. That seems like a > natural thing to do, given the coding. It is extremely unlikely to > produce a desirable result in reality. > > There is significant value in a flexible represent. There is also > significant danger if the users can not figure out what will and will > not work. Or if they can not tell if the necessary external properties > can be met. > > Yours, > Joel > > On 11/12/16 5:32 PM, Adrian Farrel wrote: > > Joel said... > > > >> One of my concerns with the proposed BGP encoding is that it can represent > >> many things that will not work. This seems to make it fragile. > > > > Joel, if I may, can I call you out on that generalisation? > > > > I don't find anything in your statement that I can discuss or debate. Perhaps you > could help with an example of what thing you might encode that "will not work". > > > > Thanks, > > Adrian > > > > PS I have cross-posted this mail to SFC and BESS as requested by the AD > > > > _______________________________________________ > > BESS mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/bess > > > > _______________________________________________ > sfc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
