Subject: [Int-area] Comments on INT Area Tunnels draft: aft-ietf-intarea-tunnels-09

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 16 Apr 2019 12:28:28 +0100

I have read draft-ietf-intarea-tunnels-09, because it is cited from 
another document that I am reviewing. I have a number of comments that 
I’d like to pass to the WG/editors for consideration, I also have a few 
more technical questions, that I will post later.

--- My first top-level comment is that I fear a small part of the 
language in the document could put some readers off because it seems to 
go-back-in-time to cite early ways of describing networks, which I think 
could be easily tuned to avoid this and make it much more accessible to 
younger folk - who probably are a really important audiance (see NiTs 
below).
--- There are places where IPv4 language is used, and I'd prefer to make 
sure that IPv6 is regarded as equally in all places (see NiTs).
--- It would be good to refer to and clarify the recommendations in 
[I-D.ietf-tsvwg-ecn-encap-guidelines], 
[I-D.ietf-tsvwg-rfc6040update-shim] and 
[I-D.ietf-tsvwg-datagram-plpmtud] witin TSVWG, and also IP Fragmentation 
Considered Fragile [I-D.ietf-intarea-frag-fragile-09].

Best wishes,

Gorry

---
"The opening sentence of the Introduction states “The Internet layering 
architecture is loosely based on the ISO seven
layer stack, in which data units traverse the stack by being wrapped
inside data units of the next layer down [Cl88][Zi80]”.

- While I totally agree with the observation, I wonder about the 
prudence in starting the Intro with this sentence. For many years 
Universities (at least where I have been) have taught the ISO model as a 
formal protocol stack as well as an architectural model. That’s not 
common anymore, and starting with a historical fact can actually deter 
“younger” readers.
- The text could you say something like:

“The Internet layering architecture follows a layered model, in which 
data units traverse a stack by being wrapped inside data units of the 
next layer down [Cl88][Zi80]”.

- and later, this strikes me as somewhat old-fashioned:
“ Such descriptions can help explain
behavior, as when the OSI seven-layer model is used as a teaching
example [Zi80].”

- and again:
“An Internet gateway is an OSI Layer 3 router when it
transits IP datagrams but it acts as an OSI Layer 2 host as it
sources or sinks Layer 2 messages on attached links to accomplish
this transit capability. “
- That’s pretty old-fashioned language for a reader in 2019, and 
definitely not the language that anyone brought up with IPv6 would
recognise. Since those early days “gateway” has had different 
interpretations by different readers - and that’s even more so today.

---
- Similarly, this seems quaint:
“There is essentially no difference between a tunnel and
the conventional layering of the ISO stack (i.e., by this
definition, Ethernet is can be considered tunnel for IP).”
- Is it talking about protocol encapsulation? In 2019 do we need to 
mention the ISO Stack?
-------------------------------

