Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap

Philip Christian <philip.christian@pscan.eu> Tue, 08 March 2016 11:12 UTC

Return-Path: <philip.christian@pscan.eu>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803A412D63C for <isis-wg@ietfa.amsl.com>; Tue, 8 Mar 2016 03:12:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eH3rXu0MIZm for <isis-wg@ietfa.amsl.com>; Tue, 8 Mar 2016 03:12:17 -0800 (PST)
Received: from know-smtprelay-omc-11.server.virginmedia.net (know-smtprelay-omc-11.server.virginmedia.net [80.0.253.75]) by ietfa.amsl.com (Postfix) with ESMTP id 52A4E12D621 for <isis-wg@ietf.org>; Tue, 8 Mar 2016 03:12:16 -0800 (PST)
Received: from christiantena.net ([82.13.85.13]) by know-smtprelay-11-imp with bizsmtp id TPCE1s0020HFYiy01PCF4m; Tue, 08 Mar 2016 11:12:15 +0000
X-Originating-IP: [82.13.85.13]
X-Spam: 0
X-Authority: v=2.1 cv=JO3GyJ+b c=1 sm=1 tr=0 a=j0AvSjNDViVSPqYGGWZBsw==:117 a=j0AvSjNDViVSPqYGGWZBsw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=7OsogOcEt9IA:10 a=WFZaTFp8ZY4A:10 a=nOQOZ-58r4lSKzjNUrUA:9 a=pILNOxqGKmIA:10
Received: from [109.249.186.85] (helo=[192.168.47.27]) by christiantena.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from <philip.christian@pscan.eu>) id 1adFYi-000Fi6-Dg; Tue, 08 Mar 2016 11:12:12 +0000
To: Xuxiaohu <xuxiaohu@huawei.com>, Marc Binderberger <marc@sniff.de>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
References: <4C33F1DA-351A-4E4C-AB2D-EB9C530EBA36@chopps.org> <05BB1848-0F89-4A06-B1C6-7E955C41C9E9@chopps.org> <2d9f516b68fd4443853f512a533bd9d6@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A6046915200863514605D3@eusaamb105.ericsson.se> <1B502206DFA0C544B7A60469152008635152D9E1@eusaamb105.ericsson.se> <3741852a2e494e6ca54fd6ffe847ba14@XCH-ALN-001.cisco.com> <20160227175134.GA16059@gredler.at> <623aa7aca98449d68305bb75bf9744dd@XCH-ALN-001.cisco.com> <20160228194314146283.17ea4e23@sniff.de> <b9b35fb6bfe44819922dfcffc218c8a8@XCH-ALN-001.cisco.com> <20160229024208162275.1495b944@sniff.de> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D514403@NKGEML515-MBX.china.huawei.com> <20160306125630991244.b2923b6f@sniff.de> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D526C7F@NKGEML515-MBX.china.huawei.com>
From: Philip Christian <philip.christian@pscan.eu>
Message-ID: <56DEB2E7.1060304@pscan.eu>
Date: Tue, 08 Mar 2016 11:09:27 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D526C7F@NKGEML515-MBX.china.huawei.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/miEIeI01kuedJGuknRp_jU7rs-c>
Cc: Les Ginsberg <ginsberg@cisco.com>, Christian Hopps <chopps@chopps.org>
Subject: Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Mar 2016 11:12:19 -0000

Please can you explain why you are proposing a new protocol extension to
do this when there is an existing extension which already achieves
exactly the same thing? i.e. the Encapsulation capability TLV described
in ITU-T G.7712 and in draft-ietf-isis-auto-encap-03.

thanks, Philip

> 
> Your understanding is correct that this draft follows the idea of
> RFC5512. That's to say, it allows automatical discovery of the tunnel
> decapsulation capability of tunnel egress nodes). The tunnel
> decapsulation capability includes but not limited to tunnel types,
> tunnel parameters (e.g., GRE key, L2TP session ID and cookie) and
> encapsulated protocols. In contrast with the tag proposal, there is
> no need for operators to manually configure many mappings between
> tags and tunnel decapsulation capabilities on each router. The manual
> configuration of such mappings is error-prone and therefore should be
> avoided if possible, IMHO.
> 
> Best regards,
> Xiaohu
>