Re: [L2sm] L2SM charter proposal

["Scharf, Michael (Nokia - DE)" <[e-mail]>]

Inline...

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Tuesday, October 11, 2016 10:56 AM
> To: Scharf, Michael (Nokia - DE); [e-mail]
> Subject: RE: [L2sm] L2SM charter proposal
> 
> 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?

I think the charter could use the term "customer service model". We can certainly argue whether this is the best term, but to me it is better than "service model". 

> > > 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?

I think a better alternative would be to list examples what MAY be included as well, provided there is WG consensus etc. But under the assumption that this WG shall be driven by operators, I suspect it is up to them to decide.

Potential implementations could probably deal with L2VPN services beyond VPWS and VPLS. Having a common base model could have benefits.

> > 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.

If that sort of work is expected to happen outside the L2SM WG, I wonder why the charter needs wording on it.

Or if it is expected to happen inside the L2SM WG, maybe a process different to L3SM would be needed?

I may be fine either way but I think a charter should have clear wording.

> > 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.

For L2SM there are comparable modeling activities in other standardization bodies, in open source projects (e.g., for orchestrators), etc. When L3SM was chartered, I think related work was less mature. So, the situation regarding a gap analysis is not exactly the same.

I think the charter should clearly explain whether a gap analysis is to be performed by the WG, or not. If the WG is not asked to perform a gap analysis, I think the charter wording can be cleaned up accordingly.
 
> 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

I agree that there could be benefits and therefore I think this design objective should be stressed. BTW, this argument does not apply to VPWS and VPLS only, as orchestrators may not be limited to that sort of services only.

> 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?

I don't follow IEEE and BBF, but both have Ethernet YANG modeling activities. Couldn't this matter?

And, as far as I know, MEF has liaisons with TMF, ONF, ITU-T, etc. on customer service models. Is there no need to look into this?

As L2VPNs are covered by multiple organizations, I'd really like to understand how the IAB plans to handle this. Wouldn't a charter be a good place to provide some guidance to the WG?

> >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?

This is normal WG business. I am more concerned about the impact of external dependencies.

Michael
 
> Anyway, that is my $0.02 to add to yours.
> Hopefully the AD is listening.
> 
> Cheers,
> Adrian