Subject: Re: [16NG] [nwg-chair] NWG feedback on 16ng's IPv4 CS draft

From: gabriel montenegro <[email-masked]>
Date: Wed, 3 Jun 2009 10:09:52 -0700 (PDT)

The new rev has appeared:
http://tools.ietf.org/html/draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05

This is a summary of changes:

Editorial changes throughout.

Got rid of all mention of WiMAX in the main text.

Section 3 on network architecture: deleted much text, instead referring to the
relevant sections in IEEE802.16, 5121 and 5154. No need to repeat text that appears 
elsewhere.

Section 4.3 on MTU: simplified to say not much more than RFC5121 says.

Section 6 on handling multicast. Got rid of it. It repeats stuff already in
both 5.3 and 5.1.

Appendix on WiMAX MTU.
Got rid of:
   The addressing and operation of IPv4 CS described in this
   document are applicable to the WiMAX networks as well. 
Got rid of recommendation that WiMAX adopt this specification.

But your favorite diff tool is your best bet, e.g.:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt

Please look it over. Hopefully, the remaining issues are manageable and less in number.

thanks,

Gabriel

________________________________
From: gabriel montenegro <[email-masked]>
To: "Riegel, Maximilian (NSN - DE/Munich)" <[email-masked]>; ext Samita Chakrabarti <[email-masked]>; Wesley George <[email-masked]>
Cc: ext Alper Yegin <[email-masked]>; [email-masked]
Sent: Wednesday, May 20, 2009 8:41:46 AM
Subject: Re: [16NG] [nwg-chair] NWG feedback on 16ng's IPv4 CS draft

Let's wait till the next version appears (ETA: end of this month) as hopefully that version
will require less fixes.

________________________________
From: "Riegel, Maximilian (NSN - DE/Munich)" <[email-masked]>
To: ext Samita Chakrabarti <[email-masked]>; gabriel montenegro <[email-masked]>; Wesley George <[email-masked]>
Cc: ext Alper Yegin <[email-masked]>; [email-masked]
Sent: Wednesday, May 20, 2009 2:11:31 AM
Subject: Re: [16NG] [nwg-chair] NWG feedback on 16ng's IPv4 CS draft

My point is not the MTU size, I am concerned about the quality of the current document. There are a number of ambiguities and misconceptions, which would require some efforts for resolving. I once did an approach to create a submission to the mailing list and gave up after an hour seeing that it requires more text to explain the issues in the document than just rephrasing the text.
 
Would it be possible to held a conference call to discuss the readiness of the IPv4-CS I-D?
 
Bye
Max

________________________________
From: ext Samita Chakrabarti [mailto:[email-masked]] 
Sent: Tuesday, May 19, 2009 11:59 PM
To: 'gabriel montenegro'; Riegel, Maximilian (NSN - DE/Munich); 'Wesley George'
Cc: 'ext Alper Yegin'; [email-masked]
Subject: RE: [16NG] [nwg-chair] NWG feedback on 16ng's IPv4 CS draft

Agreed. 
Default MTU is 1500  - if WiMAX does not want to update their SPEC or does not want to conform to this IETF draft, it is SDO business. Thus we can move forward  independently.
 
Thanks,
-Samita
 
From:gabriel montenegro [mailto:[email-masked]] 
Sent: Tuesday, May 19, 2009 9:39 AM
To: Samita Chakrabarti; Riegel, Maximilian (NSN - DE/Munich); Wesley George
Cc: ext Alper Yegin; [email-masked]
Subject: Re: [16NG] [nwg-chair] NWG feedback on 16ng's IPv4 CS draft
 
I think what we need (my intention) is not more details, but less. I agree that there is
some overlap with the WiMAX spec. We should simply refer to WiMAX for the WiMAX-specifics, 
and drop the recommendation that WiMAX should adopt this spec. Given the difference in MTU,
I won't hold my breath for them to do so, but it's really their business. 

________________________________

From:Samita Chakrabarti <[email-masked]>
To: "Riegel, Maximilian (NSN - DE/Munich)" <[email-masked]>; ext Gabriel Montenegro <[email-masked]>; Wesley George <[email-masked]>
Cc: ext Alper Yegin <[email-masked]>; [email-masked]
Sent: Monday, May 18, 2009 11:44:47 AM
Subject: Re: [16NG] [nwg-chair] NWG feedback on 16ng's IPv4 CS draft
Hi Max,
 
