The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2002-Jul> msg00099



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: Penultimate Hop Popping

  • From: "Aamer Akhter" <aakhter@cisco.com>
  • Date: Wed, 31 Jul 2002 11:50:56 -0400
  • Resent-Date: Wed, 31 Jul 2002 12:51:47 -0400
  • To: "Hummel Heinrich" <Heinrich.Hummel@icn.siemens.de>, "'roberto'" <roberto_narvaez@yahoo.com>, <mpls-ops@mplsrc.com>

hummel,


----- Original Message -----
From: "Hummel Heinrich" <Heinrich.Hummel@icn.siemens.de>
To: "'roberto'" <roberto_narvaez@yahoo.com>; "Aamer Akhter"
<aakhter@cisco.com>; <mpls-ops@mplsrc.com>
Sent: Wednesday, July 31, 2002 10:54 AM
Subject: AW: [MPLS-OPS]: Penultimate Hop Popping


> There is this fantastic savings due to penultimate label popping: No label
look-up at the egress.
>
> And there is this other fantastic savings due to IPv4-Explicit-Null label:
> No label consumption from th egress node's label space.
> Remember, B.Jensen in Yokohama:" All routers shall learn to handle  the
IPv4-Explicit-Null label" !
>
> But is all of this worth the effort?

which effort, supporting incoming explicit-null or supporting outgoing php? i
think the mpls arch rfc discusses the need for explicit-null and the benefit
of implicit null.

> And is it fair to blame any switch in case it cannot handle these
> top-of-the-art mechanism?
>
> These mechanism will only make sense if there is still an IP-destination
address in the packet header
> at the egress. They won't make sense in case of VoMPLS,etc...

by V i'm guessing you mean VLAN.

in this case there will be at least 2 labels (assuming a multihop path). the
outer label, the so-called IGP/TE label, and the inner L2 VC label. at some
point the outer label has to be ripped off. there are two ways of advertising
this behavior to the upstream neighbor today, php (implicit-null) and explicit
null. there isn't a way in the mpls shim to say don't look at the topmost
label, look at the next one (except for explicit null).


>
> They are a burden for any reasonable OAM-concept. They are a burden for any
other new concept.
> At least,they have to be scrutinized whether they jeopardized these two
important mechanisms.

i don't understand the above paragraph. can you put it in another way?

>
> Wouldn't it be better to give up these two concepts at all ?
>
> Heinrich
>
>
>
>
>
>

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml