Subject: MTU Signalling Extensions for LDP

From: Ben Black <[email-masked]>
Date: Wed, 21 Feb 2001 16:49:32 -0800

I'd like to have this draft accepted as a working group document.  The
feedback has indicated little resistance to the idea or the details of
the extension.

http://www.ietf.org/internet-drafts/draft-black-ldp-mtu-extensions-00.txt

Ben

---

From: Eric Gray <[email-masked]>
Date: Thu, 22 Feb 2001 11:36:12 -0500

Ben,

    Some feedback.

    In general, I feel that this is a good idea.  There are some
issues, however, with signaling over-head which need to be
thought through.  In particular, an effort needs to be made to
reduce the number of label mapping messages required when
updating the LSP MTU size (due, for instance to a next-hop
change).  Once you start advertising MTU, it is necessary
that the ingress of the LSP is notified any time when the
MTU becomes smaller and - at least periodically - when it
becomes larger.  It seems to me that it would be a good idea
to avoid advertising MTU in LDP until you have received a
real MTU value from an egress (as determined, for example,
by the presence of a known hop-count).  It also seems to me
to be a good idea to allow implementations to employ some
strategy to reduce the number of re-advertisements needed.

    Specific comments follow.

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.

    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.

    For a simple router, the set of intefaces might be all
interfaces - simply because a route change is likely to result
in packets being forwarded on any interface.  It isn't necessary
to include the interface(s) on which a label is being supplied,
since - if the new route has packets being forwarded using that
interface - the labels supplied for that interface would have to
be withdrawn anyway.  However, unless the MTU size limitation is
one-way, it will not make any difference if this interface is
excluded since the upstream LSR will need to include it in any
advertisements or forwarding it does using that label.

    For a more complex router (one which employs some sort of
virtual routing paradigm) there may be a set of interfaces
which is a proper subset of all interfaces on which packets
associated with a specific FEC might be forwarded.  The LSR
need only consider those interfaces, in this case.

    I would suggest that the choice between using the MTU for
the current known forwarding interface(s) and a set of interfaces
might be a operator-configurable parameter.  A specific operator
may feel - as a result of network experiences, for example, that
it is more beneficial with some LSRs to use one approach rather
than the other.

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.

    This follows the paradigm used for hop-count and for exactly
the same reason: as long as each new label advertisement arrives
with the same (unknown) MTU, it is not necessary to re-advertise
any labels which have been previously advertised (including the
new MTU).  If a technique such as this is not employed, there may
be some horrendous strobing of the network with label mappings
if the predominant mode is independent downstream unsolicited
label advertisement.

    Also, advertising an "unknown" MTU size at least lets each
LSR (up to and including the ingress LSR) know that the capability
for MTU negotiation exists.

    Again, implementations should be allowed by the specification
to advertise the minimum MTU of a set of interfaces ranging from
the set it might currently use (the "active Mapping"s in your
current draft) to the set of all interfaces.

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.

    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.

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.

Section 2.1 item 2):
-------------------

    I am not sure what value the second paragraph adds to
the specification.  Again the concept of "remote" neighbors
is getting in the way.  (BTW, does anyone need to have it
pointed out that "remote neighbor" is an oxymoron? :-))

Section 2.1 item 3):
-------------------

    If the items above are changed, this step is correct -
i.e. - it will not result in excessive label mapping messages.

Section 2.2:
-----------

    Why is the "Reserved" field included?

    The 'U' and 'F' bits are set correctly (IMO), but there
may be some value in mentioning why they are set this way.

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.

--
Eric Gray

---

From: Ben Black <[email-masked]>
Date: Wed, 28 Feb 2001 13:05:00 -0800

> Section 2.1 item 1)a):

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.

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

> Section 2.1 item 1)b):

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.

> Section 2.1 item 1)c):

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.

> "unknonw" MTU size, it must send new label mappings which omit

I don't understand this point.

> Section 2.1 item 1)d):

Yes, that wording has tripped several people up and I will work to
come up with a better phrase.

> Section 2.2:

It was originally there to hold a stack depth counter, but this was
removed early on.  THe reserved field could be safely eliminated.

> may be some value in mentioning why they are set this way.

Agreed.

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

Thank you for the detailed feedback.

Ben

---

From: Eric Gray <[email-masked]>
Date: Wed, 28 Feb 2001 17:38:22 -0500

Ben,

    Please see embedded comments/responses below...

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

> will make appropriate changes.

Okay.

> MTU value.  It indicates that MTU signaling is supported, and acts

Okay.

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

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

> come up with a better phrase.

Okay.

> removed early on.  THe reserved field could be safely eliminated.

Okay.

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

---

From: Ben Black <[email-masked]>
Date: Wed, 28 Feb 2001 15:05:14 -0800

Comments in-line...

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

> than the old trial and error approach, so why not take it as far as

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.

> known MTU size and an unknown hop-count?

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

> downstream unsolicited and independent control modes.

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

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

> 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