Subject: RE: MPLS and fragmentation..

From: "Wilder, David" <[email-masked]>
Date: Mon, 4 Dec 2000 15:02:20 -0500

This is true; IP fragmentation is done by IP before entering the MPLS
domain.  However,  there are case where adding the 4 byte label is going to
cause the packet to now exceed the max mtu size.  Then  one must look at how
to handle that situation i.e. fragment, discard or do nothing.

Dave

-----Original Message-----
From: Faisal S. Naik [mailto:[email-masked]]
Sent: Monday, December 04, 2000 2:08 PM
To: mpls uunet
Cc: [email-masked]
Subject: Re: MPLS and fragmentation..

hello soumen,
Isnt this Ip fragmentation a part of the router before the packet enters the
MPLS domain. Within the domain, there is only the label swapping mechanism
that is working, with nothing to mention about the fragmentation part.
Esp in cases of IPv6 fragmentation is not at all allowed, for exceptional
cases, extended headers of IPv6 are used.
Am i right Nisar saheb :)
Regards,
Faisal Naik

---

From: David Charlap <[email-masked]>
Date: Mon, 04 Dec 2000 15:15:04 -0500

"Wilder, David" wrote:
> domain.  However,  there are case where adding the 4 byte label is
> going to cause the packet to now exceed the max mtu size.  Then  one
> must look at how to handle that situation i.e. fragment, discard or do
> nothing.

I don't see what the problem is here.  If the ingress router knows the
MTU for the entire path (as it must, if it is going to fragment
packets), then it should not be a big deal to subtract a constant value
from the computed MTU (to accomodate the label header) and fragment to
that value instead.

-- David

---

From: Ben Black <[email-masked]>
Date: Mon, 4 Dec 2000 12:06:38 -0800

it is not possible to exceed the MTU (hence the name).  the MTU
for a path will be less than the MTU of the media carrying the path.
exactly how much less depends on how many labels are stacked, how
the encapsulation for a given media is implemented, etc.  however,
once an LSP is established, its MTU *should* be known (barring
oddities when the LSP MTU changes during a failure or other
re-routing event).

so, faisal is correct: all fragmentation should occur outside the MPLS
domain.  

ben

---

From: "James R. Leu" <[email-masked]>
Date: Mon, 4 Dec 2000 16:04:08 -0600

Hello,

See my comments at the bottom.

> from the computed MTU (to accomodate the label header) and fragment to

As David said, the key is that you need to know the MTU of the LSP at the
ingress.  RSVP-TE added a sub object that is used to "calculate" the MTU of
the LSP.  (it was added just before the Pittsburgh IETF)

LDP (CR-LDP) does not have this feature.  I'm not sure if the authors of
either the LDP or CR-LDP drafts have plans to add it, or if they even believe
it is needed.

Jim
-- 
James R. Leu

---

From: David Charlap <[email-masked]>
Date: Mon, 04 Dec 2000 17:32:49 -0500

Ben Black wrote:
> 
> i'd be quite interested in how an IP network would function correctly
> when routers do not know the MTU for a link.  would the edge devices
> learn the LSP MTU through another protocol?

The problem isn't for a link - it's for an LSP.

Of course a router must know the MTU for directly-attached links.  But
an LSP-ingress router must know the MTU for the entire LSP - that is,
the lowest MTU of all the links that the LSP traverses.

This is not something tnat traditional IP routers normally keep track of
unless they're running some kind of QoS-signalling protocol like RSVP.

-- David

---

From: David Charlap <[email-masked]>
Date: Mon, 04 Dec 2000 17:41:51 -0500

"James R. Leu" wrote:
> 
> As David said, the key is that you need to know the MTU of the LSP at
> the ingress.  RSVP-TE added a sub object that is used to "calculate"
> the MTU of the LSP.  (it was added just before the Pittsburgh IETF)

Actually, a mechanism for this has always been present.  RSVP-TE simply
added a second mechanism.

The Class-Of-Service CType for TSPEC and FLOWSPEC include MTU fields. 
The one in the TSPEC is clipped to the interface's MTU as the Path
message progresses through the network.  The one in the FLOWSPEC is
validated against each link as the Resv message comes back.

Before this was invented, this capability was achieved via the ADSPEC
object.  It also contains an MTU field, which is clipped as the Path
message propages through the network.  The value is then returned using
the FLOWSPEC back to the ingress router.

> LDP (CR-LDP) does not have this feature.  I'm not sure if the authors
> of either the LDP or CR-LDP drafts have plans to add it, or if they
> even believe it is needed.

I'm surprised.  Given the need for ingress routers to fragment packets
on behalf of the entire LSP, there must be a mechanism somewhere to
determine what value everything should be fragmented to.

-- David

---

From: Hendrik Visage <[email-masked]>
Date: Tue, 5 Dec 2000 13:34:45 +0200

> MTU for the entire path (as it must, if it is going to fragment

The problem starts with some very famous (but perhaps lesser loved by
the techies) OSes that doesn't do the Path MTU discovery correctly,
which then get's totally confused, and we are having another set of problems
to debug with the clients that were promised a pink sun, purple moons and
stars with a dash of green....

> from the computed MTU (to accomodate the label header) and fragment to

And then the famous OS just goes west, after giving the client a set of fingers
to choose from...

It's a serious issue for us, where we've seen IPSec and other tunnel solutions
giving more trouble than what's it worth.

And BTW, have I yet mentioned the impact this might have on transparent caching
solutions that ISPs have in place??

Greetz
Hendrik

-- 
------------------------
Hendrik Visage
[email-masked]

---

From: Ben Black <[email-masked]>
Date: Mon, 4 Dec 2000 14:02:14 -0800

> either the LDP or CR-LDP drafts have plans to add it, or if they even believe

i'd be quite interested in how an IP network would function correctly when
routers do not know the MTU for a link.  would the edge devices learn the
LSP MTU through another protocol?  

ben

---

From: Ben Black <[email-masked]>
Date: Mon, 4 Dec 2000 14:34:07 -0800

> determine what value everything should be fragmented to.

exactly.  i believe we are now on the same page.

ben

---

From: Ben Black <[email-masked]>
Date: Mon, 4 Dec 2000 14:27:59 -0800

as far as the router is concerned, the LSP *is* the link, and
that was the intent of my statement.  if the router attached
the one end of an LSP wishes to forward traffic over that LSP,
it must know the MTU for that LSP unless fragmentation is to
be performed by intermediate LSRs.

ben

---

From: David Charlap <[email-masked]>
Date: Tue, 05 Dec 2000 11:00:50 -0500

Hendrik Visage wrote:
> David Charlap wrote:
>> "Wilder, David" wrote:
>>>
>>> This is true; IP fragmentation is done by IP before entering the
>>> MPLS domain.  However,  there are case where adding the 4 byte label
>>> is going to cause the packet to now exceed the max mtu size.  Then
>>> one must look at how to handle that situation i.e. fragment, discard
>>> or do nothing.
>>
>> I don't see what the problem is here.  If the ingress router knows
>> the MTU for the entire path (as it must, if it is going to fragment
> 

This is irrelevant.  PMTU Discovery is not used in LSP setup.

Once the LSP is established, the ingress router should fragment packets
that are too large (or reject them if the DF bit is set.)

> which then get's totally confused, and we are having another set of
> problems to debug with the clients that were promised a pink sun,
> purple moons and stars with a dash of green....

This is the exact same problem you have without MPLS.  The only thing
that might possible change is the IP address of the router that's
dropping the non-compliant packets.

I'm sorry if you were under the impression that MPLS will eliminate the
needs for clients to have a clue about MTU values.  It was never
intended to do a thing about that problem, and it does not.

>> packets), then it should not be a big deal to subtract a constant
>> value from the computed MTU (to accomodate the label header) and
>> fragment to that value instead.
> 
> And then the famous OS just goes west, after giving the client a set
> of fingers to choose from...

What the heck are you talking about?

If your client has a broken MTU discovery, it will remain broken with or
without MPLS running in the core of the network.

> It's a serious issue for us, where we've seen IPSec and other tunnel
> solutions giving more trouble than what's it worth.
> 
> And BTW, have I yet mentioned the impact this might have on
> transparent caching solutions that ISPs have in place??

If you want to discuss something other than MPLS, please take it to
another list.

-- David

---

From: Ben Black <[email-masked]>
Date: Tue, 5 Dec 2000 10:20:20 -0800

> stars with a dash of green....

path mtu detection is not relevant how endpoints of an LSP determine
the mtu of that LSP.

ben
-- 
what great thing would you attempt if you knew you could not fail?

---

From: Hendrik Visage <[email-masked]>
Date: Wed, 6 Dec 2000 06:56:29 +0200

> This is irrelevant.  PMTU Discovery is not used in LSP setup.

Which I do agree with.
The problem that I thought was asked, and which we would like to see
if or how it will/might be addressed, or if it's just ignored.

I actually wasn't thinking about the setup of the MTU size (which I assumed
to be transparently done by MPLS...) however, I was more interested to
know if MPLS would somehow present a solution in the cases where the DF bit
is set, and the packet is just little bigger than the MTU by the size of the
MPLS labels... This will be an issue if it's not provided, especially with the
people using those famous OSes that doesn't do the correct PMTU :(

> intended to do a thing about that problem, and it does not.

I wasn't, as I also think the initial questioneer wasn't, we just wanted to
know if/how it will/might be addressed, or just ignored...

> without MPLS running in the core of the network.

Thanx, which is the case with some of the famous OSes :(

> If you want to discuss something other than MPLS, please take it to

See it in the context of the PMTU discovery that's semi broken on certain 
OSes...

> -- David

Hope it calmed you.

-- 
------------------------
Hendrik Visage
[email-masked]

---

From: Steve Elias <[email-masked]>
Date: 12 Dec 2000 09:15:03 -0500

hello,

indeed it is nice and is preferred that fragmentation occur outside
the mpls domain.  but that's not always possible or reasonable in 
real networks.

so within the mpls domain, and especially at the step where an ip
packet is converted to mpls, it is quite possible and sometimes quite
crucial to exceed the MTU.  for example, this is reasonable on
ethernets on which there are only two (or a few) nodes present and for
which the wire is not too close to the maximum length as determined by
the medium's propagation speed and the collision-detect portion of the
ethernet timing specification.

yes, this sort of thing violates a variety of standards.  
but it solves customer problems.  

as long as the router does not default to being able to violate the
MTU or an MPLS fragmentation specification, i say that it is a Good
Thing for customers to be able to configure the router it to do so.

for example, in the simplest case, to send a 1504
byte "baby giant" packet over a ethernet...

regards,

steve elias
ios network protocols
cisco systems

---

From: Ben Black <[email-masked]>
Date: Tue, 12 Dec 2000 08:21:32 -0800

are you saying that LDP need not include an MTU communication
mechanism because, on rare occassions, it is expedient to
violate accepted specifications?

ben

---

From: Steve Elias <[email-masked]>
Date: 12 Dec 2000 13:48:57 -0500

hi Ben,

no i am not saying that.

to the contrary, i can imagine that an MTU communication mechanism in
LDP could solve MTU-related problems inside an MPLS cloud, thus
avoiding fragmentation within the cloud.  such a mechanism could
operate just as well in an MPLS cloud with some nodes' interfaces
configured to exceed the 'original' MTU standards.

i'm not aware of any such fragmentation problems in real world MPLS
clouds yet, but it seems reasonable to me to expect that sooner or
later this issue would become important for some MPLS customers.

thank you,

steve elias

---

From: Serge Maskalik <[email-masked]>
Date: Tue, 12 Dec 2000 17:00:57 -0800

Comments in-line.

> configured to exceed the 'original' MTU standards.

   From the TE perspective, the LSPs are introduced into the IGP as 
  shortcuts or virtual links. If the ingress LSR is made aware of 
  the tunnel MTU, which would be exactly the smallest link MTU in
  the path, fragmentation can be done before traffic enters the 
  MPLS domain. IMO, fragmentation is significantly more complex
  when it is to be handled by a mid-point for the following reasons:

   1. LSR has no way to know what network layer protocol is 
      label-switched.

   2. Even if the LSR is aware of the underlying network layer
      protocol, what must it do? De-capsulate, fragment and 
      then encapsulate the fragments with identical label 
      headers? Does not sound like an efficient operation. 

   Existing mechanisms in RSVP-TE should be utilized for this 
  purpose. I would like to see feedback from authors of CR-LDP 
  in w/r/t to this. 

> later this issue would become important for some MPLS customers.

    A good example of such problem could be witnessed in many SP 
  architectures that use ethernet switch fabrics to make all core 
  and edge devices adjacent within a PoP. Various switch vendors 
  are not on the same page as far what is the max frame size they
  support, example - one platform does not support anything larger 
  than 802.3 header which may include 802.1q tag (in this case, 
  no label encapsulation is possible), another platform support
  frames up to 9k in size, but the forwarding is done via slow-
  path; third example is vendor which has an asic limitiation 
  which forces the max frame size of 1536 (which allows for a 
  stack three deep after subtracting 802.3 header). 

   Targeted MPLS deployments in SP networks that have provide for
  RFC2547 and L2 MPLS-based VPNs plus TE require support of label 
  stack of at least three labels (underlying RSVP-TE, LDP and VPN 
  labels). Other architecture may have a need for a deeper stack.  

	- Serge

---

From: "Andre N. Fredette" <[email-masked]>
Date: Wed, 13 Dec 2000 13:38:45 -0500

LDP, and therefore CR-LDP, does not provide an LSP MTU discovery 
mechanism.  The thinking (perhaps flawed) was that:

(a) Fragmentation is not usually an issue in the core of the network due to 
the large MTUs on typical interfaces, and

(b) If it is an issue in a particular domain, the MTU can be configured on 
the MPLS edge routers.  Note, I am aware that this is somewhat problematic 
because the MTU is not necessarily related to the local router, but is the 
minimum of all MTUs in the MPLS domain.

LDP and CR-LDPs are due to be released as RFCs in the next couple of weeks 
and I don't think this is serious enough to hold them back.

I'd be happy to write an extension to LDP for MTU discovery if people think 
it is necessary.

Andre

At 05:00 PM 12/12/2000 -0800, Serge Maskalik wrote:

[comments regarding MTU fragmentation deleted]

---

From: Ben Black <[email-masked]>
Date: Wed, 13 Dec 2000 14:21:41 -0800

> minimum of all MTUs in the MPLS domain.

It is exactly for reason (b) above that this must be in the draft (one
would hope before they move to RFCs).  Although it is often the case that
the core MTU is larger than the edge MTU, this is not always the case
and may not stay the case (for example, consider jumbo frames from gigabit
ethernet edge devices pushing packets which must be sent across POS links
with an MTU half the size (9216 vs 4470).  I am rather surprised that
this issue was not raised earlier, but now that it has been, it should
be addressed promptly.

ben

---

From: Eric Gray <[email-masked]>
Date: Thu, 14 Dec 2000 13:38:34 -0500

Ben,

        I disagree with your assertion that this is a good
reason to modify the LDP draft(s) before they become
RFCs.

        No one has shown compelling evidence that MTU
sizes will result in a need for additional fragmentation.
No one has shown a really good reason why IP MTU
size discovery will not be sufficient.  I do not believe that
we need to iron out every scenario that _might_ arise in
order to move an IETF protocol specification to proposed
standard.

---

From: Ben Black <[email-masked]>
Date: Thu, 14 Dec 2000 10:31:35 -0800

To which IP MTU size discovery mechanism are you referring?

ben

---

From: Eric Gray <[email-masked]>
Date: Thu, 14 Dec 2000 14:05:10 -0500

Ben,

    RFC 1991, November, 1990.

---

From: Eric Gray <[email-masked]>
Date: Thu, 14 Dec 2000 14:10:56 -0500

Ben,

    Oops!  RFC 1191, 11/1990.  Numerical alliteration error...

--
Eric

---

From: Ben Black <[email-masked]>
Date: Thu, 14 Dec 2000 10:57:42 -0800

RFC 1991 is PGP Message Exchange Formats.  I'm assuming this is not
the RFC you mean.

ben

---

From: Ben Black <[email-masked]>
Date: Thu, 14 Dec 2000 11:06:57 -0800

PMTUD as described in RFC 1191 requires intermediate LSRs to 1) have
the ability to generate an ICMP packet back to the source of the packet
needing fragmentation and 2) not be configured to silently drop packets
that are too big.  Current popular LSRs from Cisco and Juniper will
silently drop packets which are too big.  This breaks RFC 1191 PMTUD.

ben

---

From: Eric Gray <[email-masked]>
Date: Thu, 14 Dec 2000 14:34:54 -0500

Ben,

    That would seem to indicate that either it is
not a problem for them, or it is an opportunity
for everyone else.  :-)

    If the major market leaders do not feel that
it is necessary to support one mechanism to do
MTU discovery, what is to make anyone feel
that they will support a new one?

--
Eric

---

From: "James R. Leu" <[email-masked]>
Date: Thu, 14 Dec 2000 13:55:11 -0600

Hello All,

> that they will support a new one?

One thing to note is that both brand C and brand J have, up until recently,
been using RSVP-TE for their only MPLS signalling protocol.  As we
mentioned earlier in this thread RSVP-TE already has the means to propogate the
minimum MTU (umm ... min max trans unit?) to the ingress of the LSP.  So the
PMTUD can be handled by the ingress of the LSP.

Only recently has LDP been starting to show up on the radar.  If anyone is
currently running LDP in there network or lab I would like to know how well
PMTUD works for them (in a mixed MTU network).

Jim

-- 
James R. Leu

---

From: "James R. Leu" <[email-masked]>
Date: Thu, 14 Dec 2000 13:55:05 -0600

Hello All,

Jim

-- 
James R. Leu

---

From: "James R. Leu" <[email-masked]>
Date: Thu, 14 Dec 2000 13:56:35 -0600

