The MPLS WG Archive

[Mark Duffy <mduffy@quarrytech.com>]

At 04:34 AM 9/7/2003 +0200, Loa Andersson wrote:
>Working Group,
>
>this is to initiate a working group last call on
>
>      MTU Signalling Extensions for LDP
>      <draft-ietf-mpls-ldp-mtu-extensions-01.txt>


Below is a portion of an email posted earlier that discusses several minor 
clarifications to this draft that would be helpful.  (The full message is 
<http://cell.onecall.net/mhonarc/mpls/2003-Jul/msg00030.html>.

Thanks, Mark


>X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
>Date: Wed, 9 Jul 2003 08:41:55 -0700 (PDT)
>From: Kireeti Kompella <kireeti@juniper.net>
>To: Mark Duffy <mduffy@quarrytech.com>
>cc: mpls@UU.NET
>Subject: Re: I-D ACTION:draft-ietf-mpls-ldp-mtu-extensions-01.txt
>In-Reply-To: <5.2.0.9.0.20030707174919.01e619b0@email>
>Message-ID: <20030709081340.C75891@kummer.juniper.net>
>References: <5.2.0.9.0.20030707174919.01e619b0@email>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>Hi Mark,
>
>On Mon, 7 Jul 2003, Mark Duffy wrote:

[snip]


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

[snip]