Subject: RE: PHP negotiation

From: Shahram Davari <[email-masked]>
Date: Thu, 15 Feb 2001 06:50:56 -0800

Hi Indra,

I should also add that, after a PHP, the egress can not uniquely identify the LSP that the OAM packet belongs to. And that is why we have proposed to duplicate the user-label below the OAM label. If there was no PHP, there was no need to duplicate the user-label label.

Yours,
-Shahram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, February 15, 2001 4:58 AM
> To: [email-masked]; [email-masked]; Shahram
> Davari
> Cc: [email-masked]
> Subject: RE: PHP negotiation
> 
> 
> Hi Indra,
> 
> From a quick analysis I think you are right (Ben and Shahram 
> may wish to
> confirm this).  However,  this is a fortuitous consequence 
> rather than a
> planned one, ie a lack of protocol ID in the normal labelled 
> header forces
> one to create a special bottom-of-stack OAM alert label, and 
> so increase the
> label stack by + 1, thereby fortuitously negating the effect of PHP.
> However, PHP must not be allowed on the OAM alert labelled header.
> 
> Neil
> > -----Original Message-----
> > From: Indra Widjaja [mailto:[email-masked]]
> > Sent: 14 February 2001 21:28
> > To: Ben Mack-Crane
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]
> > Subject: Re: PHP negotiation
> > 
> > 
> > Hi Ben and Neil:
> > 
> > If I may get back to the technical discussion on why PHP 
> > impacts OAM ...
> > 
> > I still don't quite understand how PHP would specifically 
> > break the behavior
> > of your OAM proposal.
> > 
> > Behavior 1: OAM with PHP
> > Penultimate node pops the top label and sends an OAM packet 
> > to the ultimate node.
> > Upon receiving the packet, the ultimate node sees an OAM 
> > alert label and
> > forwards the packet to the local OAM engine for further processing.
> > 
> > Behavior 2: OAM without PHP
> > Penultimate node forwards an OAM packet without popping the 
> top label.
> > Upon receiving the packet, the ultimate node pops the top label.
> > Since the next label indicates an OAM alert label, the packet 
> > is forwarded
> > to the local OAM engine for further processing.
> > 
> > So it looks like the OAM engine will see no difference in the 
> > two behaviors.
> > On the other hand, it would be different if the recently 
> > popped label is saved.
> > Appreciate your clarification.
> > 
> > indra
> > 
> > 
> > Ben Mack-Crane wrote:
> > 
> > > Eric,
> > >
> > > I don't know if one could describe the OAM proposal we're 
> > working on as
> > > a "connection-oriented ITU-like scheme," but I have often 
> > found functional
> > > modeling of layered networks (defined by ITU) useful in 
> > understanding how
> > > networks work (or fail to work) in various configurations.  
> > I have even
> > > found it useful in understanding connectionless networks.
> > >
> > > It seems to me that during its evolution MPLS has developed 
> > two personas.
> > > It has a connectionless persona, exemplified by features 
> > like independent
> > > unsolicited label distribution and PHP.  It also has 
> > developed a connection-
> > > oriented persona with features like LSP tunnels and VPN 
> > applications.
> > >
> > > For cases in which an LSP must have well-defined endpoints 
> > and there is
> > > a need to be able to effectively detect MPLS layer defects 
> > (e.g. mis-merging)
> > > some additional OAM features are needed.  These OAM 
> > features apply to the
> > > MPLS (shim header) packet layer, not to sub-ip layers (for 
> > which similar
> > > OAM features are already defined).
> > >
> > > Regards,
> > > Ben Mack-Crane
> > >
> > > Eric Rosen wrote:
> > > >
> > > > Neil> I  guess  the discussion  above  gave enough  
> > pointers  as  to why  an
> > > > Neil> unambiguous location of the trail termination 
> > function is important
> > > >
> > > > Well, I can say that it  didn't give me a clue.  Repeated 
> > unsupported claims
> > > > that it is "vital" to follow ITU architectures just 
> > aren't very persuasive.
> > > >
> > > > Are  you expecting  to achieve  WG  consensus on  an OAM  
> > proposal?  If  the
> > > > proposal is  an attempt to warp  an IP-based architecture 
> > into  some kind of
> > > > connection-oriented ITU-like scheme,  my guess is that 
> > there  is very little
> > > > chance of achieving consensus.
> > > >
> > > > Actually, I  wonder if the  OAM stuff falls  under the 
> > charter of  the CCAMP
> > > > group rather than the MPLS group.
> > 
>

