Re: [L2sm] L2SM charter proposal

["Adrian Farrel" <[e-mail]>]

Hello Michael,

> I am not sure where the charter wording on
> https://datatracker.ietf.org/wg/l2sm/charter/ has been discussed. Anyway, I
had
> a look...

Don't think it has. I think the creation of this list gives us all the chance,
and it seems like you took it correctly :-)

Looking at the status of the charter, it hasn't been to the IESG yet, and after
that it will go to the whole IETF. So now is not a bad time for discussions.

> > The Layer Two Virtual Private Network Service Model (L2SM) working group is
a
> > short-lived WG tasked to create a YANG data model that describes a L2VPN
> > service (a L2VPN service model) that can be used for communication between
> > customers and
> 
> Isn't one of the lessons learnt from L3SM that the term "service model" can be
> understood in quite different ways, in particular in hierarchical network
> architectures?

Yeah. You're right that there was a lot of discussion and confusion about what a
service model is.

Qin Wu, Will Liu, and I wrote draft-wu-opsawg-service-model-explained to try to
get some consensus around the different meanings. But that document is not a WG
document (yet?) and certainly can't claim to have consensus.

So I see the problem, but I don't see a solution. To me (of course) it is clear
what a "service model" is. Is there a form of words that you would find helpful
to scope the L2SM work to the same type of "service model" that L3SM addressed?

> > applications. The working group will attempt to derive a single data model
that
> > includes support for point-to-point Virtual Private Wire Services (VPWS) and
> > multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled
> > using the Label Distribution Protocol (LDP) and the Border Gateway Protocol
> > (BGP) as described in RFC4761 and RFC6624.
> 
> To me, "includes support for" is not a very specific wording. Will the
deliverable of
> a working group be limited to VPWS and VPLS? If yes, why not state it? If no,
why
> not be more explicit about what else may be in scope, or not in scope?

I read this as:
- MUST include VPWS and VPLS
- MAY include other things

The text could be clearer. Which way would you like it to go: exclusive or
inclusive?

> BTW, that long sentence is hard to parse.

Agree.

> > It needs to be clearly understood that this L2VPN service model is not an
L2VPN
> > The deliverable from this working group will provide information to evaluate
> > the set of YANG models that have already been developed or are under 
> > development,
> 
> That sentence is also in the L3SM charter. But I wonder if L3SM has indeed
> delivered an evaluation of existing YANG models? Also, I am not sure how
draft-
> wen-l2sm-l2vpn-service-model addresses this requirement.

Hmmm, I do not believe that L3SM was chartered to provide that evaluation.
Instead (and as you note, exactly as the text is proposed for L2SM) the charter
states:

|The deliverable from this working group will provide information to evaluate
the set of
|YANG models that have already been developed or are under development, and will
|help identify any missing models or details. The deliverable can be viewed as
driving 
|requirements for protocol configuration model so that the service parameters
can be
|mapped into inputs used by the protocol models.

I took this to mean that the L3SM could be used by those working on models
"lower down the stack" (such as in BESS, RTGWG, IDR, etc.) to see whether they
had captured all of the details that would be needed to deliver the services
that operators want to sell to customers.  Looked at another way, implementers
building automated service delivery systems (who might want to support L3SM or
some proprietary variant) would use L3SM to determine whether they could map a
customer's service request to the YANG models that are used within the network
to deliver the service.

I'm not aware of this work having been done in a public forum, however, since
there are implementations of L3SM, I assume that the work has been done and that
perhaps some of the changes proposed to other models over time have arisen have
come from this work.

> I believe for L2VPNs there are other ongoing modeling activities, e.g., in
MEF, and
> there may also be overlap with some transport-oriented work in other IETF WGs.
> This sentence could be understood as an evaluation and gap analysis of
existing
> YANG models.

I think that is exactly the correct understanding.
The question is, however, who does that gap analysis.
As I say, I don't think the L3SM WG was asked to do the analysis, and this
charter text is not asking a potential L2SM WG to do that.

Gap analyses are, IMHO, best done by the people who propose to fill the gaps not
by an "external authority" that might try to instruct someone else to fill the
gaps.

> > and will help identify any missing models or details. The deliverable can be
> > viewed as driving requirements for protocol configuration model so that the
> > service parameters can be mapped into inputs used by the protocol models.
> 
> Again, I wonder if this WG really plans to deliver this? Has L3SM really
managed to
> provide good requirements for parameter mapping, e.g., for the non-trivial
> service parameters such as QoS?

As above.

> > The working group will learn from the experience of the L3SM working group
> > and it is expected that the L2SM data model will have similar structure to
the
> > L3SM data model.
> 
> I am not sure what the first part of this sentence would imply? Unless it is
spelt
> out what these lessons learnt are, I think it can be removed. The charter
wording
> of L2SM itself may obviously leverage lessons learnt from L3SM ;-)
> 
> The second part of the sentence results in quite a number of constraints
> regarding the model design. I think this warrants a dedicated sentence, and
> possibly even some further discussion on the priority of aligning structure
with
> L3SM vs. aligning with other YANG models.

The benefits of aligning structure with L3SM would seem to be:
- a "service orchestrator" could use common or similar code
- customers will have familiarity across services
- there is future potential to generalise into a common service
   model 
- discussions that led to the L3SM structure are not repeated
   leading to more rapid development

Other models with which L2SM might align are presumably the service delivery
models being worked on in BESS. There is absolutely value in looking at these
models, but they are technology specific and it is risky to force the service as
offered by the operator to be too dependent on how the network is operated.
Orchestration and mapping will be required.

> > The working group should consider draft-wen-l2sm-l2vpn-service-model as a
> > starting point.
> > 
> > The working group will coordinate with other working groups responsible for
> > L2VPN protocol work (most notably with BESS and PALS) and with the MEF.
> 
> I think there is a difference between BESS/PALS and MEF. The models in BESS
> and PALS don't overlap significantly with the scope of the L2SM charter.
> 
> I think a more explicit statement regarding MEF would be useful. MEF works on
> quite related YANG models. For instance, draft-wen-l2sm-l2vpn-service-model
> includes the following sentence: "Rather than introducing a new set of
> terminologies, the L2SM will align with existing MEF attributes when it's
> applicable." That wording may be a starting point. Albeit the question is
whether
> some sort of liaison would be limited to terminology reuse only.

I agree that the relationship with MEF will be very important.
Liaison relationships are created and maintained by the IAB.
In the absence of such a relationship a WG can only communicate and coordinate.

> Also, I wonder if MEF is really the only other relevant standardization body
for
> L2VPNs.

Ah, that's important.
Which other bodies or forums have you got in mind?

>From an implementer's perspective, lack of alignment between standardization
> bodies is an issue.
> 
> > Milestones
> 
> > December 2016   Adopt WG draft for data model
> > October  2017   Request publication of data model as Standards Track RFC
> > December 2017   Close working group
> 
> Well, this seems a bit ambitious to me, given the experience in L3SM. And L3SM
> didn't have to consider e.g. other standardization bodies...

When have WG milestones ever not been ambitious? . 
But you make a good point. L3SM was close to its dates until it hit the tail. It
had a very long tail and I do know why except that perhaps the largest volume of
review comments didn't come until right at the end of the work - perhaps a
feature of caring about the output but not caring to contribute to the
development?

Anyway, that is my $0.02 to add to yours.
Hopefully the AD is listening.

Cheers,
Adrian