Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6

Because the IPv6 delivery header does not include a checksum of its own, it is subject to corruption. SB It is subject to corruption whether or not it has a checksum. SB The point is that there may be undetected corruption. However SB detection in only probabilistic even with a checksum. So SB I

Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6

Isn't systematic rather than random corruption more likely? Stewart On 31/03/2015 23:04, Ronald Bonica wrote: Lucy, David, The proposed text says that outcome 3c) is unacceptable but highly unlikely. For example, assume the following: -That an IPv6 address is assigned to every milligram

Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6

On 30/03/2015 22:49, Ronald Bonica wrote: Lucy, Would the following text work? OLD Because the IPv6 delivery header does not include a checksum of its own, it is subject to corruption. However, even if the delivery header is corrupted, to likelihood of that corruption resulting

Re: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-06.txt

Ron The text GRE over IPv6 is deployable only in environments where the network operator deems the risk associated with behavior c) to be acceptable. really cries out for some form of RFC2119 language such as: GRE over IPv6 is MUST NOT be deployed other than where the network operator

Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6

On 01/04/2015 18:38, Joe Touch wrote: On 4/1/2015 1:14 AM, Stewart Bryant wrote: Because the IPv6 delivery header does not include a checksum of its own, it is subject to corruption. SB It is subject to corruption whether or not it has a checksum. SB The point is that there may be undetected

Re: [Int-area] Fw: Continuing IPv10 I-D discussion.

On 1 Apr 2017, at 6:12 am, Khaled Omar wrote: >> > > That's why all Internet hosts must be IPv10 hosts. If all hosts can be made IPv10, they can all be made IPv6. Thereby reducing this to a previously solved problem. ... or should I have looked more closely at

Re: [Int-area] IP-not-v10

How about Future IP. - Stewart On 28/09/2017 16:37, Khaled Omar wrote: Is there any suggestion for the I-D name other than IPv10? Khaled ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] FW: Request for a mailing list to IPmix I-D.

On 29/09/2017 18:44, Tom Herbert wrote: maybe this work, as well as a discussion about the long term plan for IP, belong in IRTF? I think IRTF would be a fine place to put work on the long term evolution of the Internet. Stewart ___ Int-area

Re: [Int-area] IPv-not-10.

On 28/09/2017 14:23, JORDI PALET MARTINEZ wrote: I don’t think even in those 500 years, we will run out of IPv6 addresses, I hope you are right, but: I am sure that the original IPv4 designers thought that 2^32 was likely to be an infinity of IP addresses, but then the Internet was hugely

Re: [Int-area] Call for support: IPmix I-D (was IPv10)

Whilst I have no opinion on this technical proposal, I do think that the IETF needs to support the ability to discuss and develop ideas that are not mainstream. The "rough consensus and running code" IETF tag line implies a pragmatic approach that seems lacking when it comes to the

Re: [Int-area] [Gen-art] Genart telechat review of draft-ietf-intarea-probe-07

an afterthought, and not a very good afterthought at that. Let's remove the E-bit (aka P-bit) and limit Probe to querying the status of IP interfaces. Ron -Original Message- From: Stewart Bryant [mailto:stewart.bry...@gmail.com] Sent: Wednesday

Re: [Int-area] [Gen-art] Genart telechat review of draft-ietf-intarea-probe-07

I cannot quite work out from the document how this works, but if we are going to PING non-IP interfaces I think the groups that work on those need some time to reflect on the implications. There are certainly a number of non-IP interfaces that may have Ethernet addresses. However, I am not

Re: [Int-area] 回复： Request a WG adoption call for draft-xu-intarea-ip-in-udp

You can also carry IP over UDP by using MPLS over IP, and including an explicit null as the only label in the label stack. A node that did not want to know about MPLS could treat the label as opaque data. - Stewart ___ Int-area mailing list

Re: [Int-area] draft-ietf-intarea-frag-fragile-03

But, always worth including a "do be deleted" note to the reviewers to stop then all sending in feedback about the nits failure. Stewart On 27/11/2018 20:42, Joe Touch wrote: FWIW: On 2018-11-27 12:22, Ron Bonica wrote: Fred, If the NFSv2 and iPERF issues are not blocking, I would like

Re: [Int-area] draft-ietf-intarea-frag-fragile-03

background. Joe On Nov 29, 2018, at 4:06 AM, Stewart Bryant <mailto:stewart.bry...@gmail.com>> wrote: But, always worth including a "do be deleted" note to the reviewers to stop then all sending in feedback about the nits failure. Stewart On 27/11/2018 20:42, Joe Touch wrote:

