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

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 22 July 2015 12:28 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5B41B3197 for <l3sm@ietfa.amsl.com>; Wed, 22 Jul 2015 05:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102
X-Spam-Level:
X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id So3E1rGQNkLx for <l3sm@ietfa.amsl.com>; Wed, 22 Jul 2015 05:28:08 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD2F1B30FE for <l3sm@ietf.org>; Wed, 22 Jul 2015 05:28:08 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t6MCS4Tr005982; Wed, 22 Jul 2015 13:28:04 +0100
Received: from 950129200 (dhcp-b176.meeting.ietf.org [31.133.177.118]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t6MCS37r005960 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2015 13:28:04 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Kireeti Kompella' <kireeti.kompella@gmail.com>, l3sm@ietf.org
References: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com>
In-Reply-To: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com>
Date: Wed, 22 Jul 2015 13:28:03 +0100
Message-ID: <029d01d0c479$dc07ccd0$94176670$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIwkYdepbJsEKHhpNfOeVRJn/+ynJ0nzb1g
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21696.004
X-TM-AS-Result: No--11.996-10.0-31-10
X-imss-scan-details: No--11.996-10.0-31-10
X-TMASE-MatchedRID: hls5oAVArl84HKI/yaqRm/nCl+sgkNd7SZHpECn4g4tXPwnnY5XL5C7s reQJNnc7Pzin/03CLtPOgXE6r4gNc5IOhgOZiPMsBEfU2vugRF3SL+EVfOJR08CIs25kwV/ZAmM sMzPNmfMM556OdJ9dfvNDzsAQllGw6MiQmVdPpgiPYUYzX2Xjl6KaxHqGRwkC+Cckfm+bb6BiYT V2JsPIeW4tpK8fb7GNwEELKqiE+8CW+cf6nEkoShNEPNwNrw/rQKuv8uQBDjo76rqmQGSwT7No8 vBZ/z47bbZmB9bk47NinADt1JP3D8fEYAf1qh/lngIgpj8eDcByZ8zcONpAscRB0bsfrpPIfiAq rjYtFiRIipBsrsRP97R5vvrH39cIilG+LMP0pTTmm9xe3qr6DX7cGd19dSFd
Archived-At: <http://mailarchive.ietf.org/arch/msg/l3sm/jUMCu2NKf494_MCXgXZoRUZuEFE>
Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Wed, 22 Jul 2015 12:28:10 -0000

Hello Kireeti,

Welcome to the party.

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

I completely take your point, but...

When we started the L3SM work we were not certain (and some remain uncertain) that the problem could be addressed even for one of our most simple services (the L3VPN) let alone for a more generic concept of services. Therefore, the WG was explicitly tasked (read the charter) to work with focus and attention on L3VPN only and to exclude consideration of other services.

That, in itself, does not predicate against modularisation, but it does make it hard to consider which modules to have (since some aspects of modularisation must surely consider the other services that might use the modules).

Therefore, my expectation of progress is...

- Continue to progress L3SM towards completion
- Publish an RFC (if it can be agreed and done)
- Start work on another similar service model (e.g. L2SM)
   - If there is energy
   - If the IESG gives us permission
- Look for commonalities and modularisations
   - If they exist it may be necessary to revise L3SM

So, from some aspects this does not look optimal. Perhaps you could have made this comment during chartering. 
But from another perspective it enables some initial progress in a new subject space that the IETF has not previously attempted. If it is successful we can dig deeper.

Overall (setting aside the fact that we are anyway constrained by our charter) I have a fear of ocean-boiling. But some early, precautionary modularisation is not going to be a problem so long as we don't spend too long arguing about exactly what to modularise.

Adrian