Subject: [rbridge] fragmentation for original ethernet frames

From: Jun Xiao <[email-masked]>
Date: Tue, 12 Oct 2010 12:25:52 +0800

Hi,

I am curious on how TRILL handle the case when the original ethernet
frames need to be fragmented due to TRILL encaped pkts exceed the MTU,
and I didn't find the answer from the draft.

Thanks,
Jun
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 12 Oct 2010 08:20:55 -0400

There is no frame fragmentation feature in TRILL. As it states in the
TRILL base protocol standard, it is possible that a frame will be
dropped due to the expansion caused by TRILL encapsulation.

This is no different from a frame being dropped due to the expansion
caused by the addition of various 802.1 tags such as 802.1ad, 802.1ah,
802.1Qau, etc. 802.1 does not provide a frame fragmentation feature
either.

Most modern switches have sufficient headroom for such frame expansion
that this is usually not a problem but, in general, end stations may
want to do some form of path MTU discovery.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: Eric Gray <[email-masked]>
Date: Tue, 12 Oct 2010 10:33:15 -0400

Jun,

Fragmentation doesn't happen at the Ethernet layer.  Over-sized PDUs
are simply discarded.

This would not be a problem that is "introduced" by TRILL, or even
made worse.

Also, in a world where almost all traffic is IP traffic of some kind,
and IP devices are the most likely Ethernet end-stations, it is not
actually necessary to solve this problem for the Ethernet layer.  IP
supports mechanisms for devices to be aware of the maximum (IP) PDU 
size (via - for example - configuration or discovery), and Ethernet 
devices can similarly be aware of maximum (Ethernet) PDU sizes, it is
possible to entirely avoid introducing over-sized PDUs.

A network administrator can detect the fact that MTU size has been
incorrectly configured or discovered because of discard statistics
reported (via management) for network devices.

If the network administrator would like to avoid the need to do this,
then he/she should buy equipment that is capable of discovering this
information on its own (thus avoiding configuration error issues).

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jun Xiao
Sent: Tuesday, October 12, 2010 12:26 AM
To: [email-masked]
Subject: [rbridge] fragmentation for original ethernet frames

Hi,

Thanks,
Jun

---

From: Jun Xiao <[email-masked]>
Date: Wed, 13 Oct 2010 00:45:25 +0800

Thanks Donald/Eric for the explanation!

On the other hand, isn't transparently/incremently deployment of rbridges
in legacy environment (which may not have enough headroom) a major goal
of TRILL? Also path MTU discovery is not performed on ipv4 end nodes,
btw, as a L2 technology, we should not have assumptions on the L3 protocols.

Thanks,
Jun

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Oct 2010 10:28:01 -0700

FWIW, L3 devices often assume that what the link interface supports the 
link also supports, which is not the case in TRILL due to the additional 
encapsulation.

Path MTU discovery will help where it is implemented and where it isn't 
blocked, e.g., where ICMP message-too-bigs aren't filtered out.

PLPMTUD (discovery via positive info in the next layer up, rather than 
relying on negative feedback in ICMP) also helps where deployed, which 
is rare.

Many protocols simply subtract from the interface MTU to account for 
encapsulations for tunnels, security, etc., which could help TRILL, but 
this is worth looking into further, IMO.

Joe

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 12 Oct 2010 10:38:25 -0700

Hi Jun,

I had raised this issue right at IETF 63 and the response from Radia
on this. You can look at the meeting minutes of TRILL.

http://tools.ietf.org/wg/trill/minutes?item=minutes63.html

          "Vishwas:  What about MTU issues?  Have we thought about those?

          Radia:  For a few years, I always assumed that adding a few
bytes would be fatal, but now they're doing VLAN tags and MAC-in-MAC
so apparently it's not a problem."

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 12 Oct 2010 11:11:02 -0700

Hi Joe,

