Subject: [v6ops] new draft: draft-binet-v6ops-cellular-host-requirements

From: <[email-masked]>
Date: Mon, 12 Nov 2012 05:45:01 -0800 (PST)

A new draft has been posted, at http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements. Please take a look at it and comment.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 13 Nov 2012 08:50:35 -0800

Hi,

At IETF85, I presented: "Operational Issues with Tunnel Maximum
Transmission Unit (MTU)" (draft-generic-v6ops-tunmtu). Since that
time, I have re-discovered RFC4459 ("MTU and Fragmentation Issues
with In-the-Network Tunneling") which covers four possible tunnel
MTU mitigations:

  "1.  Fragmenting all too big encapsulated packets to fit in the paths,
       and reassembling them at the tunnel endpoints.

   2.  Signal to all the sources whose traffic must be encapsulated, and
       is larger than fits, to send smaller packets, e.g., using Path
       MTU Discovery (PMTUD)[7][8].

   3.  Ensure that in the specific environment, the encapsulated packets
       will fit in all the paths in the network, e.g., by using MTU
       bigger than 1500 in the backbone used for encapsulation.

   4.  Fragmenting the original too big packets so that their fragments
       will fit, even encapsulated, in the paths, and reassembling them
       at the destination nodes.  Note that this approach is only
       available for IPv4 under certain assumptions (see Section 3.4)."

To avoid covering some of the same ground already examined by RFC4459,
I have therefore re-scoped draft-generic-v6ops-tunmtu to look at the
only solution alternative that can be applied generically; namely,
tunnel fragmentation and reassembly.

Please have a look at the latest version of the document and comment
on the list:

https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/

This document discusses new issues that have been uncovered since
the publication of RFC4459, and also presents a new fragmentation
and reassembly alternative that was not covered by the earlier works.

Thanks - Fred
[email-masked]

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 13 Nov 2012 22:12:22 -0500

V6ops/Draft Authors,

Here are some comments on the updated draft (and it's relation to
draft-korhonen-v6ops-rfc3316bis-00).  I hope there is not too much overlap
with other comments, I have not had time to review those as of yet.

I would agree with the WG discussion that this draft
(v6ops-cellular-host-requirements) is quite different then
draft-korhonen-v6ops-rfc3316bis-00 but there is some overlap (does not
bother me as long as they are consistent where they overlap or it
references the 3316bis document and removes the local document text)

ON this draft:

SECTION 2.1 - Wi-Fi
IN section 2.1 (Wi-Fi) there is a very short set of requirements stated
for the Wi-Fi interface.  Given that this document is focused on the 3GPP
interface and operation, perhaps you can just point to RFC 6434 (IPv6 Node
Requirements).  

I note that since you don't mention SLACC in section 2.1, but do mention
DHCPv6 (I would think that SLACC is likely a good idea to specify)

Perhaps to make it easy, put RFC 6434 in REQ#19?

OVERALL

The draft seems to have a definite parallel target for 464XLAT operation.
But most of the those requirements are SHOULDs in this document.

I would think that some operators and handsets will want 464XLAT and some
may not care (I am of the former myself - I want 464XLAT).

That said, if a cell host needs to operate on a 464XLAT network, perhaps
we need MUSTs in there?

Would it make sense to spit off the requirements for 464XLAT and make them
MUSTs within that section?  Since they would be in different section, we
can say "If the cellular host is intended to support 464XLAT operation,
then the following section applies". (or something to that effect).

Regards,

Victor Kuarsingh

On 2012-11-12 8:45 AM, "[email-masked]" <[email-masked]> wrote:

>
>A new draft has been posted, at
>http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements.
>Please take a look at it and comment.
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops