Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt

From: [email-masked]
Date: Mon, 19 Oct 2015 15:36:32 +0800

Dear,

   Thanks for your precise discussion :)

   In other word, even under bidirectional scenario,  there is no need to 
add per-SFP state to assist the forwarding on the SFs.
   Then, please return back to the very beginning, if in the diagram SF3 
receives traffic from mixed environments, how SF3 to correctly analyze the 
Mandatory Context Headers in NSH within the arriving traffic? It seems 
that adding per-SFP state to identify Context payload isn't the best 
choice, instead, coloring the Context payload explicitly like section 4.1 
would be better :)

   Thanks,

Wishes,
Linda Wang

Sumandra Majee <[email-masked]> 写于 2015/09/22 13:54:45:

> Sumandra Majee <[email-masked]> 
> 2015/09/22 13:54
> 
> 收件人
> 
> "Joel M. Halpern" <[email-masked]>, Dave Dolson 
> <[email-masked]>, "Carlos Pignataro (cpignata)" 
> <[email-masked]>, "[email-masked]" <[email-masked]>, 
> 
> 抄送
> 
> Wei Meng <[email-masked]>, "[email-masked]" <[email-masked]>
> 
> 主题
> 
> Re: [sfc] New Version Notification for 
draft-wang-sfc-md-type-issues-00.txt
> 
> The association can be made on variety of attribute,
>    A) subscriber info
>    B) network info e.g. Vlan. In the diagram SF3 is rcving flows from 
two
> different type services on two distinct interfaces.
> 
> However this can be either configured, pushed over control plane. All 
are
> fine but it is perhaps much better to color the context payload
> explicitly. I also don’t think the allocation will end with mobile and 
dc.
> 
> Regards
> Sumandra
> 
> On 9/21/15, 10:31 AM, "sfc on behalf of Joel M. Halpern"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
> >Unless we are using per-subscriber SFPs (which scalesvery badly, but 
you
> >can do it) I would expect that association to be made on the basis of
> >subscriber metadata.  In normal circumstances, the path ID is neither
> >necessary nor sufficient for the service function to enable symmetry.
> >
> >Even if the SFPs are at a granularity so that there are separate SFP 
IDs
> >for helping enforce path symmetry, that will not provide the state
> >needed for the service functions.  And the state that is needed for the
> >service functions is, in all cases I can see, sufficeint without
> >examining the SFP ID.
> >
> >Yours,
> >Joel
> >
> >On 9/21/15 1:11 PM, Dave Dolson wrote:
> >> At least some service functions require per-SFP state to associate
> >>bidirectional paths to each other.
> >>
> >>
> >> -----Original Message-----
> >> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> >> Sent: Monday, September 21, 2015 12:56 PM
> >> To: Carlos Pignataro (cpignata); [email-masked]
> >> Cc: Wei Meng; [email-masked]
> >> Subject: Re: [sfc] New Version Notification for
> >>draft-wang-sfc-md-type-issues-00.txt
> >>
> >> First, if we are doing to assume that Service Functions will use the
> >> SFP-ID to disambiguate type-1 metadata in mixed environments, we 
should
> >> say that in the draft.
> >>
> >> Second, I am a bit concerned by this proposed behavior, because we 
have
> >> been careful up till now to have the Service Functions act on 
metadata
> >> without requiring per-SFP state.  This would mark a significant 
shift.
> >>
> >> yours,
> >> Joel
> >>
> >> On 9/21/15 6:36 AM, Carlos Pignataro (cpignata) wrote:
> >>> Linda,
> >>>
> >>> It seems the issue that this draft attempts to raise can be 
summarized
> >>> with this question:
> >>>
> >>> "When traffic is steered to SF3, how SF3 to correctly analyze the
> >>> Mandatory Context Headers in NSH within the arriving traffic?"
> >>>
> >>>
> >>> The solution to this, however, is neither of what's presented in
> >>> Sections 4.1 and 4.2. The answer is much simpler and already there: 
the
> >>> SFP (by way of the SFP ID) provides context to understand the format 
of
> >>> the metadata. In other words, a given SFP ID will use one of the MD
> >>> formats/syntax (DC, Mobility, something else).
> >>>
> >>> Thanks,
> >>>
> >>> Thumb typed by Carlos Pignataro.
> >>> Excuze typofraphicak errows
> >>>
> >>> On Sep 21, 2015, at 04:26, "[email-masked]
> >>> <mailto:[email-masked]>" <[email-masked]
> >>> <mailto:[email-masked]>> wrote:
> >>>
> >>>>
> >>>> Dear all,
> >>>>
> >>>>     Here is a new draft proposed to raise an issue which may exist
> >>>>when
> >>>> MD Type=0x01 is mandatory.
> >>>> And to motivate the further discussion about MD Type. Wish you can 
pay
> >>>> attention to this to
> >>>> continue the discussion and make a consensus ;)
> >>>>
> >>>>    Thanks..
> >>>>
> >>>> Best Wishes,
> >>>> Linda Wang
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> [email-masked] <mailto:[email-masked]> 写于
> >>>> 2015/09/21 16:13:57:
> >>>>
> >>>>> [email-masked] <mailto:[email-masked]>
> >>>>> 2015/09/21 16:13
> >>>>>
> >>>>> 收件人
> >>>>>
> >>>>> "Cui Wang" <[email-masked] <mailto:[email-masked]>>,
> >>>> "Wei Meng"
> >>>>> <[email-masked] <mailto:[email-masked]>>, "Cui Wang"
> >>>> <[email-masked] <mailto:[email-masked]>>, "Wei
> >>>>> Meng" <[email-masked] <mailto:[email-masked]>>,
> >>>>>
> >>>>> 抄送
> >>>>>
> >>>>> 主题
> >>>>>
> >>>>> New Version Notification for draft-wang-sfc-md-type-issues-00.txt
> >>>>>
> >>>>>
> >>>>> A new version of I-D, draft-wang-sfc-md-type-issues-00.txt
> >>>>> has been successfully submitted by Cui Wang and posted to the
> >>>>> IETF repository.
> >>>>>
> >>>>> Name:      draft-wang-sfc-md-type-issues
> >>>>> Revision:   00
> >>>>> Title:      Metadata Type Issues
> >>>>> Document date:   2015-09-21
> >>>>> Group:      Individual Submission
> >>>>> Pages:      14
> >>>>> URL: https://www.ietf.org/internet-drafts/draft-wang-sfc-
> >>>>> md-type-issues-00.txt
> >>>>> Status: https://datatracker.ietf.org/doc/draft-wang-sfc-md-
> >>>>> type-issues/
> >>>>> Htmlized: 
> >>>>>https://tools.ietf.org/html/draft-wang-sfc-md-type-issues-00
> >>>>>
> >>>>>
> >>>>> Abstract:
> >>>>>     Service function chain is the definition of an ordered set of
> >>>>>service
> >>>>>     functions.  After instantiated, the service function path is
> >>>>>created
> >>>>>     and the classified traffic is steered through the 
corresponding
> >>>>>     service function path and then forwarded to the final
> >>>>>destination.
> >>>>>     Metadata (MD) is conveyed in SFC data plane which provides the
> >>>>>     ability to exchange context information between classifiers 
and
> >>>>>SFs,
> >>>>>     among SFs, and between external systems and SFs.  This 
document
> >>>>>is
> >>>>>     motivated to state an issue when MD Type = 0x1 and discuss 
which
> >>>>>     Metadata Type in more appropriate to be mandate in SFC data
> >>>>>plane.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Please note that it may take a couple of minutes from the time of
> >>>> submission
> >>>>> until the htmlized version and diff are available at 
tools.ietf.org
> >>>> <http://tools.ietf.org>.
> >>>>>
> >>>>> The IETF Secretariat
> >>>>>
> >>>> _______________________________________________
> >>>> sfc mailing list
> >>>> [email-masked] <mailto:[email-masked]>
> >>>> https://www.ietf.org/mailman/listinfo/sfc
> >>>
> >>>
> >>> _______________________________________________
> >>> sfc mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/sfc
> >>>
> >>
> >> _______________________________________________
> >> sfc mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/sfc
> >>
> >
> >_______________________________________________
> >sfc mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Dave Dolson <[email-masked]>
Date: Thu, 29 Oct 2015 21:26:50 +0000

Reinaldo et al,

I took another look at draft-penno-sfc-packet-02.

tl;dr: Overall, I think the SF needs to know something about the paths, so the problem cannot be solved entirely in the SFF. So solutions 5.1 and 5.4 are preferable.

As I understand section 5.1, a controller would provide the SF with pairings of complementary path coordinates.
E.g.,
Configuration says, “SPI x, SI i  is paired with SPI y, SI j”
This would mean that for a packet with SPI=x and SI=i, it can be responded with a packet on SPI=y and SI=j,
and also the opposite, that for a packet with SPI=y and SI=j, it can be responded with a packet on SPI=x and SI=i.

(In section 5.2, the same configuration needs to be given to the SFF, I believe, so there is no getting around the data model.)

In draft-ietf-sfc-control-plane-00, the C3 interface provides some information to the SF.
“…informs the SFC-aware SF about the semantics of a context information, which would otherwise have opaque meaning.”
I guess this could be reworded to be clear about describing the bidirectional semantics of different NSH coordinates.

In addition to that description of C3 interface, I’d like to point out another reason why path information is useful to the SF:
--> some SFs would like to know which side of the flow is internal vs. external
   - e.g., a firewall provides different policy to outbound packets than inbound packets.

I also appreciate the 5.4 algorithmic approach.
In this approach, do you think it would be reasonable to accept a convention like:
- paths 1..127 are outbound and
- paths 255..128 are inbound?

(You probably realize this, but it’s equivalent view is to treat the SI as a 2’s complement signed value. The opposite direction is the negative value.
In your example, the pair of 6 is calculated as (256-6)=250, which is -6.)

