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