Subject: Re: [sfc] #16 (control-plane): RSP-related Considerations (L. Dunbar/A. Malis)

From: <[email-masked]>
Date: Wed, 18 Nov 2015 08:38:53 +0000

Dear WG,

Unless I'm mistaken, We didn't receive any feedback about this discussion point. 

IMO, RSP-related considerations are worth to be discussed in the core text. 

Cheers,
Med

> -----Message d'origine-----
> De : sfc issue tracker [mailto:[email-masked]]
> Envoyé : vendredi 18 septembre 2015 08:08
> À : [email-masked]; BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]
> Objet : [sfc] #16 (control-plane): RSP-related Considerations (L.
> Dunbar/A. Malis)
> 
> #16: RSP-related Considerations (L.  Dunbar/A.  Malis)
> 
>  Discuss what to do with this appendix.
> 
>  ==
>  Appendix A.  RSP-related Considerations
> 
>     NOTE: This section records some contributions proposed by L.  Dunbar
>     and A.  Malis, but have not been discussed yet among authors.
> 
>  A.1.  Encoding the Exact SFF-SF-sequence in Data Packets
> 
>     Encoding the exact RSP in every packet has the benefit and the issues
>     associated with source routing.  This approach may not be optimal
>     when the SFP doesn't change very frequently, as in minutes or hours.
> 
>     There are contexts that it might not be feasible for the head end
>     Classifier to be notified of the changes of SFF-sequence or SFF-SF-
>     Sequence for a given SFP because of the time taken for the
>     notification and the limited capability of the Classifier nodes.
> 
>  A.2.  Fully Controlled SFF-SF-Sequence for a SFP
> 
>     This section describes the information that can be exchanged over C2
>     interface (Section 3.3.2) when the SFC Control Element explicitly
>     passes the steering policies to all SFFs for the SFF-SF-Sequence of a
>     given SFC.  In this model, each SFF doesn't need to signal other SFFs
>     for the SFP.
> 
>     Suppose the SFC ID for this SFP is "yellow", an example of policy to
>     "sff-a" is depicted in Figure 2 (for illustration proposes)
> 
>                Matching                     |       Action
>     ----------------------------------------+-------------------------
>     SFC ID = "yellow" & ingress = sffx-port | next-hop: "sf2" & VID
>     SFC ID = "yellow" & ingress = sf2-port  | next-hop: "sf3" & VID
>     SFC ID = "yellow" & ingress = sf3-port  | next-hop: sff-b
> 
>          Figure 2: Example of Traffic Steering Policy to a SFF node
> 
>     The SFF nodes may not be directly adjacent to each other.  They can
>     be interconnected by tunnels, such as GRE, VxLAN, etc.  SFs are
>     attached to a SFF node or SFC Proxy node via Ethernet link or other
>     link types.  Therefore, the steering policies to a SFF node for
>     service function chain depends on if the packet comes from previous
>     SFF or comes from a specific SF, i.e., the SFC Forwarding Policy
>     Table entries have to be ingress port specific.  There are multiple
>     different steering policies for one flow within one SFF and each set
>     of steering policies is specific for an ingress port.
> 
>     The semantics of traffic steering rules can be "Match" and "Action",
>     similar to the "route" described in [I-D.ietf-i2rs-rib-info-model].
>     The "match" and "action" for distinct ports can be different.  The
>     matching criteria for SFF can be more sophisticated.  For example,
>     the matching criteria could be any fields in the data packets:
> 
>     o  Ingress port
>     o  Destination MAC address
>     o  Source MAC address
>     o  VLAN_id,
>     o  Destination IP address
>     o  Source IP address
>     o  Source port number
>     o  Destination port number
>     o  DSCP
>     o  Packet size, etc., or any combination thereof.
> 
>     A SFF node may not support some of the matching criteria listed
>     above.  It is important that SFC control plane can retrieve the
>     supported matching criteria by SFF nodes.  The "Actions" for traffic
>     steering could be to steer traffic to the attached service function
>     or SF instantiations via a specific port.
> 
>     The "Actions" to SFC Proxy may include a method to map the SFC
>     Identifier carried in the packet header to a locally significant link
>     identifier, e.g., VLAN-ID, and a method to construct and encapsulate
>     the SFC header back to the packets when they come back from the
>     attached SFs.
> 
>     This approach does not require using an end-to-end signaling protocol
>     among Classier nodes and SFF nodes.  However, there may be problems
>     encountered if SFF nodes are not updated in the proper order or not
>     at the same time.  For example, if the SFF "A" and SFF "C" get flow
>     steering policies at slightly different times, some packets might not
>     be directed to some service functions on a chain.
>  ==========
> 
> --
> -------------------------------------+------------------------------------
> -
>  Reporter:                           |      Owner:  draft-ietf-sfc-
> control-
>   [email-masked]       |  [email-masked]
>      Type:  defect                   |     Status:  new
>  Priority:  major                    |  Milestone:
> Component:  control-plane            |    Version:
>  Severity:  -                        |   Keywords:
> -------------------------------------+------------------------------------
> -
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/sfc/trac/ticket/16>
> sfc <http://tools.ietf.org/sfc/>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 18 Nov 2015 09:34:21 -0500

