Thoughts on draft-ietf-l2vpn-vpls-inter-domain-redundancy
"Adrian Farrel" <adrian@olddog.co.uk> Thu, 13 March 2014 12:52 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com
(Postfix) with ESMTP id CD7171A082B for <l2vpn@ietfa.amsl.com>;
Thu, 13 Mar 2014 05:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.654
X-Spam-Level:
X-Spam-Status: No, score=-98.654 tagged_above=-999 required=5
tests=[BAYES_40=-0.001, RCVD_IN_BL_SPAMCOP_NET=1.347,
RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=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 iLoayc_WoHJ7 for
<l2vpn@ietfa.amsl.com>; Thu, 13 Mar 2014 05:52:23 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248])
by ietfa.amsl.com (Postfix) with ESMTP id B8B2F1A07C5 for <l2vpn@ietf.org>;
Thu, 13 Mar 2014 05:52:22 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by
asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2DCqFah009258;
Thu, 13 Mar 2014 12:52:15 GMT
Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14])
(authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id
s2DCqCQQ009209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
Thu, 13 Mar 2014 12:52:14 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org>
Subject: Thoughts on draft-ietf-l2vpn-vpls-inter-domain-redundancy
Date: Thu, 13 Mar 2014 12:52:13 -0000
Message-ID: <1f0201cf3ebb$0f657eb0$2e307c10$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac8+uvcNYgxpfhvKRDOQITaOh3iBxg==
Content-language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20562.006
X-TM-AS-Result: No--16.830-8.0-31-10
X-imss-scan-details: No--16.830-8.0-31-10
X-TMASE-MatchedRID: msidVWA1CGfZfnct5UBzcZmug812qIbzbv16+gil4jdrE1c4mB5UmnS/
VNg23pNaqFmvpQsglxqPhw/39nH6VbvuuksuYzsCbBu6+EIezdxEkrrs6EaaQ200AzyoQy/vP7C
Sa70XxNQbvLloXxZpcccQ/lgeOq52JXb8mGWA8s8ve6W+IORwrSwJzaIVMjGtbaZMa0fgRtb4EO
Cdhooabgdw1Bt6Zo9Z1SQkxzt2Vp8YB2fOueQzjySxIFlMYKvCtOt1ofVlaoIc4jS1nsD4HfoLR
4+zsDTtAqYBE3k9Mpw=
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/1xDqKUGtERwBcUHciD8XiK-jABU
Cc: l2vpn@ietf.org
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Layer 2 Virtual Private Networks <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>,
<mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn/>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>,
<mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Mar 2014 12:52:25 -0000
Hi authors, chairs, etc., As is my usual practice, I am doing a review of your document as AD to support the publication request from the WG chairs. I'll come back with further details, but for the moment I have one high level question about the intended status of this document. I am pretty sure that it is not your intention that this is a protocol specification. The advice you are giving is about how to use existing building blocks to make a deployment, and the description as a BCP seem to support this. However, you describe the contents as a "solution" and there seem to be "changes" to an ICCP implementation that are needed to make this work. Section 5.1 seems to suggest that there are some changes needed to get the ICCP implementation on the PEs to do the right thing to make this deployment possible. This seems to be consistent with your use of RFC 2119 language. Similarly, you describe the way that RFC 6870 procedures are enhanced. The implication, therefore, is that if you take existing implementations off the shelf you cannot build this deployment. You need special modifications to make it work. Doesn't that make this a protocol specification (even if rather a simple one)? On the other hand, I think a lot of the description (using "should" etc.) in Section 5 is describing the proper behavior of an ICCP implementation and needs to be phrased as "will (according to [ICCP])". So, I am a bit confused about what this document is trying to do. Maybe that confusion can be cleared by answering: - Can existing, off-the-shelf implementations of VPLS and ICCP be used to perform this function? - Are there existing deployments of this function? Thanks in advance, Adrian
- Thoughts on draft-ietf-l2vpn-vpls-inter-domain-re… Adrian Farrel
- RE: Thoughts on draft-ietf-l2vpn-vpls-inter-domai… Lizhong Jin