Regarding the second of your two points, I am not following you:
On 10/11/17 8:00 PM, Sharon wrote:
Discussed these 2 ID networking items with Albert and others, perhaps
this is a good thread:
...
2. Lisp-Lambda -
A serverless (or virtual-appliance-less) alternative to service function
chaining which is hard to scale and dev-ops. Its done by mapping flows
at the ITR, ETR, or STR (segment) to queues, and using the mapping to
invoke the (cached) function on the flow queue packets rather then hair
pining the packets in and out of function virtual appliances. Saves
nic-ram-nic-ram... costly lifting.
I am not asking why or how one can use LISP to direct traffic. I
understand that.
Rather, the description of service function chaining is veyr confusing.
1) One of the points of SFC is to direct packets to virtual service
functions. We are not mandating virtual service functions, but rather
enabling their use when operators want to use them. A technique that
avoids such direction would seem to prevent such usage, defeating the point.
2) NSH (and more generally SFC) can be used to direct traffic on paths
that do not happen to touch any service functions. If the service
function path goes through a sequence of service function forwarders,
but does not actually visit any service functions, nothing is violated.
So while I have no problem with using LISP for chaining (either using
LISP mapping to drive NSH SFPs or using LISP multi-hope technology for
the data plane) I find the explanation you provided avoce confusing.
Yours,
Joel
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