I’m perhaps biased :-), but I agree with Med.

Cheers,
Andy

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Wed, 18 Nov 2015 18:11:49 +0000

Also agree. Walter

Von: sfc [mailto:[email-masked]] Im Auftrag von Andrew G. Malis
Gesendet: Mittwoch, 18. November 2015 15:34
An: BOUCADAIR Mohamed IMT/OLN
Cc: [email-masked]; sfc issue tracker; [email-masked]; Linda Dunbar ([email-masked])
Betreff: Re: [sfc] #16 (control-plane): RSP-related Considerations (L. Dunbar/A. Malis)

Cheers,
Andy

On Wed, Nov 18, 2015 at 3:38 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Dear WG,

Cheers,
Med

> De : sfc issue tracker [mailto:[email-masked]<mailto:[email-masked]>]
> À : [email-masked]<mailto:[email-masked]>; BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]<mailto:[email-masked]>
>   [email-masked]<mailto:[email-masked]>       |  [email-masked]<mailto:[email-masked]>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 18 Nov 2015 20:20:16 +0000

I agree with Med too.

Cheers,
Linda

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Wednesday, November 18, 2015 8:34 AM
To: BOUCADAIR Mohamed IMT/OLN
Cc: sfc issue tracker; [email-masked]; Linda Dunbar; [email-masked]
Subject: Re: [sfc] #16 (control-plane): RSP-related Considerations (L. Dunbar/A. Malis)

Cheers,
Andy

Cheers,
Med

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 18 Nov 2015 23:58:34 +0000

My suggestions are inserted below:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 18, 2015 2:39 AM
To: sfc issue tracker; [email-masked]; Linda Dunbar; Andrew G. Malis ([email-masked])
Cc: [email-masked]
Subject: RE: [sfc] #16 (control-plane): RSP-related Considerations (L. Dunbar/A. Malis)

Dear WG,

Cheers,
Med

> De : sfc issue tracker [mailto:[email-masked]] Envoyé : 
> vendredi 18 septembre 2015 08:08 À : 
> [email-masked]; BOUCADAIR Mohamed IMT/OLN 
> Cc : [email-masked] Objet : [sfc] #16 (control-plane): RSP-related 
> Considerations (L.
> Dunbar/A. Malis)
> 

[Linda] I think this section should be added to Section 4, with title changed to "Encoding the exact SFF-SF sequence in NSH" 

>     "sff-a" is depicted in Figure 2 (for illustration proposes)
[Linda] This section should be added to Section 4 as well. 

Thanks, Linda 
> --
> -------------------------------------+--------------------------------
> -------------------------------------+----
> -
> -------------------------------------+--------------------------------
> -------------------------------------+----
> -
>

---

From: "sfc issue tracker" <[email-masked]>
Date: Wed, 25 Nov 2015 10:26:40 -0000

Comment (by [email-masked]):

 These two sections are moved to the core text in -01. These two sections
 appear in -01 as: 4.10.4 and 4.10.5.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-sfc-
  [email-masked]       |  [email-masked]
     Type:  defect                   |      Status:  new
 Priority:  major                    |   Milestone:
Component:  control-plane            |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/sfc/trac/ticket/16#comment:1>
sfc <http://tools.ietf.org/sfc/>