Subject: draft-ietf-mpls-in-ip-or-gre-01.txt to PS

From: Yakov Rekhter <[email-masked]>
Date: Mon, 11 Aug 2003 06:25:37 -0700

George,

I'd like to ask you to issue the Last Call on
draft-ietf-mpls-in-ip-or-gre-01.txt to move it to a Proposed Standard.

Yakov.

---

From: George Swallow <[email-masked]>
Date: Mon, 11 Aug 2003 09:35:19 -0400

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

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

---

From: Scott Bradner <[email-masked]>
Date: Mon, 11 Aug 2003 16:17:25 -0400 (EDT)

I think the doc is almost ready to be forwarded to the IESG but two
comments

>    The Protocol Number field in an IPv4 header and the Next Header field
>    in an IPv6 are set as follows:
> 
>      - X indicates an MPLS unicast packet,
> 
>      - Y indicates an MPLS multicast packet.  (The use of the MPLS-in-IP
>        encapsulation for MPLS multicast packets is for further study.)  

the ID needs to have an IANA Considerations section to tell the
IANA to assign the protocol values X & Y

> 6. Security Considerations
> 
>    MPLS-in-IP or MPLS-in-GRE tunnels may be secured using IPsec. 

I predict that there will be pushback from the security ADs over the
level of non-detail about how to use IP Sec to secure the links

Scott

---

From: Mark Duffy <[email-masked]>
Date: Mon, 11 Aug 2003 15:24:11 -0400

>it a few days before we start the official last call to see if there

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: [email-masked],[email-masked]
>From: Mark Duffy <[email-masked]>
>Subject: Re: MPLS WG Last Call draft-ietf-mpls-in-ip-or-gre-00.txt
>In-Reply-To: <[email-masked]>
>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

---

From: Scott Bradner <[email-masked]>
Date: Tue, 12 Aug 2003 11:36:04 -0400 (EDT)

> I thought that  IANA Considerations are only needed  if there are additional
> values which IANA may be called upon to assign in the future. 

such a section is needed whenever the IANA should do something -
on the specific document or setup a process for the future - this
doc assumes that values will be assigned but does not say specifically
that the values should be assigned

> Probably I should ask IANA for  assignments now, but I'm always reluctant to
> do that  because they  hardly ever respond  ;-( Alternatively we  could hope
> that the  RFC editor will get  the assignments made  by IANA as part  of the
> pre-publication process.  What's our best bet? 

the normal process is for the RFC Editor to ask the IANA (one of the
reasons for the IANA considerations section - so that the need to
request is clear)

> Scott> I predict that there will be  pushback from the security ADs over the
> Scott> level of non-detail about how to use IP Sec to secure the links 
> 
> What level of detail do you think they will require? 

at least say something about what IPSec mode and where keys come from
(manual would work for me but I'm not a SEC AD) - but this is hard to
predict (at least for me)

Scott

---

From: Eric Rosen <[email-masked]>
Date: Tue, 12 Aug 2003 11:30:33 -0400

Scott> the ID needs to have an  IANA Considerations section to tell the IANA
Scott> to assign the protocol values X & Y

---

From: Eric Rosen <[email-masked]>
Date: Tue, 12 Aug 2003 11:31:08 -0400

Mark> I sent  some comments  in response  to the previous  last call  (?) in
Mark> April, 

Oh, that was a last call for accepting  it as a WG document, not a last call
for sending it to the IESG ;-)

Mark> which have not been addressed. 

My apologies,  I meant  to incorporate them  "in the  next rev", but  I just
dropped the ball ;-(

Mark> 1.  In section 2 there are protocol numbers 'X' and 'Y' called out.  I 
Mark> presume  these are to  be replaced  with values  assigned by  IANA.  I
Mark> don't  know what  the politics  are by  which values  get  assigned or
Mark> denied  but since the  'Y' value  for MPLS  multicast "is  for further
Mark> study" perhaps  IANA should  only be  asked for an  'X' value  at this
Mark> time.   I should  think a  request  for one  value is  more likely  to
Mark> succeed than a request for two.

I figure if we  ask for both, the worst that can happen  is that we only get
one, but we might as well try for both.  

On the  Tunnel MTU issue, you are  correct that the text  is confusing.  How
about: 
 
        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 value which the tunnel head SHOULD
        use for the purposes of fragmentation and PMTU discovery
        outside the  tunnel is the Tunnel MTU value minus the
        size of the MPLS  encapsulation.

I've incorporated your other corrections.

---

From: Mark Duffy <[email-masked]>
Date: Tue, 12 Aug 2003 14:19:14 -0400

Hi Eric,

At 11:31 AM 8/12/2003 -0400, Eric Rosen wrote:
>         encapsulation

I think "this encapsulation" above should be changed to read "the MPLS 
encapsulation" or the equivalent.  "this encapsulation" in this context 
seems to refer to both the MPLS *and* the MPLS-in-IP/GRE.  However, it is 
only the size of the IP packet plus the MPLS label stack that should be 
compared to the Tunnel MTU.

>would be a packet whose size exceeds the

Thanks, Mark