The MPLS WG Archive

[Eric Gray <ewgray@mindspring.com>]

Ben,

    Please see embedded comments.

You wrote:

> On Tue, Dec 19, 2000 at 04:06:36PM -0500, Curtis Villamizar wrote:
> > Kireeti,
> >
> > I am surprised to see you take such a hard stance on this.
> >
> > There should be no requirement that the midpoints of an LSR do special
> > processing for a particular L3PID.  There should also be no
> > requirement that an LSR be completely ignorant of the L3PID.
> >
>
> The issue I am raising is whether the processing of a particular L3PID
> should be in the base specification.  I don't believe it should.  There
> should be an IP-specific draft addressing how L3PID-aware LSRs should
> handle IPv4 (and IPv6) packets.

It is often the case that a protocol specification for generic
support of multiple protocol includes one or two examples
of how the generic support works.  While it might be more
correct to do IPv4 (for example) in a separate draft, it
might also be more correct to arrange condiments on your
supper table in alphabetical order.  More correct does not
mean necessary.


>
>
> > If the MTU is passed back to the ingress of a TE tunnel, then the
> > ingress can fragment or generate the ICMP for packets with "don't
> > fragment" set.
> >
>
> Absolutely.  However, if the MTU can be determined before any packets
> flow across, why add _anything_ to the specification for processing
> packets which need to be fragmented?  The combination of proper
> signalling and silent discard within the MPLS domain provides all that
> is required.
>
> > If the L3PID is IPv4, it is perfectly legitimate to send TTL expired
> > ICMP if TTL expires.  It is equally legitimate to ignore the L3PID and
> > not generate ICMP, or disable TTL decrement at all but the egress for
> > TE tunnels (where no loop is ever possible).  LSR that don't generate
> > ICMP are simply traceroute unfriendly and the path will pick up again
> > as soon as the TTL is large enough to reach the egress of the LSP.
> >
> > If the L3PID is not IPv4 (for example MPLS) then an LSR should not try
> > to guess the type of payload.  Providers who want to retain
> > functionality that is only available if the L3PID is known will have
> > to set up TE hierarchical tunnels for IPv4 only and other hierarchical
> > tunnels to carry "anything else".  This would be true of hierarchical
> > tunnels for specific diff-serv CT values so this is no surprise.
> >
> > The text is therefore fine as is.  Perhaps some minor clarification
> > can be made, but it does not make sense to remove this.
> >
>
> Then I propose we add text for ATM, Frame Relay, Circuit Emulation, ...
>

One or two examples are fine, thanks...

>
> Ben

--
Eric