Subject: RE: PHP negotiation

From: [email-masked]
Date: Thu, 8 Feb 2001 09:32:57 -0000

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 

> -----Original Message-----
> From: Bora Akyol [mailto:[email-masked]]
> Sent: 07 February 2001 20:34
> To: Shahram Davari
> Cc: [email-masked]
> Subject: RE: PHP negotiation
> 
> 
> 
> 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: Kireeti Kompella <[email-masked]>
Date: Tue, 13 Feb 2001 01:56:32 -0800

> sense) is the LSP trail termination point?  This has implications for:

We've had (much of) this discussion before.  The LSP termination point
is the end of the LSP ... simple :-)

The simple way out of this apparent paradox is to distinguish the control
plane from the forwarding plane.  In the control plane, the LSP termination
point is clear.  For example, for RSVP, the LSP end point is the LSR that
doesn't send Path messages.  The fact that PHP is/isn't being used is
completely irrelevant in determining the LSP termination point; PHP is
purely in the forwarding plane.

> -	defect detection

Two ways: a) failure of control plane, b) notification from "lower layers".
Example of (a): loss of Path/Resv message.  Example of (b): Loss of light
from SONET/SDH layer.  Either way, PHP is irrelevant.

> -	server->client layer adapatation

If you mean (for example) IP->MPLS and MPLS->IP, this is forwarding plane
related.  PHP means this gets done one hop earlier.  I don't see an issue
here, though.

> -	performance monitoring

Forwarding plane, so PHP or not has an effect.  This is the one argument
against PHP that I buy.  And perhaps the OAM argument, although I would
have to see the OAM spec first.

> -	protection switching

Control plane.  PHP is irrelevant.

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

I don't get it.  What gets harder?  If popping is a valid operation,
how does it matter to the forwarding plane *where* the popping is done,
at the egress or one hop earlier?

Kireeti.

---

From: Bora Akyol <[email-masked]>
Date: Tue, 13 Feb 2001 07:30:20 -0800

>>>>> "Kireeti" == Kireeti Kompella <[email-masked]> writes:

    Kireeti> Bora wrote:
    >> 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.

    Kireeti> I don't get it.  What gets harder?  If popping is a
    Kireeti> valid operation, how does it matter to the
    Kireeti> forwarding plane *where* the popping is done, at
    Kireeti> the egress or one hop earlier?

The problem that you face is:

1. PHP node may not have all of the relevant information that it
   needs to so it infers what to do in some cases.

2. Think of the case of an IP
   packet when it emerges after a PHP prior to the ultimate
   tunnel egress and it comes in as an IP packet instead of MPLS
   into the ultimate egress. How is the ultimate egress node
   supposed to treat this packet? If it gets treated as an IP
   packet then you may be misapplying an ingress policy at the
   ultimate hop.

3. Doing PHP at the presence of hierarchical LSPs and MPLS-DS is
   hard (but not impossible) because it requires you to keep too
   much state in hardware and too many possible mapping
   behaviors. Makes the packet processor more complex. 

Again, I am not saying that PHP is impossible to handle but that
it makes life harder and unclear at times. "Unclear" usually
means interoperability problems and that is what worries me.

Bora

---

From: David Charlap <[email-masked]>
Date: Tue, 13 Feb 2001 10:58:37 -0500

>    needs to so it infers what to do in some cases.

Maybe.

The penultimate node isn't supposed to look at the next label down (or
underlying IP header).  It's supposed to make its forwarding decision
based on the top label alone.

If, however, the packet in the LSP is not IP, the penultimate node may
not have sufficient information to fill in the correct layer-3 protocol
ID in the layer-2 header.

> 2. Think of the case of an IP packet when it emerges after a PHP prior
>    to the ultimate tunnel egress and it comes in as an IP packet
>    instead of MPLS into the ultimate egress. How is the ultimate
>    egress node supposed to treat this packet? If it gets treated as an
>    IP packet then you may be misapplying an ingress policy at the
>    ultimate hop.

Since it is the ultimate egress router that requests PHP from the
penultimate router, you would assume that it wouldn't do this.  If there
are ingress policies on the interface facing the MPLS cloud, then the
router should be requesting PHP in the first place.

I don't see a problem, since the decision to do PHP, and the
responsibility to deal with the consequences are both in the same
router.

>    behaviors. Makes the packet processor more complex.