The issue in my view is if the forwarder is not able to accept packets
at the Ethernet layer above the MTU size and applications over
Ethernet assume at least a fixed MTU (check the size of Layer-2
control packets over Ethernet). Another case could be if after the
TRILL header is added to the Ethernet packet and then the MTU is
exceeded. The aim is not to have applications change when a new header
is added. For both the cases I think Radia's reply that it hasnt been
an issue with MAC-in-MAC holds good.

Besides I guess you are talking about PMTUD at the TRILL Layer. which
is another side of the discussion.

We have a draft which deals with TRILL OAM. It has been undergoing
review with the chairs and some of the other members active in the
TRILL WG. It should be out this week.

Thanks,
Vishwas

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Oct 2010 12:58:00 -0700

Hi, Vishwas,

On 10/12/2010 11:11 AM, Vishwas Manral wrote:
> control packets over Ethernet).

L3 checks the MTU advertised by the interface. If TRILL never changes 
that, there's no new issue with TRILL.

If TRILL eats into the MTU (AFAICT, it does), then the interface would 
never know.

 > Another case could be if after the

It has been an issue with MAC-in-MAC, but maybe it's not a new issue 
here. The key (AFAICT) appears to be telling the TRILL devices to add 
the TRILL header but retain the payload MTU size (1500 bytes). See, e.g.:
http://www.enterprisenetworkingplanet.com/netsysm/article.php/3725881/Do-More-With-Less-8021Q-Tagged-VLANs.htm

> is another side of the discussion.

PMTUD happens at the IP layer (via ICMPs).
PLMTUD happens above the IP layer.

Joe

---

From: Anil Rijhsinghani <[email-masked]>
Date: Tue, 12 Oct 2010 15:49:24 -0400

I believe Jun brings up an interesting point about backward compatibility. There
is a fine distinction between this and the valid point you raise about other
protocols also using encapsulation.

There is a standard IEEE 802.3as (since folded into a recent update of 802.3)
which says, in essence, that frame size can exceed the standard 1518 if and
only if:
a) the increase in frame size is provided only for encapsulation purposes, and
b) all devices that these encapsulated frames encounter support the function
that requires that encapsulation.

VLAN headers, by this rule, would require that all connected bridges carrying the
VLAN encapsulation support the VLAN function (but an old bridge in the path that
doesn't support VLANs might drop a packet made oversize due to the vlan
header). Similarly MAC-in-MAC assumes that all bridges that get a MiM packet
supports the MiM function, so there is effectively a contiguous MiM cloud - you're
not going to see non-MiM-capable  bridges in the midst of a MiM cloud.

TRILL explicitly allows 802.1 islands to exist between TRILL Rbridges (in fact, takes
quite a lot of trouble to allow this). Now you may have a case in which bridges are
encountering an encapsulation they don't support, and hence may drop frames
that become oversize due to that encapsulation.

In the real world, the solution is to enable "Jumbo" frames, which most bridges
have supported for a while, although this is outside the realm of any standard.
Protocols like FCoE go well beyond the incremental overhead of protocols
such as TRILL, so in the practice this is unlikely to be an issue.

Regards,
Anil

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Oct 2010 13:17:56 -0700

FWIW...

On 10/12/2010 1:02 PM, Eric Gray wrote:
> Joe,
>
> 	Classic case of YMMV.  My experience with the few IP and related
> protocols that I've worked on is that they tend to use a nice, safe,
> PDU size (like was earlier suggested on this mailing list, for IS-IS
> hello PDUs).  TCP applications - for example - may fragment the PDUs
> received from higher layers at (for instance) ~500 octets before the
> PDU is forwarded to the IP layer.

TCP used to start with segment sizes of 500 for addresses not on the 
local subnet, and interface MTUs otherwise. That's changed with the 
number of new, non-standard TCP's in widescale deployment (e.g., both 
Windows and Linux use non-standard TCPs).

> 	Doing this makes an engineering trade-off between extra overhead
> and potentially having to determine a precise MTUJ size (in spite of
> the fact that - as you point out - this is not always easy).
>
> 	An approach based on believing the host interface is the most
> restrictive MTU-limiting factor in the network between that host, and
> remote host it wants to exchange messages with, is a very error-prone
> approach.  This information (usually obtained from lower-layer calls -
> e.g. - to functions like "ioctl") is mostly useful as a starting point
> for subsequent MTU discovery interactions.  It is a bad idea to think
> of this as a substitute for accurate configuration of an MTU, or a
> proper implementation of MTU discovery.

It's used as a hint in almost all systems, but we all know it's not a 
safe approach in the absence of feedback. Routers provide feedback in 
the form of ICMPs, but switches do not.

> 	I also suspect that failures to obtain ICMP error messages is
> more likely to be the result of disabling this feature in switching
> devices, than because of filtering the messages - assuming they were
> generated in the first place.

The typical case is an enterprise, where ICMPs are blocked by firewalls 
for security reasons. Most NATs also don't bother trying to translate 
ICMPs appropriately, assuming they even have enough info to do so (in 
many cases they don't).

> 	It can happen that you will not get a response from network
> devices when using MTU discovery, but it seems highly unlikely one
> network device would be setup to filter error messages from other
> network devices.

That's been common practice for a very long time now. Here's a pointer 
from 2003, but it was common long before that as well:
http://articles.techrepublic.com.com/5100-10878_11-5087087.html

> 	Also, because of other considerations, many "stacked" protocols
> don't so much "subtract" for headers added at lower layers as make a
> request for a PDU buffer (from the next lower layer) and get one of
> a certain maximum size.  Among other things, this approach allows a
> lower layer to account for whatever over-head it requires without
> having to share this information with the higher layer (this also
> allows the stack to avoid multiple memcpy operations as the content
> is handed off from layer to layer).

That presumes the lower layer is capable of a larger payload; as noted 
in the pointer I forwarded in my response to Vishwas, that's not always 
the case, and has already become an issue for Q-in-Q.

So the issue isn't new for TRILL, but it does affect TRILL.

Joe

---

From: Eric Gray <[email-masked]>
Date: Tue, 12 Oct 2010 16:02:00 -0400

Joe,

--
Eric

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Tuesday, October 12, 2010 1:28 PM
To: Eric Gray
Cc: Jun Xiao; [email-masked]
Subject: Re: [rbridge] fragmentation for original ethernet frames
Importance: High

Joe

---

From: James Carlson <[email-masked]>
Date: Tue, 12 Oct 2010 16:37:30 -0400

> If TRILL eats into the MTU (AFAICT, it does), then the interface would 

I should know better than to jump into this discussion, as I no longer
have a horse in the race, but I think the above reflects a
misunderstanding of where TRILL is headed.

I had a discussion with Radia about this very issue some time back, and
the underlying assumption is that modern enough equipment will support
large enough oversized frames such that you should have no problem
supporting standard Ethernet MTUs plus the TRILL headers.

There are several cases to consider, but it boils down to whether you
have a traditional bridge or repeater separating two TRILL nodes in a
network, where that older device doesn't like frames that are fattened
up by TRILL.  That's what the whole MTU testing process in section 4.3.2
is about.  If you don't know for certain (based on external information)
that you've got a problem-free link to your TRILL neighbor, you can test
it, and if it fails, you can exclude it from the topology and (perhaps)
tell an administrator or human being that there's something wrong.

In other words, no, TRILL doesn't fragment, and doesn't rely on anyone
else to do so, and, yes, it does expect that all the links can support
large enough frames, and you probably shouldn't bother trying to
implement it if you can't manage at least that for your own interfaces.
 It has mechanisms (see section 4.3) that allow you to make sure that
you've got the same MTU everywhere.  In fact, it does so better than the
misbegotten FDDI/Ethernet bridges in the days of yore.

-- 
James Carlson         42.703N 71.076W         <[email-masked]>
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Jun Xiao <[email-masked]>
Date: Wed, 13 Oct 2010 16:10:54 +0800

Hi Joe,

> That presumes the lower layer is capable of a larger payload; as noted in
> the pointer I forwarded in my response to Vishwas, that's not always the
> case, and has already become an issue for Q-in-Q.
>

The issue isn't new but may get worse when we consider TRILL can have
maximum 124 bytes optional headers.

Thanks,
Jun

2010/10/13 Joe Touch <[email-masked]>:
> TCP used to start with segment sizes of 500 for addresses not on the local
> subnet, and interface MTUs otherwise. That's changed with the number of new,
> non-standard TCP's in widescale deployment (e.g., both Windows and Linux use
> non-standard TCPs).
>
> It's used as a hint in almost all systems, but we all know it's not a safe
> approach in the absence of feedback. Routers provide feedback in the form of
> ICMPs, but switches do not.
>
> The typical case is an enterprise, where ICMPs are blocked by firewalls for
> security reasons. Most NATs also don't bother trying to translate ICMPs
> appropriately, assuming they even have enough info to do so (in many cases
> they don't).
>
> That's been common practice for a very long time now. Here's a pointer from
> 2003, but it was common long before that as well:
> That presumes the lower layer is capable of a larger payload; as noted in
> the pointer I forwarded in my response to Vishwas, that's not always the
> case, and has already become an issue for Q-in-Q.
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Oct 2010 10:27:42 -0700

Hi, Eric,

On 10/13/2010 10:18 AM, Eric Gray wrote:
> Joe,
>
> 	A few off-line observations...
>
> 	It is not quite correct to refer to Windows and Linux TCP
> implementations as "non-standard."  I suspect that what you mean
> is that they are not built on the TCP reference implementation.

Linux and Windows use congestion control algorithms that are NOT part of 
the standards-track requirements as specified in the IETF. The only 
standards-track congestion control is NewReno. See the discussion of 
this in RFC4614.

> 	They are - of course - compliant with TCP as a standard,
> hence they are "standard TCP" implementations.

They do not comply with the requirements, in specific, in RFC2581.

You are correct that these implementations *interoperate* with standard 
TCP, and with each other, to provide correct data exchange. But they are 
*nonstandard* themselves.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Oct 2010 10:18:40 -0700

On 10/13/2010 10:09 AM, Eric Gray wrote:
> Joe,
>
> 	One small correction...
>
> 	I think in the discussion below, I may not have been
> very clear.  When the lower layer is asked for a buffer for
> sending a PDU, the "maximum size" PDU it returns is based
> on presumed knowledge (for instance, from configuration) of
> the legitimate maximum PDU size at that layer - after taking
> into account the overhead that will be inserted by that
> layer.

Right - except that my ethernet interface has no knowledge that there is 
a TRILL campus several ethernet switches away from it. So it can't 
subtract the TRILL overhead from whatever maximum the underlying 
ethernet supports. ingress and egress rbridges can do this, and if the 
underlying hardware supports payloads that accommodate the incoming 
frame with the addition of the TRILL header, it all works fine.

But if that's not the case, then my interface will have guessed wrong, 
because it operates under the assumption that it's talking to ethernet, 
which 'guarantees' that it can transit a 1500-byte payload.

> 	The higher layer does not control the maximum size of
> the buffer, only the amount of the buffer that it uses.

Agreed. However, it does so based on the knowledge of its own interface; 
there's no protocol to provide that info at L2 to the interface.

> 	Hence there is no implication that the lower layer may
> need to deal with a larger payload than it "believes" itself
> capable of.

There actually is - when my system makes a decision based on knowledge 
it has been told it can use, and then a downpath TRILL campus (or 
Q-in-Q) is not consistent with that...

Joe

---

From: Eric Gray <[email-masked]>
Date: Wed, 13 Oct 2010 13:09:41 -0400

Joe,

	One small correction...

--
Eric

Joe

---

From: Eric Gray <[email-masked]>
Date: Wed, 13 Oct 2010 13:18:09 -0400

Joe,

	If they were not, we would hardly be able to exchange views
about them, using a variety of different implementations and tools
that rely on properly cooperating TCP implementations.

	I suspect that you are correct about NAT implementations.
This is an important and useful observation that I had not been
including in my thinking.

	Thanks!

--
Eric

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Tuesday, October 12, 2010 4:18 PM
To: Eric Gray
Cc: Jun Xiao; [email-masked]
Subject: Re: [rbridge] fragmentation for original ethernet frames
Importance: High

FWIW...

Joe

---

From: Eric Gray <[email-masked]>
Date: Wed, 13 Oct 2010 13:57:22 -0400

Joe,

	Yes, this is true.  However, it is rarely (previously spelled
"N-E-V-E-R") the case that PDUs sent, from one Ethernet end-station 
to another, would routinely take divergent paths.  

	Even in the TRILL case (where it is possible that ECMP may be 
in use), it is unlikely that alternates will include both TRILL and
non-TRILL paths.  This is the reason why we've tried to be careful 
in "discovering" RBridge adjacencies.

	Hence - if one does not want to configure all end-stations to
use the least common MTU for all paths (including TRILL and non-TRILL
paths) - then one may use some form of pair-wise MTU discovery.  If
this is done, it would be done for Ethernet end-stations that use a
TRILL campus, not for RBridges or for TRILL.

	My main point is that this is not a problem that should be
solved for TRILL, since it is not (necessarily) a problem that has
been introduced by TRILL. 

	You've made this point yourself, in referring to a similar
set of problems with what you referred to as "Q-in-Q."

	Where this problem might have been specific to TRILL would have
been if it was possible that ECMP paths across a TRILL Campus might
have different MTUs.  I believe we finessed that problem when we
were concerned about the issue with lost "MAX-MTU" IS-IS hellos.

	If we did not, and people truly expect multi-pathing to be 
supported by RBridge deployments, then TRILL has a problem to look
at solving.

	This is not a hard problem to solve, however, using standard
tools and only slightly modified implementations.  It can be solved
in the general case by using appropriately sized CFM messages, for
example, as specified in IEEE 802.1ag - possibly as extended by 
IEEE 802.1Qaw).  Solving it in the general case should be strictly
out of bounds for TRILL (I think you would agree on this).

	If we need to solve the TRILL-specific problem I mentioned 
(assuming I am wrong and we did not finesse this problem earlier), 
the simplest approach would be to force RBridges to use a least-
common MTU.  That "least-common MTU" may either be discovered (by
using a common Ethernet MTU discovery mechanism) or configured (a
significantly less reliable approach) and "negotiated" in TRILL 
protocols (this is the part I think has already been done - but I 
may be wrong).

	Although that approach is sub-optimal, it has the advantage of
avoiding any attempt in the TRILL working group of trying to define
extensions that would need to be implemented by Ethernet end-stations.

	Should such extensions be defined in an appropriate venue - and
IEEE 802.1 or IEEE 802.3 are the obvious "appropriate venues" in this
case - then it would be desirable to be able to configure RBridges to
optionally turn off this "least-common MTU" behavior.

--
Eric

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Wednesday, October 13, 2010 1:19 PM
To: Eric Gray
Cc: Jun Xiao; [email-masked]
Subject: Re: [rbridge] fragmentation for original ethernet frames
Importance: High

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Oct 2010 11:47:46 -0700

Hi, Eric,

> to another, would routinely take divergent paths.

Not sure why this is relevant.

The point  is that my host has a NIC. That NIC thinks it knows the MTU 
on the wire. When there's TRILL in the path, and it's a few hops away, 
that MTU could be wrong if the TRILL header eats into the payload space.
> in "discovering" RBridge adjacencies.

There is no restriction that TRILL campuses span an entire ethernet 
subnet. It's entirely possible that they'd operate inside some core, and 
there would be conventional switches at the edges. When my host speaks 
to hosts on those switches, there's no TRILL in the path. When it speaks 
to hosts on the other side of the campus, there is TRILL in the path.

Either way, though, my host has no knowledge of TRILL.

> paths) - then one may use some form of pair-wise MTU discovery.

Ethernet isn't based on the assumption that endstations are configured 
manually for this sort of thing. If you deploy TRILL, you had better NOT 
expect to reconfigure the end hosts.

...
> been introduced by TRILL.

Q-in-Q has the same problem, but uses a smaller header. The point here 
is that TRILL could overstep a limit that Q-in-Q can hide in 
specifically because if the size of its header.

I don't know if there's a TRILL-specific solution required here, but 
TRILL does make the problem worse by using a larger header.

Joe

---

From: Eric Gray <[email-masked]>
Date: Wed, 13 Oct 2010 15:38:53 -0400

Joe,

	I think we're talking past each other.  Let me try to work
my way to being clearer about what your position is.

	It seems to me that you're aware that this is not a problem
limited to TRILL.

	It also seems to me that - absent a general solution - there
is nothing TRILL can do to solve the problem, unless you're saying
that TRILL headers should be made even larger so that they include
the information required to support fragmentation and re-assembly
(which they currently do not).

	Hopefully this is not what you're suggesting.  I have been
assuming that it is not, because that would be a very strange idea,
given that fragmentation and re-assembly in the forwarding plane of
switching and/or routing devices hasn't been a particularly popular
idea whenever it has been brought up before.

	Hence the problem to be solved seems to be in the NIC you're
talking about.  And if that is the case, then it isn't a problem 
for TRILL to solve.

	It is possible that you are talking about possibly expanding 
the TRILL encapsulation to support fragmentation/re-assembly.  I 
hope that you are not, but if you are, then you should realize that 
this only makes the problem worse for interconnections between 
RBridges that may possibly use intermediate forwarding devices that 
are themselves potentially a problem for (further) over-sized PDUs.

	Hence, unless we want to restrict this to interconnections
between RBridges that we know absolutely to be point-to-point, we
still need to have an MTU discovery mechanism that will work for 
at least the RBridge-to-RBridge case, if not for the general case 
with Ethernet. And - if we restrict the solution in that way - 
then we have not solved the problem.

	Not only would an approach like this not solve the problem
for even the restricted cases that apply to TRILL (because it is
still possible that RBridges may be connected via other network
devices), but it also just moves the NIC mis-alignment problem 
from a NIC that may have incorrect MTU information to one that may
have incorrect link-type information (it thinks it is a P2P link
but is not).

	So, upon reflection, it seems very unlikely to me that you 
are advocating either that we add fragmentation support to TRILL,
or that any such solution would be sufficient.

	So, it should be pretty clear we're probably not going to 
do that.  If not, then what possible TRILL-specific solution is
there?

	We either avoid discarding too-big PDUs, or we use some
mechanism that allows end-stations to avoid sending them.  

	Do you envision another approach?

	Any solution that we might propose that would allow end-
stations to avoid sending too-bug PDUs should be sufficiently
generic that it solves the problem for more than just TRILL.

	Finally, it is not clear to me at all that TRILL defines the
largest overhead possible for Ethernet tunneling, hence I am not 
convinced that even that argument can be used to indicate that we
need to solve this problem for TRILL.

--
Eric

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Wednesday, October 13, 2010 2:48 PM
To: Eric Gray
Cc: Jun Xiao; [email-masked]
Subject: Re: [rbridge] fragmentation for original ethernet frames
Importance: High

Hi, Eric,

...

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Oct 2010 13:11:23 -0700

On 10/13/2010 12:38 PM, Eric Gray wrote:
...
> mechanism that allows end-stations to avoid sending them.

It might be a caveat on deployment, i.e., that TRILL can cause MTU 
problems even where Q-in-Q does not.

Not sure there's much actionable beyond that.

Joe

---

From: Eric Gray <[email-masked]>
Date: Wed, 13 Oct 2010 16:59:11 -0400

Okay.  I think we are essentially in agreement.

Thanks!

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Wednesday, October 13, 2010 4:11 PM
To: Eric Gray
Cc: Jun Xiao; [email-masked]
Subject: Re: [rbridge] fragmentation for original ethernet frames
Importance: High

Joe

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 13 Oct 2010 14:20:27 -0700

Hi Joe,

As a requirement, we should try to avoid use of options except where
absolutely necessary.

I think the idea of option bits (in the options draft) instead of TLV
will help in a large degree for most of the cases.

Thanks,
Vishwas