When you do PHP, you lose any EXP markings on that label. The use of explicit null label helps to preserve the EXP bits until the packets reach their final destination...
Hope that helps - pls rate the post if it does.
To be honest, no :-)
It's just an idea that has been bandied around...But most of the networks I have worked on do not re-mark the EXP bits within the core anyway, so it's really a moot issue for them.
But I guess it's there if you need it, I suppose..
ok I got a reason: you do not perform php in a cell-based MPLS environment, simply because it is not possible. Removing ATM cell headers is just not possible.... ;-)
Hope this counts as a reasonable cause.
... but not quite my point ;-)
you disable php by moving from GE and POS to ATM and use cell-based MPLS! *g*
Hope this helps! Please rate all posts.
Just thinking of scenarios, it may be needed if you wanted the top EXP bits to be preserved if the packet has come across an NNI (as in a Option B Interconnect). The bottom label would probably have the other SP's label. just an idea though.
Yeah, but even then, when the SP with the bottom level gets the packet, it will just discard the explicit null label and not do anything.. So it does not really buy you anything in this case.
you could capture the value of the EXP bits in the topmost label by mapping it to a QOS group on the ingress interface. This happens before the label is discarded. On the outgoing interface you can then setup QoS policies based on the QOS group instead of the EXP bits of the bottom label if that's what you want. Normally it isn't I guess ;-)
I find below is the valid reason where u need to do disable php,like if the penultimate LSR is an ATM switch, it may not have the capability to pop the label stack. Hence a binding of Implicit NULL may be distributed only to LSRs which can support that function.
hope this helps
Another thought on this might be when you are using one-hop LSPs, most likely in MPLS-TE environment. It would really depend on things you want to accomplish, but not having the option of explicit-null value, rules out any scenario of matching on EXP value, since no label will be applied in the first place (one-hop LSPs).