Subject: [bess] BGP/SFC encoding of things that will not work

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 12 Nov 2016 22:32:46 -0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 13 Nov 2016 04:48:46 -0500

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:
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 13 Nov 2016 15:15:34 -0000

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-masked]] On Behalf Of Joel M. Halpern
> Sent: 13 November 2016 09:49
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [sfc] [bess] BGP/SFC encoding of things that will not work
> 
> Fair enough.
> 
> > 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".
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Ron Parker <[email-masked]>
Date: Sun, 13 Nov 2016 16:00:17 +0000

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-masked]] On Behalf Of Adrian Farrel
Sent: Sunday, November 13, 2016 10:16 AM
To: 'Joel M. Halpern' <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] [bess] BGP/SFC encoding of things that will not work

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

> 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.
> 
> not work.  Or if they can not tell if the necessary external 
> properties can be met.
> 
> Yours,
> Joel
> 
> >> 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.
> >
Perhaps you
work".

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 13 Nov 2016 17:10:58 -0500

In regard to this particular aspect of the proposal, my concern would be 
significantly alleviated if the text said that different service3 
function types could be used in a choice only when they were 
interchangeable / equivalent for the purposes of the service function 
path.  While there still would be ways to misuse it (that is true of 
most of our solutions), at least the develoepr and user would understand 
when it was expected to work.

Yours,
Joel