Re: [Teas] TE SFCs discussion

[Daniele Ceccarelli <[e-mail]>]

Thanks for the explanation Pavan, I’m happy to hear that.

FWIW I believe that work proposed by Igor (and the rest of the team) is extremely valuable and I believe that from an architecture and modelling point of view it belongs to TEAS (with obvious coordination with the relevant other working groups and SDOs).

Cheers
Daniele

From: Vishnu Pavan Beeram [mailto:[e-mail]]
Sent: mercoledì 18 gennaio 2017 13:12
To: Daniele Ceccarelli <[e-mail]>
Cc: Scharf, Michael (Nokia - DE) <[e-mail]>; Igor Bryskin <[e-mail]>; Xufeng Liu <[e-mail]>; Vishnu Pavan Beeram <[e-mail]>; Oscar Gonzalez De Dios <[e-mail]>; Tarek Saad <[e-mail]>; Himanshu Shah <[e-mail]>; Lou Berger <[e-mail]>; BRUNGARD, DEBORAH A (ATTLABS) <[e-mail]>; Susan Hares <[e-mail]>; Zafar Ali (zali) <[e-mail]>; Khaddam, Mazen (CCI-Atlanta) <[e-mail]>; Tony Le <[e-mail]>; Belotti, Sergio (Nokia - IT) <[e-mail]>; Beller, Dieter (Nokia - DE) <[e-mail]>; Rajan Rao <[e-mail]>; Zhangxian (Xian) <[e-mail]>; [e-mail]; Anurag Sharma <[e-mail]>; Italo Busi <[e-mail]>; [e-mail]
Subject: Re: [Teas] TE SFCs discussion

Daniele, Hi!
The authors of the TE Topology model believe that there isn't anything else to be add to the model itself (no open items/issues). There is some work that needs to be done with respect to the "supporting text" in the draft -- the authors intend to spruce up that portion of the draft in the coming weeks and then request last call. In the meantime, it would be useful for folks in the WG to review the current version of the model and reach out to the authors if they want any specific modeling construct to be added/deleted/modified.
The discussion in last week's call that Igor is talking about was focused on applications/work-items that can be built on top of the existing IETF topology models (via augments). It is safe to assume that these work-items (if/when they take off) will start as separate individual drafts in appropriate WGs (and will have nothing to do with the current WG adopted TE Topology draft).
Regards,
-Pavan (as a co-author of the TE Topology model).

On Wed, Jan 18, 2017 at 4:31 AM, Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>> wrote:
HI Igor, all,

While I think this is a very interesting (and challenging) topic I’d strongly suggest to address it in a separate draft. We definitely need to progress the TE Topology work.

Cheer
Daniele

From: Teas [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: mercoledì 18 gennaio 2017 10:08
To: Igor Bryskin <[e-mail]<mailto:[e-mail]>>; Xufeng Liu <[e-mail]<mailto:[e-mail]>>; Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>>; Oscar Gonzalez De Dios <[e-mail]<mailto:[e-mail]>>; Tarek Saad <[e-mail]<mailto:[e-mail]>>; Himanshu Shah <[e-mail]<mailto:[e-mail]>>; Lou Berger <[e-mail]<mailto:[e-mail]>>; BRUNGARD, DEBORAH A (ATTLABS) <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; Zafar Ali (zali) <[e-mail]<mailto:[e-mail]>>; Khaddam, Mazen (CCI-Atlanta) <[e-mail]<mailto:[e-mail]>>; Tony Le <[e-mail]<mailto:[e-mail]>>; Belotti, Sergio (Nokia - IT) <[e-mail]<mailto:[e-mail]>>; Beller, Dieter (Nokia - DE) <[e-mail]<mailto:[e-mail]>>; Rajan Rao <[e-mail]<mailto:[e-mail]>>; Zhangxian (Xian) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Belotti, Sergio (Nokia - IT) <[e-mail]<mailto:[e-mail]>>; Anurag Sharma <[e-mail]<mailto:[e-mail]>>; Italo Busi <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Teas] TE SFCs discussion

I assume this augmentation would be in a new I-D?

The list below covers aspects that may not be applicable to the generic use of the YANG TE models in optical, OTN, and MPLS/IP transport networks.

For what it is worth, the “NF/SF memory/CPU requirements (for VNFs)” is by far not a complete description of what describes the requirements of a VNF in reality. For instance, another very basic VNF parameter could be “disk”. But for VNFs with high-IO (“firewall”, “NAT”, DPI”) there may be further relevant parameters, e.g., for CPU and NUMA pinning. Those attributes typically cannot be abstracted easily. For a more comprehensive list of what attributes may be required, I suggest to have a look a.g. at OpenStack. ETSI NFV has formal descriptions of these attributes.

Michael


From: Teas [mailto:[e-mail]] On Behalf Of Igor Bryskin
Sent: Tuesday, January 17, 2017 10:03 PM
To: Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; Belotti, Sergio (Nokia - IT); Beller, Dieter (Nokia - DE); Rajan Rao; Zhangxian (Xian); [e-mail]<mailto:[e-mail]>; Belotti, Sergio (Nokia - IT); Anurag Sharma; Italo Busi
Cc: [e-mail]<mailto:[e-mail]>
Subject: [Teas] TE SFCs discussion

