Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-04.txt

[Joe Touch]

Hi, all,

This is a long overdue major revision of this document.

It tries to incorporate as much of the pending issues as possible.

Note: some areas near the end remain incomplete; whether they are
completed depends on whether this document remains as informational or
is decided as BCP.

Joe


On 3/13/2017 3:45 PM, internet-dra...@ietf.org wrote:
> 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 of the IETF.
>
> Title   : IP Tunnels in the Internet Architecture
> Authors : Joe Touch
>   Mark Townsley
>   Filename: draft-ietf-intarea-tunnels-04.txt
>   Pages   : 50
>   Date: 2017-03-13
>
> Abstract:
>This document discusses the role of IP tunnels in the Internet
>architecture. An IP tunnel transits IP datagrams as payloads in non-
>link layer protocols. This document explains the relationship of IP
>tunnels to existing protocol layers and the challenges in supporting
>IP tunneling, based on the equivalence of tunnels to links. The
>implications of this document are used to derive recommendations that
>update MTU and fragment issues in RFC 4459.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-intarea-tunnels-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-04
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [nvo3] Comments on draft-ietf-nvo3-gue-05

[Tom Herbert]

Hi Murray,

Thanks for the detailed reviewed! I've cc'ed int-area WG list also
since GUE in a WG item there now.

A few replies are inline...

On Wed, Mar 8, 2017 at 1:07 AM, Murray S. Kucherawy  wrote:
> Hi all,
>
> Tom asked me to review this and some related drafts.  These are mostly raw
> notes; hopefully you can make some sense of them.  If not, I'm happy to
> clarify what any of them mean.
>
> The document seems to me (with my ART area eyes) to be generally in good
> shape.  The vast majority of my feedback is editorial stuff, but there are a
> few key points I want to highlight:
>
> 1.   In a few places you use MUST, which I assume is meant to indicate a
> normative requirement.  To do that in an RFC, you have to reference RFC2119
> and include in your Introduction section some boilerplate that it specifies.
> Then, depending on how strict the IESG feels like being, all your uses of
> MUST/SHOULD/SHOULD NOT/MAY (in lowercase or in all-caps) now need to be
> all-caps (or changed to synonyms).  In addition, sometimes they would like
> you to explain,  given a SHOULD or SHOULD NOT, when one might legitimately
> deviate from that advice.  You might even be asked to explain some of the
> MUSTs if they aren’t already obvious.  In my raw notes below I've called out
> the lowercase must, may, etc. to which this applies.

Will be more specific with normative language.

> 2.   There are several acronyms that need to be expanded and/or
> references provided on first use.
> 3.   The IANA Considerations section establishes Tom as the reference
> point for the port registration, but it uses an old work email address.  If
> that’s actually in the registry, this one should update it, preferably to
> something that will be useful long-term.

Yes, we will update contact information.

> 4.   Again with the IANA Considerations section, you’re using Standards
> Action as the gate for registering anything.  The IESG might ask you to
> explain why such strict rules are being used.  Specifically, why would one
> of the lower requirements for registry changes be inadequate?

Changed to "RFC required"

> 5.   Although I think I managed to figure out the rest of the document,
> Section 3.6 confused me.  Maybe if you explain what’s going on there I can
> suggest some alternative text.

Rewrote this a bit.

> 6.   As far as I know, appendices are never normative, so there’s no
> need to say that.
>
Okay.

> -MSK
>
> Abstract:
> - such tunnels => such as tunnels
>
> Section 1:
> - such as virtual => such as a virtual (or “the”)
>
> Section 1.1:
> - don't end the "C-bit" entry with a period, or do it for all of them
>
> Section 2:
> - expand OAM on first use
> - what's going to happen when versions 2 and 3 are exhausted?
>
Then we need a new protocol :-). In reality, I think it is unlikely
this will ever happen in the lifetime of the protocol. Because GUE is
arbitrarily extensible, the version number is mostly a fail-safe so
that if we found a deficiency in the primary GUE header we could fix
this with a new version. Note that version 1 is a convenient means to
do header compression for the most common use case and not really a
another version, we don't foresee burning any more version numbers for
anything like that.

> Section 3.1:
> - do we need to define or reference a definition for "local tuple"?
> - define or reference ECMP
> - "not applied" => "not applied,"
> - using "MUST" needs a reference to RFC2119 somewhere in Section 1 with the
> usual boilerplate
> - "C-bit: When set, indicates" ...
> - Hlen: "header_len" is bytes, correct?
> - Proto/ctype: "When the C-bit is set, this ..."
> - "Flags." => "Flags:"
> - "Private data: ... If private data are present, that portion of the
> payload immediately follows the extension fields in the header.  The length
> ..."
>
> Section 3.2:
> - where are control message types enumerated?
>
> Section 3.2.1:
> - "When the C-bit is not set, the ..."
> - When the outer IP protocol is IPv4, the proto ..."
> - "the proto field can be set"
> - "MUST NOT"?
>
> Section 3.2.2:
> - "MUST"
> - include a reference to where type 0 is defined
>
> Section 3.3:
> - missing comma
> - "may"
> - "optional"
>
> Section 3.3.1:
> - "may"
> - why "may" a flag indicate the presence of an extension field?  should that
> be "some flags indicate..."?
> - "must"
> - "may" again
> - don't understand "if two flag bits are paired, a field may possibly be
> three different lengths"

I added an example.

> - "must"
> - "... for example ..." is a run-on sentence
> - "must not"
> - "may"
> - "... is set, which indicates ..."
> - don't understand how I would know bits 17-19 are paired
>
> Section 3.4:
> - "may"
> - starting sentence with "Where"
> - "... necessary, for instance it might contain ..."
> - "... from an encapsulator, the packet ..."  x2
> - "may"
>
> Section 3.5.1
> - "carry formatted message" => "carry formatted data"
> - "may"
> -  the mdash needs a space before 

[Int-area] I-D Action: draft-ietf-intarea-gue-01.txt

[internet-drafts]

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 of the IETF.

Title   : Generic UDP Encapsulation
Authors : Tom Herbert
  Lucy Yong
  Osama Zia
Filename: draft-ietf-intarea-gue-01.txt
Pages   : 38
Date: 2017-03-13

Abstract:
   This specification describes Generic UDP Encapsulation (GUE), which
   is a scheme for using UDP to encapsulate packets of different IP
   protocols for transport across layer 3 networks. By encapsulating
   packets in UDP, specialized capabilities in networking hardware for
   efficient handling of UDP packets can be leveraged. GUE specifies
   basic encapsulation methods upon which higher level constructs, such
   as tunnels and overlay networks for network virtualization, can be
   constructed. GUE is extensible by allowing optional data fields as
   part of the encapsulation, and is generic in that it can encapsulate
   packets of various IP protocols.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-gue/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-intarea-gue-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gue-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[internet-drafts]

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 of the IETF.

Title   : IP Tunnels in the Internet Architecture
Authors : Joe Touch
  Mark Townsley
Filename: draft-ietf-intarea-tunnels-04.txt
Pages   : 50
Date: 2017-03-13

Abstract:
   This document discusses the role of IP tunnels in the Internet
   architecture. An IP tunnel transits IP datagrams as payloads in non-
   link layer protocols. This document explains the relationship of IP
   tunnels to existing protocol layers and the challenges in supporting
   IP tunneling, based on the equivalence of tunnels to links. The
   implications of this document are used to derive recommendations that
   update MTU and fragment issues in RFC 4459.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-intarea-tunnels-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area