Subject: RE: PHP negotiation

From: "Huang, Thomas" <[email-masked]>
Date: Wed, 7 Feb 2001 08:34:06 -0800

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: "Huang, Thomas" <[email-masked]>
Date: Wed, 7 Feb 2001 10:04:31 -0800

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:

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

     - Serge

study for
negotiation

---

From: [email-masked]
Date: Wed, 7 Feb 2001 14:16:59 -0500

Hi Thomas,

I understand the problem you mentioned when PHP is not deterministic.  The
LER has to be prepared to deal with both situations, with or without a
label.  If you think that is too much for your LER, you can decide just not
to ask for PHP across the platform.  That is what we can be sure.

PHP cannot always be done.  In case of IP/ATM, the labels are carried in
the VPI/VCI field of the ATM header.  ATM switches cannot remove the ATM
header to pass the IP packet to the LER.  Sometimes, processing speed at
one router can be a concern that prevent it from peeling off one label
layer.  So, requiring all routers be capable of doing PHP is not possible.

LER will only do two lookups if PHP is not done and LER will know whether
two lookups is needed when it does the first one(if there is a label).
Session 3.16 of RFC3031 gives the detail.

Regards,
Jane

"Huang, Thomas" <[email-masked]> on 02/07/2001 01:04:31 PM

To:   [email-masked]
cc:   Serge Maskalik <[email-masked]>, [email-masked], Bora Akyol
       <[email-masked]>, [email-masked]
Subject:  RE: PHP negotiation

Hello Jane:

the previous lsr is capable of popping. The egress router has to program
the

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,

Thanks,
Jane D. Jiang

Hello Serge:

/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

     - Serge

study for
negotiation

---

From: [email-masked]
Date: Wed, 7 Feb 2001 12:32:43 -0500

Hi Thomas,

Thanks,
Jane D. Jiang

Hello Serge:

/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

     - Serge

study for
negotiation

---

From: "Huang, Thomas" <[email-masked]>
Date: Fri, 9 Feb 2001 09:38:27 -0800

Bora and Neil:
I would agree too. This entire PHP notion is not architecturally necessary. 

I studied Neil's oam document and the PHP would not help in terimating oam
signals.

/Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 08, 2001 1:33 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: PHP negotiation

I agree Bora....if you allow PHP, then where (in a functional architecture
sense) is the LSP trail termination point?  This has implications for:
-	defect detection
-	server->client layer adapatation
-	performance monitoring
-	protection switching

neil 

> From: Bora Akyol [mailto:[email-masked]]
> Sent: 07 February 2001 20:34
> To: Shahram Davari
> Cc: [email-masked]
> 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: [email-masked]
Date: Thu, 15 Feb 2001 16:27:29 -0000

Manohar Ellanti [mailto:[email-masked]] wrote on 16 February 2001 03:55
>
> PHP is signaled by the ultimate/egress node to the 
> penultimate node. If OAM
> requires that per LSP work is to be done at the egress node 
> and so one needs
> the top label to demultiplex at the egress node, why should 
> one think of
> enabling PHP? Isn't  this egress initiated PHP negotiation. 
> If the egress
> itself doesn't want penultimate node to pop the top level, 
> then why in the
> first place initiate the PHP negotiation? May be I missed 
> some discussion.
> But it looks very trivial to me that not using PHP feature is 
> a simple way
> of out this.
> 
NH=> Yes it is......this is the obvious solution.  Alternatively, and as
Shahram pointed out, if we capture the orginal source 4 octet labelled
header in the OAM payload (or the CV or P pkt) then we can still make the
association.

---

From: [email-masked]
Date: Thu, 15 Feb 2001 16:27:30 -0000

Eric Rosen [mailto:[email-masked]] wrote on 15 February 2001 15:03
> 
> So PHP doesn't make OAM impossible after all!  I guess I'm 
> not surprised.
> Shahram> after a PHP, the egress can  not uniquely identify 
> the LSP that the
> Shahram> OAM packet belongs to.
> 
> You haven't forgotten  that LSPs are multipoint-to-point, 
> have  you?
NH=> The scope of the work is targetted at important LSPs that are pt-pt,
usually set-up via ER signalling.  So the work is not targeted at plain LDP
LSPs....however, if you/Cisco have some possible OAM solutions here Eric I
would be very happy to review them for you.  

>Do you have a way to tell where the OAM came from?
NH=> In our case yes...its the Trail Termination Source Identifier, which is
composed of a source LSR address + a tunnel ID.  What do you/Cisco do here
(for both pt-pt case and the mpt-pt case)?

---

From: [email-masked]
Date: Thu, 15 Feb 2001 17:50:05 -0000

> If you meant that the egress router needs to count *user* 
> packets for that LSP,
> then I agree that PHP must be avoided.
> 
> indra
> 

Indra....look at the details on P flows I sent you.  Further, Shahram has
extended the basic ideas in a good survey of variations on the basic P flow
theme.....we need to choose one though yet.

Note - when I originally proposed the P flow it was as a simple 1st line
diagnostic tool for Ops people and not a full-blown QoS metric analysis
tool;  and as currently envisaged, it simply counts the (cummulative) lost
pkts/octets over some period T.  So it would be used in ad hoc mode as an
adjunct to the basic (defect detection/handling) CV flow as/when needed, but
not full time......its costs to measure/collect metrics, so you should only
do it when needed.  In any network one needs at least 4 types of perf
measures:
-	simple OAM to aid Ops people and to protect customers traffic, eg
security issues.....key in-service metric is availability, QoS are metrics
are dependent on getting availability stuff right 1st;
-	ad hoc sampling of detailed QoS metrics, eg using probes, to get a
feel for the population behaviour/trends and to detect otherwise latent
faults;
-	nodal/link utilisation trends, eg for TE and inputs to
planning/design cycle;
-	UPC discard/re-classification activity
Our work clearly only addresses the 1st of these items.

As regards packet/octet loss metrics however, these could also be counted by
doing so at both ingress and egress (ie no need for P flow....a P flow just
allows this to be done at one end, the sink).  There are some inaccuracy
issues with 'pkts in flight' and the synchronisation of the 2 ends (ie so
they relate to the same T period).  However, as T->large these inaccuracies
will decrease as a %.

As regards the PHP issue wrt P flows.....we are still OK for the reason
Shahram pointed out a few mails back, since we intend to put the orginal 4
octet labelled header (ie outgoing from the LSP source LSR) in both CV and P
OAM pkt payloads.  So, fortuitously rather than by design (due to need for 2
label stacking forced by having no protocol ID field), we can actually
identify which LSP the P flow should be associated with even with PHP (of
top label only).

neil

---

From: Shahram Davari <[email-masked]>
Date: Fri, 16 Feb 2001 07:12:54 -0800

Hi Eric,

I forgot to mention that duplicating the original user-label under the OAM label, is not a good enough solution for PHP case. The reasons are:

1) The Performance packets could be identified uniquely, but the user data packets can't. Because we can't duplicate the user label in user data packets. So basically LSP QoS measurements can't be done with PHP.

2) The Connectivity verification packets could be uniquely identified, but in case of mis-merging or mis-routing it would be very difficult to track the problem, because we don't know from which LSP the CV packets are arriving.

Yours,
-Shahram  

> From: Eric Rosen [mailto:[email-masked]]
> Sent: Thursday, February 15, 2001 10:03 AM
> To: Shahram Davari
> Cc: [email-masked]'; [email-masked];
> [email-masked]; [email-masked]
> have  you?  Do you
> have a way to tell where the OAM came from? 
>