IETF Logo Mail Archive

Re: [mpls] [Idr] Fwd: Working Group adoption poll on draft-rosen-mpls-rfc3107bis

"Acee Lindem (acee)" <acee@cisco.com> Wed, 31 August 2016 14:37 UTC

Return-Path: <acee@cisco.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEA912DB8D; Wed, 31 Aug 2016 07:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.049
X-Spam-Level:
X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 kO5HmydG3n7n; Wed, 31 Aug 2016 07:37:24 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7FC12DCAB; Wed, 31 Aug 2016 07:15:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11345; q=dns/txt; s=iport; t=1472652905; x=1473862505; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CvM5Q8KFKzcjkuzN9CMh0R/5Ca4qBk9jNLU2/cZ8cMA=; b=CgXq+qzV+2DFz5aLCvffLUZKYZJVD1kvPvmY8rqEEcmBi7s0nWjCDPxe b7Ap5N/VI7FosiybfbYgzz07KvJLWHM9jxVT/sd71kYrP2kVcKAQuGwOm dbIOFzA3zBnKF0aadac9T/H8A5y8KoJLow3oNUE9tEH94Vp6arS+W3j3b c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D4AgAY5sZX/5xdJa1dgxozAQEBAQEegVMHg0CvUoUNggGGHQIcgS04FAECAQEBAQEBAV4nhGEBAQUjVhACAQgRAwECKAMCAgIwFAkIAgQBDQUbiCuuZI8jAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIl5gQOEIwEBO4JigloFmVABjy+PV4xIg3gBHjaCeoE1cIRNgSB/AQEB
X-IronPort-AV: E=Sophos;i="5.30,262,1470700800"; d="scan'208,217";a="147426382"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2016 14:15:04 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u7VEF2kl003951 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Aug 2016 14:15:04 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 Aug 2016 10:15:02 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 31 Aug 2016 10:15:02 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Robert Raszuk <robert@raszuk.net>, Eric Rosen <erosen@juniper.net>
Thread-Topic: [mpls] [Idr] Fwd: Working Group adoption poll on draft-rosen-mpls-rfc3107bis
Thread-Index: AQHSA2mTmZjCk1nk8UG09DsTehNMO6BjHUgA
Date: Wed, 31 Aug 2016 14:15:01 +0000
Message-ID: <D3EC5D03.7C805%acee@cisco.com>
References: <f1eda3f9-e097-098a-dd47-2386ab3f1a67@pi.nu> <8A502F2D-E7EC-4497-9BF1-1295E1F21A02@pi.nu> <CA+b+ERmp1YemDCKmpbjYBnxF5RPH-8mv0D+ASs3LDMieQn_4CA@mail.gmail.com>
In-Reply-To: <CA+b+ERmp1YemDCKmpbjYBnxF5RPH-8mv0D+ASs3LDMieQn_4CA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.198]
Content-Type: multipart/alternative; boundary="_000_D3EC5D037C805aceeciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/wQEjQ5KZ7NLMknCXn59tf-aVjAI>
Cc: idr wg <idr@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] [Idr] Fwd: Working Group adoption poll on draft-rosen-mpls-rfc3107bis
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Aug 2016 14:37:28 -0000

Hi Robert,

Currently, everything in draft-rosen-mpls-rfc3107bis is pretty much backward compatible with our more than a decade old RFC 3107 implementations and deployments. What you are proposing is not and has implications in both the control and forwarding planes. If you really believe that this is “the biggest issue", I’d suggest you articulate it in a separate draft with concrete use cases for having separate IP and MPLS topologies for the same set of prefixes. Then the WGs can evaluate the requirement and proposed solution independent of RFC 3107 BIS.

Thanks,
Acee

From: mpls <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>> on behalf of Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Date: Wednesday, August 31, 2016 at 5:24 AM
To: Eric C Rosen <erosen@juniper.net<mailto:erosen@juniper.net>>
Cc: IDR List <idr@ietf.org<mailto:idr@ietf.org>>, "mpls@ietf.org<mailto:mpls@ietf.org>" <mpls@ietf.org<mailto:mpls@ietf.org>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [mpls] [Idr] Fwd: Working Group adoption poll on draft-rosen-mpls-rfc3107bis

Hi Eric,

While adoption call is sort of encouragement for further input before I respond to Loa's mail I would like to get one additional answer from 3107bis authors and WGs members.

Those who spend years in mpls deployment know quite well that the biggest issue with today's 3107 deployment is lack of the clear definition of its interaction with SAFI-1. While one would hope that 3107bis with new capability will clean this mess section 5 of your document rather sweeps it all under the carpet stating that it is just local policy. IMO it is not a matter of local policy nor it is implementation detail.

Local policy can be to choose which RIB (or sequence of RIBs) should be used for resolution of specific SAFIs and not how to mix SAFI-1 with SAFI-4. It's not a local matter at all to have deployment resulting in inconsistent IBGP best paths across given domain.

To me cleanest is to separate those two SAFIs completely from each other by the spec both in BGP (done) as well as local RIB and FIB/LFIB.

Likewise I do not quite agree that SAFI-4 should be "convertible" to SAFI-1. And we all realize that opposite direction is rather hard.

Another perhaps minor clarification would be to get an explicit confirmation that SAFI-4 can be recursive over SAFI-4 or for that matter SAFI-1 (MPLS in GRE or SR in IP).

Thx,
R.

v2.23.0 | Report a Bug | By Email