Subject: Re: I-D ACTION:draft-ietf-mpls-ldp-mtu-extensions-01.txt

From: Mark Duffy <[email-masked]>
Date: Mon, 07 Jul 2003 19:16:31 -0400

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:

>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.  But how to determine if that is the case?  It is 
hard to say how "bad" the locally generated approximation would be without 
making an assumption about what information would be locally available, and 
no such assumption is stated here.  I would think the goal of the scheme 
should rather be that the procedure "discover either the exact MTU for that 
LSP, or a value that is no larger than the exact MTU".  I'm not sure though 
that this goal is achievable -- see my last comments below,  regarding 
sect. 2.4.

>    Hop MTU: the MTU of an LSP hop between an upstream LSR A and a
>    downstream LSR B.  This size includes the IP header and data (or
>    other payload) and the part of the label stack that is considered
>    payload as far as this LSP goes.  It does not include any lower-level
>    headers.  (Note: if there are multiple links between A and B, the Hop
>    MTU is the minimum of the MTU of those links used for forwarding.)

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

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

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

>           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.  In any event, I think it would be 
worthwhile to explicitly state in the document how LSR L is to calculate 
the Hop MTU, or to enhance the definition of Hop MTU in section 2.1 to 
explain the effect of PHP on the value.

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

>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?  This basically leaves the hop(s) 
immediately downstream of the "dumb" LSR out of the calculation.  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.  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!

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

Thanks, Mark

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 9 Jul 2003 08:41:55 -0700 (PDT)

Hi Mark,

> I have a few comments (mostly nits) on the -01 draft that I hope will be

They are, thanks!

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

> to clarify it is not talking about the link MTUs.

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

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

> "downstream LSR" that was defined in sect. 2.1.

Okay.

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

> s/the MTU that it computed/the LSP MTU that it computed/

Okay.

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

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.

> has more than 1 downstraem LSR?  How does it then "forward the TLV to its

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

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

Kireeti.

---

From: Mark Duffy <[email-masked]>
Date: Mon, 14 Jul 2003 13:49:58 -0400

>be too large.  (See below also.)

[snip]

Hi Kireeti, and thanks for responding.  Sorry about the delay in getting 
back to you.

I think the basic question is, what is the right thing to do when some of 
the Hop MTUs are missing (e.g. because the LSR upstream of the hop does not 
support the MTU signalling extensions).

Just to summarize the lengthy section I snipped...   As written, (as you 
point out above) the scheme calculates and uses the min of the values it 
does have.   This is per the [U=1, F=1] mode of LDP.  The alternative would 
be to use a [U=1, F=0] LDP behavior.

The benefit here of F=1 is that you can get some use out of the scheme even 
though not all LSRs in the path are supporting it.  This is especially 
important for a feature such as this that is being added late in the game.

The benefit of F=0 is that when the scheme is missing necessary 
information, it tells the affected upstream LSRs that it failed, rather 
than telling them a possiblly incorrect value.  This would alert the 
upstream LSRs to use a different strategy; perhaps using a 
known-conservative MTU value.

I suppose I agree with you that given a choice between the two, the first 
way (F=1) is better.  I think is is possible to get the best of BOTH by 
using another, separate TLV that is originated by the egress LSR only, and 
passed with U=1, F=0, that tests the continuity of support for the MTU 
discovery.  Then LSRs would learn an MTU for the downstream portion of the 
LSP, as well as learning whether that MTU was based on all Hop MTUs or just 
a subset of them. What do you think?  Worthwhile or not worth the extra 
complexity?

Mark