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

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> 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).
> 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" <[e-mail]> написал(а):
>
>    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.
>
>
>