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

Kireeti Kompella <kireeti.kompella@gmail.com> Tue, 21 July 2015 15:00 UTC

Return-Path: <kireeti.kompella@gmail.com>
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2BD1B1B2EA9 for <l3sm@ietfa.amsl.com>; Tue, 21 Jul 2015 08:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AsWL0lfFT0p1 for <l3sm@ietfa.amsl.com>; Tue, 21 Jul 2015 08:00:13 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C92B1B2EB6 for <l3sm@ietf.org>; Tue, 21 Jul 2015 08:00:13 -0700 (PDT)
Received: by wicmv11 with SMTP id mv11so44168267wic.0 for <l3sm@ietf.org>; Tue, 21 Jul 2015 08:00:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=pu9kYLzyqd8nH+0yDofuUUPXUcfMPharh8bzn6IfygA=; b=XOOqSz2unNWgMli2x6z/JMc23eQIYnP0F0Lz+4GtMUki5o0JnB3Gs0deGHWLIi2kEj w/kVbYNMZnO6RlQMSJ7PNzVR92bRndNp9xfZL5tSVGs/rgFqnhTfQlQwSFwYeZw1rbvq f4IcuopYITtEpAqV/ak6BNSzfzUQIYeBgOOcaHGXlB7uMbOQ/EXnt6fdoWSCbo45aHdS XqKbnh+kvOMtmbEaSLqOCPoUf1osWysq1wbNzq7RG9Udb44kZRxLEXfOg4CXrrNzgBoy dSx7KkJvT7EH9ud78bbKh7TAD/FCuBX4xCk/BZvdB3I5Fmws3ZnFjVyMXAUZJCG1OQfc JDow==
X-Received: by with SMTP id t4mr34128737wiv.55.1437490812011; Tue, 21 Jul 2015 08:00:12 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:176:c80:953:3006:3eff? ([2001:67c:370:176:c80:953:3006:3eff]) by smtp.gmail.com with ESMTPSA id v20sm37456670wjw.17.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Jul 2015 08:00:10 -0700 (PDT)
From: Kireeti Kompella <kireeti.kompella@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 21 Jul 2015 17:00:10 +0200
Message-Id: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com>
To: l3sm@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/l3sm/bEyM3hzho61LO0UWF0yeD2-lGYY>
Cc: Kireeti Kompella <kireeti.kompella@gmail.com>
Subject: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: L3VPN Service YANG Model discussion group <l3sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3sm>, <mailto:l3sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l3sm/>
List-Post: <mailto:l3sm@ietf.org>
List-Help: <mailto:l3sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3sm>, <mailto:l3sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jul 2015 15:00:15 -0000


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:
	OAM (liveness)

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

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

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.

4) might be hard, but define defaults for as many YANG leaves as possible.

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.

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?

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 :)