The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

>>>>> "Kireeti" == Kireeti Kompella <kireeti@juniper.net> writes:


    Kireeti> Bora wrote:
    >> I would have to add to this that when you have an MPLS
    >> diffserv network that uses a combination of E and L_LSPs
    >> and PHP is enabled, implementation of PHP in hardware
    >> becomes quite complex due to amount of tables, exception
    >> cases and remapping.

    Kireeti> I don't get it.  What gets harder?  If popping is a
    Kireeti> valid operation, how does it matter to the
    Kireeti> forwarding plane *where* the popping is done, at
    Kireeti> the egress or one hop earlier?

The problem that you face is:

1. PHP node may not have all of the relevant information that it
   needs to so it infers what to do in some cases.

2. Think of the case of an IP
   packet when it emerges after a PHP prior to the ultimate
   tunnel egress and it comes in as an IP packet instead of MPLS
   into the ultimate egress. How is the ultimate egress node
   supposed to treat this packet? If it gets treated as an IP
   packet then you may be misapplying an ingress policy at the
   ultimate hop.

3. Doing PHP at the presence of hierarchical LSPs and MPLS-DS is
   hard (but not impossible) because it requires you to keep too
   much state in hardware and too many possible mapping
   behaviors. Makes the packet processor more complex. 

Again, I am not saying that PHP is impossible to handle but that
it makes life harder and unclear at times. "Unclear" usually
means interoperability problems and that is what worries me.

Bora