IETF Logo Mail Archive

Re: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-00.txt

"Acee Lindem (acee)" <acee@cisco.com> Wed, 02 September 2015 19:04 UTC

Return-Path: <acee@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936921B4B87; Wed, 2 Sep 2015 12:04:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 Ze1Rog_mv4d5; Wed, 2 Sep 2015 12:03:57 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06AB31B4DF4; Wed, 2 Sep 2015 12:03:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3162; q=dns/txt; s=iport; t=1441220627; x=1442430227; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XeXGDBz0+U9AGHsjyPvBBbvUHy4yF9Hh9y/SSce/j1o=; b=edgwhFdOPI+5jYNN/iXGit0grg8S3O5VjQlEC/m/jbHXFYAkRsccgbSZ /0glj7ZbWte8J/Whk14poWC58wJWijPfDy75JKUCzFeWZXiwVOEdTbOuM /7cxP80SbblIcGxxpBprv2mUuLZt9AUVkF3nNaLG1Mvq7Y377Qg2xzJ07 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CQAgATR+dV/4gNJK1dgxtUaQaDHbopAQmBbQqFewIcgR44FAEBAQEBAQGBCoQkAQEEAQEBIBE6CxACAQgaAiYCAgIlCxUQAgQBDQWILg22KpR5AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIopMhFgzB4JpgUMBBJVJAYUGh2+abyaEAHGBSIEFAQEB
X-IronPort-AV: E=Sophos;i="5.17,455,1437436800"; d="scan'208";a="25686315"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP; 02 Sep 2015 19:03:46 +0000
Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t82J3ksx021492 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Sep 2015 19:03:46 GMT
Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Sep 2015 14:03:45 -0500
Received: from xhc-aln-x10.cisco.com (173.36.12.84) by xch-rcd-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 2 Sep 2015 14:03:45 -0500
Received: from xmb-aln-x06.cisco.com ([169.254.1.223]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0248.002; Wed, 2 Sep 2015 14:03:44 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Robert Raszuk <robert@raszuk.net>, Eric C Rosen <erosen@juniper.net>
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-00.txt
Thread-Index: AQHQ5NwO82W77Wiiu0+jfmFIdeZl/Z4oVYwAgAAJRgCAAAVuAIABYK8AgAAllgD//45jgA==
Date: Wed, 02 Sep 2015 19:03:43 +0000
Message-ID: <D20C94E4.2D86B%acee@cisco.com>
References: <20150819185950.7160.20919.idtracker@ietfa.amsl.com> <55E5CA6B.1000308@labn.net> <D20B2EC6.26AC6%keyupate@cisco.com> <CA+b+ERmEEO4_6_tdih68BAjrFVOxJ-VaAuAR=Ms=zj7NdF0YiA@mail.gmail.com> <55E5F8FA.6020108@labn.net> <D20B4955.26B4C%keyupate@cisco.com> <55E72562.5070405@juniper.net> <CA+b+ERn0r4Xjjh05r5xmy9Z2rU4L_7xbcdRyyTYi_AdNxzCb9w@mail.gmail.com>
In-Reply-To: <CA+b+ERn0r4Xjjh05r5xmy9Z2rU4L_7xbcdRyyTYi_AdNxzCb9w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.37.102.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <35BF7FFC61A7CE42876EEE1D3E00B6D9@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/_HWf7CFt2Mdkuv8sU6RcxgCRLR8>
Cc: "Keyur Patel (keyupate)" <keyupate@cisco.com>, "idr@ietf.org" <idr@ietf.org>, Lou Berger <lberger@labn.net>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-00.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2015 19:04:03 -0000

Hi Robert, 

On 9/2/15, 11:50 AM, "Idr on behalf of Robert Raszuk"
<idr-bounces@ietf.org on behalf of robert@raszuk.net> wrote:

>Hi Eric,
>
>> Of course, nothing stops someone from writing a new draft specifying
>> something like the Encaps-SAFI, and specifying the semantics of
>> attaching various attributes (including the tunnel encapsulation
>> attribute) to it.
>
>True that nothing stops to do that work. It is only that such work to
>go from draft to RFC will take easily 5-8 years in the current IETF
>process.
>
>Use case for encapsulation SAFI I see is described in
>https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-00
>especially when there is need to do EPE in traditional WAN networks
>and not those "trendy" ones Keyur referred to which no longer use ISIS
>or OSPF.

Are you sure you meant to reference the BGP EPE draft? AFAIK, there is no
requirement for the encapsulation SAFI in this draft. The advertised EPE
SIDs are local segment routing labels - MPLS is the implied encapsulation.

Thanks,
Acee 




>
>As you know (apparently not everyone does) attaching an attribute to
>route which is not used for forwarding (due to Admin Distance as
>example) makes implementations very ugly and kludgy.
>
>Sorry but I do not buy arguments stating as a main reason that
>deploying new SAFI is hard. If you deploy new SAFI in a p2p fashion
>between controller and PE/ASBR (which is exactly what is needed for
>EPE use case) its deployment is as easy as deploying BGP-LS SAFI.
>
>Cheers,
>Robert.
>
>PS1:
>
>> But the feedback (both public and private) has been
>> overwhelmingly in favor of obsoleting RFC5512
>
>Just curious if that feedback came from the same folks who voted and
>encouraged original specification or completely different ones .... ;)
>
>PS2:
>
>For EPE use case using Encap SAFI for signalling controller to edges
>is just an option. There could be of course alternatives worked for
>example in I2RS WG or using YANG models and NETCONF. So I will not be
>making much noise about keeping it any more. It just looks bizarre to
>obsolete something which seems useful.
>
>_______________________________________________
>Idr mailing list
>Idr@ietf.org
>https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email