The MPLS WG Archive

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

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

You wrote:

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