The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Apr> msg00146



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

PHP

  • From: Markus Jork <mjork@avici.com>
  • Date: Thu, 18 Apr 2002 10:37:59 -0400
  • cc: Vach Kompella <vkompella@timetra.com>, David Charlap <David.Charlap@marconi.com>, mpls@UU.NET

> 
> On Wed, 17 Apr 2002, Vach Kompella wrote:
> 
> > So what if they are not "IP packets" but "Ethernet packets" or "Frame Relay
> > packets" in the PWE3 sense of the word.
> 
> Perhaps you are all agreeing, in different ways (not unusual).
> 
> David wrote:
> 
> > Please note that the payload under the shim header is still the IP
> > packet.  Which is why the L3PID should still be 0x0800.
> 
> David's point is, an LSP used to carry IP is signaled with an L3PID of
> 0x0800, no matter what L2 protocol the LSP is carried *over* and no
> matter how deep the label stack is (correct me if I misread you, David).
> 
> However, if an L2 protocol is carried *over* the LSP (e.g., Frame
> Relay over MPLS using draft-martini), then the LSP should not be signaled
> (strictly speaking) with an L3PID of IP.  (Note: the payload under the
> shim header (label stack) is no longer IP.)
> 
> > What do you say is the "ethertype" of the packet with the VC label?
> 
> One could use the convention of "ethertype of 0x8847 means dunno",
> and signal LSPs used for draft-martini with 0x8847.
> 
> Kireeti.
> 

It looks to me as if the L3PID signaling seemed like a good idea at the
time but turned out to be not particularly useful. The problem is that
it is often unknown what type of traffic is carried on an LSP. For
example an RSVP LSP can be used to carry IP traffic and at the same time
also labeled traffic from a targeted LDP session that runs over the RSVP LSP.
The type of traffic underneath the LDP label (either IP or some L2
protocol) cannot be known by the RSVP ingress router. So part of the
traffic across the RSVP LSP is known to be IP, the other part is
unknown. What L3PID is the right one to use? Currently, these LSPs are
signaled with a L3PID of IP.

The L3PID as currently defined in RSVP-TE does not have any practical
value as far as I can tell. Maybe it should be redefined to only
apply to packets with a label stack of 1 while all other packets on
the LSP with label stack > 1 are simply of unknown protocol type.
That way the L3PID is at least useful for the penultimate hop to check
whether it's ok to do PHP.

Markus



  • Follow-Ups:
    • PHP
      • From: Kireeti Kompella <kireeti@juniper.net>
    • PHP
      • From: David Charlap <David.Charlap@marconi.com>
  • References:
    • PHP
      • From: Kireeti Kompella <kireeti@juniper.net>