Return-Path: 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: From: Robert Raszuk To: Luyuan Fang Content-Type: multipart/alternative; boundary=001a1140fe666be092051225b22f Archived-At: Cc: "mpls@ietf.org" , Petr Lapukhov , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 00:00:02 -0000 --001a1140fe666be092051225b22f Content-Type: text/plain; charset=UTF-8 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. --001a1140fe666be092051225b22f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Luyuan,

Quote:

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

Can you provide any reasoning for going to such complexity when t=
rying to use MPLS as transport within and between DCs as compared with usin=
g IP based transport ? Note that IP based transport native summarization pr=
ovides 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 doc=
ument."
+ 
Quote:
=


"2) The network no=
des MUST support MPLS forwarding."


Please kindly note that to the best of my knowledge number of ODMs route=
rs used to construct IP CLOS Fabric does not really have control plane whic=
h supports MPLS transport. Neither distributed nor centrally ie via control=
ler managed.

Quote:

"The ke=
y observation is that it is impractical, uneconomical, and
ultimately unnecessary to use a fully connected Clos-based topology in a la=
rge scale DC."

That is an i=
nteresting statement. I think however that one should distinguish interconn=
ected 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.

- - -=C2=A0

While we could g=
o via number of other comments let's cut it short.=C2=A0

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

Quote:

"Altho=
ugh HSDN can be used with any forwarding technology, including IPv4 and IPv=
6,"

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

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

2. Can you d=
escribe how are you going to distribute MPLS stack to be used for forwardin=
g 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. Fo=
r TE is there anything missing in the below document ?
https://tools.ietf.org/html/draft-l=
apukhov-bgp-sdn-00

Many thx,
r.

=
--001a1140fe666be092051225b22f--