Hello All,

Jim

-- 
James R. Leu

---

From: Ben Black <[email-masked]>
Date: Thu, 14 Dec 2000 11:57:43 -0800

Doing anything but silently discarding would require either a change
to draft-ietf-mpls-label-encaps-08.txt or taking the slow path through
the LSR.  Note that RSVP now has 2 mechanisms for reporting path MTU.
This is not a new idea.  

Quite simply, PMTUD is _easily_ broken without an MTU reporting mechanism,
and since LDP is a protocol for IP, it should support fundamental IP
requirements.

ben

---

From: Guangzhi Li <[email-masked]>
Date: Thu, 14 Dec 2000 15:14:32 -0500

Jim:

one copy of your email to mpls is enough :=)

---

From: Ben Black <[email-masked]>
Date: Thu, 14 Dec 2000 12:10:56 -0800

Cisco unpacks the IP datagrams, then processes them?  Ouch.  It appears
I was optimistically misinformed.

ben

On Thu, Dec 14, 2000 at 03:19:27PM -0500, Dan Tappan wrote:
> At 11:06 AM 12/14/00 -0800, Ben Black wrote:
> I can't speak authoritatively for Juniper, but this is a false statement as 
> far as Cisco.
> 
> 
> >ben
> >

---

From: Dan Tappan <[email-masked]>
Date: Thu, 14 Dec 2000 15:19:27 -0500

---

From: Eric Gray <[email-masked]>
Date: Thu, 14 Dec 2000 15:33:49 -0500

Ben,

    Consider this.  You are about to discard a packet
because it is to large.  Who cares if you do this on the
slow path?

--
Eric Gray

---

From: Dan Tappan <[email-masked]>
Date: Thu, 14 Dec 2000 15:32:41 -0500

At 12:10 PM 12/14/00 -0800, Ben Black wrote:
>Cisco unpacks the IP datagrams, then processes them?

in the appropriate error handling case

>  Ouch.  It appears

Optimistic in what sense? Optimistic that Cisco would field an 
implementation which would break existing network functionality? Optimistic 
that someone else could get away with a broken implementation because they 
hoped Cisco/Juniper had?

> > > > > > > > would hope before they move to RFCs).  Although it is often 
> the
> > > case that
> > > > > > > > ethernet edge devices pushing packets which must be sent 
> across
> > > POS links
> > > > > > > > this issue was not raised earlier, but now that it has 
> been, it
> > > should
> > > > > > > > be addressed promptly.
> > > > > > > >
> > > > > > > > ben
> > > > > > >
> > > > > > >
> > > >
> > > >

---

From: Ben Black <[email-masked]>
Date: Thu, 14 Dec 2000 12:25:51 -0800

The silent discard is not in the slow path.  Unpacking an IP
datagram, processing it (whether that be fragmenting it or
generating an ICMP message), then forwarding it is more
involved than simply label swapping.  This operation may
or may not be performed in the fast path, depending on the
implementation.

ben

---

From: Ben Black <[email-masked]>
Date: Thu, 14 Dec 2000 12:43:28 -0800

> that someone else could get away with a broken implementation because they 

If we could step back for a moment: are you talking about edge LSRs or core LSRs
(the difference being an edge LSR processes unlabeled datagrams, while a core
LSR generally does not).  The whole point of this discussion is core LSRs
(specifically, core LSRs communicating path MTU information for the use of edge
LSRs).