So, from my point of view, there either needs to be an interface to the SF, or an established convention about path symmetry and packet up/down direction, as well as whether metadata is service-path-invariant.

-Dave

From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Monday, September 21, 2015 2:06 PM
To: Joel M. Halpern; Dave Dolson
Cc: [email-masked]
Subject: Re: [sfc] in-path packet generation

We studied this issue considerably and documented the solutions we implemented here:

URL:            https://www.ietf.org/internet-drafts/draft-penno-sfc-packet-00.txt
Status:         https://datatracker.ietf.org/doc/draft-penno-sfc-packet/
Htmlized:       https://tools.ietf.org/html/draft-penno-sfc-packet-00

Abstract:
   Service Functions (e.g., Firewall, NAT, Proxies and Intrusion
   Prevention Systems) generate packets in the reverse flow direction to
   the source of the current in-process packet/flow.  In this document
   we discuss and propose how to support this required functionality
   within the SFC framework.

On 9/21/15, 10:59 AM, "sfc on behalf of Joel M. Halpern" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

That is an aspect that I had not considered in asking your question.
That is not about symmetry of SFPs, but about the behavior of service
functions which generate extra packets in each direction.

Over all, that is seriously under-specified, and we should address it.

While I don't know what answer the working group will adopt, my
inclination is to say that such packet generation needs a classifier.
The service function generates the packet with whatever metadata it
wants to attach, and then hands it to a classifier to determine what to
do with it.

Separately, I would note that even if we adopt an SFP-stateful solution
for such service functions, I would not want the metadata handling to
drive a requirement for such state in all service functions in order to
understand the metadata.
Before someone argues that this would only be needed in hybrid
deployments, I would observe that I expect service functions to be
designed and built to work in both dedicated and hybrid deployments.
And if MD-1 is a MUST (as it currently is written) then they all have to
have this capability.

Yours,
Joel

On 9/21/15 1:40 PM, Dave Dolson wrote:
I might be missing something, but let's take a very simple case: a proxy SF needs to respond to a SYN packet received on a SFP with a SYN-ACK. Which SFP should the SYN-ACK be placed on?

I've been assuming there needs to be a configuration to pair up left-to-right with right-to-left SFPs, and that the C3 interface would eventually provide this.

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Monday, September 21, 2015 1:32 PM
To: Dave Dolson; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Cc: Wei Meng; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt

Unless we are using per-subscriber SFPs (which scalesvery badly, but you
can do it) I would expect that association to be made on the basis of
subscriber metadata.  In normal circumstances, the path ID is neither
necessary nor sufficient for the service function to enable symmetry.

Even if the SFPs are at a granularity so that there are separate SFP IDs
for helping enforce path symmetry, that will not provide the state
needed for the service functions.  And the state that is needed for the
service functions is, in all cases I can see, sufficeint without
examining the SFP ID.

Yours,
Joel

On 9/21/15 1:11 PM, Dave Dolson wrote:
At least some service functions require per-SFP state to associate bidirectional paths to each other.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, September 21, 2015 12:56 PM
To: Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Cc: Wei Meng; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt

First, if we are doing to assume that Service Functions will use the
SFP-ID to disambiguate type-1 metadata in mixed environments, we should
say that in the draft.

Second, I am a bit concerned by this proposed behavior, because we have
been careful up till now to have the Service Functions act on metadata
without requiring per-SFP state.  This would mark a significant shift.

yours,
Joel

It seems the issue that this draft attempts to raise can be summarized
with this question:

The solution to this, however, is neither of what's presented in
Sections 4.1 and 4.2. The answer is much simpler and already there: the
SFP (by way of the SFP ID) provides context to understand the format of
the metadata. In other words, a given SFP ID will use one of the MD
formats/syntax (DC, Mobility, something else).

Thanks,

On Sep 21, 2015, at 04:26, "[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]><mailto:[email-masked]%3e>" <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]><mailto:[email-masked]%3e>> wrote:

Dear all,

      Here is a new draft proposed to raise an issue which may exist when
MD Type=0x01 is mandatory.
And to motivate the further discussion about MD Type. Wish you can pay
attention to this to
continue the discussion and make a consensus ;)

     Thanks..

Best Wishes,
Linda Wang

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> 写于
2015/09/21 16:13:57:

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
2015/09/21 16:13

收件人

"Cui Wang" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>,
"Wei Meng"
<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>, "Cui Wang"
<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>, "Wei
Meng" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>,

抄送

主题

Htmlized: https://tools.ietf.org/html/draft-wang-sfc-md-type-issues-00

Abstract:
      Service function chain is the definition of an ordered set of service
      functions.  After instantiated, the service function path is created
      and the classified traffic is steered through the corresponding
      service function path and then forwarded to the final destination.
      Metadata (MD) is conveyed in SFC data plane which provides the
      ability to exchange context information between classifiers and SFs,
      among SFs, and between external systems and SFs.  This document is
      motivated to state an issue when MD Type = 0x1 and discuss which
      Metadata Type in more appropriate to be mandate in SFC data plane.

Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org
<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc