01-18-2006 03:21 PM
In what all scenarios do we disable php..?
Thanks in advance
01-18-2006 03:34 PM
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.
Regards,
Paresh.
01-18-2006 03:39 PM
Hi Paresh,
out of curiosity: have you ever implemented it or seen an implementation because of this?
Regards, Martin
01-18-2006 04:10 PM
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..
Cheers,
Paresh.
01-18-2006 04:29 PM
:-)
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.
Cheers, Martin
01-18-2006 07:27 PM
True :-)
But then, you don't really get an option to disable PHP with cell-based MPLS...
Paresh.
01-18-2006 11:03 PM
True :-)
... 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.
Cheers, Martin
01-19-2006 12:22 AM
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.
01-19-2006 12:30 AM
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.
Paresh.
01-19-2006 01:12 AM
Well he could probably use the 'Pipes" and mark with his EXP on the egress. But true, sounds to far-fetched.
01-19-2006 01:28 AM
Hi,
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 ;-)
cheers,
Stefan
01-19-2006 11:04 PM
hi,
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
Anand
01-20-2006 08:31 AM
Hi,
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).
David
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide