Re: [Teas] TE SFCs discussion

[Igor Bryskin <[e-mail]>]

Hi guys

Last Friday I had a very interesting and useful discussion with Joel Halpern and Daniele,
.
First, Joel did recognize the importance and usefulness of SF-aware topology information. A few important uses cases came up during the discussion that I personally have never thought of.


Second, Joel expressed a preference for a controller to be able to collect data from multiple sources in accordance with separate simple narrowly focused models and assemble/relate the data in a local DB, rather than collecting data from a single data store governed by a single complex model. There are several reasons to that:



1)  the latter is not hopeless, but the former would require much narrower acceptance and lesser buy in from the industry for each of the involved model to succeed. Folks that only care about NSH may not want to deal with TE complexities (which in their minds may be somebody else's problem);

2)  IETF does not have expertise to cover all areas. For example, IETF does not have the expertise to formally describe NFs, their instances and components. It would be prudent to make use of the definitions developed by ETSI cloud applications folks, and would be wasteful to start doing this in IETF from scratch. I think Michael was saying the same thing. I also believe we have similar problems with policies: IETF does not have an expertise in defining declarative languages, for example, and that's why the policy models/interfaces work seems to be moving nowhere.

3)  Not everything has to be written in YANG. For example, ETSI NF definitions are written in TOSCA



My interpretation/takeout from this discussion is that SF-aware topology model does not have to be an augmentation/mount of TE or L3/L2 topology models. Instead it could be independent and have a single (top level) list, with the list elements containing:



·        [topology ID, node ID] pair (this would allow for an interested client to look up the node's topological attributes (as well as other TE, L3 or L2 topology information associated with the topology in question) independently using data collected via TE, L3, L2, etc. model based interface);



·        list of SF IDs associated with the node (again, the client would be able to look up SFs in the data structure containing SF descriptions defined, for example, by ETSI cloud folks in the form of TOSCA models);



·        list of SFF IDs associated with the node ( SFF descriptions could be looked up in the data structure defined by SFC WG YANG models);



·        SF connectivity matrix describing whether, how and at what costs the hosted by the node SFs could be locally chained and connected to the node's SFFs;



·        SFF connectivity matrix describing whether, how and at what costs the node's SFFs could be connected to the node's LTPs (link termination points) and TTPs (tunnel termination points) to create/manipulate SFCs over the network topology (i.e. spanning multiple nodes).





This IMHO would keep the model simple, focused, applicable to either or both TE or/and reachability (L3, L2)  network topology.



Would this make a better sense to you?



Cheers,

Igor


From: Vishnu Pavan Beeram [mailto:[e-mail]]
Sent: Wednesday, January 18, 2017 7:12 AM
To: Daniele Ceccarelli
Cc: Scharf, Michael (Nokia - DE); Igor Bryskin; 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]; Anurag Sharma; Italo Busi; [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