Re: [Teas] Transport slice negotiation

[Igor Bryskin <[e-mail]>]

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=[e-mail]>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 <[e-mail]>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;[e-mail]&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

[e-mail]

Teas Info Page


| 
| 
|  | 
Teas Info Page


 |

 |

 |