Subject: PID in LDP

From: Yakov Rekhter <[email-masked]>
Date: Tue, 13 Feb 2001 11:01:07 -0800

Folks,

Right now we have a situation where RSVP, CR-LDP) have a mechanism (PID) 
to identify an LSP payload, while LDP doesn't have such a mechanism. 

Would there be any objections to add a new TLV to LDP that would
carry the PID information ?

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 13 Feb 2001 12:02:33 -0800

David,

> Yakov Rekhter wrote:
> > 
> > Right now we have a situation where RSVP, CR-LDP) have a mechanism
> > (PID) to identify an LSP payload, while LDP doesn't have such a
> > mechanism.
> 
> Does CR-LDP have such a field?  I was looking for one and didn't find it
> in the draft.

You are correct.

> It would definitely be useful in CR-LDP.

Agreed.

> It would be less useful in LDP, since it could not reasonably be used in
> any unsolicited label distribution mode.

Look at draft-martini-l2circuit-trans-mpls. It specifies unsolicited
downstream mode. And the Virtual Circuit FEC TLV defined in that
Internet Draft carries in its VC Type field the information which is not
that different from what would be carried in the PID. 

Yakov.

---

From: David Charlap <[email-masked]>
Date: Tue, 13 Feb 2001 15:17:18 -0500

Yakov Rekhter wrote:
> 
>> It would be less useful in LDP, since it could not reasonably be used
>> in any unsolicited label distribution mode.
> 
> Internet Draft carries in its VC Type field the information which is
> not that different from what would be carried in the PID.

I understand.  It would certainly be possible to send an L3PID TLV with
label mapping messages in addition to label request messages.

My only concern is that unsolicited label allocation of multiple L3
protocols would quickly lead to an unmanageable number of labels. 
Instead of sending out mappings for every FEC, you're now sending them
out for every legal combination of FEC and L3 protocol.  This could
easily overrun an LSR's capabilities.  Especially if the edge routers
know about a large number of protocols.

Consider also the kinds of non-IP traffic that is likely to exist.

Most will probably be streaming audio/video/whatever protocols, which
will likely require some level of QoS - meaning they'll be signalled
with RSVP-TE or CR-LDP.

The rest will probably be legacy LAN traffic (like NetWare or
AppleTalk), which will probably not be a large percentage of the
network's traffic - resulting in a lot of wasted LSPs if LDP establishes
a full mesh for these protocols.

This is why I said it could not "reasonably" be used.  It could, of
course, be used, but I don't think it would be a good idea.

-- David

---

From: "James R. Leu" <[email-masked]>
Date: Tue, 13 Feb 2001 14:51:39 -0600

> carry the PID information ?

Hello Yakov,

Excuse me if I'm mis-understanding the problem, but doesn't the combination
of FEC element type and address family field of the FEC TLV do this already?
I could see the addition of new FEC element types and, if need be, the usage
of different address families.

> Yakov.

Jim
-- 
James R. Leu

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 13 Feb 2001 13:18:30 -0800

> of FEC element type and address family field of the FEC TLV do this already?

No it doesn't.

> of different address families.

That doesn't solve the problem of identifying the payload of an LSP.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 13 Feb 2001 11:47:46 -0800

> Folks,
> 
> Right now we have a situation where RSVP, CR-LDP have a mechanism (PID) 

I don't think I was correct wrt CR-LDP...

Yakov.

---

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

-- David

---

From: Bob Thomas <[email-masked]>
Date: Wed, 14 Feb 2001 06:55:58 -0500

Yakov,

> carry the PID information ?

Would you give an example of how this TLV would be used?
To evaluate the suggestion that a PID TLV be added it would be
helpful to see how the information carried by the FEC TLV is
insufficient.  (Please note I am asking this question in the
context of LDP not CR-LDP.)

Thanks,
Bob

---

From: Eric Gray <[email-masked]>
Date: Wed, 14 Feb 2001 09:14:33 -0500

Yakov,

    I have to agree with Bob.  In the normal case for LDP,
each hop of an LSP is established for the explicit purpose
of carrying packets associated with a specific FEC.  If
some enterprising individual chooses to use the LSP in
some other way, there is a strong implication of either a
pair of cooperating implementations, or a need to use
CR-LDP.  In either case, there is no need to define any
new TLVs in LDP for this purpose.