As I understand from NWG feedback that they did not like IETF to recommend 1500 byte MTU size (Appendix section) for future revision of NWG Wimax specs.  Other than that there are minor editorial changes that we want to do to polish the draft. 
 
Here is the summary from NWG feedback:
> > In particular the influence of tunneling inside the network should be
> > carefully discussed.
> > In addition we would kindly ask to either remove whole Appendix C on
> > the WiMAX MTU size or revise the text explaining the real issues in
> > the WiMAX architecture. In particular the statements on the
> > applicability of the I-D on the WiMAX architecture and the
> > recommendation on future modifications in the WiMAX architecture seem
> > not to be very appropriate to us.
What is your suggestion on updating Appendix C? 
 
Thanks,
-Samita

From:Riegel, Maximilian (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Monday, May 18, 2009 12:19 AM
To: ext Gabriel Montenegro; Samita Chakrabarti; Wesley George
Cc: ext Alper Yegin; [email-masked]
Subject: RE: [16NG] [nwg-chair] NWG feedback on 16ng's IPv4 CS draft
 
Is there really a demand to work on an update of the IPv4-CS I-D?
Which details would require/qualify for an IETF specification?
The current architectural model closely resembles the WiMAX architecture, and WiMAX provides a comprehensive specification for it.
 
Bye
Max

________________________________

From:ext Gabriel Montenegro [mailto:[email-masked]] 
Sent: Friday, May 15, 2009 8:21 PM
To: Samita Chakrabarti; 'Wesley George'; Riegel, Maximilian (NSN - DE/Munich)
Cc: 'ext Alper Yegin'; [email-masked]
Subject: RE: [16NG] [nwg-chair] NWG feedback on 16ng's IPv4 CS draft
yes, I've been delinquently holding to the pen.
Lets shoot for end of the month at the latest.

________________________________

From:Samita Chakrabarti [[email-masked]]
Sent: Friday, May 15, 2009 11:15 AM
To: 'Wesley George'; 'Riegel, Maximilian (NSN - DE/Munich)'
Cc: 'ext Alper Yegin'; Gabriel Montenegro; [email-masked]
Subject: RE: [16NG] [nwg-chair] NWG feedback on 16ng's IPv4 CS draft
Hi Wes,

Yes, there will be an updated draft before Stockholm. Gabriel was working on
the updates.

I am expecting that we will soon have a revision to review.

Thanks,
-Samita

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Wesley George
> Sent: Friday, May 15, 2009 9:54 AM
> To: Riegel, Maximilian (NSN - DE/Munich)
> Cc: ext Alper Yegin; ext Gabriel Montenegro; [email-masked]
> Subject: Re: [16NG] [nwg-chair] NWG feedback on 16ng's IPv4 CS draft
> 
> Is someone working on an updated version of this draft to be reviewed in
> Stockholm since we did not meet in SFO? I believe that one of the first
> times that I submitted objections to the MTU language, I provided a
proposed
> text that would cover some of the concerns raised below, not all of which
> was included in subsequent drafts.
> http://www.ietf.org/mail-archive/web/16ng/current/msg00824.html
> 
> Thanks,
> Wes
> 
> _________________________________________
>    Wesley George
>        Sprint IP Engineering
>    703-689-7505 (O)  703-864-4902 (PCS)
>          http://www.sprint.net/
> _________________________________________
> 
> 
> On Thu, 12 Feb 2009, Riegel, Maximilian (NSN - DE/Munich) wrote:
> 
> > Gabriel,
> >
> > The WiMAX Forum NWG reviewed section 4-3 and Appendix C of
> > draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-04.txt and would like to
> > make a couple of remarks on the MTU issue:
> >
> > - The I-D is not very clear about the MTU issues appearing in an IPv4
> > over IEEE 802.16 transmission system. The ambiguities mainly result
> > out of the vague definition of the IEEE 802.16 link comprising both
> > the radio part of the link as well as the part of the link between BS
> > and AR, when the functions are located in different entities.
> >
> > - Section 4.3 in particular misses the discussion of the dependencies
> > between MTU size and the tunneling protocol deployed between BS and AR.
> >
> > - Section 4.3 also misses, that there is no packet loss when the MTU
> > size limitation is caused by the encapsulation overhead on the link
> > between BS and AR. E.g. when GRE is used for the tunnel between BS and
> > AR, the transport IP layer can fragment the GRE packets to fit the
> > transport MTU on the link between BS and AR. Reassembly in the tunnel
> > endpoint at the AR will re-establish the original user IP packet.
> >
> > - Please note that the reason of the WiMAX NWG to limit the MTU going
> > over IPv4-CS to 1400 Bytes was to avoid fragmentation on the link
> > between BS and ASN-GW as well as on the link between ASN-GW and CSN
> > (MIP tunnel). Fragmentation and re-assembly require considerable
> > processing power in the network elements.
> >
> > - Appendix C makes statements which would require more detailed review
> > of the I-D by WiMAX NWG. In particular 'The addressing and operation
> > of IPv4-CS described in this document are applicable to the WiMAX
> > networks as well' has not been verified yet.
> > Furthermore 'Thus, WiMAX MS nodes should use this default (1400) MTU
> > value per the current specification [WMF].  However, due to reasons
> > specified in section 4.3 above, it is strongly recommended that future
> > WiMAX MS nodes support a default MTU of 1500 bytes, and that they
> > implement MTU negotiation capabilities as mentioned in this document.'
> > makes recommendations to WiMAX without understanding the real reasons
> > for the limitation of the MTU size in Mobile WiMAX.
> >
> > We would recommend to 16ng to revise the sections on MTU size to
> > better explain the underlying issues leading to restrictions in the MTU
> size.
> > In particular the influence of tunneling inside the network should be
> > carefully discussed.
> > In addition we would kindly ask to either remove whole Appendix C on
> > the WiMAX MTU size or revise the text explaining the real issues in
> > the WiMAX architecture. In particular the statements on the
> > applicability of the I-D on the WiMAX architecture and the
> > recommendation on future modifications in the WiMAX architecture seem
> > not to be very appropriate to us.
> >
> >
> > Bye
> > Max
> > Vize Chair NWG
> >
> >
> > ________________________________
> >
> > From: ext Gabriel Montenegro [mailto:[email-masked]]
> > Sent: Monday, November 03, 2008 11:59 AM
> > To: [email-masked]
> > Cc: 'Daniel Soohong Park'
> > Subject: [nwg-chair] NWG feedback on 16ng's IPv4 CS draft
> >
> >
> >
> > Prakash, Max and Yong Chang,
> >
> >
> > The IETF 16ng WG has published a revision of this draft:
> >
> > "Transmission of IPv4 packets over IEEE 802.16's IP Convergence
> > Sublayer"
> >
> > Per this announcement:
> >
> > http://www.ietf.org/mail-archive/web/16ng/current/msg00863.html
> > <http://www.ietf.org/mail-archive/web/16ng/current/msg00863.html>
> >
> > We understand that this specification currently is not normative to
> > NWG (as opposed to RFC5121 on IPv6 CS). Nevertheless, given its
> > relevance, and with the hope it may become normative to NWG in some
> > future revision, the 16ng WG would like to solicit feedback from NWG
> > on this draft.
> >
> > In particular, please note that this draft specifies a default MTU of
> > 1500,  which is different from the WiMAX-specified MTU of 1400 (per
> > the recently approved R1_V1.3.0-Stage-3  NWG specifications).  For MTU
> > discussion, please refer to these sections:
> >
> > http://tools.ietf.org/html/draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-0
> > 4#
> > section-4.3
> > <http://tools.ietf.org/html/draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-
> > 04
> > #section-4.3>
> > http://tools.ietf.org/html/draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-0
> > 4#
> > appendix-C
> > <http://tools.ietf.org/html/draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-
> > 04
> > #appendix-C>
> >
> > The 16ng WG will next meet on Nov 18 during the IETF in Minneapolis
> > (https://datatracker.ietf.org/meeting/73/agenda.html). If at all
> > possible, it would be best if comments were received before that date
> > in order for the WG to discuss them during the meeting.
> >
> > Please send your comments to the [email-masked] <mailto:[email-masked]>
> > mailing list.
> >
> > Thanks,
> >
> > Gabriel and Daniel
> > 16ng co-chairs
> >
> >
> >
> >
> _______________________________________________
> 16NG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/16ng

---

From: Wesley George <[email-masked]>
Date: Thu, 4 Jun 2009 09:24:37 -0400 (EDT)

Gabriel - this looks good to me. The only point/recommendation I might
make for the MTU section is that currently, it focuses only on solutions
that enable the End Host to determine or be advised of the path MTU. It
would be good to also recommend something regarding the underlying network
between the MS and the BS.
What I mean by this is, if the implementor of the 802.16 network either
knows or has control over the MTU of the transport method between the BS
and the MS, they should be able to either set the MTU on the transport
network so that it is higher than 1500 + any encapsulation overhead, or
ensure that it fragments larger PDUs properly. Obviously, the latter will
not work if the DF bit is set, so perhaps we leave out the discussion of
fragmentation altogether, but I do think it's worth mentioning that
raising the MTU of the transport network is a viable alternative to using
some means to communicate a non-default MTU to the MS.

Perhaps right before "Some of the mechanisms..." you could add
something like this:

With an end host MTU of 1500 bytes, the underlying network between the 
BS and the MS MUST support an MTU of at least 1500 bytes plus the overhead 
of any chosen encapsulation method between the BS and MS. 
For ease of standardization, the underlying network SHOULD support an MTU 
of at least 100 bytes larger than the chosen host MTU value, as this is 
large enough to ensure that there is no dropping or fragmentation of 
oversize packets regardless of the encapsulation method.
If it is not possible to change the MTU of the network segments between 
the BS and the MS, then a lower-than-default MTU must be used and 
communicated to the IPv4 CS host.

(then, "Some of the mechanisms available...")

Thanks,
Wes

         http://www.sprint.net

Appendix on WiMAX MTU.
Got rid of:

thanks,

Gabriel

 
 
Bye
Max

Agreed. 
 
Thanks,
-Samita

 

Thanks,
-Samita

 
Bye
Max

Thanks,
-Samita

proposed

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 9 Jun 2009 09:38:07 -0700 (PDT)

Hi George, thanks for the comments.

About your suggestion for text to mitigate fragmentation in the presence of tunneling:
I discussed this recently with the ADs. Jari's comment was that given that the issue is
general for tunneling, and not specific to 802.16, we don't actually need to say anything.
That seemed to be his preference. It is mine too, as we've learned that saying less is
often times better. 

If anything, I would rather add a relevant *informative* reference instead of adding any text that may
be inconclusive.

For example, one could think of referring interested readers to:
 
MTU and Fragmentation Issues with In-the-Network Tunneling
http://tools.ietf.org/html/rfc4459 
But I don't even know if that is the more appropriate text one would want to point at.
I'm cc-ing the author, Pekka Savola, as he may have some more current info for us.
 
Gabriel

----- Original Message ----
> From: Wesley George <[email-masked]>
> To: gabriel montenegro <[email-masked]>
> Cc: "Riegel, Maximilian (NSN - DE/Munich)" <[email-masked]>; ext Samita Chakrabarti <[email-masked]>; ext Alper Yegin <[email-masked]>; [email-masked]
> Sent: Thursday, June 4, 2009 6:24:37 AM
> With an end host MTU of 1500 bytes, the underlying network between the BS and 
> the MS MUST support an MTU of at least 1500 bytes plus the overhead of any 
> chosen encapsulation method between the BS and MS. For ease of standardization, 
> the underlying network SHOULD support an MTU of at least 100 bytes larger than 
> the chosen host MTU value, as this is large enough to ensure that there is no 
> dropping or fragmentation of oversize packets regardless of the encapsulation 
> method.
> If it is not possible to change the MTU of the network segments between the BS 
> and the MS, then a lower-than-default MTU must be used and communicated to the 
> IPv4 CS host.
> 
> relevant sections in IEEE802.16, 5121 and 5154. No need to repeat text that 
> appears elsewhere.
> 
> From: gabriel montenegro 
> To: "Riegel, Maximilian (NSN - DE/Munich)" ; ext 
> Samita Chakrabarti ; Wesley George 
> Cc: ext Alper Yegin ; [email-masked]
> From: "Riegel, Maximilian (NSN - DE/Munich)" 
> To: ext Samita Chakrabarti ; gabriel montenegro 
> ; Wesley George 
> Cc: ext Alper Yegin ; [email-masked]
> My point is not the MTU size, I am concerned about the quality of the current 
> document. There are a number of ambiguities and misconceptions, which would 
> require some efforts for resolving. I once did an approach to create a 
> submission to the mailing list and gave up after an hour seeing that it requires 
> more text to explain the issues in the document than just rephrasing the text.
>  
> From: ext Samita Chakrabarti [mailto:[email-masked]] Sent: Tuesday, May 
> 19, 2009 11:59 PM
> Agreed. Default MTU is 1500  - if WiMAX does not want to update their SPEC or 
> does not want to conform to this IETF draft, it is SDO business. Thus we can 
> move forward  independently.
>  
> Thanks,
> -Samita
>  
> From:gabriel montenegro [mailto:[email-masked]] Sent: Tuesday, May 19, 
> 2009 9:39 AM
> some overlap with the WiMAX spec. We should simply refer to WiMAX for the 
> WiMAX-specifics, and drop the recommendation that WiMAX should adopt this spec. 
> Given the difference in MTU,
> From:Samita Chakrabarti 
> To: "Riegel, Maximilian (NSN - DE/Munich)" ; ext 
> Gabriel Montenegro ; Wesley George 
> 
> Cc: ext Alper Yegin ; [email-masked]
> As I understand from NWG feedback that they did not like IETF to recommend 1500 
> byte MTU size (Appendix section) for future revision of NWG Wimax specs.  Other 
> than that there are minor editorial changes that we want to do to polish the 
> draft.  
> The current architectural model closely resembles the WiMAX architecture, and 
> WiMAX provides a comprehensive specification for it.
>  
> Bye
> Max
>  
> 
> From:ext Gabriel Montenegro [mailto:[email-masked]] Sent: 
> Friday, May 15, 2009 8:21 PM
> > > Please send your comments to the [email-masked] 
> > > mailing list.
> > >
> > > Thanks,
> > >
> > > Gabriel and Daniel
> > > 16ng co-chairs
> > >
> > >
> > >
> > >

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Jun 2009 13:50:29 +0300 (EEST)

> I'm cc-ing the author, Pekka Savola, as he may have some more current info for us.

In developing a protocol, I personally think the protocol 
specification should decide a model to be adopted either in the 
protocol or in operating the protocol, or just explicitly leave the 
issue open. RFC4459 just lists some alternatives and their tradeoffs.

Apart from that there isn't much to add.  There's a bit more recent 00 
draft that also discusses tunnels from an architectural and less 
practical perspective, but I'm not sure if it provides any more 
information than the RFC above: draft-touch-intarea-tunnels-00.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Wesley George <[email-masked]>
Date: Wed, 10 Jun 2009 12:57:50 -0400 (EDT)

I can appreciate that approach. I didn't really consider that we might be 
reinventing the wheel. *blush*
I think a reference to some issues that the implementor should be aware 
of is better than no mention of them so probably since the below is still 
in draft, the RFC is better than nothing.

Thanks,
Wes

On Wed, 10 Jun 2009, Pekka Savola wrote:

> In developing a protocol, I personally think the protocol specification 
> should decide a model to be adopted either in the protocol or in operating 
> the protocol, or just explicitly leave the issue open. RFC4459 just lists 
> some alternatives and their tradeoffs.
>
> Apart from that there isn't much to add.  There's a bit more recent 00 draft 
> that also discusses tunnels from an architectural and less practical 
> perspective, but I'm not sure if it provides any more information than the 
> RFC above: draft-touch-intarea-tunnels-00.
>
>
> --

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 10 Jun 2009 10:31:56 -0700 (PDT)

I'll add a reference to the RFC with language to the effect that it is just one possible source of information.

----- Original Message ----
> To: Pekka Savola <[email-masked]>
> Cc: gabriel montenegro <[email-masked]>; "Riegel, Maximilian (NSN - DE/Munich)" <[email-masked]>; ext Samita Chakrabarti <[email-masked]>; ext Alper Yegin <[email-masked]>; [email-masked]
> Sent: Wednesday, June 10, 2009 9:57:50 AM
> I think a reference to some issues that the implementor should be aware of is 
> better than no mention of them so probably since the below is still in draft, 
> the RFC is better than nothing.
> 
> Thanks,
> Wes
> 
> > In developing a protocol, I personally think the protocol specification should 
> decide a model to be adopted either in the protocol or in operating the 
> protocol, or just explicitly leave the issue open. RFC4459 just lists some 
> alternatives and their tradeoffs.
> > 
> perspective, but I'm not sure if it provides any more information than the RFC 
> above: draft-touch-intarea-tunnels-00.
> > 
> > 
> > -- Pekka Savola                "You each name yourselves king, yet the