Re: [Teas] Transport slice negotiation

["Joel M. Halpern" <[e-mail]>]

Conceptually, including a structure along those lines in the abstracted 
model that seems to be appropriate for the network slicing work makes sense.

Yours,
Joel

On 5/15/2020 9:58 AM, Igor Bryskin 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 
> <[e-mail]> 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 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 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
> 
> 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
>> 
>> 
> 
>