--
Eric Gray

---

From: Yangguang Xu <[email-masked]>
Date: Wed, 14 Feb 2001 14:53:11 -0500

Hello,

In the scenario as below:

   -------A------B-----C-------D------E------F-----G----

A,..,G are MPLS capable routers. C and E are FAs. There is a high granularity
LSP between C and E, with LSP/Tunnel ID xxx.  

When A wants to set up another low granularity LSP from A to G, A decides to use
xxx. Assuming these routers are within the same area, what should be in the ERO
/ TLV

1) A (strict), B (strict), C(strict), E(strict), F (strict), G(strict)  

or

2)A (strict), B (strict), C (strict), xxx(?), E(strict), F(strict), G(strict)

Thanks,

Yangguang

---

From: Eric Rosen <[email-masked]>
Date: Thu, 15 Feb 2001 09:58:54 -0500

David> My only concern is that unsolicited label allocation of multiple L3
David> protocols would quickly lead to an unmanageable number of labels. 
David> Instead of sending out mappings for every FEC, you're now sending them
David> out for every legal combination of FEC and L3 protocol.  This could
David> easily overrun an LSR's capabilities.  Especially if the edge routers
David> know about a large number of protocols.

I agree 100%. 

Right  now the  same  "top label"  could  be used  for  carrying regular  IP
traffic,  for carrying  L3VPN  traffic, and  for  carrying emulated  circuit
traffic.   The distinction is  made, as  necessary, after  the top  label is
popped.  It's hard to see what is gained by a scheme that doubles or triples
the number  of labels  used (and the  signalling to distribute  them), while
providing no additional functionality.  

The "VC type"  FEC TLV in draft-martini-... isn't really a  PID; I would say
it  carries  information about  the  kind of  PE-CE  circuit  that is  being
transported, rather than about the payload  of the packets.  The real use of
that is  to indicate  whether some kind  of interworking  function (protocol
translation) is  needed in order to  make the circuit  operational.  I don't
think this could be replaced by a  PID.  For example, the "VC type" might be
used to  indicate that  one side  of a circuit  is PPPoE,  and the  other is
"plain" PPP.  I don't think this could be eliminated in favor of a PID value
associated with the top label.

---

From: David Charlap <[email-masked]>
Date: Thu, 15 Feb 2001 10:28:01 -0500

Eric Rosen wrote:
>> Instead of sending out mappings for every FEC, you're now sending
>> them out for every legal combination of FEC and L3 protocol.  This
>> could easily overrun an LSR's capabilities.  Especially if the edge
>> routers know about a large number of protocols.
> 
> I agree 100%.
> 
> traffic,  for carrying  L3VPN  traffic, and  for  carrying emulated
> circuit traffic.  The distinction is made, as necessary, after the top 
> label is popped.  It's hard to see what is gained by a scheme that
> doubles or triples the number of labels used (and the signalling to
> distribute them), while providing no additional functionality.

Please don't quote my words out of context.  Especially if you're using
them to advocate a position opposite to mine.

My comment about label explosion has nothing to do with whether L3PID is
encoded into a second-level label or via a new TLV.  My concern is with
automatic generation of LSPs for protocols other than IP.  There is no
problem with label explosion if LSPs for non-IP protocols must be
explicitly requested by ingress nodes.

I happen to prefer the situation where the L3PID is signalled during LSP
creation.  It allows the transit routers to know what's inside the LSP. 
The router can therefore pop the last label and forward the traffic
unlabeled, or insert it into a different LSP - an impossibility if there
is a label underneath that is encoding a protocol instead of a
destination.

In section 3.22 of RFC 3031 (MPLS Architecture), a router that doesn't
yet have an NHLFE can choose to pop the label stack if it can forward
the content correctly.  Obviously, knowledge of the L3PID is a
requirement if it is going to be able to do this - otherwise it wouldn't
know where to look for the L3 destination address.

-- David

---

From: Eric Rosen <[email-masked]>
Date: Thu, 15 Feb 2001 11:26:18 -0500

