Re: [spring] Dynamic Proxy in SR service programming

["Joel M. Halpern" <[e-mail]>]

Thank you.  I think it would help if this were spelled out more clearly 
in the draft.

Yours,
Joel

On 7/26/2020 3:32 PM, Francois Clad (fclad) wrote:
> Hi Joel,
> 
> Thank you for your email.
> 
> At high-level, the dynamic proxy combines a caching mechanism with a mapping scheme that associates cache entries to packets or flows.
> 
> There are many possible mapping schemes, each has pros and cons that make it more suitable in some environments and less in others. This I-D describes a simple one, which is interface-based (or VLAN-based), and implies that a dynamic proxy SID is used in a single SID-list at a time. This makes it particularly suitable for container-based environments, where VNFs are spawned on a per-SFC basis.
> 
> In different environments, other mapping techniques could be used, such as those described in draft-song-sfc-legacy-sf-mapping.
> 
> Cheers,
> Francois
> 
> 
> On 26/07/2020 02:57, "spring on behalf of Joel M. Halpern" <[e-mail] on behalf of [e-mail]> wrote:
> 
>      Thank you.  That does clarify, and it would probably be good to be
>      explicit in the document.  (The restriction makes sense, we just need to
>      be clear.)
> 
>      Yours,
>      Joel
> 
>      On 7/25/2020 8:31 PM, Stefano Salsano wrote:
>      > Il 2020-07-25 19:49, Joel M. Halpern ha scritto:
>      >> <chair hat off; speaking only as an individual member of the WG>
>      >>
>      >> In looking at the description of the dyanmic proxy behavior, I was
>      >> reminded of a problem that the SFC working group wrestled with and
>      >> never resolved to our satisfaction.  (In the SFC case, since we were
>      >> not specifying the behavior of the proxy, we could leave it to
>      >> implementors.   This document seems to be more specific.)
>      >>
>      >> As I understand the draft, the dyanicm proxy for a non-SR aware
>      >> service function can be handling packets subject ot multiple service
>      >> policies. That is desirable.  These separate policies will have
>      >> separate cache entries.  Also good.
>      >> But as far as I can tell, the re-attachment of the cached header to
>      >> the returned packet (from the non-SR aware SF) is done based on first
>      >> come, first cache.
>      >
>      > Hi Joel,
>      >
>      > I'm speaking as an author of draft-ietf-spring-sr-service-programming-02
>      > (but I do not know if my opinion is agreed by all the authors)
>      >
>      > my understanding of the dynamic proxy scenario is that a given "non-SR
>      > aware service function" (aka "legacy VNF") can be associated with a
>      > single Service Chain at a given time
>      >
>      > so you can dynamically change the Service Chain by sending a Packet-2
>      > with a different SR policy with respect to Packet-1, but this is meant
>      > to change the Service Chain for the following packets of the flow,
>      > rather than to operate on a packet-by-packet basis
>      >
>      > you are right that operating on a packet-by-packet basis leads to
>      > inconsistent behavior!
>      >
>      > In draft-ietf-spring-sr-service-programming-02, the following limitation
>      > is associated to the static SR proxy, but it also applies to the dynamic
>      > proxy:
>      >
>      >     However, a static SR proxy
>      >     segment can be used in only one service policy at a time.  As opposed
>      >     to most other segment types, a static SR proxy segment is bound to a
>      >     unique list of segments, which represents a directed SR service
>      >     policy.  This is due to the cached SR information being defined in
>      >     the segment configuration.  This limitation only prevents multiple
>      >     segment lists from using the same static SR proxy segment at the same
>      >     time, but a single segment list can be shared by any number of
>      >     traffic flows.
>      >
>      > This is he description of the dynamic proxy:
>      >
>      >     The dynamic proxy is an improvement over the static proxy that
>      >     dynamically learns the SR information before removing it from the
>      >     incoming traffic.
>      >
>      > Maybe it would be better to explicitly clarify that the same limitation
>      > of the static SR proxy is applicable: "only one service policy at a
>      > time"... the difference is that you can change this association
>      > dynamically, e.g. in the order of few seconds but NOT on a
>      > packet-by-packet basis
>      >
>      > hope that it clarifies...
>      >
>      > ciao
>      > Stefano
>      >
>      >
>      >> What happens if, due to differences in internal processing, packets
>      >> from different service policies get swapped in time.  So packets go in
>      >> Packet-1, Packet-2, but come out Packet-2, Packet-1.  The text seems
>      >> to result in the proxy reattaching the SR information to the wrong
>      >> packets?
>      >>
>      >> Am I misreading the text?
>      >>
>      >> Depending upon ones, reading, this may apply to a case where a single
>      >> device is service as multiple static proxies for a single non-SR aware
>      >> SF.  It was not clear if that was intended to be allowed, but if so
>      >> the same issue would seem to apply.
>      >>
>      >> Yours,
>      >> Joel
>      >> <chair hat returning to wherever it belongs.>
>      >>
>      >> _______________________________________________
>      >> spring mailing list
>      >> [e-mail]
>      >> https://www.ietf.org/mailman/listinfo/spring
>      >
>      >
> 
>      _______________________________________________
>      spring mailing list
>      [e-mail]
>      https://www.ietf.org/mailman/listinfo/spring
>