Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2017-01-04

From: Xufeng Liu <[email-masked]>
Date: Tue, 10 Jan 2017 22:08:18 +0000

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.

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 17 Jan 2017 21:03:19 +0000

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:[email-masked]]
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); [email-masked]; Belotti, Sergio (Nokia - IT); Anurag Sharma; Italo Busi
Cc: [email-masked]
Subject: IETF TE Topology YANG Model Design Meeting Notes - 2017-01-04

Attendees:
Igor, Xufeng, Pavan

Thanks,
- Xufeng

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Wed, 18 Jan 2017 09:08:15 +0000

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:[email-masked]] 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); [email-masked]; Belotti, Sergio (Nokia - IT); Anurag Sharma; Italo Busi
Cc: [email-masked]
Subject: [Teas] TE SFCs discussion

Hi guys,

-          etc.

Cheers,
Igor

From: Xufeng Liu [mailto:[email-masked]]
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); [email-masked]<mailto:[email-masked]>; Belotti, Sergio (Nokia - IT); Anurag Sharma; Italo Busi
Cc: [email-masked]<mailto:[email-masked]>
Subject: IETF TE Topology YANG Model Design Meeting Notes - 2017-01-04

Attendees:
Igor, Xufeng, Pavan

Thanks,
- Xufeng

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 18 Jan 2017 09:31:06 +0000

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

Michael

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); [email-masked]<mailto:[email-masked]>; Belotti, Sergio (Nokia - IT); Anurag Sharma; Italo Busi

Hi guys,

-          etc.

Cheers,
Igor

Attendees:
Igor, Xufeng, Pavan

Thanks,
- Xufeng

---

From: "Belotti, Sergio (Nokia - IT)" <[email-masked]>
Date: Wed, 18 Jan 2017 10:31:25 +0000

Hi Daniele,
That was my understanding last time during the te-topology weekly call.
I think Igor can confirm too.

Thanks
sergio

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

HI Igor, all,

Cheer
Daniele

To: Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Xufeng Liu <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>; Oscar Gonzalez De Dios <[email-masked]<mailto:[email-masked]>>; Tarek Saad <[email-masked]<mailto:[email-masked]>>; Himanshu Shah <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>; BRUNGARD, DEBORAH A (ATTLABS) <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>; Khaddam, Mazen (CCI-Atlanta) <[email-masked]<mailto:[email-masked]>>; Tony Le <[email-masked]<mailto:[email-masked]>>; Belotti, Sergio (Nokia - IT) <[email-masked]<mailto:[email-masked]>>; Beller, Dieter (Nokia - DE) <[email-masked]<mailto:[email-masked]>>; Rajan Rao <[email-masked]<mailto:[email-masked]>>; Zhangxian (Xian) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Belotti, Sergio (Nokia - IT) <[email-masked]<mailto:[email-masked]>>; Anurag Sharma <[email-masked]<mailto:[email-masked]>>; Italo Busi <[email-masked]<mailto:[email-masked]>>

Michael

Hi guys,

-          etc.

Cheers,
Igor

Attendees:
Igor, Xufeng, Pavan

Thanks,
- Xufeng

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 18 Jan 2017 19:54:06 +0800

+1

Regards,
Jeff

