ISE write-up for: draft-zhang-gre-tunnel-bonding-05
Abstract:
"There is an emerging demand for solutions that provide redundancy and
load-sharing across wired and cellular links from a single service
provider, so that a single subscriber is provided with bonded access
to heterogeneous connections at the same time.
In this document, GRE (Generic Routing Encapsulation) Tunnel Bonding
is specified as an enabling approach for bonded access to a wired and
a wireless network in customer premises, e.g. homes. In GRE Tunnel
Bonding, two GRE tunnels, one per network connection, are set up and
bonded together to form a single GRE tunnel for a subscriber.
Compared with each composing connection, the bonded connections
promise increased access capacity and improved reliability. The
solution described in this document is currently implemented by
Huawei and deployed by Deutsche Telekom AG. Publication of this
document is to enable other developers to build interoperable
implementations."
This draft has IANA Considerations, as follows:
"ANA need not to assign anything for the GRE Tunnel Bonding Protocol.
The GRE Protocol Type for the GRE Channel is set to 0xB7EA which is
under the control of IEEE Registration Authority. However, IANA may
update the "IEEE 802 Numbers" IANA web page [802Type] which is of
primarily historic interest."
This draft has an obvious overlap with the BroadBand Forum. After
a long discussion about that, David Sinicrope and I have agreed on
the following ISE Statement to be included in it:
"This document has been developed and published as an RFC using
the ‘IESG Procedures for Handling of Independent and IRTF Stream
Submissions’ (RFC 5742). As noted in RFC 5742 sec 1, “Documents
published in streams other than the IETF stream (e.g., Independent
Stream) might not receive any review by the IETF for such things as
security, congestion control, or inappropriate interaction with
deployed protocols. Generally, there is no attempt for IETF
consensus or IESG approval. Therefore, the Independent Submissions
Editor disclaims, for any of the non-IETF stream documents, any
knowledge of the fitness of those RFCs for any purpose.
It is recommended RFC 5742 be consulted for further information
regarding publications from this stream. Use of this document as
a normative reference, in particular from other normative standards,
is discouraged."
The draft was reviewed for me by Stewart Bryant, Adrian Farrel and
Ralph Droms. Their reviews are appended below; its authors have made
the changes to address the reviewers concerns.
- - - - -
Stewart Bryant's review:
Overall, I think that this is a well written document, and should be
published. It is well suited to the Independent stream, although
as information to the community on a deployed protocol, it could
just as easily have been adopted by an AD and published via that route.
Please look for SB> for some minor comments.
The GRE header [RFC2890] is used to encapsulate data packets. The
Protocol Type is either 0x0800 [RFC2784] or 0x86DD [RFC7676], which
indicates the inner packet is either an IPv4 packet or an IPv6
packet. The Key field is set to a unique value for the entire bonding
connection. The Sequence Number field is used to maintain the
sequence of packets transported in all GRE tunnels as a single flow
between the HG and the HAAP.
SB> It would be good to note that this is the GRE s/n field.
==========
4.3. Traffic Classification and Distribution
For the offloading use case, the coloring mechanism specified in
[RFC2698] is being used to classify subscriber's IP packets, both
upstream and downstream, into the DSL GRE tunnel or the LTE GRE
tunnel. Packets colored as green will be distributed into the DSL GRE
tunnel and packets colored as yellow will be distributed into the LTE
GRE tunnel. For the scenario that requires more than two GRE tunnels,
multiple levels of token buckets might be realized. However, that is
out of the scope for this document.
SB> Might be good to clarify that this is RFC2698 token bucketsss
=============
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| |K|S| Reserved0 | Ver | Protocol Type 0xB7EA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SB> The above is a little confusing. You correctly say that the key
SB> is optional in the base protocol, but in this instantiation it
SB> is mandatory. Perhaps it would be better just say what it is
SB> actually like in this protocol. Then you don't specify
SB> Reserved0 or ver, so this is sort a half reminder of the
SB> base spec.
=============================
Client Identification Name
This is a 40-byte ANSI string value set by the operator. It is
used as the identification of the HG in the operator's network.
SB> ANSI or ASCII or US-ASCI or something else?
===============
Idle Timeout
An unsigned integer measured in seconds. It takes values in the
range 0 through 172,800 with the granularity of 60. The default
value is 1,440 (24 hours). The value 0 indicates the idle timer
never expires.
SB> I am wondering what causes the session to close when this is set to zero?
==============
The Key bit is set to one so that the Key field is present. The Key
field is used as a 32-bit random number. It is generated by the HAAP
per bonding connection and notified to HG (See Section 5.2.9).
SB> Can there be an RNG collision in this protocol? .. and what
happens if one occurs?
==================
8. IANA Considerations
The GRE Protocol Type for the GRE Channel is set to 0xB7EA which is
under the control of IEEE Registration Authority. Please update the
"IEEE 802 Numbers" IANA web page [802Type] which is of primarily
historic interest.
SB> This is actually the Ether types registry. The number is allocated in
SB> http://standards-oui.ieee.org/ethertype/eth.txt so it's just a case
SB> of reflecting the number in the IANA shadow registry
- - - - -
Adrian Farrel's review:
he document describes a mechanism to provide connectivity services over
a set of (two) GRE tunnels that span multiple network connections. The
solution mechanism is clearly labelled as having been developed by a
specific single vendor and as such is not easily mistaken for any sort
of standard.
I have reviewed the document with a view to whether it would be possible
to build an interoperable implementation and I have tried to avoid
saying "I would not have designed it like that." My only other
considerations in review are motivation and clarity.
It is a mild surprise that there is no associated IPR for this work,
but that is OK.
I think it would be helpful if the Abstract gave some reason for the
publication of the document. Of course, this isn't a requirement, but it
can help the reader. Sometimes the reason is "For historical purposes so
that there is a record of what was built and deployed in case that
information is useful for future protocol work," and sometimes it is "To
enable other developers to build interoperable implementations if they
want to."
It would be nice if the Introduction repeated the text from the Abstract
about being a specific vendor's solution, and also the motivational
words if added to address my previous point.
Technically I am interested to understand why this work is supplied only
for bonding GRE tunnels when many other tunnel bonding situations might
arise, but (of course) that in no way invalidates this work although it
would appear that the identical approach could be used in other
tunnelling technologies
There are a few abbreviations in the Introduction that need to be
expanded on first use.
A point that I only picked out of terminology section and Figure 1, but
which I believe could usefully be highlighted in the Introduction and
maybe even the Abstract is that this solution is intended to apply when
the tunnel termination points at both ends are common for the two
tunnels. That is to say, that the home gateway supports multiple
technologies for uplinks (rather than there being two gateways) and that
the tunnels reach to the HAAP and not to separate routers or to separate
operators. This is a limit to the applicability that does not invalidate
the solution, but is a useful level-set for the reader (for example, I
operate a similar set of uplinks, but from different providers, so this
solution would not work for me).
Sections 1, 2 and 4.2 etc. cite RFC 2890 as the reference for GRE. I
think this should be RFC 2784. While you may want to use the extended
GRE header, you still need to give the base reference for GRE itself.
I think that in section 4.4 and 4.7 (with reference to RFC 2890) it
would be helpful to give some guidance about how much buffering is
needed at the recombination point (i.e., what value to select for
MAX_PERFLOW_BUFFER), and how to select a value for OUTOFORDER_TIMER.
Presumably this can be a function of the RTT Difference Threshold and the
line rate.
4.7 says that customers may input policies, but gives no hint how this
is achieved.
The figures in section 5 say "Key (optional)" but the mandatory setting
of the k-bit to 1 makes it clear that the key is not optional.
Section 1 has
Note that if there were more than
two connections that need to be bonded, the GRE Tunnel Bonding
mechanism could support that scenario, as well. However, support for
more than two connections is out the scope of this document.
But Section 5 has
T (1 bit)
Tunnel Type. Set to 1 if the control message is sent via the DSL
GRE tunnel. Set to 0 if the control message is sent via the LTE
GRE tunnel
That appears to place some limitations on the use of this mechanism.
Section 5
Attribute Length (2 octets)
Attribute Length indicates the length of the Attribute Value.
...say "in octets" or some other unit.
5.1.1
Client Identification Name
This is a 40-byte ANSI string value set by the operator. It is
used as the identification of the HG in the operator's network.
...needs a reference for "ANSI string" so that people can interop. Maybe
Windows-1252 was intended? (But I wish it had used UTF-8.)
Similar in 5.1.2.
(Note that 5.6.2 uses ASCII for string representation, and the mix
within the same spec is likely to cause confusion - although there is no
law against it.)
5.2.5
Bypass Bandwidth Check Interval
An unsigned integer measured in seconds. This value can be chosen
in the range 0 through 300.
I assume the value zero has special meaning (such as never check) and
does not mean "check every zero seconds".
Similarly in 5.2.6 for Active Hello Interval and 5.2.8 for Idle Timeout.
5.4.1
The timestamp value seems to have no meaning unless it is a time count
relative to something. Is this absolute clock time? Time since system
restart? Time since tunnel up? Time since user last accessed Facebook?
5.6.2
The figure and text make it look as though Commit_Count, Packet_Sum, and
Packet_ID are present once for each TLV. But that would surely lead to
confusion, additional bytes, and possible error cases.
5.6.2
The name Commit_Count implies it should be monotonic increasing
(possibly by one) for each new filter list package. But the text only
says "different" which allows any (e.g., random) change of value.
Clarity would help.
5.6.2
Packet_Sum
If the Filter List Package attribute might make the control
message larger than the MTU, fragmentation is used. The
Packet_Sum indicates the total number of Filter List Packages.
I think "...total number for fragments of this Filter List Package."
5.6.2
Packet_ID
The fragmentation index of this Filter List Package.
This might usefully say that each fragment is numbered starting at 1 and
increasing by one up to Packet_Sum.
5.6.2
Need to state the units (octets?) for Length and Description Length
5.6.2
I think you are supposed to use a kosher example FQDN not a real one.
5.6.2 doesn't explain how to encode some of the filter values in ASCII.
For example, "Destination IP&Port" and "Source IP Range&Port"
5.6.2
The lengths of the auxiliary Description Value and Value fields are
restricted to a maximum of 4 bytes and 32 bytes respectively, which
aims to limit the size of the Filter List TLV sent on the GRE tunnel.
This almost made me make some "I wouldn't do it like that" comments
about how to save bytes on the wire
But two important points:
1. If the length of Description Value is limited to 4 bytes them I
suggest the field is very close to unhelpful. You could make it more
useful by suggesting descriptions for each of the Filter List TLV types
that you define.
2. 32 bytes seems potentially insufficient for encoding FQDNs. Depending
on encoding, it may also be a problem for "Source IP Range&Port".
The IANA considerations section is probably wrong. IANA does not track
Ethertypes. (I note xB7EA is correctly registered at
http://standards-oui.ieee.org/ethertype/eth.txt.)
- - - - -
Ralph Droms' review:
I took a pragmatic view to reviewing the doc, and took into account the ISE
note you plan to attach to it. I focused on potential conflicts between the
protocol described in the document and IETF protocols, and didn't review the
document carefully for correctness, etc.
In my opinion, it would be appropriate to publish the document with the ISE
note. The protocol in the document uses a dedicated Ethertype to isolate its
traffic from other traffic. Because of the isolation provided by that
Ethertype, the protocol in this document and other protocols will operate as
"ships in the night" and won't interfere with each other.
This document reminds me of the solution to a conflict between the IETF TCP
spec and an extension defined by ITU-T which would have broken TCP stacks that
didn't implement the extension. The IETF and ITU-T eventually (and painfully)
negotiated a solution in which the ITU-T extended TCP would only be used in
"IP-like" datagrams that used a different Ethertype than IPv4 or IPv6.
- - - - -- - - - -