Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

["Reinaldo Penno (repenno)" <[e-mail]>]

Oh, how can I not defer toa request like that (;)

We can always say that sfc-packet ‘updates rfc xxxx’.

On 7/19/17, 12:50 PM, "Joel M. Halpern" <[e-mail]> wrote:

    I beg you not to ask for more changes to NSH.  The document is in good 
    shape.  It will never be perfect.  We need to finish it.
    
    Having said that, if you really think we need to fix something in the 
    document, you need to say so on the list.  I would VERY strongly request 
    that if you do so, please include explicit new text and a clear 
    description of where you think it goes.
    
    Yours,
    Joel
    
    On 7/19/17 11:48 AM, Reinaldo Penno (repenno) wrote:
    > My preference (as I explained to Dave offline) is based a lot on current implementations and the draft.
    > 
    > - I re-read NSH base and all examples have, as far as I can tell, unidirectional SPI. It might be legacy, an overlook, but that it is how I interpret it
    > - Many vendors might have taken that to heart. Yes, I know, you should not cast in stone your implementations based on draft…still.
    > 
    > Irrespective if we change that or not I believe NSH base should clearly state the relationship between forwarding and Path (or Path + ID). Saying nothing is asking for one of those IETF mile-long threads where somebody will argue that saying nothing is the same as ‘allowed’.
    > 
    > Thanks,
    > 
    > On 7/19/17, 11:37 AM, "Joel M. Halpern" <[e-mail]> wrote:
    > 
    >      Just for clarity, my preference between the algorithmic encoding methods
    >      is quite small.
    >      Yours,
    >      Joel
    >      
    >      On 7/19/17 4:29 AM, Kent Leung (kleung) wrote:
    >      > Hi Ron. The control plane (sect. 5.1) and encoded (sect. 5.3) methods are covered in the draft along with the pros and cons of each of the options. A method to generate asymmetric paths for asymmetric SFC is described in sect. 6. This technique is based on symmetric SI sequence with NOP. Both algorithmic (sects. 5.4.1 & 5.4.2) methods can leverage this SI scheme to support asymmetric SFC. So maybe we need to reword the draft better to explain that mirrored order for both directions is not assumed.
    >      >
    >      > Just updating the running count:
    >      >
    >      > Sect 5.4.1 (one service path ID, service index indicates flow direction):
    >      >
    >      > -	(4) Dave, Joel, Ron, Kyle
    >      >
    >      > Sect 5.4.2 (two service path IDs, each indicate flow direction):
    >      >
    >      > -	(6) Sumandra, Jim, Kent, Renaldo, Roberta, Paul
    >      >
    >      >   Kent
    >      >
    >      > -----Original Message-----
    >      > From: Ron Parker [mailto:[e-mail]]
    >      > Sent: Tuesday, July 18, 2017 4:12 PM
    >      > To: Joel M. Halpern <[e-mail]>; Kent Leung (kleung) <[e-mail]>; Reinaldo Penno (repenno) <[e-mail]>; Dave Dolson <[e-mail]>; Roberta Maglione (robmgl) <[e-mail]>; James N Guichard <[e-mail]>
    >      > Cc: [e-mail]
    >      > Subject: RE: [sfc] clarification on Service Path ID for draft-penno-sfc-packet
    >      >
    >      > Good point on the optionality of this bidirectional concept.
    >      >
    >      > For the bidirectional case, we would ultimately like to know the correlation of the 2 paths.    I'm thinking that this is more, even, than correlating the "forward" SPI and the "reverse" SPI.   It also becomes useful to correlate the position of a particular service function.   A strict presumption of mirrored order for the 2 directions does not always hold.   Lets say in the forward direction we want SF types A, B, C, D but in the reverse direction we want A, D, C, B.   It would be useful to know that SF D appears at the 4th position of the forward flow and the 2nd position of the correlated reverse flow.   This starts to become too heavy to insert into the encapsulation itself.   Instead, this full knowledge can be achieved through control plane distribution and stateful elements (e.g., SFF, SF).
    >      >
    >      > So, the encapsulation can carry all of the correlation information, none of the correlation information, or some of the correlation information.    I'm not so sure "some" is that useful.
    >      >
    >      >     Ron
    >      >
    >      >
    >      > -----Original Message-----
    >      > From: Joel M. Halpern [mailto:[e-mail]]
    >      > Sent: Tuesday, July 18, 2017 9:58 AM
    >      > To: Ron Parker <[e-mail]>; Kent Leung (kleung) <[e-mail]>; Reinaldo Penno (repenno) <[e-mail]>; Dave Dolson <[e-mail]>; Roberta Maglione (robmgl) <[e-mail]>; James N Guichard <[e-mail]>
    >      > Cc: [e-mail]
    >      > Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet
    >      >
    >      > Since there are not always two directions, I would prefer not to define that bit as always meaning direction.  I do not mind if the bit is used by configuration in a directional fashion.  (It is odd, but clearly works.)
    >      >
    >      > Yours,
    >      > Joel
    >      >
    >      > On 7/18/17 9:12 AM, Ron Parker wrote:
    >      >> I support 5.4.1 (single SPI with direction indicated in SI).   That
    >      >> being said, the approach effectively reduces SI by 1 bit and reallocates
    >      >> that bit to direction.   Is it feasible to instead be explicit by
    >      >> creating an direction bit?   Also, how do we refer to directions?
    >      >> East/West?   North/South?  Left/Right?   Upstream/Downstream?
    >      >>
    >      >>      Ron
    >      >>
    >      >> *From:* sfc [mailto:[e-mail]] *On Behalf Of *Kent Leung
    >      >> (kleung)
    >      >> *Sent:* Tuesday, July 18, 2017 4:54 AM
    >      >> *To:* Reinaldo Penno (repenno) <[e-mail]>; Dave Dolson
    >      >> <[e-mail]>; Roberta Maglione (robmgl) <[e-mail]>;
    >      >> James N Guichard <[e-mail]>
    >      >> *Cc:* [e-mail]
    >      >> *Subject:* Re: [sfc] clarification on Service Path ID for
    >      >> draft-penno-sfc-packet
    >      >>
    >      >> Hi Reinaldo. I agree we need to get agreement in WG and update the
    >      >> draft soon as folks are unsure what to implement.
    >      >>
    >      >> It seems most folks have chimed in. Here’s the latest count. I’m
    >      >> putting names down to make sure the count is accurate.
    >      >>
    >      >> Sect 5.4.1 (one service path ID, service index indicates flow direction):
    >      >>
    >      >> -(2) Dave, Joel
    >      >>
    >      >> Sect 5.4.2 (two service path IDs, each indicate flow direction):
    >      >>
    >      >> -(6) Sumandra, Jim, Kent, Renaldo, Roberta, Paul
    >      >>
    >      >> Do we have some rough consensus yet? Or wait for more opinions to decide?
    >      >>
    >      >> Kent
    >      >>
    >      >> *From:* Reinaldo Penno (repenno)
    >      >> *Sent:* Monday, July 17, 2017 3:59 PM
    >      >> *To:* Kent Leung (kleung) <[e-mail]
    >      >> <mailto:[e-mail]>>; Dave Dolson <[e-mail]
    >      >> <mailto:[e-mail]>>; Roberta Maglione (robmgl)
    >      >> <[e-mail] <mailto:[e-mail]>>; James N Guichard
    >      >> <[e-mail] <mailto:[e-mail]>>
    >      >> *Cc:* [e-mail] <mailto:[e-mail]>
    >      >> *Subject:* Re: [sfc] clarification on Service Path ID for
    >      >> draft-penno-sfc-packet
    >      >>
    >      >> Hi Kent/others,
    >      >>
    >      >> this decision is quite important for real deployments, as opposed to
    >      >> demos and related.  I hope as the first step we all agree that we
    >      >> cannot have more than one way of interpreting directionality of paths
    >      >> and associated reverse paths. That would be an interoperability
    >      >> nightmare and reduce the usefulness of NSH considerably.
    >      >>
    >      >> So, whatever way it goes the WG needs to embrace it.
    >      >>
    >      >> Thanks,
    >      >>
    >      >> *From: *sfc <[e-mail] <mailto:[e-mail]>> on
    >      >> behalf of "Kent Leung (kleung)" <[e-mail]
    >      >> <mailto:[e-mail]>>
    >      >> *Date: *Monday, July 17, 2017 at 10:36 AM
    >      >> *To: *Dave Dolson <[e-mail]
    >      >> <mailto:[e-mail]>>, "Roberta Maglione (robmgl)"
    >      >> <[e-mail] <mailto:[e-mail]>>, James N Guichard
    >      >> <[e-mail] <mailto:[e-mail]>>
    >      >> *Cc: *"[e-mail] <mailto:[e-mail]>" <[e-mail]
    >      >> <mailto:[e-mail]>>
    >      >> *Subject: *Re: [sfc] clarification on Service Path ID for
    >      >> draft-penno-sfc-packet
    >      >>
    >      >> Why can’t there be stats for per SPI and more granular stats for per
    >      >> SPI/SI? They seem to serve different purposes. The former is providing
    >      >> counters for all flows in each service path. The latter is provide
    >      >> counters for all flows served at each hop in the service path.
    >      >>
    >      >> Can you explain the “spiral” scenario and how that pertains to
    >      >> usefulness of having per service path stats? Thanks.
    >      >>
    >      >> Kent
    >      >>
    >      >> *From:* Dave Dolson [mailto:[e-mail]]
    >      >> *Sent:* Monday, July 17, 2017 3:01 PM
    >      >> *To:* Roberta Maglione (robmgl) <[e-mail]
    >      >> <mailto:[e-mail]>>; James N Guichard
    >      >> <[e-mail] <mailto:[e-mail]>>
    >      >> *Cc:* Kent Leung (kleung) <[e-mail]
    >      >> <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
    >      >> *Subject:* RE: [sfc] clarification on Service Path ID for
    >      >> draft-penno-sfc-packet
    >      >>
    >      >> Strictly, stats should be per SPI and SI, in order to support the
    >      >> so-called spiral.
    >      >>
    >      >> But I can see how folks might find the lazy implementation to be useful.
    >      >>
    >      >> *From:*Roberta Maglione (robmgl) [mailto:[e-mail]]
    >      >> *Sent:* Monday, July 17, 2017 11:00 AM
    >      >> *To:* James N Guichard
    >      >> *Cc:* Dave Dolson; Kent Leung (kleung); [e-mail]
    >      >> <mailto:[e-mail]>
    >      >> *Subject:* Re: [sfc] clarification on Service Path ID for
    >      >> draft-penno-sfc-packet
    >      >>
    >      >> I agree on the operational aspect: having different SPI's for each
    >      >> direction simplifies the troubleshooting procedures, as statistics on
    >      >> the packets counters for each direction on each SF, can be displayed
    >      >> just based on SPI.
    >      >>
    >      >> Regards,
    >      >>
    >      >> Roberta
    >      >>
    >      >> Inviato da iPad
    >      >>
    >      >>
    >      >> Il giorno 15 lug 2017, alle ore 01:09, James N Guichard
    >      >> <[e-mail] <mailto:[e-mail]>> ha
    >      >> scritto:
    >      >>
    >      >>      Yes understood but I was assuming no manipulation of the SI and my
    >      >>      point was more from an operational perspective; if I use the same
    >      >>      path ID in both directions then I cannot immediately tell in which
    >      >>      direction the packets are flowing unless I go one step deeper and
    >      >>      look at the SI leading to a correlation of SPI + SI to be able to
    >      >>      figure out my traffic matrix. Not so if the SPI is uni-directional.
    >      >>
    >      >>      Jim
    >      >>
    >      >>      *From:* Dave Dolson [mailto:[e-mail]]
    >      >>      *Sent:* Friday, July 14, 2017 2:51 PM
    >      >>      *To:* James N Guichard <[e-mail]
    >      >>      <mailto:[e-mail]>>; Kent Leung (kleung)
    >      >>      <[e-mail] <mailto:[e-mail]>>; [e-mail]
    >      >>      <mailto:[e-mail]>
    >      >>      *Subject:* RE: clarification on Service Path ID for
    >      >>      draft-penno-sfc-packet
    >      >>
    >      >>      There is not actually forwarding ambiguity, since SFF forwarding
    >      >>      depends on **both** SPI and SI.
    >      >>
    >      >>      So for example, there is no ambiguity in forwarding to use SI in the
    >      >>      range [0,127] of up-link and range [128,255] for down-link, on the
    >      >>      same SPI.
    >      >>
    >      >>      The limitation is ~127 SFs per path instead of ~255.
    >      >>
    >      >>      As I see it, Kent’s question is one of aesthetics. Do folks like the
    >      >>      same SPI used for two directions?
    >      >>
    >      >>      Personally, I find use of a single SPI to be more elegant,
    >      >>        consuming only one path ID instead of two. (section 5.4.1).
    >      >>
    >      >>      It may make debugging easier as well.
    >      >>
    >      >>      Also, for what it’s worth, we demonstrated this method of section
    >      >>      5.4.1 at a previous IETF hackathon.
    >      >>
    >      >>      -Dave
    >      >>
    >      >>      *From:*sfc [mailto:[e-mail]] *On Behalf Of *James N Guichard
    >      >>      *Sent:* Friday, July 14, 2017 2:25 PM
    >      >>      *To:* Kent Leung (kleung); [e-mail] <mailto:[e-mail]>
    >      >>      *Subject:* Re: [sfc] clarification on Service Path ID for
    >      >>      draft-penno-sfc-packet
    >      >>
    >      >>      Hi Kent,
    >      >>
    >      >>      [personal opinion …] I have always assumed that the service path ID
    >      >>      would be uni-directional given that it would be difficult to avoid
    >      >>      collision in all forwarding scenarios. If you look at a basic SFC
    >      >>      a-b-c and the service index is set to 255 at the classifiers a & c
    >      >>      (which imho will be the normal practice) then at b you would have a
    >      >>      conflict if the same service path ID is used in both directions.
    >      >>
    >      >>      Jim
    >      >>
    >      >>      *From:* sfc [mailto:[e-mail]] *On Behalf Of *Kent Leung
    >      >>      (kleung)
    >      >>      *Sent:* Friday, July 14, 2017 1:58 PM
    >      >>      *To:* [e-mail] <mailto:[e-mail]>
    >      >>      *Subject:* [sfc] clarification on Service Path ID for
    >      >>      draft-penno-sfc-packet
    >      >>
    >      >>      Hi. We are working on a revision for this draft. There were 4
    >      >>      proposed solution options in section 5. During some discussions,
    >      >>      most folks seem to favor the use of algorithmic method in section
    >      >>      5.4. However, there are 2 sub-options. One is based on same Service
    >      >>      Path ID and using Service Index to determine flow direction (sect.
    >      >>      5.4.1). The other is based on setting high order bit on Serve Path
    >      >>      ID, which determines flow direction (sect. 5.4.2). There are mixed
    >      >>      opinions. One reason is that there may be the assumption the Service
    >      >>      Path ID is uni-directional. No explicit wording of that nature has
    >      >>      been encountered in the RFCs, maybe we missed something?
    >      >>
    >      >>      If Serve Path ID is required to be uni-directional, then the answer
    >      >>      is easy (=> 5.4.2). We would like to solicit WG comments to get
    >      >>      rough consensus and revised the next version with that solution.
    >      >>      This problem is critical to address for Service Function that
    >      >>      generate packet in reverse direction, especially security service
    >      >>      functions as mentioned in draft-wang-sfc-ns-use-cases.
    >      >>
    >      >>      Thanks.
    >      >>
    >      >>      Kent
    >      >>
    >      >>      _______________________________________________
    >      >>      sfc mailing list
    >      >>      [e-mail] <mailto:[e-mail]>
    >      >>
    >      >> https://url.serverdata.net/?a_R6iwBQImYWCr69g6-h0raXDRY2EORuQb3vcjuo_j
    >      >> Yzi8LHrrWr1VlAzSt23U6FhEXpHwQ1RPMguMZ7RGyHHPw~~
    >      >>
    >      >> <https://url.serverdata.net/?a_R6iwBQImYWCr69g6-h0raXDRY2EORuQb3vcjuo_
    >      >> jYzi8LHrrWr1VlAzSt23U6FhEXpHwQ1RPMguMZ7RGyHHPw~~>
    >      >>
    >      >>
    >      >>
    >      >> _______________________________________________
    >      >> sfc mailing list
    >      >> [e-mail]
    >      >> https://url.serverdata.net/?a_R6iwBQImYWCr69g6-h0raXDRY2EORuQb3vcjuo_j
    >      >> Yzi8LHrrWr1VlAzSt23U6FhEXpHwQ1RPMguMZ7RGyHHPw~~
    >      >>
    >      
    >