Re: [Teas] Transport slice negotiation

[Igor Bryskin <[e-mail]>]

 
Hi Joel,

 

Per your suggestion I am puttingthis 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 <[e-mail]> wrote: 

 

 

Thank you for thesummary 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 excaptions for 
specific better or worse cases.)

 

IB>> As you know,in TEAS WG we have developed YANG TE Topology model that allows to do exactlythis. Specifically, it allows for a client for a give abstract TE node (andentire network or slice could be described as a single abstract TE node) tospecify  a Connectivity Matrix (CM) of requiredAccess Point to Access Point (AP-AP) connections/paths along with TE bounds onsaid paths, such as minimal available bandwidth, maximal permissible delay, requiredprotection capabilities, 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 long as the path specific entry bound doesnot 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  

On routing protocols, there are two aspects.  One is if the customer 
needs to conduct routing exchanges with the operator (which is common). 
Clearly, the protocol to be used has to be specified.  If the custoemr 
tries to use OSPF, and the oeprator expects IS-IS, things will not work 
well.
The second aspect is if there is a requirement for some specific 
information to be advertised into the global Internet.  If the Slice 
includes Internet connectivity, and if the customer wants prefixes or 
communities advertised, that probably needs to be negotiated.

Yours,
Joel

PS: This probably should be copied to the DT list, as we all need to be 
careful about private conversations.  Can you please copy it there?


On 5/14/2020 9:38 AM, Igor Bryskin wrote:
> Hi Joel,
> 
> I hope you are doing well and staying safe.
> 
> Thanks for the interesting discussion that you triggered WRT and in the 
> context of Transport Slice (TS),
> 
> I think we have established one thing that should not be negotiated 
> between TS client and server, which is the level of TS 
> solation/separation from other slices. But I’d like to know your opinion 
> which things must be negotiated. Obviously, the client must specify the 
> IDs of Access Points (APs) it wants to interconnect via/across the TS, 
> as well as the required connectivity (both flexibility and limitations) 
> along with verifiable SLOs , such as maximal delay (incidentally, do you 
> see such SLOs will be always homogenous for any AP-to-AP pair, or some 
> such pairs nay stipulate exceptional (more stringent) SLOs?)
> 
> What else it is to TS slice requirement? What about Control Plane 
> requirements? For example, should the client be able to request BGP 
> support from the TS? How about the security, for example, should the 
> client be able to request its traffic to be encrypted by TS? Can the 
> client request certain network functions, such as firewalls, to be 
> provided by the TS? Could be any requirements WRT the data [plane 
> capabilities?
> 
> AS always, you insight is much appreciated.
> 
> Regards,
> 
> Igor
> 
>