The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

Here is a specific problem:

Even though DS WG has defined specific codepoints (one of which is AF and is
quite generic in terms of applicability to services), the architecture also
allows for arbitrary codepoints and arbitrary remappings between codepoints.

Not only this, but it allows for arbitrary remappings that depend not only
the ingress port but also the egress port (since each ingress port can be
coming from a DS domain and each egress port can be going to another DS
domain). This causes an NxM multiplication problem where any HW that
actually implements these specs needs to tolerate a N ingress ports being
remapped to M egress ports in a fashion that could either depend on the
pre-configured DSCPs and policer outputs or completely be specified by the
user.

In addition, most HW that operates at OC48c/OC192c speeds does this by
streaming packets through and not using store and forward mechanisms (Just
check the specs for recent framers, network processors, etc). This means
that the packet length (especially for MPLS) is NOT available until the
packet has left the HW pipeline. This means that modification to the packet
headers can not be done at a single point in a system and need to be split
among egress and ingress.

I do realize that there are ways to overcome these problems, but HW cycle
times are unlike software. In this regard, the lack of standardized (and not
so flexible) mechanisms and the lack of definition of standardized services
(which are intentionally left out of the scope of the DS WG) is causing a
lot of heartaches for HW development.

So HW/system vendors then choose the mechanisms that make sense and
implement them, but this causes HW to not comply with certain aspects of
some internet drafts.

I am making these comments in a constructive manner hoping that it helps the
standardization problem, on the other hand, we don't have the luxury of time
to wait, so I am expecting people's experiences with DS to become available
for review sometime soon.

I also believe that the inherent flexibility of the DS documents are
hampering the deployment of a DS based architecture in the Internet, also
the confusion over terminology, and continuous introduction of new terms is
not helping this process either.

Regards

Bora Akyol



> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> Sent: Thursday, June 01, 2000 11:08 AM
> To: Bora Akyol
> Cc: diffserv@ietf.org
> Subject: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv 
> Extensions
> related questions/comments
> 
> 
> Bora Akyol wrote:
> 
> [mpls list deleted from this reply]
> 
> > 8. THIS IS A GRIPE. Did anyone consider hardware 
> pipelining, etc while this
> > spec was being written? This actually is one of my biggest 
> gripes about
> > Diffserv. It is so damn flexible which makes almost any HW 
> implementation
> > leave out features, maybe we should have started something 
> that was concrete
> > and implementable.
> 
> I think there were plenty of people working at the 
> hardware/software boundary
> involved in the basic definition of diffserv; efficient 
> implementability
> was the main motivation for choosing a stateless model driven 
> by a 6 bit flag.
> 
> You generalized gripe is not much help. Can you be specific 
> about where
> you see the lack of implementability? 
> 
>   Brian
>