[nvo3] 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: nvo3@ietfa.amsl.com
Delivered-To: nvo3@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/nvo3/FoQ2EdrUguI756hxW9QUWnI2oJI>
Cc: Pedro Marques <pedro.r.marques@gmail.com>, "mpls@ietf.org" <mpls@ietf.org>, Petr Lapukhov <petr@fb.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: [nvo3] https://tools.ietf.org/html/draft-fang-mpls-hsdn-for-hsdc-01
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-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.