Subject: RE: multiple lookups per packet

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 20 Nov 2000 11:14:06 -0500

agree everything except the last statement.
I think traffic engineering aspects of MPLS may require
cascadeing tunnels for service aggregation purposes.
This is new and not a bad thing, just contradicts your last point.

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Monday, November 20, 2000 11:03 AM
To: S. Chkaravorty
Cc: [email-masked]'
Subject: Re: multiple lookups per packet 

SC> One of the largest product vendors  have told me that MPLS does not work
SC> well in the core where speed (optics_ckts) is the concern. 

Well, don't believe everything you hear.

SC> It is really too complex given this "multi-tunneling" aspect,

This makes  no sense to me.  Either  a particular node needs  to function as
the endpoint  of several nested  tunnels, or it  does not.  If it  does not,
then  it will  not need  to look  at  more than  one label,  so the  "multi-
tunneling aspect" is  irrelevant.  If the node does need  to function as the
endpoint of several nested tunnels, then it will need to do multiple lookups
regardless of whether MPLS  is used or not.  Use of MPLS  does not force one
into use of multi-tunneling mode.

---

From: [email-masked]
Date: Wed, 22 Nov 2000 09:00:37 -0000

Eric Rosen wrote: <snipped>

> Php  was invented precisely  to ensure
> that you don't  end up with a  bunch of "sorry, look below"  labels when
> you
> get to the egress.
> 
> You  don't need  to lose  QoS information  with php,  since the  QoS  can
> be
> propagated downward when a label is  popped.  As Curtis points out, there
> is
> some impact  on your ability to keep  per-LSP counts, and if  there were
> any
> OAM capability that might be impacted as well.
	NH=>PHP seems a very crude tool that does not appear to have been
thought out in arch terms.  I know many attending IETF don't have a high
regard for ITU work (which I think is a pity, since they lose out in
learning something) but for those with open minds I would suggest a look a
G.805 (functional arch) will prove useful.  This describes, in particular,
trails and client/server (network layer) recursion.  All the important
server<=>client adaptation functions are performed just after the server
layer trail termination point......so this would include functionality like
connectivity verifcation, defect detection, defect consequent actions (eg
foward/backward defect information), prot-sw, performance registers (if
used), etc.......so yes Curtis is right, making the trail term point a
movable feast does cause a problem for OAM (and the way I read the 'special
labels', one key aspect is to convey the Exp information which would
otherwise be lost with PHP......another example that PHP breaks basic arch
principles).

> The issues inherent  in the handling of nested  tunnels are not
> particularly
> MPLS-specific, any tunneling technology  which allows nested tunnels has
> the
> same issues.
	NH=> Absolutley right.  As I said above, for those who wish to learn
please have a look at G.805.  One consequence of this, is that *each* LSPs
is a layer network and that client/server relationships exist when LSP are
nested.