[mpls] https://tools.ietf.org/html/draft-fang-mpls-hsdn-for-hsdc-01
Robert Raszuk <robert@raszuk.net> Thu, 26 March 2015 00:00 UTC
Return-Path: <rraszuk@gmail.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 88A811A906A; Wed, 25 Mar 2015 17:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Xu3LWDzKMaFF; Wed, 25 Mar 2015 17:00:00 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA751A8822; Wed, 25 Mar 2015 17:00:00 -0700 (PDT)
Received: by igcxg11 with SMTP id xg11so40418034igc.0; Wed, 25 Mar 2015 17:00:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=+fpxsnnKoAlfjFjLZhyoL7xJ+wbZ+2Eszw8SFWoyeOk=; b=aZ0nBIowK2626uxybCZvGGEBhrZCgW2s9Iz4a6iZM/CoFdxOamXOqZVG/4gh+06oR8 sQga1ZsMM9+NleeElw/4/NIfOh57g8haY/SlCn2OlAZImldAyhitJcUMl1+2vqveBN+O eruUNA7l11ylTgdN1QfQTQvxsyxSNxy8oiRqwHL1rENLcBG2ff8MxA2vMThUgFFYdHhs NZdffvRzglR9XN13UJBNIrn6BEOQqBadHSXLUdBZiKCYbmZUyu/CLFlYw0XzHJT+fRl8 7jLtnZy0hvlL7Alc105QQb6+qCXmN6YA5r3kBRxI3zdAaMYp3G3CjIAuQJhautiL5xz/ bRLA==
MIME-Version: 1.0
X-Received: by 10.107.149.210 with SMTP id x201mr16557591iod.33.1427328000054; Wed, 25 Mar 2015 17:00:00 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.107.137.70 with HTTP; Wed, 25 Mar 2015 17:00:00 -0700 (PDT)
Date: Thu, 26 Mar 2015 01:00:00 +0100
X-Google-Sender-Auth: jEkUceyXKenkUqorlp9C6IhsbMw
Message-ID: <CA+b+ERnGa3TOo5-qu5RWyPXcjduKCrYzX0hR2F6NEkNoQe9h=w@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: Luyuan Fang <lufang@microsoft.com>
Content-Type: multipart/alternative; boundary="001a1140fe666be092051225b22f"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/Z0Wfc2QyyzNvO6v7rFCU1z6C6X8>
Cc: "mpls@ietf.org" <mpls@ietf.org>, Petr Lapukhov <petr@fb.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: [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:00:02 -0000
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.
- [mpls] https://tools.ietf.org/html/draft-fang-mpl… Robert Raszuk
- Re: [mpls] https://tools.ietf.org/html/draft-fang… Robert Raszuk
- Re: [mpls] https://tools.ietf.org/html/draft-fang… Petr Lapukhov
- Re: [mpls] https://tools.ietf.org/html/draft-fang… Petr Lapukhov
- Re: [mpls] https://tools.ietf.org/html/draft-fang… Petr Lapukhov