RE: Thoughts on draft-ietf-l2vpn-vpls-inter-domain-redundancy

"Lizhong Jin" <lizho.jin@gmail.com> Thu, 13 March 2014 16:00 UTC

From: "Lizhong Jin" <lizho.jin@gmail.com>
To: <adrian@olddog.co.uk>, <draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org>
References: <1f0201cf3ebb$0f657eb0$2e307c10$@olddog.co.uk>
In-Reply-To: <1f0201cf3ebb$0f657eb0$2e307c10$@olddog.co.uk>
Subject: RE: Thoughts on draft-ietf-l2vpn-vpls-inter-domain-redundancy
Date: Fri, 14 Mar 2014 00:00:34 +0800
Message-ID: <5321d62b.ac81420a.2853.fffff490@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: Ac8+uvcNYgxpfhvKRDOQITaOh3iBxgAGL4Hg
Content-Language: zh-cn
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/gwFP5VxAW8B8ssBXBAGJbqYV9DE
Cc: l2vpn@ietf.org
Precedence: list

Hi Adrian,
Thank you for the review. I will try to answer the questions.
- Can existing, off-the-shelf implementations of VPLS and ICCP be used
  to perform this function?
[Lizhong] no, the ICCP implementation should be enhanced to support this specific scenario in this draft. But this enhancement will not influence the protocol interoperability.
- Are there existing deployments of this function?
[Lizhong] we design this function for our customer (Zhihua Liu as co-author). Could Zhihua and other operators on the list help to clarify whether there is a deployment of this function?

Regards
Lizhong

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Thursday, March 13, 2014 8:52 PM
> To: draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org
> Cc: l2vpn@ietf.org
> Subject: Thoughts on draft-ietf-l2vpn-vpls-inter-domain-redundancy
> 
> 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