This was the very reason we introduced the concept of RSP. Perhaps the value
wasn't recognized so well at the time because we were wrestling with other
issues. But, IMO, RSP was always about the ability to have "loose hops" as
Adrian describes. And, as Adrian describes, the option to build and deploy a
network that runs somewhat autonomously (like dynamic IP routing) as well as
still allowing for a network that is more strictly controlled from an external
entity, like the way we often describe SDN. Both are valid, but the former
requires this "loose hop" "late binding" type of instance selection capability.
At one point, it was suggested by someone on the thread that the actual
resulting RSP could be stamped into a type 2 TLV. Such an encoding would
likely require not just a sequence of SFI's, but a sequence of {SFF, SFI} to
handle the multi-homed SFI case. It could be very useful for troubleshooting
and service assurance, too.
Ron
-----Original Message-----
From: sfc [mailto:[email protected]] On Behalf Of Adrian Farrel
Sent: Sunday, November 13, 2016 10:16 AM
To: 'Joel M. Halpern' <[email protected]>; [email protected]
Cc: [email protected]
Subject: Re: [sfc] [bess] BGP/SFC encoding of things that will not work
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
_______________________________________________
sfc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
