Subject: Last Call: MTU Signalling Extensions for LDP to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 29 Jul 2002 16:58:26 -0400

The IESG has received a request from the Multiprotocol Label Switching
Working Group to consider MTU Signalling Extensions for LDP
<draft-ietf-mpls-ldp-mtu-extensions-00.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by August 12, 2002.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mtu-extensions-00.txt

---

From: Mark Duffy <[email-masked]>
Date: Mon, 29 Jul 2002 17:29:49 -0400

Hi,

I reported a number of problems with the Example section (section 3) of
draft-ietf-mpls-ldp-mtu-extensions-00.txt on 23 July.  I didn't realize at
the time that the draft was almost ready for Last Call; perhaps it had
already been submitted even.  So, apologies for the lateness of my
comments.  All the same I believe that the procedures in section 2 of the
document are difficult to understand, and that a correct example is
therefore very important.  One of the authors agreed with my comments and I
understood that the draft was to be updated.

A copy of the comments is below.
Thanks, Mark Duffy

>X-Sender: [email-masked]
>X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
>Date: Tue, 23 Jul 2002 11:07:26 -0400
>To: [email-masked],[email-masked],[email-masked]
>From: Mark Duffy <[email-masked]>
>Subject: issues in draft-ietf-mpls-ldp-mtu-extensions-00
>
>Hi, 
>
>In draft-ietf-mpls-ldp-mtu-extensions-00 I believe there are several
>problems with the example in section 3.
>
>At the very end of the example it states:
>
>   At t[2]:
>
>   1) Rx receives a Mapping for F from Ry with an MTU of 9216.  Rx
>   compares 9212 (9216 - 4) to 4466, and sends a Mapping message for F
>   with an MTU of 4466 to Ri.
>
>   2) Ri has not received Mappings for F.
>
>   At t[3]:
>
>   1) Ri receives a Mapping for F from Rx with an MTU of 4462.  Ri
>   compares 4466 to 9216, and sets the MTU for P1 to 4462 (4466 minus
>   the overhead of 1 label pushed onto the stack).
>
>
>The last step looks to me like it has several errors.
>At t[2] item 1 Rx sends a mapping with mtu of 4466 to Ri.  Therefore at
>t[3] step 1 Ri should receive a mapping from Rx with an mtu of 4466.  Also
>in this same step Ri should subtract 4 bytes from both the MTU it learned
>from Rx, as well as its local interface MTU, in making the calculation (to
>account for the label pushed at Ri).
>
>So it looks to me like the correct text for t[3] is:
>
>   1) Ri receives a Mapping for F from Rx with an MTU of *4466*.  Ri
>   compares *4462* to *9212*, and sets the MTU for P1 to 4462 (4466 minus
>   the overhead of 1 label pushed onto the stack).
>
>---------------------
>
>Also, the example doesn't seem to correctly account for the encapsulation
>of LSP P1 inside LSP P2 from Rx to Re.  It discusses mappings for FEC F to
>LSP P1 distributed to Ry, however Ry may be unaware of FEC F, since LSP P1
>is encapsulated in P2 at this point.  
>
>I think the way to fix this would be to:
>  Let FEC G represent traffic mapped to LSP P2.
>  Change t[0] and t[1] items #1 to discuss G rather than F.
>  Change t[0] and t[1] items #2 to include G.
>  Chnage t[2] item #1 to receive mapping for G from Ry, send mapping for F
>to Ri.
>  Adding another column to the table at the right of the figure would help
>as well, giving the "MTU with P1 and P2 overhead".
>
>
>Apologies if I am misunderstanding this, or if this has already been
>pointed out.
>
>--Mark
>