Hi guys,

In case we want to further discuss the evolution and future directions of the YANG TE modeling work, below is a quick write-up of what we touched at the previous meeting.

I suggested starting working on what I call Network Function Aware TE Topology model, which is intended to be an augmentation of the basic TE topology model. In a nutshell the new model will do the following:


1)      Formally define/describe a NF/SF as a potential participant of a Service Function Chain (SFC). Said definition will include the following attributes:

-          NF/SF identity (e.g. firewall, NAT, DPI, etc.);

-          NF/SF instance (e.g. configuration profile ID);

-          NF/SF virtual/real flag;

-          NF/SF uni-/bi-directional flag;

-          NF/SF throughput, delay and other general metrics;

-          NF/SF memory/CPU requirements (for VNFs);

-          NF/SF provider preference of use;

-          etc.



2)      Introduce an NF/SF as a topological element. Specifically, a given NF/SF will be hosted by a TE node. Said TE node could be physical (e.g. router, switch, server, workstation) or abstract (e.g. Data Center, network domain). From the model perspective said TE node will have a list of all (possibly large number) NFs/SFs it hosts (just like it has a list of its TTPs in the basic TE topology model). The model will introduce for TE node an additional attribute - NF Connectivity Matrix (NFCM). The basic variant of this attribute (NFBCM) will describe whether and how NFs  hosted by the TE node could be chained together (to produce intra-node SFCs) and/or to the node’s TTPs (to be chained over TE tunnels terminated by the TTPs with NFs/SFs hosted by other topology TE nodes, i.e. to produce inter-node SFCs). The detailed variant of the NFCM (NFDCM) will also describe at what costs (e.g. in terms of delay) a given NF could be connected inside the hosting TE node to another NF or TTP hosted by the same TE node. This is in perfect similarity with Basic/Detailed Link Connectivity Matrix attribute describing in the basic TE topology model the TE node’s switching capabilities/limitations.
The ultimate goal of the model is to describe a provider’s data-store that would make possible for a client to:

a)       identify/discover NFs/SFs on a network topology

b)      Build dynamic TE SFCs and compute TE paths connecting adjacent NFs/SFs in the SFCs;

c)       Duel-optimize TE SFCs based on optimal location of NFs/SFs and optimal TE paths interconnecting them;

d)      Constrain TE SFCs both end-to-end (e.g. bandwidth, e2e delay/jitter) and on every leg (e.g. delay/jitter synchronization of a pair of NFs/SFs adjacent in the SFC);

e)      Abstract and scale TE SFCs as we do today with TE nodes, links and tunnels
The companion - TE SFC model (an augmentation of the basic TE tunnel model) -  will allow for the client to set up and manipulate  TE SFCs in the same manner as the basic TE tunnel model allows to do so for TE tunnels. In particular it will be possible:

a)       to set up and manipulate TE SFCs in a regular and compute-only mode;

b)      to protect/recover TE SFCs from network failures
Both models will inherently allow for streaming of telemetry information on per TE SFC basis and scheduling of one-time and/or periodic TE SFC provisioning/reconfiguration in time.

As Pavan and Tarek pointed out, If proves useful, we can further generalize the NF Aware TE Topology model to allow for the client to use either TE or L3 topology information when selecting dynamic SFC paths (for example, to use so selected paths in the context of Segment Routing)

TE SFCs could be used as overlays to carry actual SFPs taking care of SFC control plane payload manipulation, such as handling of SFC metadata and NSH encapsulation.
TE SFSs fit comfortably into the Hierarchical SFCs work of the IETF SFC WG.

I believe that TE SFC models will better address the requirements of applications, such as network (5g style) slicing, compared to Basic TE topology/tunnel models. I also believe that architectures like ACTN will greatly benefit from TE SFC models (e.g. in decoupling NFs/SFs from network locations and to address the function mobility challenges).

Feel free to ask any questions and provide your feedback.

Cheers,
Igor




From: Xufeng Liu [mailto:[e-mail]]
Sent: Tuesday, January 10, 2017 5:08 PM
To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); [e-mail]<mailto:[e-mail]>; Belotti, Sergio (Nokia - IT); Anurag Sharma; Italo Busi
Cc: [e-mail]<mailto:[e-mail]>
Subject: IETF TE Topology YANG Model Design Meeting Notes - 2017-01-04

Attendees:
Igor, Xufeng, Pavan

- Continued discussion on supporting-tunnel-ttp on a tunnel-ttp

  > The proposed model change is:
         +--rw supporting-tunnel-termination-point* [node-ref tunnel-tp-ref]
            +--rw node-ref         leafref
            +--rw tunnel-tp-ref    leafref

  > Will add restriction to limit the number of supporting nodes/links for
   each TE node/link to be at most 1.
    The base I2RS network topology model allows more than 1 supporting
    node for each node, and more than 1 supporting link for each link.
    For a TE topology, when multiple nodes/links are abstracted, we
    use underlay, so there is no more than one supporting node/link.

- Reviewed the section of local link connectivity list on a tunnel termination point.
  > We will make LLCL the same as connectivity-matrix, by adding any missing attributes.

Thanks,
- Xufeng

Note: Please drop me an email if you need an invite for joining the weekly call.

_______________________________________________
Teas mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas