Brian,
Let me give you a comparison: I think DNS is a system with
a standardized data-model for information about specific objects,
primarily hosts and services. The result/action from using DNS is
most commonly some TCP connection(s). That does not make DNS a
TSV target. The metadata framework is
On Thu, Jul 18, 2013 at 02:11:21PM +0200, mohamed.boucad...@orange.com wrote:
> >[RP] I believe the end-point making the request for flow characteristics
> >will be the CPE in many cases where the applications is not metadata
> >aware. In other words, the CPE makes the request on behalf of applicat
Btw: I wrote something about proxies i would like to amend:
> See section 3.1.4.1 which talks about proxies. The problem really is where
> the proxied information comes from. If the proxy is doing DPI inspection to
> deduce it or some configured mappings, then it's likely going to be unreliable
>
Brian,
Let me give you a comparison: I think DNS is a system with
a standardized data-model for information about specific objects,
primarily hosts and services. The result/action from using DNS is
most commonly some TCP connection(s). That does not make DNS a
TSV target. The metadata framework is
Nice start. Some comments:
1. diagnostics
It would be lovely to have a section about diagnostics,
eg: fragmentation/reassembly counters, status of PMTUD
and the like and explain at least which of the relevant
counters are derived/mandated from tunnel-type independent
RFCs (eg: for interfaces). If
E).
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
>
>
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> ----
--
---
Toer
When & where ? I did not see a mail on the list with that subject nor on the
agenda. Where should i have looked ?
Thanks!
Toerless
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
On Fri, Aug 03, 2018 at 09:48:25AM +0200, Mikael Abrahamsson wrote:
> I've kept saying "Networks must support ip fragmentation properly.
Why ? Wheren't you also saying that you've got (like probably many
else on this thread) all the experience that only TCP MSS gets you
working connectivity in man
On Sat, Aug 25, 2018 at 08:32:41AM +0200, Mikael Abrahamsson wrote:
> > IMHO, we (network layer) should accept defeat on network layer
> > fragmentation and agree that we should make it easier for the
> > transport layer to resolve the problem.
>
> I want to keep the fragmentation requirement for
On Sat, Aug 25, 2018 at 01:46:47PM -0700, Joel Jaeggli wrote:
> It's actually not that useful if it's an icmp message. because it's
> going to fail in many cases where it has to be hashed to a destination.
> just like non-initial fragements do...
>
> 4821 gets you there with tcp.
Its meant to su
On Sun, Aug 26, 2018 at 09:09:54AM -0700, Joe Touch wrote:
>
>
> > On Aug 24, 2018, at 8:24 PM, Toerless Eckert wrote:
> >
> > Of course. Will take a decade to get ubiquitously deployed, but
> > neither IPv4 nor IPv6 will go away, only the problems with fragmenta
On Sun, Aug 26, 2018 at 11:38:57AM -0700, Joe Touch wrote:
> NATs already have what they need to do the proper job - they need to
> reassemble and defragment using unique IDs (or cache the first fragment when
> it arrives and use it as context for later - or earlier cached - fragments).
> There?
On Sun, Aug 26, 2018 at 11:26:47PM +0200, Ole Troan wrote:
>
>
> > On 26 Aug 2018, at 23:12, Joe Touch wrote:
> >
> > As I???ve mentioned, there are rules under which a NAT is a valid Internet
> > device, but it is simply not just a router.
>
> If there really was, can you point to where thos
On Sun, Aug 26, 2018 at 03:50:18PM -0700, Joe Touch wrote:
> > Reassmbly/refragment and MTU discovery puts NAT out of the realm of many
> > cost effective HW acceleration methods. Simple address rewrite does not.
>
> And crumple zones and airbags get in the way of cars running fast and being
> in
On Sun, Aug 26, 2018 at 04:16:39PM -0700, Tom Herbert wrote:
> When the host stack pundits are asking network device stack builders
> to conform to the standard protocols then I believe that is
> reasonable. If firewalls were standard and ubiquitous, and standards
> were adhered to, then host stack
On Sun, Aug 26, 2018 at 05:10:00PM -0700, Joe Touch wrote:
> Agreed, but reassembly is clearly possible (hosts do it). The issue is cost.
>
> We are not in the business of defending a vendor's idea of profit margin
> WHEN it gets in the way of a required mechanism. I've described why it's
> requir
On Sun, Aug 26, 2018 at 08:19:41PM -0700, Tom Herbert wrote:
> Toerless,
>
> I'm not sure what "outsourced into a common network component" means.
> I've done a lot of app and OS development and have NEVER once
> "outsourced" security to the network.
And i worked in a company where for a good whi
Thanks, Joe
This has gotten pretty long. Let me sumarize my suggestions upfront:
For the draft itself, how about it also consideres recommendations not only
for IPv6 but IPv4. Such as simply also only do what we've accepted to be
feasible for IPv6. Like: do never rely on in-network fragmentation
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 worrying only about select transport protocols. So we need a
> mechanism that works equa
On Tue, Aug 28, 2018 at 06:02:19PM -0700, Tom Herbert wrote:
> https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options
> https://tools.ietf.org/html/draft-ietf-intarea-gue-extensions
Thanks
> "NOTE: While [RFC2460] required that all nodes must examine and
> process the Hop-by-Hop Options header,
Dear intarea WG
We think draft https://datatracker.ietf.org/doc/draft-bryant-arch-fwd-layer-ps/
does in part touch aspects related to intarea, so we are interested in
your opinion/feedback. We think its mostly architectual through, so
maybe architecture-disc...@ietf.org is more appropriate for ove
interested, i'd certainly
like to hear about it from you.
Cheers
Toerless
On Mon, Mar 23, 2020 at 09:01:34PM -0700, Joseph Touch wrote:
> Reads like an academic white paper. Worth about as much of my attention.
>
> Sorry, but you asked.
>
> Joe
>
> > On Mar 2
>
> ???-Original Message-
> From: Int-area on behalf of Toerless Eckert
>
> Reply-To: "draft-bryant-arch-fwd-layer...@ietf.org"
>
> Date: Tuesday, 24 March 2020 at 03:10
> To: "int-area@ietf.org"
> Cc: "draft-bryant-arch-fwd-layer...@ietf
On Tue, Mar 24, 2020 at 01:56:01PM -0400, Ted Lemon wrote:
> On Mar 24, 2020, at 1:52 PM, Toerless Eckert wrote:
> > But without a longer term architectural track doing work like this
> > in parallel to current WGs, it will be difficult for the IETF to really
> > drive
On Tue, Mar 24, 2020 at 11:06:53AM -0700, Joseph Touch wrote:
>
>
> > On Mar 24, 2020, at 10:56 AM, Ted Lemon wrote:
> >
> > On Mar 24, 2020, at 1:52 PM, Toerless Eckert > <mailto:t...@cs.fau.de>> wrote:
> >> But without a longer term architectura
Hi Tommy, Lorenzo
Thanks for this work. Its always good trying to make _any_ progress on this
subject matter.
This is a huge can of really interesting worms many of us have been thinking
about for a long time in various aspects, so i have to constrain myself. Not
sure i succeed.
The one most h
Hi Jeff, *.
I am very supportive of i think what could be the spirit of this draft (and
similar
drafts that Stewart mentioned exist), but i am quite worried about some of the
current fundamentals:
This looks a lot like
"i have a point problem (MPLS fragmentation), but to sell it better, i will
Hi Yijao,
Just in case, and from how i interpret what Dirk wrote:
If this new draft is meant to put an end of further work on any of the prior
-00 drafts,
such as (i am guessing) draft-jia-scenarios-flexible-address-structure-00, then
it
would be good to try to put a forward pointer into the sy
Thanks, Jeff, inline.
On Tue, Feb 23, 2021 at 02:01:11PM +, Jeffrey (Zhaohui) Zhang wrote:
> "i have a point problem (MPLS fragmentation), but to sell it better, i will
> give it a more
> inclusive name, but i don't really care that much about the other 99%
> opportunity/challenges".
> (not
On Fri, Jan 15, 2021 at 06:38:09PM -, Adrian Farrel wrote:
> Just to re-assert that the Independent Submissions Stream can publish
> Informational and Experimental RFCs.
Just if its approriate to ask on a list where i could probably wade through
rfcs to find
the answer: Whats the relevance/d
It is somewhat ironic to see how it was IP and IPv6 that where the protocols
that where
successfully enhanced with additional adress semantics not considered when they
where designed
(ok, at last IPv4, but arguably also in a more subtle fashion IPv6). Even
though as Stewart
points out, CLNP woul
Thanks, Adrian
Looking back at a lot of (multicast) RFCs that started as experimental i guess
i had tied
the meaning of the word too much to "blessed by IETF for further adoption", but
it
makes a lot of sense to apply it also to other (non IETF blessed/validated)
experiments.
Just never thought
Hi Brian,
On Tue, Mar 02, 2021 at 09:08:10AM +1300, Brian E Carpenter wrote:
> There is work on supporting shorter address lengths in limited domains where
> that is sufficient. I don't think we have a viable use case yet for longer
> addresses, although we do have a need for 3GPP operators to s
Thanks, Stewart, inline..
On Tue, Mar 02, 2021 at 01:53:12PM +, Stewart Bryant wrote:
> I don???t think there is a simple backwards compatible approach, but we can
> probably do more than we do today.
>
> Backwards compatible means that you could put your new packet into a IPv6
> parser and
Carsten:
Thank you, fully agree. The first time i saw "backward compatibity" pop up in
these discussions was in questions from ISOCI people in discussions
about future evolution of IP/Internet - of course without any clear
specification or reference as to what they actually meant with it.
Would b
As i interjected on the microphone and expanding on now after
i browsed through the meeting minutes of the past meetings:
There is a sad history of intarea running out of time, and
especially in such a group bringing together such diverse interests,
the opportunity for discussion is a lot more imp
Pascal,
Yes, the low-power world in IETF invented a lot of concepts that SRv6 then
reinvented, but
heck, late in the process they managed to at least acknowledge some of that
prior work through
references ;-) nd not, the logic around compact alternatives to SRH also
started with the premise th
that we should be able to do for "normal" hosts as
well.
> Keep safe;
You too
Cheers
Toerless
>
> Pascal
>
> > -Original Message-
> > From: Toerless Eckert
> > Sent: jeudi 8 avril 2021 2:24
> > To: Pascal Thubert (pthubert)
> > Cc: S
a) WG:
I think there should be first substantial discussion about the subject matter
on the mailing list (ohttp) before proceeding on a WG request for this work.
b) Draft:
Neither the charter text, nor draft-thomson-http-oblivious provide a (to me)
good persuasive high level explanation or justi
Toerless
On Mon, Jul 12, 2021 at 01:00:25PM -0700, internet-dra...@ietf.org wrote:
> A new version of I-D, draft-eckert-intarea-functional-addr-internets-00.txt
> has been successfully submitted by Toerless Eckert and posted to the
> IETF repository.
>
> Name: draft-eckert-int
As sent to the WG just right now, i would be happy to have a slot
to discuss the ideas of:
Abstract:
Idea for network packet header beyond rfc8200:
How variable length network layer addresses with a functional semantic can
support requirements for many limited domain internets, such as e
Service for Application-Layer
> Forwarding <https://www.strayalpha.com/pubs/iwan2003.pdf>. In: International
> Workshop on Active Networks (IWAN), IFIP, 2003.
>
> > On Jul 12, 2021, at 4:11 PM, Toerless Eckert wrote:
> >
> > As sent to the WG just right now, i wou
> >
> >
> > Title : Functional Addressing (FA) for internets with
> > Independent Network Address Spaces (IINAS)
> > Author : Toerless Eckert
> > Filename: draft-eckert-intarea-functional-addr-internets-00.txt
> > Pages
n.
>
> My favourite article on that topic is
> https://www.cl.cam.ac.uk/techreports/FUCAM-CL-TR-849.pdf
>
>Brian
>
> >
> > Stewart
> >
> > Sent from my iPad
> >
> >> On 13 Jul 2021, at 00:05, Toerless Eckert wrote:
> >> Dea
Dear int-area WG,
I did ask for a slot in int-area@IETF112 for subject draft and
would like to bring your attention to it.
The draft proposes a new structured address for Multicast resulting
in a forwarding plane that would eliminate many of the complexities
and limitation of BIER-/TE.
I wanted
Dear Int Area WG.
I wanted to bring attention to subject draft which was recently posted by its
IAB
authors, but only to architecture-discuss as its primary discussion list and
panrg as the current most likely research adjacency.
If we want to see work adjacent and following up from this effort,
Fred,
Section 5 of draft-templin-intarea-parcels-06 reads as if there is a mandatory
dependency against draft-templin-6man-omni.
Q1: Is that true ? If not, then i must be overlooking a description how parcels
would work
in the absence of OMNI.
Q2: If there is this dependency, how do you think
On Tue, Feb 01, 2022 at 08:14:08PM +, Templin (US), Fred L wrote:
> > Section 5 of draft-templin-intarea-parcels-06 reads as if there is a
> > mandatory
> > dependency against draft-templin-6man-omni.
> > Q1: Is that true ? If not, then i must be overlooking a description how
> > parcels woul
question trying to understand the feasibility of incremental deployment
Cheers
Toerless
> Thanks - Fred
>
> > -Original Message-
> > From: Toerless Eckert [mailto:t...@cs.fau.de]
> > Sent: Wednesday, February 02, 2022 7:53 AM
> > To: Templin (US), Fred L
&g
nk?
>
> Fred
>
> > -Original Message-
> > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Templin
> > (US), Fred L
> > Sent: Wednesday, February 02, 2022 9:58 AM
> > To: Toerless Eckert
> > Cc: int-area@ietf.org
> > Subject
Tony,
Thanks for the document. Certainly an interesting topic to discuss.
1. Is there any specific reason to bring this up now, e.g.: urgency to
avoid running out of headroom or the like ? Would be good to add that
to the text for motivation. right now it reads very architectural.
2. There is
t had a requirement that every Internet ISP had to use LISP, would
there be a need for Tony to write this document ?
Cheers
Toerless
On Fri, Feb 25, 2022 at 07:40:25AM -0800, to...@strayalpha.com wrote:
>
> > On Feb 25, 2022, at 12:02 AM, Toerless Eckert wrote:
> >
> >&
On Fri, Feb 25, 2022 at 08:34:29AM -0800, Tony Li wrote:
> > Aka: In one possible universe (where less-stupid router vendors finally
> > start putting powerful enough control plane CPU/memory into routers),
> > i may not predominantly have a scalability issue of the routing subsystem,
> > but only
Thanks, Tony,
Inline
On Fri, Feb 25, 2022 at 01:17:17PM -0800, Tony Li wrote:
> > On Feb 25, 2022, at 9:38 AM, Toerless Eckert wrote:
> > I just ran against control plane resource limitations in products way more
> > often during the decades than i felt necessary knowing
Hey wait. I didn't even say tunnel at all ;-)
I just said you can unfortunately not claim to be an Internet ISP and
not carry the whole bloody BGP routing table by just using LISP (unfortunately).
Aka: Joe touch pointed out that something like LISP (on-demand routing
information
if thats an appr
On Fri, Feb 25, 2022 at 08:19:42PM -0800, to...@strayalpha.com wrote:
> I disagree; a tunnel (done correctly) is isomorphic to a link. There’s no
> difference between tunnels and what we already rely on as “L2”.
I guess wrt. routing we (Internet Routing Architecture) started out with
alot of simp
Eliot, *:
Thanks for the historic reference to IEN19!
IEN19 defines that "an address indicates *where* it is". But in the
Internet, my rfc4291 subnet prefix is injected into Internet BGP,
so that (part of the IPv6) address does not tell me nada, zilch,zip
about *it*'s location. Only the routing s
NAT IMHO has been vilified for a lot of bad instances of NAT from the past.
Now unfortunately, the term is identified with evil only, so maybe we should
find a better term for what IMHO are really useful/beneficial instances.
Maybe "address rewrite".
Non-evil address rewrite IMHO is per-flow-state
On Tue, Mar 01, 2022 at 11:54:35AM -0800, Dino Farinacci wrote:
> > For example: The use of locator/identifier in RFC6830 (LISP) i think is,
> > to use the White Knight's terminology, only what an address is
> > called by an xTR (or the LISP instance) but nothing more: It does not
> > defining what
On Thu, Mar 03, 2022 at 09:28:23AM -0800, Dino Farinacci wrote:
> > of its address structure helps the underlay to locate the entity (xTR) that
> > the
> > address is assigned to (xTR). So the name 'locator' is 'just' a good
> > name for what LISP calls/uses the address for, not for how the under
>
> Yours,
> Joel
>
> On 3/4/2022 6:39 AM, Toerless Eckert wrote:
> > On Thu, Mar 03, 2022 at 09:28:23AM -0800, Dino Farinacci wrote:
> > > > of its address structure helps the underlay to locate the entity (xTR)
> > > > that the
> > > >
(ESID) is an example of an
> identifier. A Fully Qualified Domain Name (FQDN) that precisely
> names one logical node is another example. (Note well that not
> all FQDNs meet this definition.)
>
> Regards
>Brian
>
> On 05-Mar-22 00:39, Toerles
; goal is the same).
>
> Best regards,
>
> Antoine
>
> -Original Message-
> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Jens
> Finkhaeuser
> Sent: Monday, March 7, 2022 10:12 AM
> To: Brian E Carpenter
> Cc: Toerless Eckert ; Int-ar
echanisms (well,
> > it uses a specific network function coupled with a database to perform the
> > discovery, but the goal is the same).
> >
> > Best regards,
> >
> > Antoine
> >
> > -Original Message-
> > From: Int-area [mailto:int
[ Disclaimer: Cc some more mailing list in the hope that it would help to reach
more technical and administrative contributors to the specific aspects asked for
IETF than those who can afford to track an IETF wide list such as last-call.]
0. Confused
I am really confused about the email, because
Just some questions about AH/ESP here:
What actually is (so far, without your draft) the technical benefits
and/or differences of ESP and AH in IPv6 being classified as IPv6
extension headers, as opposed in IPv4, where they are currently
defined as "yet another (next level) Protocol ?
Any differe
On Mon, Mar 04, 2024 at 06:11:38PM -0800, Tom Herbert wrote:
> We can treat them as EH for purposes of extension header ordering in
> section 2.2. Also, IPv4 AH needs to be updated to take EH into account
> as mentioned below. Other than that I don't believe there are any
> substantive differences.
ader chain.
Cheers
Toerless
On Tue, Mar 05, 2024 at 05:56:54PM +0100, Toerless Eckert wrote:
> On Mon, Mar 04, 2024 at 06:11:38PM -0800, Tom Herbert wrote:
> > We can treat them as EH for purposes of extension header ordering in
> > section 2.2. Also, IPv4 AH needs to be upda
tension
headers when
your draft goes through. the flag in the registry probably would only impact the
ability of packet parsers to parse at least the extension header chain.
Cheers
Toerless
> Tom
>
> >
> > Cheers
> > Toerless
> >
> > On Tue, Mar 05
ot be said about any of the other IP protocol code points.
Cheers
toerless
> Tom
>
> >
> > Cheers
> > Toerless
> >
> > > Tom
> > >
> > > >
> > > > Cheers
> > > > Toerless
> > > >
>
70 matches
Mail list logo
