Subject: Re: [Teas-ns-dt] [Teas] Transport slice negotiation

From: Eric Gray <[email-masked]>
Date: Fri, 15 May 2020 19:50:13 +0000

Hey, Igor.

First, a little context.  We are not just starting this work; we started this work last year.  And the intent in this work is to define relevant components, including an abstract northbound interface (NBI) - which is the way that a transport slice client requests a specific transport slice service over a minimally specified underlay network - and a framework for subsequent development (of models, for instance).

Our intent is not to redo (or replace) any specific work that has been completed, or is already in progress in the IETF, generally, and certainly not redo/replace work done in the TEAS WG specifically.

If you could be precise as to what work on "YANG TE Topology model" it is that you refer to, perhaps it would be possible to give an answer to the question as to why we did not (if indeed, we did not) start with that work.

If, for instance, you are referring to the L3SM - or L2SM - models, look at the text in the definitions draft (section 5.2 - "Transport Slice Controller Interfaces"), specifically where we talk about the transport slice controller (TSC) southbound interface (SBI) and list examples including these two cases.

We also have included ACTN and VPN+ in the framework draft.

If you feel we should add more examples from other TEAS work, to either or both drafts, please feel free to propose text - or at least work with members of the design team to construct text we can include.

Thanks, in advance,
--
Eric

_________________________________________________________________________
Igor Bryskin <[email-masked]> Fri, 15 May 2020 13:58 UTC wrote: 
 
Hi Joel,

Per your suggestion I am putting this discussion on the list. Thank you for your response.

Please, see a comment/suggestion in-line.

Regards,

Igor

On Thursday, May 14,2020, 9:50:19 AM EDT, Joel M. Halpern mailto:&lt;[email-masked]&gt; wrote: 

Thank you for the summary of the agreements below.  That helps 
significantly.  I am happy to provide my personal perspective on the 
questions you ask.  There is plenty of room for compromise.

On homogeneity, I tend to expect that things are non-uniform, and 
therefore the SLO specification needs to be able to be endpoint pair 
specific some of the time.  (I tend to like something along the lines of 
PNNI where on provides the base uniform value and then exceptions for 
specific better or worse cases.)

IB>> As you know, in TEAS WG we have developed YANG TE Topology model that allows to do exactly this. Specifically, it allows for a client for a give abstract TE node (and entire network or slice could be described as a single abstract TE node) to specify  a Connectivity Matrix (CM) of required Access Point to Access Point (AP-AP) connections/paths along with TE bounds on said paths, such as minimal available bandwidth, maximal permissible delay, required protection capabilities, etc. Additionally, the CM includes a container - Default Connectivity Matrix Entry - which is supposed to simplify a homogeneous connectivity configuration. Specifically, a TE bound configured within Default Connectivity Matrix Entry should apply to any valid AP-AP path,  as long as the path specific entry bound does not explicitly overwrites it.

Why don't we start with this? If we decide along the road that some AP-AP path specific parameters are missing (e.g. path availability metric), a simple augmentation would fill the gaps. What do you think?

Igor  

 --- [SNIP] ---

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 18 May 2020 18:54:05 +0000 (UTC)

Hi Eric,

I do respect the DT’s effort. I seethe discussion triggered by Joel as very important one and complimentary towhat DT is doing. In this discussion we are trying to agree on which things(aspects, group of parameters, etc.) need to be negotiated by the client andthe provider when the client requests the TS service. This is important fromthe NBI point of view, and it would be very helpful if at some point one of DT’sdocument provides a concise set of requirements to this end. 

So far, we have established thatthere is no need to negotiate (or even discuss) the level ofseparation/isolation of the requested TS from other TSs. There are certainthings that definitely need negotiation, such as identities of APs, parametersof access links, topology (at least, connectivity flexibility and limitations) interconnectingAPs across TS, TE bounds, such as maximal delay,minimal available bandwidth,required path/connection protection capabilities, etc.) expressed on per   AP to APlevel and per TS level (for requesting homogeneous connectivity and defaultconnectivity rules).

 We are still trying to figure outwhat needs to be negotiated in the control plane area (e.g. BGP capabilities),security/encryption, monitoring, complimentary network functions to be providedby the TS, etc.,

Regards,

Igor

On Friday, May 15,2020, 3:50:33 PM EDT, Eric Gray <eric.gray=[email-masked]>wrote: 

Hey, Igor.

First, a littlecontext.  We are not just starting this work; we started this work lastyear.  And the intent in this work is to define relevant components,including an abstract northbound interface (NBI) - which is the way that atransport slice client requests a specific transport slice service over aminimally specified underlay network - and a framework for subsequentdevelopment (of models, for instance).

Our intent is not toredo (or replace) any specific work that has been completed, or is already inprogress in the IETF, generally, and certainly not redo/replace work done inthe TEAS WG specifically.

If you could beprecise as to what work on "YANG TE Topology model" it is that yourefer to, perhaps it would be possible to give an answer to the question as towhy we did not (if indeed, we did not) start with that work.

If, for instance, youare referring to the L3SM - or L2SM - models, look at the text in thedefinitions draft (section 5.2 - "Transport Slice ControllerInterfaces"), specifically where we talk about the transport slicecontroller (TSC) southbound interface (SBI) and list examples including thesetwo cases.

We also have includedACTN and VPN+ in the framework draft.

If you feel we shouldadd more examples from other TEAS work, to either or both drafts, please feelfree to propose text - or at least work with members of the design team toconstruct text we can include.

Thanks, in advance,

--

Eric

Igor Bryskin <[email-masked]>Fri, 15 May 2020 13:58 UTC wrote: 

Hi Joel,

Per your suggestion Iam putting this discussion on the list. Thank you for your response.

Please, see acomment/suggestion in-line.

Regards,

Igor

On Thursday, May14,2020, 9:50:19 AM EDT, Joel M. Halpern mailto:&lt;[email-masked]&gt;wrote: 

 

Thank you for thesummary of the agreements below.  That helps 

significantly.  Iam happy to provide my personal perspective on the 

questions youask.  There is plenty of room for compromise.

On homogeneity, I tendto expect that things are non-uniform, and 

therefore the SLOspecification needs to be able to be endpoint pair 

specific some of thetime.  (I tend to like something along the lines of 

PNNI where on providesthe base uniform value and then exceptions for 

specific better orworse cases.)

IB>> As youknow, in TEAS WG we have developed YANG TE Topology model that allows to doexactly this. Specifically, it allows for a client for a give abstract TE node(and entire network or slice could be described as a single abstract TE node)to specify  a Connectivity Matrix (CM) of required Access Point to AccessPoint (AP-AP) connections/paths along with TE bounds on said paths, such asminimal available bandwidth, maximal permissible delay, required protectioncapabilities, etc. Additionally, the CM includes a container - DefaultConnectivity Matrix Entry - which is supposed to simplify a homogeneousconnectivity configuration. Specifically, a TE bound configured within DefaultConnectivity Matrix Entry should apply to any valid AP-AP path,  as longas the path specific entry bound does not explicitly overwrites it.

Why don't we startwith this? If we decide along the road that some AP-AP path specific parametersare missing (e.g. path availability metric), a simple augmentation would fillthe gaps. What do you think?

Igor  

--- [SNIP] ---

_______________________________________________

Teas mailing list

[email-masked]

Teas Info Page

| 
| 
|  | 
Teas Info Page

 |

 |

 |