Re: [Int-area] I-D Action: draft-herbert-ipv4-udpencap-eh-00.txt

On 05/03/2019 01:37, Brian E Carpenter wrote: Hi, This is an interesting draft, but I must say I have serious doubts about the IETF working on any significant update to IPv4 at the IP header level, or of any such updates ever making it into the operational network. This is something that

Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06

:*Stewart Bryant [mailto:stewart.bry...@gmail.com] *Sent:* Wednesday, January 30, 2019 10:15 AM *To:* Templin (US), Fred L ; Fred Baker ; Tom Herbert *Cc:* int-area *Subject:* Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06 Hi Fred I had something quite simple in mind: Fragment

Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06

rently under consideration: https://datatracker.ietf.org/doc/draft-ietf-intarea-gue-extensions/ https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ Thanks - Fred *From:*Int-area [mailto:int-area-boun...@ietf.org] *On Behalf Of *Stewart Bryant *Sent:* Wednesday, January 30, 2019 6

Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06

wrote: Right, but when considering bringing an encapsulation protocol on board, why not bring in a mature one like GUE and use either GUE fragmentation or Joe Touch’s UDP trailer idea? Fred *From:*Stewart Bryant [mailto:stewart.bry...@gmail.com] *Sent:* Wednesday, January 30, 2019 10:35 AM

Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06

On 30/01/2019 18:55, Templin (US), Fred L wrote: IP fragmentation shortcomings (e.g., reassembly errors at high data rates). How big a problem is this in reality? If you are going to run at speed you ought to set a conservatively low MTU? I am always told that the core runs jumbo anyway,

Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06

On 29/01/2019 23:37, Fred Baker wrote: Section 4.5: "IP fragmentation causes problems for some routers that support Equal Cost Multipath (ECMP). Many routers that support ECMP execute the algorithm described in Section 4.4 in order to perform flow based forwarding; As far as I know, routers

Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06

That's true for IPv4,the only way to do stateless ECMP and have fragments follow the same path as non-fragments is to hash over the IP addresses only. There is not enough entropy in that. I remember the original ECMP studies, and if the designers could have got away with just SA/DA/Prot

Re: [Int-area] GPS over wifi for underground locations -- submitted draft RFC.

Given that when I turn off Wifi, my phone asks me to turn it back on to improve location accuracy there must me something similar already deployed. I think that the current system is based on using the SSIDs which have the advantage that they are a broadcast signal and do not require that you

Re: [Int-area] Evaluate impact of MAC address randomization to IP applications

> > From: Int-area mailto:int-area-boun...@ietf.org>> > on behalf of Stewart Bryant <mailto:stewart.bry...@gmail.com>> > Date: Wednesday, 23 September 2020 at 12:38 > To: Andy Smith mailto:ajsph...@gmail.com>> > Cc: "int-area@ietf.org <mailto:int-a

Re: [Int-area] Evaluate impact of MAC address randomization to IP applications

So I am curious, and probably out of touch. MAC addresses are supposed to be unique hardware device addresses that ultimately come from a registry administered by IEEE and are supposed to be allocated exactly once to one hardware entity. Is MAC address randomisation something that IEEE

Re: [Int-area] IPv10 draft (was Re: FW: [v6ops] v6ops - New Meeting Session Request for IETF 109 - IPv10)

> > If you can’t write code, what business do you have proposing standards? > Proposing standards is an additional skill on top of network programming, not > a separate skillset. That is an opinion. I am not sure it is correct, or necessary to express it. It is not one that I agree with. It

Re: [Int-area] draft-zzhang-intarea-generic-delivery-functions

Thank you Jeffery Please see the note that I sent about iOAM who also want to sit after BoS … and both of you want the same space that PALS and DetNet is already using. We plan to have a joint session on this hosted by PALS at the next IETF, but I think we also need to include the iOAM people.

[Int-area] Using ISO8473 as a network layer to carry flexible addresses

Re drafts: https://datatracker.ietf.org/doc/draft-jia-scenarios-flexible-address-structure/

[Int-area] The small address use case in FlexIP

Re drafts: https://datatracker.ietf.org/doc/draft-jia-scenarios-flexible-address-structure/

Re: [Int-area] The small address use case in FlexIP

medium it > does not delay things much. > > Behcet > > On Wed, Feb 3, 2021 at 8:09 AM Stewart Bryant <mailto:stewart.bry...@gmail.com>> wrote: > > Re drafts: > > https://datatracker.ietf.org/doc/draft-jia-scenarios-flexible-address-structure/ > > <ht

Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always?

Sequence number checking in the forwarder is always a problem because it is stateful so I doubt that many high-scale or high-speed forwarders ever did this. I think there is an undisclosed assumption that go up enough levels and its IP so sequence number checking in the transport network (as

Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always?

> On 9 Jun 2021, at 12:19, Derek Fawcus > wrote: > > On Wed, Jun 09, 2021 at 11:23:00AM +0100, Stewart Bryant wrote: >> >> I doubt that there is much L2TP still out there. It was in its prime with >> dialup modems. > > Stewart, > > Isn't

Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always?

Adding PALS and someone there may know. Stewart > On 4 Jun 2021, at 15:13, Bob Briscoe wrote: > > Int-area list, > > I'm looking for experience on common L2TP practice, most likely from > operators. I tried sending this query to the l2tp...@ietf.org > list, as

Re: [Int-area] New Version Notification for draft-lhan-problems-requirements-satellite-net-00.txt

The thing that worries me about iSL is whether the inability to do LI will prohibit licensing in some countries. - Stewart > On 7 Jul 2021, at 03:51, Hesham ElBakoury wrote: > > Mark Handley published the paper "Using ground relays for low-latency > wide-area routing in megaconstellations"

Re: [Int-area] New Version Notification for draft-lhan-problems-requirements-satellite-net-00.txt

Do others find it annoying that when you reply to an int area message that includes the SARAH list they have to then approve their own message? S ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] New Version Notification for draft-lhan-problems-requirements-satellite-net-00.txt

> > From: Hesham ElBakoury > Sent: Thursday, July 8, 2021 10:57 AM > To: Lin Han > Cc: Stewart Bryant ; Int-area@ietf.org; > sa...@jiscmail.ac.uk; rt...@ietf.org; UTTARO, JAMES ; > i...@ietf.org > Subject: Re: [Int-area] New Version Notification for > draft-lhan-pro

Re: [Int-area] New Version Notification for draft-lhan-problems-requirements-satellite-net-00.txt

Sent from my iPad > On 9 Jul 2021, at 01:28, Hesham ElBakoury wrote: > > That is, any traffic carried over Intelsat satellite backhaul from a cell > site to the core is landed in the same country and doesn’t leave the > country’s borders. This capability allows mobile operators to meet

Re: [Int-area] New Version Notification for draft-lhan-problems-requirements-satellite-net-00.txt

