Tom,
> Yes I am with you here.
>
> However let's observe that this is pretty common best practice to disable any
> hardware offload on the box when running tcpdump or wireshark.
>
> In fact some implementations (F5) do it for you automagically :)
>
> And as it has been said based on the
Joel,
> On 10 Oct 2022, at 15:36, Joel Halpern wrote:
>
> Eric, you seem to be objecting to something I did not say. I have not asked,
> and do not expect, for the document to mandate or even suggest that arbitrary
> domains should drop packets with SRH. I will note that given that SRH is
> On 9 Oct 2021, at 22:02, Brian E Carpenter
> wrote:
>
> It is mandated by the current IPv6 addressing architecture. Despite many
> discussions, there has never been consensus to change it. So if /64 is not
> the boundary between the routeable part and the host-specific part, it's not
>
> On 25 May 2020, at 17:49, Ron Bonica wrote:
>
> Ole,
>
> When commenting on list, could you indicate whether hats are on or off?
And that is important to you for this particular message because?
> Juniper Business Use Only
Ole
> -Original Message-
> From: otr...@employees.org
> On 6 Dec 2019, at 22:09, Fernando Gont wrote:
>
> I don't think there is much room for interpretation here, but anyway I
> should ask: are you suggesting that I have attacked or been attacking
> the process?
I would rather say taking advantage of the process.
By reiterating the same
Hello,
As agreed in the working group session in Singapore, this message starts a
new two week 6MAN Working Group Last Call on advancing:
Title: Operations, Administration, and Maintenance (OAM) in Segment
Routing Networks with IPv6 Data plane (SRv6)
Author : Z. Ali, C. Filsfils,
Fernando,
>> The takeaway I attempted to highlight is that there is in fact agreement
>> between 6man and spring on how to proceed, and we are proceeding as
>> agreed to work on the relevant documents.
>
> I don't really know what the agreement is, other than the implicit
> agreement that if
>> I don’t see a need to continue this debate on meta issues, but since you
>> framed this as criticism of me in the chair role I found it required to
>> reply.
>
> I expect the chair to uphold a previously reached consensus and put the
> requirement of justifying deviating from it with the
>
>
>
>> I think you have repeatedly made your point.
>
> Yes he has, and he makes a good point that should be heard. Your argument of
> "RFCs aren't the law, and we can ignore parts of them if it suits us" just
> isn't true. RFCs are based on consensus, and ignoring the outcome of that
>
Fernando,
> On 5 Sep 2019, at 21:54, Fernando Gont wrote:
>
> On 5/9/19 22:30, Ole Troan wrote:
>>
>>
>>>> On 5 Sep 2019, at 21:03, Fernando Gont wrote:
>>>
>>> We have wasted way too much time and energy with all the methafores an
> On 5 Sep 2019, at 21:03, Fernando Gont wrote:
>
> We have wasted way too much time and energy with all the methafores and
> curious interpretations of standards by folks pushing and/or supporting
> EH insertion, really.
Pot calling kettle black?
This is an issue we all know is there. And
Joel,
> Part of the reason we write restrictions and requirements into RFCs is so
> that we do not have to repeat the arguments.
>
> If the proponents of the insertion have arguments for why it is now okay,
> they need to make those arguments. And they need to make sure that the
> discussion
Fernando,
>> The IETF is not writing de jure standards.
>> In fact reality is quite different, and the Internet evolves the way it does
>> somewhat independently of what documents the IETF produces.
>> In fact I know of no networking products (or deployments) that follow the
>> intent and
o Gont wrote:
>
> On 4/9/19 09:58, Ole Troan wrote:
>> Fernando,
>>
>>>>> Since there have been plenty of attempts to do EH insertion or
>>>>> leave the IPv6 standard ambiguous in this respect, and the IETF has
>>>>> had consensus that E
> Ron
>
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Ole Troan
> Sent: Wednesday, September 4, 2019 2:58 AM
> To: Fernando Gont
> Cc: Suresh Krishnan ; Ron Bon
Fernando,
>>> Since there have been plenty of attempts to do EH insertion or
>>> leave the IPv6 standard ambiguous in this respect, and the IETF has
>>> had consensus that EH insertion is not allowed, I think it would be
>>> bad, wastefull, tricky, and even dangerous to let a document go
>>>
> End.B6.Insert specified in draft-ietf-spring-srv6-network-programming-01 will
> insert a new SRH in the received IPv6 packet, which results in two SRHs in
> one IPv6 packet. It is contradict with RFC8200 that says Each extension
> header should occur at most once, except for the Destination
is an extension point. If people found some use for that, what's the harm?
That middle boxes get confused? Isn't that a feature? ;-)
Cheers,
Ole
>
> Yours,
> Joel
>
> On 5/9/19 8:36 AM, Ole Troan wrote:
>>> I think it is equally important to note that given an existing way
> I think it is equally important to note that given an existing way of
> encapsulating Ethernet in IP, one ought to have a good reason for creating a
> different one. There is no indication that this use case needs anything
> different than next-header 97.
>
> And Ole, no next-header does
>>> I suspect that we will be far more likely regret this use of 59 in the long
>>> term than we will regret changing to 97 at this early stage.
>> But it’s not that nh=59 can be used to imply that Ethernet follows. That
>> would be very bad.
>> It’s that ip processing stops here.
>> Then if the
> On 9 May 2019, at 11:05, Stewart Bryant wrote:
>
>
>
>> On 08/05/2019 19:13, Ole Troan wrote:
>> Ron,
>>>
>>>
>>> Folks,
>>>
>>> Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-
mation signalled separately?
Cheers,
Ole
>
> Ron
>
>
>
> Juniper Internal
>
>> -----Original Message-
>> From: Ole Troan
>> Sent: Wednesday, May 8, 2019 3:33 PM
>> To: Ron Bonica
>&
Sander,
>
> The next-header should identify what follows, so that anybody parsing the
> packets knows what to expect. Using "No Next Header" should mean "nothing
> follows". Once we start using No-next-header for "some stuff may follow" it
> will become very hard to make sense of packets.
Ron
>
>
>
> Non-Juniper
>
>> -Original Message-
>> From: Ole Troan
>> Sent: Wednesday, May 8, 2019 2:14 PM
>> To: Ron Bonica
>> Cc: Bob Hinden ; Tom Herbert
>> ; SPRING WG ; 6man WG
>&
24 matches
Mail list logo