- The multicast discussion is split between two parts fo the intro. The 
phrases:
“Tunnels allowed multicast
packets to transit efficiently between multicast-capable routers over
paths that did not support native link-layer multicast.”
... introduce multicast before the list of protocols, but the discussion 
of multicast continues after more current examples in
“The first attempt to use large-scale tunnels was to transit multicast
traffic across the Internet in 1988 “
- Could these two be combined?
--
- I suspect the sentence mentioning IPv6 transition will be more 
familiar than mulkticast to many, maybe it could be a separate para?
“Similar
techniques have been used to support incremental deployment of other
protocols over legacy substrates, such as IPv6 [RFC2546].”
---
“Link packet: a link layer message, which can carry an IP datagram
as a payload”
- I would expect many know this as a link frame, should this also be 
mentioned?
---
In bullet “Ingress”:
- Is “physical link” defined? The use of physical and virtual may be 
important concepts, and could benefit from being defined, or a few words 
added here.
---
- The statement:
“To the extent that
the Internet has a single, coherent interpretation, its architecture
is defined by its core protocols “
- The meaning seems clear, but the following list omits mention of the 
IPv6 Stack completely. That strikes me as really needing to be at least 
mentioned as *the* architecture for the Internet.
---
In section 3.3:
“so both are viewed as hosts on network N (Figure 7).
Consequently [RFC1122]”
- is this the same in IPv6? (I think so, please can we cite an RFC?)
and:
“Because routers, not links, alter hop counts [RFC1812],”
- please add IPv6 language and reference.
“it must satisfy all
requirements expected of a link [RFC1122][RFC3819].”
- and IPv6 reference?
---
In section 4.1.1:
“When feedback is received from these fields,”
- Please explain “feedback” here, this was not clear by what mechanism 
and at what point along the path.
---
In section 4.1.1:
“There are exceptions to this rule that are explicitly intended to
relay signals from inside the tunnel to the network outside the
tunnel,”
- I think this refers to an action at the tunnel egress.
---
In section 4.1.2:
- When referring to [RFC6040] it would be useful to also reference this 
BCP-to-be (to be WGLC’ed shortly in tsvwg:
[I-D.ietf-tsvwg-ecn-encap-guidelines]
and
[I-D.ietf-tsvwg-rfc6040update-shim]
Which is a standards track specification that will update existing 
IP-shim-(L2)-IP protocols.

- Although there consider more than this document, referencing them 
ensures that readers do not overlook them.
---
In section 4.1.2:
“interfaces of the router [RFC1122].”
- Please add IPv6 node reference.
---
In section 4.1.3:
“A router is
required to decrement the TTL by at least one or the number of
seconds the packet is delayed, whichever is larger [RFC1812].”
- Please insert “IPv4” router. I’d actually personally prefer the text 
to say that RFC 1812 required that an IPv4 router..”
---
“(link-local discovery and related protocols [RFC4861]).”
- Please cite The Generalized TTL Security Mechanism (GTSM)
RFC 5082 as the reference and ND as an example.
---
“ The uniqueness of the IP ID is a known problem for high speed nodes,
because it limits the speed of a single protocol between two
endpoints [RFC4963]. “
- I’d quibble - I think it is more accurate to say it *can* limit the 
speed when this field is used to uniquely identify packets in flight (e.g.
when fragmentation is enabled).
---
In section 4.1.5:
- I’m cautious about the text below, because the other danger is to any 
other receiving process on the same node receiving corrupted packets:
“For this reason, it is safe to use UDP with a zero checksum for
atomic tunnel link packets only;”
- Could we cite [RFC6936] again after this to be sure the context is 
understood?
---
“(PLMTUD) [RFC4821]”
- I think we should also cite: ietf-tsvwg-datagram-plpmtud.
---
In section 4.2.2:
“ As a
link in network M, transit packets might be fragmented before they
reach the tunnel..”
- I found that sentence hard to parse and rather long. Maybe it was 
because it starts with “As a...” - is it possible to rephrase?
---
“A router
attempting to process such a message would already have generated an
ICMP "packet too big" and the transit packet would have been dropped
before entering into this algorithm.”
- Not quite my understanding because of the wording, would this text be OK?:
“A router
attempting to process such a packet should already have
generated an
ICMP "packet too big" message and the transit packet would have
been dropped before entering into this algorithm.”
---
- NiT:
“ Some messages have detailed specifications for relaying between the
tunnel link packet and transit packet, including Explicit Congestion
Notification (ECN [RFC6040]) and multicast (IGMP, e.g.).”
- Is it necessary to add IGMP as an example here? (I’m really unsure).
- If you think this is useful can you relate to RFC 7450 - because that 
is being deployed and is a PS for tunnels.
“IGMP snooping enables IP multicast and also please add "and MLD” after 
IGMP.
---
In section 4.3.3:
- It would be good to add a reference to RFC 8085 for multicast CC, 
citing section 4 of RFC 8085 contains guidance on congestion control for 
multicast tunnels.
---
- NiT:
“It is useful to relay network congestion notification between the
tunnel link and the tunnel transit packets.”
- Please cite the RFCs and IDs on this - e.g. ECN RFCs cited earlier. I 
think you’ll find there are requirements, rather than “useful” comments.
-----------

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Apr 2019 08:12:56 -0700

Hi, Gorry,

Thank you for the deep feedback - I’ve been waiting for this sort of input for quite a long time (from the community as a whole)...

> On Apr 16, 2019, at 4:28 AM, gorry Fairhurst <[email-masked]> wrote:
> 
> 
> I have read draft-ietf-intarea-tunnels-09, because it is cited from another document that I am reviewing. I have a number of comments that I’d like to pass to the WG/editors for consideration, I also have a few more technical questions, that I will post later.
> 
> --- My first top-level comment is that I fear a small part of the language in the document could put some readers off because it seems to go-back-in-time to cite early ways of describing networks, which I think could be easily tuned to avoid this and make it much more accessible to younger folk - who probably are a really important audiance (see NiTs below).

I’ll look; it certainly is important to start with Internet terms (gateway, datagram, etc.) before jumping into more recent terms.

> --- There are places where IPv4 language is used, and I'd prefer to make sure that IPv6 is regarded as equally in all places (see NiTs).

Agreed,

> --- It would be good to refer to and clarify the recommendations in [I-D.ietf-tsvwg-ecn-encap-guidelines], [I-D.ietf-tsvwg-rfc6040update-shim] and [I-D.ietf-tsvwg-datagram-plpmtud] witin TSVWG, and also IP Fragmentation Considered Fragile [I-D.ietf-intarea-frag-fragile-09].

Certainly - thanks for noting that. The doc has been in development over an absurdly long time (due to waxing and waning IETF interest), but I do hope we can wrap things up now that there seems to be broader interest.

Further notes below...

> —

> "The opening sentence of the Introduction states “The Internet layering architecture is loosely based on the ISO seven
> - While I totally agree with the observation, I wonder about the prudence in starting the Intro with this sentence. For many years Universities (at least where I have been) have taught the ISO model as a formal protocol stack as well as an architectural model. That’s not common anymore, and starting with a historical fact can actually deter “younger” readers.
- this remains the dominant model for teaching (top-down or bottom-up)
- I know of only one teaching approach and textbook that do not use that model (and it’s mine and under development ;-)

> “The Internet layering architecture follows a layered model, in which data units traverse a stack by being wrapped inside data units of the next layer down [Cl88][Zi80]”.

It’s important to refer to the ISO 7-layer stack because it remains dominant in protocol stack descriptions (even the idea of a protocol stack, inaccurate as it is, is based thereon).

> this transit capability. “

See above.

> - That’s pretty old-fashioned language for a reader in 2019, and definitely not the language that anyone brought up with IPv6 would
> recognise. Since those early days “gateway” has had different interpretations by different readers - and that’s even more so today.

Agreed; I’ll provide a translation table up front and use more modern terms.

> - Is it talking about protocol encapsulation? In 2019 do we need to mention the ISO Stack?

We do - the stack is an ISO concept.

Yes, this refers to protocol encapsulation.

Note that this sentence is fundamental to much of the rest of the document - i.e., if you get tunneling right, you can’t tell the difference between running over a tunnel vs. running over the next protocol layer down.

> - The multicast discussion is split between two parts fo the intro. The phrases:
> ... introduce multicast before the list of protocols, but the discussion of multicast continues after more current examples in

Probably - I’ll check.

> --
> - I suspect the sentence mentioning IPv6 transition will be more familiar than mulkticast to many, maybe it could be a separate para?
> “Similar

Sure.

> - I would expect many know this as a link frame, should this also be mentioned?

I’ll add that to the terms; some links use frames (Ethernet, SONET); others use cells (ATM), and others use packets. I

> ---
> In bullet “Ingress”:
> - Is “physical link” defined? The use of physical and virtual may be important concepts, and could benefit from being defined, or a few words added here.

Will do.

> - The meaning seems clear, but the following list omits mention of the IPv6 Stack completely. That strikes me as really needing to be at least mentioned as *the* architecture for the Internet.

Will do.

> - is this the same in IPv6? (I think so, please can we cite an RFC?)

Yes - thankfully there now is such a doc (RFC6434).

(there wasn’t when I started this doc in 2008)

> - please add IPv6 language and reference.

Will do - though this is only a draft right now (draft-ietf-v6ops-ipv6rtr-reqs) and it expired last year.

> requirements expected of a link [RFC1122][RFC3819].”

See above...

> - Please explain “feedback” here, this was not clear by what mechanism and at what point along the path.

Will do.

> - I think this refers to an action at the tunnel egress.

Both ingress and egress. Will clarify.

> ---
> In section 4.1.2:
> - When referring to [RFC6040] it would be useful to also reference this BCP-to-be (to be WGLC’ed shortly in tsvwg:
> Which is a standards track specification that will update existing IP-shim-(L2)-IP protocols.
> 
> - Although there consider more than this document, referencing them ensures that readers do not overlook them

Will do.

> .

Will do (see above).

> - Please insert “IPv4” router. I’d actually personally prefer the text to say that RFC 1812 required that an IPv4 router..”

WIll do, though I tend to not use RFCs in the text (only as references).

> RFC 5082 as the reference and ND as an example.

Will do.

> - I’d quibble - I think it is more accurate to say it *can* limit the speed when this field is used to uniquely identify packets in flight (e.g.

Will do - again, this should refer to RFC6864, which didn’t exist when we started this trek...

> ---
> In section 4.1.5:
> - I’m cautious about the text below, because the other danger is to any other receiving process on the same node receiving corrupted packets:
> - Could we cite [RFC6936] again after this to be sure the context is understood?

Will do.

> - I think we should also cite: ietf-tsvwg-datagram-plpmtud.

Will do.

> - I found that sentence hard to parse and rather long. Maybe it was because it starts with “As a...” - is it possible to rephrase?

Will do.

> been dropped before entering into this algorithm.”

I’ll check and make sure it’s more clear.

> - Is it necessary to add IGMP as an example here? (I’m really unsure).

It is, IMO - it is a signaling protocol that we tend to ignore and one of the ways in which tunnels can break where (real) links work if we don’t get it right.

> - If you think this is useful can you relate to RFC 7450 - because that is being deployed and is a PS for tunnels.

Will do.

> “IGMP snooping enables IP multicast and also please add "and MLD” after IGMP.

Will do.

> ---
> In section 4.3.3:
> - It would be good to add a reference to RFC 8085 for multicast CC, citing section 4 of RFC 8085 contains guidance on congestion control for multicast tunnels.

Will do.

> - Please cite the RFCs and IDs on this - e.g. ECN RFCs cited earlier. I think you’ll find there are requirements, rather than “useful” comments.

There are some, but not all the ones that are needed IMO. And frankly I haven’t checked to make sure that all the docs in this space are actually correct — taking a look at the list of errors that were not noticed in previous standards, I’d want to either cite them as “like these docs” or need to check them to make sure of the details before citing them as recommended by **this* doc.

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 17 Apr 2019 08:08:25 +0100

Thanks Joe, see below.

On 16/04/2019, 16:12, Joe Touch wrote:
> Hi, Gorry,
>
> Thank you for the deep feedback - I’ve been waiting for this sort of 
> input for quite a long time (from the community as a whole)...
>
>> On Apr 16, 2019, at 4:28 AM, gorry Fairhurst <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>> another document that I am reviewing. I have a number of comments 
>> that I’d like to pass to the WG/editors for consideration, I also 
>> have a few more technical questions, that I will post later.
>>
>> language in the document could put some readers off because it seems 
>> to go-back-in-time to cite early ways of describing networks, which I 
>> think could be easily tuned to avoid this and make it much more 
>> accessible to younger folk - who probably are a really important 
>> audiance (see NiTs below).
>
> I’ll look; it certainly is important to start with Internet terms 
> (gateway, datagram, etc.) before jumping into more recent terms.
>
>> --- There are places where IPv4 language is used, and I'd prefer to 
>> make sure that IPv6 is regarded as equally in all places (see NiTs).
>
> Agreed,
>
>> [I-D.ietf-tsvwg-datagram-plpmtud] witin TSVWG, and also IP 
>> Fragmentation Considered Fragile [I-D.ietf-intarea-frag-fragile-09].
>
> Certainly - thanks for noting that. The doc has been in development 
> over an absurdly long time (due to waxing and waning IETF interest), 
> but I do hope we can wrap things up now that there seems to be broader 
> interest.
>
> Further notes below...
>
>>
>> Best wishes,
>>
>> Gorry
>>
>> —
>
>> "The opening sentence of the Introduction states “The Internet 
>> layering architecture is loosely based on the ISO seven
>> Universities (at least where I have been) have taught the ISO model 
>> as a formal protocol stack as well as an architectural model. That’s 
>> not common anymore, and starting with a historical fact can actually 
>> deter “younger” readers.
> - I know of only one teaching approach and textbook that do not use 
> that model (and it’s mine and under development ;-)
>
You may not be as alone as you feel on this.
> It’s important to refer to the ISO 7-layer stack because it remains 
> dominant in protocol stack descriptions (even the idea of a protocol 
> stack, inaccurate as it is, is based thereon).
>
>>
The stack of protocols have long since died... the reference model 
wasn't bad... encapsulation and layering remain. Anyway, to me the 
really important thing fr is that people find and then read the 
RFC-to-be and read past the start of the introduction to take away the 
important recommendations. I suspect some checking can separate 
historical context from providing a motivation to read.
> Note that this sentence is fundamental to much of the rest of the 
> document - i.e., if you get tunneling right, you can’t tell the 
> difference between running over a tunnel vs. running over the next 
> protocol layer down.
>
>> ... introduce multicast before the list of protocols, but the 
>> discussion of multicast continues after more current examples in
> I’ll add that to the terms; some links use frames (Ethernet, SONET); 
> others use cells (ATM), and others use packets. I
>
>> ---
>> In bullet “Ingress”:
>> important concepts, and could benefit from being defined, or a few 
>> words added here.
>
> Will do.
>
>> ---
>> - The statement:
>> “To the extent that
>> - The meaning seems clear, but the following list omits mention of 
>> the IPv6 Stack completely. That strikes me as really needing to be at 
>> least mentioned as *the* architecture for the Internet.
>
> Will do.
>
>> ---
>> In section 3.3:
> Will do - though this is only a draft right now 
> (draft-ietf-v6ops-ipv6rtr-reqs) and it expired last year.
>
>> “it must satisfy all
>> - Please explain “feedback” here, this was not clear by what 
>> mechanism and at what point along the path.
>
> Will do.
>
>> ---
>> In section 4.1.1:
Ah yes - that should be written about.
>
>> ---
>> In section 4.1.2:
>> - When referring to [RFC6040] it would be useful to also reference 
>> this BCP-to-be (to be WGLC’ed shortly in tsvwg:
>> ensures that readers do not overlook them
>
> Will do.
>
>> .
>> ---
>> In section 4.1.2:
>> - Please insert “IPv4” router. I’d actually personally prefer the 
>> text to say that RFC 1812 required that an IPv4 router..”
>
>> - I’m cautious about the text below, because the other danger is to 
>> any other receiving process on the same node receiving corrupted packets:
> It is, IMO - it is a signaling protocol that we tend to ignore and one 
> of the ways in which tunnels can break where (real) links work if we 
> don’t get it right.
>
>> - If you think this is useful can you relate to RFC 7450 - because 
>> that is being deployed and is a PS for tunnels.
>
> Will do.
>
>> citing section 4 of RFC 8085 contains guidance on congestion control 
>> for multicast tunnels.
>
> Will do.
>
>> ---
>> - NiT:
>> - Please cite the RFCs and IDs on this - e.g. ECN RFCs cited earlier. 
>> I think you’ll find there are requirements, rather than “useful” 
>> comments.
>
> There are some, but not all the ones that are needed IMO. And frankly 
> I haven’t checked to make sure that all the docs in this space are 
> actually correct — taking a look at the list of errors that were not 
> noticed in previous standards, I’d want to either cite them as “like 
> these docs” or need to check them to make sure of the details before 
> citing them as recommended by **this* doc.
>
>> -----------
>>
>>
Gorry