David> Please don't  quote my  words out of  context.  Especially  if you're
David> using them to advocate a position opposite to mine. 

My apologies, I guess I didn't  fully understand you, there was no intention
to misrepresent.

David> There is no problem with label explosion if LSPs for non-IP protocols
David> must be explicitly requested by ingress nodes.

Well,  the PID  would have  to distinguish  VPN IP  packets from  non-VPN IP
packets  as well,  if  you hope  to rely  on  the PID  to determine  whether
intermediate nodes can extract and properly process the payload. 

It seems to me that label explosion occurs whether the LSPs are set up in an
unsolicited  manner or  whether they  are set  up explicitly.   You  must be
assuming  that the  number of  labels  needed to  represent VPN  or layer  2
tunnels is  just a small  fraction of the  total number of labels  per node.
Why would you assume that?

---

From: David Charlap <[email-masked]>
Date: Thu, 15 Feb 2001 11:50:27 -0500

Eric Rosen wrote:
> 
> It seems to me that label explosion occurs whether the LSPs are set up
> in an unsolicited manner or whether they are set up explicitly.  You
> must be assuming that the number of labels needed to represent VPN or
> layer 2 tunnels is just a small fraction of the total number of labels
> per node.

Who said anything about VPN?  You know as well as I do that a private
address is meningless outside of its own network.  If a transient
condition would cause such a packet to hit a router without an NHLFE,
there's no way the packet is going to be forwarded, no matter how it's
encoded.

I explicitly said that a PID field is needed for non-IP traffic.  This
is not an IP packet with a private address being tunneled across a
public network.

There are two uses for non-IP traffic I can think of:

1: Streaming data (like voice).

   It makes sense for media server or media gateway to strip off as
   much overhead as possible (like IP headers) and just send the PCM
   (or MPEG, or H.323, or whatever) stream directly in the LSP.

   A transit router won't be able to forward these packets without the
   labels, since there's no address information in the data stream, but
   it will be able to identify the traffic as something that is not
   routable.

   Of course, this is really not applicable for LDP, but CR-LDP, since
   some level of QoS will be desired for these applications.  I doubt
   customers would be happy if this traffic was treated like all other
   traffic to the destination.

   Yes, DiffServ and the EXP bits can be used, but not everyone is
   going to support DS, and DS may not provide the required
   granularity.  (Imagine 20 different streams, each with a different
   QoS requirement?)

   In this situation, you're not changing the potential for label
   explosion, because a customer in this scenario is going to have to
   be using CR-LDP and L-LSPs anyway.  Tacking on an extra TLV so that
   the content can be identified is not a big deal.

2: Legacy LAN traffic.

   If someone wants to connect two legagy Netware (or Appletalk, etc.)
   servers across the internet, it would be nicer to pass the packets
   in an LSP instead of tunneling them through IP.  A transit router
   may know how to route these.  (Probably not in an ISP core, but
   possibly in an enterprise network.)

   I can't imagine this being a large amount of traffic, however.

-- David

---

From: Eric Gray <[email-masked]>
Date: Thu, 15 Feb 2001 12:37:18 -0500

David,

First:

    I fail to see why you have demonstrated a real need to
tell intermediate LSRs what kind of traffic they are forwarding
on a specific LSP.

    It seems to me that you need only to indicate if the packets
are something that the intermediate LSR might know how to
forward or not.  Since you stipulate that you would only need
to be able to make this distinction when using CR-LDP, then
this is only needed for CR-LDP.

    CR-LDP defines a FEC which carries the meaning you seek.

    So, what else do you need?

Second:

    Have you looked at proposals for transporting compressed
headers over MPLS?  With such an approach, it is difficult to
see what the real advantage is in omitting the IP header when
transporting data via an LSP.

--
Eric GRAY  (please note the last name :-)

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 15 Feb 2001 09:42:08 -0800

Eric,

> this is only needed for CR-LDP.

Please recall the discussion ~1 month ago on the subject of
handling TTL=0 in the "shim" header by the intermediate LSRs.

Yakov.

---

From: David Charlap <[email-masked]>
Date: Thu, 15 Feb 2001 13:02:29 -0500

