On Thu, Nov 13, 2014 at 7:57 AM, Pat Thaler wrote:
> Comments from an Ethernet point of view.
>
>
>
> 3.1 MTU discovery mentions sending 1200-1400 bytes rather than 1500 to
> allow for tunnel overhead. 1500 bytes seems like a reference to the
> Ethernet maximum frame size (1518 with the MAC Head
On Fri, Nov 14, 2014 at 7:16 PM, Iljitsch van Beijnum
wrote:
> On 14 Nov 2014, at 12:46, Bill Fenner wrote:
>
> > I mentioned this at the mic in the meeting, but thought it would be
> useful to mention on the list. We have brand-new equipment for this IETF
> meeting network,
Hi,
I wanted to bring your
attention to draft-fenner-intarea-probe-clarification, which is intended as
an update to RFC8335 based on a survey of existing implementations and
comparing them with the spec. I'm including the "what's changed since
RFC8335" section below.
https://datatracker.ietf.org
Hi equi,
Thanks for bringing this up. It definitely sounds useful in a mixed version
environment, but I think there's a little bit more needed in this document,
because there are two important cases to consider:
- There's already an RFC4884 extension header
- There is not yet an RFC4884 extension
Hi all,
I've updated the node ID ICMP extension draft that I presented in intarea
in Brisbane. The motivation for this work is that we got a request from a
customer to append the hostname to the interface name field in the RFC5837
response, e.g.,
2 10.2.2.3 11.322 ms
and I thought it was more
n.
>
> For example, "Ethernet1/1-George.sjc" would be a completely legal zone
> identifier under RFC4007. As has also been observed, so would
> "blåbærsyltetøy0/0/0".
>
> Opinions welcome, here or on 6man. Consistency of the two drafts seems
> desirable.
>
kind of implicit negotiation --
it's not unreasonable to imagine that a system that is configured in Norway
could present its blueberry jam interface the way you describe. RFC8343
doesn't specify anything here, and I would lean towards that more-recent
spec reflecting current thinking on
back is
very welcome.
Thanks,
Bill
-- Forwarded message -
From:
Date: Fri, Jul 5, 2024 at 9:20 AM
Subject: New Version Notification for
draft-fenner-intarea-probe-clarification-01.txt
To: Bill Fenner , Chris Lenart ,
Jen Linkova , Mohamed Boucadair <
mohamed.boucad...@o
Hi Carlos,
My high level question is: why does this belong in ICMP? More particularly,
why would a provider be interested in the sustainability aspects of a
single path as seen by traceroute, as opposed to a wholistic view of the
network that could be gathered by a centralized NMS using a netconf
Hi,
I've submitted version -02 of
https://datatracker.ietf.org/doc/draft-fenner-intarea-extended-icmp-hostid/
, which is an RFC4884-based ICMP extension that allows supplying a textual
hostname and/or a single identifying IPv4/IPv6 address for a node. This is
intended to address deployments where
FC 4620?
>
> Regards,
> Brian
>
> On 7/15/24 3:41 PM, Warren Kumari wrote:
> > On Sat, Jul 13, 2024 at 9:03 AM, Bill Fenner wrote:
> >
> >> Hi,
> >>
> >> I've submitted version -02 of https://datatracker.ietf.org/doc/
> >> draft-fe
On Fri, Jul 26, 2024 at 8:17 PM Alia Atlas wrote:
> I read draft-fenner-intarea-extended-icmp-hostid-02 and think it is a very
> useful idea.
>
Thanks!
I'm thinking about it also from the ability to provide additional
> abstraction information that could be useful to annotate a node with.
>
> F
Hi,
As we discussed in the intarea meeting in Vancouver, I'd like to request WG
adoption of draft-fenner-intarea-extended-icmp-hostid. As we found during
and after the wg meeting, it's useful not just for its originally imagined
purpose, but to add additional useful information when translating t
Hi,
I've made a bunch of minor clarifications and updates to
draft-ietf-intarea-extended-icmp-nodeid and submitted them as -02, and I
think it's ready for WG Last Call. As we discussed in the WG meeting in
Bangkok, the use cases in the document are well-defined and clearly useful,
both for the tr
Hi Wassim,
It's well past the proposed 2 weeks, but I just wanted to share my
enthusiasm for this document. It's clear, to the point, and addresses a
real problem that we came across while working with the update to RFC8335
and is relevant to the further ongoing uses of the ICMP extension header.
Hi,
This document addresses a very awkward problem that came up with RFC8335.
The document is clear, straightforward, and deserves advancement.
Bill
On Mon, May 5, 2025 at 12:52 PM Wassim Haddad wrote:
> Dear all,
>
>
>
> This email triggers a WGLC for the “ICMP Extension Header Length Fiel
Thanks, Jen, I've recorded this at
https://github.com/fenner/icmp-node-id/issues/6 . If nothing else we can
treat it as an IETF Last Call comment.
Bill
On Wed, Jul 23, 2025 at 5:10 AM Jen Linkova wrote:
> Sorry, I know that the WGLC has ended, but I've just spotted a text
> which might need
On Wed, Jul 16, 2025 at 5:31 AM Luigi Iannone wrote:
> Dear Authors,
>
> thanks forwriting this document, which is quite clear.
> As a shepherd I went through the document and have a few comments.
>
>
> I think the the definition of _unique_ Node ID is a bit hidden in the
> document and not clear
18 matches
Mail list logo
