Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model

["Aijun Wang" <[e-mail]>]

Hi, all:

 

The reason that we consider to design the L3SM in modular manner is that we should consider its relationship with the device model as early as possible:

1. Can we make use of the Yang Model that defined in other WGs as modules?

2. Or can we leave some spaces for future module definition?

3. The service model should be abstracted in a higher level and  hide the detail technology information into the modules at best. Is this the right way to define the service module from top to down?

4. If there is no more modules for us to refer now,  can we group the related stanza into different modules and make it as the base of the modular prototype?

 

 

Aijun Wang

 

China Telecom Corporation Limited Beijing Research Institute 

Intelligent Network Product Line

 

From: L3sm [mailto:[e-mail]] On Behalf Of Rob Shakir
Sent: Wednesday, July 22, 2015 9:09 PM
To: 'Kireeti Kompella'; [e-mail]; Benoit Claise; [e-mail]
Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model

 

Folks,

 

+1 to Kireeti’s point that modularisation/mash-ups are the best way forward - we have common network designs for how e.g., an L3 edge interface works, which should not be duplicated between services. Indeed, where they are - this creates inefficiencies - such as having to change code and tooling surrounding multiple service models just to change one parameter of an interface (supporting an IP MTU of $current_value+1).

 

However, I can see the point that is being made by Adrian/Benoit. I might observe that this is a balance between standardisation (setting in RFC-stone), and building efficient ‘blocks’ of an overall architecture that are usable.

 

To me, I’m more interested in the latter, than the former. So - can we take an approach that says that we create an L3VPN service model - and stamp it as some final version (figuring out whether we can actually get to this step is interesting in and of itself) but not necessarily get out our chisels and start carving [0]? Subsequently, common elements can be pulled apart into modules that achieve the most efficient architecture.

 

The balance we have here is one that I think the IESG needs to approach - how do we both iterate on models (that are of course software), and get to things that can be considered ‘standards’ despite the fact that they may be refactored in the future.

 

Cheers,

r.

 

[0]: This might be done by, rather than not publishing, determining that the model’s status is really experimental, as we *know* as a WG that modularity would be very useful, if not essential, to have.

 

On 22 July 2015 at 13:53:04, Benoit Claise ([e-mail]) wrote:

Dear all,

+1 to Adrian's message.

My ocean-boiling concern has always been: in order to do the perfect job 
of modularity/grouping/augmentation, we should investigate all existing 
and potential future services. And the L2VPN are technology specific, so 
it's start to be difficult.

This is the reason why the charter is so strict and only focuses on L3VPN.

Obviously, we should follow Adrian's advice: "But some early, 
precautionary modularisation is not going to be a problem so long as we 
don't spend too long arguing about exactly what to modularise."

Regards, Benoit
> Hello Kireeti,
>
> Welcome to the party.
>
>> 1) At a high level, I would like to see services as compositions (mash-ups) of
>> service elements. This is a generalization of the comments that Aijun made.
>> Here’s why. As we (either the IETF or other bodies, or SPs on their own) define
>> other services, it would be very convenient to be able to reuse these service
>> elements.
> I completely take your point, but...
>
> When we started the L3SM work we were not certain (and some remain uncertain) that the problem could be addressed even for one of our most simple services (the L3VPN) let alone for a more generic concept of services. Therefore, the WG was explicitly tasked (read the charter) to work with focus and attention on L3VPN only and to exclude consideration of other services.
>
> That, in itself, does not predicate against modularisation, but it does make it hard to consider which modules to have (since some aspects of modularisation must surely consider the other services that might use the modules).
>
> Therefore, my expectation of progress is...
>
> - Continue to progress L3SM towards completion
> - Publish an RFC (if it can be agreed and done)
> - Start work on another similar service model (e.g. L2SM)
> - If there is energy
> - If the IESG gives us permission
> - Look for commonalities and modularisations
> - If they exist it may be necessary to revise L3SM
>
> So, from some aspects this does not look optimal. Perhaps you could have made this comment during chartering.
> But from another perspective it enables some initial progress in a new subject space that the IETF has not previously attempted. If it is successful we can dig deeper.
>
> Overall (setting aside the fact that we are anyway constrained by our charter) I have a fear of ocean-boiling. But some early, precautionary modularisation is not going to be a problem so long as we don't spend too long arguing about exactly what to modularise.
>
> Adrian
>
>
>
> _______________________________________________
> L3sm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/l3sm

_______________________________________________
L3sm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/l3sm