e chance of attack on the reassmebly queue, IP fragmentation is
perfectly useful and in use. However, even in that environment there
are improvements that could be made like using flow label to to get
consistent forwarding between fragments and non-fragments.
Tom
>
> -- Christian Huitema
> __
On Thu, Nov 29, 2018 at 3:41 PM Christian Huitema wrote:
>
> On 11/29/2018 1:05 PM, Templin (US), Fred L wrote:
>
> > iperf3 is a real Internet application in the same way that ping, traceroute,
> > tcpdump, etc. are real applications. It is a well-known tool that network
> > engineers use on a
PMTU discovery and IP fragmentation, rather than
rewriting all the UDP applications to implement fragmentation.
Tom
>
>
>
> Ron
>
>
>
>
>
>
>
> From: Templin (US), Fred L
> Sent: Thursday, November 29, 20
Please see my response below maked TH.
Thanks,
Tom
---
** TH's video link dropped shortly into the presentation and wasn't
completed or able to respond to the comments **
CF: As TSVWG chair I didn't get why it was being proposed. TSVWG is in
the title and this is what TSVWG
MP also. The flow
label is a generic mechanism that works not only with fragmentation,
but any case where an intermediate node is unable or doesn't want to
to parse the transport layer header to get ports from the transport
layer. All major OSes should be setting flow label properly at this
point.
Tom
On
t;
>
The hardest part is pmtu discovery, signaling discovered pmtu to the UDP
application, and then the application needs to know how to make smaller
packets to fit into mtu. The last step is especially problematic since it's
application specific logic. The natural recourse applications hav
telligent middle box deployment decisions.
I don't think this paragraph is needed with the suggested text above.
Tom
>
> > -Original Message-
> > From: Brian E Carpenter
> > Sent: Thursday, November 15, 2018 10:44 PM
> > To: Ron Bonica ; Tom
shed. For discussion, can you give
a specific example of a required protocol that would only work in a
limited domain, but would be incorrect if used in the Internet?
Tom
>
> Brian
>
> ___
> Int-area
On Wed, Nov 14, 2018 at 1:25 PM, Brian E Carpenter
wrote:
> On 2018-11-15 10:02, Tom Herbert wrote:
>> On Wed, Nov 14, 2018 at 12:50 PM, Ron Bonica wrote:
>>> Tom,
>>>
>>> Please look inline for a little compromise and a little pushback. I hope
>>&
On Wed, Nov 14, 2018 at 12:50 PM, Ron Bonica wrote:
> Tom,
>
> Please look inline for a little compromise and a little pushback. I hope that
> we can reach consensus in this round.
>
> Ron
>
>
>> -Original Mes
On Wed, Nov 14, 2018 at 11:35 AM, Ron Bonica wrote:
> Folks,
>
> Since we seem to have reached consensus on Section 7.1, let's take another
> stab at Section 7.3. I am looking particularly to Tom Herbert and Joe Touch
> for feedback, since they objected to the previous formulatio
. port information)? But, ECMP is not required to make IP
work either. Forwarding solely based on destination IPv4 address for
unicast packets needs to work.
> I.e it’s now part of ‘normal’ routing/forwarding. That’s absolutely not the
> case. In IPv6 packets are delivered to hosts based on longest matc
On Mon, Nov 12, 2018 at 3:56 PM, Ron Bonica wrote:
> Tom,
>
> OK. Let's see if the following text works any better for you.
>
> Ron
>
> 7.1. For Protocol Developers
>
>Protocol developers SHOULD NOT deve
On Mon, Nov 12, 2018 at 1:08 PM, Ron Bonica wrote:
> Joe, Tom,
>
> Does the following text work for you?
>
> Ron
>
> ===
>
>
> 7.1. For Protocol Developers
>
>Protoc
t behavior. If the intent is to address those
implementations, they will need guidance on how to fix things. IMO, it
wouldn't be correct or feasible to recommend they do virtual
reassembly.
Tom
> Note the generous application of the word "SHOULD". These are
> recommendations, not iron-f
ould be required to do the equivalent work.
They can't do the equivalent work of hosts for the reasons above. I
don't see how we can require something that is impossible to do
correctly.
Tom
>
> Just because they ‘don’t want to’ doesn’t make it so.
>
> Joe
>
>> On Nov 8, 2018, a
e both the destination and the
intermediate device maintain state for reassmbly that is the target of
the attack.
Tom
>
> You make the mess, you clean it up, IMO.
>
> Joe
>
>> On Nov 8, 2018, at 8:09 AM, Tom Herbert wrote:
>>
>>> On Wed, Nov 7, 2018 at 10:32 A
On Wed, Nov 7, 2018 at 10:32 AM, Joe Touch wrote:
> Sorry - previous response got cut off. Let's try again...
>
>
>
>
> On 2018-11-07 10:08, Tom Herbert wrote:
>
> On Wed, Nov 7, 2018 at 9:24 AM, Joe Touch wrote:
>
> It conserves no work to pass fragme
ateless devices whether
they think this is feasible solution.
Tom
>
> Joe
>
>> On Nov 7, 2018, at 8:45 AM, Tom Herbert wrote:
>>
>>> On Wed, Nov 7, 2018 at 8:28 AM, Joe Touch wrote:
>>> The current “solution” of ignoring this need isn’t tenable either, though.
I don't believe customers will have much interest in paying premium
for a device just because it deals with fragmentation.
Tom
>
> Joe
>
>> On Nov 7, 2018, at 8:07 AM, Tom Herbert wrote:
>>
>> Hi Ron,
>>
>> In the int-area meeting you mentioned that the proposed
is likely a front end to many hosts, a DOS attack would
potentially block the service for all the hosts.
Tom
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
- Original Message -
From:
To: "tom petch" ;
Sent: Monday, October 29, 2018 10:42 AM
Hi Tom, all,
In order to provide a full context, below some precisions:
* draft-ietf-softwire-yang DOES NOT create a new registry for
maintaining tunnel types nor changes the procedure to
since Last Call completed and I have
suggested that it needs to go back to softwires for them to agree this
is really what they want before the I-D goes any further.
Tom Petch
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman
On Mon, Oct 15, 2018, 5:48 PM Brian E Carpenter
wrote:
> On 2018-10-16 11:26, Tom Herbert wrote:
> >
> >
> > On Mon, Oct 15, 2018, 3:11 PM Fred Baker <mailto:fredbaker.i...@gmail.com>> wrote:
> >
> >
> >
> > > On Oct 15, 2018, at
ways sent the first fragment last when
fragmenting. This wreaked havoc on middle boxes trying to reassemble. That
was changed to send first fragment first. But even so, I think there might
be some ECMP implementations that could route first fragment (off=0)
differently to create ooo packets relative to
On Mon, Oct 15, 2018 at 1:35 PM, Ron Bonica wrote:
> Hi Tom,
>
> The examples in Sections 4.1-4.4 all refer to stateless devices. The problem
> could be solved by making them all stateful. However, that may not be
> practical because of:
>
Ron,
I think you're refe
On Mon, Oct 15, 2018 at 12:50 PM, Ron Bonica wrote:
> Hi Tom,
>
>
>
> This is reminiscent of loss amplification in IP-over-ATM. In IP-over-AM, if
> you lose one cell, you have to retransmit every cell belonging to the
> packet. In reality, you have to retransmit every cell
On Mon, Oct 15, 2018 at 12:28 PM, Joe Touch wrote:
>
>
>
>
> On 2018-10-15 12:13, Tom Herbert wrote:
>
> On Mon, Oct 15, 2018 at 12:06 PM, Templin (US), Fred L
> wrote:
>
> Hi Tom,
>
> ...
> From what I saw when I was working with iperf3. By default, it use
On Mon, Oct 15, 2018 at 12:11 PM, Ron Bonica wrote:
> Hi Tom,
>
> Hope you are feeling better. Comments inline.
>
> Ron
>
>
>> Message: 1
>> Date: Wed, 10 Oct 2018 13:55:16 -0700
>> From: Tom Herbert
>> To: int-area
>>
On Mon, Oct 15, 2018 at 12:06 PM, Templin (US), Fred L
wrote:
> Hi Tom,
>
>> -Original Message-----
>> From: Tom Herbert [mailto:t...@herbertland.com]
>> Sent: Monday, October 15, 2018 11:52 AM
>> To: Templin (US), Fred L
>> Cc: Joe Touch ; Ronald Bonica
e use case. But then I have to ask: why not just
crank up MTUs to a high number to eliminate fragmentation overhead?
Tom
>
> Thanks - Fred
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
On Mon, Oct 15, 2018 at 11:00 AM, Joe Touch wrote:
>
>
>
>
> On 2018-10-15 09:59, Tom Herbert wrote:
>
> On Mon, Oct 15, 2018 at 9:46 AM, Joe Touch wrote:
>
> Two points I'd like to make:
>
> 1) it is very important to list at least one other applicatio
optimizations that could be done such as compressing
out a GUE header that is common in every message.
Comments are appreciated!
Thanks,
Tom
-- Forwarded message --
From:
Date: Fri, Sep 28, 2018 at 3:14 PM
Subject: New Version Notification for draft-herbert-tsvwg-gte-00.txt
To: Tom
es. I don't think there's any argument that
fragmentation has higher goodput than equivalent unfragmented stream
of packets.
Tom
> Joe
>
>
>
> On 2018-10-15 08:32, Tom Herbert wrote:
>
>
>
> On Mon, Oct 15, 2018, 8:14 AM Ron Bonica wrote:
>>
>> Hi Fred,
>>
inherent of fragmentation
and good reason why not to use fragmentation over the Internet. This
probably should be mentioned in the draft.
Tom
> Ron
>
>
> > Message: 2
> > Date: Wed, 10 Oct 2018 16:22:47 +
> > Fr
ense is this "difficult"? Difficult because there are no ICMP
errors for dropped fragments, difficult because network operators
don't share their policy on fragmentation, or other meaning?
Tom
On Wed, Oct 10, 2018 at 7:38 AM, wrote:
>
> A New Internet-Draft is available from the on-line
Hello,
I have posted a draft defining some control messages for GUE. These
are for capabilties query/response and echo request/reply. There are
another two defined in
https://tools.ietf.org/html/draft-herbert-tsvwg-gte.
Comments are appreciated!
Thanks,
Tom
-- Forwarded message
On Wed, Sep 12, 2018 at 7:42 PM, Brian E Carpenter
wrote:
> Just picking on one part of Tom's excellent note:
>
> On 2018-09-13 11:14, Tom Herbert wrote:
> ...
>> IMO, IETF's strength and advantage is that it focuses on standardizing
>> protocols without standardiz
On Wed, Sep 12, 2018 at 5:39 PM, Amelia Andersdotter
wrote:
> Dear all,
>
> Thanks Brian for going through all this work, and Tom and Alexandre for
> providing interesting feedback.
>
> In section 3, it may be more interesting to divide Examples of Limited
> Domain Requi
On Wed, Sep 12, 2018 at 1:53 PM, Brian E Carpenter
wrote:
> Tom,
>
> On 2018-09-13 04:10, Tom Herbert wrote:
>> Hi Brian,
>>
>> Thanks for the draft!
>>
>> I am still concerned about the implications and perceptions this draft
>> might entail. Part
rable Internet protocols. I guess the
consequences of this is that if someone defines a protocol that only
operates in a limited domain, then the limited domain itself needs to
be clearly defined in normative language.
Tom
On Tue, Sep 11, 2018 at 8:30 PM, Brian E Carpenter
wrote:
> New version, w
proto field, it would
> undermine that context.
>
Hi Joe,
The GUE fragmentation option includes a orig-proto field to hold the
protocol of the reassembled packet. That needs to be matched in all
fragments along with srd/dst and ID, Also the protocol field in the
GUE header of the firs
On Fri, Aug 31, 2018 at 8:56 AM, Joe Touch wrote:
>
>
> On Aug 31, 2018, at 8:44 AM, Tom Herbert wrote:
>
>
> Joe,
>
> There is an alternative: don't use NAT!
>
>
> Agreed - that should also be part of the observations of this doc.
>
> Yes, something needs
ancer
(https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44824.pdf)
without employing a synchronization protocol. It is rather complex
though and not a solution easily generalized for simple environments.
Like NAT though, in the long run I believe IPv6 offers a better
solutio
On Wed, Aug 29, 2018 at 7:58 PM, Joe Touch wrote:
>
>
>
>
> On 2018-08-29 18:34, Tom Herbert wrote:
>
>
> Joe,
>
> End hosts are already quite capable of dealing with reassembly,
>
>
> Regardless, middleboxes shouldn't be avoiding their own effort by
On Wed, Aug 29, 2018 at 5:32 PM, Joe Touch wrote:
>
>
>
>
> On 2018-08-29 10:38, Tom Herbert wrote:
>
>
> I don't think you need the part about acting as a host, that would
> have other implications.
>
>
> It does, and that's exactly why you do. In particu
On Fri, Aug 24, 2018 at 12:34 PM, Templin (US), Fred L
wrote:
> Hello,
>
> As document shepherd, I am required to perform a review. Please see below
> for initial comments, and respond on the list.
>
Hi Fred,
Thanks for shepherd review and comments! Some response inlin
On Wed, Aug 29, 2018 at 10:10 AM, Joe Touch wrote:
> Tom,
>
>
>
>
> On 2018-08-29 09:53, tom wrote:
>
> On Wed, Aug 29, 2018 at 8:11 AM, Joe Touch wrote:
>
>
>
>
>
> On 2018-08-28 17:24, Toerless Eckert wrote:
>
> ...Sure, i meant to imply that po
ubsequently negated intermediate devices ability to peruse the
transport layer. But, crypto isn't magic dust either. There is only so
much of the packet we can encrypt, and a host at its discretion MAY
want to share to share transport layer information in the netwo
On Tue, Aug 28, 2018 at 5:24 PM, Toerless Eckert wrote:
> On Tue, Aug 28, 2018 at 03:51:58PM -0700, Tom Herbert wrote:
>> I think it's the opposite-- the definition of the context should be
>> protocol agnostic. We need to get middleboxes out of doing DPI and to
>> stop worry
iven the
update in RFC8200 and if some useful HBH options are defined, I would
expect that new deployments and replacements might start to lower the
HBH drop rate. In any case, the drop rates for DestOpts are still no
where close to zero, so regardless of which option is used used some
backoff is needed when
t-ietf-tunnels, there are some issues with the details in that RFC).
I think it's probably better to use 4 and show the example as IPv4/IP
encapsulation since that's probably more common.
Thanks,
Tom
>
> Joe
>
>
> ___
> Int-area mailing l
nd OS development and have NEVER once
"outsourced" security to the network. OSes and apps need to work
across all networks, in any possible environment, so having one
network provide a strict firewall, and in the next one no firewall
doesn't help really help things. Least common denominator for sec
ontrol on the Internet without a firewall ?
>
Conversely, do you allow your smartphone to connect to a network
before you've verified that a firewall is being run in the network,
what vendor provided it, and what the configured rules are?
Tom
> Cheers
> Toerless
>
>> Usi
On Sun, Aug 26, 2018 at 2:12 PM, Joe Touch wrote:
>
>
> On Aug 26, 2018, at 12:58 PM, Tom Herbert wrote:
>
> On Sun, Aug 26, 2018 at 11:38 AM, Joe Touch wrote:
>
>
>
> On Aug 26, 2018, at 10:31 AM, Christian Huitema wrote:
>
> It seems that the biggest
T follow the same path. So in a
multi-homed environment this will eventually break someone. For IPv6,
this is also a clear violation of RFC8200 since intermediate nodes are
processing a non-HBH extension header in a packet not addressed to the
them. The only robust solution to NAT and its fra
do its
work eliminating the need for DPI at the middlebox (protocol compliant
with RFC8200). This works on any packet regardless of whether it's a
fragment (no reassembly at firewall is ever necessary), any
combination of extension headers, and any transport protocol even
those that don't have
of legacy implementation that
might hard to fix completely, I don't think we've seen a good argument
that these problems are infeasible to fix in new deployments and
products. I think this draft is an opportunity not only highlight the
problems, but to suggest some practical fixes to improve th
suspect we'll have softening of
other requirements like "Networks SHOULD support extension headers",
or "Networks SHOULD support protocols other than TCP". That would be
accepting and codifying non-conformance as well as the protocol
ossification that entails.
Tom
>
>
On Tue, Aug 14, 2018 at 10:26 PM, Brian E Carpenter
wrote:
> Tom,
>
> Thanks for the comments. See in-line:
>
> On 15/08/2018 12:00, Tom Herbert wrote:
>> On Mon, Aug 13, 2018 at 7:07 PM, Brian E Carpenter
> ...
>>>
>> Hi Brian, thanks for the draft.
>
only one vendor solution). So then
does a limited domain become a vehicle for vendors to define and
deploy their own value-add protocol extensions without regard to
interoperability? The open endedness of "local policy" alluded to in
the SR protocol draft as well as some statement concern
On Fri, Aug 3, 2018 at 12:48 AM, Mikael Abrahamsson wrote:
> On Thu, 2 Aug 2018, Tom Herbert wrote:
>
>> This leads to driving everything down to only support the least common
>> denominator. Problem is that we can never move things forward if everyone is
>> bound to LCD.
work
> less well, that's fine, but they still need to work.
>
This leads to driving everything down to only support the least common
denominator. Problem is that we can never move things forward if
everyone is bound to LCD.
Tom
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
>
On Tue, Jul 31, 2018 at 2:21 PM, Ole Troan wrote:
> Tom,
>
>> How is this story going to be different for IPv6? How do we ensure that
>> non-conformant implementation for IPv4 isn't just carried over so that
>> fragmentation, alternative protocols, and exte
cture.
>
Ole,
How is this story going to be different for IPv6? How do we ensure that
non-conformant implementation for IPv4 isn't just carried over so that
fragmentation, alternative protocols, and extension headers are viable on
the IPv6 Internet?
Tom
> Cheers,
> Ole
__
On Mon, Jul 30, 2018 at 11:50 AM, Joe Touch wrote:
>
>
>
>
> On 2018-07-30 11:16, Tom Herbert wrote:
>
> On Mon, Jul 30, 2018 at 10:34 AM, Joe Touch wrote:
>
>
>
>
>
> On 2018-07-30 08:11, Tom Herbert wrote:
>
> On Sun, Jul 29, 2018 at 9:22 AM, Joe T
On Mon, Jul 30, 2018 at 10:34 AM, Joe Touch wrote:
>
>
>
>
> On 2018-07-30 08:11, Tom Herbert wrote:
>
> On Sun, Jul 29, 2018 at 9:22 AM, Joe Touch wrote:
>
>
>
> On Jul 29, 2018, at 9:11 AM, Tom Herbert wrote:
>
> ...
>
> That said, there's no r
On Sun, Jul 29, 2018 at 9:22 AM, Joe Touch wrote:
>
>
> On Jul 29, 2018, at 9:11 AM, Tom Herbert wrote:
>
> ...
>
> That said, there’s no real problem with a NAT *IF* it acts as a host on the
> Internet
> (see ouch, J: Middlebox Models Compatible with the Internet. U
On Sun, Jul 29, 2018 at 9:22 AM, Joe Touch wrote:
>
>
> On Jul 29, 2018, at 9:11 AM, Tom Herbert wrote:
>
> ...
>
> That said, there’s no real problem with a NAT *IF* it acts as a host on the
> Internet
> (see ouch, J: Middlebox Models Compatible with the Internet. U
th transport layer state is to be an L4
proxy. The intermediate is a host endpoint for the proxy connections,
but then that has its own problems since it breaks E2E functionality
(like TCP auth). So the only real solution is to eliminate transport
state from the network. I'm still holding out hope th
ead. Lowering the MTU for everyone just to avoid fragmentation
for that case is a poor tradeoff-- it's better to fragment for that
case.
Tom
>>
>> 3. fragmentation always splits info across packets
>>
>> And there’s something important about layering:
>>
On Fri, Jul 27, 2018 at 11:54 AM, Fernando Gont wrote:
> Tom,
>
> On 07/27/2018 07:20 PM, Tom Herbert wrote:
> []
>>>
>>> For example, what happens with EHs has a lot to do with engineering:
>>> they could be made to work (e.g., remove performance
On Fri, Jul 27, 2018 at 9:25 AM, Fernando Gont wrote:
> On 07/27/2018 05:15 PM, Tom Herbert wrote:
>> On Fri, Jul 27, 2018 at 5:38 AM, Fernando Gont wrote:
>>> Hi, Joe,
>>>
>>> On 07/26/2018 04:14 AM, Joe Touch wrote:
>>>> Hi, all,
> [..
ant implementation. It's true that
calling implementations that probably won't help to fix what is out
there, but maybe this could help prevent new instances of
non-conformance.
Tom
> Thanks!
>
> Cheers,
> --
> Fernando Gont
> e-mail: ferna...@gont.com.ar || fg...@si6networks.com
&
eling. It seems to work fine in such
an environment and is preferable to lowering the MTU for everyone
(even non-tunnels) or turning on jumbo frames (complex to do at large
scale).
Tom
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
>
> ___
>
of transport layer ports, so I think that use of flow
label for this purpose should be recommended somewhere in section 7.
Tom
> Joe
>
>> On Jul 24, 2018, at 12:42 PM, Wassim Haddad
>> wrote:
>>
>> Dear all,
>>
>> We would like to start a WG adoption call for
>&
s
for an application developer to knowingly develop an application that
relies on IPv6 fragmentation. Besides that, RFC8085, which is
referenced in section 5.2, already provides the recommendations that
applications should avoid fragmentation by limiting packer size or
doing PMTU discovery. I don't see
losed
network with low loss and has appropriate security measures in place,
then it can be beneficial. I suspect that describes the network that
your're running iperf in. If this interpretation of the draft's intent
is correct, maybe there could be some words to clarify that.
Tom
> Thanks -
data corruption. Because of this,
probably the only robust method for in-situ OAM is Hop-by-Hop options.
Tom
> Regards,
> Greg
>
> -- Forwarded message --
> From:
> Date: Thu, Jun 28, 2018 at 9:51 AM
> Subject: New Version Notification for draft-mirsky-
sted seems bereft of any details about the new
transport protocol; will another draft be coming that specifies the
transport protocol and answers questions like this?
Tom
>
>
>>>>
>>>> >> >
>>>> >> > Back to your questions that I under
might be opportunities to improve
communications by some coordinated interaction with the network (like
we propose in FAST), but these are strictly optimization and not
requirements to make basic communications work.
Tom
>
> Luca
>
>
>
> On Wed, Jun 20, 2018 at 5:13 PM Tom Herbert
plications
have to change or use a new API for hICN?
If the implication of hICN is that all Internet hosts need to change
to support a new consumer/producer communications model, a new
transport protocol, and a new application API-- there's nothing minor
about that!
Tom
>
> On Wed,
.
I think this draft should distinguish problems inherent in IP fragmentation
and those that have be created by middle boxes that can't deal with
fragments
Tom
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
> ___
> Int-area mailing list
&
On Thu, May 17, 2018 at 11:12 PM, 徐小虎(义先) <xiaohu@alibaba-inc.com> wrote:
> Tom,
>
> It seems that your argument is based on an assumption that GUE is the only
> UDP tunnel mechanism implemented on the chip. What about if other UDP tunnel
> mechanisms (e.g., VXLAN, G
his is nothing
more than programming the TCAM with entries that match GUE v0, GUE v1
IPv4, GUE v1 IPv6. Complexity of implementation is completely
insignificant.
Tom
> Xiaohu
>
> --
> From:Templin (US), Fred L <fred.l.temp...
CMP,
diffserv, security, etc. The current IP over UDP draft doesn't
adequately address the issues and it would be far easier to leverage
all the work that went into RFC8086 than to redo the work here.
Tom
> Regards,
> Behcet
>>
>> Xiaohu
>>
>>
>> ---
P [RFC7510] and TRILL-in-UDP
> (https://tools.ietf.org/html/draft-ietf-trill-over-ip-16#page-20) and etc.
>
GUE variant 1 implements native UDP encapsulation for IPv4 and IPv6.
Except for a different port number, there is no protocol difference
between that and doing IP in UDP as separate prot
are no poor investigators out there -
> the judicial system has built in presumption of innocence to help to deal
> with this.
>
What judicial system are referring to? Not all the world's population
live under a judicial system based on the presumption of innocence--
China and Nort
On Tue, Apr 24, 2018 at 2:11 AM, Dave O'Reilly <r...@daveor.com> wrote:
> Tom,
>
> I think the points you raise below need to be challenged because (a) they are
> not a priori true and (b) they oversimplify a much more nuanced situation.
> See below.
>
>>&
es" that
many reasonable people would not consider meritable to allow access.
For example, in many regions of the world it is considered a crime
speaking out against an unjust government. To a lot of people that is
considered a violation of human rights and such laws are considered
unjust. I would e
ion headers) to a packet in
flight.
Tom
> Maybe we are not synced by this overlay/underlay use case. :-)
>
> Tianran
>
>
>
>
> Sent from WeLink
>
> 发件人： Shwetha Bhandari (shwethab)
> 收件人： Tianran Zhou<zhoutian...@huawei.com>;Frank Br
On Fri, Apr 13, 2018 at 11:22 AM, Mickey Spiegel
<mspie...@barefootnetworks.com> wrote:
> Tom,
>
> On Thu, Apr 12, 2018 at 10:17 PM, Tom Herbert <t...@herbertland.com> wrote:
>>
>> Mickey,
>>
>> Looking at these ippm drafts more closely, I have a muc
ondering if hop-by-hop options been considered for this
application? Their interpretation in the network is unabiguous and
they also have the advantage that the work with any IP protocol or
encapsulation.
Thanks,
Tom
On Thu, Apr 12, 2018 at 3:31 PM, Mickey Spiegel
<mspie...@barefootnetworks.com&
On Thu, Apr 12, 2018 at 3:31 PM, Mickey Spiegel
<mspie...@barefootnetworks.com> wrote:
> Tom,
>
> On Thu, Apr 12, 2018 at 2:46 PM, Tom Herbert <t...@herbertland.com> wrote:
>>
>> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky <gregimir...@gmail.com>
On Thu, Apr 12, 2018 at 2:50 PM, Greg Mirsky <gregimir...@gmail.com> wrote:
> Hi Tom,
> could you please mention which drafts, iOAM or OOAM, you refer to. Please
> note, that OOAM supports both active and hybrid OAM methods, while iOAM only
> the latter.
Section 3 of draft-b
afts only requires 4 bytes. Using the OOAM header approach would add an
>> unnecessary overhead of 4 bytes – which is significant.
>
What is the relationship between this proposal and
draft-fioccola-v6ops-ipv6-alt-mark which is currently searching for a
way to squeeze out two bits in the IP head
Hello,
As per discussion last week, the alternate checksum for GUE has been
changed to use CRC-32C. This was also discussed on a thread in tsvwg
and CRC-32C seems to be the best choice (if it isn't GUE can be
extended with a different one in the future).
Tom
-- Forwarded message
On Mar 7, 2018 7:30 AM, "Templin, Fred L" <fred.l.temp...@boeing.com> wrote:
Hi Tom,
> -Original Message-
> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: Tuesday, March 06, 2018 8:03 AM
> To: Ron Bonica <rbon...@junip
ing the MTU would only benefits the special case and hurts the
common case.
Tom
> Cheers,
> Ole
>
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
lieu of doing IP fragmentation.
This is addresses several of the problems described for IP
fragmentation.
Tom
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
201 - 300 of 389 matches
Mail list logo
