The MPLS WG Archive

[Mark Duffy <mduffy@quarrytech.com>]

At 09:35 AM 8/11/2003 -0400, George Swallow wrote:
>I personally believe this document is ready for last call.  I'll give
>it a few days before we start the official last call to see if there
>are any objections.
>
>...George


Hi,
I sent some comments in response to the previous last call (?) in April, 
which have not been addressed.  They are included below.
Thanks, Mark


>X-Sender: mduffy@email
>X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
>Date: Fri, 11 Apr 2003 17:38:33 -0400
>To: mpls@UU.NET,erosen@cisco.com
>From: Mark Duffy <mduffy@quarrytech.com>
>Subject: Re: MPLS WG Last Call draft-ietf-mpls-in-ip-or-gre-00.txt
>In-Reply-To: <200303311913.OAA05418@bifocal.cisco.com>
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"; format=flowed
>
>
>>This message begins an MPLS Workgroup last call on
>>
>>   Encapsulating MPLS in IP or GRE
>>     draft-ietf-mpls-in-ip-or-gre-00.txt
>
>Hi, I have a few questions/comments on the draft.
>
>1.  In section 2 there are protocol numbers 'X' and 'Y' called out.  I 
>presume these are to be replaced with values assigned by IANA.  I don't 
>know what the politics are by which values get assigned or denied but 
>since the 'Y' value for MPLS multicast "is for further study" perhaps IANA 
>should only be asked for an 'X' value at this time.  I should think a 
>request for one value is more likely to succeed than a request for two.
>
>
>2.  In sect 4.1, there is a clear implication that the "Tunnel MTU" 
>describes the maximum sized *MPLS packet* that can be encapsulated in the 
>IP or GRE packet.  Therefore I think the following paragraph is not quite 
>correct:
>
>    In some cases, the tunnel head receives, for encapsulation, an IP
>    packet, which it first encapsulates in MPLS and then encapsulates in
>    MPLS-in-IP or MPLS-in-GRE.  If the source of the IP packet is
>    reachable from the tunnel head, and if the result of this
>    encapsulation would be a packet whose size exceeds the Tunnel MTU,
>    then the tunnel head SHOULD use the Tunnel MTU value for the purposes
>    of fragmentation and PMTU discovery outside the tunnel.
>
>I think it should instead read something like:
>
>    In some cases, the tunnel head receives, for encapsulation, an IP
>    packet, which it first encapsulates in MPLS and then encapsulates in
>    MPLS-in-IP or MPLS-in-GRE.  If the source of the IP packet is
>    reachable from the tunnel head, and if the result of **the MPLS**
>    encapsulation would be a packet whose size exceeds the Tunnel MTU,
>    then the tunnel head SHOULD use the Tunnel MTU value, **less the size
>    of the added MPLS label stack,** for the purposes of fragmentation
>    and PMTU discovery outside the **MPLS LSPs and encapsulating** tunnel.
>
>
>3.  A few typos:
>
>In the last sentence of sect. 2 and the exact same text again at the last 
>sentence of sect. 3:  s/is the topmost packet of the decapsulated 
>packet/is the topmost label of the decapsulated packet/
>
>In sect 4.1  s/mpls packet be decapsulated/mpls packet can be decapsulated/
>
>In sect 8 s/RFC7915/RFC791/
>
>Thanks,
>Mark