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

[Rob Shakir <[e-mail]>]

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