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 5A7E61A7005; Wed, 25 Mar 2015 20:34:21 -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 4lZE2EnpUuVo; Wed, 25 Mar 2015 20:34:18 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 94C6A1A7001; Wed, 25 Mar 2015 20:34:18 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so43240872igb.1; Wed, 25 Mar 2015 20:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uqnforVYTJl/JXHwtrtk7mOlQLGHtEox54j721vSiYo=; b=unYvlqv8cXZAjK+0MQxiQr75Lz958fTXNUFpydFHxp3TX7BUfZDI9JU3Fz1qSmcsPp qkT6FDjAHgntF+H5gSljJOdruMbjTmDTLdr4fq/67RuDslxFKfYOr/IeqF40ZSjyOcJi /r0+EUIKL9h9aRaSEcMmqLsK9g0vojfU4MEFu86/yPzOKEuP4Kfvl4oZ2YHvbqpEBLxP AleghUJQGNVKOY+G+u///m8UKPwqp4tMd6YVKdpUc54YBHr46uQKFK1JLbVTIPgjMCzu H8acLPMI82yzGcGPvjUh8z70lkElTlCt2u7VffuqRbiS7Zotd7GZ5+I9M3W6rXAP9z0c TAig== MIME-Version: 1.0 X-Received: by 10.50.29.109 with SMTP id j13mr34235016igh.2.1427340858034; Wed, 25 Mar 2015 20:34:18 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.137.70 with HTTP; Wed, 25 Mar 2015 20:34:17 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Mar 2015 04:34:17 +0100 X-Google-Sender-Auth: fD0Cj2HyU8XcpVEIRiw3037CGwk Message-ID: From: Robert Raszuk To: Petr Lapukhov Content-Type: multipart/alternative; boundary=047d7bd74a30d11216051228b07d Archived-At: Cc: "mpls@ietf.org" , "nvo3@ietf.org" , Luyuan Fang 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 03:34:21 -0000 --047d7bd74a30d11216051228b07d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Petr, Thank you very much for yr comment ! One question: > 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). Let me understand this. What is the definition of "uniform end to end transport" ? If you use IP for transport and say use L3VPN option C in overlay or for example LISP what is not uniform in compute node to compute node transport across any DC or any region ? As far as OAM do we have any missing tools with IP operation ? - - - I am just trying to understand technical rationale - if any such exist - aside from sales, political, religious or fanatic - why anyone would propose mpls transport for DC underlay. - - - No longer then today I was actually arguing with one networking vendor that MPLS as demux value (say in RFC4364) makes a lot of sense for DCs multi tenant rather then reinventing the wheel and use different name for effectively the same function (GRE key or NVGRE VSID). But that is in the overlay space. Completely different topic. Best regards, r. On Thu, Mar 26, 2015 at 1:56 AM, Petr Lapukhov wrote: > 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 matc= h > 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, unle= ss > 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, b= ut > 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), whi= ch > 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, =D0=B2 5:00 PM, "Robert Raszuk" =D0=BD= =D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): > > Hello Luyuan, > > Quote: > > "The HSDN forwarding architecture in the underlay network isbased on fou= r main concepts: 1. Dividing the DC and DCI in ahierarchically-partitioned = structure; 2. Assigning groups ofUnderlay Border Nodes in charge of forward= ing within each partition; 3. Constructing HSDN MPLS label stacks to identi= fy 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 bas= ed transport ? Note that IP based transport native summarization provides u= nquestionable forwarding FIB compression. > > > Quote: > > > "HSDN is designed to allow the physical decoupling ofcontrol and forwardi= ng, and have the LFIBs configuredby a controller according to a full SDN ap= proach. 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 router= s used to construct IP CLOS Fabric does not really have control plane which= supports MPLS transport. Neither distributed nor centrally ie via controll= er 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 disting= uish 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 statem= ent: > > > 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 base= d underlay in the DCs that drove you to provide this document to be based o= n MPLS ? > > > (Note that tenant mobility is the overlay task and nothing to do with und= erlay.) > > > 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. > > > --047d7bd74a30d11216051228b07d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Petr,

Thank you very much for yr comment= ! One question:

> To me, the only good selling point for mpls in DC, in my opinion,= =C2=A0
> is having a uniform end to e= nd transport (with corresponding OAM etc).

Let me understand this. What is the definition of "uniform end to en= d transport" ?=C2=A0

If you use IP for transport and say use L3VPN optio= n C in overlay or for example LISP what is not uniform in compute node to c= ompute node transport across any DC or any region ?=C2=A0

As far as OAM do = we have any missing tools with IP operation ?=C2=A0

- - -=C2=A0

I am just tryin= g to understand technical rationale - if any such exist - aside from sales,= political, religious or fanatic - why anyone would propose mpls transport = for DC underlay.

- - -=C2=A0

No longer then today I was actually arguing with o= ne networking vendor that MPLS as demux value (say in RFC4364) makes a lot = of sense for DCs multi tenant rather then reinventing the wheel and use dif= ferent name for effectively the same function (GRE key or NVGRE VSID). But = that is in the overlay space. Completely different topic.

Best regards,
r.


On= Thu, Mar 26, 2015 at 1:56 AM, Petr Lapukhov <petr@fb.com> wrote:=
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). Mp= ls 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 uni= form 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 sell= ing point for mpls (I was arguing for mpls, btw). In general, MPLS offers u= niform, protocol agnostic forwarding plane, with simple lookup, but the latter is not such a big win with moder= n (and upcoming) silicon. Next, for entropy reasons it is often necessary t= o resort to leaky abstractions with mpls =C2=A0(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 s= tructure and careful control of state propagation rather that underlying fo= rwarding 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 h= aving a uniform end to end transport (with corresponding OAM etc). It is no= t very clear whether this has more advantages than downsides, and requires = a separate discussion :)

Petr

Mar 25, 2015, =D0=B2 5:00 PM, "Robert Raszuk" <robert@raszuk.net> =D0=BD=D0= =B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):

Hello Luyuan,

Quote:

"The HSDN forwarding a=
rchitecture in the underlay network isbased on four main concepts: 1. Divid=
ing the DC and DCI in ahierarchically-partitioned structure; 2. Assigning g=
roups ofUnderlay Border Nodes in charge of forwarding within each partition=
; 3. Constructing HSDN MPLS label stacks to identify the end points accordi=
ng to the HSDN structure; and 4. Forwarding using the HSDN MPLS labels.&quo=
t;

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

Quote:

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

+ 
Quote:

&qu=
ot;2) The network nodes MUST support MPLS forwarding."


Please kind=
ly note that to the best of my knowledge number of ODMs routers used to con=
struct IP CLOS Fabric does not really have control plane which supports MPL=
S transport. Neither distributed nor centrally ie via controller managed.

Quote:

"T=
he key 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 interesting statement. =
I think however that one should distinguish interconnected regions with pro=
per 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 intercon=
nect discussion.

- - -=C2=A0
=

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

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

=
Qu=
ote:

<=
/span>
&quo=
t;Although HSDN can be used with any forwarding technology, including IPv4 =
and IPv6,"
=

1. Can you summarise reasons what problems do you se=
e with IPv4/IPv6 based underlay in the DCs that drove you to provide this d=
ocument to be based on MPLS ?=C2=A0

(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 use=
d for forwarding in the underlay to servers ?

=

3. How are you going to provide efficient ECMP in=
tra-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<=
br>

Many thx,
r.

--047d7bd74a30d11216051228b07d--