Yes, that was interesting work. However, I spoke to one of the ITU Raporteurs about this, and was warned that relaying through ground stations would likely be subject to geo-political restriction in the same way that telephone call routing is (county C will block calls between anyone and

Re: [Int-area] The small address use case in FlexIP

The problem with this approach is that you only secure the address and not the rest of the packet, so you end up with two crypto functions to execute. Also there are other contenders for the suffix such as the arrival action as per network programming, and the perhaps per hop action as per

Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

but you do have a way of finessing many of the standards issues that you face with a new network layer protocol. - Stewart > Thanks, > Yihao > > 发件人: Stewart Bryant [mailto:stewart.bry...@gmail.com > <mailto:stewart.bry...@gmail.com>] > 发送时间: 2021年2月3日 20:50 > 收件人: draft-jia-

Re: [Int-area] The small address use case in FlexIP

> On 5 Feb 2021, at 12:06, Jiayihao wrote: > > - As mentioned in "http://acticom.de/internet-of-things-iot/ > ", a typical payload size equals > just around 25 bytes per IPv6 datagram. Thus typically the saving rate will > be

Re: [Int-area] The small address use case in FlexIP

> On 5 Feb 2021, at 12:06, Jiayihao wrote: > > > - The header format could be described either in separate draft or be > included in previous draft. The reason we have not provide a header format > yet is that the address format itself is already a complex topic, so it's > better for us

Re: [Int-area] The small address use case in FlexIP

dressed. > > Best regards, > > Dirk > > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Stewart Bryant > Sent: 05 February 2021 15:59 > To: Jiayihao > Cc: Lin Han ; > draft-jia-flex-ip-address-struct...@ietf.org; int-area ; > fle...@ietf.org

Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

> On 1 Mar 2021, at 15:33, Toerless Eckert wrote: > > I really don't understand why the IPv6 world has not understood how the most > easy way > to allow for the applicability of IPv6 to grow (especially beyond "just more > addresses thn IPv4") > would be to come up with a backward compatible

Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

> On 1 Mar 2021, at 20:08, Brian E Carpenter > wrote: > > > It would take but a minute to design a longer-address mechanism for IPv6, > although I don't have space to include it in the margin of this email**. But > it would take many years for it to be widely implemented and deployed,

Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

> On 1 Mar 2021, at 20:08, Brian E Carpenter > wrote: > > But it would take many years for it to be widely implemented and deployed, > during which time the Internet would be opaque to such addresses. Answering this separately. You are correct that it would take years for it to be deployed

Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

1: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 it would correctly

Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

th the approach you propose. - Stewart > Guangpeng Li > > From: Stewart Bryant [mailto:stewart.bry...@gmail.com > <mailto:stewart.bry...@gmail.com>] > Sent: Tuesday, March 2, 2021 9:53 PM > To: Toerless Eckert mailto:t...@cs.fau.de>> > Cc: Stewart Bryant &

Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

> On 2 Mar 2021, at 20:15, Brian E Carpenter > wrote: > > On 03-Mar-21 01:32, Stewart Bryant wrote: >> >> >>> On 1 Mar 2021, at 20:08, Brian E Carpenter >> <mailto:brian.e.carpen...@gmail.com>> wrote: >>> >>> >>&g

Re: [Int-area] draft-zzhang-intarea-generic-delivery-functions

> > Juniper Business Use Only > From: mpls mailto:mpls-boun...@ietf.org>> On Behalf > Of Jeffrey (Zhaohui) Zhang > Sent: Tuesday, February 23, 2021 10:19 AM > To: Stewart Bryant <mailto:stewart.bry...@gmail.com>>; Rakesh Gandhi <mailto:rgandhi.i...@gmail.com>

Re: [Int-area] draft-zzhang-intarea-generic-delivery-functions

> > It’s not clear that GAL/G-ACH is designed for situations like this. It definitely was not intended to do this when we designed the CW or when we designed the ACH. - Stewart ___ Int-area mailing list Int-area@ietf.org

Re: [Int-area] draft-zzhang-intarea-generic-delivery-functions

> On 23 Feb 2021, at 15:18, Jeffrey (Zhaohui) Zhang wrote: > > I am not sure if that is a good idea: > > RFC 5586 says “The G-ACh MUST NOT be used to transport user traffic”. To me > IOAM traffic is user traffic with OAM information. Correct on both counts. Though we could change the 5586

Re: [Int-area] draft-zzhang-intarea-generic-delivery-functions

GDFH. It should be able to > co-exist with PW CW. > > Thanks. > Jeffrey > > -Original Message- > From: Jeffrey (Zhaohui) Zhang > Sent: Thursday, February 18, 2021 10:35 PM > To: Stewart Bryant > Cc: int-area@ietf.org; mpls ; p...@ietf.org; Kireeti Kompel

Re: [Int-area] [mpls] draft-zzhang-intarea-generic-delivery-functions

as mentioned above, it’s tempting to > treat GDFH as a channel type just to be able use the already assigned GAL. > > Thanks. > Jeffrey > > From: Rakesh Gandhi mailto:rgandhi.i...@gmail.com>> > Sent: Thursday, February 18, 2021 6:49 PM > To: Stewart Bryant <mailto:ste

Re: [Int-area] draft-zzhang-intarea-generic-delivery-functions

not competing with IOAM > or PW/DETNET CW? > > Thanks. > Jeffrey > > From: Stewart Bryant <mailto:stewart.bry...@gmail.com>> > Sent: Monday, February 22, 2021 5:15 AM > To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>> > Cc: Stewart Bryant <mai

Re: [Int-area] draft-eckert-intarea-functional-addr-internets-00.txt

An interesting draft Toerless. From a background POV it is worth noting ISO 8473 which is in deployment with multi-type variable length address. It is also worth noting that SA is different from DA to the extent that it may not belong in the network layer header of the outgoing packet. The SA

Re: [Int-area] Where/How is the features innovation happening?

> I have no idea when I last sent a packet from my client host to any other > client host. I can give two examples from the world of amateur (ham) radio: I used echolink (VoIP) to a local repeater. I received DX Cluster spots (reported observations of interesting stations) from a service

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

The key question that I would ask Dino is whether these need to be addressed at the network layer? > On 1 Dec 2021, at 22:18, Dino Farinacci wrote: > > Here's my single feature request the network layer should provide: > > (1) I want to be connected ALL THE TIME, I want my computer to use all

Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

There is both a topological view of an address and a protocol view. The topological view is some place in the network, be that a node or an interface. The protocol view is that it is an instruction, for example to deliver the packet to the place identified by the address field lookup. In IP

Re: [Int-area] New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

I agree with Adrian’s comments. This is a good initiative particularly if enhanced as Adrian proposes. Stewart > On 28 Mar 2023, at 03:24, Adrian Farrel wrote: > > [Spring cc’ed because, well, you know, SR. I wonder whether 6man and 6ops > should care as well.] > > tl;dr > I think this is