Subject: Re: [sfc] NSH context headers: fixed/tlv

From: Sumandra Majee <[email-masked]>
Date: Fri, 4 Dec 2015 02:02:01 +0000

Hello Walter,

Inline.

>Hi Sumandra,
>
>Thanks for your feedback. From my point of view it would make some sense
>if the WG would elaborate more details on the actual forwarding
>requirements. Some would say use NSH SFP but the WG allowed that a SFP
>must not uniquely support a FW decision. Therefore the notion of a RSP.
>For sure we could  also use a SFP-ID plus some "SFP distinguisher" to
>ensure appropriate forwarding.

<SM> Good question. By the time I came back to IETF thread I see the
discussion progressed quite a bit. I do believe forwarding logic would
have take into account of,
   SFP-ID + PATH + [optional data] what you are calling SFP distinguisher.
Additional context for SFF to have intelligent forwarding choice.
Yes it could be ID + some additional context to select a particular
container on a host.
It could be information to bypass next SFF.

> 
>
>When you talk about a flow-id, do you mean the original naked user
>generated L2/L3 flow before entering the SFC overlay (tunnel) system? If
>yes, how does this information contribute to a constrained SFC overlay
>forwarding? We would use the flow entries and try to generate something
>like an "SFC entropy-ID" (not to say label) as a "SFP distinguisher" but
>will this data really include info on constrained SFC forwarding?

<SM> Flow ID was a bad choice of word, this may point to a particular
workload (which might map to multiple tcp flows), it can be msg or
transaction ID as set by classifier or proxy. SFF do need to understand
but this contextual data can be used to program the forwarding path.

<"SFC entropy-ID" (not to say label) as a "SFP distinguisher" but will
this data really include info on constrained SFC forwarding?>

<SM> What do you mean by constrained SFC forwarding?

> 
>
>Until now I thought a SFF first is a simple FW engine which may be
>extended to become a classifier. I've seen the intelligence located more
>in the SF. But well, it may be worth to think about your view that a SFF
>may have some more functionality.
>
>Best regards,
>Walter
>
>-----Ursprüngliche Nachricht-----
>Von: Sumandra Majee [mailto:[email-masked]]
>Gesendet: Donnerstag, 3. Dezember 2015 21:51
>An: Dave Dolson; Haeffner, Walter, Vodafone DE; David Melman; [email-masked]
>Betreff: Re: [sfc] NSH context headers: fixed/tlv
>
>
>
>On 12/3/15, 11:47 AM, "sfc on behalf of Dave Dolson"
><[email-masked] on behalf of [email-masked]> wrote:
>
>>My point about supporting all MD types was for SFF function only.
>>I don't believe SFFs need to parse past the start of the NSH header to
>>make a forwarding decision. SFFs don't need metadata or start of inner
>>packet.
>
>That is a very broad statement and I don¹t agree with that. If SFF wants
>to look at flowid, or at another contextual information to skip a portion
>of chain then that would be required. Furthermore it will perhaps
>restrict many other potential optimization and applications. SFF is a
>logical entity and can be implemented in software with highly
>programmable hooks or it can be a dumb next hop lookup engine.
>>
>>
>>
>