Re: [mpls-linux-general] PHP

[Yon U. <hav...@gm...>]

Hi,

On Thu, 24 Oct 2002, James R. Leu wrote:

> On Wed, Oct 23, 2002 at 11:57:11PM -0700, nitin panjwani wrote:
> > Hi James,
> > Is this implementation of MPLS supports penultimate
> > hop popping or is there way to configure it whatever
> > way we want.
> > Thanks,
> > Nitin
>
> I'm a bit torn as to how to answer this.  Maybe someone out there can
> help me decide what is the correct way to do this.  I have 2 thoughts:
>
> -PHP should be the responsibility of the signaling protocol.  If a
>  protocol receives the implicit null label, it should know not
>  to cross connect to a real label value and instead terminate that level
>  of the LSP.

 That tunnel might not terminate (label stack). This cant even be
controlled (or known) by the signaling protocol (this might be a P-LSR,
which doesnt know what the PE-LSRs have signalled between them).
 Terminating is ok for the simple LDP case, without other signaling
protocols.

> -PHP is controled by the MPLS forwarding plan.  If an outsegment is created
>  with the implicit null label it creates it's instructions in such a way
>  as to not push a label.  During outgoing processing if the packet
>  doesn't have any labels it is sent out the interface as an IP packet
>  without doing a routing lookup.  If it has labels, then it is sent out
>  the interface with out interogating the top level label.  This brings
>  up all sorts of questions though.  Like how to handle EXP and TTL?

 I like this transparency, which avoids having to consider the special
case(s) in the signalling proto to forwarding plane interface.

 I tried this setup (inlabel: POP, FWD -> outlabel: SET (no PUSH)) a few
mpls-linux releases ago, result: the IP packet is forwarded as a MPLS
frame, resulting in garbage (processing of the IP header as an MPLS header
on the receiving side).

 I think a mixed solution could work (considering ip and ipv6):
signaling sets up an inlabel of POP, FWD(outlabel) and an
outlabel of PUSH(null-label), SET(int, nh, proto).

 A 1-label packet will get POPed, and forward to the outlabel->PUSH (which
will be a NOP for the null label(s))  and then the SET, which seeing no
label at all will set the L2-frame protocol to the SET-command proto
parameter and correctly deliver the packet to the (last) nexthop for
correct processing. If the label stack is not empty, the PUSH is NOP again
and the SET seeing a non empty stack forwards the packet as a MPLS
L2-frame, ignoring the proto parameter.

 Summarizing, I suggest:

* adding a default proto for the SET instruction, modifying it to consider
the label-stack depth and modifying the L2-frame protocol field
accordingly.

* modifying the PUSH instruction to do a NOP on null-labels.

 I think this mixed approach is the most comprehensive and on the
least-surprise path for the users.

 Further, it is possible to always do a label XC, which means no need to
change the inlabel on outlabel changes, simplifying implementations. One
can effectively map the LSR-MIB objects 1:1 to the mpls-linux objects:

LSR-MIB  -> mpls-linux
 in-label     in-label POP, FWD (to XC)
 XC           out-label [PUSH,[PUSH,[...]]], FWD(to out-label)
 out-label    out-label [PUSH], SET

This might be not so efficient as doing a single in-label -> out-label XC
in terms of forwarding plane processing time.

It is efficient in change control (and signaling protocol implementation):

 * Multiple (N) in-labels might map to a single XC, changing the XC is a
single operation, not a N operation.

 * A single XC might represent a VRF-label for a remote VRF-route, or a
BGP-label for a super-route (not 2547, but bgp-mpls (rfc 3107)), a LSR
might want to directly switch the LDP labels for those subnets (N) to the
XC. Anyway, FTN-MIB maps FECs to XC-Indexes.

 * An out-label might represent an LDP or RSVP-TE label, which might
change with time (ldp<-->rsvp-te transition for the stacked lsp bottom
label or rsvp-te resignaling after a fault or te-lsp parameter change).

 Well, the mapping is not exactly 1:1, the LSR-MIB label stack object and
XC object are both mapped to a single mpls-linux out-label object

 This approach is efficient for a LSR which is using an out-label for a
remote LSR-ID to do 3 things at once:

1) vanilla LDP LER LSR-ID route/32, (FEC32 -> XC1 -> out-label-1),

2) using the LSR-ID LSP to push labeled VPN-VRF packets on it
(FEC-VRF -> XC2 -> out-label-1), and

3) intermediate LSR for the remote LSR-ID (in-label -> XC1 -> out-label-1)

 In case 1&3 XC1 will be empty (just FWD), in case 2 for each VRF route
there will be different a FEC -> XC tuple and in case 3 the in-label will
be LDP distributed to other peers. In this scenario, doing a switch from
(f.e) LDP to RSVP-TE for the bottom label (out-label-1) could be a single
call to the mpls-linux kernel.

 To get back to the original subject, if the bottom label toggles between
Null and non-Null (direct-link failing and recovering) integrating the
Null-label recognition in the forwarding plane means the signaling
protocol needs not do any acrobatics on potentially a large number of
routes (worst case: BGP full table and a large number of VPN customers).

Hmm, I kept on writing, this is more than the subject was about, oh well.

regards,
 yon