Subject: [Int-area] I-D Action:draft-ietf-intarea-tunnels-00.txt

From: [email-masked]
Date: Fri, 26 Mar 2010 09:30:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Area Working Group Working Group of the IETF.

	Title           : Tunnels in the Internet Architecture
	Author(s)       : J. Touch, M. Townsley
	Filename        : draft-ietf-intarea-tunnels-00.txt
	Pages           : 22
	Date            : 2010-03-26

This document discusses the role of tunnels in the Internet
architecture. It explains their relationship to existing protocol
layers, and the challenges in supporting tunneling.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-intarea-tunnels-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 30 Mar 2010 09:09:33 -0700

Authors,

I sent these comments off-list (below), but I thought
folks on the list might want to know about the concept
of tunnel fragmentation (also raised by me at the mike
during Joe's talk). The concept was described in Section
3.1.7 of RFC2764, but did not appear in RFC4459. The
concept is now manifested in functional specification
in RFC5320 and also 'draft-templin-intarea-seal'.

Fred
[email-masked]

--- comments on 'draft-ietf-intarea-tunnels' ---

1) Section 1, s/data units other/data units of other/

2) Section 1, to the bulleted list of tunnel types, add
   as a final bullet:

    o numerous others

3) Section 3.1, paragraph beginning "A more recent
   alternative is packetization-layer path MTU discovery".
   Add the following as a trailing sentence to that
   paragraph:

   "Note that while PLPMTUD is an end-to-end MTU determination
    mechanism, it requires that any tunnels in the path present
    a consistent MTU value the same as for any link."

4) Section 3.1, paragraph beginning: "Either of these techniques
   (PMTUD, PLMTUD)", I don't agree that PLPMTUD "can be applied
   to tunnels" without adding significant extra mechanism to the
   tunnel endpoints in a manner that is not specified in RFC4821.
   Would prefer to change the first sentence of that paragraph
   to something a bit less explicit such as: "Classical MTU
   determination methods can be applied to tunnels."

5) Section 3.2, first sentence, change to: "There are three
   places where fragmentation can occur in a tunnel, called
   Outer Fragmentation, Tunnel Fragmentation, and Inner
   Fragmentation."

6) Section 3.2.1, the sentence: "These fragments are reassembled
   at the encapsulator" - should be "decapsulator".

7) There should be a new section 3.2 between the Inner/Outer
   Fragmentation sections called "Tunnel Fragmentation". This
   section should talk about a mid-layer segmentation and
   reassembly capability such as described in RFC2764,
   Section 3.1.7. This is the approach that SEAL takes, and
   I can provide text if there is interest.

8) Section 3.2.2, first sentence, I would rather think that
   inner fragmentation distributes the impact across both
   the *encapsulator* and destination, since the encapsulator
   has to perform fragmentation but the decapsulator does not
   have to reassemble (the final destination gets to do the
   reassembly). So, there is not really any impact on the
   decapsulator since all it sees are unfragmented packets.

9) Section 3.2.3, I *would not* want to see this turn into
   a recommendation for *outer* fragmentation to use the
   "Figure 6 Fragmenting Evenly" approach, since this
   destroys the ability for the far end to determine an
   MTU based on the size of the largest fragment received.
   I *would* favor the use of even fragmentation for inner
   fragmentation, however.

10) Section 3.3, the sentence: "Signals from routers
   downstream of the egress (R3 in Figure 9) need to
   traverse the tunnel in reverse." - This statement is
   not really true; the signals could just as well be
   routed through some other path that does not traverse
   the tunnel in reverse. This sentence should be
   removed.

11) Section 4.1.3, "message too big" should be changed to
   "packet too big".

12) Section 4.1.3, final paragraph, "keeping copies of
   recently sent packets" is useless if the tunnel ingress
   is using an anycast source address. This section should
   note that maintenance of tunnel soft state is incompatible
   with the use of an anycast outer source address.

13) Section 4.2.3, "message too big" => "packet too big".

14) Section 5.2, there needs to be a paragraph that talks
   about Tunnel Fragmentation (see comment 7) above).

15) Section6, "The use of PLPMTUD for tunnels". OK, I see
   now that you are contemplating an adaptation of RFC4821
   for tunnels. Robin Whittle has already done that:

   'draft-whittle-ivip-arch'

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Internet-
> [email-masked]
> Sent: Friday, March 26, 2010 9:30 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action:draft-ietf-intarea-tunnels-00.txt
>