Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt

Qin Wu <bill.wu@huawei.com> Thu, 12 January 2017 05:52 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: l2sm@ietfa.amsl.com
Delivered-To: l2sm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9473129488 for <l2sm@ietfa.amsl.com>; Wed, 11 Jan 2017 21:52:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.419
X-Spam-Level:
X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 eU7h0fmaR94x for <l2sm@ietfa.amsl.com>; Wed, 11 Jan 2017 21:52:39 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4FF12943B for <l2sm@ietf.org>; Wed, 11 Jan 2017 21:52:38 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYQ67566; Thu, 12 Jan 2017 05:52:36 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 12 Jan 2017 05:52:35 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.43]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 12 Jan 2017 13:51:47 +0800
From: Qin Wu <bill.wu@huawei.com>
To: John Strassner <strazpdj@gmail.com>, "l2sm@ietf.org" <l2sm@ietf.org>
Thread-Topic: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt
Thread-Index: AQHSbJf2T9wdissAAkujXPHJj+CEEg==
Date: Thu, 12 Jan 2017 05:51:47 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9A751B3E@nkgeml513-mbs.china.huawei.com>
References: <CAJwYUrH6jRoHv3m8b8RXw4_Lir41nGv=JDVvTE6S6brJiOBkUQ@mail.gmail.com>
In-Reply-To: <CAJwYUrH6jRoHv3m8b8RXw4_Lir41nGv=JDVvTE6S6brJiOBkUQ@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.78.218]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9A751B3Enkgeml513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.587719A5.0016, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.43, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 9f589624d8aa4ae52ce80a9e2451103a
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2sm/-9gxmSbHFZWzBldnz4_UrCCNlv4>
Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt
X-BeenThere: l2sm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" <l2sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2sm>, <mailto:l2sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l2sm/>
List-Post: <mailto:l2sm@ietf.org>
List-Help: <mailto:l2sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2sm>, <mailto:l2sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jan 2017 05:52:42 -0000

>   * I can't speak for anyone else, but my criticism regarding the
>     inclusion of "technology-specific parameters", as you put it, is not
>     in respect of the PE-CE links.  I agree the technology details are
>     needed there.  However, the draft also includes a lot of details
>     about the technology used within the SP's network (i.e., PE-PE) -
>     that is the detail which I think is not relevant and does not belong
>     in a service model.

I do agree that some of those parameters should be removed. That
shouldn't be considered as a reason for the WG to not adopt this
draft. Indeed, it **should** be easier to gain consensus on what should
and should not be included by working on it as a WG.

Regarding the PE-PE technology, I viewed that as being part of the
Service Delivery Model in the opsawg draft. Qin, please correct me
if I am wrong here.

[Qin]: Thanks John for clarification and comments.
Service Delivery Model is really about how the service is delivered and realized while L2SM model is about what the service is, what kind of technologies available you can support.
Service Delivery Model is a model that has already been instantiated, e.g., VRF specific detailed parameters(VRP, route distinguisher, router target),
BGP specific detailed parameters such as next hop options. These parameters are part of service delivery model, but not part of L2SM model or L3SM model. L2SM would not cover too much details on these BGP specific parameters, it just say bgp, ospf, static, rip, etc can be supported since L2SM is not instantiated model, since you don’t know which PE you will select, which interface on the device you will allocate before they can be mapped into config parameters therefore we introduce location and device constraint in the model to help the management system to decide PE selection, interface selection in the lower layer rather than service layer.

I am not sure we really cover PE-PE details in L2SM model, we did describe one VPN can be extended across multiple autonomous systems, but don’t go into details to discuss
VRF specific detailed parameters and BGP specific detailed parameters, since these are something belonging to service delivery model. you will see L3SM also model it as one special site.

In a word, L2SM model will only describe how many sites you have, how one site connects to the other site, how one site connects to internet, DataCenter, public cloud, how to describe
Connectivity between these sites or between site and datacenter. What kind of technologies pertaining to these connectivity service can be supported.