The MPLS WG Archive

["Yongjun Im" <yongjuni@erlangtech.com>]

Hi, please find the inline comment below.

Take care,

Thanks.

----- Original Message ----- 
From: <suchauhan@hss.hns.com>
To: "Eric Gray" <eric.gray@sandburst.com>
Cc: "David Charlap" <david.charlap@marconi.com>; "'mpls@uu.net'" <mpls@UU.NET>
Sent: Wednesday, April 25, 2001 11:20 PM
Subject: Re: Fragmentation in RFC-3032

hi!
      A few other points to ponder here;-

1. As David said that the switch may be incapable of detemination of IP
characteristics. This leads us implicitly to the discussion held earlier that
can there be MPLS nodes that are L3 unaware. My understanding is if we try and
have a scenario where the MPLS nodes (LSRs) are L3 unaware we are doing away a
lot of advantages MPLS gives us and not gaining much. To me a LSR unaware of L3
is basically a ATM switch which is un-neccesarily also running LDP. Correct me
if I am wrong but this will only be benificial if we consider static LSP setup
done manually which would be sacrificing a lot and gaining nothing, as that you
can almost do with just a pure ATM setup.

>>In my opinion, an ATM swith without an MPLS signaling capability is just
>>"Native ATM Switch", not LSR. Basically when we call an ATM switch as an LSR, 
>>it means that the ATM switch has a capability of MPLS signaling like LDP.
>>If the LSR has an MPLS signaling capability, the LSR also has an IP forwarding capability
>>because the LDP runs over TCP(UDP)/IP protocols. That is to say, any real LSR supports
>>an IP forwarding in control path, even though the MPLS data path is a cell-based forwarding.
>>Can we think that an LDP could be working without co-operating with L3 routing protocol?
>>I don't think so.

Thanks,

Yongjun.

2. The other thing as Eric pointed out here about ATM SAR cpability in my
opinion SAR and IP Fragmentation are seperate functions and can and should not
be clubbed as one. the reason is that for doing IP Fragmentation there are a
whole lot of other things that need to be done (like IP header replication)
rather than just chopping a packet into smaller ones. I think what Eric is
proposing is very novel that we try and do some sort of Fragmentaions at L2
instead of L3 to deal with teh small MTU on the outgoing link. This will need a
whole lot of thinking before we want to commit on this.

3. As has been said here earlier it should be a requirement put on the LERs to
run Path MTU discovery in order to provide that this sort of case does not
arise. What the RFC says is probably the "worst case action" than the "best
possible one" ;o)


regards
sumit




Eric Gray <eric.gray@sandburst.com> on 04/26/2001 12:04:06 AM

To:   David Charlap <david.charlap@marconi.com>
cc:   "'mpls@uu.net'" <mpls@UU.NET> (bcc: Sumit Chauhan/HSS)

Subject:  Re: Fragmentation in RFC-3032




David,

    Correct me if I'm wrong (or feel free to correct me if
I'm right ... again), but ATM switches switching ATM
cells have no way to know if an IP packet that extends
over multiple cells is "too long".

    I believe this determination would be made by that
ATM switch saddled with SAR responsibility.  If that is
the case, why would that ATM switch be intrinsically in-
capable of fragmenting IP packets?

--
Eric Gray

You wrote:

> Eric Gray wrote:
> >
> > In addition to what Jack says below, the intent is to specifically
> > allow implementations to silently discard packets it might otherwise
> > be expected to fragment.
>
> More specifically, some hardware (especially legacy ATM hardware) may be
> incapable of performing IP fragmentation.  These same boxes may also be
> incapable of generating ICMP messages.
>
> If a too-large packet arrives at such a box, it has no choice but to
> drop it.
>
> Ideally, the LER that admits the packet into the LSP should check the
> size and fragment (or generate ICMP if DF is set) to the LSP's MTU size
> (that is, the mimimum MTU of all the routers along the LSP).  But this
> may not always be possible - not all signaling protocols report the
> LSP's MTU to the ingress router.
>
> Hence the RFC, which allows LSRs to either fragment or discard too-large
> packets that don't have DF set.
>
> -- David