There is nothing "broken" about implementations that silently drop too-big
packets.  It is specifically allowed by the drafts, and I agree with it.

ben

---

From: Eric Gray <[email-masked]>
Date: Thu, 14 Dec 2000 16:08:42 -0500

Ben,

    As Dan implied, this is an exception condition.
It is possible that some implementations might
discard a packet without first passing significant
information about the packet (if not the whole
packet itself) to be processed on the "slow
path" (i.e. - by a control CPU).  It is not very
likely, though.  Even "silent discard" is not
necessarily a simple operation and, in most cases,
many implementations would want to include the
option to eventually do something about all of
those strange bits that keep getting dumped.

--
Eric Gray

---

From: Ben Black <[email-masked]>
Date: Thu, 14 Dec 2000 12:58:40 -0800

> those strange bits that keep getting dumped.

Like figure out the MTU and let the edge LSRs properly
handle fragmentation and PMTUD processing so core LSRs
need not know anything about the protocols being carried 
within labelled datagrams?  It isn't always IP.

ben

---

From: Brandon Ross <[email-masked]>
Date: Thu, 14 Dec 2000 18:12:40 -0500 (EST)

On Thu, 14 Dec 2000, Eric Gray wrote:

> If the major market leaders do not feel that it is necessary to support
> one mechanism to do MTU discovery, what is to make anyone feel that they
> will support a new one? 

Because if that's the case (and I'm not convinced it is), then it's
fundamentally and operationally broken.  PMTU will not work if the ingress
LSR does not either fragment packets to fit through the LSP or in the case
of DF packets, drop and send ICMP needs fragmentation messages.

I do know for a fact that Juniper's GRE functionality is broken for
similar reasons, or at least it was the last time I tried it.

Brandon Ross                                                 404-522-5400
EVP Engineering, NetRail                           http://www.netrail.net
AIM:  BrandonNR                                             ICQ:  2269442
Read RFC 2644!

---

From: Brandon Ross <[email-masked]>
Date: Thu, 14 Dec 2000 18:15:56 -0500 (EST)

On Thu, 14 Dec 2000, Ben Black wrote:

> If we could step back for a moment: are you talking about edge LSRs or
> core LSRs (the difference being an edge LSR processes unlabeled
> datagrams, while a core LSR generally does not).  The whole point of
> this discussion is core LSRs (specifically, core LSRs communicating path
> MTU information for the use of edge LSRs). 
> 
> There is nothing "broken" about implementations that silently drop
> too-big packets.  It is specifically allowed by the drafts, and I agree
> with it. 

Do you mean in reference to a core LSR, or an ingress LSR?  It is most
certainly broken if an ingress LSR does not either fragment or send ICMP
needs fragmentation in the case of DF packets.  I don't see an issue with
dropping silently (actually I don't see any options other than silent
drop) for core LSRs, but there does, indeed, need to be a mechanism to let
the edge LSRs know what the MTU for the LSP is so they can handle the
fragmentation/dropping.

---

From: Eric Gray <[email-masked]>
Date: Thu, 14 Dec 2000 21:11:52 -0500

Brandon,

    The point is that it does not make sense to argue
that a new mechanism is needed because the current
one doesn't get used.  I do not feel that the argument
is valid regardless of the validity of the assumption on
which it is based.

--
Eric Gray

---

From: Brandon Ross <[email-masked]>
Date: Fri, 15 Dec 2000 11:11:13 -0500 (EST)

On Thu, 14 Dec 2000, Eric Gray wrote:

>     The point is that it does not make sense to argue that a new
> mechanism is needed because the current one doesn't get used.  I do not
> feel that the argument is valid regardless of the validity of the
> assumption on which it is based. 

Perhaps I am missing the point, it wouldn't be the first time, but as an
operator I can tell you that one of the reasons we haven't yet deployed
MPLS is because of problems with PMTU when running across links that are
effectively smaller than 1500.

If you're saying that we should pressure vendors to get the current
mechanism implimented and working before developing a new one, then I tend
to agree.

---

From: Steve Blake <[email-masked]>
Date: Sun, 17 Dec 2000 23:10:53 -0500

> I'd be happy to write an extension to LDP for MTU discovery if people think 

Those with long memories may remember that ARIS could convey the LSP path
MTU to the ingress LSR, because of the particular way that ARIS worked.
How this feature missed being added to LDP (at least as an option) is a
mystery to me.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                  (919)472-9913