The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

Ben,

    Please see embedded comments/responses below...

You wrote:

> On Thu, Feb 22, 2001 at 11:36:12AM -0500, Eric Gray wrote:
> >
> > Section 2.1 item 1)a):
> > ---------------------
> >
> >     The egress LSR would know what interface it will be using
> > to forward packets it receives on an LSP (otherwise, it would
> > not have advertised reachability for the FEC for this LSP, and
> > it would be required to refuse a corresponding LSP request).
> > It will know what the MTU is for that interface.  Therefore,
> > it should provide a "real" MTU rather than 0xffff.
> >
>
> The MTU in question is for the LSP, not the end to end path for a
> given FEC.  What happens to packets outside the MPLS domain, which
> I believe the unlabeled side of an LER is, is not a concern when
> determining the MTU within the MPLS domain.

Bitten by the "end-to-end" bug.

The devices at either end of an LSP are typically not hosts and
- I believe - are responsible for forwarding packets.  I can see
that existing MTU discovery mechanisms will discover the MTU
limitations for non-MPLS packets, but it seems to be silly for an
LSR implementation to advertise a maximum MTU size for LSPs
that is greater than the maximum IP packet MTU size (plus the
size of the MPLS shim header) for the interface on which it will
forward packets once it gets them.

In the below diagram, assume 'R' nodes are non-MPLS routers
(WRT a [set of] LSPs) and 'L' nodes are LSRs.

    ---- R1 --- L2 --- L3 --- L4 --- R5 ---

If R5 is the next hop with respect to a particular LSP for L4, then
L4 knows what the MAX MTU size is for IP packets it will forward
to R5 and can add to this number the number of bytes that will be
present in label(s) associated with any specific LSP.  It seems
to me that this should be the MTU that it would advertise to L3 for
any LSPs that proceed from L3 to L4 that are associated with a
FEC for which R5 is the next hop.  Is there a reason why this is not
true, or an example of when it would not be true?

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.

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?

>
>
> >     An LSR should be permitted, by wording in the specification,
> > to use either the MTU of the interface it will forward packets
> > on, or the minimum of a set of interfaces (up to and including
> > all interfaces) over which it might forward the packet.
> >
>
> This issue was previously raised and I neglected to include it.  I
> will make appropriate changes.

Okay.

>
>
> >
> > Section 2.1 item 1)b):
> > ---------------------
> >
> >     Applying the reasoning above, an LSR that is not the egress
> > for a FEC should not include an MTU TLV (or it should include a
> > TLV with an "unknown" MTU) until it receives a label mapping from
> > a downstream LSR that does include an MTU TLV with a "real" MTU.
> > In order to include information about the ability to negotiate LSP
> > MTU, a non-egress LSR might advertise an MTU of either 0x0000 or
> > 0xffff to indicate that it currently does not know the MTU for the
> > LSP downstream.
> >
>
> Perhaps it was not stated clearly enough, but 0xffff is the unknown
> MTU value.  It indicates that MTU signaling is supported, and acts
> as a placeholder.

Okay.

>
>
> >
> > Section 2.1 item 1)c):
> > ---------------------
> >
> >     If the above approach is bought into, the case where an LSR
> > receives a label mapping which does not contain an MTU TLV becomes
> > the example of the backward compatibility case (an existing LSR
> > will not include this TLV) and indicates that there is no end to
> > end MTU negotiation capability for this LSP.  At this point, my
> > thinking is that this should be refelected all the way to the
> > ingress (for example, to allow the ingress to "prefer" an LSP
> > which does have MTU negotiation) by omission of the MTU TLV in
> > all label mappings issued corresponding to this downstream LSP.
> > I could be persuaded that this is not a good idea, however - if
> > there are sound (or numerous) arguments against it.
> >
>
> 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?

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.

>
>
> >     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.

>
>
> > Section 2.1 item 1)d):
> > ---------------------
> >
> >     The meaning of "neighbor to which it is not directly
> > connected" is a little obscure for me.  If the neighbor is
> > connected via some sort of logical link, then an LSR should
> > be smart enough to use the MTU corresponding to the logical
> > link.  Is this what you are saying?  If so, it applies - I
> > believe - more generally than to the LSP case.  For example,
> > there may be different MTU sizes associated with different
> > VLAN tags and it is likely (in the Ethernet case) that there
> > will be different MTU sizes depending on the next-hop (MAC
> > address) - somewhat independent of the physical interface.
> >
>
> Yes, that wording has tripped several people up and I will work to
> come up with a better phrase.

Okay.

>
>
> >
> > Section 2.2:
> > -----------
> >
> >     Why is the "Reserved" field included?
> >
>
> It was originally there to hold a stack depth counter, but this was
> removed early on.  THe reserved field could be safely eliminated.

Okay.

>
>
> >     The 'U' and 'F' bits are set correctly (IMO), but there
> > may be some value in mentioning why they are set this way.
> >
>
> Agreed.
>
> > Section 5:
> > ---------
> >
> >     The procedures in this specification do introduce a new
> > security issue: it is now possible to introduce a new type
> > of "attack" in which a forged TCP segment contains an MTU
> > TLV with an incorrect value.  For example, an attacker may
> > insert a TLV with an MTU one smaller than the last MTU
> > advertised (forcing new advertisements to be strobed upstream)
> > and continue in this vein until the MTU reaches zero.
> >
> >     The procedures defined in RFC 3036, however, provide some
> > protection against such an attack.  Hence, while a new hazard
> > is introduced, the risk of an attack in general is not increased.
> >
>
> I believe the statement that no _new_ security issues are introduced
> is accurate, as the ability to inject forged TCP segments raises
> security issues for numerous components of LDP.

I see the direction of your argument.  The question is whether or not
a new form of attack constitutes a new issue if the mechanism to
combat this form of attack is both a) already in use or defined for
defense against existing attack opportunities and b) fool-proof.
I believe this same argument could have been stretched to apply
to LDP since the mechanism used there is lifted bodily from BGP.

Your call, but be prepared to defend your position. :-)

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

>
>
> Thank you for the detailed feedback.
>
> Ben