> On Jan 18, 2017, at 17:31, Daniele Ceccarelli <[email-masked]> 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 
>  
> 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
>  
>  
> 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:
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Wed, 18 Jan 2017 07:12:14 -0500

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 <
[email-masked]> 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:[email-masked]] *On Behalf Of *Scharf,
> Michael (Nokia - DE)
> *Sent:* mercoledì 18 gennaio 2017 10:08
> *To:* Igor Bryskin <[email-masked]>; Xufeng Liu <
> [email-masked]>; Vishnu Pavan Beeram <[email-masked]>; Oscar
> Gonzalez De Dios <[email-masked]>; Tarek Saad <
> [email-masked]>; Himanshu Shah <[email-masked]>; Lou Berger <
> [email-masked]>; BRUNGARD, DEBORAH A (ATTLABS) <[email-masked]>; Susan
> Hares <[email-masked]>; Zafar Ali (zali) <[email-masked]>; Khaddam,
> Mazen (CCI-Atlanta) <[email-masked]>; Tony Le <[email-masked]>;
> Belotti, Sergio (Nokia - IT) <[email-masked]>; Beller, Dieter
> (Nokia - DE) <[email-masked]>; Rajan Rao <[email-masked]>;
> Zhangxian (Xian) <[email-masked]>; [email-masked];
> Belotti, Sergio (Nokia - IT) <[email-masked]>; Anurag Sharma <
> [email-masked]>; Italo Busi <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Teas] TE SFCs discussion
>
>
>
> 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:[email-masked] <[email-masked]>] *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); [email-masked]; Belotti, Sergio (Nokia - IT); Anurag
> Sharma; Italo Busi
> *Cc:* [email-masked]
> *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:
>
> 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.
>
> 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);
>
> 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:
>
> 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.
>
> 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).
>
>
>
> *From:* Xufeng Liu [mailto:[email-masked] <[email-masked]>]
> *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);
> [email-masked]; Belotti, Sergio (Nokia - IT); Anurag Sharma;
> Italo Busi
> *Cc:* [email-masked]
> *Subject:* IETF TE Topology YANG Model Design Meeting Notes - 2017-01-04
>
>
>
> Attendees:
>
> Igor, Xufeng, Pavan
>
>
>

---

From: Dieter Beller <[email-masked]>
Date: Wed, 18 Jan 2017 13:14:01 +0100

All,

+1

Let's progress and finalize the TE topology work first before
jumping on other fancy stuff that should indeed go into a separate
draft!

Thanks,

Dieter

On 18.01.2017 12:54, Jeff Tantsura
wrote:

+1

Regards,

Jeff

On Jan 18, 2017, at 17:31, Daniele Ceccarelli <[email-masked]>
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:[email-masked]]
On Behalf Of Scharf, Michael (Nokia - DE)

To: Igor Bryskin <[email-masked]>;
Xufeng Liu <[email-masked]>;
Vishnu Pavan Beeram <[email-masked]>;
Oscar Gonzalez De Dios <[email-masked]>;
Tarek Saad <[email-masked]>;
Himanshu Shah <[email-masked]>;
Lou Berger <[email-masked]>;
BRUNGARD, DEBORAH A (ATTLABS) <[email-masked]>;
Susan Hares <[email-masked]>;
Zafar Ali (zali) <[email-masked]>;
Khaddam, Mazen (CCI-Atlanta) <[email-masked]>;
Tony Le <[email-masked]>;
Belotti, Sergio (Nokia - IT) <[email-masked]>;
Beller, Dieter (Nokia - DE) <[email-masked]>;
Rajan Rao <[email-masked]>;
Zhangxian (Xian) <[email-masked]>;
[email-masked];
Belotti, Sergio (Nokia - IT) <[email-masked]>;
Anurag Sharma <[email-masked]>;
Italo Busi <[email-masked]>

Cc: [email-masked]

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:[email-masked]]
On Behalf Of Igor Bryskin

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); [email-masked]; Belotti, Sergio (Nokia - IT); Anurag
Sharma; Italo Busi

Cc: [email-masked]

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

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); [email-masked]; Belotti, Sergio (Nokia - IT);
Anurag Sharma; Italo Busi

Cc: [email-masked]

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

> 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

[email-masked]

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 18 Jan 2017 13:38:11 +0000

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:[email-masked]]
Sent: mercoledì 18 gennaio 2017 13:12
To: Daniele Ceccarelli <[email-masked]>
Cc: Scharf, Michael (Nokia - DE) <[email-masked]>; Igor Bryskin <[email-masked]>; Xufeng Liu <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; Oscar Gonzalez De Dios <[email-masked]>; Tarek Saad <[email-masked]>; Himanshu Shah <[email-masked]>; Lou Berger <[email-masked]>; BRUNGARD, DEBORAH A (ATTLABS) <[email-masked]>; Susan Hares <[email-masked]>; Zafar Ali (zali) <[email-masked]>; Khaddam, Mazen (CCI-Atlanta) <[email-masked]>; Tony Le <[email-masked]>; Belotti, Sergio (Nokia - IT) <[email-masked]>; Beller, Dieter (Nokia - DE) <[email-masked]>; Rajan Rao <[email-masked]>; Zhangxian (Xian) <[email-masked]>; [email-masked]; Anurag Sharma <[email-masked]>; Italo Busi <[email-masked]>; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
HI Igor, all,

