Re: [Isis-wg] WG adoption of draft-xu-isis-encapsulation-cap

Hannes Gredler <hannes@gredler.at> Mon, 24 October 2016 09:21 UTC

Return-Path: <hannes@gredler.at>
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 CE42D1295A4 for <isis-wg@ietfa.amsl.com>; Mon, 24 Oct 2016 02:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level:
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 JSQ36PT_NPSo for <isis-wg@ietfa.amsl.com>; Mon, 24 Oct 2016 02:21:48 -0700 (PDT)
Received: from gilfert.gredler.at (gilfert.gredler.at [87.106.222.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB5312943D for <isis-wg@ietf.org>; Mon, 24 Oct 2016 02:21:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) (uid 1000) by gilfert.gredler.at with local; Mon, 24 Oct 2016 11:21:46 +0200 id 0000000002FAC667.00000000580DD2AA.0000320C
Date: Mon, 24 Oct 2016 11:21:46 +0200
From: Hannes Gredler <hannes@gredler.at>
To: uma.chunduri@gmail.com
Message-ID: <20161024092146.GA12580@gredler.at>
References: <f996714c90c249b5a71ec4d8938d3aad@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A604691520086358001538@eusaamb106.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <1B502206DFA0C544B7A604691520086358001538@eusaamb106.ericsson.se>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/t1SqbJxJFseCmabC2YpAqVdP_q8>
Cc: Christian Hopps <chopps@chopps.org>, isis-wg@ietf.org
Subject: Re: [Isis-wg] WG adoption of 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: Mon, 24 Oct 2016 09:21:51 -0000

uma,

guess we have rough consensus that this is work that the WG wants to take on -
please resubmit as draft-ietf-isis-encapsulation-cap.

thanks !

/hannes & chris


On Fri, Apr 08, 2016 at 03:24:40AM +0000, Uma Chunduri wrote:
| Les,
| 
| Thx for your reply.
| 
| > Some of us have suggested that there are existing mechanisms which will serve just as well - if not better.
| 
| What existing mechanism do we have to advertise the tunnel capabilities and the associated parameters of the egress node to be used at an ingress node??
| 
| I think w.r.t tags usage - 
| 
| Multiple responses was given in the mailing list including http://www.ietf.org/mail-archive/web/isis-wg/current/msg04500.html  
| http://www.ietf.org/mail-archive/web/isis-wg/current/msg04519.html 
| 
| However we can further update the draft to include provisioning requirements at ingress node with available options for the operators to exercise the preference.
| (it seems per offline discussion @ietf95).
| 
|  --
| Uma C.
| 
| 
| -----Original Message-----
| From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
| Sent: Thursday, March 10, 2016 7:41 AM
| To: Philip Christian; isis-wg@ietf.org; xuxiaohu@huawei.com
| Subject: [Isis-wg] Relationship between draft-xu-isis-encapsulation-cap and draft-ietf-isis-auto-encap-03
| 
| (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.
| _______________________________________________
| Isis-wg mailing list
| Isis-wg@ietf.org
| https://www.ietf.org/mailman/listinfo/isis-wg
| 
| _______________________________________________
| Isis-wg mailing list
| Isis-wg@ietf.org
| https://www.ietf.org/mailman/listinfo/isis-wg