Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt

[John Strassner <[e-mail]>]

Hi all,

first, I would like to express support for the WG adopting this draft. Sorry
that I'm not an operator :-) but I am actively involved in the MEF and
other relevant IETF WGs.

Second, some comments to Scott:

> Hi Scott,
>
> I agree; but what is being proposed is not iteration, reuse and
> extension, which you rightly extol.

I disagree - the iteration is the continuous revision of the draft. The
charter
says that the WG "...will also coordinate with other organizations working
on related L2VPN data models (such as the MEF)", which is good enough
for me.

> It is instead ignoring all the work
> that has gone before (not just the MEF yang models, but the 10+ years of
> work MEF has done in defining Carrier Ethernet services).

I think that the L2SM charter is different than the Carrier Ethernet work
done
in the MEF. Where do you think they overlap, and why?

>
> Benoit, to answer your points:
>
>   * You are correct that MEF has a grand vision for the LSO
>     architecture; time will tell whether that is achievable. However,
>     the one small part of it that they are furthest progressed with is
>     exactly the same area that is covered by L2SM.  I don't understand
>     why you think L2SM is following a different architecture; in both
>     cases what we are talking about is a model for the set of things
>     that need to be agreed between the SP and the customer, right?

I disagree. The charter says:

    ... is a short-lived WG. It is tasked to create a YANG data model that
    describes a L2VPN service (a L2VPN customer service model). The
    model can be used for communication between customers and
    network operators, and to provide input to automated control and
    configuration applications.

First, the MEF didn't start with the goal of creating a YANG data model;
this by itself differentiates the resulting architectures and approaches.
The fact that 10 years later the MEF added a YANG model doesn't
make them equal. Indeed, the MEF (should) be defining its YANG
model directly from its Core Info Model and relevant other models; in
contrast, the IETF currently has no such info model from which to
derive the L2SM YANG data model.

Second, in reading Qin's opsawg draft, there is some similarity in how
a "service model" is defined (e.g., emphasizing connectivity offered).
However, I still view this as different from the current work done in
the MEF. For example, I would hope that in the MEF, we would
consider defining service models that are amenable to orchestration;
that is clearly outside the scope of L2SM (at least now).

>   * I can't speak for anyone else, but my criticism regarding the
>     inclusion of "technology-specific parameters", as you put it, is not
>     in respect of the PE-CE links.  I agree the technology details are
>     needed there.  However, the draft also includes a lot of details
>     about the technology used within the SP's network (i.e., PE-PE) -
>     that is the detail which I think is not relevant and does not belong
>     in a service model.

I do agree that some of those parameters should be removed. That
shouldn't be considered as a reason for the WG to not adopt this
draft. Indeed, it **should** be easier to gain consensus on what should
and should not be included by working on it as a WG.

Regarding the PE-PE technology, I viewed that as being part of the
Service Delivery Model in the opsawg draft. Qin, please correct me
if I am wrong here.

>   * I do not understand what you mean when you say the MEF has worked on
>     CE-based models.  A service model is not used between the CE and PE,
>     it is used between the customer's management systems (as the client)
>     and the SP's management systems (as the server).  There are
>     differences in terminology for those systems, but fundamentally I
>     don't see any difference between MEF and IETF approach here.  Can
>     you clarify what you meant?

I agree with David that the MEF model is **not** a CE-based model. I'm
also not sure what is meant by that.

As stated earlier, I disagree with David that the MEF and IETF approaches
are the same - please see my above comments.

>
> Benoit, you mentioned that, as vendors, we should listen more to
> operators.  I agree.  I would love to hear from the operators who
> support adoption of this draft what issues they see with the MEF models,
> and why they believe that starting again from scratch in IETF is a
> better option than working with MEF to improve on what they have already
> done, and then augmenting ("extending") it to fill in any gaps.  The MEF
> models are certainly far from perfect (and of course they are still WIP
> in MEF), but what I would like to understand is why you, as operators,
> think they are not a good starting point for solving the problems that
> led to the creation of this WG.

I would love to hear that as well, but this shouldn't be an impediment for
the WG to adopt this draft.

>
>    David
>>
>>On 03/01/2017 19:19, Scott Mansfield wrote:
>>
>> I agree with Benoit.  There are many dimensions to the modeling space
>> and we can’t let the perfect be the enemy of the good.  Constant
>> communication and sharing will help alignment while allowing the
>> people that actually run networks to get what they need.  30+ years of
>> object-oriented software development (should have) taught all
>> designers/architects/programmers that the first iteration of a
>> solution is not the best and most optimized. Each iteration provides
>> the opportunity to abstract, refine, refactor, and extend.  Proper
>> information hiding and encapsulation is key.  Automation is very
>> important and we need to work together to ensure that whatever models
>> that are created are supported by tools that allow for effective reuse
>> and extensions.

...

elided rest of message thread


regards,
John

-- 
regards,
John