Re: [Isis-wg] Relationship between draft-xu-isis-encapsulation-cap and draft-ietf-isis-auto-encap-03

Philip Christian <philip.christian@pscan.eu> Thu, 10 March 2016 16:58 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 65AA712DA3B for <isis-wg@ietfa.amsl.com>; Thu, 10 Mar 2016 08:58:36 -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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6kvLyTdlpp2 for <isis-wg@ietfa.amsl.com>; Thu, 10 Mar 2016 08:58:33 -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 7C03612D85E for <isis-wg@ietf.org>; Thu, 10 Mar 2016 08:56:21 -0800 (PST)
Received: from christiantena.net ([82.13.85.13]) by know-smtprelay-11-imp with bizsmtp id UGwJ1s0140HFYiy01GwKCA; Thu, 10 Mar 2016 16:56:20 +0000
X-Originating-IP: [82.13.85.13]
X-Spam: 0
X-Authority: v=2.1 cv=Cbz1n+fl c=1 sm=1 tr=0 a=j0AvSjNDViVSPqYGGWZBsw==:117 a=j0AvSjNDViVSPqYGGWZBsw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=7OsogOcEt9IA:10 a=WFZaTFp8ZY4A:10 a=48vgC7mUAAAA:8 a=MLryxz_PCb4bnORS_xwA:9 a=FRKw1qfGqoSMbNcB:21 a=88i1ir0oMhSNs3_Q:21 a=QEXdDO2ut3YA: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 1ae3sm-000Lp0-TB; Thu, 10 Mar 2016 16:56:16 +0000
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "xuxiaohu@huawei.com" <xuxiaohu@huawei.com>
References: <f996714c90c249b5a71ec4d8938d3aad@XCH-ALN-001.cisco.com>
From: Philip Christian <philip.christian@pscan.eu>
Message-ID: <56E1A68A.3030307@pscan.eu>
Date: Thu, 10 Mar 2016 16:53:30 +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: <f996714c90c249b5a71ec4d8938d3aad@XCH-ALN-001.cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/4N9v3j7uPYzU9TvxFDT5nVyiskA>
Subject: Re: [Isis-wg] Relationship between draft-xu-isis-encapsulation-cap and draft-ietf-isis-auto-encap-03
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: Thu, 10 Mar 2016 16:58:36 -0000

Hi Les & Xiaohu,

I understand your point that they are different use cases of encapsulation.
However I also think that a single code point could be used for both as
they are so similar.

The old draft for G.7712 / isis-auto-encap was too narrow in scope to
cover both use cases, but that is a problem with the words in the draft,
not with using the code point.  The words in the draft can be changed,
they are just words.  I can do it in a few hours if this wg wants me to,
or Xiaohu and me can do it together; I don't mind.

Equally the two use cases could use two different code points.  The two
technologies would just ignore each other.

This WG needs to decide whether these two things should use the same
codepoint, which would be a generalised encapsulation capability TLV=16
with two or more usecases, or whether the "tunnelling over the hole"
usecase should use 16 and the "meshing of tunnels over IP" usecase
should use router-capability TLV=242.  Both views are probably valid,
and I don't think that either Xiaohu or me are going to "win" such an
argument, so the WG will need to decide.

Concerning the use of auto-encap in G.7712 I have started to put feelers
out to see whether it actually got deployed or not.  This is going to
take weeks or months of research because the SONET/SDH guys are buried
very deep in major telcos and not easy to find.  The routing stacks are
also written by different vendors to those who actually sell the kit and
some of these vendors no longer exist, but the boxes are still there
connecting countries and cities together.

I would not expect a "migration" away from CLNP to be complete until the
lasers burn out in the multiplexers to be honest.  Once these things are
installed and forwarding traffic the operators will never, never touch
them. Unnecessary upgrades will always be avoided.  This was the whole
reason that tunnelling across them was needed.

I was quite cross that IANA would not document the use of TLV 16 by
G.7712 in an ITU-T official document.  It would cost them nothing and
could have protected against a massive network meltdown of a national or
international optical network, or at least the status panel of a major
telco all going red and the ops guys having a panic wondering if they
just trashed an entire national network or not.  Fortunately no-one has
chosen to use TLV 16 for something else but I still think it was a mistake.

sorry for the long email, I hate long emails and so now I have made a
hypocrite of myself, Philip

On 10/03/2016 15:40, Les Ginsberg (ginsberg) wrote:
> (Subject was " Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap")
> 
> (I have deliberately changed the subject and removed (most of) the original thread.)
> 
> Philip/Xiaohu -
> 
> For me the debate about whether the same codepoint  should be used in the two drafts serves neither constituency. 
> 
> The two drafts are trying to address two qualitatively different issues.
> 
> In the case of draft-xu-isis-encapsulation-cap the authors are suggesting that explicitly advertising supported tunnel encaps/endpoints is useful in order to support partial deployment of some existing encap (MPLS, SR) over a common L3 layer or to support some form of traffic engineering (RLFA example is cited).  The debate going on is NOT about the encoding of the advertisement, it is about whether the advertisement is needed at all. Some of us have suggested that there are existing mechanisms which will serve just as well - if not better.
> 
> In the case of draft-ietf-isis-auto-encap-03, the draft is trying to address the case of islands where a common network layer is not supported (notably an IP island in a CLNS network - or vice versa) - in which case forwarding is not possible at all without introducing some tunneling encap. The debate (if memory serves...it has been 12 years :-) ) was about whether this is a problem which needs solving. For the SONET deployment community this issue did exist (not sure whether it still does) - but from the IP/IPv6 community the need for solving this problem was not perceived as great.
> 
> I think Philip has a point that it could be possible to use the codepoint from the auto-encap draft in support of draft-xu-isis-encapsulation-cap - but focusing on that debate when the need for draft-xu-isis-encapsulation-cap is still being debated seems at best premature.
> 
> I also think that using draft-xu-isis-encapsulation-cap to try to advance draft-ietf-isis-auto-encap-03 is inappropriate. The need to support the use case defined in the auto-encap draft should be discussed on its own merits. It was discussed years ago - whether it needs to be revived should be the subject of a separate thread (if at all). I am concerned that there might be a codepoint in use which is not documented in the IANA registry - so it would be useful to hear whether this technology is in active use in SONET deployments. The draft itself states this is a migration tool - if the migration has already occurred then obviously this makes reviving auto-encap moot.
> 
>    Les
> 
> 
>> -----Original Message-----
>> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Philip Christian
>> Sent: Monday, February 29, 2016 3:30 AM
>> To: isis-wg@ietf.org
>> Subject: Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
>>
>> Please can people explain how
>>
>> https://datatracker.ietf.org/doc/draft-xu-isis-encapsulation-cap/
>>
>> might fit in with, or cause problems with this
>>
>> https://tools.ietf.org/html/draft-ietf-isis-auto-encap-03
>>
>> which was adopted by the ITU-T and appears to be still very much part of IT-T
>> G.7712.