The MPLS WG Archive

[Ben Black <ben@layer8.net>]

Comments in-line...

On Wed, Feb 28, 2001 at 05:38:22PM -0500, Eric Gray wrote:
> 
> Assuming that this is true, then - if you would like to avoid strobing
> or rippling the network with LSP setup traffic, you would want to
> reverse the sense of MTU advertising that you do.  IOW, you would
> want to announce a known MTU only when the announcement comes
> from an egress LSR (and may be modified by "better knowledge" on
> the way).  You could invent a new usage and have an egress LSR
> provide 0xffff while non-egress LSRs initially use 0x0000 (to mean
> MTU unknown) - but doing this would seem to be an attempt to
> hide correct information about the LSP.
> 

If the egress LSR is basing its MTU on the egress link MTU, then why
would it ever need to advertise 0xffff?

> One argument I feel you could make is that changing the interface
> on which the egress LSR will forward non-MPLS packets would
> result in the same sort of strobing.  However, this would only be
> the case if the MTU size of the new interface is smaller.  Hence,
> the new, smaller, MTU size would have to be discovered the
> hard-way using IP MTU size discovery edge-to-edge.  I think
> the MPLS approach you are suggesting is intended to be better
> than the old trial and error approach, so why not take it as far as
> it can legitimately go?
> 

Actually, this approach is intended to allow the existing mechanism,
path MTU detection, to function properly.  I prefer to see LSPs as
virtual circuits just as in FR or ATM, for this application.  This
draft does exactly that, and nothing more.  It seems to me that you 
are suggesting a fairly minor change (using the egress link MTU)
which makes the LSP MTU not quite the LSP MTU.  This might be a
semantic nit, but I don't see a strong reason to deviate from the
meaning of MTU for existing VC technologies.

> >
> > My thinking was that partial information is better than no information
> > (which is the current state of things).  My calculating the MTU at each
> > hop, the ingress LSR can learn some approximation of the path MTU,
> > which may be correct, but will be no worse off than if it had no MTU
> > information.  I see the advantage of your suggestion to allow
> > differentiation between end to end known MTU and partial path MTU, but
> > I am not sure how to fit that into the hop by hop model of the draft.
> 
> Let's assume that the LSRs in the hop-by-hop MPLS domain are
> using hop count. Doesn't it seem a bit inconsistent to include a
> known MTU size and an unknown hop-count?
> 

They are orthogonal functions, so I don't see any inconsistency.

> Even in a more general sense, however, the same concern that
> applied to hop-count applies to MTU size as well - i.e. - use
> of a known MTU size in each subsequent advertisement can
> result in excessive rippling of LDP messages when using the
> downstream unsolicited and independent control modes.
> 

Do you mean re-advertisement of an unchanged MTU value?  

> >
> >
> > >     Also, in the event that (using independent mode) the LSR has
> > > previously provided label mappings that includes an MTU TLV of
> > > "unknonw" MTU size, it must send new label mappings which omit
> > > this TLV.
> > >
> >
> > I don't understand this point.
> 
> If, as you stated above, you are using the inclusion of an MTU TLV
> as an indication of MTU size negotiation capability, then - when an
> LSR receives a label mapping from a downstream LSR that will be
> the next hop for a (set of) LSP(s) - it now knows that this capability
> does not exist downstream.
> 
> If the intention in including the TLV is to let upstream LSRs know
> that this capability exists, then the newly discovered incapability
> must be announced to the upstream LSRs as well.
> 

Simply not advertising the MTU TLV can convey this.  Do we see no use
in having partial MTU information?

> 
> Just remember that the term "fool-proof" is usually evidence of a
> lack of awareness of the resourcefulness of the average fool...
> 

No more fool-proof than the rest of the protocol.  I make no claims
as to the strength of the existing protocol mechanisms.


Ben