Eric Gray wrote:
> 
>     I fail to see why you have demonstrated a real need to tell
> intermediate LSRs what kind of traffic they are forwarding on a
> specific LSP.
> 
>     It seems to me that you need only to indicate if the packets are
> something that the intermediate LSR might know how to forward or not.
> Since you stipulate that you would only need to be able to make this
> distinction when using CR-LDP, then this is only needed for CR-LDP.

I stipulate that streaming media applications only make sense over
CR-LDP.

But there is a second category of non-IP traffic, namely legacy LAN
traffic.  While an ISP core network won't be seeing this (except as part
of a VPN connection), an enterprise network might.

In such a situation, merely knowing whether or not the packet can be
routed isn't enough.  The router also has to know what the packet is, so
it can locate appropriate addressing information.

I realize that most MPLS work is focussing on ISP core networks, but you
shouldn't assume that those are the only networks that will ever want to
use it.  An optional TLV to carry L3PID information isn't a big deal.

>     CR-LDP defines a FEC which carries the meaning you seek.

Where?  I just re-read it again and didn't find this.

> Second:
> 
>     Have you looked at proposals for transporting compressed headers
> over MPLS?  With such an approach, it is difficult to see what the
> real advantage is in omitting the IP header when transporting data via
> an LSP.

The means of encapsulating streaming data in an LSP I mentioned is just
an example.  I did not mean to suggest it as the way things should be
done.

-- David

> David Charlap wrote:
>> Eric Rosen wrote:
>>>
>>> It seems to me that label explosion occurs whether the LSPs are set
>>> up in an unsolicited manner or whether they are set up explicitly.
>>> You must be assuming that the number of labels needed to represent
>>> VPN or layer 2 tunnels is just a small fraction of the total number
>>> of labels per node.
>>
>> there's no way the packet is going to be forwarded, no matter how
>> it's encoded.
>>
>> I explicitly said that a PID field is needed for non-IP traffic.
>> This is not an IP packet with a private address being tunneled across
>> a public network.
>>
>>    A transit router won't be able to forward these packets without
>>    the labels, since there's no address information in the data
>>    stream, but it will be able to identify the traffic as something
>>    that is not routable.
>>
>>    Of course, this is really not applicable for LDP, but CR-LDP,
>>    since some level of QoS will be desired for these applications.  I
>>    doubt customers would be happy if this traffic was treated like
>>    all other traffic to the destination.
>>
>>    be using CR-LDP and L-LSPs anyway.  Tacking on an extra TLV so
>>    that the content can be identified is not a big deal.
>>
>> 2: Legacy LAN traffic.
>>
>>    If someone wants to connect two legagy Netware (or Appletalk,
>>    etc.) servers across the internet, it would be nicer to pass the
>>    packets in an LSP instead of tunneling them through IP.  A transit
>>    router may know how to route these.  (Probably not in an ISP core,
>>    but possibly in an enterprise network.)
>>

---

From: Eric Gray <[email-masked]>
Date: Thu, 15 Feb 2001 15:55:16 -0500

Yakov,

    Could you be a little more specific?  I looked through all
of the messages in January and this month and likely ones
from December and while there was a pretty lively chat on
the subject in December and a few light discussions last
month, I could see no direct reference to the issues with
TTL expiry mid-LSP.

    I'd like to do due-diligence in finding this discussion as
I have no real desire to re-ignite it.  But I fail to see how it
is relevant.  If TTL expires, you discard the packet and -
if you would not know how to forward it, that is all you can
do anyway.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 15 Feb 2001 12:56:59 -0800

Eric,

> if you would not know how to forward it, that is all you can

Would you also send ICMP TTL expired ?

Yakov.

---

From: Eric Gray <[email-masked]>
Date: Thu, 15 Feb 2001 16:30:35 -0500

David,

    Wish I could avoid embedding  comments, but please see
below...

> use it.  An optional TLV to carry L3PID information isn't a big deal.

I see at least three issues here:

1) whether or not it makes sense to transport non-IP packets
    using (base) LDP;
2) whether or not it makes sense to use CR-LDP to setup LSPs
    for multiple L3 protocols in an enterprise LAN environment;
3) under what circumstances will it make sense to try to route
    non-IP packets even in an enterprise LAN environment.

