Subject: RE: PHP negotiation

From: Shahram Davari <[email-masked]>
Date: Wed, 7 Feb 2001 11:14:38 -0800

Hi Thomas,

1)PHP is not as straight forward as it looks. PHP is different from terminating an LSP tunnel, because in PHP you need to route based on top label and then pop that label, while in LSP termination, you need to pop and then route based on lower label or IP header. If the MPLS processing is based on a pure hardware solution, then being able to do LSP termination does not mean that you can do PHP.
2) If the penultimate LSR can't do PHP, it sends a RSVPErr message and the LSP won't be established. So there is no way to receive a non-popped packet for the LSP that PHP was requested for. You either receive a popped  packet for that LSP or you don't receive any packet at all.
3) There is no need to differentiate between penultimate hop popped and non-popped packets. Because the egress always processes the top label, and if the top label indicates a tunnel termination then another lookup must be done. This holds even if an egress LSR randomly asks for PHP.

Yours,
-Shahram

> -----Original Message-----
> From: Huang, Thomas [mailto:[email-masked]]
> Sent: Wednesday, February 07, 2001 1:05 PM
> To: [email-masked]
> Cc: Serge Maskalik; [email-masked]; Bora Akyol; [email-masked]
> Subject: RE: PHP negotiation
> 
> 
> Hello Jane:
> Thanks for your kind msg. I made an error in confusing you. I 
> meant to say
> the egress router sends msg with a null label to a PHP router 
> upstream.
> 
> But your msg still gave useful explanations. 
> 
> I realized that it sounds easy in two lookup scenario you 
> described as well
> as by others when the upstream LSR did not pop the label as requested.
> 
> However, when implementing it, i am not sure about it. Let's 
> assume we have
> only 1 level label. At egress we receive eithter labelled or 
> a l3 packet if
> the previous lsr is capable of popping. The egress router has 
> to program the
> fabric before the data traffic comes. If it's deterministic, 
> the egress can
> be programmed just to do one lookup to forward the l3 packet. 
> Otherwise, at
> least 2 lookups needed...
> 
> I guess it's a matter of efficiency. both rsvp and ldp can signal the
> upstream lsr to do penultimate hop popping. 
> 
> It appears to me PHPoping is not that difficult. Why the spec 
> says a LSR may
> or may not capable of doing it? The harder thing is to do the 
> two lookups if
> the downstream egress lsr does not know if the packet has had 
> its label
> popped..
> 
> /Thomas
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, February 07, 2001 9:33 AM
> To: Huang, Thomas
> Cc: Serge Maskalik; [email-masked]; Bora Akyol; [email-masked]
> Subject: RE: PHP negotiation
> 
> 
> 
> Hi Thomas,
> 
> Actually, RFC3031 implied that the penultimate hop popping 
> should only be
> requested by the LSP egress router, rather than LSP egress router
> responding to a request by its upstream LSP peer.
> At the time egress LSP router receives a packet, it will 
> either have a shim
> header or only the IP header.  If it still have a shim 
> header, by looking
> up the label in the ILM table, it will know whether this router is an
> egress router (As we know the so mentioned egress LSP router 
> is only egress
> relative to the top of the label stack.  After the top label 
> being popped,
> the previous LER is now a regular LSR for the new top label.) 
>  If it is,
> then it means that no PHP has been done and the top label 
> must first been
> popped and a second round of label/IP header lookup needs to 
> be taken care.
> If it is not an egress router, then PHP has been done.    So, 
> it is not
> hard to distinguish whether PHP has been done or not.
> 
> However, not all routers can do penultimate hop popping though it is
> powerful to have penultimate hop popping.
> 
> A signalling mechanism is needed for a LER to ask its 
> upstream LSR to do
> PHP.
> 
> Thanks,
> Jane D. Jiang
> 
> 
> 
> 
> "Huang, Thomas" <[email-masked]>@UU.NET on 
> 02/07/2001 11:34:06
> AM
> 
> Sent by:  [email-masked]
> 
> 
> To:   Serge Maskalik <[email-masked]>, [email-masked]
> cc:   Bora Akyol <[email-masked]>, [email-masked]
> Subject:  RE: PHP negotiation
> 
> 
> Hello Serge:
> I am not sure what you really mean when you say you don't see 
> a need for a
> negotiation mechanism.
> 
> Let's assume the egress responded to a "PHP" lsr with a null 
> label that it
> desires to use. Without some type of signaling back to the 
> egress LSR, how
> does it know if the data packets come later have the labels 
> popped already
> or not and process them.
> 
> Maybe Bora's embedded comment is useful. This PHP knowledge has to be
> passed
> to peers administratively by operators, which is kind of 
> awarkward. After
> all, we have rsvp-te/ldp for signaling. why none of these 
> signaling address
> this issue?
> 
> /Thomas
> 
> -----Original Message-----
> From: Serge Maskalik [mailto:[email-masked]]
> Sent: Monday, January 29, 2001 10:11 AM
> To: [email-masked]
> Cc: Bora Akyol; [email-masked]
> Subject: Re: PHP negotiation
> 
> 
> 
>       Believe it or not, this used to be a major inter-operability
>      problem between two major vendors. One major vendor singalled
>      implicit null for all LSPs, _unless_ it was a single hop LSP
>      in which case the explicit null was signalled to preserve the
>      EXP field. The fact that the other vendor treated label 0 as
>      implicit null did not help either ;)
> 
>       I think most folks would agree that php is a good default
>      behavior. If folks want to do L-LSPs and not have to look at
>      DSCPs for the sake of keeping policies equal across the board
>      or want to maintain the encapsulation to the last hop for other
>      reasons, global or per-LSP configuration options could exist.
> 
>       I do not see a need for a negotiation mechanism.
> 
> 
>      - Serge
> 
> Thus spake [email-masked] ([email-masked]):
> 
> >
> >
> > From:  James Huang@MITEL on 01/24/2001 02:06 PM PST
> > I found in sec 6 of RFC 3036 that PHP negotiation is an 
> area of future
> study for
> > LDP.   Is it also an area of future study for RSVP-TE?  Before this
> negotiation
> > mechanism becomes available,  I presume we can only reply on manual
> > configuration on a per peer basis.
> >
> > -- James Huang
> >
> >
> >
> >
> >
> > Bora Akyol <[email-masked]> on 01/24/2001 12:33:03 PM
> >
> > To:   James Huang/USA/Mitel@Mitel
> > cc:   Bora Akyol <[email-masked]>, [email-masked]
> >
> > Subject:  Re: PHP negotiation
> >
> >
> >
> > There is no such mechanism. The assumption is that the network
> > operator knows how to configure their equipment and they know
> > their network.
> >
> > Bora
> >
> >
> > >>>>> "James" == James Huang <[email-masked]> writes:
> >
> >     James> From: James Huang@MITEL on 01/24/2001 12:03 PM PST Hi
> >     James> Bora: Maybe I did not express my concern clear
> >     James> enough.  As you said, the LSP setup will fail when
> >     James> the egress LSR assigns an Implicit NULL label to the
> >     James> penultimate hop, if the penultinate hop does not
> >     James> support PHP.  So there should be some negotiation
> >     James> mechanism in LDP or RSVP/TE such that an egress
> >     James> router will know not to assign an Implicit NULL label
> >     James> to a penultimate hop that does not support PHP.  But
> >     James> I can not find such mechanism in the documents.
> >
> >     James> -- James Huang
> >
> >
> >
> >
> >
> >     James> Bora Akyol <[email-masked]> on 01/23/2001 08:24:45
> >     James> PM
> >
> >     James> To: James Huang/USA/Mitel@Mitel cc: [email-masked]
> >
> >     James> Subject: PHP negotiation
> >
> >
> >
> >
> >     James> You should also read the label encapsulation
> >     James> RFC. What happens is that the egress LSR assigns an
> >     James> (...) NULL label (I think it should be Implicit Null)
> >     James> to the penultimate hop, if penultimate hop does not
> >     James> support this, then LSP setup should fail.
> >
> >     James> There was a LOOONG discussion on this sometime last
> >     James> year.
> >
> >     James> Some people think this stuff is really clear. I think
> >     James> that it is in about three different RFCs, and someone
> >     James> needs to write a BCP that explains common usage and
> >     James> tricks that network operators that use MPLS should
> >     James> use.
> >
> >     James> BTW, this question comes up about once a month on the
> >     James> list, maybe we should have an MPLS FAQ.
> >
> >     James> Bora
> >
> >
> > >>>>> "James" == James Huang <[email-masked]> writes:
> >
> >     James> Hi all, The following paragraph is from Section
> >     James> 3.16. (Penultimate Hop Popping) of RFC3031.
> >
> >
> >     James> "Initial label distribution protocol negotiations
> >     James> MUST allow each LSR to determine whether its
> >     James> neighboring LSRS are capable of popping the label
> >     James> stack.  A LSR MUST NOT request a label distribution
> >     James> peer to pop the label stack unless it is capable of
> >     James> doing so."
> >
> >     James> However, I can not find any mechanism in LDP/CR-LDP
> >     James> or RSVP-TE to accomplish this PHP negotiation.
> >
> >     James> Am I missing something here?
> >
> >
> >
> >     James> -- James Huang
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
>

---

From: Bora Akyol <[email-masked]>
Date: Wed, 7 Feb 2001 12:33:42 -0800

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.

I think that PHP is a hack that was useful when routers
could not do at least two lookups when doing a POP. I think it
is an architectural mis-feature and hopefully with time, it will be
used less and eventually deprecated.

Bora

---

From: David Melman <[email-masked]>
Date: Thu, 08 Feb 2001 09:19:49 +0200

> complex due to amount of tables, exception cases and remapping.

Bora, can you elaborate a bit on the complexity that you refer to in
implementing PHP in hardware in an MPLS diffserv network?

Thanks,

David