Subject: RE: PHP

From: [email-masked]
Date: Thu, 18 Apr 2002 20:35:44 +0100

David Charlap wrote18 April 2002 16:33
> 
> Markus Jork wrote:
> > 
> > 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 L3PID of the inner LSP is known, because it is signaled as IP.
> 
> The ingress router for the inner LSP also knows the L3PID of the outer
> LSP, since it must participate in the signaling for the outer LSP.
> 
> I would argue that it should not shunt incompatible traffic into that
> LSP.  Don't allow a non-IP LSP to tunnel through an IP-LSP.
> 
> If the inner LSP is meant to carry traffic of many different 
> types, then
> it should be signaled as such.  With an L3PID meaning 
> "unknown".  Which
> would mean, of course, that the egress of such an LSP would 
> not be able
> to handle a packet that only has one label - since it won't know the
> actual L3PID after popping that last label.  But this would be OK, if
> there's another label on the stack - either indicating an outer LSP to
> use for forwarding, or indicating the L2/L3 PID.
> 
> Of course, the whole argument falls apart when you realize 
> that the two
> LSPs (inner and outer) don't both have to be RSVP.  I don't 
> think L3PID
> is signaled with LDP or CR-LDP.
NH=> Can I just check something here David.....in the martini-trans ID I
believe only LDP is allowed for signalling XoverMPLS LSPs.  If so, then how
can we signal the payload 'X' of the LSP for such XoverMPLS cases?  I always
assumed that the 'multiprotocol' aspects would be taken care of by label
semantics in lieu of no PID field in the MPLS header.  So am I right one
cannot signal this and only configure it?  And why is RSVP-TE say prohibited
for the setting up the inner LSP?  Any enlightenment/corrections would be
much appreciated.

regards, Neil

---

From: David Charlap <[email-masked]>
Date: Thu, 18 Apr 2002 15:55:21 -0400

[email-masked] wrote:
> 
> Can I just check something here David.....in the martini-trans ID
> I believe only LDP is allowed for signalling XoverMPLS LSPs.  If
> so, then how can we signal the payload 'X' of the LSP for such
> XoverMPLS cases?  I always assumed that the 'multiprotocol' aspects
> would be taken care of by label semantics in lieu of no PID field
> in the MPLS header.

That would be correct.

> So am I right one cannot signal this and only configure it?

I don't know of any way to signal an association between these labels
and the protocols they represent.  If they're not pre-defined by
standards, they will have to be configured.

> And why is RSVP-TE say prohibited for the setting up the inner
> LSP?

It's not.

But the inner LSP isn't going to be able to know a-priority that it will
only be used for tunneling other LSPs through it.  It will have to be
able to correctly de-encapsulate a packat that arrives at the egress
node with only one label on it.  In RSVP-TE, the L3PID field in the
LABEL_REQUEST tells it how to do this.  If you signal the LSP with
something that the egress switch can't de-encapsulate, the LSP will
probably be rejected.

If you know that the egress switch will never receive a one-label packet
(which is beyond the scope of signaling protocols), then you can simply
set up the inner LSP as an IP tunnel.  Now, it will behave the way LDP
does - requiring that a protocol-identifying label be at the bottom of
the label stack.

In LDP, it is assumed that this packet must be IP, so the problem never
comes up.  Anything that's not IP must have a second protocol-
identifying label on the stack.

-- David

---

From: Eric Rosen <[email-masked]>
Date: Thu, 18 Apr 2002 16:00:48 -0400

Neil> in the martini-trans  ID I believe only LDP  is allowed for signalling
Neil> XoverMPLS LSPs.  If so, then how  can we signal the payload 'X' of the
Neil> LSP for such XoverMPLS cases? 

Martini signaling (using LDP) does signal the X, it's the VC type (i.e. it's
part of the FEC).  

But the  fact that a particular Martini  LSP is carrying protocol  X is only
known at the two endpoints of that  LSP.  An RSVP-TE tunnel whose head is at
some arbitrary place in the network will not know this. 

Neil> I always assumed that the  'multiprotocol' aspects would be taken care
Neil> of by label semantics in lieu of no PID field in the MPLS header. 

Yes, when a packet is within a  tunnel, you may not be able to determine the
payload type by  examining the header.  If it is a  Martini packet, you need
to get to  the node that assigned the bottom label  before you can determine
the payload type.

---

From: hginjpal <[email-masked]>
Date: Thu, 18 Apr 2002 13:54:42 -0700

UNSUBSCRI BE