Re: [mpls] https://tools.ietf.org/html/draft-fang-mpls-hsdn-for-hsdc-01

Petr Lapukhov <petr@fb.com> Thu, 26 March 2015 00:56 UTC

Return-Path: <prvs=0527b9b59b=petr@fb.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2401A1B23; Wed, 25 Mar 2015 17:56:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.084
X-Spam-Level:
X-Spam-Status: No, score=0.084 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, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 lCpzW7fC3Nqz; Wed, 25 Mar 2015 17:56:28 -0700 (PDT)
Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1CD21A1A58; Wed, 25 Mar 2015 17:56:27 -0700 (PDT)
Received: from pps.filterd (m0004077 [127.0.0.1]) by mx0b-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id t2Q0rP2e013377; Wed, 25 Mar 2015 17:56:25 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=RNmANG31FzmFncTYbmkTXV1PwIbgst66h+mNCyAdcMc=; b=Dk7b3FypnnJjCdVsIi0NVf5JuhZmD0rpcfJPxNtHyy2tY2Zx3K9ZEFO9Wi7hhIFL4req K+9d002ytyNW0paPo0Zr3WRQ0fjx3eD0Q06b9MG6ZM38f4EB1RG/iDuigyPkirQRCRlG FCGDnUGxGz0AdUaUB1AlScZojzG0O5I1xaQ=
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 1tc7tw816n-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Mar 2015 17:56:25 -0700
Received: from PRN-MBX01-2.TheFacebook.com ([169.254.4.97]) by PRN-CHUB11.TheFacebook.com ([fe80::80d:37ff:4b6a:a4fc%12]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 17:56:23 -0700
From: Petr Lapukhov <petr@fb.com>
To: Robert Raszuk <robert@raszuk.net>
Thread-Topic: https://tools.ietf.org/html/draft-fang-mpls-hsdn-for-hsdc-01
Thread-Index: AQHQZ1fPspED0N7DmUK9mRcUoHV2rZ0t8Ksz
Date: Thu, 26 Mar 2015 00:56:21 +0000
Message-ID: <A5CA7469-D5E8-4E55-903A-89B048E2267F@fb.com>
References: <CA+b+ERnGa3TOo5-qu5RWyPXcjduKCrYzX0hR2F6NEkNoQe9h=w@mail.gmail.com>
In-Reply-To: <CA+b+ERnGa3TOo5-qu5RWyPXcjduKCrYzX0hR2F6NEkNoQe9h=w@mail.gmail.com>
Accept-Language: en-US
Content-Language: ru-RU
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_A5CA7469D5E84E55903A89B048E2267Ffbcom_"
MIME-Version: 1.0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-25_07:2015-03-25,2015-03-25,1970-01-01 signatures=0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/4bkvoyCxSZShaR-MljGnMhoIeNI>
X-Mailman-Approved-At: Thu, 26 Mar 2015 07:23:40 -0700
Cc: "mpls@ietf.org" <mpls@ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>, Luyuan Fang <lufang@microsoft.com>
Subject: Re: [mpls] https://tools.ietf.org/html/draft-fang-mpls-hsdn-for-hsdc-01
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 26 Mar 2015 00:56:30 -0000

AFK, so can't write a well-formed comment :(

but in short, my personal experience was that circuit-like transports play well as *augmentation* to shortest-path / ecmp / longest-prefix match techniques, not as a complete replacement (after all, ip already works). Mpls circuits are alright if you have network asymmetry and need to work around it, but in symmetric topologies they seem rather unnecessary, unless you really want to have end-to-end uniform data plane, which has both downsides and benefits.

Robert and I had some discussions around pure mpls / seamless mpls DC + DCI networks a couple of years ago, but it was hard to find a strong selling point for mpls (I was arguing for mpls, btw). In general, MPLS offers uniform, protocol agnostic forwarding plane, with simple lookup, but the latter is not such a big win with modern (and upcoming) silicon. Next, for entropy reasons it is often necessary to resort to leaky abstractions with mpls  (eg nibble guessing) or add complications (entropy label), which makes the architecture more complicated.

Additionally, I feel that FIB compaction has more to do with network structure and careful control of state propagation rather that underlying forwarding mechanism. On this side, something that could be achieved with IP via simple summarization requires rather sophisticated LSP hierarchies with mpls.

To me, the only good selling point for mpls in DC, in my opinion, is having a uniform end to end transport (with corresponding OAM etc). It is not very clear whether this has more advantages than downsides, and requires a separate discussion :)

Petr

Mar 25, 2015, в 5:00 PM, "Robert Raszuk" <robert@raszuk.net<mailto:robert@raszuk.net>> написал(а):

Hello Luyuan,

Quote:


"The HSDN forwarding architecture in the underlay network isbased on four main concepts: 1. Dividing the DC and DCI in ahierarchically-partitioned structure; 2. Assigning groups ofUnderlay Border Nodes in charge of forwarding within each partition; 3. Constructing HSDN MPLS label stacks to identify the end points according to the HSDN structure; and 4. Forwarding using the HSDN MPLS labels."


Can you provide any reasoning for going to such complexity when trying to use MPLS as transport within and between DCs as compared with using IP based transport ? Note that IP based transport native summarization provides unquestionable forwarding FIB compression.


Quote:


"HSDN is designed to allow the physical decoupling ofcontrol and forwarding, and have the LFIBs configuredby a controller according to a full SDN approach. Th controller-centric approach is described in this document."


+

Quote:


"2) The network nodes MUST support MPLS forwarding."



Please kindly note that to the best of my knowledge number of ODMs routers used to construct IP CLOS Fabric does not really have control plane which supports MPLS transport. Neither distributed nor centrally ie via controller managed.


Quote:


"The key observation is that it is impractical, uneconomical, and
ultimately unnecessary to use a fully connected Clos-based topology in a large scale DC."


That is an interesting statement. I think however that one should distinguish interconnected regions with proper CLOS fabric from some sort of CLOS fabric want-to-be type of topologies. In any case it has no bearing on the main points of the scalable interconnect discussion.


- - -


While we could go via number of other comments let's cut it short.


Your draft states that HSDN works with IPv4 transport in the below statement:


Quote:


"Although HSDN can be used with any forwarding technology, including IPv4 and IPv6,"


1. Can you summarise reasons what problems do you see with IPv4/IPv6 based underlay in the DCs that drove you to provide this document to be based on MPLS ?


(Note that tenant mobility is the overlay task and nothing to do with underlay.)


2. Can you describe how are you going to distribute MPLS stack to be used for forwarding in the underlay to servers ?


3. How are you going to provide efficient ECMP intra-dc ? I see no trace of entropy labels in your document.


4. For TE is there anything missing in the below document ?

https://tools.ietf.org/html/draft-lapukhov-bgp-sdn-00


Many thx,

r.