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

Hi Kireeti,

Thanks for your valuable comments (as usual ;) ).

See inline comments

-----Original Message-----
From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Kireeti Kompella
Sent: Tuesday, July 21, 2015 17:00
To: l3sm@ietf.org
Cc: Kireeti Kompella
Subject: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model

Hi,

Very happy to see this WG, and to see the l3vpn _service_ YANG model.  Wish I’d been paying attention earlier :)

Some comments:

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.  Example: suppose an L2SM module is needed.

Elements to consider:
	availability
	QoS
	access-control-list
	OAM (liveness)
	customer-specific-info

I don’t know how one defines a mash-up of modules in YANG, maybe as simple as “import”.

[SLI] Modularization is a really good point, before going to start the work, I would like to ensure that all components are there so we can think the good way to split elements. For sure groupings can be created and being reused.

(Note: this has nothing to do with service chaining!)

2) I think it would be convenient to have certain stanzas directly under vpn-svc, and again under vpn-svc/sites — essentially, a default for the entire service, and overrides for each site.
[SLI] Could you elaborate on which stanza you would like to see ?

3) not sure why “bfd” is under “routing protocols”.  You may be better off having a stanza called OAM/Hello/liveness, where one can choose bfd among other mechanisms.
[SLI] Some shortcuts have been taken (like vrrp as routing protocol :) ), this can be fixed.

4) might be hard, but define defaults for as many YANG leaves as possible.
[SLI] Not sure this would be doable, but I will have a look. Defaults may differ for each service providers ...

5) From comments on the mailing list, it seems OTT VPNs (customer-provisioned) are out of scope; however, doing such a model will help clarify common elements, and might help organize the L3VPN SM better.
[SLI] For now yes, but the idea is to see if we can make the model generic enough to fit also customer provisioned VPNs.

6) Philosophical comment: should scrutinize service models to ensure we’re making them as abstract as possible.  E.g., I’m very happy that RDs and RTs are not in the SM.  Question: what else can be trimmed?
[SLI] Multiple eyes are required for that purpose, we are continuously trying to trim and make more abstraction but any new idea is good to take. Idea list is becoming empty on our side ... so new eyes are welcome.

Finally, should YANG models (in general) have guidance as to where to place augments?  The theory is, you start with an SM (or data model in general) that everyone agrees on — lowest common denominator.  Then, as people augment a DM, if a certain augmentation appears in several such models, that might be promoted to being a part of the standard DM.  Or maybe I’m a dreamer :)

Kireeti.

_______________________________________________
L3sm mailing list
L3sm@ietf.org
https://www.ietf.org/mailman/listinfo/l3sm

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.