Cheer
Daniele

From: Teas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Scharf, Michael (Nokia - DE)

Michael

Hi guys,

-          etc.

Cheers,
Igor

Attendees:
Igor, Xufeng, Pavan

Thanks,
- Xufeng

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

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 18 Jan 2017 14:27:48 +0000

Hi guys,

Thanks for so many comments! I am very pleased to see so much interest.

First, it was never our intention to put TE SFC semantics into current TE topology & tunnel models. This would be certainly separate augmentations (and separate IDs).

Second, TE SFCs are not SFCs per-se, rather, traffic engineered overlays to carry SFPs inside. A good analogy would be L3VPNs and TE tunnels supporting them. One can view VRFs supporting a given L3VPN as NFs connected via BGP LSPs (SFPs) that are carried within TE tunnels, which are traffic engineered overlays, connecting PEs hosting said VRFs, so that certain purely TE objectives (e.g. delay constraints) could be met. The idea is to generalize this concept: arbitrary NFs could be chained in arbitrary multi-leg SFCs with their SFPs carried inside chains of TE tunnels (rather than individual independent TE tunnels) that are constrained and optimized both individually and chain e2e.

Third, to answer Michael’s comments. Yes, it is a difficult challenge to formally describe NFs on the network. What we have in mind is to come up as much as possible with a common set of attributes describing an NF. We are also thinking of group-specific augmentations describing certain groups of NFs (not unlike we describe TE links that belong to different network layers). The goal is to allow for the client to dynamically identify NFs on the network that could be chained in desired SFCs. We really need help with this, and if you, Michael, or anyone else can help with the definitions, it would be really valuable.

Cheers,
Igor

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Wednesday, January 18, 2017 8:38 AM
To: Vishnu Pavan Beeram
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); [email-masked]; Anurag Sharma; Italo Busi; [email-masked]
Subject: RE: [Teas] TE SFCs discussion

Cheers
Daniele

Daniele, Hi!

Cheer
Daniele

Michael

Hi guys,

-          etc.

Cheers,
Igor

Attendees:
Igor, Xufeng, Pavan

Thanks,
- Xufeng

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Wed, 18 Jan 2017 20:44:26 +0000

My priority is that the existing TE models are finalized.

Standardization activities for common sets of attributes for network functions already exist, e.g., in ETSI and OASIS. It is not clear to me whether standardization of non-networking attributes (i.e., non-TE attributes) would be in the “comfort zone” of TEAS, of the routing area, or of even the IETF as a whole. For what it is worth, I also have some trouble with understanding the analogy between configuration of a VRF and the network function specification such as CPU core/NUMA pinning, Intel DPDK configuration, etc. which are pretty typical examples for NF requirements. To me, these look like two quite disjoint technical topics.

Michael

From: Igor Bryskin [mailto:[email-masked]]
Sent: Wednesday, January 18, 2017 3:28 PM
To: Daniele Ceccarelli; Vishnu Pavan Beeram
Cc: Scharf, Michael (Nokia - DE); 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); [email-masked]; Anurag Sharma; Italo Busi; [email-masked]
Subject: RE: [Teas] TE SFCs discussion

Hi guys,

Cheers,
Igor

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Wednesday, January 18, 2017 8:38 AM
To: Vishnu Pavan Beeram
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); [email-masked]<mailto:[email-masked]>; Anurag Sharma; Italo Busi; [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas] TE SFCs discussion

Cheers
Daniele

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

Daniele, Hi!

Cheer
Daniele

Michael

Hi guys,

-          etc.

Cheers,
Igor

Attendees:
Igor, Xufeng, Pavan

Thanks,
- Xufeng

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 23 Jan 2017 19:02:55 +0000

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:[email-masked]]
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); [email-masked]; Anurag Sharma; Italo Busi; [email-masked]
Subject: Re: [Teas] TE SFCs discussion

Daniele, Hi!

Cheer
Daniele

Michael

Hi guys,

-          etc.

Cheers,
Igor

Attendees:
Igor, Xufeng, Pavan

Thanks,
- Xufeng