Not really.  Labels are supposed to be non-hierarchical.  As long as
uniqueness and scoping rules of RFC 3031 section 3.14 are obeyed, the
egress router will not have a problem.  It will get a packet with a
label, and will forward according to that label.  The fact that the
presence of that label is due to PHP on the previous router shouldn't
affect its forwarding decision at all.  It's still a simple label->NHLFE
mapping, just for a different label.

Of course, if the scoping rules are violated (meaning the label space of
the router that originally did the push is in conflict with the previous
hop router's label space), then the meaning of the label received is
ambiguous.

You can't know if it comes from the previous-hop router's label space or
from the label space of the router that pushed the second-level label. 
If the same label exists in both label spaces, they must be handled
identically in order for anything to work.  But this rule applies
whether or not PHP is used.

> means interoperability problems and that is what worries me.

It seems to me that only your first problem is a real problem.  And even
then, only if the LSP's traffic is non-IP.

-- David

---

From: David Charlap <[email-masked]>
Date: Tue, 13 Feb 2001 11:09:45 -0500

David Charlap wrote:
> penultimate router, you would assume that it wouldn't do this.  If
> there are ingress policies on the interface facing the MPLS cloud,
> then the router should be requesting PHP in the first place.

I mean, of course, "... should _not_ be requesting PHP ..."

-- David

---

From: "Manohar Ellanti" <[email-masked]>
Date: Tue, 13 Feb 2001 21:37:18 -0800

----- Original Message -----
From: "David Charlap" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, February 13, 2001 7:58 AM
Subject: Re: PHP negotiation

> ID in the layer-2 header.

If the the packet in the LSP is not IP, I would like  to know if PHP is
applicable as per the RFC/drafts for L2 transport over MPLS such as FR, ATM,
PPP, Cisco HDLC, VLAN/EtherNet Frame

Assuming, PHP is applicable for IP as well as non-IP payloads then your
concerns regarding protocol ID in the layer  2 header is for the particular
case of   PHop ---- Egress Node link being ethernet. What if the link is PPP
or Cisco HDLC or FR or ATM? There is no or may be different encapsulation
information that the PHOP need to prefix to the payload before transmitting
on the link between PH node and Egress node.

---

From: Eric Rosen <[email-masked]>
Date: Tue, 13 Feb 2001 13:11:44 -0500

Manohar> If the the packet in the LSP is not IP, I would like to know if PHP
Manohar> is applicable as per the RFC/drafts for L2 transport over MPLS such
Manohar> as FR, ATM, PPP, Cisco HDLC, VLAN/EtherNet Frame

The encapsulation  for L2 transport over  MPLS uses two  labels.  The bottom
label must be seen by the egress  node, but the top label is subject to php.
No problem, because  then when the egress node looks at  the packet, it sees
the bottom label, which is just what it needs to see.

---

From: David Charlap <[email-masked]>
Date: Tue, 13 Feb 2001 14:20:32 -0500

Eric Rosen wrote:
>> 
>> If the the packet in the LSP is not IP, I would like to know if PHP
>> is applicable as per the RFC/drafts for L2 transport over MPLS such
>> as FR, ATM, PPP, Cisco HDLC, VLAN/EtherNet Frame
> 
> The encapsulation  for L2 transport over  MPLS uses two labels.  The
> bottom label must be seen by the egress node, but the top label is
> subject to php.  No problem, because  then when the egress node looks
> at the packet, it sees the bottom label, which is just what it needs
> to see.

Note that this is different from transporting a non-IP L3 packet.

While the two-label mechanism can work, it is may also possible to use a
single label.  When RSVP-TE is used, an ingress router provides the
ethertype of the L3 protocol in the label-request object.  So every
router knows what's underneath the label.

If the penultimate router's outgoing interface can support sending the
L3 protocol without a label, and the egress router can receive said
unlabeled packet, then PHP can work with only one label on the stack. 
The first condition is something the penultimate router should know on
its own.  The second condition is something the egress router will know,
and should consider before requesting PHP.

I think all the popular interface types support non-IP L3 protocols:

- Ethernet and those protocols that emulate ethernet have a protocol
  field.  802.3 has the protocol in the LLC/SNAP field
- PPP has a protocol field, although it's not the same as ethertypes
- ATM uses SNAP for RFC-2684 (formerly 1483) VCs.
- Frame Relay uses SNAP for RFC-2427-formatted VCs

I'm unfamiliar with HDLC, but I'd be surprised if it didn't also have a
protocol-ID field in the header somewhere.

-- David