Subject: [Mpls-interop] PHP in MPLS-TP - what is it all about?

From: Loa Andersson <[email-masked]>
Date: Thu, 09 Oct 2008 17:43:05 +0200

All,

ok - this is a mud pool and since no one else seems to be willing
to jump in I might as well be first :)

I want to re-iterate on PHP since one of the central statements
from people saying that we can't use PHP is that we lose the
information of where that packet came from. To my understanding
this wrong.

Admittedly - the PHP mechanisms is designed to work with, or at
least it works best with, a control plane. But whatever a control
plane can do you can also configure manually.

When a label is PHPed there are a few cases.

First the PW case:

The PW label always reaches the edge of the transport network, and
since labels for PWs are assigned by LDP and the LDP session is
established over a TCP session you know exactly where a label for
a PW came from. The PW label is not PHPed. It is the label of the
transport LSP that is PHPed.

The LSP case (or maybe better the RSVP-TE)

When setting up LSPs RSVP-TE operates with certain specific
information that makes it possible to either know the origination
of an LSP. This information is:
LSP IDs and sender IP addresses that gives the information about
where the LSP started/originated.
RFC 3209 also calls this "tunnel id" and "extended tunnel id".

RSVP-TE also indicates the payload type through the GPID.

Based on this it is possible to indicate 3 cases at the penultimate
LSR, all of them rather uncomplicated

1. You are always allowed to pop a label that does not have the bottom
   of stack bit set. For LSPs which you hand out implicit null label
   you will a cross reference between the inner label and the outer
   tunnel (it is in the label request(s).
   This might leave a LFU on top of the stack, so the OAM information
   beneath the needs to carry the LSP ID or tunnel ID to let you know
   the originator.

2. You are also allowed to pop a label if the payload is IP, through
   the source IP address you know where it came from, assuming that you
   know behind which ingress a particular IP address is located.

   There is a border case here, a L3VPN might arrive at the penultimate
   router with a single label and the payload indicated as "IP". But in
   this case the "ultimate" router will not assign the the implicit
   null label, since the label is needed to identify the VPN and through
   the address family it is know that a VPN is set up.

3. You can't PHP a label with the BoS bit set if the payload is
   indicated other than "IP", so the label will reach the egress
   and through the mapping between label and the LSP id / tunnel id
   you know the sender.
   In actual life the decision is taken by the ultimate router, if there
   a reason not do to PHP (the cases above) don't assign the implicit
   null label.

So PHP as defined for MPLS networks works just as well for MPLS-TP.

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                           [email-masked]
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: "BOCCI Matthew" <[email-masked]>
Date: Thu, 9 Oct 2008 18:10:45 +0200

Loa,

I think it's not just a case of where it came from, but also how it got
there. You need to know both the source of a packet, and the LSP it
arrived on at a given LER or PE to know whether a mis-merge has
occurred.

Matthew

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: 09 October 2008 16:43
> To: MEAD team
> Subject: [Mpls-interop] PHP in MPLS-TP - what is it all about?
> 
> All,
> 
> ok - this is a mud pool and since no one else seems to be 
> willing to jump in I might as well be first :)
> 
> I want to re-iterate on PHP since one of the central 
> statements from people saying that we can't use PHP is that 
> we lose the information of where that packet came from. To my 
> understanding this wrong.
> 
> Admittedly - the PHP mechanisms is designed to work with, or 
> at least it works best with, a control plane. But whatever a 
> control plane can do you can also configure manually.
> 
> The PW label always reaches the edge of the transport 
> network, and since labels for PWs are assigned by LDP and the 
> LDP session is established over a TCP session you know 
> exactly where a label for a PW came from. The PW label is not 
> PHPed. It is the label of the transport LSP that is PHPed.
> 
> information that makes it possible to either know the 
> origination of an LSP. This information is:
> LSP IDs and sender IP addresses that gives the information 
> about where the LSP started/originated.
> Based on this it is possible to indicate 3 cases at the 
> penultimate LSR, all of them rather uncomplicated
>

---

From: Loa Andersson <[email-masked]>
Date: Thu, 09 Oct 2008 18:26:21 +0200

Matthew,

> arrived on at a given LER or PE to know whether a mis-merge has

and exactly how does that differ with PHP and non-PHP, even it
the label is PHP, you (the ultimate LSR has the LSPId, as has all
LSR on the path and it is possible to trace it)

exactly how do you use a non-PHP label to decide if a mis-merge
has occured? that label will be the same in both cases - wouldn't
it?

/Loa

-- 
Loa Andersson