Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt

["Elzur, Uri" <[e-mail]>]

Catching up (was traveling myself, sigh)

I'm ok with the added text too.  I think it may solve your need/case, not sure how broad it is, but see no harm. It also requires some control plane interaction as the metadata is not guaranteed to stay constant for the duration, so the disclaimer you propose is necessary

Thx

Uri ("Oo-Ree")
C: 949-378-7568


-----Original Message-----
From: sfc [mailto:[e-mail]] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, April 14, 2016 10:04 AM
To: Dave Dolson <[e-mail]>
Cc: Elzur, Uri <[e-mail]>; [e-mail]
Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt

Hi Dave,

Sorry, I was traveling yesterday.  In principal I don't have any issues with the text since it doesn't impose requirements but rather clarifies a possible behavior.

I do wonder about how common this will be: a control of sorts is needed for semantic meaning -- in type 1 or type 2 cases.

Paul

> On Apr 14, 2016, at 9:33 AM, Dave Dolson <[e-mail]> wrote:
> 
> Paul and Uri, can you please comment as to whether you agree or disagree with this wording?
> 
> I feel that it allows the actual content to be opaque while giving 
> guidance for service functions that create or replay packets in the chain.
> 
> From my point of view, this is how such devices will work anyhow.
> 
> -Dave
> 
> 
> 
> -----Original Message-----
> From: sfc [mailto:[e-mail]] On Behalf Of Dave Dolson
> Sent: Wednesday, April 13, 2016 9:13 AM
> To: Paul Quinn (paulq); Ron Parker
> Cc: Thomas Narten; [e-mail]
> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
> 
> Paul,
> Are you unhappy with the metadata constraints I suggested below?
> Perhaps qualified by "In the absence of out-of-band configuration..." ?
> 
> I believe that the schemes proposed in these drafts satisfy the constraints:
> - draft-sfc-nsh-dc-allocation-4,
> - draft-napper-sfc-nsh-broadband-allocation-00
> 
> (I thought there were more allocation schemes, but I guess they 
> expired.)
> 
> I'll update it here:
> 
>   In the absence of out-of-band configuration to indicate otherwise,
>   metadata used in NSH headers must meet the condition that
>   a transport-layer-stateful Service Function can save away
>   metadata values that it has witnessed.  An injected packet can
>   therefore be assigned a clone of metadata taken from an earlier
>   packet going in the same direction.  For example, a Service Function
>   can send a TCP packet using metadata cloned from another TCP packet
>   of the same connection and direction.
> 
>   Note that the Service Function need not know the meaning of the
>   metadata; it just needs to know it is safe to clone in this manner.
> 
> 
> -Dave
> 
> 

_______________________________________________
sfc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sfc