The MPLS WG Archive

[Ben Black <ben@layer8.net>]

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.

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

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

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

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

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

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

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

Thank you for the detailed feedback.


Ben