Subject: Re: multiple lookups per packet

From: "S. Chkaravorty" <[email-masked]>
Date: Sun, 19 Nov 2000 15:00:18 -0500

Thanks Manohar.

> I think you raised an important concern regarding the direction MPLS is taking
> us and our ability to see its final role in the internet. To me sometimes it
> appears that MPLS is more of an interim solution/attempt to fit/reuse ATM
> hardware to provide fast IP switching.

1.  Agreed.  It is an INTERIM solution for some (not all) ATM vendors and
carriers. And that too, MPLS has not been tested out in the inter-ISP level yet,
the best we can tell.

> On the other hand there are genuine concerns from traffic engineering
> perspective that large ISPs, such as UUNET, that  would like to see some
> control over routing compared to best effort and hop-by-hop routing. They need
> to establish paths in the network that are determined by operator or by
> dynamic traffic engineering constraints. MPLS architecture does provide lot of
> advantages to do that.

2.  Agreed.  But I have also heard from one of very senior UUNET engineers that
the best they can do is intra-ISP TE (and that is all they do with MPLS - no
kidding).

> QoS Provisioning platforms should be able to  perform better compared to
> traditional models (IntServ or DiffServ) vs  label based QoS.

3.  Agreed again - completely.  (Such platform provisioning is already widely
used in data centers where the traffic is no less huge.)

> In the presence of multiple label lookup, this is an issue only at the
> aggregation point or the penultimate hop. There might be some implementation
> improvements such as hardware caching or some low level software in the data
> forwarding/switching path that might not make multiple label lookup come in
> the way of switching at line speed. One can always add latency of 125uSec (All
> SONET equipment adds latency of 125 uSec) that will provide some breathing
> space for the LSR/LER. This means LSR is processing a Packet that will be sent
> 125uSecond later. However I don't think multiple lable look up performance
> issue will arise due to use of  deep nesting in practical deployment. Any
> level more than 2 or 3 might be questionable traffic engineering practice
> although I can't rule out such a scenario. But generally
> aggregation/deaggregation will be done but one must balance against what will
> be gained by too much aggregation vs using separate LSP.

4. Just as a reminder, way back and possibly for much larger time allotment
available, ATM was considered not scalable.  Now we have MPLS over ATM with much
less time on hand (OC 48 - 192) and should we think we don't have a problem?

SC

---

From: "Manohar Ellanti" <[email-masked]>
Date: Sun, 19 Nov 2000 23:13:37 -0800

SC,

I think you raised an important concern regarding the direction MPLS is
taking us and our ability to see its final role in the internet.

To me sometimes it appears that MPLS is more of an interim solution/attempt
to fit/reuse ATM hardware to provide fast IP switching. On the other hand
there are genuine concerns from traffic engineering perspective that large
ISPs ,such as UUNET, that  would like to see some control over routing
compared to best effort and hop-by-hop routing. They need to establish paths
in the network that are determined by operator or by dynamic traffic
engineering constraints. MPLS architecture does provide lot of advantages to
do that.

QoS Provisioning platforms should be able to  perform better compared to
traditional models (IntServ or DiffServ) vs  label based QoS. In the
presence of multiple label lookup, this is an issue only at the
de-aggregation point or the penultimate hop. There might be some
implementation improvements such as hardware caching or some low level
software in the data forwarding/switching path that might not make multiple
label lookup come in the way of switching at line speed. One can always add
latency of 125uSec (All SONET equipment adds latency of 125 uSec) that will
provide some breathing space for the LSR/LER. This means LSR is processing a
Packet that will be sent 125uSecond later.

However I don't think multiple lable look up performance issue will arise
due to use of  deep nesting in practical deployment. Any level more than 2
or 3 might be questionable traffic engineering practice although I can't
rule out such a scenario. But generally aggregation/deaggregation will be
done but one must balance against what will be gained by too much
aggregation vs using separate LSP.

-Manohar