The MPLS WG Archive

[neil.2.harrison@bt.com]

I agree with all Ben says in here.

neil

> -----Original Message-----
> From:	Ben Black [SMTP:ben@layer8.net]
> Sent:	Tuesday, December 19, 2000 9:31 PM
> To:	curtis@avici.com
> Cc:	Kireeti Kompella; mpls@UU.NET
> Subject:	Re: Concerns regarding the numerous layer violations in base
> MPLS drafts
> 
> 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. 
> 
> > 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, ...
> 
> 
> Ben