---

From: Eric Rosen <[email-masked]>
Date: Thu, 15 Feb 2001 10:03:21 -0500

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?  Do you
have a way to tell where the OAM came from?

---

From: Ben Mack-Crane <[email-masked]>
Date: Thu, 15 Feb 2001 09:29:39 -0600

Hello Indra,

I think the real issue here is that one needs to know the user-label for the
LSP over which the OAM packet is received in order to be able to detect
connectivity defects (e.g. mis-merging) and to do performance monitoring.

If the user label is popped before reaching the LSP termination point, the
OAM processor at the termination point has no way of knowing on which LSP
a connectivity verification packet was received.  If the trace ID is wrong,
it is impossible to determine which LSP has the mismerging defect.

Similarly, for performance monitoring the egress must count packets received
on a particular LSP to compare that number with the count in an OAM performance
packet.  If the user-label is PHP'ed, the egress router cannot count packets for
that LSP.

Regards,
Ben

---

From: "Manohar Ellanti" <[email-masked]>
Date: Thu, 15 Feb 2001 19:55:17 -0800

----- Original Message -----
From: "Ben Mack-Crane" <[email-masked]>
.
> packet.  If the user-label is PHP'ed, the egress router cannot count
packets for
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.

-Manohar

---

From: Ben Mack-Crane <[email-masked]>
Date: Thu, 15 Feb 2001 09:34:48 -0600

Eric,

There are some issues with PHP (see my reply to Indra).

We haven't forgotten that LSPs may be multipoint-to-point, but
this case presents some interesting challenges (as you know).

We have not addressed the multipoint-to-point case yet, in favor
of trying to complete a simple and useable OAM for the point-to-point
case.

Regards,
Ben

---

From: "Indra Widjaja" <[email-masked]>
Date: Thu, 15 Feb 2001 11:47:04 -0500

> But it looks very trivial to me that not using PHP feature is a simple way

Manohar:

The issue is not when you have the option to use or not use PHP.
But, when you have to use PHP, would it make OAM impossible to implement.

indra

---

From: "Indra Widjaja" <[email-masked]>
Date: Thu, 15 Feb 2001 11:37:58 -0500

> packet.  If the user-label is PHP'ed, the egress router cannot count packets for

Ben:

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

indra

---

From: Ben Mack-Crane <[email-masked]>
Date: Thu, 15 Feb 2001 11:32:31 -0600

Manohar,

You're right, of course.  I was trying to follow the thread of the
discussion and failed to notice that it had circled around, in a sense.

If the egress LSR supports OAM (i.e., the ability to pop a label header,
recognise the OAM header, and do OAM processing) then it would not need
(or want) to request PHP -- so the question is moot from that perspective.

Regards,
Ben

---

From: Eric Rosen <[email-masked]>
Date: Thu, 15 Feb 2001 13:46:29 -0500

I really hate to keep this thread going, but ...

Ben> If the egress LSR supports OAM (i.e., the ability to pop a label header,
Ben> recognise the OAM header, and do OAM processing) then it would not need
Ben> (or want) to request PHP -- so the question is moot from that perspective.

Well, not  exactly. You don't request  PHP just because you  feel like doing
it, you do it  so that you can provide at high  speed functionality that you
wouldn't otherwise be  able to provide at high  speed.  (However many labels
you can look at at high  speed, there's always a piece of functionality that
requires one more.)  

So if you had an OAM scheme  that depended on the absence of php, you'd have
to choose  which is  more important  to you: supporting  the OAM  scheme, or
providing the additional functionality.