I believe one answer could be made to address all of these issues:
simply define a new FEC type for additional L3 protocols.  The
main reason why I would advocate this approach - as opposed
to defining an L3PID TLV, is that it can only make sense for an
intermediate LSR to attempt to route ANY L3 packet if it knows
how to route that L3 packet.  That would imply the analog of a
route table entry for that L3 protocol address in each intermediate
LSR on an LSP intended to carry packets for that L3.

A secondary reason for advocating this approach is that (base)
LDP is fundamentally a hop-by-hop LSP signaling protocol: it
only really makes sense to signal labels between two adjacent
LDP peers if each of them knows how to deal with inserting or
removing packets in the corresponding LSP.

 Obviously, any enterprise routers that do not know how to
route L3 "X" would have to have "X" packets tunneled
through them, either using IP tunneling and LDP, or using
CR-LDP (or RSVP-TE to be fair).

Certainly there is the possibility of adding new FEC types
in an as-yet unwritten RFC.  That's part of what makes
this "MP"LS.

Yes, this approach would be a big deal, but I am not convinced
that merely adding an L3 PID TLV adds any real value.  Even a
no-op is a wasted instruction if it is not needed.

> Where?  I just re-read it again and didn't find this.

CR-LDP only defines one FEC Element type (the others were
previously defined in LDP).  See section 4.10.  I confess that
the meaning "don't expect to be able to route these packets"
is implicit - simply because the FEC type is unspecified -
however, it is possible to use an explicit FEC type and the way
I would interpret an "opaque" FEC type is exactly this way.  I
made this argument several times during the process of getting
the draft to where it is and I am slightly dissappointed not to
find this meaning more explicitly stated.  I certainly recall that
there was agreement that this was implied by the new FEC type.

---

From: Eric Gray <[email-masked]>
Date: Thu, 15 Feb 2001 16:41:38 -0500

Yakov,

    Hmmm.  Thought it might be that.  The answer is that
you would not be likely to be able to send an ICMP error
message to the packet source if you would not be able to
route the original packet - if unexpired - to the packet
destination.

    However, there is a back-doorsy kind of way to send
an ICMP error message to the LSP ingress if the LSP was
established using either CR-LDP or RSVP-TE.  Also, I
am pretty sure that Ron Bonica's efforts to resolve this
little problem in the general tunneling case have not yet
been abandoned.

    And I sure don't see how having an L3 PID identifying
an LSP as having been established to carry non-IP packets
is going to help with this specific problem (therefore the
question on relevancy).

--
Eric Gray

---

From: David Charlap <[email-masked]>
Date: Thu, 15 Feb 2001 16:55:16 -0500

> LSR on an LSP intended to carry packets for that L3.

This would work.

There would still, however, need to be a way to indicate that the data
in the LSP is not the same type as the FEC, however.  This way a transit
router will know not to try and forward a packet that leaves the LSP in
the middle (due to a transient condition).

If the router handles transient conditions by always dropping packets,
this isn't a problem.  If it tries to forward them, it must know what's
inside.  For instance, a raw digitized audio stream may have a packet
where the first 20 bytes resemble an IP header - nevertheless, you
wouldn't want to use those bytes for a forwarding decision.

The main reason for my advocacy of a L3PID TLV is simply because that's
what RSVP-TE already does (it's a field in the LABEL_REQUEST object).

> removing packets in the corresponding LSP.

True.  CR-LDP is tunnel-oriented, but LDP is not.

-- David

---

From: David Charlap <[email-masked]>
Date: Thu, 15 Feb 2001 17:18:41 -0500

[RE: ICMP generation on TTL expiry]

> route the original packet - if unexpired - to the packet

You may have a route to the source, even if you don't have one
to the destination.

> is going to help with this specific problem (therefore the

If the packet is not IP, then the source won't expect or want an ICMP
response.  It might, however, expect something else, depending on what
that L3 protocol is.

If the L3 protocol is unknown, there isn't much it can do.  If it knows
what the protocol is (IP or otherwise), it can generate an appropriate
response (assuming, of course, that the response can be routed back to
the source.)

The mechanism with which it uses to know the protocol doesn't matter, as
long as it knows.

-- David