The MPLS WG Archive

[Kireeti Kompella <kireeti@juniper.net>]

Hi Mark,

On Mon, 7 Jul 2003, Mark Duffy wrote:

> Hi and thanks, I am glad to see the LDP MTU extension moving forward!
>
> I have a few comments (mostly nits) on the -01 draft that I hope will be
> helpful:

They are, thanks!

> >1. Introduction
> >...
> >                       This information is sufficient for a set of LSRs
> >    along the path followed by an LSP to discover either the exact MTU
> >    for that LSP, or an approximation which is no worse than could be
> >    generated with local information on the ingress LSR.
>
> [md] How do we define "no worse"?  I'd suggest that it should mean the
> procedure is not more likely to discover an LSP MTU value that is higher
> than the actual value.

Basically, the path MTU discovery problem is to take the min of a set
of values (those values being the MTUs of the involved links).  If some
of those values are missing, the best you can do ("no worse") is to
take the min of the values you *do* have.  As you point out, this can
be too large.  (See below also.)

> [md] The final sentence above seems incorrect.  I think that if there are
> multiple links between A and B, the Hop MTU is the minimum of the Hop MTU
> that would be computed using the above definition for any of those links
> alone.  Maybe it just needs
> s/MTU of those links/Hop MTU of those links/
> to clarify it is not talking about the link MTUs.

That's what was meant; I'll make the clarification.

> >2.2. Example
> >
> >    Consider LSRs A-F interconnected as follows:
> >
> >                  M       P
> >                _____ C =====
> >               /      |      \
> >      A ~~~~~ B ===== D ----- E ----- F
> >          L       N       Q       R
> >
> >    Say that the link MTU for link L is 9216, for links M, Q and R is
> >    4470, and for N and P is 1500.
>
> [md]  A link between C-D is shown in the diagram but it is not given a name
> like the other links are, nor is it mentioned further except a few
> paragraphs below in "C's peers for FEC X are B, D and E."  Perhaps it
> should be removed or else involved more fully.

Well, the point was, no all links emerging from a router are used for
forwarding ... I'll make that explicit.

> [md]  In section 2.3 in the list items a),  b), c) it uses the term
> "downstream neighbor".  These should probably instead use the term
> "downstream LSR" that was defined in sect. 2.1.

Okay.

> >           b)  For each downstream neighbor Z, L computes the minimum of
> >                the Hop MTU to Z and the LSP MTU in the MTU TLV that Z
>
> [md]  The procedure in sect. 2.3 requires each LSR L (in step 1.B.b) to
> determine the Hop MTU to each Downstream LSR.  Based on the definition of
> Hop MTU, we might presume that this value is arrived at by subtracting 4
> octets (1 label size) from the payload capacity of the underlying
> link.  However, in the case of PHP where the LSR L is the penultimate hop,
> I think the correct Hop MTU is *equal* to the payload capacity of the
> underlying link.  Do you agree?  Though it may not be worth the added
> complexity to get the extra 4 bytes.

I agree, and I didn't put it in just because of the added complexity.
However, I can say that a PHP LSR MAY use the full payload.

> >    2.  For each LDP neighbor (direct or targetted) of L to which L
> >        decides to send a Mapping for FEC F, L attaches an MTU TLV with
> >        the MTU that it computed for this FEC.
>
> [md]  In the last line, to be completely clear,
> s/the MTU that it computed/the LSP MTU that it computed/

Okay.

> >2.4. MTU TLV
> >...
> >    Note that the U and F bits are set.  An LSR that doesn't recognize
> >    the MTU TLV MUST ignore it when it processes the Label Mapping
> >    message, and forward the TLV to its peers.  This may result in the
> >    incorrect computation of the LSP MTU; however, silently forwarding
> >    the MTU TLV preserves maximal amount of information about the LSP
> >    MTU.
>
> [md]  Is that the best thing to do?

There are three choices:
a) [U=0]: LSP doesn't come up if it passes through a "dumb" LSR (bad!!!)
b) [U=1, F=1]
c) [U=1, F=0]

> This basically leaves the hop(s)
> immediately downstream of the "dumb" LSR out of the calculation.

Not quite.  If the "dumb" LSR faithfully copies the MTU TLV to its
upstream, only the one link downstream of the "dumb" LSR gets left out.
That's the point of the 'F' bit.

> This can
> only err in the direction of computing an LSP MTU that is *too large*.  If
> OTOH the TLV were not propagated upstream (F bit cleared) the next upstream
> LSR could instead make some conservative guess about the MTU of the
> downstream portion of the LSP.  E.g. use a configured value (might
> typically be set to 1500 minus sizeof a few labels).  That's kind of ugly,
> but it might be pragmatic.

In which case, every LSP that passes through a "dumb" LSR will have an
MTU of (to be even more conservative) 576 minus a few labels!  As you
say, that's ugly.

> But note that right now sect. 2.3, 1.B.b, says
> in the absence of the MTU TLV to presume an MTU of the downstraem portion
> of the LSP of 65535!

Again, not quite.  Then again, if the ingress is dumb, that's what you
get.

If the consensus of the WG is to go with U=1, F=0, I'll be happy to make
the change.  Otherwise, I'd rather leave it the way it is.

> [md]  Also, what is an LSR that doesn't recognize the MTU TLV to do if it
> has more than 1 downstraem LSR?  How does it then "forward the TLV to its
> peers"?

You're asking how the 'F' bit works.  Beyond the scope of this document :-)

Good question, though.  Anyone care to take a stab?

Kireeti.